Transparencia Radical para CEXs

Basado en Proof of Solvency de Vitalik Buterin

La semana pasada, en Lemon dimos un primer paso hacia la transparencia publicando una prueba de activos y pasivos abiertamente. Sin embargo, les comparto el porqué un PoR — proof of reserves — no es condición suficiente para probar la solvencia (activos — pasivos ≥ 0) y la integridad del total de la suma de los pasivos; y también cómo se podrían haber adulterado ambas pruebas.

A todo le agrego una explicación + una vista desde el otro lado del mostrador + qué podría haber hecho un CEX (centralized exchange) para adulterarlo + cuál sería una solución usando tecnología y eliminando intermediarios. Mi objetivo principal es impulsar que, de acá en adelante, vayamos hacia una industria con transparencia radical.

Empecemos partiendo la validación en dos: Prueba de Activos (o Proof of Funds en Ingles) para comprobar que tenemos las criptomonedas, y Prueba de Pasivos (o Proof of Liabilities), para validar los depósitos de los usuarios.

En el análisis de ambas pruebas, dividiremos el comportamiento de la compañía/wallet en agente Bueno 😇 (lo que hicimos), en agente Malo 👿(lo que podría haber hecho alguien con diferentes incentivos) y cuál sería una solución en donde no dependemos de que el agente sea bueno o malo, sino sustentada meramente por matemática y tecnología: la manera “trustless“🔒.

Prueba de Activos

Prueba de Activos (Proof of Funds): Tenemos que probar el control sobre las direcciones que holdean los activos y detallar la cantidad de activos.

La verificación de la dirección se puede hacer firmando un mensaje que valide la pertenencia con la clave privada asociada a dicha dirección, por ejemplo firmando un mensaje arbitrario. O también puede hacerse moviendo fondos de manera predeterminada.

Un desafío posible para esa verificación de pertenencia es cuando tenemos cold storage con air gap, donde la idea es no tener contacto con esas llaves por seguridad. Mas sobre Air gap.

En la mayoría de los casos, con probar que las wallets nos pertenecen es suficiente. Lo importante de la prueba de activos es ** que sea lo más tiempo real posible **. Que no sea una foto, sino una película. Con los activos on chain lo podemos ver directamente y actualizar bloque a bloque.

Prueba de Activos — Agente Bueno 😇

En este caso lo que hicimos fue contratar un auditor externo el cual revisó billetera por billetera en: (a) que tuviéramos el control al mover fondos desde ahí (b) registrar el saldo de cada activo y lo constató en este documento. Es decir tomó la “foto” de nuestros activos. https://www.lemon.me/pruebadefondos.pdf

Prueba de Activos — Agente Malo 👿

En este caso, un CEX que no tuviera los fondos, podría haber adulterado la “foto” tomando activos prestados, sacar la foto y luego devolverlos. Como se rumorea paso con Huobi y GateIO. Otro escenario es que el auditor podría haber estado comprometido y realizar un reporte fraudulento.

Prueba de Activos — Trustless 🔒

La implementación sin intermediarios es validar las billeteras y brindar un trackeo on chain en tiempo real de las billeteras validadas con los saldos en blockchain, mismo si están colocados en protocolos DeFi. Lo más importante es tener la película y no la foto. Simple as that.

Esta es la solución que estamos presentando desde Lemon esta semana. Acá un mini spoiler.

Prueba de Pasivos

Prueba de Pasivos (Proof of Liabilities): Acá viene la parte difícil. ¿Cómo probamos que los depósitos de los usuarios son los que realmente tenemos sin revelar la privacidad de los usuarios? Es decir, por ejemplo, que Alicia tiene 1 BTC registrado como saldo en Lemon y que Bob tiene 2 ETH.

Prueba de Pasivos — Agente Bueno 😇

Para esto, un escribano ingresó a nuestro sistema y validó los saldos de todos los usuarios (en su totalidad) en las diferentes monedas. Y lo constató en este documento. https://www.lemon.me/acta-pasivos.pdf

Prueba de Pasivos — Agente Malo 👿

Un CEX deshonesto podría haber armado una versión reducida y adulterada de la base de datos escondiendo la original, de tal manera que los saldos registrados sean inferiores a los reales. O hipotéticamente el escribano podría estar comprometido.

Prueba de Pasivos — Trustless🔒

Acá se pone más complejo. Voy a explicar 2 soluciones de la manera más simple posible. La primera, usando los famosos merkle trees. La segunda, propuesta por el crack de Vitalik, usando ZKSnarks.

1. Merkle Trees Approach

Lo que hacemos es generar un merkle tree con los balances de los usuarios. En donde cada hoja del árbol representa los balances en las distintas monedas de un usuario, los nodos la suma parcial y la raíz la suma total.

