Vitalik: ¿Cómo pueden los intercambios centralizados demostrar sus fondos?

Cada vez que colapsa un importante intercambio centralizado, surge una pregunta común: ¿podemos utilizar tecnología criptográfica para resolver el problema? Los intercambios podrían crear pruebas criptográficas que demuestren que los fondos que mantienen en la cadena son suficientes para cubrir sus responsabilidades con los usuarios, en lugar de simplemente depender de métodos "legales" como permisos gubernamentales, revisiones de auditores y verificación de los antecedentes personales de quienes administran y operan el intercambio. Los intercambios podrían establecer un sistema en el que sea fundamentalmente imposible retirar los fondos de los depositantes sin su consentimiento. Potencialmente, podríamos explorar todo el espectro entre CEX ambiciosos y de buen corazón que "no hacen cosas malas" y DEX en cadena que "no pueden hacer cosas malas" pero que actualmente son ineficientes y filtran privacidad. Este artículo profundizará en los intentos históricos de hacer que las transacciones sean casi sin confianza, las limitaciones de estas tecnologías y algunas ideas más nuevas y poderosas que utilizan ZK-SNARK y otras tecnologías avanzadas.

Balances y árboles Merkle: prueba de solvencia a la antigua usanza

Los primeros intentos de los intercambios de utilizar métodos criptográficos para demostrar que no estaban defraudando a sus usuarios se remontan a mucho tiempo atrás. En 2011, el mayor intercambio de Bitcoin en ese momento, MtGox, demostró que tenía fondos transfiriendo 424242 BTC a una dirección previamente anunciada. En 2013, comenzaron las discusiones sobre cómo demostrar el otro lado de la ecuación: el tamaño total de los depósitos de los clientes. Si demuestra que los depósitos de los clientes son iguales a X (una "prueba de responsabilidad") y demuestra la propiedad de las claves privadas de X monedas (una "prueba de activos"), tiene prueba de solvencia: ha demostrado que el intercambio tiene los fondos para pagar todo. depositantes.

El método más sencillo para comprobar los depósitos era publicar una lista de pares (nombre de usuario, saldo). Cada usuario podría verificar si su saldo estaba incluido y cualquiera podría verificar la lista completa para asegurarse de (i) que cada saldo no sea negativo y (ii) que el total sea igual al monto reclamado. Sin embargo, esto viola la privacidad, por lo que se podría hacer una pequeña modificación: publicar una lista de pares (hash(nombre de usuario, sal), saldo) y enviar de forma privada a cada usuario su valor de sal. Pero incluso esto filtra información sobre el equilibrio y patrones de cambios de equilibrio. El deseo de proteger la privacidad nos lleva al siguiente invento: la tecnología del árbol Merkle (también conocido como árbol hash).

Verde: nodo Charlie. Azul: nodo de David, que también es el nodo que recibirá Charlie como parte de su prueba. Amarillo: nodo raíz, mostrado públicamente a todos.

La tecnología del árbol Merkle implica colocar el balance de un cliente en un árbol de suma Merkle. En este árbol, cada nodo es un par (equilibrio, hash). Los nodos de hoja de la capa inferior representan los saldos de los clientes individuales y los valores hash salados de sus nombres de usuario. En cada nodo de nivel superior, el saldo es la suma de los dos saldos siguientes y el valor hash es el hash de los dos nodos siguientes. Una prueba de suma de Merkle, como una prueba de Merkle, es una "rama" del árbol, compuesta de nodos hermanos en el camino desde la hoja hasta la raíz.

Los intercambios envían a cada usuario una suma Merkle como prueba de su saldo para demostrar sus tenencias. Los usuarios tienen entonces la seguridad de que su saldo se incluye correctamente como parte del total. Puede encontrar un ejemplo de código simple aquí.

