Actualización de Safe Network Dev 🇪🇸 18 agosto 2022

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

Esta semana estamos analizando con un poco más de profundidad las emisiones de SNT. Así es como, luego de la distribución de tokens inicial al inicio de la red, el 70% restante de los el suministro total se creará y distribuirá de forma segura como consecuencia de que las personas carguen datos a largo plazo. Hemos estado pensando un poco más sobre cómo debería funcionar esto para que sea lo más simple y seguro posible, y hemos eliminado un par de pasos de nuestro diseño original.

Saludos a @southside por probar las últimas compilaciones y proporcionar registros :ora:. Mirando esos picos y fallas de nodos ahora.

Progreso general

@Davidrusu ha racionalizado los registros para que cada uno sea una sola línea para que sean más fáciles de analizar y eliminar información superflua. Desafortunadamente, en el proceso habremos borrado el Vdash de @happy being, pero con suerte no de una manera que sea demasiado difícil de desborrar nuevamente.

Gran parte del resto del trabajo consiste en pruebas, pruebas, pruebas. Siguiendo una sugerencia de @Chriso, estamos realizando algunos cambios en la forma en que las pruebas afectan la compilación nocturna, introduciendo una rama de preparación y priorizando la corrección de fallas de prueba que impiden un lanzamiento allí, para que el código siempre esté listo para el lanzamiento o cerca de él.

Y @anselme solucionó un problema en el paso de transmisión de clave efímera BLS en DKG. Tanto la transmisión clave de BLS como los votos de DKG están funcionando correctamente ahora y todos los miembros están recibiendo todos los votos, un paso importante.

Emisiones de SNT

Cuando los usuarios suben datos a la red, pagan. No queremos que cada pago resulte en emisiones de SNT, solo una parte de ellas, y queremos que esa proporción varíe de acuerdo con las necesidades de la red. Si la red requiere más espacio de almacenamiento, la proporción de cargas que dan como resultado una emisión de SNT aumenta para atraer más nodos de almacenamiento, cuando hay mucho espacio, disminuye. El mecanismo exacto para esto aún está en discusión, pero esperamos brindarle más detalles en breve.

Un pago que resulta en la creación de un nuevo DBC (“Génesis”) se llama (por ahora) un “evento de Génesis”. El ‘evento de Génesis’ requiere una ‘Prueba de Génesis’, que es un archivo que codifica información sobre el valor del DBC y sus destinatarios.

El valor del Genesis DBC es bastante sencillo: es una parte fija del valor de la transacción de almacenamiento (por ejemplo, se puede recompensar el 90 % del pago inicial).

La parte de los destinatarios es donde las cosas son un poco más complejas. El ‘evento de génesis’ de una transacción ocurre en una sola sección, y todos los ancianos y los nodos de almacenamiento reciben un pago en proporción a la antigüedad de sus nodos. Pero la membresía de una sección cambia constantemente, entonces, ¿cómo sabemos qué nodos pagar?

La información sobre los ancianos de la sección se encuentra en el Proveedor de autoridad de la sección (SAP), pero es posible que no esté completamente actualizada y, mientras se actualiza a través de AE, la membresía puede cambiar nuevamente.

Entonces, una mejor manera sería usar los destinatarios del pago del “evento de Génesis”. Al cliente se le dice en la solicitud de la tienda (cotización) a quién pagar, incluidos los SAP (ancianos) y los nodos de almacenamiento. Las edades de los nodos en el momento de la cotización se pueden calcular a partir de su ID. De esa manera, cualquiera de los destinatarios puede volver a emitir el DBC para sí mismo y para los demás destinatarios en cualquier momento, y se garantizará que el pago les llegue incluso si ya no están en la sección, el proceso es determinista.

Sin embargo, nuestro primer puerto de escala para la reemisión siempre será el cliente (el pagador), ya que eso quita algo de tensión a la red. Estamos discutiendo si uno de los destinatarios de la recompensa de DBC podría ser el propio cliente, creando un incentivo para que el cliente haga la reemisión, pero si eso falla, cualquiera de los nodos de red mencionados en GenesisProof puede hacerlo en su lugar.

Solo pagar por almacenar adultos, en lugar de todos los adultos en una sección (otro escenario posible), funciona bien, ya que significa menos DBC y menos mensajes. Con el tiempo, los pagos se realizan aleatoriamente en la sección/red porque los nodos de almacenamiento se deciden por la dirección XOR de los fragmentos de datos.

Así que eso es en lo que estamos trabajando ahora. Todavía tenemos que descubrir cómo establecer el costo de la tienda, cómo hacer que la extracción de SNT no sea rentable para las secciones deshonestas y dónde almacenar las GenesisProofs.

También estamos dispuestos a eliminar el apodo ‘Génesis’ para los nuevos DBC, ya que es confuso. Una sugerencia es RootDBC - ¿qué os parece, oh comunidad?


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.