Que maravilla esto igual. Que ZK, que EVM, que Layer 2, que Ethereum, su escalabilidad, sus traumas y sus sueños. Que los rollups y las rollup wars y que Base, Arbitrum, Optimism, ZKSync, Starknet, Loopring, Mantle, Mantis, Metis, Polygon ZK, Linea, Boba, Scroll, Taiko, Aztec, Fuel. Sin soplar y sin chistar, ordenadas por TVL, las layer2 más importantes (a mi descuageringado criterio y a riesgo oneroso de olvidarme alguna).

Que maravilla el TVL, o total value locked para los despistados, como parámetro que rige el mundo, como ley ordenatoria número uno de las profundidades de la galaxia cripto, de los pantanos que acumulan agua estancada dentro y fuera de Ethereum. Que maravilla que incluso cuando se habla de escalabilidad, rige el mundo el TVL, que mide la liquidez. Por que en el fondo “liquidity is king” y lo demás vemos. También en el fondo, y no tanto, “liquidity has no royalty”. En definitiva, la liquidity, o lo que Marx y cualquier hispano hablante no aburguesado de tanto “crypto” llamaría lisa y llanamente “el capital”, fluye libremente por distintas redes, protocolos y promesas. Y como diría la Bersuit 🎶 me muevo para aquí, me muevo para allá 🎶.

Pero hoy, loco, no vamos a hablar de TVL. Vamos a tratar de entender que hay detrás de todo eso. Vamos a ver la parte técnica de las layer 2, específicamente de los rollups, de los ZK rollups y, para ser más preciso, de las ZK EVM.

¿Que significa ZK EVM?

Para hablar de los tipos de ZK EVM, tenemos que entender que es una ZK EVM. En general se divide a las blockchains en 2 tipos: aquellas que son compatibles con la EVM y aquellas que no. Esta distinción fue muy útil sobre todo durante 2021 y 2022, con el boom de las ETH killers, blockchains que apuntan a resolver los problemas de escalabilidad de Ethereum (y el trilema de escalabilidad). Redes como Polkadot, Cardano o Solana no son EVM. Osea, no tienen la capacidad de procesar programas hechos para EVM. Harmony, RSK, Aurora, Celo y algunas más, sí.

¿A que nos referimos con compatibilidad? Vamos a explicarlo con una metáfora. Viste que hay distintos tipos de amigos? Bueno todos tenemos ese amigo o amiga que la rompe con edición de fotos. Y siempre manda fotos editadas al grupo. Hasta que un día decís, loco basta de tolerar esta abrumadora centralización fotográfica. Yo también quiero editar fotos. Vas a google y ponés: “descargar photoshop gratis”. Te aparece una página llena de virus que te da dos opciones:

  • descargar para MAC
  • descargar para Windows

Bueno, eso es la compatibilidad. Photoshop es un programa hecho para hacer fotos (y para llenarle la compu de virus a los que se lo quieran descargar gratis). Es decir, es un paquetito lleno de archivos que contienen código. Ahora, el código del programa para MAC es distinto que el de Windows. Porque son dos sistemas operativos diferentes, que no son compatibles.

Con las blockchains pasa lo mismo. Vos podes armar tu protocolo de fotos descentralizadas para que sea compatible con Ethereum, o con la Ethereum Virtual Machine, o no.

Entonces ¿qué son las ZK EVM? Son redes que usan Zero Knowledge Proofs y que son compatibles con Ethereum. Sí, ya sé. El concepto de compatiblidad sigue quedando bastante amplio. Es por eso justamente que hacemos este análisis. Exploramos distintos diseños de ZK EVM para agruparlos en tipos según que tan compatibles son. Es como hacer un análisis de Messi y su compatibilidad con otros jugadores:

  • Messi con Xavi, Iniesta, De Paul o Di María: 100% compatible.
  • Messi con Lavezzi, Higuain, Rakitic o Thierry Henry: bastante compatible.
  • Messi con Mbappe o Mourinho: muy poco compatible.

Los diferentes tipos de ZK EVM

Nuestroq querido amigo Vitalik definió 4 tipos de ZK EVM: desde perfectamente compatible a “apenas compatible”. Ya vamos a ver en detalle los 4 tipos. Pero lo interesante es que agrega una variable extra. Resuta que la EVM no está optimizada para ZK. Este es un tema que da para otro artículo entero, pero las ZK generan pruebas Starks y la EVM tiene algunos problemas de performance para procesarlas. Es como ir a la montaña con zapatillas de correr. Está bien, pero no es ideal. Las zapatillas de correr son ideas si vas a saltar por todos lados, no tanto si tenes que estar pisando barro y piedras.