La fuga de privacidad en este diseño es mucho menor que en una lista totalmente pública y se puede reducir aún más mezclando ramas cada vez que se publica la raíz. Sin embargo, todavía existen algunas filtraciones de privacidad. Charlie puede saber que alguien tiene un saldo de 164 ETH, que la suma de los saldos de dos usuarios es 70 ETH, etc. Un atacante que controle muchas cuentas aún puede aprender mucho sobre los usuarios del intercambio.

Un aspecto sutil pero importante de este esquema es la posibilidad de saldos negativos: ¿Qué pasa si un intercambio con un saldo de cliente de 1390 ETH solo tiene 890 ETH en reservas e intenta cubrir el déficit agregando un saldo de -500 ETH en una cuenta ficticia en ¿el árbol? Resulta que esta posibilidad no rompe el esquema, aunque es precisamente por eso que necesitamos árboles de suma Merkle en lugar de árboles Merkle normales. Supongamos que Henry es una cuenta ficticia controlada por el intercambio, donde se colocan -500 ETH.

La verificación de prueba de Greta fallará: el intercambio tendrá que ofrecerle el nodo -500 ETH de Henry, que ella rechazará porque no es válido. La verificación de Eve y Fred también fallará ya que el ETH total en los nodos intermedios encima de Henry es -230, ¡lo que también los invalida! Para evitar el robo, el intercambio tendrá que esperar que nadie en la mitad derecha de todo el árbol verifique su comprobante de saldo.

Si el intercambio puede identificar usuarios con un valor de 500ETH y creen que estos usuarios no se molestarán en verificar las pruebas o no serán creídos cuando se quejan de nunca recibir una prueba, entonces el intercambio puede escapar con confianza del castigo por robo. Sin embargo, el intercambio también podría lograr el mismo efecto excluyendo a estos usuarios del árbol.

Por lo tanto, con el único propósito de demostrar prueba de responsabilidades, la tecnología del árbol Merkle es esencialmente tan buena como el esquema de prueba de responsabilidades. Pero sus atributos de privacidad aún no son los ideales. Puedes usar los árboles Merkle de manera más inteligente, por ejemplo, haciendo de cada satoshi o wei una hoja individual, pero en última instancia, con técnicas más modernas, hay mejores maneras de lograrlo.

Mejora de la privacidad y la solidez con ZK-SNARK

Los ZK-SNARK son una tecnología poderosa, potencialmente para la criptografía lo que los transformadores son para la inteligencia artificial: una tecnología universalmente potente que supera por completo una gran cantidad de problemas en tecnologías específicas desarrolladas hace décadas. Naturalmente, podemos utilizar ZK-SNARK para simplificar y mejorar enormemente la privacidad en los protocolos de prueba de responsabilidad.

Lo más simple que podemos hacer es colocar todos los depósitos de los usuarios en un árbol Merkle (o más simplemente, un compromiso KZG) y usar un ZK-SNARK para demostrar que todos los saldos en el árbol no son negativos y en conjunto suman un valor reclamado. . Agregar una capa de hash para mayor privacidad y darle a cada usuario una sucursal de Merkle (o prueba de KZG) no revelará los saldos de otros usuarios.

Utilizar los compromisos de KZG es un método para evitar filtraciones de privacidad, ya que elimina la necesidad de proporcionar "nodos hermanos" como prueba. Se puede utilizar un ZK-SNARK simple para demostrar la suma de los saldos y que cada saldo no es negativo. Podemos utilizar un ZK-SNARK especializado para demostrar la suma y la no negatividad de los saldos en el mencionado KZG. Aquí hay un ejemplo simple que logra esto. Introducimos un polinomio auxiliar, que "establece los bits de cada saldo" (para fines ilustrativos, supongamos que los saldos están dentro de ), y cada 16 posiciones rastrea un total acumulado con un desplazamiento, por lo que la suma es cero solo cuando el total real es consistente con el total declarado. Si z es la raíz unidad -128, podemos probar la siguiente ecuación.

