Actualización de Safe Network Dev 🇪🇸 26 mayo 2022

Esta es una traducción automática. El original en inglés está aquí: 26 May 2022

Nuestro objetivo principal con Safe Network es la permanencia de los datos. Almacenamos copias de datos en dispositivos que, estadísticamente, es poco probable que estén en la misma región en caso de que, por ejemplo, se produzca un corte masivo de energía o una interrupción de Internet impuesta por el gobierno. Para este propósito, cuantas más copias, mejor, pero eso impone demandas en el almacenamiento y, en particular, en el ancho de banda de la red. Esta semana analizamos un enfoque para abordar este problema, que debería permitir más redundancia con menos flujo de datos.

Progreso general

@Anselme ha solucionado un error de consenso, implementando la antientropía para el traspaso y las generaciones. También se han fusionado reintentos de unión más completos (donde nos aseguramos de que estamos en el estado de la sección actual) :muscle: .

@Chriso está profundizando en la implementación de DBC y ya completó todos los cambios de CLI para pasar un DBC a un nuevo propietario. Ahora está dirigiendo su atención al lado sn_api para asignar el cambio de propietario de DBC.

También podemos informar sobre el progreso en el frente de la observabilidad con @yogesh logrando buenos avances con los mensajes de seguimiento de ruta, asegurándonos de que todos los flujos de mensajes (archivo y registro) tengan una respuesta de seguimiento de ruta al cliente por parte de los adultos y estén registrados en las pruebas.

Y @davidrusu ha estado corriendo la voz, asistiendo a otra reunión de Toronto CompSci para hablar sobre los Tree CRDT. “Una gran discusión en general”, informa, y ​​un excelente lugar para reclutar partes interesadas en Safe Labs.

En el mundo seguro más amplio, el proyecto comunitario en curso para apoyar a MaidSafeCoin en el protocolo ERC20 continúa sin cesar, ¡y nos complace anunciar que estos esfuerzos continúan dando frutos! ¡Entonces, además de Uniswap, eMAID ahora también está abierto para operar en P2PB2B!

Puede agradecer a los miembros dedicados de la comunidad, como @Sotros25 y @Mightyfool, que se han encargado de impulsar este tema continuamente :clap:

Optimización de la transferencia de datos

Cuando alguien realiza una solicitud GET, esa patada inicia una serie de procesos. Primero, la solicitud se transmite a los ancianos en qué sección se almacena el fragmento. Luego, los ancianos calculan qué cuatro adultos almacenan el fragmento, los cuatro XOR más cercanos a la dirección del fragmento, y cada uno de esos adultos pasa su copia del fragmento a los ancianos, quienes luego se los devuelven al cliente solicitante.

Esto proporciona redundancia, siempre hay cuatro adultos con una copia del fragmento y también nos brinda una forma de monitorear el rendimiento. Si un adulto es significativamente más lento o menos confiable, puede ser degradado. Pero viene con una etiqueta de precio.

Si el cliente se pone en contacto con los siete ancianos de la sección solicitando un fragmento ‘A’ de 1 MB, y cada uno de los ancianos, a su vez, solicita el fragmento A de los cuatro adultos que lo sostienen y se los devuelve al cliente, entonces potencialmente son 28 MB (4x7) que pasan a través de la red para una única solicitud GET de 1 MB.

Actualmente, estamos utilizando un sistema intermedio en el que el cliente contacta a tres ancianos al azar y esos ancianos contactan a los cuatro adultos que tienen el fragmento A, por lo que potencialmente tenemos 12 MB (3x4) de datos fluyendo a través de la red para una solicitud de 1 MB, mejor, pero todavía no es genial. Y reducir los contactos a tres ancianos tiene un costo: si solo tenemos tres ancianos interactuando con los adultos, ya no tenemos una gran mayoría para decidir si uno de los adultos es disfuncional, lo que hace que el seguimiento de la disfunción sea más complejo.

Una solución que estamos viendo ahora son los algoritmos de dispersión de información (IDA, también conocido como codificación de borrado). Esto podría ayudarnos a reducir significativamente el volumen de transferencia de datos por GET, haciendo que los adultos pasen una parte de los datos a los mayores en lugar de todo. Luego, los ancianos pasan estos datos compartidos al cliente, quien los vuelve a ensamblar y, voilá, se recrea el fragmento A. Potencialmente, esto podría reducir los flujos en un GET a solo 1,4 MB por un fragmento de 1 MB.

¿Entonces, cómo funciona? Lo primero es lo primero, no estamos proponiendo reemplazar la replicación con un IDA. Algunos proyectos hacen esto (por ejemplo, Solana), pero para nosotros hay demasiadas compensaciones. Entonces, al igual que ahora, si un adulto se desconecta, sus datos se replican en su totalidad a otro adulto. El cambio es que los adultos podrán dividir el fragmento A en siete partes utilizando un IDA y devolver solo un fragmento a los mayores si lo solicitan, en lugar del fragmento completo, lo que significa que se intercambian muchos menos datos.

Una vez que ha recogido cinco de las siete piezas, el cliente puede volver a montar el trozo A.

Esta cifra de cinco de siete sin duda encendió algunas bombillas mentales :bulb:, porque es el mismo umbral que usamos para el consenso BLS, pero IDA es una bestia diferente de la criptografía de umbral, diseñada para optimizar el almacenamiento y la transferencia de datos en lugar de que compartir en secreto. En caso de que se pregunte de dónde provienen los 0,4 adicionales (la transferencia de un fragmento de 1 MB mediante IDA requiere 1,4 MB de flujos de datos), esta es una sobrecarga inevitable por la forma en que funciona el algoritmo.

Por lo tanto, menos estrés en la red y también en el cliente y, por supuesto, los siete ancianos ahora están en contacto con los adultos, lo que hace que el consenso sobre la disfunción sea mucho más simple.También deberían ser posibles optimizaciones adicionales con esta arquitectura. Debido a los cambios recientes en la Membresía, ahora sabemos cuál de los tres adultos que sostienen el fragmento A es el más cercano. Entonces, en lugar de pedir el trozo A, el cliente puede pedir directamente el primer trozo A[0] y los ancianos irán directamente al adulto más cercano; la segunda pieza A[1], los mayores preguntarán al siguiente adulto más cercano, y así sucesivamente. Cualquier falla simplemente se vuelve a intentar en otro adulto. Esto es más eficiente y significa que potencialmente podemos aumentar la cantidad de réplicas (adultos que tienen el fragmento A) sin ningún estrés adicional significativo en la red, con ganancias obvias para la redundancia de datos.


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.