Actualización de Safe Network Dev 🇪🇸 25 de febrero de 2021

Esta es una traducción automática. El original en inglés está aquí: Safe Network Dev Update - February 25, 2021

Resumen

Estas son algunas de las cosas principales a destacar desde la última actualización de desarrollo:

  • Habrá una reunión virtual de Community Safe Chat el viernes 26 de febrero (mañana) a las 9PM GMT. Detalles completos aquí.
  • La identificación y eliminación de errores continúa, junto con varias mejoras de eficiencia a medida que logramos un progreso significativo esta semana en el camino hacia una red de prueba pública.
  • Se han fusionado algunos PR importantes de “sn_routing” esta semana, específicamente PR # 2323, PR # 2328 y PR # 2336. Detalles completos a continuación.
  • Dos relaciones públicas más significativas de “sn_routing”, # 2335 y # 2336, ambos críticos para una red de prueba estable, ahora se plantean y deberían revisarse y fusionarse en los próximos días.
  • @scorch ha enviado un PR para (¡finalmente!) resolver “ese problema” donde las versiones de la CLI en sí y los binarios externos como sn_node o sn_authd donde se confunden.
  • Echa un vistazo a la excelente excavación y análisis de @bzee aquí mientras busca mejorar y actualizar la enlaces a Node.js.

Chat seguro de la comunidad: viernes 26 de febrero, 9 p.m. GMT

Los esfuerzos de marketing impulsados ​​por la comunidad continúan gracias al trabajo de @sotros25, @m3data, @piluso y otros. ¡Esfuerzos incansables debemos decir!

Ha habido discusiones y estrategias en el foro, y en pequeñas reuniones de zoom sobre las últimas semanas, incluida esta en la que discutimos algunas de las investigaciones de mercado de @sotros25 sobre proyectos adyacentes.

Estamos encantados de tener otra reunión virtual este viernes, con una invitación abierta para que todos los miembros de la comunidad participen.

Los primeros 45 minutos de la conversación serán sobre la estrategia de marketing comunitario. Después de eso, abriremos la palabra para un debate más amplio sobre la red segura. El objetivo es ayudar a definir la estrategia de marketing y también utilizar el contenido de estas discusiones como video para generar conciencia y participación.

Tenga en cuenta que esta llamada se grabará, transmitirá y retransmitirá, por lo que aquellos cuyos horarios o zonas horarias no funcionen no se la perderán.

Los detalles completos y el enlace para unirse estarán disponibles aquí.

Cliente seguro, nodos y qp2p

Plan del proyecto Safe Network Transfers
Plan de proyecto de cliente seguro
Plan de proyecto de nodo de red segura

El trabajo aquí esta semana ha consistido en estabilizar las redes. Comenzamos la semana investigando un comportamiento extraño, solo visto con ciertos registros habilitados, lo que eventualmente nos llevó a un pequeño fragmento en el enrutamiento en el que manteníamos un “bloqueo” durante una llamada asíncrona larga (enviando un mensaje de cliente), que estaba provocando un estancamiento en las respuestas. Fue difícil de entender; pero una vez que nos dimos cuenta de que la cerradura se llamaba como parte de la declaración “if”, solo teníamos que sacarla y asegurarnos de que la cerradura se cayera una vez que teníamos lo que se necesitaba allí. Esto hizo que las respuestas de los clientes volvieran a aparecer.

Con los cambios en la infraestructura de mensajería completados la semana pasada, los nodos ya no incluyen ninguna lógica para la agregación de firmas, confiando completamente en la capacidad del enrutamiento para hacerlo. Anteriormente, solo teníamos agregación en el origen, donde el enrutamiento agregaba las firmas en los ancianos antes de enviarlo al destino, lo que resultaba en que el mensaje con la firma agregada se enviara al destino varias veces, y los duplicados se filtraran en el nodo de destino. Al mover la agregación de firmas al destino, podemos reducir parte de la carga de los Ancianos y reducir significativamente la cantidad de mensajes que se intercambian. Agregamos soporte para acumulación de destinos en el enrutamiento y lo usamos en sn_node para la comunicación entre una sección y sus Adultos portadores de fragmentos. Con las dos correcciones anteriores, ahora tenemos todas las pruebas del cliente pasando en una sola sección, con un código de nodo enormemente simplificado. Sin embargo, se necesita un RP de seguimiento para cubrir un caso de uso adicional, que son las comunicaciones entre los Ancianos en una sección y los Ancianos en otra sección, una parte del flujo de recompensas (ya que los fondos de la sección son administrados por una sección, pero retenidos / verificados en otra sección). Esto se está cubriendo mientras hablamos, y debería fusionarse antes del fin de semana.

