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

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

Hoy analizaremos más a fondo los DBC y la propiedad. La red central y los DBC / Mints han ido avanzando en paralelo, pero nos estamos acercando a poder unirlos: cross_fingers :. Están sucediendo muchas cosas en este momento, muchas de las cuales, lamentablemente, son imposibles de describir en una descripción general como esta, pero en resumen, ha sido una buena semana para resolver algunos problemas complicados y de larga data con la estabilidad, las conexiones y las pruebas.

Progreso general

@oetyng ha estado investigando la mejor manera de lidiar con archivos pequeños que no se autocifrarán debido a su tamaño, denominados Spots para distinguirlos de los blobs más grandes (> 3072 bytes) que pasan por SE. Los puntos incluirán muchos archivos de datos de texto sin formato, incluidos DataMaps, por lo que aún deben cifrarse a menos que sean datos públicos publicados.

@yogesh y @joshuef han corregido un error que enviaba un mensaje a todos los ancianos en una sección en lugar de solo la selección que se requiere después de un mensaje de actualización de AE. Esto aumentó drásticamente los mensajes de ida y vuelta en la red, lo que provocó una amplificación de los mensajes (más mensajes para los ancianos significaban más para los adultos y luego más mensajes de regreso). Con la solución fusionada en PR # 473, la eficiencia y el rendimiento de la red han aumentado, lo que significa que nuestras pruebas E2E están pasando de manera mucho más consistente.

También se está trabajando en la introducción de algunos mensajes temporales de sondeo AE. Será utilizado por secciones para sondear periódicamente otras secciones de la red, buscando actualizaciones activando flujos AE, y ayudará a que las secciones se mantengan actualizadas, dando más estabilidad a la red. (Esto eventualmente debería quedar obsoleto una vez que tengamos el tráfico DBC enrutado por toda la red).

@Yogesh también ha solucionado un problema con las pruebas AE, donde el bucle causaba la amplificación de los mensajes.

@ChrisO está trabajando en la CLI y la API, actualizándolas para que sean compatibles con las últimas versiones de la red, y algunos comandos ahora están funcionando usando la clave de genesis, aunque este trabajo aún no se ha convertido en “main”, debería estar disponible “pronto”.

@Chris.Connelly y @lionel.faber han estado experimentando con la eliminación del grupo de conexiones de qp2p. El grupo de conexiones mantiene las conexiones abiertas después de un contacto inicial, pero es un instrumento contundente y una especie de caja negra. Queremos más control para poder optimizar el uso de recursos y, por lo tanto, buscamos implementar algo mejor en el código base de safe_network.

Los problemas de memoria anteriores ahora se han solucionado en su mayoría (estamos reducidos a que la mayoría de los nodos están inactivos ~ 80 MB y subimos a alrededor de 250 MB bajo carga), pero hay un caso de borde pendiente encontrado por @qi_ma donde se encuentra el archivo de registro de un nodo recién reubicado aumentando de tamaño, presumiblemente porque los mensajes no se están recibiendo.

Propiedad de DBC

Al diseñar un sistema DBC, una decisión que debe tomar es si los DBC tendrán propietarios o no. Con DBC sin propietario, cualquiera que tenga en sus manos un DBC puede gastarlo, lo que se aproxima bastante a las monedas de oro, pero tiene sus propios problemas.

Dado que cualquiera que tenga una copia del DBC puede gastarlo, es una práctica común volver a emitir inmediatamente un DBC una vez que lo reciba para asegurarse de que otra persona no lo gaste primero.

Esta reedición implica enviar el DBC a un Mint para convertirlo en un nuevo DBC del mismo valor, esta rotación de DBC es un desperdicio tanto para el cliente como para la red, y lo que es peor, debilita nuestra seguridad, ya que enviar el DBC a un Mint podría resultar en el DBC es robado por un nodo Mint malicioso (recuerde, cualquiera que tenga una copia del DBC puede gastarlo y Mints necesita una copia para ejecutar una reedición).

Los DBC de propiedad resuelven estos problemas agregando la clave pública de los propietarios de DBC al DBC, una Mint requerirá una prueba de propiedad antes de volver a emitir un DBC de propiedad. Esta prueba generalmente involucra al propietario que firma la transacción de reemisión.

Con DBC de propiedad, podemos almacenar el DBC públicamente sin temor a que lo roben, ya que solo nosotros tenemos las claves secretas para gastar nuestro DBC.

NOTA: En realidad, podemos modelar DBC sin propietario con DBC propios empaquetando la clave secreta con un DBC al realizar un pago.

Privacidad y DBC propios

Para ilustrar esta sección, imagine que a Sam le gustaría recibir donaciones en SafeCoin, Sam transmite su clave pública de donación en línea para que todos la vean y solicita a sus seguidores las monedas de repuesto.

Cualquiera que desee donar a Sam volvería a emitir algunos de sus DBC a Sam utilizando la clave de donación de Sam como propietario de DBC y enviando los DBC resultantes a Sam.

Ahora, desafortunadamente, cualquiera que audite los registros de reemisión de Mints podría encontrar las transacciones de Sam escaneando las transacciones que involucren la clave de donación de Sam. Esto no es lo que queremos de un sistema monetario consciente de la privacidad.

Discutimos este escenario en profundidad, pero con la criptografía existente no pudimos encontrar una manera de combinar una clave de donación estática y DBC con propietarios de claves de una sola vez.

