TL;DR
Una prueba de conocimiento cero permite a una parte (un verificador) determinar la validez de una declaración dada por otra parte (el probador) sin ningún conocimiento del contenido de la declaración. Por ejemplo, es posible que Binance quiera demostrar que ha respaldado completamente los fondos de sus usuarios en reservas sin revelar todos los saldos de los usuarios individuales.
Se podría construir una "Prueba de Reservas" con un árbol Merkle que proteja contra la falsificación de sus datos internos, en este caso, los saldos netos totales de sus clientes, siendo pasivos del intercambio hacia sus usuarios. Luego, esto se puede combinar con un zk-SNARK (un protocolo de prueba de conocimiento cero) que garantiza que los usuarios puedan verificar que su saldo forma parte del saldo neto total de activos del usuario sin conocer los saldos individuales.
Introducción
A la luz de los acontecimientos del mercado, la seguridad de los criptoactivos custodiados se ha convertido en un tema crítico. Los usuarios de Blockchain valoran mucho la transparencia y la apertura, pero también apoyan la privacidad y la confidencialidad. Esto crea un dilema a la hora de demostrar las reservas de fondos en poder de los custodios. A menudo existe un equilibrio entre transparencia, confianza y confidencialidad de los datos.
Sin embargo, este no tiene por qué ser el caso. Al combinar protocolos a prueba de conocimiento cero como zk-SNARK con árboles Merkle, podemos encontrar una solución eficaz para todas las partes.
¿Qué es la prueba de conocimiento cero?
Una prueba de conocimiento cero permite a una parte (un verificador) determinar la validez de una declaración dada por otra parte (el probador) sin ningún conocimiento del contenido de la declaración. Veamos un ejemplo sencillo.
Tienes una caja fuerte cerrada cuya solución sólo tú conoces. La caja fuerte, por el ejemplo, no se puede abrir, forzar ni abrir de ninguna otra forma que no sea conociendo la combinación. Este hecho también lo establece, verifica y conoce su amigo que participa en el experimento.
Le dices a tu amigo que conoces la combinación, pero que no quieres regalarla ni abrir la caja delante de él. Encima de la caja hay un agujero por el que tu amigo puede pasar una nota. Para que esto sea una prueba de conocimiento cero, tu amigo no debería tener ninguna información adicional sobre el proceso aparte de la declaración dada.
Puedes demostrarle a tu amigo que conoces la combinación abriendo la caja, diciéndole lo que estaba escrito en la nota y cerrándola nuevamente. Sin embargo, en ningún momento ha revelado la combinación.
Para ver un ejemplo más avanzado, consulte ¿Qué es la prueba de conocimiento cero y cómo afecta a Blockchain? artículo.
¿Por qué utilizamos la prueba de conocimiento cero?
Las pruebas de conocimiento cero son adecuadas para probar algo sin revelar información o detalles confidenciales. Este podría ser el caso si no desea entregar su información financiera o personal que podría usarse de manera inapropiada.
En criptografía, puede demostrar que posee una clave privada sin revelarla ni firmar nada digitalmente. Es posible que un intercambio de criptomonedas también desee demostrar el estado de sus reservas sin revelar información confidencial sobre sus usuarios, incluidos los saldos de sus cuentas individuales.
Para estos ejemplos (y muchos otros), una prueba de conocimiento cero utilizaría algoritmos que toman una entrada de datos y devuelven "verdadero" o "falso" como salida.
Definición de pruebas de conocimiento cero en términos técnicos
Una prueba de conocimiento cero, en términos técnicos, sigue una estructura específica con ciertos criterios. Ya hemos cubierto las funciones de probador y verificador, pero también hay tres criterios que debe cubrir una prueba de conocimiento cero:
Lo completo. Si la afirmación es verdadera, el verificador quedará convencido por la prueba proporcionada, sin necesidad de ninguna otra información o verificación.
Solvencia. Si la afirmación es falsa, el verificador no quedará convencido de la veracidad de la afirmación mediante la prueba proporcionada.
Conocimiento cero. Si la afirmación es verdadera, el verificador no obtiene ninguna información aparte de que la afirmación es verdadera.
¿Qué es un zk-SNARK?
Un zk-SNARK (Argumento de conocimiento no interactivo, sucinto y de conocimiento cero) es un protocolo de prueba que sigue los principios de conocimiento cero descritos anteriormente. Con un zk-SNARK, podrías demostrar que conoces el valor hash original (que se analiza más adelante) sin revelar cuál es. También puede probar la validez de una transacción sin revelar ninguna información sobre los montos, valores o direcciones específicos involucrados.
Los zk-SNARK se usan y discuten comúnmente dentro del mundo blockchain y las criptomonedas. Pero quizás se pregunte por qué alguien se molestaría en usar zk-SNARK cuando podría usar un método simple de par de claves públicas y privadas para proteger la información. Sin embargo, no podríamos implementar la prueba matemática para garantizar que no se incluyan saldos negativos ni la suma del árbol de Merkle.
En el caso de las reservas de una bolsa, queremos demostrar un respaldo 1:1 de los saldos de los clientes sin que se hagan públicos los identificadores y saldos de cada cuenta. Además, la tecnología zk-SNARK hace que la falsificación de datos sea aún más improbable.
¿Qué es un árbol Merkle?
Presentar los fondos sumados de las cuentas de los usuarios de Binance requiere trabajar con un gran conjunto de datos. Una forma de presentar criptográficamente esta gran cantidad de datos es utilizar un árbol Merkle. En él se puede almacenar de manera eficiente una gran cantidad de información y su naturaleza criptográfica hace que su integridad sea fácilmente verificable.
Funciones hash
Para codificar de manera sucinta una entrada, un árbol Merkle depende del uso de funciones hash. En resumen, el hashing es el proceso de generar una salida de tamaño fijo a partir de una entrada de tamaño variable. En otras palabras, cuando una entrada de cualquier longitud se procesa mediante un algoritmo, se producirá una salida cifrada de longitud fija.
Mientras la entrada siga siendo la misma, la salida también lo será. Esto significa que podemos tomar grandes cantidades de datos transaccionales y convertirlos en un resultado manejable. El resultado será radicalmente diferente si se cambia alguna información en la entrada.
Por ejemplo, podríamos tomar el contenido de 100 libros e ingresarlos en la función hash SHA-256. Luego proporcionaría algo como esto como resultado:
801a9be154c78caa032a37b4a4f0747f1e1addb397b64fa8581d749d704c12ea
Si luego cambiamos un solo carácter de la entrada (esos 100 libros), el hash sería completamente diferente, así:
abc5d230121d93a93a25bf7cf54ab71e8617114ccb57385a87ff12872bfda410
Esta es una propiedad importante de las funciones hash porque permite una fácil verificación de la precisión de los datos. Si alguien replica el proceso de hash de esos mismos 100 libros utilizando el algoritmo SHA-256, obtendrá exactamente el mismo hash que el resultado. Si la salida es diferente, podemos afirmar con certeza que la entrada fue cambiada. Esto significa que no es necesario comprobar de forma individual o manual las diferencias entre las entradas, lo que puede requerir mucha mano de obra.
Árboles Merkle en el mundo de las criptomonedas
Al almacenar datos de transacciones en una cadena de bloques, cada nueva transacción se envía a través de una función hash, que genera valores hash únicos. Imagine que tenemos ocho transacciones (A a H) que procesamos individualmente para obtener sus resultados hash. Estos son los que llamamos nodos de hoja de Merkle. En la imagen a continuación, puede ver el valor hash único de cada letra: hA para A, hB para B, hC para C, etc.
Luego podemos tomar pares de resultados hash, combinarlos y recibir un nuevo resultado hash. Los hash de hA y hB juntos, por ejemplo, nos darían una nueva salida hash de hAB conocida como rama Merkle. Tenga en cuenta que cada vez que se genera una nueva salida, ésta tiene una longitud y un tamaño fijos, según la función hash utilizada.
Ahora tenemos los datos de dos transacciones (por ejemplo, A y B) combinados en un hash (hAB). Tenga en cuenta que si cambiamos cualquier información de A o B y repetimos el proceso, nuestra salida hash hAB sería completamente diferente.
El proceso continúa a medida que combinamos nuevos pares de hashes para volver a aplicarlos (consulte la imagen a continuación). Combinamos hAB con hCD para obtener un hash hABCD único y hacemos lo mismo con hEF y hGH para obtener hEFGH. Al final, recibimos un único hash que representa los resultados hash de todos los hashes de transacciones anteriores. En otras palabras, la salida hash haBCDEFGH representa toda la información anterior.
El gráfico que se muestra arriba se llama árbol de Merkle y la salida hash hABCDEFGH es la raíz de Merkle. Usamos raíces de Merkle en los encabezados de los bloques, ya que resumen criptográficamente todos los datos de las transacciones en un bloque de manera sucinta. También podemos verificar rápidamente si algún dato ha sido manipulado o modificado dentro del bloque.
Las limitaciones de los árboles Merkle
Volvamos a nuestro ejemplo de reservas CEX. Un CEX quiere demostrar el respaldo 1:1 de todos los activos de sus clientes y construye un árbol Merkle que reúne los UID de sus clientes con sus tenencias de activos netos (compensando activos y pasivos) a nivel simbólico. Una vez liberado (y firmado para demostrar la propiedad de la raíz de Merkle proporcionada), un usuario individual no tendría forma de comprobar si el árbol de Merkle es válido sin acceder a todas sus entradas.
Es posible que un intercambio no haya incluido algunas entradas. También podría crear cuentas falsas con saldos negativos para alterar el pasivo total. Por ejemplo, aunque los activos de los clientes pueden sumar $1,000,000, se podría agregar una cuenta falsa con un saldo de -$500,000. Esto crearía un objetivo de reservas de sólo 500.000 dólares.
El caso de la prueba de reservas es diferente de la raíz Merkle de un bloque, ya que los usuarios pueden ver todas las transacciones que contiene un bloque en un explorador de blockchain. Sin embargo, un CEX no querrá revelar el saldo de cada cuenta por razones de seguridad y privacidad de los datos. Los clientes tampoco estarían contentos con que los saldos de sus cuentas se hicieran públicos. En este caso, el CEX no puede probar que los saldos de los usuarios suman el total correcto sin hacer visibles los saldos de otros usuarios.
Una solución que los intercambios pueden considerar emplear es utilizar un auditor externo confiable. El auditor puede comprobar las cuentas y reservas individuales antes de dar fe finalmente de la validez de la raíz Merkle proporcionada. Sin embargo, para los usuarios, este método requiere confianza en el auditor y en los datos utilizados para la auditoría. No tiene que depender de un tercero cuando puede confiar en los datos.
Combinando zk-SNARK con árboles Merkle
El problema anterior es un caso perfecto para usar zk-SNARK. Queremos demostrar que las reservas cubren totalmente las responsabilidades de los usuarios y no están falsificadas. Sin embargo, por razones de privacidad y seguridad, no queremos mostrarle al verificador la composición exacta de los saldos y reservas de los usuarios.
Al utilizar un zk-SNARK, un intercambio de cifrado puede demostrar que todos los conjuntos de saldos de los nodos de hoja del árbol de Merkle (es decir, los saldos de las cuentas de los usuarios) contribuyen al saldo total de activos del usuario reclamado por el intercambio. Cada usuario puede acceder fácilmente a su nodo hoja como si hubiera sido incluido en el proceso. zk-SNARK también garantiza que cualquier árbol Merkle generado no contenga usuarios con un saldo de activos neto total negativo (lo que implicaría falsificación de datos, ya que todos los préstamos están sobregarantizados). También se utiliza un cálculo del estado global de Binance, es decir, una lista del saldo neto total de cada activo que posee cada cliente de Binance.
Echemos un vistazo a cómo Binance aborda la situación. Para empezar, Binance define las restricciones del cálculo que desea probar y las define como un circuito programable. A continuación se muestra el conjunto de tres restricciones que utiliza Binance en su modelo.
Para el conjunto de equilibrio de cada usuario (nodo de hoja de árbol Merkle), nuestro circuito garantiza que:
Los saldos de activos de un usuario se incluyen en el cálculo de la suma del total de los saldos netos del usuario con Binance.
El saldo neto total del usuario es mayor o igual a cero.
El cambio de la raíz del árbol Merkle es válido (es decir, no utiliza información falsificada) después de actualizar la información de un usuario al hash del nodo hoja.
Luego, Binance puede generar una prueba zk-SNARK para la construcción del árbol Merkle de acuerdo con el circuito. Esto implica que el intercambio ejecute un cálculo pesado de los ID y saldos de los usuarios de hash mientras garantiza que la prueba supere las restricciones.
Un verificador examinará la prueba (y su código fuente abierto publicado públicamente) para estar convencido de que el cálculo se ejecuta respetando todas las restricciones. El cálculo de la verificación lleva un tiempo extremadamente corto en comparación con el tiempo de prueba.
En cada publicación de Prueba de Reservas, el intercambio publicará:
1. La prueba Merkle para cada usuario.
2. La prueba zk-SNARK y la entrada pública (un hash de la lista del saldo neto total de cada activo y la raíz de Merkle) del circuito para todos los usuarios.
Las partes interesadas pueden verificar la prueba de Merkle, asegurando que sus saldos individuales hayan contribuido a la raíz del árbol de Merkle. También pueden verificar la prueba zk-SNARK para garantizar que la construcción del árbol Merkle cumpla con las restricciones definidas en el circuito. Para obtener una explicación más detallada de la solución zk-SNARK y su rendimiento, consulte nuestro blog Cómo los zk-SNARK mejoran el sistema de prueba de reservas de Binance.
Pensamientos finales
Los zk-SNARK proporcionan la tecnología necesaria para garantizar la integridad y la privacidad de los datos al mismo tiempo. Su aplicación para demostrar reservas y aumentar la transparencia de CEX debería ayudar a generar confianza en la industria blockchain. Para muchos, un acontecimiento como este era algo que se esperaba desde hace mucho tiempo y llega en un momento crucial para los CEX.
Esta es la primera versión de nuestro zk-SNARK y esperamos recibir comentarios de la comunidad para poder continuar mejorando el sistema.
Otras lecturas
(Blog) Cómo los zk-SNARK mejoran el sistema de prueba de reservas de Binance
(Academia) Prueba de Reservas (PoR)
(Academia) ¿Qué es la prueba de reservas y cómo funciona en Binance?
