Actualización de Safe Network Dev 🇪🇸 16 de septiembre de 2021

Esta es una traducción automática. El original en inglés está aquí: Update 16 September, 2021

Esta semana vamos a entrar en un poco más de detalle sobre las mentas distribuidas / fragmentadas, cómo encajan con los DBC y la privacidad, y qué significan tanto para la red como para la experiencia del usuario.

Progreso general

David Rusu y @danda han estado experimentando agregando claves forzadas de una sola vez a su trabajo con firmas ciegas, y también haciendo que el cliente escriba en el libro gastado. Un trabajo en progreso todavía, pero se ve bien hasta ahora.

Se corrigieron muchos errores esta semana. Estamos luchando con otro problema de memoria de nodo en torno a la colocación de archivos. Estos picos de memoria fueron causados ​​por un problema de amplificación del mensaje causado por los flujos de AE ​​en el cliente, así como de los adultos de vuelta a los clientes. Las correcciones para esos se han fusionado ahora y el uso de la memoria se ha reducido considerablemente.

Con esto, comenzamos a buscar más resúmenes sobre la mensajería en la red, con nodos configurados para imprimir estas estadísticas junto con el uso de recursos en los registros. Una vez que tengamos esto en su lugar, comenzaremos a considerar el uso de toda esta información en nuestros sistemas de prueba para asegurarnos de que no puedan colarse más errores de amplificación.

En relación con esto, @chris.connelly ha estado investigando qp2p, eliminando parte de la funcionalidad de agrupación de conexiones que ya no es necesaria.

@oetyng está implementando el manejo de contrapresión (resistencia o fuerza que se opone al flujo de datos deseado a través del software). La idea es que un nodo verifique la carga de su CPU al recibir solicitudes. Si está por encima de cierto nivel, devolverá un mensaje que contiene la carga de la CPU. El nodo receptor puede entonces regular sus comunicaciones basándose en esta información. Después de un tiempo, vuelven a la configuración predeterminada.

No es necesario sincronizar esta información ni llegar a ningún acuerdo. El manejo de la contrapresión es como las pautas de tráfico. Cuando la mayoría de los conductores siguen las pautas de tráfico, el tráfico fluye más suavemente, incluso si hay algunos controladores locos :slight_smile: Lo que significa que, aunque un nodo defectuoso podría optar por no seguir las pautas, ya que la mayoría de los nodos en la red funcionarán correctamente y seguirán las pautas, el tráfico mejorará en comparación con no tener esas pautas.

Al menos esta es la idea, y estaremos probando esto durante algún tiempo. Es una nueva dimensión de la comunicación en red, algo así como lo ha sido AE, y requerirá tiempo para adaptarse.

El error de elección de @Anselme ha sido el proceso de autocifrado que ha estado enviando algunos errores confusos que estaban fallando en algunas pruebas unitarias. Ahora está buscando refactorizar el NRS para simplificarlo.

Mientras tanto, @Lionel.faber ha mejorado la forma en que GitHub Actions trabaja para automatizar las implementaciones de redes de prueba en Digital Ocean, lo que ha funcionado muy bien con el equipo, y @Qi_Ma ha descubierto un comportamiento anómalo con AE. Con cada bicho aplastado nos acercamos un poco más.

Ah, y nos alegró mucho recibir un PR de @davidpbrown. Es genial tener miembros de la comunidad involucrados. Si alguien quiere contribuir, primero debe bifurcar el repositorio, más aquí.

Mentas DBC

DBC Mints ha existido desde los años 90, pero nunca llegó a ser muy popular.

Un problema grave que impide la adopción es que, por lo general, se han centralizado y, por lo tanto, requieren que los usuarios del sistema (titulares de tokens) confíen completamente en el operador de la menta. Un operador de menta codicioso podría inflar la oferta monetaria sin que nadie más lo supiera, robando así valor a todos los usuarios. Además, el operador de menta podría simplemente desaparecer y todos los tokens perderían valor de la noche a la mañana. Por lo tanto, uno debe confiar en el operador de la menta no solo hoy, sino también mañana, y también en que ningún tercero, pirata informático, información privilegiada o gobierno puede afectar su operación.

La descentralización a través de secciones (fragmentación) es una característica central del diseño de Safe Network. El diseño de SN DBC aprovecha y se basa en eso para crear un Mint que es tanto descentralizado como escalable. Hasta la fecha, ninguna criptomoneda implementada [1] ha incorporado mentas DBC descentralizadas de las que tengamos conocimiento, por lo que este es un desarrollo novedoso. Nuestro objetivo es escalar al uso en todo el mundo con liquidaciones de transacciones instantáneas (y privadas).

