El último lanzamiento, Ruido v1.1.2, finalmente llega 9 meses después del lanzamiento inicial de Noise.
El lanzamiento involucra un refactor completo que ha permitido que Noise adopte mejoras significativas de rendimiento, seguridad, privacidad y ergonomía del desarrollador.
Haga clic aquí para acceder a Github de Noise, o aquí para acceder a los godocs de Noise, por ejemplo, código y documentación.
ruido es una pila de red P2P obstinada y fácil de usar para aplicaciones descentralizadas y protocolos criptográficos escritos en Go.
ruido está hecho para ser mínimo, robusto, amigable para el desarrollador, eficiente, seguro y multiplataforma en multitud de dispositivos al hacer uso de una pequeña cantidad de dependencias de grado de producción bien probadas.
Ahora, analicemos las novedades.
Se introdujo un grupo de conexiones limitado para evitar que los desarrolladores tengan que mantener arduamente el ciclo de vida de las conexiones y los recursos asociados con un solo par.
El grupo de conexiones de forma predeterminada está limitado de tal manera que un solo nodo puede tener, como máximo, un número específico de conexiones entrantes y salientes abiertas en cualquier momento.
Si el grupo está lleno y se necesita establecer una nueva conexión, el grupo desconectará con gracia la última conexión insertada (bloqueará la rutina actual hasta que las últimas conexiones insertadas se vacíen por completo) para dejar espacio para la nueva conexión .
Este cambio reúne una experiencia de usuario mucho más simple para los desarrolladores que usan Noise.
Para enviar / recibir mensajes, y enviar solicitudes / respuestas entre pares, no se requiere ninguna administración sobre las conexiones de un desarrollador.
Los protocolos de red implementados sobre Noise, por lo tanto, ya no tienen que preocuparse por los supuestos detrás del estado o el ciclo de vida de las conexiones entre pares.
Con la introducción de la agrupación de conexiones viene un desacoplamiento de las identidades de pares de conexiones de larga duración a nodos externos.
Las identidades de pares ahora se conservan opcionalmente fuera de la instancia de conexión en una tabla de enrutamiento de Kademlia desacoplable que puede conservarse en el disco / en la memoria.
Además, la API de Kademlia para Ruido ahora admite el envío / recepción de mensajes a / desde pares, o la conexión a pares mediante su clave pública Ed25519.
Eventos que pueden estar enganchados a Kademlia.
El módulo de descubrimiento de pares se ha generalizado para admitir la búsqueda de ID de pares (compuesto por su IP / puerto público y la clave pública Ed25519) en caso de que tenga su clave pública Ed25519.
El módulo de descubrimiento de pares para Kademlia.
Para mejorar el anonimato, la privacidad y la seguridad de los nodos, Noise ahora asume estrictamente que todas las conexiones serán de corta duración.
Las conexiones por tiempo de espera predeterminado después de una duración de tiempo especificada no deberían producirse actividades de lectura / escritura.
Tener un tiempo de espera inactivo permite que los nodos cierren correctamente las conexiones no utilizadas y liberen recursos extraños.
Opción funcional para especificar un tiempo de espera inactivo.
Con frecuencia, las conexiones de reciclaje también permiten primitivas criptográficas confidenciales asociadas con el cifrado / descifrado de mensajes por cable a través de pares para que sus claves sean recicladas con frecuencia.
Las conexiones entre pares de forma predeterminada ahora se cifran con el modo de contador Galois AES de 256 bits (GCM) con una clave compartida Curve25519 establecida por un apretón de manos Diffie-Hellman de curva elíptica.
En detalle, el protocolo de protocolo de enlace ejecutado al establecer una conexión con un compañero es el siguiente:
sus pares se envían entre sí sus efímeras claves públicas Ed25519, los pares convierten las claves públicas que recibieron en claves públicas Curve25519, sus pares convierten sus efímeras claves privadas Ed25519 en claves privadas Curve25519, los pares establecen un secreto compartido al realizar ECDH con sus claves privadas Curve25519 privadas y sus Clave pública Curve25519, los pares usan el secreto compartido como una clave simétrica y se comunican desde entonces con mensajes cifrados / descifrados a través de. GCM AES de 256 bits con un nonce de 12 bytes generado aleatoriamente.
El proceso es similar a cómo se realizan los apretones de manos sobre TLS 1.2 sin el uso de la función de derivación de clave (KDF), pero sin requerir importar y mantener todo el conjunto de TLS en su proyecto.
Las ID de pares están representadas por una dirección IPv4 / IPv6 y un puerto entero de 16 bits sin signo y una clave pública Ed25519. Los ID se intercambian después de que se establece una sesión cifrada a través de una conexión entre pares.
En una versión posterior, las opciones estarán disponibles para deshabilitar / personalizar el protocolo de protocolo de enlace utilizado para los nodos.
La idea de personalizar el protocolo de protocolo de enlace proviene del siguiente problema de Github enviado por un miembro de la comunidad.
Se introdujeron nuevos métodos para crear complementos que pueden engancharse a eventos emitidos a lo largo del ciclo de vida de un nodo.
Kademlia ahora está completamente desacoplado y ahora es un complemento opcional que puede implementarse en su aplicación.
Puede integrarse en su aplicación simplemente llamando al método Bind a su nodo antes de que su nodo comience a escuchar nuevos pares.
Una aplicación básica habilitada para Kademlia en 34 líneas de código.
También se proporciona una gran cantidad de API de opciones funcionales para personalizar los tiempos de espera, la configuración y el registro.
Algunas de las varias opciones configurables.
Todos los tiempos de espera, la configuración del grupo de conexiones y el registro se proporcionan valores predeterminados razonables para que pueda usar Noise desde el principio. Más explícitamente:
No se imprimen registros por defecto. Se genera un par de claves Ed25519 al azar para un nuevo nodo. Los pares intentan marcarse como máximo tres veces. Se permite un total de 128 conexiones salientes en cualquier momento. Se permite un total de 128 conexiones entrantes en en cualquier momento. Las conexiones caducan después de 10 segundos si no se producen lecturas / escrituras.
Se han reducido muchas dependencias a su mínimo. En total, Noise v1.1.2 solo consta de aproximadamente 4000 líneas de código.
El mayor cambio es un cambio en las bibliotecas de registro de rs / zerolog a uber-go / zap después de los puntos de referencia de rendimiento en aplicaciones que hemos realizado internamente con Noise.
Muchas de nuestras aplicaciones son críticas para el rendimiento y necesitan rastrear grandes cantidades de registros. El almacenamiento en búfer incorporado de registros con uber-go / zap ha sido extremadamente útil.
Más explícitamente:
El registro se maneja mediante uber-go / zap. La agrupación de búferes de bytes se maneja mediante valyala / bytebufferpool. Las pruebas de la unidad se manejan mediante stretchr / testify. Las firmas Ed25519 se manejan mediante oasislabs / ed25519. es manejado por agl / ed25519.
Opcionalmente, se puede especificar una función de serialización y deserialización para los tipos Go que se enviarán a / de sus pares.
Esto le permite especificar el formato de cable de los mensajes enviados entre sus pares para que estén en una amplia variedad de formatos, como protobuf, msgpack, json o incluso binario sin formato (¡haga clic aquí para ver un ejemplo!).
Todos los métodos que terminan con un sufijo de * Message en la API para Node, como RegisterMessage, por ejemplo, manejan automáticamente la serialización / deserialización en el cable.
Documentación para el método RegisterMessage.
Consulte los ejemplos y la documentación aquí para obtener más información.
Se introdujeron varios métodos (esperar hasta que finalice el protocolo de enlace, esperar hasta que se cierre la conexión) para mantener y rastrear el ciclo de vida de las rutinas, las instancias de nodo, las instancias pares e incluso los recursos de conexión.
Esto nos ha ayudado mucho en la creación de pruebas unitarias y pruebas de integración que verifican los casos extremos de redes para aplicaciones altamente concurrentes que hemos implementado internamente.
En total, una sola conexión genera 4 goroutines:
uno para manejar la lógica del protocolo, uno para reciclar una conexión en caso de que se agote el tiempo de espera, uno para leer y almacenar en búfer bytes sin procesar de una conexión, y uno para enviar y almacenar en búfer bytes sin procesar a una conexión.
Un solo nodo genera solo 1 goroutine para escuchar nuevas conexiones.
También puede ejecutar sus propios puntos de referencia separados localmente en un solo núcleo ejecutando cualquiera de estos comandos:
vaya a ejecutar github.com/perlin-network/noise/cmd/benchmark_send
vaya a ejecutar github.com/perlin-network/noise/cmd/benchmark_rpc
Las versiones de ahora en adelante están marcadas con un número de versión formateado como MAJOR.MINOR.PATCH.
Los principales cambios importantes implican un aumento en MAYOR, los cambios menores compatibles con versiones anteriores implican un aumento en MENOR, y los parches y las correcciones de errores implican un aumento en PATCH a partir de v2.0.0.
Por lo tanto, el ruido a partir de ahora respeta principalmente las versiones semánticas. Además, Noise permanecerá con MAJOR en v1, ya que aún debe considerarse que se encuentra en su fase inicial de desarrollo.
Principalmente lo respeta porque, debido a un desafortunado incidente en el que las versiones anteriores de Noise se etiquetaron incorrectamente (v0.1.0, v1.0.0, v1.1.0 y v1.1.1), la información del módulo Go de las versiones anteriores se almacenó en caché de forma incorrecta en el proxy. golang.org y sum.golang.org.
Esto había causado varios problemas con los usuarios que buscaban adoptar Noise en sus proyectos; como se muestra aquí y aquí.
Como resultado…
El ruido a partir de ahora tendrá versiones futuras a partir de v1.1.2.
Hasta que la API de Noise sea estable, las versiones posteriores solo incluirán baches en MINOR y PATCH.
Integrar el ruido en el soporte de su proyecto Go Los módulos Go ahora son tan simples como ejecutar ve a buscar github.com/perlin-network/noise.
Un punto de dolor que me resuena fuertemente de la comunidad es que las versiones anteriores de Noise no estaban bien documentadas.
A partir de esta versión, todos los métodos y estructuras en Noise ahora están bien documentados, con un código de ejemplo comprobable de Go proporcionado en el godoc de Noise ubicado aquí.
La documentación y los ejemplos de ruido se pueden encontrar aquí.
De hecho, con el último Go, ejecuta estos dos comandos y puedes probar un ejemplo de chat descentralizado creado con Noise.
(terminal 1) vaya a ejecutar github.com/perlin-network/noise/cmd/chat -p 9000
(terminal 2) vaya a ejecutar github.com/perlin-network/noise/cmd/chat -p 9001 127.0.0.1:9000
Damos la bienvenida a más ejemplos proporcionados por la comunidad y nos complace responder cualquier otra pregunta sobre la documentación de Noise.
Abra un RP o haga sus preguntas en un nuevo número de Github.
Mejor aún, únase a nosotros en nuestro servidor Discord y hable con nosotros directamente si tiene preguntas o si desea contribuir con algún código.
Ahora que Noise está casi completo, algunas características se me ocurren y creo que deberíamos priorizarlas en las próximas versiones.
La opción de personalizar los protocolos de protocolo de enlace / deshabilitar el protocolo de enlace. Reintroducción del reenvío de puertos NAT-PMP / UPnP. Una transición a una API de opciones alternativas para configurar las opciones. Una API más extensa para registrar tipos de Go que se serializarán / deserializarán automáticamente. -cable. Paquetes para protocolos de cotilleo implementados sobre ruido. Paquetes para protocolos de consenso implementados sobre ruido. Más ejemplos y documentación.
Las contribuciones son muy bienvenidas y apreciadas, con nuestro apoyo siempre disponible en caso de que desee que una de estas características salga antes.
De lo contrario, esperamos que pruebe Noise y que le ayude significativamente a realizar su próxima aplicación descentralizada.
En ocasiones, prevalecerán pequeños cambios importantes, pero consideramos que deberían ser muy poco probables en las próximas actualizaciones a partir de ahora.
PD En caso de que se pregunte acerca de las actualizaciones de Perlin, se publicará una publicación sobre lo que vendrá a continuación para Perlin en el futuro cercano.
Hasta la próxima,
Kenta Iwasaki.
