Cómo las zk-SNARK mejoran el sistema de prueba de reservas de Binance
Lo más destacado
En noviembre de 2022, Binance publicó su sistema de prueba de reservas que utiliza la técnica criptográfica del árbol de Merkle para que los usuarios puedan verificar los activos bajo reserva.
Ahora, Binance ha mejorado su solución con la integración de zk-SNARK, un tipo de pruebas de conocimiento cero.
A partir de ahora, los usuarios podrán verificar que el saldo total neto de cada cuenta no sea negativo y que todos los activos de los usuarios formen parte del saldo total neto de activos de usuarios declarado por Binance, todo ello de forma privada y segura.
Echa un vistazo a los entresijos de la nueva solución de prueba de reservas de Binance que, mediante la combinación de zk-SNARK y la información del árbol de Merkle, ofrece a los usuarios una forma nueva y mejorada de verificar el estado de las reservas de Binance.
Durante los últimos meses, el equipo de desarrolladores de Binance ha estado trabajando intensamente para crear soluciones avanzadas de prueba de solvencia. Estas herramientas se han convertido en una pieza fundamental de los exchanges de criptomonedas centralizados debido a la crisis de confianza en la que se ha sumido el sector tras la caída de FTX. Los fondos de los usuarios almacenados en Binance están respaldados en una proporción de 1:1, más las reservas, y encontrar la forma de demostrar al público que este dato es cierto de manera transparente ha pasado a ser una parte fundamental del plan de Binance para restablecer la confianza en el sector.
En noviembre de 2022, lanzamos nuestro sistema de prueba de reservas que utiliza la técnica criptográfica del árbol de Merkle para que los usuarios puedan verificar los activos que poseen en Binance. El diseño inicial de esta solución, si bien supuso un avance en la labor de Binance de ofrecer transparencia en los fondos de los usuarios, presentaba dos defectos:
Para proteger la privacidad del usuario, los nodos hoja de la prueba de Merkle representaban el hash de las posesiones de los usuarios y, por lo tanto, la raíz de Merkle era incapaz de reflejar la suma de la información de los saldos de sus nodos hoja.
La entidad cuyas reservas se estuvieran verificando podía añadir un saldo negativo con una cuenta falsa en alguna parte del árbol para que las reservas totales obligatorias parecieran más pequeñas. El siguiente diagrama extraído del blog de Vitalik Buterin muestra un ejemplo de este tipo de árboles de Merkle malintencionados (aunque, en este caso, la raíz refleja la suma de todos los saldos de los nodos hoja, lo que puede ocasionar problemas de privacidad).
Ahora contamos con una solución que puede subsanar estos defectos y así reforzar el sistema de prueba de reservas de Binance. Al basarnos en protocolos de pruebas de cero conocimiento, las zk-SNARK, podemos demostrar que:
Todos los nodos hoja del árbol de Merkle han contribuido al saldo total de los usuarios que Binance afirma disponer de cada activo.
No hay ningún usuario que tenga un saldo total neto negativo (el valor total en USD de todos los activos de los que es titular el usuario) incluido en el árbol de Merkle.
Un breve apunte sobre los saldos y los resultados negativos
Dado que Binance ofrece productos de trading de márgenes, de préstamos de criptomonedas y de futuros, el saldo que un usuario tenga de cada criptoactivo puede estar compuesto por activos y pasivos. El saldo de un usuario de un criptoactivo en particular puede ser negativo, pero el saldo total neto de todos los activos de criptomonedas no debería serlo (ya que todo los préstamos están totalmente cubiertos por la garantía).
En esta situación hipotética, pongamos por caso que Alicia deposita 10 000 BUSD en Binance para a continuación utilizar 4000 BUSD como garantía para tomar prestados 2 BNB (a un tipo de 1 BNB = 1000 BUSD, si suponemos que Binance siempre presta garantías al alza). En la siguiente tabla vemos el estado de cuentas de Alicia.
Si Alicia ofrece a Bob (que también había depositado 10 000 BUSD) 1 BNB a cambio de 1000 BUSD, su estado de cuentas una vez completada la operación sería el siguiente:
En este caso, el saldo de BNB de Alicia sería de -1, que no es un nodo válido en un árbol de Merkle y que solo da cuenta de un activo: BNB. No obstante, si tenemos en cuenta los saldos totales netos, Alicia sigue teniendo 10 000 BUSD.
Otra de las dificultades radica en la magnitud de la base de usuarios de Binance. Una solución viable debe generar pruebas de usuario y pruebas zk-SNARK para decenas de millones de usuarios, y algunos de ellos pueden tener más de 300 criptoactivos en nuestra plataforma.
En definitiva, nuestro objetivo es demostrar los siguientes hechos en un período de tiempo razonable:
Que los activos de cada usuario de Binance forman parte de nuestro saldo de usuarios total declarado como se indica en la instantánea. Los usuarios pueden verificar nuestro saldo de usuarios total declarado y compararlo con los activos almacenados en las direcciones controladas por Binance utilizando un explorador de blockchain (como Etherscan para billeteras de Ethereum o BscScan para billeteras de BNB Chain).
Que el saldo total neto de cada usuario no sea negativo, lo que demostraría que Binance no ha creado cuentas falsas con saldo negativo para reducir el tamaño de nuestras reservas verificadas de forma artificial.
¿Qué es zk-SNARK?
Antes de que pasemos a comentar nuestra solución en detalle, hagamos un breve resumen del mecanismo de prueba de conocimiento cero. Los protocolos de conocimiento cero como zk-SNARK permiten que una parte, el demostrador, demuestre a otra parte, el verificador, que ha ejecutado correctamente una serie de cálculos basándose en determinadas entradas y respetando ciertas restricciones, todo ello sin dar a conocer cuáles son esas entradas. Efectuar los cálculos puede llevar mucho tiempo, pero gracias al mecanismo matemático subyacente, el verificador puede evaluar la prueba de forma rápida y segura.
El demostrador (Binance) empieza definiendo un conjunto de restricciones para el cálculo que quiere verificar. Las restricciones se definen en circuitos que pueden expresarse en un lenguaje de programación de alto nivel (en nuestro caso, una versión bifurcada de gnark).
A continuación, el demostrador ejecuta el grueso de los cálculos, aplicando la función de hash a los id. y a los estados de cuentas de todos los usuarios, y genera pruebas de que los cálculos respetan las restricciones que se hayan establecido. Para ello, utiliza el rastro del cálculo (testigo) y las entradas públicas o privadas.
El verificador (usuario) obtiene las pruebas y las verifica cotejándolas con las entradas públicas del circuito para asegurarse de que los cálculos se han ejecutado correctamente y que han respetado todas las restricciones. El cálculo de verificación se efectúa en poquísimo tiempo en comparación con lo que se tarda en obtener las pruebas. Si el demostrador no genera las pruebas en los circuitos predefinidos, no podrá facilitar pruebas válidas para superar el proceso de verificación.
Si te gustaría analizar más a fondo los entresijos de zk-SNARK, puedes consultar esta serie de artículos.
Nuestra solución
El pilar fundamental sobre el que se asienta la solución de prueba de reservas mejorada es también un árbol de Merkle. Si utilizamos el ejemplo anterior, quedaría de la siguiente manera:
Además del árbol de Merkle, mantenemos un estado global que consiste en una lista de los saldos totales netos de cada activo que posee cada cliente de Binance.
Para demostrar la veracidad de nuestras reservas, generaremos una prueba zk-SNARK de la construcción del árbol de Merkle. En cada conjunto de saldos de un usuario, un nodo hoja del árbol de Merkle, nuestro circuito se asegurará de que:
El saldo de cada activo de este usuario esté incluido en la lista de estado global que ya mencionamos.
El saldo total neto del usuario no sea negativo.
El cambio de la raíz del árbol de Merkle sea válido después de actualizar la información de este usuario en el hash del nodo hoja.
Puedes consultar estas especificaciones técnicas y nuestro código fuente del circuito (restricciones) para obtener más información sobre su aplicación.
En cada instancia de prueba de nuestras reservas, publicaremos:
1. La prueba de Merkle: los hashes de cada usuario (en el caso de Alicia, aparecen representados por los nodos azules de la imagen anterior).
2. Las pruebas zk-SNARK y las entradas públicas (un hash de la lista de los saldos totales netos de cada activo y la raíz de Merkle) del circuito de todos los usuarios.
Al verificar la prueba de Merkle, los usuarios pueden asegurarse de que su estado de cuentas está incluido en la raíz del árbol de Merkle. Al verificar la prueba zk-SNARK, los usuarios pueden asegurarse de que la construcción del árbol de Merkle respeta las restricciones que aparecen definidas en el circuito.
La seguridad de esta solución depende en gran medida de la configuración de la clave de prueba y la clave de verificación. Actualmente estamos trabajando en el desarrollo de una configuración de claves descentralizada. De todas las ceremonias de configuración descentralizadas de confianza disponibles hoy en día, la de Ethereum es un magnífico ejemplo de lo que buscamos. Estamos muy cerca de disponer de una solución MPC que nos permita ofrecer una configuración descentralizada.
Rendimiento
El número de usuarios de Binance con saldos que deben incluirse en el cómputo total es enorme y, por lo tanto, no hay forma de obtener una única prueba de la construcción del árbol de Merkle que dé cuenta de todos los usuarios al mismo tiempo. Una forma de solucionar esta cuestión es dividir a los usuarios en grupos de 864, para así tener un circuito de menor escala y procedimientos de prueba paralelos.
Pongamos por caso que, en un grupo de 864 usuarios, cada uno de ellos posee 350 activos diferentes y que el saldo de cada activo se encuentra dentro de un rango de [0, 2^64-1]. Con un servidor de 32 núcleos y 128 GB, el tiempo de generación de la prueba de zk es de unos 110 segundos y la verificación de la prueba, de menos de 1 milisegundo.
Binance activará 1000 demostradores al mismo tiempo para así conseguir generar pruebas de todas las cuentas en un plazo de 2 horas. El coste de utilizar este servidor de demostradores durante una hora es de aproximadamente 0,56 USD, de forma que el coste total que conlleva generar todas las pruebas de zk que den cuenta de todos los usuarios ascendería a unos 1000 USD.
Conclusión
Ofreceremos la primera iteración de pruebas para usuarios generada por esta nueva solución en un anuncio de prueba de reservas que publicaremos próximamente. Además, hemos abierto el código de nuestro procesador de datos de usuarios, el demostrador, el circuito y el verificador para que todos los exchanges centralizados que estén basados en el mismo modelo que nosotros puedan generar pruebas para sus usuarios y activos de forma sencilla.
Esperamos que esta sea una pieza fundamental a la hora de mejorar la transparencia en el sector de los activos digitales. Asimismo, estamos trabajando para implementar la solución que menciona el blog de Vitalik a fin de obtener un mejor rendimiento, lo que nos permitirá ofrecer pruebas con mayor frecuencia y por un coste menor.
Como esta es la primera versión de nuestra zk-SNARK, nos encantaría leer las opiniones de la comunidad al respecto para poder seguir mejorando el sistema.
Código y otras publicaciones relacionadas
Binance Academy: Mejoramos la transparencia de las criptomonedas con la prueba de conocimiento cero
El blog de Vitalik: Cómo ofrecer un CEX seguro: la prueba de solvencia y mucho más
Advertencia de riesgo: la inversión en criptoactivos no está regulada, puede no ser adecuada para inversores minoristas y perderse la totalidad del importe invertido. Es importante leer y comprender los riesgos de esta inversión que se explican detalladamente en esta ubicación.