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

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

Hemos estado esperando una actualización sobre la economía segura durante las últimas semanas, y nos complace poder ofrecer una descripción general de nuestro pensamiento actual sobre los certificados de portador digital (DBC). Todavía hay algunas bolas en el aire marcadas como “claves de un solo uso” y “denominaciones”, pero definitivamente estamos convergiendo en una solución viable que será rápida, privada y segura.

Al igual que con muchas otras innovaciones de Safe, los objetivos de los DBC son la simplicidad y hacer que el cliente haga el trabajo siempre que sea posible, lo que generalmente equivale a lo mismo. Queremos evitar tener que almacenar estados (por ejemplo, saldos de cuentas) en la red, o recurrir a la lógica condicional, lo cual genera complejidad. En su lugar, estamos implementando Anti-Entropy en muchas comunicaciones, donde el flujo es: intentar -> éxito (continuar) | fail (reintentar) , mientras que realizar un seguimiento del estado es tarea del Cliente.

Sabemos que está ansioso por ensuciarse las manos nuevamente con una nueva red de prueba, pero para que valga la pena, queremos asegurarnos de que la red sea estable con múltiples secciones y que AE esté funcionando correctamente en todos los ámbitos.

Progreso general

Estamos tratando de resolver un problema intermitente que consiste en ver diferentes Ancianos en una sección recibiendo diferentes mensajes del mismo nodo (esto no debería suceder) y / o elegir diferentes Adultos para almacenar el mismo fragmento. Además, los ancianos a veces escriben datos, que es el trabajo de los adultos. @Qi_Ma y @lionel.faber han estado analizando estas anomalías en los mensajes.

Hemos tenido un impulso para terminar de implementar AE en el cliente, con @bochaco y @yogesh a la cabeza. Todavía hay algunos problemas desagradables allí y @ lionel.faber ha estado ayudando con la depuración del Cliente AE y ya ha identificado una de las causas del comportamiento anómalo, ya que los Ancianos tienen claves de sección diferentes.

@oetyng ha terminado su refactorización de autocifrado (que ahora se ha fusionado en main), y también ha estado trabajando en refactorizar la forma en que se manejan los fragmentos.

Y @danda ha estado analizando la cuestión de las denominaciones de DBC: al seleccionar denominaciones para nuestra moneda, ¿qué valores debemos elegir y por qué? Lo que parece ser una pregunta bastante simple en realidad implica algunas compensaciones interesantes entre la eficiencia de la red y la usabilidad humana.

Una descripción general de los DBC

Un DBC es un ‘vale digital’ único que tiene valor en virtud del hecho de que ha sido emitido de manera demostrable por una casa de moneda confiable como parte de un sistema económico. Para gastar un DBC, debe volver a emitirlo en una casa de moneda. La casa de la moneda puede tomar su DBC y volver a emitirlo como dos o más DBC nuevos si lo desea (por ejemplo, pago a una tienda, el resto como cambio para usted), y se pueden volver a emitir varios DBC como un solo DBC.

Lo importante para nosotros es que los DBC brindan una forma rápida, segura y flexible de realizar pagos que es compatible con la criptografía de firmas de múltiples firmas / umbral y se puede usar en línea y fuera de línea. Simplifican muchos aspectos de la economía de la red segura.

La situación actual

Actualmente nuestro sistema DBC involucra lo siguiente:

Fragmentación: La menta se divide entre secciones, de modo que cada sección es responsable de volver a emitir solo ciertos DBC, determinados por el nombre / id del DBC.

Nodos de menta descentralizados: Dentro de una sección, los nodos de menta individuales (Ancianos) funcionan de forma autónoma, sin coordinación. Un Cliente que realiza una operación de reemisión debe obtener un “ReissueShare” de una gran mayoría de nodos de menta (al menos 5 de 7). Cada “ReissueShare” contiene un “SignatureShare” de BLS. El cliente combina estos “SignatureShare” para obtener una firma completa. El Cliente agrega esta Firma al contenido del DBC para formar un DBC completo, listo para gastar.

Propiedad de DBC: Cada DBC tiene un propietario, identificado por una “PublicKey”. Esto permite que los DBC se almacenen y transfieran en texto sin cifrar sin que nadie los robe. La menta verifica que el propietario haya firmado correctamente cada DBC de entrada cuando se gasta (se vuelve a emitir).

Importe oculto: Los importes DBC están ocultos de modo que solo el remitente y el receptor pueden saberlo. Ni siquiera los nodos de menta pueden ver la cantidad. Sin embargo, la casa de la moneda puede verificar que la suma de DBC de entrada coincide con la suma de DBC de salida mediante el uso de compromisos de Pedersen y pruebas de alcance (a prueba de balas).

Spentbook: Cada nodo Mint escribe en un Spentbook. Durante cada reedición, el nodo de menta primero verificará que todos los DBC de entrada no estén ya en el Spentbook (no se hayan gastado) y que todas las firmas y salidas sean correctas. Luego registra cada entrada como gastada en el Spentbook. Idealmente, queremos trasladar esto al cliente, ver más abajo.

Mejoras futuras

Todavía estamos buscando dónde podemos realizar mejoras en el sistema DBC, y se están considerando los siguientes:

Claves de un solo uso: Los nodos de menta harían cumplir que cada clave pública solo se puede usar en una única transacción de reemisión. Esto puede ayudar con la privacidad porque evita que las claves se utilicen en múltiples transacciones.

El cliente escribe en Spentbook: Con esta configuración, el cliente escribiría entradas de Spentbook antes de contactar al menta. El beneficio de esto es que la llamada de reemisión se vuelve idempotente, lo que significa que un cliente puede hacer la misma llamada de reemisión muchas veces y recibir la misma respuesta cada vez.

Firmas ciegas: Esto nos brindaría un verdadero certificado de “portador” sin dueño. Una forma pura de efectivo digital imposible de rastrear, por así decirlo.

Libro de Espejos Público: Hacer público el Libro de Espejos se considera deseable / necesario para que el público audite la oferta monetaria, es decir, para verificar que no se haya creado dinero adicional a través de fraude / robo o errores / errores.

Para cualquier persona interesada en bucear más profundamente, nuestro código DBC está en la caja sn_dbc.


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.