Actualización de Safe Network Dev 🇪🇸 13 de enero de 2022

Esta es una traducción automática. El original en inglés está aquí: Update 13 January, 2022

Fue fantástico y gratificante ver que la última red de prueba de la comunidad funcionaba tan bien :tada:. Muchas gracias a todos los que participaron :orar: :orar: :orar:. Ahora que la red se está volviendo más estable, es hora de pasar a los puntos más finos de almacenamiento y recuperación de datos, y nuestros planes actuales se describen a continuación. Como siempre, estamos tratando de idear mecanismos básicos que sean livianos y flexibles y que puedan ampliarse fácilmente para respaldar otras funciones, como pagos y agricultura. Lo que es más importante, no implican ningún supuesto de sincronización de red.

Progreso general

@yogesh logró solucionar un problema lógico al promocionar nuevos ancianos, reduciendo la cantidad de rondas AE y, en consecuencia, los intercambios de mensajes, de 150 a 15. Esta es una optimización impresionante de 10X, pero está seguro de que se puede hacer aún más aquí. En una etapa posterior. Él y @anselme ahora están analizando los procesos de manejo de datos descritos en la sección principal a continuación, con @qi_ma depurando el proceso de reconocimiento y manejo de errores en el cliente.

@Joshuef ha presentado Bors, un sistema de automatización que integra múltiples relaciones públicas a la vez, por lo que es un verdadero ahorro de tiempo cuando funciona, que después de un poco de manipulación es la mayor parte de el tiempo ahora, felizmente. Él y @oetyng también han estado trabajando para trasladar los registros a los adultos, simplificar las entradas de registros y flexibilizar el requisito actual de enviar solicitudes a los siete mayores (ver más abajo).

@bochaco está considerando el consenso de membresía del flujo de enrutamiento y el manejo de nodos que se desconectaron, y cómo se integrará con el trabajo de DKG que @davidrusu y @danda han estado impulsando.

@chriso ha estado actualizando y ordenando la documentación de CLI, y @lionel.faber ha corregido algunas pruebas de extremo a extremo que no pasaban, actualizando la herramienta testnet en el proceso.

Manejo de datos

El corazón de la red Safe es su capacidad para almacenar datos de forma segura, confiable y permanente. Aquí hay una descripción general de nuestro pensamiento actual sobre el manejo de datos. También aborda otros temas, como la UI/UX y las comprobaciones de actividad para que los adultos vean si están haciendo lo que deben, y también un mecanismo para que los clientes paguen por el almacenamiento.

Datos válidos

Los datos almacenados en la red deben ser válidos desde el punto de vista de la red. Una vez que un dato es válido, cualquiera puede almacenarlo.

Cada elemento de datos se compone de un nombre, el contenido, una firma y una clave de sección.

El nombre debe estar firmado por cualquier clave de sección válida (antigua o actual), y la clave de sección será de la sección donde se almacena.

Como recordatorio, una sección está compuesta por siete ancianos que toman decisiones y muchos más (60 a 100) adultos que almacenan datos y los ofrecen cuando los ancianos se lo indican.

Los datos son almacenados por los cuatro adultos más cercanos (en términos XOR) a su nombre.

Capacidad de almacenamiento

Retrocediendo un poco, cada adulto es en realidad la computadora de alguien. Puede ser una VM en la nube, una PC doméstica o una Raspberry Pi, o incluso un teléfono inteligente, siempre que tenga suficiente almacenamiento. Pero, ¿cuánto almacenamiento es suficiente? Esto es un poco complicado porque es probable que los requisitos aumenten con el tiempo.

Si un adulto se queda sin espacio dejará de responder correctamente y será penalizado (perderá la edad del nodo). Si la máquina también se usa para otras cosas, como trabajo, música, almacenamiento de fotos, etc., estar llena de fragmentos seguros también afectaría a estos también, por lo que, por ambas razones, es importante que su propietario reciba una advertencia amplia cuando se esté agotando la capacidad: y que la red también es consciente.

Hay algunas opciones aquí. Primero, no establecemos un límite para el almacenamiento seguro, simplemente medimos el espacio que queda en el disco y advertimos cuando está casi lleno. Esto tiene la ventaja de la simplicidad, pero dado que el almacenamiento es un proceso en segundo plano, la capacidad total podría apoderarse del usuario y darle una sorpresa desagradable.

Otra opción sería que el usuario elija un valor fijo para el volumen de almacenamiento, con cantidades sugeridas basadas en el espacio disponible al momento de iniciar el nodo, empujando a la gente hacia una cantidad útil para la red, tal vez resaltando un valor medio.

56f116afea9b75720278c2479bdc3435e0ec9c5f