El primer valor en una configuración efectiva es 0 0 0 0 0 0 0 0 0 0 1 2 5 10 20 -165 0 0 0 0 0 0 0 0 0 1 3 6 12 25 50 -300… Para entender cómo se pueden transformar tales ecuaciones en comprobaciones polinómicas y luego en ZK-SNARK, consulte mi artículo sobre ZK-SNARK para obtener más explicaciones aquí y aquí . Si bien no es un protocolo óptimo, demuestra que las pruebas criptográficas de este tipo no son tan misteriosas hoy en día.

Con sólo unas pocas fórmulas adicionales, estos sistemas de restricciones pueden adaptarse a escenarios más complejos. Por ejemplo, en un sistema de negociación apalancado, es aceptable que los usuarios individuales tengan saldos negativos, siempre que tengan otros activos suficientes para cubrir los fondos con alguna garantía. Se puede utilizar un SNARK para demostrar esta restricción más compleja, asegurando a los usuarios que el intercambio no arriesgará sus fondos al eximir secretamente a otros usuarios de las reglas.

A largo plazo, este tipo de prueba de deuda ZK podría utilizarse no sólo para los depósitos de los clientes en las bolsas, sino también para una gama más amplia de préstamos. Cada vez que alguien toma un préstamo, coloca un registro en un polinomio o árbol que contiene ese préstamo, y la raíz de esta estructura se publica en la cadena. Esto permitiría a cualquiera que solicite un préstamo presentar a ZK pruebas a los prestamistas de que no ha pedido demasiado prestado de otros préstamos. En última instancia, las innovaciones legales podrían incluso hacer que los préstamos comprometidos de esta manera tengan mayor prioridad que los préstamos no comprometidos. Esto nos lleva en la misma dirección que una idea discutida en “Sociedad descentralizada: encontrar el alma de Web3”: establecer un concepto de reputación negativa o garantía en la cadena a través de alguna forma de “token vinculado al alma”.

Prueba de activos

La versión más simple de prueba de activos es el protocolo que hemos visto anteriormente: para demostrar que tiene X cantidad de monedas, solo necesita mover X monedas en un momento previamente acordado o en una transacción que incluya el mensaje "Estos fondos pertenecen a Binance” en su campo de datos. Para evitar tarifas de transacción, también puede firmar un mensaje fuera de la cadena; Tanto Bitcoin como Ethereum tienen estándares para mensajes de firma fuera de la cadena.

Esta sencilla técnica de prueba de activos tiene dos problemas prácticos:

1. Procesamiento de “almacenamiento en frío”.

2. Doble uso de garantías.

Por razones de seguridad, la mayoría de las bolsas mantienen la mayoría de los fondos de sus clientes en un “almacenamiento en frío”: en computadoras fuera de línea donde las transacciones deben firmarse manualmente y transferirse a Internet. La configuración de almacenamiento en frío que alguna vez usé para fondos personales involucraba una computadora permanentemente fuera de línea, que generaba un código QR que contenía la transacción firmada, que podía escanear con mi teléfono. Los protocolos de intercambio modernos son más complejos y a menudo implican cálculos de varias partes entre varios dispositivos. Dadas estas configuraciones, ¡incluso un mensaje adicional para demostrar el control sobre una dirección es una operación costosa!

Una transacción puede tomar varios caminos:

• Mantenga algunas direcciones a largo plazo conocidas públicamente. El intercambio genera varias direcciones, publica prueba de propiedad de cada una una vez y luego reutiliza estas direcciones. Este es, con diferencia, el esquema más simple, aunque añade algunas restricciones sobre cómo proteger la seguridad y la privacidad.

• Configure muchas direcciones, probando algunas al azar. El intercambio podría tener muchas direcciones, tal vez usando cada una solo una vez y retirándolas después de una transacción. En este caso, el intercambio podría tener un protocolo para seleccionar aleatoriamente algunas direcciones que deben "abrirse" para demostrar la propiedad. Algunas bolsas ya han hecho algo similar con los auditores, pero en principio esta técnica podría convertirse en un proceso totalmente automatizado.