En ese frente, con una pequeña actualización de algunos eventos de enrutamiento, ahora obtenemos nuestra sección hermana PublicKey dividida para que sepamos dónde enviar tokens para completar las carteras de la sección secundaria resultante. Después de un poco más de depuración de flujo allí, eso parece estar pasando y ahora estamos depurando un pequeño bucle de enrutamiento en la división, donde la información de la sección no se detecta correctamente y repetidamente estamos pasando la misma información (incorrecta) a un nuevo nodo. También estamos refactorizando el patrón de comunicación entre clientes, nodos y sus secciones, donde las claves de sección anteriormente desactualizadas estaban causando errores en las recompensas y los flujos de transferencia. Por lo tanto, ahora aplicaremos la verificación y actualización de conocimientos de PublicKey con cada mensaje que se enviaría a través de la red y, en consecuencia, mantendremos a todos los pares actualizados con los últimos conocimientos de la red.

Para empezar, la división de los fondos de la sección será una transferencia encadenada tras otra, ya que todavía no tenemos transferencias de “uno a varios”, y el encadenamiento era una tarea trivial, que funcionaba lo suficientemente bien para una red de prueba. Sin embargo, con la refactorización de TransferAgreementProof hace un par de meses en un débito firmado y un crédito firmado, ahora podemos implementar con relativa facilidad transferencias de uno a varios al incluir un conjunto de créditos. Un regalo para más tarde :).

Como tarea de menor prioridad, y en paralelo a lo anterior, comenzamos a prepararnos para la actualización a una nueva versión de Quinn que nos permite finalmente actualizar a Tokio v1 estable. Lo acabamos de probar y estamos preparando los RP para que esta migración ocurra tan pronto como se publique la versión de Quinn v0.7.0.

Otra mejora que lo hizo en esta semana se refería al borrado de datos privados. Antes de los cambios recién fusionados en self_encryption y sn_client, la eliminación de un blob privado significaba eliminar solo el blob raíz, que era el mapa de datos de los datos reales que se autocifran y almacenan en la red. Nuestra última incorporación al equipo, @kanav, ha implementado un enfoque de eliminación recursiva que elimina los fragmentos individuales, junto con los fragmentos que almacenan los mapas de datos, logrando la eliminación en un sentido real.

API y CLI

@scorch ha enviado un PR para eliminar la opción -V de los subcomandos de CLI para evitar confusiones entre la versión de CLI en sí y la versión de binarios externos como sn_node o sn_authd. Este cambio también incluyó la adición de un subcomando bin-version a los subcomandos $ safe node y $ safe auth para obtener la versión de los binarios externos, de modo que la semántica sea clara, junto con la distinción entre la CLI versión y versiones sn_node o sn_authd.

Actualmente, la biblioteca qjsonrpc está implementada para admitir el estándar JSON-RPC 2.0. Dicho esto, hay ciertos códigos de error que se definen en la especificación que no fueron expuestos por la caja. Esto significa que los consumidores necesitan redefinir las mismas constantes ellos mismos, lo cual no es necesario ya que en cierto sentido son parte de la implementación. Por esta razón, @scorch también envió un PR para exponer estos códigos de error como constantes de qjsonrpc.

Como se mencionó en la sección anterior, también hemos estado tratando de prepararnos para actualizar a Tokio v1, por lo que hemos estado preparando la CLI y las cajas de autenticación para dicha actualización haciendo algunas pruebas preliminares.

CRDT

