Esta es una traducción automática. El original en inglés está aquí: Update 23 February, 2023
Más que cualquier otra cosa, lo que dificulta la creación de redes distribuidas y descentralizadas confiables es la asincronía: simplemente no podemos garantizar que el “mensaje A” llegue antes que el “mensaje B”, o incluso si llegará. Con unos pocos nodos, está bien, pero en una sección con decenas de nodos, la cantidad de posibles combinaciones de eventos y mensajes es enorme y es un verdadero desafío para razonar. Esta semana echamos un vistazo a Stateright, una herramienta muy útil para probar nuestras suposiciones algorítmicas, ya que prueba todas las diferentes posibilidades.
Progreso general
@bochaco está probando la respuesta de la red a diferentes tamaños de fragmentos, incluida la forma en que maneja los mapas de datos. Los fragmentos pequeños son más rápidos de transmitir, pero generan mapas de datos mucho más grandes, por lo que tenemos que autocifrarlos recursivamente hasta que tengan menos de chunk_size. También hay otras compensaciones bastante técnicas, pero básicamente estamos buscando un tamaño óptimo para nuestros trozos.
@anselme y @dirvine están buscando un campo razón para DBC SpentProofs, la prueba de una transacción. Este es un nuevo campo que contiene el motivo del gasto. Podría ser el hash de trozos pagados o un número de orden de compra, o algún otro tipo de etiqueta. Lo importante es que los mayores podrán saber si es válido o no (por ejemplo, si es el pago de un solo fragmento, ¿el Tx coincide con el precio de almacenamiento de los datos?).
¿Por qué hacer esto? Simplificación y seguridad. Podría significar que podemos eliminar la necesidad de que los ancianos firmen datos. Por lo tanto, no más riesgo de ‘ataque de clave antigua’ donde, si un mal actor obtiene una clave anterior, podría usarla para validar datos. Con este diseño, las firmas de los ancianos ya no serán válidas.
El flujo:
- Cliente pide cotización para almacenar datos: 1 SNT por favor
- El cliente vuelve a emitir un DBC de 1 SNT para los ancianos con una referencia a los datos como motivo de DBC
- El cliente le dice a los ancianos que se gasta enviando entradas de SpentBook para ese DBC (las entradas contienen el
motivo) - Los ancianos verifican ese motivo y actualizan sus SpentBooks
- El DBC ahora se gasta oficialmente por razón
- El cliente solicita a los ancianos actuales una copia firmada de esa entrada de SpentBook
- Una vez que el cliente obtiene suficientes firmas, puede almacenar los datos proporcionando una copia firmada de la sección actual de la entrada de SpentBook junto con los datos
- Los ancianos verifican si la sección firmada (lo que significa que la mayoría de los ancianos ven el mismo motivo) la entrada de SpentBook se refiere a los datos y los almacena.
Continuamos eliminando los bloqueos de lectura/escritura en el código para un mejor rendimiento y simplificación (sin subprocesos múltiples a menos que sea absolutamente necesario). @joshuef está trabajando para eliminar el grande alrededor del propio estado nodo.
Como algunos miembros perspicaces de la comunidad ya han visto, @oetyng está modelando una versión simplificada de una red de pago.
@chriso está trabajando para mejorar aspectos de la CLI, incluida la reelaboración del comando de actualización.
Y @davidrusu se ha quedado atrapado en Stateright.
Derecho estatal
Stateright es una biblioteca de Rust que promete ser de gran ayuda para probar suposiciones. Básicamente, es un verificador de modelos que ejecuta todas las combinaciones posibles de eventos para verificar si una suposición establecida es válida.
Las redes descentralizadas son difíciles de modelar por una variedad de razones: los nodos pueden morir, los nodos pueden ser bizantinos, los mensajes pueden retrasarse, los mensajes pueden llegar desordenados o no llegar, puede tener condiciones de carrera inesperadas, etc., etc. Stateright ayuda trabajemos a través de todas esas posibilidades.
Como ejemplo, es posible que queramos saber si el doble gasto de DBC es posible con nuestro diseño actual. Modelamos la suposición “Doble gasto no es posible” en el código, lo agregamos a nuestra base de código existente y establecemos Stateright en él. Stateright luego ejecutará cada combinación individual según lo permitido en nuestro modelo de algoritmo. Retrasará los mensajes, hará que dos ancianos fallen a la vez y enviará eventos fuera de orden. Una vez que ha agotado todas las posibilidades sin poder gastar dos veces, obtenemos una bonita marca verde: nuestra suposición es válida. Cada estado que encontró era correcto.
Si algo falla, opcionalmente nos redirige a una GUI donde podemos revisar los mensajes que provocaron la falla y determinar cuál fue el problema.
Lo bueno es que prueba todo, no solo un subconjunto de posibles combinaciones. En las redes descentralizadas, son los casos extremos los que lo matan, y con Stateright, a diferencia de otros métodos que usan muestreo, puede estar seguro de que los cubre todos. Puede haber millones de combinaciones para ejecutar, pero siempre que hayamos escrito las suposiciones correctamente, es bastante rápido.
La otra cosa es que es de gran ayuda para corregir iterativamente nuestro código. Son algunas funciones adicionales que podemos poner en nuestra base de código de producción para verificar modelos. Lo más probable es que usemos esto para escribir piezas específicas de código de producción y hacerlo en un modelo. Cuando el modelo está satisfecho, tomamos ese código de producción y lo guardamos en Safe.
Puede obtener más información sobreut Stateright en los docs o de este video, que aunque es un La introducción es bastante técnica.
Mejor aún, aquí hay un enlace a nuestros experimentos actuales. Para los entrometidos/interesados/curiosos, simplemente clone este repositorio GitHub - maidsafe/stableset-experiments. Usamos la rama maestra de Stateright, por lo que también deberá clonar eso en la misma carpeta donde clonó el repositorio de experimentos.
Tenga en cuenta, sin embargo, que estos son datos experimentales de Safe Labs de la vida real y cambian significativamente día a día a medida que subimos la apuesta en nuestra búsqueda de simplicidad.
Si realiza una cargo run --release y luego abre http://127.0.0.1:3000, verá la GUI. Luego puede hacer clic manualmente en qué mensajes enviar o, de hecho, hacer clic en “ejecutar hasta completar” y le mostrará dónde están los problemas actuales. Tenga en cuenta que casi siempre tenemos problemas allí, ya que estamos probando iterativamente, así que no se desanime, en realidad es genial :sonriendo:.
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.