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

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

Esta semana vamos a entrar en más detalles sobre la desvinculación de DBC y cuáles son las implicaciones y compensaciones para la experiencia del usuario y la eficiencia de la red.

Progreso general

Un anciano es un tipo especial de nodo con derechos de voto y deberes administrativos, mientras que un adulto almacena datos y los entrega a pedido, pero para el cliente se ven exactamente iguales. @chris.connelly ha estado trabajando en algunos errores que ven a un cliente tratando de arrancar a un adulto, que luego lo ignora creando un bucle desagradable.

Chris también ha estado trabajando para mejorar la herramienta sn_launch (¡como algunos de ustedes vieron!) Y depurar la actualización qp2p.

@JimCollinson ha estado analizando el tema de las credenciales, usando multisig para poder agregar más opciones de autenticación a la contraseña básica / mnemónico, incluidas claves de hardware, mnemotécnicos adicionales o frases semilla, etc. Por ejemplo, el usuario puede estipular que cualquiera de tres Se deben presentar cinco credenciales para desbloquear una caja fuerte. Multisig también abre la puerta al uso de n terceros confiables para recuperar una cuenta, si lo desea. Los usuarios de Safe Network perderán inevitablemente las credenciales, y multisig ofrece una ruta para la recuperación segura de la cuenta, lo que permite al usuario controlar el equilibrio de riesgo como mejor le parezca.

@bochaco está viendo cómo el Cliente valida que la sección con la que está hablando está actualizada a través de AE.

@Qi_Ma está analizando lo que sucede cuando los adultos se llenan. Actualmente, existe un comportamiento aberrante en la forma en que los ancianos eligen el siguiente adulto alternativo no completo para almacenar un fragmento y en cómo los Ancianos saben dónde está el fragmento, dado que ya no es el XOR más cercano al nombre del fragmento.

Mientras tanto, @chriso ha estado trabajando en la modernización de la API para tener en cuenta los nuevos cambios de mensajería, una tarea que ya casi está terminada.

El trabajo de @oetyng con la integración del “autocifrado” reforzado junto con el refactor de manejo de fragmentos se ha fusionado. La dualidad de alcance (público / privado) se ha movido del nivel de fragmento a nivel de blob, simplificando enormemente las tareas de código y nodo. También se ha agregado el manejo adecuado de la clave secreta de facto, que las salidas de autocifrado junto con los fragmentos cifrados. Con esto en su lugar, el trabajo en el procesamiento por lotes de fragmentos ahora puede continuar.

También hemos fusionado nuestra rama de funciones de trabajo en progreso con master (o más bien, movimos el HEAD de main a esto si quieres entrar en los detalles de git …). Esto significa que la rama era más estable que la principal. Estamos viendo más pases de CI y un código mucho más limpio en general. Hay muchas cosas en esta rama que se han agregado y todavía estamos probando y depurando varios flujos. Pero con AE en todas partes y un flujo de código más simple en el nodo, todo esto se vuelve más fácil a medida que avanzamos. Entonces, aunque todavía no hay una red de prueba para que la gente juegue, vamos en la dirección correcta.

Más sobre DBC

Continuando con nuestra serie sobre DBC, esta semana profundizamos en la propiedad de la desvinculación. Discutimos por qué es importante y revisamos las diferentes formas en que las criptomonedas centradas en la privacidad intentan lograrlo.

Con suerte, esta descripción general puede servir para proporcionar a los lectores más contexto y antecedentes para las tecnologías que hemos estado explorando, como pruebas de conocimiento cero, firmas ciegas, compromisos, denominaciones fijas, etc.

Desvinculabilidad

Entonces, ¿por qué es importante que un token monetario sea desvinculable? En resumen, porque ese es el medio técnico para lograr la propiedad monetaria más general y altamente deseable de fungibilidad. Fungibilidad significa que un token es intercambiable con otro.

Piense en dos lingotes de oro sin marcar de igual peso. Uno es tan bueno como el otro. Son indistinguibles. Sin embargo, si estas barras están marcadas con números de serie y alguna entidad central mantiene una lista de todos los intercambios de oro rastreados por el número de serie, entonces podemos tener una situación en la que una barra vale menos que otra en la mente de los destinatarios potenciales porque era asociado con alguna actividad “mala” en el pasado. U otro podría ser aún más valioso porque pasó por las manos de una persona famosa. Con tal sistema, los participantes pueden comenzar a perder la confianza en los lingotes de oro. Es posible que tengan que verificar con una “lista buena / mala” centralizada para cada transacción para evitar recibir una “barra incorrecta”, y el sistema en general se vuelve menos eficiente. Debido al seguimiento, hemos perdido fungibilidad. Para obtener más información sobre esto, consulte el artículo vinculado anteriormente.