Voy con un ejemplo, supongamos que tenemos 4 usuarios: Fede, Gabi, Vicky y Cami; cada uno con su balance en Bitcoin representados por un nodo del árbol (root leaf). Podemos armar un Merkle Tree y llegar a un nodo raíz (merkle tree root) con un hash y la suma de todos los saldos.

Con solamente mi hoja y los distintos nodos, puedo llegar a la raíz y validar, sin tener la información de los demás usuarios, de que los pasivos son la totalidad.

Supongamos que soy Vicky, cuento con mi hash y mi saldo. Necesito la informacion en azul e ir computando (amarillo) para llegar por mi cuenta al nodo raíz.

Una vez ahi, puedo constatar que el nodo raíz y el balance publicado por la compañía es igual al que pude calcular desde mi lado y comprobar la totalidad de los pasivos.

El único problema con este approach es que en el primer cálculo recibo otra hoja ( en el ejemplo lo marque con un warning azul), exponiendo el balance de otro usuario sin identificar. Si lo extendemos a un agente malicioso el cual se encuentre en control de varias cuentas podría obtener esta info de múltiples usuarios. Es un riesgo menor, pero existe.

2. Vitalik’s ZKSnarks Approach

Okay, para entender este approach necesitamos dividirlo en 2 partes. La primera el KZG y la segunda el ZkSnark. Qué es un KZG?

Voy a resumir un KZG (Kate-Zaverucha-Goldberg) polynomial commitment como especie de “función de hash de caja negra” con algunas propiedades especiales (sorry criptógrafos). La más importante, el polinomio puede cometer un montón de números con solo un punto y proporcionar la prueba de inclusión para cualquiera de estos números sin revelar el resto de los números al verificador. Esto permite ser más eficiente a la hora de probar vs. un merkle tree, ejemplo con 128KB.

Para curiosos, encontré esta representación ilustrativa de cómo podemos pasar de un merkle tree en un KZG commitment. Entiendo que varios EIP van a contener KZG.

La segunda parte es el ZKSnark, siglas de Zero-Knowledge Succinct Non-Interactive Argument of Knowledge. (Succinct siendo: pruebas chicas y rápidas de comprobar). Es una construcción de prueba en donde puedo probar cierta información sin revelar esa información y sin que haya una interacción (non interactive) entre el probador y el verificador.

Juntando estas dos, Vitalik propone poner los balances de los usuarios en un KZG commitment y usar un ZKSnark para probar que todos los balances son no negativos y que la suma da cierto valor.

De esta manera, a diferencia del Merkle tree eliminamos por completo el riesgo de revelar parcialmente cualquier tipo de información y manteniendo la total privacidad. Sí, es un genio.

Mi opinión, la relación riesgo sobre daño (risk/damage) de revelar algo de privacidad con el Merkle Tree approach es varios órdenes de magnitud inferior al estado actual de la industria, en donde no sabemos si hay empresas que tienen o no los fondos de los usuarios como pasó con FTX y es por donde tenemos que arrancar. Con más tiempo y con implementaciones de la versión de Vitalik podemos migrar de merkle a zksnarks.

Conclusión

Desde Lemon, salimos de manera rápida con un PoR que sabíamos que era imperfecto para dar un shock de confianza después de una oleada de rumores y FUD, con sus respectivas vulnerabilidades expuestas en este post.

Como vimos, ya existen herramientas que nos permiten disponer de la confianza en los exchanges para probar su solvencia y que la totalidad de los depósitos sean los correctos.

En Lemon, estamos implementando tanto la prueba de activos como de pasivos de manera que sean transparentes y no haga falta confiar en nadie más que en la criptografía. A fin de cuentas, este fue el motivo por el cual much@s nos sumamos a crypto, ¿no?

Finalmente, siendo parte del directorio de la Cámara Fintech, estoy volcando estas ideas en una propuesta y presentándola para que se convierta en un standard para las empresas Argentinas. Invito a todos los que quieran colaborar en el proyecto, tengo mi twitter DM abierto.

M.

— —

📕:

Vitalik Proof of Solvency:-https://vitalik.ca/general/2022/11/19/proof_of_solvency.html

KZG commitments-https://alinush.github.io/2020/05/06/kzg-polynomial-commitments.html -https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html

KZG proof fast https://alinush.github.io/2021/06/17/Feist-Khovratovich-technique-for-computing-KZG-proofs-fast.html

Zk-snarks- https://www.youtube.com/watch?v=gcKCW7CNu_M&t=648s

https://consensys.net/blog/developers/introduction-to-zk-snarks/

Kraken’s merkle tree approach example:-https://www.kraken.com/proof-of-reserves