Afortunadamente, al mismo tiempo queCuando estábamos explorando estas preguntas, @mav había estado investigando las matemáticas detrás de las técnicas de derivación de claves BLS y se le ocurrió una técnica realmente inteligente que nos permite hacer derivaciones de claves del lado de la clave pública. La técnica permite a cualquiera derivar una clave secundaria a partir de una clave pública conocida.

Por ejemplo, en el caso anterior de Sam, suponga que Janet desea donar $ 10 a Sam. Janet primero derivaría una nueva clave de propietario usando un índice aleatorio

índice_propietario = 256bits_aleatorios ()
owner_pk = sams_donation_pk.derive_child (índice_propietario)

Entonces Janet volvería a emitir un DBC de $ 10 con el propietario establecido en owner_pk. Este DBC de $ 10 luego se envía a Sam junto con el owner_index. Cuando Sam va a gastar esta donación, usa el owner_index para derivar la clave secreta del propietario a partir de la clave secreta de la donación:

owner_sk = sams_donation_sk.derive_child (índice_propietario)

En resumen, hemos ofuscado la clave pública de donación mediante un índice de derivación aleatoria. Este índice se envía a Sam junto con el DBC donado para que Sam pueda obtener la clave de propietario cuando desee gastarla. Dado que el índice de derivación nunca se envía a la Casa de la Moneda, los registros de auditoría no podrán encontrar ninguna referencia a la clave de donación de Sam.

Las claves de Spentbook y Spend

Volver a emitir un DBC siempre implica escribir en el Spentbook. El Spentbook es un registro de todos los DBC que se han gastado y la transacción de reemisión en la que se gastó el DBC; se puede considerar como una gran tabla distribuida que asigna un DBC a una transacción. Cada vez que se gasta un DBC, se agrega al Spentbook. Cuando alguien intente gastar el mismo DBC nuevamente, los Mints notarán que ya tiene una entrada en el Spentbook y se negarán a firmar la reedición.

En iteraciones anteriores del sistema Safe DBC, teníamos a los propios Mints escribiendo las entradas del Spentbook en cada reedición, pero recientemente nos mudamos a un nuevo modelo en el que se espera que los Clientes escriban en el Spentbook. Este cambio es una reducción significativa en la carga en nuestros nodos Mint, ya que escribir en el libro usado y las verificaciones de pruebas de propiedad requeridas eran partes costosas del flujo de reemisión.

Para ilustrar el cambio, continuemos con el ejemplo anterior, Sam recibió una donación de DBC de $ 10 y ahora le gustaría gastarlo.

Primero, Sam construye la transacción que le gustaría ejecutar, aquí está dividiendo sus $ 10 en un DBC de $ 8 y un DBC de $ 2.

let tx = ReissueTransaction {
  entradas: {$ 10DBC}
  salidas: {$ 8DBC, $ 2DBC}
}

Ahora que Sam especificó la transacción, Sam debe comprometer el DBC de $ 10 a esta transacción registrándolo en Spentbook.

Escribir en el Spentbook requiere una prueba de que usted es realmente el propietario del DBC, la forma en que lo hacemos es obligar a los clientes a obtener una clave de gasto DBC y demostrar la propiedad firmando la transacción.

Clave de gasto

Una clave de gasto es la forma en que se hace referencia a los DBC en el Spentbook. Se deriva del propietario de DBC utilizando el hash del DBC.

sea ​​dbc = $ 10DBC;
vamos a gastar clave = dbc.owner.derive_child (sha3_256 (dbc))

Quizás se pregunte por qué no usamos directamente al propietario de DBC. ¿Por qué derivar otra clave cuando se supone que el propietario es una clave de un solo uso? Bueno, la Casa de la Moneda no ve el índice aleatorio utilizado para derivar el propietario, por lo que no tenemos ninguna garantía de que en realidad sea una clave única.

Spentbook requiere que tengamos una clave única para cada DBC, por lo que usamos el hash del DBC para derivar una clave de gasto que se garantiza que será impredecible. Entonces, en total, tenemos tres claves en funcionamiento aquí, derivadas en cadena:

well_known_key <- publicado ampliamente y asociado con una entidad real
owner_key <- derivado de well_known_key usando un índice aleatorio
gastar_clave <- derivado de la clave_propietario usando el hash DBC

Compromiso con una transacción

Sam ahora tiene una transacción con la que le gustaría comprometerse y una clave de gasto.

deje input_dbc = $ 10DBC;
let tx = ReissueTransaction {
  entradas: {input_dbc}
  salidas: {$ 8DBC, $ 2DBC}
}

deje gastar clave = input_dbc.owner.derive_child (sha3_256 (input_dbc))

Sam firma la transacción con esta “llave_desgastar” y envía la “tx”, la “llave_causa” y la firma a la red para que se escriban en el Spentbook.

Una vez que se ha escrito el Spentbook, todo lo que queda por hacer es obtener una firma de Mint que certifique que la transacción es válida. Para hacer esto, Sam simplemente envía la transacción tx a Mint, cada nodo de Mint consultará el Spentbook y se asegurará de que cada entrada de transacción esté comprometida con esta misma transacción. Si eso pasa, verificamos las restricciones de reemisión estándar, es decir, la suma de las entradas debe equilibrarse con la suma de las salidas, y que cada DBC de entrada sea válida.

Una vez que todos los controles pasan, la Casa de la Moneda firma la reedición y devuelve la firma a Sam, quien luego agrega y forma los DBC de salida final. Hecho.

Este nuevo flujo de reedición da como resultado nodos Mint que simplemente actúan como validadores con una vista de solo lectura en Spentbook, esto debería reducir las demandas de recursos en los nodos Elder y brindarnos una red más rápida.


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.