Actualización de Safe Network Dev 🇪🇸 29 de julio de 2021

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

Esta semana analizaremos en profundidad los DBC, que tienen el potencial de revolucionar los pagos en línea y simplificar muchos aspectos de la economía de la red segura. Realmente son ese gran negocio, pero en su forma estándar tienen algunos inconvenientes cuando se trata de transacciones privadas.

Un problema es que una casa de moneda puede ver las transacciones que pasan a través de ella y podría, en caso de compromiso, publicar esas transacciones. Esta semana veremos una forma de ocultar transacciones de una casa de la moneda (compromisos de Pedersen) y también una forma de evitar que los malos actores jueguen con los compromisos de Pedersen (pruebas de rango).

Progreso general

@danda y David Rusu están liderando el diseño de transacciones confidenciales y adaptando DBC para hacer cumplir las claves de un solo uso. @danda lo analiza con más detalle en esta publicación.

En el lado del cliente, @yogesh ha estado trabajando duro en el código para hacer posible que los clientes hablen directamente con las secciones donde residen los fragmentos, lo cual es mucho más eficiente que enrutar todo a través de una sección.

Enrutamiento: @lionel.faber se ha puesto en contacto con el equipo de quinn, que ha ofrecido algunas sugerencias sobre las causas de algunos de los problemas de tiempo de espera / restablecimiento que los usuarios de testnet habrán experimentado. También estamos trasladando aspectos de la funcionalidad de enrutamiento a qp2p para reducir la complejidad.

La gran racionalización de la mensajería continúa a buen ritmo, con una selección despiadada de los tipos de mensajería poco utilizados, lo que reducirá los errores y dará como resultado un código más limpio. Como se mencionó en la actualización de la semana pasada, la mensajería debe mantenerse al mínimo para lograr la eficiencia, y lo mismo se aplica al contenido de los mensajes. El uso de CRDT y el hecho de que los clientes agreguen firmas nos permite eliminar gran parte del problema y reducir el trabajo de burro que realiza la red.

Uno de los MaidSafers más nuevos que está a la altura de sus ojos en la refactorización de mensajes es @ Chris.Connelly. Aquí hay una introducción de Chris:

Soy un ingeniero de software con sede en Edimburgo con experiencia en el desarrollo de back-end de servicios web y automatización de infraestructura en la nube, pero ahora estoy buscando ampliar mis horizontes en sistemas distribuidos y descentralizados. Soy un apasionado de la ingeniería holística (considerando todo el sistema y evitando roles especializados) y escribiendo software confiable usando Rust (y algunas veces Elm en el lateral), ¡y estoy emocionado de hacerlo aquí en MaidSafe!

Compromisos de Pedersen y pruebas de rango

Los compromisos de Pedersen son una forma de prueba de conocimiento cero diseñada para ocultar los valores en las transacciones. Permiten al receptor verificar que la suma de todos los números ingresados ​​en el compromiso es igual a la suma de todos los números emitidos en la transacción, sin revelar los números en sí.

Entonces, si tengo 30 tokens, le pago 20 y alguien más 10, esta transacción puede ser verificada por un tercero (¿los valores de entrada y salida suman, “verdadero” o “falso”?) Sin que ellos conozcan los valores involucrados.

Para que los DBC se gasten, deben estar autorizados por una ceca. Los compromisos de Pedersen hacen posible que Mint verifique que los valores de entrada y salida del DBC se sumen (es decir, que sea válido) y firme la transacción sin tener conocimiento de las cantidades negociadas.

Una debilidad de los compromisos de Pedersen cuando se utilizan para validar transacciones es que pueden ser engañados por números negativos. Una transacción con una entrada de 20 y salidas de 30 y -10 sería válida, pero dado que el “dinero negativo” no puede existir como token, efectivamente el pagador ha convertido 20 tokens en 30 tokens. ¡Magia! (Pero no para la economía).

Las pruebas de rango hacen que sea criptográficamente imposible que un valor de salida esté fuera de un cierto rango, digamos 0-2 ^ 32. Hacemos cumplir esto diciendo que una transacción solo es válida si cada salida también contiene una prueba de rango.

Entonces, si tengo un DBC por 30 tokens y quiero pagar a Alice 20 y Bob 10, el proceso es el siguiente:

Envío mi DBC a la menta junto con un compromiso de Pedersen con la entrada (encriptada) como 30 y las salidas (encriptadas) como 20 + una prueba de rango y 10 + una prueba de rango. La menta comprueba que los valores de entrada y salida se suman y que cada salida tiene una prueba de rango válida, firma la transacción y vuelve a emitir los DBC a las claves públicas (ofuscadas) de Alice y Bob.

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.