Esta es una traducción automática. El original en inglés está aquÃ: Update 08 June, 2023
En todo el mundo, miles de nodos siguen zumbando, almacenando y reproduciendo cuidadosa e incuestionablemente las fotos de gallos de la comunidad y las opciones musicales insondables para siempre, y para siempre, y para siempre. No se preocupe, vamos a eliminar esta red de prueba a su debido tiempo. TodavÃa no hemos llegado allÃ, pero a medida que pasa el tiempo, la red se vuelve notablemente más estable, predecible y escalable, lo cual es extremadamente gratificante. Continúe cargando y compartiendo, y publique sus registros si ve algo adverso.
Bajo el capó
Algunos resultados de pruebas concluyentes nos han convencido de cambiar nuestro modelo de replicación de datos de empujar a tirar. Según el modelo de inserción que hemos estado usando hasta ahora, cuando hay abandono (un nodo se desconecta), los nodos con copias de los datos en poder del nodo inactivo los empujan al siguiente nodo más cercano. Algunos de esos nodos tendrán éxito en empujar sus fragmentos, otros no, pero deberÃa haber suficiente tolerancia en el sistema (según lo controlado por la elección de valor k) para garantizar que no se pierdan datos.
El método de extracción es similar, excepto que el nuevo nodo, al darse cuenta de que es el heredero del nodo muerto, solicita fragmentos de su grupo cercano. Una vez más, algunas solicitudes pueden tener éxito, otras no, pero al final se deben recibir todos los fragmentos.
Entonces, ¿cuál es la diferencia? Está en la cantidad de mensajes que se envÃan y la cantidad de copias adicionales que son necesarias para que el modelo push funcione. @Qi_ma ha estado realizando pruebas en condiciones extremas de abandono y descubrió que la atracción es superior en todas las métricas: mensajes, CPU, memoria y tasa de éxito. Por lo tanto, el cambio fue una obviedad. A partir de ahora estamos usando el modelo pull.
Es mucho mejor, pero seguimos viendo mensajes caÃdos ocasionalmente, por lo que el éxito aún no es del 100 %.
En otros lugares, los DBC ahora se están replicando, sentando las bases para pagar por los datos, que será el tema de una futura red de prueba. @bochaco ha creado una ilustración de Merkle DAG y cómo construyen un árbol para el chunks que nos permite usar la raÃz del árbol como comprobante de pago del almacenamiento, que reproduciremos aquÃ.
Los comprobantes de pago de almacenamiento se generan utilizando un árbol Merkle binario:
Un árbol Merkle, también conocido como árbol hash, es una estructura de datos utilizada para la verificación de datos.
y sincronización. Es una estructura de datos de árbol donde cada nodo no hoja es un hash de
sus nodos secundarios. Todos los nodos hoja están a la misma profundidad y están tan a la izquierda como sea posible.
posible. Mantiene la integridad de los datos y utiliza funciones hash para este propósito.
En Safe, para pagar a la red por el almacenamiento de datos, todos los archivos se autoencriptan primero
obteniendo todos los fragmentos que el usuario debe pagar antes de subirlos. Un Merkle binario
El árbol se crea utilizando las direcciones/Xornames de todos estos fragmentos, cada hoja en el árbol de Merkle
contiene el valor obtenido al codificar cada Xorname/dirección de Chunk.
El siguiente árbol muestra cómo se usarÃan dos archivos A y B, con dos fragmentos cada uno.
para construir el árbol de Merkle:
[ Root ]
hash(Node0 + Node1)
^
|
*-------------------------------------------*
| |
[ Node0 ] [ Node1 ]
hash(Leaf0 + Leaf1) hash(Leaf2 + Leaf3)
^ ^
| |
*----------------------* *----------------------*
| | | |
[ Leaf0 ] [ Leaf1 ] [ Leaf2 ] [ Leaf3 ]
hash(ChunkA_0.addr) hash(ChunkA_1.addr) hash(ChunkB_0.addr) hash(ChunkB_1.addr)
^ ^ ^ ^
^ ^ ^ ^
| | | |
[ ChunkA_0 ] [ ChunkA_1 ] [ ChunkB_0 ] [ ChunkB_1 ]
^ ^ ^ ^
| | | |
*----------------------* *----------------------*
| |
self-encryption self-encryption
| |
[ FileA ] [ FileB ]
El usuario vincula el pago realizado a los nodos de almacenamiento configurando el valor raÃz del árbol de Merkle
como el valor 'Dbc::reason_hash'. Gracias a las propiedades del árbol de Merkle, el usuario puede
luego proporcione el DBC de salida y el registro de auditorÃa para cada uno de los fragmentos que se pagan con el mismo
DBC y árbol, a los nodos de almacenamiento al cargar los Chunks para almacenarlos en la red.
@Anselme ha estado solucionando algunos errores en el grifo y la billetera, que actualmente no marcan los DBC como gastados en la red. También ha resuelto algunos problemas de registro.
@Roland ha generado un PR para recopilar métricas de sistemas, redes y procesos. Esto está detrás de una puerta de caracterÃsticas, lo que significa que se puede activar y desactivar según nuestras necesidades. DeberÃa ser útil durante las redes de prueba para recopilar métricas de la comunidad. Más adelante habilitaremos las métricas de OpenSearch, pero esta es una solución simple por ahora.
@ChrisO tiene un proceso de lanzamiento de red de prueba automatizado que funciona de forma experimental. DeberÃa estar listo para la acción en vivo muy pronto. Él y @aed900 también han estado trabajando en otros aspectos de las redes de prueba, incluida la gestión de secretos en Digital Ocean. Angus también ha estado analizando un problema en el que los nodos privados (detrás de NAT) se escriben en la tabla de enrutamiento, que no es lo que queremos.
Afortunadamente, @bzee, que ha estado indagando en libp2p, cree que una próxima versión deberÃa resolver este problema por nosotros.
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.