Esta es una traducción automática. El original en inglés está aquí: Update 28 September, 2023
Esta semana hemos estado analizando los resultados de la red de prueba y trabajando para corregir errores. Lo primero que hay que tener en cuenta es que, para facilitar la depuración, la red de prueba fue deliberadamente implacable, y un fragmento tuvo que replicarse en los ocho nodos del grupo cercano para que se considerara válido. Dicho esto, descubrió algo extraño en torno a los fragmentos faltantes en los que @qi_ma y @joshuef han estado investigando.
En ocasiones, la descarga de archivos grandes fallaba debido a que faltaban uno o más fragmentos en la descarga. Gracias a todos los que informaron esto. Una de las razones que sospechamos tiene que ver con el almacenamiento en caché. Al buscar un registro de Kademlia tenemos algunas opciones. Quorum::One significa que tomamos la primera respuesta que recibimos, Quorum::All significa que esperamos a que lleguen todas las respuestas y verificamos que coincidan. Dado que los fragmentos son autoverificables (contenido abordado), una respuesta debería ser suficiente, ya que podemos verificar su validez en el acto.
Sin embargo, parece que el almacenamiento en caché de Kademlia, que debería almacenar en caché fragmentos en nodos más cercanos cuando se usa Quorum::One, no funciona de la manera que pensábamos… Parece garantizar que solo un nodo contenga los datos, solo (como en lugar de todavía garantizar que llegue a todos los poseedores de datos, aunque solo exijamos una copia). Así que lo desactivaremos por ahora y volveremos a Quorum::All para ver cómo nos va.
Los costes de almacenamiento incorrectos son otra posible razón por la que faltan trozos. A veces, el cliente solicita costos de almacenamiento a nodos diferentes a aquellos que terminan almacenando los fragmentos. Esto da como resultado que no se pague a los nodos de almacenamiento. También estamos viendo algunos errores de replicación, por lo que también los estamos investigando. (¡Esto bien puede estar relacionado con el trabajo de Quorum/almacenamiento en caché anterior!)
Para hacer la vida más fácil, hemos hecho que si un fragmento no se descarga, todo el proceso se detenga con un mensaje de error “MissingChunk”, en lugar de esperar hasta el final. También estamos mejorando el registro para depurar cada lote de cargas y descargas. Y dado que los registros brindan información valiosa de depuración, ahora estamos registrando la salida de clientes y nodos de forma predeterminada. Los registros son bastante detallados, así que tenga en cuenta que las instancias pequeñas probablemente se llenarán más rápido.
Y hemos agregado pares de arranque codificados en el código del nodo y del cliente, por lo que ya no es necesario configurar la variable SN_PEERS.
El “tamaño de lote” y la “concurrencia” parecen tener algún efecto, ya que los tamaños de lote más grandes aceleran significativamente las descargas y las configuraciones de concurrencia más grandes, hasta 40 aproximadamente, hacen lo mismo. Ahora estamos experimentando con los efectos en el rendimiento de reducir el tamaño del grupo cercano de 8 a 5, lo que debería generar descargas más rápidas y un menor uso de memoria.
Gracias, como siempre, a todos los que se involucraron y pusieron a prueba el proyecto. Como recompensa, podías disfrutar de la diversión de vivir en un entorno hiperinflacionario, además una o dos personas se volvieron extremadamente ricas en SNT. No lo gastéis todo de una vez, chicos.
Notas en efectivo
CashNotes es el nuevo nombre de los DBC que refleja mejor la forma en que se realizan los pagos. El código subyacente no ha cambiado aquí.
Básicamente, son una representación local de tokens en una billetera. Los destinatarios pueden gastarlos en la red a cambio de otros nuevos del mismo valor (valor total de entrada/salida de transmisión).
Las CashNotes se crean en transacciones y se asignan a claves públicas derivadas. Las claves derivadas se crean a partir de la clave pública del destinatario más un índice aleatorio. Se utiliza una clave derivada diferente para cada transacción, lo que hace que cada CashNote sea única y no pueda vincularse a la clave pública original del propietario.
El destinatario necesita el índice aleatorio secreto junto con la información de la transacción principal para generar la clave privada derivada correspondiente y canjear CashNote para recibir pagos.
Progreso general
@joshuef y @qi_ma han sido los principales miembros del equipo involucrados en analizar los costos de tienda incorrectos, las replicaciones fallidas y los fragmentos faltantes. Josh elevó un PR para fallar rápido tan pronto como faltan fragmentos durante la descarga, y temporalmente eliminó el almacenamiento en caché de Kademlia y volvió a Quorum::All para solucionar el problema de los fragmentos faltantes.
Además de ayudar con la depuración, Qi continúa investigando el almacenamiento en caché de libp2p para comprenderlo mejor y estudió la implementación pub/sub de GossipSub en la que @bochaco también está trabajando. Ahora se encuentra en la etapa de prueba y están rastreando cómo se propagan los mensajes entre nodos. Aún queda un pequeño camino por recorrer en ese sentido. @bochaco también ha estado trabajando en notificaciones de recompensas en el nodo.
@Anselme limpió el código no utilizado en la caja sn_transfers, minimizó el riesgo de seguridad al hacer que los módulos sean privados y reescribió los puntos de referencia utilizando API de transferencia de alto nivel para manejar esto cambiar.
@bzee está trabajando para reutilizar las transferencias cuando cambian los costos de los nodos. cuando la tiendaing node aumenta su precio entre que el cliente solicita una tienda y cuando realiza el pago, ese pago es insuficiente. En lugar de tener que empezar de nuevo, queremos volver a intentarlo con el CashNote original y, si eso falla, volver a recargarlo con un CashNote adicional, que es más rápido.
@Chriso Agregó soporte para binarios versionados en la herramienta de implementación automatizada de testnet y ha estado trabajando para que funcione, junto con algunas mejoras interesantes. el ux “seguro”.
@roland también trabajó en correcciones en respuesta a los hallazgos de la red de prueba, y @dirvine redujo el tamaño del grupo cercano de 8 a 5 para mejorar el rendimiento. David también ha estado pensando más en un mecanismo de actualización seguro para Safe.
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.