Esta es una traducción automática. El original en inglés está aquí: Update 06 October, 2022
La mayor parte del equipo está ocupada refactorizando Autoridad, el código que nos dice qué actores pueden hacer qué acciones y qué nivel de autorización que requieren. Le entregamos a un joven llamado @dirvine para que explique más.
Progreso general
Otras correcciones también están en curso.
@anselme ha corregido un error en la caja sn_sdkg que implicaba hacer recursivo el manejo de votos. ¡Con esto, un nodo que hace DKG por sí solo llegaría a la terminación recursivamente al manejar su primer voto en una llamada! (No es bueno).
@bochaco continúa depurando las comunicaciones entre los nodos, junto con @qi_ma, y también corrigiendo los problemas encontrados con los comandos de subproceso único y consultas/consultas en la canalización de integración continua (CI).
Mientras tanto, @bzee y @chriso continúan examinando el funcionamiento de Quinn, la implementación de Rust del protocolo Quic para establecer y mantener conexiones entre pares, con miras a refactorizar qp2p.
Autoridad de refactorización
Por el momento tenemos una Autoridad por mensaje y esa autoridad se divide entre nodo, cliente, sección y sección_parte. Es a la vez confuso y propenso a errores. Más recientemente, hemos estado indagando en ‘Autoridad’, lo que significa y lo que nos compra.
El primer paso en esta limpieza es eliminar la autorización de mensajes y centrarse en “Operaciones”. Con eso queremos decir que la operación en el mensaje es donde queremos verificar la autoridad y también poder aplicarla directamente a los datos. Esta parte nos ahorra, 1: tener la autoridad (firmas) dos veces y 2: garantizar que cualquier mutación de datos (incluido el almacenamiento) tenga la ‘Autoridad’ relevante.
Para desglosar esto un poco. Para almacenar trozos o un contenedor (un registro) requerimos que los clientes paguen. Cuando han pagado, cada anciano devuelve una firma de parte de la sección. Luego, el cliente agrega la firma para crear una firma de sección. Esa firma de sección permanece con los datos y hace que los datos sean NetworkValid. Por lo tanto, no tiene sentido firmar todo el mensaje, solo la parte que dice “Almacén ABC”, donde ABC es el nombre de los datos. Entonces, cada pieza de datos ahora tiene SectionAuthority y no nos importa en qué mensaje o formato recibimos la operación firmada.
¿Y qué?, se preguntarán algunos. Bueno, en esencia, lo que estamos haciendo ahora es bastante emocionante desde varios puntos de vista:
- Menos código de nuevo
- Tipos de datos más concretos
- Eliminar el requisito de cualquier firma de mensaje (advertencia en un minuto).
- Y el grande… ver abajo
Los astutos pueden notar en este punto una gran victoria para las redes descentralizadas aquí. Con los elementos de datos SectionSigned y SectionTree de algunas actualizaciones anteriores tenemos datos válidos independientes de la red. es decir, cualquier red que también confíe en nuestro SectionTree, incluso la mayoría (en el caso de un mega hackeo) puede validar y confiar en los datos de NetworkValid. Esta característica permite que los datos se trasladen a otras redes, o incluso a Safe II, ¿quién sabe?
Sin embargo, tenemos mensajes de firma de nodos, y pensamos en eso como ‘Evidencia’. Los nodos se envían mensajes entre sí y a los clientes con datos o sugerencias (como el nodo X está muerto o el nodo Y quiere unirse, etc.) y tratamos sus mensajes como comandos de infraestructura (es decir, transitorios) o comandos de servicio al cliente (dame datos). Como estos mensajes tienen consecuencias en la red, requerimos que los nodos se comporten. Si se descubre que se portan mal, debemos tener pruebas irrefutables de mal comportamiento para poder castigarlos. El mensaje firmado nos da una prueba irrefutable del comportamiento de un nodo.
Teniendo todo esto en cuenta, la refactorización actual es bastante rápida, son solo unos pocos días, pero nos brinda mucha simplicidad y, al mismo tiempo, nos brinda más flexibilidad para almacenar/republicar datos. Imagine que encuentra algunos datos antiguos en su nodo, no está en la red pero debería estarlo. Entonces no debería necesitar pagar para almacenarlo, solo debe decir que aquí hay datos de Sección Firmada, DEBE almacenarlos. Es el contrato de la red con el planeta.
No solo eso, los clientes que pagan para almacenar, en realidad pagan para obtener SectionAuthority en los datos, lo que los convierte en NetworkValid. Ahora, esto significa que pueden agregar la autoridad de la sección a sus datos y elegir almacenarla en cualquier momento que deseen. También pueden volver a publicarlo si la red les falla de alguna manera.
Hay 3 o 4 de nosotros tomando esta tarea esta semana y ya estamos viendo mejoras en la claridad y posiblemente encontremos algunos errores extraños a medida que eliminamos el código anterior (la mensajería todavía tiene un código muy antiguo allí). Es un refactor realmente bueno que hará que la búsqueda de errores sea mucho más simple, ya que hace que las operaciones de la red sean más simples. También hace que la red sea más sencilla de explicar.
Enlaces útiles
- Sitio web de red segura
- Introducción a la red segura
- Aspectos básicos de la red
- Hoja de ruta
- Glosario
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.