Escrito por Joxes para DeFi LATAM. Sitio Web | Twitter.
En nuestro anterior Estado de la escalabilidad en Ethereum para DeFi LATAM, tomamos ventaja del estadío actual de los Optimistic Rollups más importantes para explicar en un alto nivel cómo funciona la tecnología y qué punto se encontraban. Ahora han pasado tres meses, el avance tecnológico no se detiene y cada vez son más los proyectos que se suman a la lista creciente de diferentes capas de ejecución (otra forma de llamar a la familia de L2 y similares) en desarrollo y lanzamiento al público.
En esta edición actualizamos el cuadro presentado en diciembre con nuevos proyectos y denominaciones entre la amplia gama de lo entendido por el ecosistema por L2.
A medida que aparezcan más y más proyectos con diferentes propuestas arquitectónicas, el término L2 será cada vez más ambiguo y a la vez restrictivo, propiciando el continuo debate en la comunidad de Ethereum. Seguramente algunas consideradas hoy “L2” no serán vistas así en el futuro, mientras que otras quedarán para el recuerdo por su absoluto desuso.
Parte 1: Una introducción a los Validity Rollups
Ethereum siempre se ha caracterizado por ser una red que bien valora sus recursos computacionales, esto es, cada transacción procesada por la red el remitente paga un coste por su ejecución e inclusión en la cadena de bloques (ver estimaciones) que va de la mano de un Ether escaso y motiva que la red aumente su seguridad vía participación como productores de bloques, ya sea hoy mediante minería, o en el futuro, con validadores PoS. Por otro lado, Ethereum sigue operando en su capa principal de forma tradicional como siempre se cuenta: las transacciones publicadas son verificadas individualmente por todos los nodos participantes: si existen 5000 nodos, entonces 5000 veces la transacción tendrá el privilegio de se ejecutada, en todas partes del mundo y en un relativo mismo lapso de tiempo. En favor de la descentralización de la red, Ethereum sólo procesa alrededor de 12 transacciones por segundo, ya que si arbitrariamente decide ampliar sus capacidades por la vía fácil, (por ejemplo, aumentando el Gas Limit y/o tiempos por bloque, clásica técnica del ethkiller promedio) expulsará automáticamente a los nodos con recursos más humildes, perdiendo el sentido como red distribuida que pretende ser.
¿Es posible que la red Ethereum pueda de alguna forma validar más transacciones de lo habitual sin que implique linealmente más carga de trabajo para los nodos?
Escalando mediante pruebas de cero conocimiento.
Un ZK Rollup ó Validity Rollup, es una solución de escalabilidad L2 de Ethereum que implementa la criptografía de un protocolo de zero-knowledge en el cual un conjunto grande de transacciones son ejecutadas fuera de cadena y publicadas resumidamente en Ethereum, adjuntando junto a las mismas estas pruebas criptográficas (conocidas como pruebas ZK o pruebas de validez) que la red principal verifica para dar validez a las transacciones y estado de la L2. Resulta fascinante entender que aunque en la segunda capa se procesan un conjunto de transacciones abismal, Ethereum no tiene porqué interpretar, revisar o ejecutar por sí mismo estas transacciones, basta con solo procesar estas pruebas de validez para tener seguridad plena de que la L2 publicó transacciones honestas o no.
Por lo tanto, la clave para entender cómo funcionan este tipo de Rollups, es comprender cómo estos protocolos criptográficos consiguen su cometido en verificar transacciones de forma más eficiente.
¿Qué es una prueba de cero conocimiento?
Una prueba de cero conocimiento (a partir de ahora zero knowledge proof) es un protocolo que mediante criptografía una parte (conocido como el prover), puede demostrar a la otra parte (el verificador) que una declaración es verdad sin que el primero deba incurrir en entregar información completa para que el verificador pueda interpretar para afirmar que es correcta.
No obstante, las zero knowledge proofs son de naturaleza probabilística, es decir, no se alcanza la certeza por una sentencia absoluta y comprobable a partir de la información aportada, sino por el contrario, sin dicha información hay que procurar que la declaración es altamente probable hasta el punto que no hay margen para el error.
Ejemplo:
En la coloración de grafos, una serie de puntos se encuentran interconectados por líneas. El famoso problema se resume en la siguiente pregunta, ¿Cuál es el número mínimo de colores necesarios para dibujar cada punto y que ningún color coincida entre 2 puntos conectados?
En el gráfico de Peterson, resultará fácil intuir que 2 colores no sería suficiente variedad y que inevitablemente algunos puntos del mismo color estarán conectados. Por otro lado, 4 colores o más favorecerá la variedad y será fácil de resolver disponiendo colores y que ninguno coincida con otro.
¿Pero qué pasa en el caso de tener que usar sólo 3 colores?
Supongamos ahora que no tenemos intenciones de resolverlo por nosotros mismos, sino que alguien nos demuestre que efectivamente es posible cumplir con este gráfico para tres colores.
¿Es posible que alguien nos afirme que es posible esto sin revelarnos el resultado?
La respuesta es sí.
En el campo del cero conocimiento, el prover puede ordenar los colores a su propia disposición sin revelarlo abiertamente a nosotros. No obstante, podríamos verificar si dicha afirmación es cierta interactuando con el mismo de forma iterativa.
El prover puede ordenar los colores como desee y procurando cumplir con la regla, ocultando luego la información para nosotros (ver 0). Siguiente paso nosotros como verificadores solicitamos revelar dos puntos conectados arbitrarios y chequear si coinciden o no en colores (ver 1). Al chequear, el prover ahora puede reordenar los colores para luego nosotros repetir el procedimiento y así sucesivamente (ver 2, 3, 4…). El punto es, que si el prover tiene razón, pasarán infinitos intentos y jamás acertaremos en hallar dos puntos del mismo color conectados; por el contrario si el prover miente, tarde o temprano lo descubriremos. En caso positivo, cada intento eleva el grado de confianza, por lo que se hay certeza de que sí es posible cumplir la regla para 3 colores, pero como verificadores no hemos ganado información precisa sobre cómo luce el problema resuelto, solo la certeza de que es completamente cierto.
Tal como se explicó este procedimiento, es conocido como zero knowledge proofs interactivas, ya que el prover y verificador se están comunicando en rondas sucesivas. En el mundo blockchain particularmente, dan un paso más adelante y se aplican zero knowledge proofs bajo la forma no-interactiva.
En Blockchains, una interacción entre el prover y verificador de forma clásica como el demostrado en el ejemplo anterior sería un problema, porque las redes se basan en simples entidades (nosotros los usuarios como provers) enviando transacciones para ser incluidas (los nodos y validadores como verificadores) en un solo paso. No hay necesidad de interacción continua porque los nodos reciben toda la información necesaria para incluir las transacciones de los usuarios, siempre que desglosemos toda la información necesaria. Es acá donde las pruebas de conocimiento no-interactivas hacen la diferencia, al no tener que revisar o verificar la información a validar de la forma en que fue generada o interpretada en su totalidad, en un solo paso.
Como ejemplo, podríamos tomar una función matemática f(x) con entradas de conocimiento público o datos privados no revelados. En este caso el prover realiza el cálculo de la función y el verificador puede corroborar que el resultado es cierto, sin conocer los datos privados ni hacer el cálculo por sí mismo, solamente verificando la zero-knowledge proof.
En este caso, la zero-knowledge proof no interactiva se traduce en una única prueba criptográfica concisa y suficiente que el prover debe entregar al verificador para que el segundo pueda tener completa certeza de que el sistema y los resultados son correctos. A su vez, con esta zero-knowledge proof no interactiva, el verificador no gana o aprende nada por sí mismo sobre cómo se llegó al resultado. Esta valiosa propiedad de validación, es lo que le permite a esta tecnología aplicarse a dos grandes campos en blockchain:
- Privacidad, en el cual las transacciones pueden ser validadas sin que el verificador conozca los datos de quién envía o qué se información se está manejando (ZCash, Tornado Cash).
- Escalabilidad, con el objetivo de que la verificación de transacciones y estado de una blockchain se pueda hacer sin que conlleve a realizar la misma carga de trabajo de quien la genera (Rollups, Validiums).
De hecho, todo lo explicado de zero-knowledge proofs no interactivas, es lo que se suele llamar bajo el acrónimo zk-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge).
Funcionamiento en Rollups
A partir de este momento, reemplazaré el término “zero-knowledge proof” por “prueba de validez” en el contexto de escalabilidad.
Imaginemos que fuese posible verificar una cantidad grosera de transacciones sin conocer todos los datos referidos a las mismas en un solo lapso de tiempo, un solo bloque. Imaginemos ahora que resulta más fácil y rápido verificar una prueba de validez referida a dicho bloque en vez de chequear todas y cada una de las transacciones individualmente. ¿Significa que podríamos hacer más con los mismos recursos? La respuesta es sí, con ZK Rollups.
Aunque es popular llamar esta tecnología bajo el nombre de ZK Rollups, también es conocido y más correcto usar el término Validity Rollups.
Los ZK Rollups operan bajo la misma filosofía de funcionamiento de un Optimistic Rollup: ser una cadena separada que utiliza a Ethereum para su seguridad, mediante la publicación de transacciones y utilización de dicha red principal para validar que las transacciones son correctas. A diferencia de los Optimistic Rollups, los ZK no requieren de ningún juego económico para asegurar las transacciones, ya que esto es reemplazado por la verificación de toda la cadena con las pruebas de validez usando Ethereum.
Desde la vista de Ethereum, los ZK Rollups son una serie de contratos inteligentes vinculados que almacenan la información de la cadena-L2 (merkle tree de balances y estado + datos de transacciones) y los fondos en la capa de aplicación de Ethereum, pero, en vez de que la red principal tenga que verificar toda esta data publicada, la prueba de validez (zk) entendido como una “prueba de computación” de que las transacciones fueron procesadas y por lo que esta misma sólo se encarga de validar dicha prueba. En el medio, un ZK Rollup no requiere de guardar toda la información que genera de forma cruda hacia la red Ethereum, al contrario aprovecha eficientemente el espacio de bloque para registrar los datos relevantes y así apuntar a un número tope teórico de 2000 transacciones por segundo, algo imposible en realizar en la red Ethereum con transacciones convencionales.
Los actores que hacen vida en un ZK Rollup se resumen en tres roles:
- Secuenciadores: reciben y procesan las transacciones de los usuarios dándoles un orden y construyendo los batches a publicar en Ethereum. Estos actores corren un nodo completo de L2, con especificaciones similares al de un validador de una red de alto rendimiento (como Solana).
- Provers: genera la prueba de validez a partir del paquete de transacciones procesadas por el secuenciador en determinado plazo de tiempo. El prover corre un hardware especial (ASIC) destinado a la producción de las pruebas de validez sin demoras una vez las transacciones están listas para finalizarlas, un trabajo efectuado en minutos, generalmente. En ocasiones el papel de prover y secuenciador son efectuados por un mismo actor, que también se les suele llamar coordinador.
- Verificador: asumido por Ethereum desde su capa de aplicación (EVM) donde se alojan los contratos correspondientes. La L1 recibe el conjunto de transacciones y la red en sí misma las comprueba únicamente a partir de la verificación de la prueba de validez proporcionada por el prover. Todo nodo completo de Ethereum es en cierto sentido un verificador por tener una copia del estado de la blockchain de Ethereum y correr los contratos inteligentes. Como ventaja, no requiere de participantes adicionales ni confianza asumida como en el caso de los Optimistic Rollups.
Según el funcionamiento del ZK Rollup, el secuenciador/prover determinará la comisión de transacción de los usuarios, destinando una parte para asumir los costes de publicar en la red Ethereum y otra a modo de regalías por su servicio (del mismo modo que un minero o validador de una L1).
El ciclo de funcionamiento de un ZK Rollup consiste en la siguiente secuencia:
- Los usuarios, desde la red Ethereum depositan fondos en el contrato del puente o receptor de fondos del ZK Rollup. La transacción confirmada es reafirmada por un secuenciador que minteará los activos dentro de la cadena haciendo efectivo el depósito.
- Ya dentro del ZK Rollup los usuarios realizan transacciones e interacciones según corresponda. El secuenciador y prover reciben las transacciones y el usuario por su parte recibe una confirmación suave, la promesa de que será incluida (publicada) en Ethereum.
- Minutos después, un conjunto de transacciones son publicadas en Ethereum (en forma de batch) y el merkle tree con los nuevos balances y estado es actualizado. En paralelo una prueba de validez generada por el prover se envía al contrato de verificación para la validación de las transacciones.
- La prueba de validez es verificada por un contrato de Ethereum comparándola con la información de la gama de Merkle roots correspondiente al conjunto de transacciones procesadas del momento. Esta verificación se realiza a modo de “circuitos” en el cual la prueba entera sirve para convalidar la transición o cambio de estado del ZK Rollup, consiguiendo que las interacciones de los usuarios tengan una confirmación final. Cabe destacar que si la prueba de validez es “inválida” o corresponde a transacciones fraudulentas/incorrectas, el contrato no aprobará dicha prueba.
Bajo el mismo sistema también se aprueban los retiros de fondos en el ZK Rollup una vez que la prueba de validez es verificada. Con esto, los usuarios también podrían salir del Rollup sin permiso ejecutando una transacción de la L1, e incluso realizar un retiro de emergencia en caso de que el secuenciador o prover no quiera cooperar o no esté activo. Finalmente, todo esto sin necesidad de tiempos de espera arbitrarios como 7 días o más tal como pasa en otras soluciones de escalabilidad.
Generación de la prueba de validez
El núcleo de un ZK Rollup es la implementación de una forma de un protocolo de cero conocimiento. Generar la prueba de validez por parte del prover no resulta nada sencillo y requiere recursos computacionales adicionales. En la familia de pruebas de validez tradicionales del tipo SNARK es común escuchar el uso de algoritmos criptográficos tales como Groth16 (el sistema más usado por diversos proyectos tales como Loopring y Hermez), PLONK (creado por Aztec y usado por zkSync) y en añadidura a implementaciones de curvas elípticas que se corresponde al tipo de contrato deployado en Ethereum.
En simultáneo, un nuevo tipo de prueba de validez conocido como STARK (Scalable Transparent Arguments of Knowledge) ha sido desarrollado por Starkware, puesto a producción y que cada vez toma más preferencia por sus ventajas comparativas, siendo adoptada por otros proyectos como Polygon (Hermez, Miden y Zero).
La discusión entre SNARK vs STARK a la vista de los usuarios está basada en su performance y aplicabilidad en el contexto de las blockchains. Mientras que el SNARK convencional es más barato de verificar en Ethereum, tiene la desventaja de tener que ser implementado mediante un trusted setup, lo que implica que su configuración inicial es establecida por un número de participantes mediante una ceremonia, que en caso de complot por parte del 100% de los integrantes, son capaces de vulnerar el sistema (lo común es que la información de la configuración inicial sea destruida por al menos un participante). Por su parte, las pruebas STARK son más costosas de verificar en Ethereum pero no requieren de un trusted setup, además de seguir vigentes en un mundo post-cuántico. Un cuadro comparativo resumen se muestra a continuación.
El reto de los matemáticos, ingenieros, informáticos y otras disciplinas involucradas en este campo está en hacer más eficientes estos sistemas en el tiempo. De hecho, cada vez se anuncian optimizaciones de dichos protocolos tales como TurboPLONK y UltraPLONK de Aztec, Halo2 de Scroll o mediante recursividad como Plonky2 de Polygon Zero. Con el tiempo, estaremos llegando al punto donde los beneficios de las pruebas STARK también serán tomados por las pruebas SNARK y viceversa, en todos los ámbitos mencionados.
Parte 2: ZK Rollups para pagos y de aplicación específica
Las primeras versiones de ZK Rollups han estado basadas en funcionalidades básicas de las cadenas de bloques tales como la transferencia de valor y operaciones especiales, pero no en la implementación de contratos inteligentes en general. Esto es así porque la tecnología basada en zero-knowledge proofs ha estado en muy temprano desarrollo y la adaptabilidad a computación arbitraria (un estado como la EVM) requería enorme trabajo adicional y optimización de la tecnología de los provers con el paso del tiempo. Como resultado, en la experiencia de usuario se puede observar que el uso de dichos Rollups se efectúa a través de interfaces especiales, wallets personalizadas o adaptadas y otras consideraciones que se desmarcan del clásico uso de billeteras como metamask.
Aztec:
El equipo de Aztec es conocido por ser el primero en implementar un ZK Rollup en Ethereum el 1 de febrero de 2020. En sus primeras versiones con zk.money, Aztec integra ETH y DAI para ofrecer transacciones privadas en un ambiente escalado, lo que se conoce también como un Rollup ZK-ZK ó ZK al cuadro. Aztec ha estado en el desarrollo de diferentes sistemas de proving a partir de PLONK como turboPLONK y ultraPLONK que busca hacer más eficiente la generación de pruebas de validez considerando las características de privacidad, que generalmente son un coste adicional que impacta en Ethereum. Para ofrecer dicha funcionalidad, Aztec integra un sistema UTXO con “notas” privadas que se envían entre usuarios sin revelarse la identidad ni balances involucrados.
Una segunda versión llamada Aztec Connect desplegada este mes, los usuarios pueden usar aplicaciones DeFi en L1 a través de este nuevo tipo de Rollup (conocido como DeFi Pooling). Element y Lido a través de Curve han sido las primeras aplicaciones integradas, y se espera que otras más se integren en el mediano plazo como Liquity, Compound y Aave.
Loopring:
A finales de febrero de 2020, Loopring se lanza como un L2-exchange del tipo libro de órdenes. En su modelo, el secuenciador tiene control de la gestión de libro de órdenes y maneja el comercio según las solicitudes, guardando los resultados en Ethereum. Por el momento ha pasado por tres versiones con mejoras de rendimiento y experiencia de usuarios como la inclusión de provisión de liquidez vía AMM, y como no, integración para crear NFTs.
LRC es el token del proyecto y cumple con la función de ser un captador del 70% de fees del protocolo por medio del staking. También sirve de enganche para participaciones en su DAO y cambiar parámetros del protocolo.
zkSync v1:
De Matter Labs, zkSync v1 es una de las versiones de ZK Rollup más exitosas del espacio, por su simplicidad e integraciones de diferente índole. Tal y como Axl explica en su último artículo para DeFi LATAM, una de las características notables es el posible pago de comisiones en tokens ERC20. La integración con el DEX ZigZag, posibilidad de minteo de NFTs e integración con Argent para el uso de Lido, Yearn y Aave a bajo coste, hace de este ZK Rollup útil para diversos tipos de usuarios. Mención especial a Gitcoin, el cual habilitó la posibilidad de usar la red para participar en grants.
Su próxima versión, zkSync 2.0, planea albergar contratos inteligentes y ser EVM compatible, lo cual discutiremos más adelante.
ZKSpace:
Conocido antes como ZKSwap, es un ZK Rollup que desde el principio se enfocó en ser un DEX del tipo AMM. Desde su lanzamiento en 2021, ha pasado por las versiones 1, 2 y 3, siendo esta última renombrada como ZKSpace. Con esta versión, también se suma las característica de minteo y comercio de NFTs.
Su token, ZKS tiene un rol en la gobernanza del uso de la red. a través de un sistema “PoS mining” los usuarios pueden bloquear ZKS para recibir a cambio gZKS y empezar a captar recompensas. Stakeando los tokens, se publicar propuestas a la gobernanza vía snapshot tales como enlistar nuevos tokens, proponer airdrops, incentivar liquidez, cambiar los parámetros de fees e incluso modificar el roadmap del proyecto.
Hermez 1.0:
La primera versión de Hermez se lanzó en marzo del 2021, como un ZK Rollup basado en sólo transferencia para ETH y una selecta lista de ERC20s. Este proyecto fue el primero en proponer un modelo descentralizado de producción de bloques para rollups, bajo el nombre de Proof of Donation, en el cual diferentes candidatos “coordinadores” apostaban con tokens del proyecto en forma de subasta para ser seleccionados como procesador de transacciones por un periodo de 40 bloques de Ethereum, alrededor de 10 minutos. El ganador recibía fees correspondientes y de los tokens stakeados un 30% se quemaban, 40% se dirigían a Gitcoin Grants y el 30% se dirigían para el resto de participantes.
El desarrollo de la versión 1, se detuvo en simultáneo con la absorción del proyecto hacia Polygon, dando de baja su token HEZ, para un cambio por MATIC en un ratio de conversión de 1 por 3,5 respectivamente. Sus esfuerzos ahora están en la próxima versión, una zkEVM.
dYdX:
dYdX es un protocolo DeFi que implementó un ZK Rollup en Q2-2021, utilizando StarkEx, un engine desarrollado por Starkware enfocado en trading. En estas versión dYdX está para el trading de contratos perpetuos. La gestión de los libros de órdenes se maneja completamente off-chain por parte del secuenciador. dYdX solo admite depósitos en USDC y los precios de los mercados son traceados gracias a una integración especial con Chainlink. El balance de los usuarios se mantiene seguro en Ethereum y validado por la prueba de validez del tipo STARK, el cual sirve para efectuar retiros de emergencia utilizando una herramienta desarrollada por l2beat.
Su token DYDX cumple con el rol de gobernanza sobre el protocolo, sin ninguna funcionalidad sobre el funcionamiento del Rollup en sí.
Estadísticas
Según los costos inherentes del rollup, utilidad y los incentivos presentes, hace que algunos ZK Rollups sean adoptados más que otros. A continuación, se presenta la actividad off-chain de los ZK Rollups mencionados, basada en las transacciones diarias realizadas sobre la L2 en los últimos 28 días.
En la actualidad, zkSync y Loopring son los ZK Rollups más utilizados con +10k transacciones por día, priincipalmente por sus casos de uso e integraciones mencionadas que siempre atrae usuarios, y en el caso particular de Loopring, adición de incentivos . En un escalón más abajo, ZKSpace y la primera versión de Aztec su actividad fluctúa entre 100-1k, lo cual demuestra la utilidad en Aztec en cuanto a privacidad, y de nuevo incentivos en ZKSpace. El ZK Rollup menos usado en este gráfico, Polygon Hermez 1.0, cuyo desarrollo ha sido completamente detenido, con días sin reportar transacciones. Al día de hoy, DYDX no reporta públicamente esta clase de datos.
Parte 3: La zkEVM y contratos inteligentes en ZK Rollups
Como hemos mencionado, las pruebas de validez son una forma extremadamente novedosa para probar qué transacciones son válidas de forma eficiente. El problema es que los contratos inteligentes y el funcionamiento de Ethereum en sí no se pensaron en que a futuro convendría aplicarles estas nuevas tecnologías criptográficas. Como resultado, el corazón de Ethereum, la EVM (máquina virtual donde están todos los contratos inteligentes) ha ganado toda la aceptación y popularidad como estándar, y ahora se ha convertido en una enorme tarea en introducir pruebas de validez de distintas maneras a la misma y así “escalar el alojamiento y uso de contratos inteligentes”.
Para los proyectos ZK Rollups es de sumo interés permitir que contratos inteligentes se puedan desplegar en sus redes-L2 y replicar la utilidad de Ethereum, básicamente para sumar compatibilidad y adopción. Para conseguirlo, algunos proyectos han construido su propia versión de máquina virtual optimizada para permitir pruebas de validez como pruebas de computación de que los contratos inteligentes han sido ejecutados correctamente, con la posibilidad o no de aceptar lenguaje de solidity. Otros han intentado la ruta difícil, en introducir el uso de las pruebas de validez directamente en distintas instancias de alguna forma de EVM (emulando su funcionamiento), y esto generalmente se le conoce como zkEVM.
En cualquier caso, el objetivo de arquitecturas así, es conseguir que el estado inicial de una VM pase a nuevos estados de forma consecutiva, pudiendo ser verificadas con pruebas de validez a nivel de Ethereum.
A continuación se listan las L2 cuyos proyectos tienen una ruta clara de implementación de contratos inteligentes sobre formas de ZK Rollups:
- StarkNet: por Starkware, este ZK Rollup está construida con un arquitectura 100% propia basada en su desarrollo a partir de su invención de pruebas del tipo STARK. Es por ello que han desarrollado Cairo, un lenguaje de programación de StarNet OS en la que prometen un serie de optimizaciones respecto a solidity. No obstante, el equipo de Nethermind se encuentra en proceso de implementación de un compilador de solidity a Cairo. Las consecuencias de todo este nuevo trabajo implican que el funcionamiento de la red no será como el de una EVM (geth) y por lo tanto las herramientas de tooling, wallets, servicios y otras infraestructuras deberán tomar su tiempo para ser compatibles con esta nueva L2 Mainnet: alpha (permisionada).
- Miden: por Polygon, esta construcción data desde el desarrollo de Winterfell por Facebook (ahora Meta). Con un filosofía semejante a StarkNet, Miden correría contratos inteligentes escritos en Miden Assembly, el cual contará con compilador para soportar lenguajes como Solidity y Move, portando todo a la MidenVM, basada en pruebas STARK. Testnet: Q4 2022?, Mainnet: 2023?.
- zkSync 2.0: por Matter Labs, su versión admite ser compatible con contratos escritos en solidity, sin ser capaz de soportar todas y cada una de las funciones de una EVM convencional tal y como llamadas a SHA256 y Keccak256, uso de ecrecover, etc, lo que implica que un muy reducido número de desarrolladores deberán hacer modificaciones para poder funcionar en zkSync 2.0 (a pesar de que asumen de que aplicaciones DeFi y general podrán correr sin modificaciones en un 90%). En la arquitectura de este rollup, los contratos escritos en Solidity se compilan a Yul y luego en una VM de bajo nivel (LLVM) conocido como ZincVM, por lo que al final los contratos son ejecutados bajo una forma de zkVM completamente distinta. El equipo de Matter Labs se enfocó en garantizar la compatibilidad con Solidity en esta nueva instancia para justificar la etiqueta de “zkEVM”, pero admiten que tienen interés a largo plazo de expandir los usos de contratos escritos a partir de Zinc directamente. Testnet: activa, Mainnet: Q3 2022?.
- Hermez 2.0: por Polygon, plantea ser un ZK Rollup plenamente compatible con la EVM diseñada en Ethereum a la vista de los desarrolladores de contratos inteligentes en solidity, vyper, etc. Esta zkEVM consigue la implementación de contratos en Solidity tomando todas las instrucciones de la EVM (opcodes) una por una en una forma intermedia (micro-opcodes) y adaptarlas a una uVM basadas en STARK. Luego, la validación formal de Rollup vía Ethereum se realiza mediante una prueba tipo SNARK, lo que implica que la prueba SNARK verifica la prueba STARK (se genera la prueba de una prueba). Testnet: activa, Mainnet: Q4 2022?.
- Scroll: este equipo también persigue implementar una forma de zkEVM a nivel de bytecode, sin alterar los lenguajes de programación admitidos por la EVM ni modificar su forma de procesar. Todas las instrucciones de la EVM (opcodes) se mantienen intactas y se generan las pruebas SNARK para validar todas sus partes, optimizador con el sistema prover llamado Halo2. Según Scroll, esta es la arquitectura más uniforme para hacer una EVM compatible con pruebas de validez, heredando la seguridad del diseño EVM original. Testnet: Q3-Q4 2022?, Mainnet: 2023?.
- Consensys: similar a Hermez y Scroll, diseña su propia versión de zkEVM sin lenguajes intermediarios y manteniendo el funcionamiento tal y como lo es la EVM. Testnet: sin fecha estimada.
- AppliedZKP: proyecto impulsado desde la Ethereum Foundation, también busca la forma más genuina de alcanzar una zkEVM equivalente en su totalidad al funcionamiento de la EVM tradicional. La innovación de esta iniciativa viene dada por la separación de la computación (ejecución de transacciones) del almacenamiento (storage) lo que conlleva a funcionar con dos pruebas de validez en paralelo, EVM proof y state proof respectivamente. Lo especialmente relevante es que la fundación prevé en un futuro implementar su propia versión de ZK Rollup bajo la modalidad de enshrined rollup (rollup casado con el protocolo Ethereum y no operando a partir de un contrato inteligente convencional) o incluso convertir la L1 en un ZK Rollup de estas mismas características. Es por eso que el enfoque de la fundación es hacerlo lo más objetivamente posible aplicable a los clientes de ejecución de Ethereum y compatibilidad con todo lo trabajado hasta ahora. Testnet: sin fecha, Mainnet: posterior a Ethereum PoS + danksharding (como parte de zk-SNARK everything según Vitalik Buterin en su roadmap para Ethereum).
Otros proyectos que también han anunciado su intención de permitir correr contratos inteligentes en ZK Rollups son Sin7Y, Loopring (ambos en una modalidad zkEVM) y Aztec (para su versión 3 con contratos escritos en Noir, lenguaje basado en Rust).
Aunque para los desarrolladores lidiar con un ZK Rollup que exitosamente compile el lenguaje solidity a otro implementado por la L2 puede que sea casi indistinguible de utilizar un Rollup con una zkEVM equivalente a la de Ethereum, impacta en la experiencia de los ingenieros y las supuestos de seguridad de cualquier forma modificada de EVM distinta al modelo original, sin contar los riesgo de mala implementación de cualquier protocolo criptográfico, indistintamente de ser SNARK o STARK.
Al final del día, queda demostrado que construir una VM para ZK Rollups desde cero y amigable a pruebas de validez, reduce el tiempo de desarrollo respecto al de lanzar una zkEVM lo más fidedigna posible. Solo el tiempo dirá cual de todas estas propuestas predominará en el largo plazo.
Parte 4: ¿Son realmente las ganadoras en el largo plazo? Sobre descentralización y otros retos
Los ZK Rollups son aceptados como la tecnología de facto a escalar a largo plazo sea cuál sea el caso de uso. Sin embargo, si bien su forma de validación es innovadora, al día de hoy enfrentan el más importante desafío para alcanzar un estadío maduro de tal: la descentralización en todos sus aspectos y otras garantías de seguridad. Revisemos cada uno de los puntos:
- Bugs en contratos inteligentes: un Rollup, como cualquier otra aplicación en Ethereum, no está exenta de ser explotada si convive con una vulnerabilidad a miras de ser aprovechada. Aún peor, una mala implementación de pruebas de validez también puede ser de riesgo para los contratos y burlar el sistema, tal y como lo descubrió Trail of bits en este artículo para distintos sistemas como Girault, bulletproofs y PLONK. El uso de pruebas de validez no debe generar falsas sensaciones de seguridad absoluta, solo formas de validación eficiente que prometen serlo.
- Token: conceptualmente un rollup está hecho para funcionar sin necesidad de incentivos económicos basados en un token adicional, sólamente en la moneda de la red principal (ETH). En la práctica, un ZK Rollup requiere de un conjunto de secuenciadores y provers que estén correctamente coordinados de acuerdo a su mejor interés (ganar dinero recolectando fees) y a su vez brinden un buen servicio a la red L2. En este caso, un token adicional puede jugar un rol en la participación de estos actores y evitar la colisión entre los mismos, con algún mecanismo de consenso en la producción de bloques. Adicionalmente se sabe que, como todo protocolo no terminado o que requiere de mantenimiento, la mejor manera es de alinear los objetivos a través de un token de gobernanza, tal y como hacen algunos ZK Rollups en funcionamiento.
- Centralización de secuenciadores y provers: en ambos casos, ambos roles requieren de hardware extremadamente especializado, que deja por fuera a cualquier usuario común. En el caso de los secuenciadores, mientras más actividad se espere en el ZK Rollup, requerirá de una capacidad computacional estilo servidor con alta banda ancha de internet, para procesar y confirmar las transacciones en segundos originadas desde todas partes del mundo. Por su parte, los provers necesitarán hardware como ASICs, FPGAs o gama de GPUs (más energía) para garantizar que las pruebas de validez se generen en pocos minutos. Por ello es que, mientras más ambicioso sea el ZK Rollup y tope de procesamiento de transacciones, estos requerimientos serán cada vez más altos, y dependerá de las desarrolladoras de chips que esta brecha se reduzca. En este último punto , Paradigm estima que este mercado podría tener un tamaño similar al de la minería de redes PoW, pero mientras tanto, esta posibilidad de participación queda en manos de grandes compañías, lo cual no se puede descartar que en algún punto hagan uso de su poder para reordenar transacciones, extraer dinero vía MEV y censurar usuarios.
El equipo de Polygon Hermez ha sido el primero en develar un nuevo mecanismo de consenso para los secuenciadores y provers alinear sus incentivos para mantener activa la red, cuyo nombre propuesto ha sido Proof of Efficiency.
Prueba de Eficiencia es un mecanismo de participación descentralizada para ZK Rollups basado en la experiencia recolectada de su anterior Proof of Donation. El objetivo de la misma es garantizar la participación por incentivos económicos, evitar el control de la red por un sólo productor de bloques y promover la eficiencia en los tiempos de confirmación.
En este caso, los secuenciadores estarán encargados de recolectar las transacciones de los usuarios y ganar fees por inclusión para luego publicarlas en Ethereum y él mismo pagar los fees correspondientes por crear un nuevo batch, y para evitar malos comportamientos, estos actores deberán stakear o pagar un fee en MATIC para que sean tomados en cuenta e incluirlo en dichos paquetes. Los provers, llamados acá agregadores, se encargará de leer los batches en L1 y generar la prueba de validez para todas las transacciones pendientes. Estos batches contendrán los fees adicionales para que los provers generen las pruebas de validez cuando les sea rentable, bajo un esquema de first come, first serve, sin ningún requerimiento adicional para participar.
Siendo este el primer mecanismo de consenso explícitamente establecido para un ZK Rollup, será una referencia más adelante para el resto de los proyectos, que también buscarán plantear sus propios modos de participación.
Final
Como se mencionó en el presente artículo, los ZK Rollups son la opción de facto para escalar Ethereum, hasta el punto de que la Ethereum Foundation la considere como tecnología para escalar la mismísima L1. Mientras tanto, un día en Web3 es un año en la tierra, y solo el paso del tiempo nos posicionará en la solución más aceptada para escalar Ethereum para los próximos mil millones de personas.
Sin más que agregar, si llegaste hasta el final no olvides unirte a las comunidades DeFi LATAM y L2 en Español para estar al día con lo último en el mundo de la escalabilidad en Ethereum.
#L222
Fuentes y lecturas destacadas:
- Understanding Zero-knowledge proofs through illustrated examples.
- How Zk-Rollups Work.
- A Review of zk-SNARKs.
- zk-SNARKs.
- Luozhu sobre zkEVM.
- zk-SNARKs vs. Zk-STARKs vs. BulletProofs? (Updated).
- Hardware Acceleration for Zero Knowledge Proofs.
- An approximate introduction to how zk-SNARKs are possible.
- Why and How zk-SNARK Works: Definitive Explanation.
- Zero Knowledge EVMs: What is a zkEVM?.
- zk, zkVM, zkEVM and their Future.
- Polygon ZK: Deep Dive Into Polygon Hermez 2.0.
- A specification for a ZK-EVM.
- Coordinated disclosure of vulnerabilities affecting Girault, Bulletproofs, and PlonK.
- Proof of Efficiency: A new consensus mechanism for zk-rollups.