Esto le da al usuario más control, pero la desventaja es que nosotros, y mucho menos ellos, no sabemos realmente cuál es el valor ideal y cómo podría cambiar con el tiempo.

Puede ser posible crear una partición expandible dedicada solo para datos de Safe Network, pero eso podría ser complejo de hacer, dada la variedad de plataformas y sistemas operativos.

Entonces, este todavía está en discusión.

Comprobar que los adultos se están comportando

Cuando el cliente quiere obtener algún dato, hace una solicitud a los ancianos en la sección más cercana al nombre del dato. Luego, cada anciano calcula qué cuatro adultos deberían sostener el trozo. Lleva un registro de la operación ID que deben cumplir los adultos. Cuando los mayores han recibido una respuesta de un adulto con un fragmento de datos, desvincula el ID de la operación del nombre de ese adulto, ya que ahora se ha cumplido.

En esta etapa, los ancianos verificarán si hay adultos que no respondan. Un adulto no responde si se desempeña significativamente peor que sus vecinos (la tolerancia exacta se calculará experimentalmente). A los adultos que no respondan se les reducirá a la mitad la edad de sus ganglios y pueden ser reubicados.

Almacenamiento en caché de ancianos

Desde hace algún tiempo, hemos estado pensando en la mejor manera de implementar el almacenamiento en caché. Para muchas operaciones, creemos que el almacenamiento en caché en los nodos más antiguos ayudará con el rendimiento y la gestión de datos a medida que los nodos se desconectan, como medida de seguridad contra la pérdida de datos y como una forma de acelerar la redistribución de fragmentos.

En este esquema, los ancianos almacenarán cualquier dato puesto o recuperado de la sección en un caché LRU (usado menos recientemente). Se limitará la capacidad de la memoria caché, y los ancianos dejarán caer los datos usados ​​menos recientemente según sea necesario.

¿Qué sucede cuando promocionamos un nodo?

Cuando promovemos a un adulto a mayor, el adulto primero publica sus datos a otros adultos y los mayores registran los fragmentos en su caché de LRU, eliminando al azar cualquiera que supere su límite de tamaño si es necesario.

¿Qué sucede al reiniciar?

Cuando un adulto reinicia o se reubica, envía sus fragmentos a los tres ancianos más cercanos al nombre del fragmento y almacenan tanto como sea posible en su caché. Los ancianos, a su vez, almacenan cada trozo para cuatro adultos.

Los ancianos pueden eliminar datos de su caché, pero los adultos no pueden eliminar datos. Los adultos informan continuamente su nivel a los mayores, y una vez que están llenos en un 90 %, no se les envían más datos.

Almacenamiento de datos como cliente

Cuando un cliente almacena datos, los envía a tres ancianos para que los firmen. ¿Por qué tres? Porque se garantiza que haya un nodo honesto entre ellos, ya que asumimos que no hay más de dos ancianos defectuosos en una sección de siete. Con un anciano honesto, siempre que los datos sean válidos, el cliente eventualmente obtendrá una gran mayoría de acciones de firma (5) de los ancianos de la sección honesta, lo que significa que se puede almacenar. Tan pronto como un nodo haya devuelto un reconocimiento con una firma de red, ese fragmento puede considerarse almacenado.

Obtener datos como cliente

Dado que los fragmentos están firmados y se autovalidan, en el caso de datos inmutables, el cliente solo necesita un fragmento. No importa si está firmado en la red o no, porque es inmutable.

Los datos mutables (CRDT) son un poco más complejos. En este caso, el contenedor está firmado por secciones, pero los contenidos solo están firmados por el cliente (el propietario de los datos). De esta manera, los datos se autovalidan y son difíciles de corromper, pero un nodo malicioso o defectuoso podría negarse a entregar el contenido o proporcionar contenido antiguo al cliente.

Por lo tanto, el cliente quiere asegurarse de obtener la mayor cantidad de datos posible, lo que significa que debe solicitar los datos al menos a una superminoría de ancianos (tres). Cuantas más copias tenga, más rápido podrá fusionar esas copias para recrear la última versión de los datos.

Pagar por el almacenamiento

Este modelo se adapta muy bien al uso de DBC para pagar el almacenamiento por adelantado. Cuando un cliente solicita que se almacenen 100 fragmentos, cada uno de los ancianos regresa con un precio por firmar los nombres de esos fragmentos.
Las citas de los ancianos deben ser las mismas. Cualquier cita de un anciano que sea muy diferente sugeriría un anciano defectuoso, y el cliente podría señalar ese hecho de nuevo a la sección para que pueda ser tratado.

Luego, el cliente paga el monto cotizado antes de almacenar sus 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.