También hay muchas implicaciones de pérdida de privacidad al recibir o realizar un pago con un token que tiene un largo historial adjunto. Safe Network aspira a permitir transacciones privadas y seguras para todos los participantes de la red.

¿Cómo podemos determinar si una moneda es enlazable o desvinculable? En realidad, es bastante fácil, solo observamos las entradas y salidas de un par de transacciones.

Nota: En el caso de DBC, a menudo usamos las palabras transacción y reemisión enintercambiablemente

A continuación, se muestra un ejemplo simplificado de dos reediciones que utilizan nuestro sistema DBC actual. Podemos decir que Bob le pagó 50 a Alice (1ª reedición) y luego Alice le pagó los mismos 50 a Jim (2ª reedición). Entonces, cada reedición tiene solo un DBC de entrada y un DBC de salida. Cada DBC tiene una cantidad asociada, una clave pública del propietario pubkey y una firma de menta mintsig. En este ejemplo, pubkey, mintsig y hash se acortan a 3 dígitos para mayor brevedad. En realidad, son números únicos muy grandes.

reedición 1 (r1):
→ input = a {amount = 50, pubkey = 567, mintsig = 233}, hash (a) = 223
→ salida = b {cantidad = 50, clave de publicación = 725, mintsig = 112}, hash (b) = 787

reedición 2 (r2):
→ input = b {amount = 50, pubkey = 725, mintsig = 112}, hash (b) = 787
→ salida = c {cantidad = 50, clave de publicación = 212, mintsig = 455}, hash (c) = 993 

Nota: a, b y c son etiquetas para este ejemplo. No aparecen en una reedición. Los montos ahora están ocultos por compromisos, pero no son relevantes para este análisis.

Podemos ver fácilmente que la entrada b para r2 coincide con la salida b para r1. Podemos vincularlos mediante cualquiera de: pubkey == 725 o mintsig == 112, o hash == 787.

Esto establece que las reediciones r1 y r2 están vinculadas entre sí porque comparten un DBC común. A lo largo de una serie de reediciones, esto crea una cadena que se puede seguir.

Esto es lo que se entiende por vinculabilidad.

Además, si el monto es un valor único (o compromiso de valor), podría usarse para vincular transacciones.

Un punto importante a tener en cuenta es que incluso si eliminamos los campos pubkey y mintsig y solo usamos un campo de identificación aleatorio (para evitar el doble gasto), los DBC siguen siendo identificables por su valor hash. En otras palabras, si los mismos datos se utilizan como salida para una reedición y como entrada para otra, las reediciones se pueden vincular. Esto se puede generalizar a cualquier criptomoneda, sustituyendo la palabra transacción por reemisión.

Puede preguntar: ¿qué pasa si usamos múltiples entradas y salidas y cantidades variables para dividir y fusionar tokens? Bueno, estas técnicas pueden hacer que sea más difícil estar seguro del rastro de un token individual. Esa es la base de CoinJoin, CoinShuffle y algoritmos de mezcla similares. Hacen más enlaces posibles para seguir / evaluar. Pero en realidad no rompen ningún enlace … que se conservan indefinidamente para que cualquiera pueda analizar en su tiempo libre utilizando análisis estadísticos, datos de terceros (por ejemplo, intercambios), etc. Los criptógrafos generalmente consideran tales técnicas como “salsa débil”.

También puede preguntar: ¿Por qué tener un identificador único en el DBC? La respuesta es que se necesita un identificador para evitar el doble gasto. La casa de la moneda debe poder registrar una “moneda” como gastada, con el fin de detectar cualquier intento futuro de gastarla de nuevo.

Una vez que comprendamos la vinculabilidad, podemos empezar a pensar en formas de prevenirla.

Un sistema con la propiedad de desvinculabilidad no tendría tales enlaces. La gran pregunta es, ¿cómo lograr esa propiedad?

Firmas ciegas

