La máquina virtual de Ethereum (ETH), creada en 2015, se diseñó para ejecutar contratos inteligentes, no para generar pruebas criptográficas. Las pruebas de conocimiento cero nacieron para verificar cómputos de forma barata y privada, sin saber ni siquiera qué es un opcode.
Durante años, ambos mundos parecían irreconciliables.
Después, los ingenieros lograron conectarlos y el resultado es una de las infraestructuras técnicamente más exigentes de todo el ecosistema cripto.
ZkEVM —siglas de zero-knowledge Ethereum Virtual Machine— es el intento de ejecutar contratos inteligentes compatibles con Ethereum y demostrar después, mediante pruebas ZK, que se han ejecutado correctamente, sin que los desarrolladores tengan que reescribir ni una línea de código.
Sobre el papel suena sencillo. En la práctica, ha supuesto resolver problemas que bloquearon a toda la industria durante medio decenio.
TL;DR
- Una ZkEVM ejecuta contratos inteligentes compatibles con Ethereum y genera una prueba de conocimiento cero de que la ejecución fue correcta, lo que permite liquidar transacciones de forma rápida y barata en la red principal de Ethereum.
- Cuanto más difícil es construir una ZkEVM, más compatible resulta con las herramientas actuales de Ethereum; este equilibrio está en el centro de todas las decisiones de diseño.
- Los usuarios se benefician de las garantías de seguridad de Ethereum sin pagar las comisiones de gas de la red principal, y los desarrolladores pueden desplegar contratos en Solidity existentes con pocas o ninguna modificación.
Qué hacen realmente las pruebas de conocimiento cero
Antes de entrar en la parte EVM, conviene tener claro qué es —y qué no es— una prueba de conocimiento cero. Una prueba ZK es un método criptográfico que permite que una parte, el probador (prover), convenza a otra, el verificador (verifier), de que una afirmación es verdadera sin revelar los datos subyacentes que la respaldan.
El ejemplo clásico es demostrar que conoces una contraseña sin enviarla nunca. En blockchain, la afirmación casi siempre es computacional: “He ejecutado este programa sobre esta entrada y he obtenido esta salida, y lo he hecho correctamente”.
El verificador —en este caso, un contrato inteligente en la Capa 1 de Ethereum— comprueba la prueba en milisegundos, en lugar de volver a ejecutar por sí mismo cada transacción.
Las pruebas de conocimiento cero permiten a una red de Capa 2 agrupar miles de transacciones, generar una única prueba compacta de que todas son válidas y publicar solo esa prueba en Ethereum, reduciendo de forma drástica el coste por usuario.
Hoy, dos familias de pruebas dominan el panorama ZkEVM. Los SNARKs (Succinct Non-interactive ARguments of Knowledge) producen pruebas diminutas que se verifican muy rápido, pero requieren una ceremonia de configuración confiable (trusted setup). Los STARKs (Scalable Transparent ARguments of Knowledge) no necesitan configuración confiable y son resistentes a ataques cuánticos, pero generan pruebas más voluminosas. La mayoría de los equipos ZkEVM se ha decantado, de momento, por sistemas basados en SNARKs porque el coste de verificación en la red principal de Ethereum es un límite duro.
También puede interesarte: Trump Media cancela acuerdo del tesoro Cronos por 6.420 millones de dólares con Crypto.com
Por qué es tan difícil demostrar la EVM
La Máquina Virtual de Ethereum es un entorno de ejecución basado en pila, con más de 140 opcodes, un sistema de gas, una estructura de memoria compleja y una colección de casos límite acumulados en una década de uso real. Cada opcode —desde un simple ADD hasta las precompiladas criptográficas como ECRECOVER— debe poder representarse como una restricción aritmética para que un sistema de pruebas ZK pueda razonar sobre él.
El problema es que los sistemas de prueba ZK hablan un lenguaje matemático muy estrecho: trabajan de forma nativa sobre cuerpos finitos y ecuaciones polinómicas. La EVM se diseñó sin nada de esto en mente. Opcodes como KECCAK256 (la función de hash de Ethereum) son casi lo más hostil posible para los circuitos ZK porque implican operaciones a nivel de bit que se traducen en conjuntos de restricciones enormes y costosos.
Este desajuste dio lugar a lo que los investigadores bautizaron como el “problema de incompatibilidad con la EVM”. Podías construir un rollup ZK rápido y barato, pero solo ejecutaría programas a medida escritos para entornos ZK‑friendly. O podías intentar soportar la EVM completa, a costa de que generar las pruebas fuera tan lento y caro que perdiera todo el sentido. El reto de ingeniería de ZkEVM consiste en colapsar ese compromiso.
Generar una prueba ZK para un único hash KECCAK256 puede requerir millones de restricciones aritméticas. Un bloque típico de Ethereum contiene miles de hashes; por eso las primeras ZkEVM tardaban horas en generar pruebas y aún hoy necesitan hardware especializado.
También puede interesarte: Arthur Hayes anticipa rally de Bitcoin si la Fed libera los 1,373 billones de dólares en bonos de Japón
Los cuatro tipos de ZkEVM y qué significan
No todas las ZkEVM son iguales. El investigador de Ethereum Vitalik Buterin propuso en 2022 una taxonomía, hoy muy citada, que divide las implementaciones en cuatro tipos según su grado de compatibilidad con el stack actual de Ethereum. Entender estos tipos es la forma más rápida de evaluar cualquier proyecto ZkEVM.
Tipo 1: totalmente equivalente a Ethereum. Demuestra exactamente la misma transición de estado, estructura de bloque, funciones de hash, todo, sin modificaciones. Esto permite que los clientes de Ethereum existentes sincronicen de forma nativa y que todas las herramientas funcionen sin cambios. El coste es que generar pruebas es extremadamente lento y caro. Hoy no hay ninguna ZkEVM en producción operando como Tipo 1, aunque varios equipos trabajan en ello.
Tipo 2: equivalente a la EVM. Introduce cambios internos —por ejemplo, sustituir KECCAK por un hash más amigable para ZK en el estado trie— pero mantiene compatibilidad completa con el bytecode EVM. Los contratos se comportan de forma idéntica. Los desarrolladores no perciben cambios. Generar pruebas es más rápido que en Tipo 1, pero sigue siendo pesado. Scroll y las primeras versiones de Polygon zkEVM se sitúan en este rango.
Tipo 3: añade más modificaciones que rompen un número reducido de funcionalidades muy específicas, como ciertas precompiladas. Casi todos los contratos existentes siguen funcionando. El coste de probar baja de forma significativa. La mayoría de ZkEVM comerciales lanzadas en 2023‑2024 arrancaron en un punto intermedio entre Tipo 2 y Tipo 3.
Tipo 4: en lugar de demostrar bytecode EVM directamente, compila el código fuente en Solidity o Vyper hacia una máquina virtual personalizada optimizada para ZK. Es la opción más rápida y barata, pero puede introducir sutiles diferencias de comportamiento y hace inviables algunos trucos de bajo nivel sobre la EVM. zkSync Era apuesta por este modelo con un compilador propio basado en LLVM.
Esta taxonomía es crítica para los desarrolladores. Un proyecto que migra un protocolo DeFi muy probado desde la red principal preferirá Tipo 2 o Tipo 3 para asegurar paridad de comportamiento. Un protocolo nuevo, en cambio, puede aceptar un Tipo 4 a cambio de costes de prueba más bajos y finalización más rápida.
También puede interesarte: Anthropic asegura 191 megavatios de energía en Texas de un minero de Bitcoin
Cómo procesa realmente una transacción una ZkEVM
Seguir una transacción de extremo a extremo ayuda a visualizar la arquitectura. Cuando un usuario envía una operación a una red ZkEVM, sucede lo siguiente:
Primero, la transacción llega a un secuenciador, el nodo encargado de ordenar y agrupar operaciones en lotes (batches). El secuenciador ejecuta las transacciones, actualiza el estado de la Capa 2 y ofrece al usuario una “confirmación blanda” casi inmediata. A estas alturas, el monedero del usuario ya refleja el cambio de saldo, pero la transacción aún no está finalizada criptográficamente en Ethereum.
Segundo, el lote de transacciones pasa a un probador (prover), un software (o hardware) especializado que ejecuta el algoritmo de pruebas ZK. El probador toma el estado previo, todas las transacciones y el estado resultante, y genera una prueba de validez que certifica que la transición de estado se ha calculado correctamente. Este paso es muy intensivo en cómputo y puede tardar desde segundos hasta varios minutos, según el sistema.
Tercero, la prueba y una pequeña cantidad de datos de transacción comprimidos se envían a un contrato inteligente en Ethereum, el contrato verificador.
Este contrato comprueba la prueba en una única llamada on‑chain, con un coste de gas prácticamente fijo, independientemente del número de transacciones incluidas en el lote. Una vez verificada, la raíz de estado de la Capa 2 queda finalizada en Ethereum y se considera tan segura como cualquier transacción en la red principal.
También puede interesarte: Un ETF de XRP aparece en la revelación del fondo cripto de 111.000 dólares del National Bank of Canada
ZkEVM modular e interoperabilidad entre cadenas
El diseño original de ZkEVM asumía una única capa de liquidación: Ethereum. Todo se probaba y todo se asentaba en la red principal. Una arquitectura más reciente, el ZkEVM modular, separa la capa de ejecución, la capa de pruebas y la capa de liquidación para que puedan componerse de forma independiente.
Aquí entran proyectos como Prom.
Prom se define como una ZkEVM modular de Capa 2 que permite la interoperabilidad tanto entre cadenas EVM como no EVM. En lugar de demostrar la ejecución y liquidar solo en Ethereum, envía pruebas a varias cadenas de forma simultánea, creando un puente matemático entre ecosistemas que antes carecían de conexión trustless.
El enfoque modular es relevante porque rompe la idea de que Ethereum sea la única superficie válida de liquidación.
Una prueba ZkEVM, al final, es solo matemática. Si la Cadena A y la Cadena B tienen contratos verificadores capaces de comprobar esa matemática, una única prueba puede finalizar una transición de estado en ambas cadenas a la vez. Así es como las pruebas ZK pasan de ser únicamente una técnica de escalado a convertirse en un primitivo universal de interoperabilidad.
Las arquitecturas ZkEVM modulares desacoplan ejecución y liquidación: una misma prueba de validez puede verificarse en Ethereum, en una cadena no EVM o en ambas, generando una fuente compartida de verdad criptográfica entre ecosistemas que, de otro modo, serían incompatibles.
También puede interesarte: TRON movió 2,1 billones de dólares en USDT, pero su liquidez DeFi se redujo 1,9 %
ZkEVM frente a Optimistic Rollups, cara a cara
La comparación entre ZkEVM y los optimistic rollups aparece constantemente, y con razón: ambos atacan el mismo problema con filosofías opuestas.
Los optimistic rollups asumen que las transacciones son válidas por defecto y solo las verifican si alguien presenta una prueba de fraude dentro de una ventana de disputa (normalmente, siete días). Esto abarata su operación y simplifica su desarrollo, pero implica que las retiradas hacia la red principal de Ethereum tarden una semana, salvo que se recurra a un puente de liquidez. Arbitrum y Optimism son hoy las dos redes de optimistic rollups dominantes.
Los rollups ZkEVM no dan nada por hecho: cada lote se considera inválido hasta que una prueba demuestre lo contrario. Esto implica mayor coste computacional en el lado del “prover”, pero permite que las retiradas se consoliden en Ethereum en cuestión de horas, en lugar de días, sin depender de observadores honestos que detecten fraude.
En la práctica, para el usuario las diferencias se resumen así:
- Velocidad de retirada: ZkEVM se impone con claridad: la finalidad basada en pruebas se alcanza en horas, frente a los siete días de las retiradas nativas en optimistic rollups.
- Coste por transacción: hoy, los optimistic rollups suelen ser más baratos porque la generación de pruebas añade coste. Esta brecha se está cerrando a medida que mejoran el hardware y los algoritmos de prueba.
- Modelo de seguridad: ZkEVM ofrece garantías de validez criptográfica. Los optimistic rollups ofrecen seguridad económica vía pruebas de fraude: robusta, pero no equivalente a un respaldo matemático estricto.
- Compatibilidad EVM: los ZkEVM modernos (Tipo 2/3) han reducido casi por completo la distancia y ya soportan prácticamente todo el stack de herramientas de Ethereum, eliminando lo que fue durante años una ventaja clave de los optimistic rollups.
- Riesgo de liveness: los sistemas ZkEVM pueden detenerse si falla el “prover”. Los optimistic rollups siguen procesando mientras el secuenciador esté operativo.
Ningún enfoque es superior en términos absolutos. Las aplicaciones de gran volumen que priorizan el coste mínimo y pueden convivir con una ventana de retirada de una semana tienden hacia los optimistic rollups. Las que necesitan finalidad rápida, liquidación entre cadenas o pruebas matemáticas de corrección se inclinan hacia ZkEVM.
También te puede interesar: Las acciones de CoreWeave se disparan un 11 % tras duplicar ingresos del 2T gracias a la IA
Quién se está beneficiando realmente de ZkEVM ahora mismo
ZkEVM no es una promesa futurista: ya hay varias redes en producción con valor bloqueado real y usuarios pagando comisiones. Aun así, conviene entender quién gana más en cada capa del stack.
Los protocolos DeFi que migran desde la red principal de Ethereum se benefician de una semántica de ejecución casi idéntica (Tipo 2/3) y unos costes de gas drásticamente más bajos. Un protocolo que expulsaba al inversor minorista con comisiones de 30 dólares por swap en mainnet puede ofrecer transacciones por debajo del céntimo en un ZkEVM sin reescribir sus smart contracts.
Los puentes y aplicaciones entre cadenas se benefician de arquitecturas ZkEVM modulares que publican pruebas en múltiples redes. En vez de depender de un puente multisig —históricamente, la categoría más atacada en cripto— los usuarios pueden apoyarse en una prueba matemática verificada on‑chain.
Las empresas e instituciones que desarrollan aplicaciones permissionadas o semipermissionadas obtienen un entorno de ejecución probado, con auditabilidad criptográfica. Cada transición de estado es demostrablemente correcta, algo clave para cumplimiento normativo y contabilidad.
Los desarrolladores que empiezan proyectos hoy deben entender el compromiso entre un ZkEVM Tipo 4 y uno Tipo 2 antes de elegir red. Si escribes contratos en Solidity desde cero y buscas máxima velocidad de prueba y comisiones mínimas, una red Tipo 4 puede encajar mejor. Si estás migrando un protocolo existente y no puedes asumir diferencias de comportamiento, una red Tipo 2 o Tipo 3 es la opción más prudente.
Para el usuario de a pie, ZkEVM se percibe sobre todo como una cadena barata, rápida y compatible con Ethereum, donde su wallet habitual funciona y sus tokens se pueden puentear sin fricción. La maquinaria criptográfica que hay debajo es invisible, que es precisamente como debe ser una buena infraestructura.
También te puede interesar: Monad marca récord de TVL con 868 millones de dólares, pero la demanda de MON sigue floja
Conclusión
ZkEVM es hoy el problema de convergencia más complejo de la criptografía aplicada: tomar una máquina virtual diseñada sin estructura matemática y obligarla a hablar el lenguaje de las pruebas de conocimiento cero.
Los equipos que lo han llevado a producción han pasado años lidiando con incompatibilidades de funciones hash, explosión de restricciones y hardware de prueba que ni siquiera existía cuando se publicaron los papers originales.
El sector sigue avanzando a gran velocidad. Los tiempos de generación de pruebas se reducen de forma constante. Las redes descentralizadas de “provers” empiezan a desplegarse. La equivalencia total con Ethereum de Tipo 1 sigue siendo un objetivo, y varios equipos están cada vez más cerca.
Para cualquiera que construya sobre el ecosistema de Ethereum —o invierta en él— entender cómo funciona realmente ZkEVM, más allá de los eslóganes de marketing, es la base sobre la que se deben tomar todas las decisiones posteriores.
Lee a continuación: La ofensiva de 500.000 millones de dólares de Nvidia en financiación de IA pone en el radar a los tokens de cómputo cripto
