Esta es una traducción automática. El original en inglés está aquí: Update 12 January, 2023
En primer lugar, muchas gracias a todos los que participaron en nuestra red de prueba la semana pasada. Lo contamos como un éxito ya que todos nuestros cambios recientes funcionaron como se esperaba y la red se mantuvo estable hasta que se llenó. Buen material. 
Algunos de ustedes notaron que necesitábamos 7 ancianos para responder al cliente en lugar de 5. Eso se debe a que estábamos siendo intencionalmente duros al probar las conexiones y asegurarnos de que todo funcionara correctamente. Estamos ocupados implementando más mejoras y le enviaremos otra red de prueba una vez que estén listas. Pero los requisitos de “todos los ancianos deben responder” y requisitos similares de “modo estricto” seguirán existiendo por un tiempo.
En segundo plano, el equipo ha estado trabajando en los detalles más finos de la distribución de tokens. @JimCollinson nos lleva a donde tenemos que ir.
Progreso general
@qi_ma y @roland continúan simplificando el flujo de reubicación. Esta es una de las áreas más complejas para hacerlo bien. Primero, los ancianos deben notar que se ha ido un nodo y votar sobre ese hecho. Luego, deben votar sobre el cambio de membresía, notificar a un candidato para reemplazar el nodo que falta y luego intercambiar mensajes para que el nuevo nodo tenga toda la información que necesita antes de que se le transfieran los datos. Entonces, muchas partes móviles y cuanto más simple podamos hacerlo, mejor.
Para monitorear estos acontecimientos complejos, necesitamos un sistema sólido de observabilidad de monitoreo, que es en lo que está @chriso. Actualmente está trabajando para que OpenSearch y OpenTelemetry funcionen con Amazon ECS.
@Roland también está refinando una GUI para usarla con seguridad para eliminar la necesidad de usar la temida línea de comando. Debería ser demostrable pronto.
@Joshuef continúa reduciendo la cantidad de comunicaciones que manejamos entre nodos. Parece que estamos contactando nodos que están fuera de la sección y luego esperando respuestas que nunca llegan, causando errores.
@bochaco ha terminado de eliminar el flujo de envío de Cmd::SendMsg, introduciendo un nuevo comando para separar los flujos que están destinados exclusivamente a los flujos.
Y @anselme está dirigiendo su atención a algunos refactores de DBC. Más sobre eso en una fecha posterior.
Actualizaciones de los planes para la distribución segura de tokens de red
Hola amigos. Una pequeña actualización para Token Distribution RFC mientras redondeamos algunas soluciones.
Hay muchas partes móviles; desde capacidades técnicas, propuestas de diseño, consideraciones operativas hasta comentarios legales. Mucho se dedica a ajustes que pueden parecer pequeños en la superficie, por lo que le agradecemos todo el apoyo, la paciencia y sus extensos comentarios y comentarios en el último subproceso RFC 0061.
Emisión de tokens y suministro de Génesis
El mayor cambio aquí es una respuesta a la pregunta sobre si acuñamos el suministro total en el lanzamiento de la red, y cómo y cuándo se crea y distribuye el 70% de los tokens restantes.
Acuñar el suministro total en el lanzamiento requería que la Fundación o la propia Red mantuvieran y luego distribuyeran estos tokens a lo largo del tiempo, los cuales tienen desafíos importantes que queremos evitar, principalmente la seguridad, pero también la distribución equitativa de una porción considerable de la poder económico.
Un recordatorio de que los objetivos eran A. liberación gradual de los Tokens Restantes, mientras que al mismo tiempo B. tener los tokens bajo la custodia de la Red.
La solución aquí no es tenerlos acuñados por adelantado, sino que la Red los emita con el tiempo, creándolos a medida que la Red crece, y pagándolos a los operadores de Nodos como Recompensas de suministro de recursos.
Si bien todavía es un trabajo pesado que es poco probable que se complete sin retrasar el inicio de la red, estamos satisfechos de que sea una solución de diseño razonable al alcance, y que se puede implementar a través de una actualización posterior al lanzamiento de la red.
Por lo tanto, el suministro de Génesis, que circulará en el lanzamiento, será el 30% del Suministro Máximo, y el resto solo comenzará a existir después de que se pueda mostrar e implementar una solución satisfactoria, segura y sólida; y luego estos tokens se filtrarán a los contribuyentes de la red durante un período prolongado, probablemente décadas.
Otros cambios menores
También notará algunos otros ajustes menores, como el lenguaje que describe la elegibilidad para Network Royalties como desarrollador de aplicaciones; más precisión en la asignación del SNT para los accionistas; y declarando directamente que eMaid será canjeable 1:1 por tokens de red segura, al igual que el sabor original de MaidSafeCoin.
Suministro máximo
Notará el cambio en el término de Suministro total a Suministro máximo, que es para articular mejor los cambios en torno a las emisiones de tokens y el suministro de génesis propuesto.
Una cosa que proponemos que queda del RFC es el cambio del límite original de Safecoin de 2 ^ 32 al suministro máximo de 4,525,524,120. Esto es para resolver la peculiaridad del crowdsale original que vio una superposición de MAYUDA.
Pero es importante tener en cuenta que:
- Ningún inversor, participante de crowdfund o titular de MAID sale perdiendo.
- Se mantiene el tan promocionado intercambio 1:1 de Maid a SNT; que es fácil de describir y comprender, y muy útil de mantener para la usabilidad cuando se accede a la red con MAID.
- Debido a cambios técnicos fundamentales, los tokens ya no están vinculados a direcciones de red. Esto permite cosas como la divisibilidad, pero también nos da la libertad de especificar un suministro máximo adecuado.
- El suministro máximo de MAID se conoce y anuncia desde hace casi una década, se muestra en cada intercambio y aplicación de cadena de bloques, junto con los términos de canje 1: 1, por lo que no es una sorpresa.
- Es una solución más limpia y creemos que es más fácil explicar las asignaciones del 5/10/15 % otorgadas a los grupos de distribución iniciales, y su participación en la economía general, que examinar repetidamente por qué MAID ahora es del 10,37 %.
Sabemos que esta es una elección que a algunos de ustedes no les gustará, pero es una entre dos opciones estéticas/ergonómicas, las cuales llegan al mismo resultado, por lo que hemos elegido lo que creemos que es el camino de menor resistencia.
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.