En concreto, hay un trade-off bastante lineal: más compatibilidad equivale a menos performance, y más performance, equivale a menos compatiblidad.

Vitalik lo define en este gráfico, donde además estan los 4 tipos de ZK EVM específicados.

Bien podríamos terminar el artículo acá, pero tengo tiempo, llueve así que no voy a ir al gimnasio, por lo que vamos a definir cada uno de las 4 categorías de ZK.

Type 1 (100% Ethereum-equivalent)

Las ZK-EVM de tipo 1 apuntan a ser totalmente equivalentes a Ethereum. No cambian nada del protocolo para hacer que generar las ZK proofs sea más fácil.

La ventaja es evidente: compatibilidad total. Son sistemas que pueden verificar la ejecución de Etherum tal cual está hoy. Pueden usar los clientes de Ethereum, además de toda su infraestructura.

La desventaja también: como dijimos, la EVM no está pensada para que generar pruebas criptográficas y verificarlas sea sencillo. Las pruebas tardan varias horas en procesarse.

Type 2 (100% EVM-equivalent)

Atención a la descripción. Este tipo es 100% equivalente con la EVM, pero no con Ethereum. Esto quiere decir que la ejecución es idéntica a la EVM pero hay algunas diferencias en la forma de estructurar la información. El objetivo es ser compatible con las aplicaciones de Ethereum pero hacer pequeñas modificaciones al protocolo para que generar pruebas sea más rápido.

La ventaja es justamente esa: las aplicaciones son compatibles, aunque no vas a poder usar un cliente de Ethereum para verificar lo que hacen. Vas a poder usar varias herramientas para desarrollar en Ethereum.

Type 2 ZK-EVMs strive to be exactly EVM-equivalent, but not quite Ethereum-equivalent. That is, they look exactly like Ethereum “from within”, but they have some differences on the outside, particularly in data structures like the block structure and state tree.

The goal is to be fully compatible with existing applications, but make some minor modifications to Ethereum to make development easier and to make proof generation faster.

La desventaja es que si bien las ZK EVM de tipo 2 ofrecen mejores tiempos que las de tipo 1, todavía son bastante lentas para toda la parte ZK.

Tipo 2.5 (EVM-equivalent, excepto por el gas)

Una opción que permite mejorar la eficiencia general de una ZK EVM equivalent es cambiar los costos de gas para que sea más caro hacer operaciones que son dificiles de validar con ZK. Esto haría que algunas aplicaciones se rompan, por lo que deberían ser readaptadas. Es decir, no va a ser 100% EVM equivalent.

Tipo 3 (casi EVM-equivalent)

Las ZK EVMs de este tipo hacen varios sacrificios a la compatibilidad para mejorar los tiempos del prover y hacer que sea más fácil trabajar con la parte criptográfica de las ZK.

La ventaja es que es más fácil de construir y hay mucho mejores tiempos que con el tipo 1 y 2.

La desventaja es que ya no hay una compatibilidad absoluta con la EVM, lo que quiere decir que varios devs van a tener que ajustar sus programas para llevarlos de Ethereum a la ZK EVM. Ojo, alguas aplicaciones van a seguir siendo compatibles, pero las chances de que haya cosas que no funcionen son más altas por lo que incluso si no hay que hacer cambios al código o si son cambios mínimos, va a requerir a los protocolos que esten atentos. Algunas aplicaciones si van a tener que ser re escritas casi enteramente.

Tipo 4 (Solidity equivalent)

Este tipo es un poquito más complejo de entender. Son sistemas que no usan la EVM, sino que toman código escrito en un lenguaje de alto nivel como Solidity o Vyper y lo compilan a un lenguaje diseñado para ser ZK-SNARK friendly. Es como si agregasen una capa intermedia para traducir aplicaciones compatibles con la EVM y luego las procesan en un lenguaje diferente que es mucho mejor para ZK.

Las ventajas son las que te imaginarás… tiempos mucho más rápidos, porque no hay que hacer ZK proofs de todos los pasos que da la EVM para ejecutar transacciones.

La desventaja es que hay mucha más incompatibilidad y eso genera muchos riesgos. Varias aplicaciones van a poder “traducirse” sin problema pero hay algunas cositas a las cuales hay que prestar atención:

  • los contratos pueden tener addresses diferentes.
  • algunas apps usa EVM bytecode escrito a mano en algunas partes. Esto puede traerle problemas a una ZK EVM tipo 4.
  • mucha infraestructura no va a funcionar, porque se basa en el EVM bytecode.