La funcionalidad de descentralización se puede dividir en algunas áreas principales:

  1. Peers de MintNode dentro de una sección.
  2. Fragmentación: cada sección es responsable de un subconjunto de DBC.
  3. Agregación de clientes
  4. Spentbook distribuido escrito por el cliente

Veamos cada uno de estos.

pares de MintNode dentro de una sección.

Dentro de una sección, cada Anciano también se designa como MintNode. Por lo tanto, hay 7 nodos, con otros listos y esperando para reemplazar cualquier nodo que falle. Cuando se forma la sección o cambia la membresía, los nodos realizan una ronda de * generación de clave distribuida * (DKG) para crear una clave BLS compartida. Esta es una clave multi-sig, de modo que 5 de los 7 nodos (supermayoría) deben firmar un dato para que se considere válido. En el caso de DBC, los datos firmados se denominan * ReissueShare *. EstasReissueShares debe recopilarse de una gran mayoría de nodos en una sección para completar la reemisión de DBC administrados por esa sección.

Digamos que uno de los nodos es malicioso. Quizás un cliente se ha coludido con un nodo para gastar el doble de uno de sus DBC. El nodo malicioso podría responder con una ReissueShare fraudulenta por el doble gasto, pero esta participación por sí sola es inútil, un cliente debe convencer a una gran mayoría de nodos antes de que pueda recolectar suficientes ReissueShares para certificar una reemisión de doble gasto.

Además, es difícil en términos de tiempo y recursos convertirse en un Nodo Mint (sección Anciano) en primer lugar. Safe Network tiene un concepto de Node Age mediante el cual los nodos Adult deben demostrar que son confiables y honestos a lo largo del tiempo. Solo el adulto de mayor edad se selecciona como anciano cada vez que un anciano existente desaparece. Además de esto, un nodo no puede elegir en qué sección estará. Todas estas estrategias dificultan que un atacante logre múltiples nodos maliciosos en una sección relevante para su actividad DBC.

Fragmentación: cada sección es responsable de un subconjunto de DBC.

La fragmentación es un término general que significa dividir los datos para que diferentes servidores manejen subconjuntos de datos.

Nuestro enfoque de fragmentación es bastante simple. La clave de gasto de DBC (una clave única universalmente única) determina qué sección es responsable de manejarla. El software cliente es responsable de enviar un ReissueRequest idéntico a todos los nodos de menta en todas las secciones correspondientes a las entradas DBC en ReissueRequest.

En el siguiente ejemplo, tenemos 3 entradas, cada una de las cuales es manejada por diferentes secciones, cada sección responde con una supermayoría (5 de 7) de acciones reemitidas.

A medida que un MintNode recorre los DBC de entrada, para cada uno de ellos verifica si tiene la responsabilidad o no. Si un MintNode es responsable de un DBC, se consulta al Spentbook sobre si este DBC ya se ha gastado. Por lo tanto, un MintNode ReissueShare solo proporciona SignatureShare para los DBC para los que una sección en particular tiene autoridad.

Agregación de clientes

Cuando un usuario desea volver a emitir un DBC, el software cliente del usuario se pone en contacto con cada uno de los 7 MintNodes de la sección o secciones responsables de los DBC de entrada y envía una ReissueRequest. Cada nodo valida la solicitud y, si todo es correcto, responde con un ReissueShare que contiene un BLS SignatureShare.

El software cliente recopila las respuestas ReissueShare de todos los MintNodes que contactó y los inspecciona. Si al menos 5 nodos en una sección determinada han respondido correctamente, el cliente puede combinar su SignatureShare para formar una Mint Signature final para cada DBC de salida. Con la firma en la mano, el cliente construye los DBC reales que luego se pueden enviar como entrada a otra reedición.

Spentbook distribuido escrito por el cliente

Esta es una característica en desarrollo. La idea básica es que el Cliente se compromete con una ReissueTransaction determinada y publica ese compromiso, identificado por la clave de gasto de DBC (o un hash de la clave), en la red segura antes de realizar una ReissueRequest. Cada MintNode solo tiene que leer la entrada de Spentbook para cada DBC y validar que la entrada esté correctamente firmada por el propietario de DBC. Esto simplifica las operaciones para MintNode, que ya no necesita escribir ningún dato, y mantiene la API de reemisión de MintNode idempotente. En otras palabras, el Cliente puede llamar a reissue muchas veces con el mismo ReissueRequest y siempre obtener la misma respuesta.

Planeamos entrar en más detalles sobre Spentbook en una actualización posterior.

[1] Se publicó un documento técnico en 2019 que describe un sistema DBC Mint descentralizado llamado Scrit. El diseño de Scrit es sustancialmente diferente al nuestro, y no parece haber sido implementado públicamente al momento de escribir este artículo.


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.