La técnica más antigua conocida fue inventada por David Chaum y se conoce como Firmas ciegas. Tiene la ventaja de que es el esquema más simple de implementar, y al menos por ahora, el más eficiente, lo que lo hace muy adecuado para las operaciones de acuñación.

Repasemos el concepto básico de una firma ciega. El artículo de Chaum utiliza el ejemplo de una elección realizada de forma remota. Aquí presentamos una versión condensada, aunque también vale la pena leer la de Chaum.

Una firma ciega es como poner un “trozo” de papel con un mensaje (por ejemplo, un voto) dentro de un “sobre” forrado con carbón. Mary envía el “sobre” con la “hoja” adentro y una dirección de remitente al funcionario electoral Charles. Charles firma el “sobre” (que también firma el “resbalón” en el interior) y lo devuelve. En una fecha posterior, Mary quita la “papeleta” de voto y se la envía a Charles en un nuevo “sobre”, pero sin remitente. Charles abre el “sobre”, quita el “comprobante”, verifica que tenga una firma válida de Charles y cuenta el voto, sin saber quién emitió este voto en particular o cuándo fue firmado (entre el conjunto de sobres firmados).

El punto clave es que no existe un vínculo entre lo que está en cualquiera de los resguardos y lo que estaba escrito en cualquiera de los sobres. Por lo tanto, el funcionario electoral Charles desconoce el voto emitido por cada uno de los votantes. (excluyendo escritura forense, etc., etc. que no son relevantes para discusiones criptográficas).

Ok, vamos a realizar nuestras dos reediciones de nuevo, esta vez usando firmas ciegas. Ahora es la DBC Mint la que firma ciegamente los sobres. Para este ejemplo, asumimos que todos los DBC tienen el mismo valor.

reedición 1 (r1):
→ input = a.slip {pubkey = 567, mintsig = 233}, hash (a.slip) = 223
→ salida = b.envelope {ciego (b.slip)}, hash (b.envelope) = 565

reedición 2 (r2):
→ input = b.slip {pubkey = 445, mintsig = 112}, hash (b.slip) = 787
→ salida = c.envelope {ciego (c.slip)}, hash (c.envelope) = 993

En palabras:

  • Bob presenta la entrada A (deslizamiento) para acuñar (with mint sig válido sobre A) y obtiene la firma de mint sobre la salida B (sobre) con mint sig indicando que B vale lo mismo que A (slip).
  • Mint también marca A (deslizamiento) como gastado.
  • Bob saca B (nota) de B (sobre) y se lo da a Alice, quien presenta B (nota) a la casa de la moneda y obtiene la firma de la menta sobre C (sobre) que vale lo mismo que B (nota).
  • Mint también marca B (deslizamiento) como gastado.

Ahora, lo interesante aquí es que B (sobre) tiene un hash diferente de B (deslizamiento) dentro. 565! = 787

Por lo tanto, los hashes no coinciden entre tx1 y tx2 y tampoco los campos. Nada conecta estas dos transacciones juntas hasta donde la ceca puede ver. ¡Tenemos la desvinculación!

Circuitos de conocimiento cero

Un enfoque más moderno para las transacciones desvinculables es mediante el uso de circuitos de prueba de conocimiento cero (ZK) en ZCash.

Con las pruebas ZK, estamos intentando convencer a la Casa de la Moneda de algo sin revelar información confidencial. Los sistemas a prueba de circuitos ZK como PLONK han surgido en los últimos años como sistemas generales para las pruebas ZK de ingeniería.

Por ejemplo, digamos que implementamos un circuito ZK que simula sha3_256. Este circuito nos permitiría demostrarle a un tercero que conocemos los datos que se someten a hash sin revelar los datos en sí. ¡Incluso podemos probar propiedades sobre estos datos!

Digamos, por ejemplo, que los datos que estamos procesando son en realidad una transacción de reemisión completa.