• Opciones ZKP más complejas. Por ejemplo, un intercambio podría configurar todas sus direcciones como 1/2 firmas múltiples, donde la clave de cada dirección es diferente y la otra es una versión ciega de alguna clave de respaldo de emergencia "importante", almacenada de una manera compleja pero altamente segura. como una firma múltiple 12/16. Para proteger la privacidad y evitar exponer todo su conjunto de direcciones, un intercambio podría incluso ejecutar una prueba de conocimiento cero en la cadena de bloques, demostrando el saldo total de todas las direcciones con este formato en la cadena.

Otra cuestión importante es evitar el doble uso de garantías. Los intercambios podrían fácilmente intercambiar garantías entre sí como prueba de reserva, pretendiendo ser solventes cuando no lo son. Idealmente, la prueba de solvencia sería en tiempo real y se actualizaría después de cada bloque. Si esto no es práctico, una opción menos ideal es coordinar un horario fijo entre diferentes intercambios, por ejemplo, demostrando reservas todos los martes a las 14:00 UTC.

La última pregunta es: ¿podemos hacer pruebas de activos en moneda fiduciaria? Los intercambios no solo contienen criptomonedas; también poseen monedas fiduciarias dentro del sistema bancario. En este caso, la respuesta es: sí, pero dicho proceso dependerá inevitablemente del modelo fiduciario "fiat": el propio banco puede probar los saldos, los auditores pueden probar los balances, etc. Teniendo en cuenta que el fiat no puede verificarse criptográficamente, esto es lo mejor que Se puede hacer dentro de ese marco, pero aún así vale la pena hacerlo.

Otro enfoque es separar claramente una entidad que gestiona el intercambio y trata con monedas estables respaldadas por activos como el USDC de otra entidad que maneja el proceso de entrada y salida de efectivo entre las criptomonedas y el sistema bancario tradicional (el propio USDC). Dado que los "pasivos" del USDC son solo tokens ERC20 en cadena, la prueba de responsabilidad es "gratuita" y solo requiere prueba de activos.

Plasma y Validiums: ¿Podemos liberar los CEX?

Supongamos que queremos ir más allá: no solo queremos demostrar que el intercambio tiene los fondos para reembolsar el dinero de los usuarios. En cambio, queremos evitar por completo que el intercambio robe los fondos de los usuarios.

El primer gran intento en este sentido fue Plasma, una solución de extensión popular en la comunidad de investigación de Ethereum en 2017 y 2018. Plasma funciona dividiendo el saldo en un conjunto de “monedas” individuales, a cada una de las cuales se le asigna un índice y se ubica en una posición específica en el árbol Merkle de un bloque de Plasma. Una transferencia válida de una moneda requiere colocar la transacción en la posición correcta en el árbol, con la raíz del árbol publicada en la cadena.

Un esquema simplificado de una versión de Plasma. Las monedas se almacenan en un contrato inteligente y las reglas del protocolo Plasma se ejecutan por la fuerza durante el retiro.

OmiseGo intentó construir un intercambio descentralizado sobre este protocolo, pero desde entonces, han cambiado hacia otras ideas. En este sentido, el propio grupo Plasma también ha evolucionado, convirtiéndose ahora en el proyecto Optimism, centrado en rollups optimistas de EVM.

No vale la pena considerar las limitaciones tecnológicas de Plasma, tal como se concibió en 2018 (como demostrar la fragmentación de las monedas). Desde el pico del discurso de Plasma en 2018, los ZK-SNARK se han vuelto más viables en casos de uso relacionados con la expansión. Como se mencionó anteriormente, los ZK-SNARK lo han cambiado todo.