Hemos estado iterando en el CRDT subyacente al tipo de secuencia en sn_data_types. Anteriormente, Sequence se implementó con LSeq. Probamos una Lista más simple para resolver algunos pánicos con inserciones profundas, y luego cambiamos a GList para admitir el caso de uso de solo crecimiento. En el análisis, todos estos CRDT no hacen el control de versiones del modelo como nos gustaría. Intentan linealizar el orden de los documentos, cuando en realidad el historial de un documento forma un DAG. Tenemos un diseño para un CRDT de registro Merkle-DAG que nos permitiría modelar fielmente el historial de documentos y leer las versiones más actualizadas.

También hemos comenzado a eliminar la mutabilidad de las Políticas de nuestros tipos de datos mutables, es decir, de nuestros tipos de datos basados ​​en CRDT como Sequence. En nuestra implementación actual, hemos intentado resolver todo tipo de conflictos que las mutaciones de políticas concurrentes pueden crear en los datos CRDT. Se ha demostrado que esto complica bastante las cosas y ni siquiera cubre todos los escenarios posibles para la resolución de conflictos. Por lo tanto, decidimos comenzar a movernos hacia un enfoque diferente donde las políticas se vuelven inmutables una vez que hanSe ha definido en la creación de un contenido. Cambiar una Política significará entonces clonar el contenido en una nueva dirección con la nueva Política, y eventualmente se podrá crear algún mecanismo para vincular estas diferentes instancias y las aplicaciones solo podrán usarlo caso por caso.

BRB - Difusión confiable bizantina

Nuestro intento de integrar el prototipo del sistema de archivos sn_fs con BRB ha expuesto un par de asperezas. La razón es que sn_fs está recibiendo operaciones del kernel del sistema operativo más rápido de lo que pueden ser aplicadas por BRB. Con este fin, hemos creado un par de soluciones relacionadas: 1) omitir la capa de red cuando se envía una operación a sí mismo y 2) realizar un seguimiento de cuándo los pares han recibido ProofOfAgreement para evitar enviar la siguiente operación hasta el 2 / 3 de los pares han aplicado la op actual. Esto es necesario para cumplir con el requisito de pedido de origen de BRB. El ordenamiento de la fuente significa que las operaciones que provienen de la misma fuente (actor) deben ordenarse secuencialmente, sin embargo, las operaciones de muchos actores diferentes pueden procesarse simultáneamente.

También como parte de la integración sn_fs, modificamos la caja brb_dt_tree para admitir el envío de múltiples operaciones de árbol dentro de una sola operación BRB. Esto efectivamente nos da una propiedad de transacción atómica para aplicar operaciones CRDT relacionadas lógicamente en forma de todo o nada. Tenemos la intención de utilizar este mismo patrón en otros tipos de datos BRB.

Enrutamiento

Plan del proyecto

Esta semana fusionamos un PR cambiando la forma en que se manejan los mensajes de los clientes, por lo que ahora se pueden enrutar a través de la red de la misma manera que los mensajes de nodo. Esto significa que un cliente puede enviar una solicitud fuera de su sección y recibir una respuesta incluso cuando los destinatarios de la solicitud no puedan conectarse directamente con el cliente debido a NAT restrictiva o problemas similares.

Como se detalla en la sección de Nodos anterior, también implementamos acumulación de firmas de mensajes en el destino, lo que significa que los usuarios de enrutamiento ya no tienen que implementar este flujo manualmente , lo que resulta en un código más simple.

Finalmente, la resolución de la bifurcación PR ahora está en marcha y en revisión. Durante el trabajo en este PR, descubrimos algunos errores adicionales que no estaban relacionados con el manejo de las bifurcaciones. A lo largo de la semana hemos estado ocupados depurándolos y, a partir de hoy, parece que en su mayoría los hemos arreglado todos. Los resultados de las pruebas de estrés internas parecen muy prometedores, además, logramos ejecutar una red de host local con ** 111 (!) Nodos ** en una sola máquina y todo salió bien. Un RP con esas correcciones se encuentra actualmente en estado * borrador * y debería estar listo para su revisión pronto.

Enlaces útiles


No dude en responder a continuación con enlaces a las traducciones de esta actualización para desarrolladores y los moderadores las agregarán aquí.

Como proyecto de código abierto, siempre estamos buscando retroalimentación, comentarios y contribuciones de la comunidad, así que no sea tímido, únase y creemos la red segura juntos.