let reissue = Reeditar {
   entradas: {Dbc {cantidad: 9, propietario: pk1, ..}, Dbc {cantidad: 1, propietario: pk2, ..},
   salidas: {Dbc {cantidad: 10, propietario: pk3, ..}
   pruebas_de_propiedad: {pk1_sig, pk2_sig}
};

Podría ejecutar esta reedición a través de sha3_256 para producir un hash:tx_hash = sha3_256 (reedición).
Para convencer a la menta de que se trata de un hash de una transacción válida, podemos generar una prueba ZK usando nuestro circuito sha3_256.

Un circuito ZK tiene entradas públicas y privadas, en este ejemplo, la información de reemisión serán entradas privadas y el tx_hash será una entrada pública.

privado: [9, pk1, 1, pk2, 10, pk3, pk1_sig, pk2_sig]
público: [tx_hash]

Podemos escribir restricciones en estas entradas privadas / públicas, estas restricciones se codifican en un circuito ZK que luego se puede ejecutar para producir pruebas de que estas restricciones se cumplen

/// Restricciones de reemisión
privado [0] + privado [2] = privado [4] // 9 + 1 = 10
private [1] .verify (privado [0..6], público [6]) // pk1 firmó la transacción
private [3] .verify (privado [0..6], público [7]) // pk2 firmó la transacción
public [0] = sha3_256 (privado) // volver a emitir hashes de datos a tx_hash

Nota: nos referimos a las entradas por su índice, los circuitos tienen un tamaño predeterminado, este tamaño limita la cantidad de DBC de entrada / salida que podemos reemitir dentro de una sola transacción de reemisión.

Ahora, una vez que codifiquemos estas restricciones como un circuito ZK, podemos insertar los detalles de la reemisión en las ranuras de entrada privadas y el tx_hash en la ranura de entrada pública del circuito. Luego giramos la manivela para producir una prueba de que se satisfacen todas las restricciones.

Es importante destacar que esta prueba no filtra ninguna información sobre las entradas privadas, podemos enviar esta prueba junto con el tx_hash a una Casa de la Moneda y estaría convencido de que este tx_hash es un hash de una transacción válida. La casa de la moneda podría firmar tx_hash para certificar la reedición.

Esto es muy bueno, pero la investigación en esta área aún es joven y las herramientas en torno a estos sistemas de circuitos ZK aún son bastante inmaduras. Las pruebas tienden a ser muy lentas de producir y verificar, especialmente para circuitos complicados como sha3_256.

Si desea profundizar esta serie es bastante buena.

Firmas de anillo

Las firmas de anillo, como se usan en Monero y otras criptomonedas, son un método para ocultar el historial de transacciones al esconderse en un grupo.

En una firma de anillo, Alice firma una transacción usando (1) la clave privada de Alice, (2) la clave pública de Alice y (3) las claves públicas de otras personas. Cualquiera puede verificar la firma de Alice utilizando el conjunto de claves públicas, pero (normalmente) no pueden determinar quién fue el verdadero firmante porque hay varias claves públicas equivalentes.

Como tal, las firmas de anillo son una forma de mezcla automática. Todavía existen enlaces, pero hay tantos que puede resultar demasiado difícil de analizar. En Monero en la actualidad hay 11 posibles firmantes: el real más otros 10. Así que esto es como esconderse en una multitud de 11 personas … mejor que estar solo, pero no es muy reconfortante si un sabueso está husmeando.

Importe oculto

La Ocultación de cantidades, también conocida como Transacciones confidenciales, también ayuda a mejorar la privacidad, pero no afecta la [des] vinculación.

Amount Hiding es compatible con circuitos zk y firmas de anillo, pero no con un enfoque de firma ciega, que generalmente requiere el uso de denominaciones fijas.

Hablamos sobre Ocultar cantidad a través de los compromisos de Pedersen en una actualización anterior.

Denominaciones fijas

Las denominaciones fijas son otra forma de protección de la privacidad, con un propósito similar al ocultamiento de cantidades. El sistema solo permite un cierto número limitado de cantidades. Para representar cualquier otra cantidad, se debe realizar un cambio utilizando las cantidades conocidas.

Obligar a todas las transacciones a utilizar estos importes fijos significa que todas las entradas y salidas de una transacción aparecen regulares. Si bien la cantidad total de una transacción dada es visible, no se puede rastrear una entrada o salida dada de manera efectiva por su cantidad porque se fusiona en un océano de otras fichas que valen la misma cantidad. Como tal, todas las unidades de una denominación dada son fungibles entre sí.

Por lo tanto, es importante mantener pequeño el número total de denominaciones. Por ejemplo, se podría definir cada valor entero con su propia denominación. Si bien esto funcionaría técnicamente, es malo para la privacidad, ya que las personas a menudo usan cantidades muy únicas. En lugar de fundirse en un océano, una sola gota deambula por sí misma.


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.