Una versión más moderna del concepto Plasma es lo que Starkware llama validium: esencialmente lo mismo que ZK-rollup, excepto que los datos se almacenan fuera de la cadena. Esta estructura se puede utilizar para muchos casos de uso, particularmente cuando un servidor centralizado necesita ejecutar algún código y demostrar su ejecución correcta. En un validium, los operadores no pueden robar fondos, aunque dependiendo de los detalles de la implementación, algunos fondos de los usuarios podrían quedarse bloqueados si el operador desaparece.

Todo esto es muy prometedor: la relación entre CEX y DEX está lejos de ser una oposición binaria. De hecho, existe todo un espectro de opciones, incluidas varias formas de centralización híbrida, donde puede disfrutar de beneficios como la eficiencia y al mismo tiempo contar con numerosas salvaguardas criptográficas para evitar que los operadores centralizados cometan la mayoría de las formas de abuso.

Sin embargo, en la mitad derecha de este espacio de diseño, es necesario discutir una cuestión fundamental: el manejo de los errores del usuario. Hasta ahora, el tipo de error más crítico es: ¿Qué se debe hacer si los usuarios olvidan sus contraseñas, pierden sus dispositivos, son pirateados o pierden el acceso a sus cuentas?

Los intercambios pueden abordar este problema: primero mediante la recuperación del correo electrónico y, si eso falla, mediante formas más complejas de recuperación a través de KYC. Sin embargo, para poder resolver estos problemas, los intercambios deben tener un control real sobre las monedas. Para tener la capacidad de restaurar legítimamente el acceso a las cuentas de los usuarios, los intercambios deben tener el poder que también podría usarse indebidamente para robar fondos de esas cuentas. Esta es una compensación inevitable.

La solución ideal a largo plazo se basa en la autocustodia, complementada con tecnologías como billeteras de recuperación social y de firma múltiple, para ayudar a los usuarios a manejar emergencias. Pero a corto plazo, existen dos soluciones alternativas aparentes, cada una con costos y beneficios claramente diferentes.

Conclusión: mejores intercambios en el futuro

A corto plazo, existen dos categorías distintas de intercambios: con custodia y sin custodia. Hoy en día, este último está representado por DEX como Uniswap. En el futuro, también podríamos ver CEX criptográficamente "restringidos", donde los fondos de los usuarios se guardan en algo parecido a un contrato inteligente validium. También podríamos ser testigos del surgimiento de intercambios semi-custodios, donde les confiamos dinero fiduciario en lugar de criptomonedas.

Ambos tipos de intercambios seguirán existiendo. La forma más sencilla y compatible con versiones anteriores de mejorar la seguridad de los intercambios de custodia es aumentar la prueba de reservas. Esto implica una combinación de prueba de activos y prueba de responsabilidad. Desarrollar protocolos bien estructurados para ambos presenta desafíos técnicos, pero debemos avanzar en ambas áreas tanto como sea posible y abrir el software y los procesos para que todos los intercambios puedan beneficiarse.

A largo plazo, espero que avancemos cada vez más hacia que todos los intercambios sean sin custodia, al menos en términos de criptomonedas. La recuperación de billetera existirá para nuevos usuarios que manejan pequeñas cantidades y para instituciones que necesitan tales arreglos por razones legales. Es posible que sean necesarias opciones de recuperación altamente centralizadas, pero esto se puede hacer a nivel de billetera, no dentro del intercambio en sí. La forma en que magic.link interactúa con plataformas como Polymarket es un ejemplo de este enfoque. En términos de dinero fiduciario, el flujo entre el sistema bancario tradicional y el ecosistema criptográfico puede verse facilitado por procesos locales de entrada y salida de efectivo para monedas estables respaldadas por activos, como el USDC. Sin embargo, alcanzar plenamente este objetivo llevará algún tiempo.

Un agradecimiento especial a Balaji Srinivasan, así como al personal de Coinbase, Kraken y Binance por sus discusiones.

Descargo de responsabilidad:

1. Este artículo está reimpreso de [Chaincatcher]. Todos los derechos de autor pertenecen al autor original [Vitalik]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.