Ethereum se prepara para la mayor actualización de su historia: EVM será retirada y RISC-V tomará el control

Título original: Goodbye EVM, Hello RISC-V

Autor original: jaehaerys.eth, investigador cripto

Traducción original: TechFlow

Resumen

Ethereum se prepara para la transformación arquitectónica más importante desde su creación: reemplazar la EVM por RISC-V.

La razón es simple: en un futuro centrado en Zero Knowledge (ZK), la EVM se ha convertido en un cuello de botella de rendimiento:

· Actualmente, zkEVM depende de un intérprete, lo que provoca una ralentización de entre 50 y 800 veces;

· Los módulos precompilados complican el protocolo y aumentan los riesgos;

· El diseño de stack de 256 bits es sumamente ineficiente al generar pruebas.

Soluciones de RISC-V:

· Diseño minimalista (aprox. 47 instrucciones básicas) + ecosistema maduro de LLVM (compatible con Rust, C++, Go, etc.);

· Se ha convertido en el estándar de facto para zkVM (adoptado por el 90% de los proyectos);

· Cuenta con una especificación formal SAIL (a diferencia del ambiguo Yellow Paper) → permite verificación estricta;

· Camino de pruebas en hardware (ASICs/FPGAs) ya en pruebas (SP1, Nervos, Cartesi, etc.).

El proceso de migración consta de tres etapas:

· Reemplazar módulos precompilados por RISC-V (pruebas de bajo riesgo);

· Era de doble VM: EVM y RISC-V coexisten e interoperan completamente;

· Reimplementar la EVM dentro de RISC-V (estrategia Rosetta).

Impacto en el ecosistema:

· Los Rollups optimistas (como Arbitrum y Optimism) deberán reconstruir su mecanismo de pruebas de fraude;

· Los Rollups de Zero Knowledge (como Polygon, zkSync, Scroll) obtendrán enormes ventajas → más baratos, rápidos y simples;

· Los desarrolladores podrán usar directamente librerías en Rust, Go y Python en la capa L1;

· Los usuarios disfrutarán de pruebas unas 100 veces más baratas → camino hacia un Gigagas L1 (aprox. 10,000 TPS).

Finalmente, Ethereum evolucionará de una “máquina virtual de contratos inteligentes” a una capa de confianza minimalista y verificable para Internet, cuyo objetivo final es “ZK-Snarkificar todo”.

La encrucijada de Ethereum

Vitalik Buterin dijo una vez: “El objetivo final es... ZK-Snarkificar todo”.

El destino de las pruebas de Zero Knowledge (ZK) es inevitable, y el argumento central es simple: Ethereum se está reconstruyendo desde cero sobre la base de las pruebas ZK. Esto marca el destino técnico del protocolo: alcanzar su forma final mediante la reconstrucción de L1, impulsado por un zkVM de alto rendimiento respaldado por equipos de desarrollo centrales como Succinct.

Con esta visión como meta, Ethereum se encuentra en el umbral de la transformación arquitectónica más importante desde su nacimiento. Ya no se trata de actualizaciones graduales, sino de una reconstrucción total de su núcleo computacional: reemplazar la Ethereum Virtual Machine (EVM). Esta medida es la piedra angular de la visión más amplia de “Lean Ethereum”.

La visión de Lean Ethereum busca simplificar sistemáticamente todo el protocolo, dividiéndolo en tres módulos principales: Lean Consensus, Lean Data y Lean Execution. En el núcleo de Lean Execution, la cuestión clave es: ¿la EVM, motor de la revolución de los contratos inteligentes, se ha convertido en el principal cuello de botella para el futuro de Ethereum?

Como señala Justin Drake de la Ethereum Foundation, el objetivo a largo plazo de Ethereum siempre ha sido “Snarkificar todo”, una herramienta poderosa para fortalecer todas las capas del protocolo. Sin embargo, durante mucho tiempo, este objetivo parecía un “plan lejano”, ya que requería el concepto de pruebas en tiempo real. Ahora que las pruebas en tiempo real están cerca de ser realidad, la ineficiencia teórica de la EVM se ha convertido en un problema práctico urgente.

Este artículo analiza en profundidad los argumentos técnicos y estratégicos para migrar Ethereum L1 a la arquitectura de conjunto de instrucciones (ISA) RISC-V. Esta medida no solo promete una escalabilidad sin precedentes, sino que también simplificará la estructura del protocolo y alineará a Ethereum con el futuro de la computación verificable.

¿Qué ha cambiado realmente?

Antes de explorar el “por qué”, primero debemos aclarar el “qué” está cambiando.

La EVM (Ethereum Virtual Machine) es el entorno de ejecución de los contratos inteligentes de Ethereum, conocida como la “computadora mundial” que procesa transacciones y actualiza el estado de la blockchain. Durante años, su diseño fue revolucionario y sentó las bases para el nacimiento de DeFi y los NFT. Sin embargo, esta arquitectura personalizada de casi una década ha acumulado una gran deuda técnica.

En contraste, RISC-V no es un producto, sino un estándar abierto: un “alfabeto” de diseño de procesadores gratuito y general. Como enfatizó Jeremy Bruestle en la conferencia Ethproofs, sus principios clave lo hacen ideal para este rol:

· Minimalismo: El conjunto de instrucciones básico de RISC-V es extremadamente simple, con solo 40 a 47 instrucciones. Como dice Jeremy, esto lo hace “casi perfecto para el caso de uso de una máquina universal superminimalista que necesitamos”.

· Diseño modular: Las funciones más complejas se agregan mediante extensiones opcionales. Esto es crucial porque permite que el núcleo permanezca simple, mientras que las funciones se expanden según sea necesario, sin imponer complejidad innecesaria al protocolo base.

· Ecosistema abierto: RISC-V cuenta con una enorme y madura cadena de herramientas, incluido el compilador LLVM, que permite a los desarrolladores usar lenguajes populares como Rust, C++ y Go. Como menciona Justin Drake: “Las herramientas alrededor de los compiladores son muy ricas, y construir compiladores es extremadamente difícil... así que tener estas cadenas de herramientas es de un valor incalculable”. RISC-V permite que Ethereum herede estas herramientas listas para usar de forma gratuita.

El problema del overhead del intérprete

El impulso para reemplazar la EVM no se debe a un solo defecto, sino a la convergencia de varias limitaciones fundamentales, problemas que en un futuro centrado en Zero Knowledge ya no pueden ser ignorados. Estas limitaciones incluyen cuellos de botella de rendimiento en los sistemas de pruebas ZK y el riesgo creciente derivado de la complejidad interna del protocolo.

El motor más urgente de esta transformación es la ineficiencia inherente de la EVM en los sistemas de pruebas ZK. A medida que Ethereum avanza hacia un modelo en el que el estado de L1 se verifica mediante pruebas ZK, el rendimiento de los probadores se convierte en el mayor cuello de botella.

El problema radica en cómo funcionan actualmente las zkEVM. No prueban directamente la EVM, sino el intérprete de la EVM, que a su vez se compila a RISC-V. Vitalik Buterin señala sin rodeos este problema central:

“...si la implementación de la zkVM es compilar la ejecución de la EVM en algo que finalmente se convierte en código RISC-V, ¿por qué no exponer directamente el RISC-V subyacente a los desarrolladores de contratos inteligentes? Así se elimina por completo el overhead de la VM externa”.

Esta capa adicional de interpretación genera una enorme pérdida de rendimiento. Se estima que, en comparación con probar programas nativos, esta capa puede provocar una caída de rendimiento de entre 50 y 800 veces. Incluso optimizando otros cuellos de botella (como cambiar al algoritmo de hash Poseidon), esta parte de la “ejecución de bloques” sigue ocupando entre el 80% y el 90% del tiempo de prueba, convirtiendo a la EVM en el obstáculo final y más difícil para escalar L1. Al eliminar esta capa, Vitalik espera que la eficiencia de ejecución aumente 100 veces.

La trampa de la deuda técnica

Para compensar la falta de rendimiento de la EVM en operaciones criptográficas específicas, Ethereum introdujo contratos precompilados: funciones especializadas codificadas directamente en el protocolo. Aunque esta solución fue pragmática en su momento, hoy genera lo que Vitalik Buterin llama una situación “desastrosa”:

“Las precompiladas han sido desastrosas para nosotros... han inflado enormemente la base de código confiable de Ethereum... y han causado problemas graves que casi resultan en fallos de consenso”.

La complejidad es asombrosa. Vitalik ejemplifica que el código wrapper de una sola precompilada (como modexp) es más complejo que todo el intérprete RISC-V, y la lógica de la precompilada es aún más engorrosa. Agregar nuevas precompiladas requiere un proceso de hard fork lento y políticamente controvertido, lo que frena la innovación en aplicaciones que necesitan nuevos primitivos criptográficos. Vitalik concluye:

“Creo que deberíamos dejar de agregar nuevas precompiladas desde hoy”.

La deuda técnica arquitectónica de Ethereum

El diseño central de la EVM refleja prioridades de otra época, pero ya no es adecuado para las necesidades computacionales modernas. La EVM eligió una arquitectura de 256 bits para manejar valores criptográficos, pero para los enteros de 32 o 64 bits que suelen usarse en contratos inteligentes, esta arquitectura es sumamente ineficiente. Esta ineficiencia es especialmente costosa en sistemas ZK. Como explica Vitalik:

“Cuando se usan números más pequeños, en realidad no se ahorran recursos, pero la complejidad aumenta de dos a cuatro veces”.

Además, la arquitectura de stack de la EVM es menos eficiente que la arquitectura de registros de RISC-V y CPUs modernas. Requiere más instrucciones para realizar la misma operación y complica la optimización del compilador.

Estos problemas —el cuello de botella de rendimiento en pruebas ZK, la complejidad de las precompiladas y las elecciones arquitectónicas obsoletas— constituyen razones convincentes y urgentes: Ethereum debe superar la EVM y adoptar una arquitectura más adecuada para el futuro.

El plan RISC-V: remodelando el futuro de Ethereum sobre bases más sólidas

Las ventajas de RISC-V no solo radican en las deficiencias de la EVM, sino en la fortaleza inherente de su filosofía de diseño. Su arquitectura ofrece una base robusta, simple y verificable, ideal para entornos de alto riesgo como Ethereum.

¿Por qué un estándar abierto es mejor que un diseño personalizado?

A diferencia de las arquitecturas de instrucciones personalizadas, que requieren construir todo el ecosistema de software desde cero, RISC-V es un estándar abierto y maduro con tres ventajas clave:

Ecosistema maduro

Al adoptar RISC-V, Ethereum puede aprovechar décadas de avances colectivos en ciencias de la computación. Como explica Justin Drake, esto le da a Ethereum acceso directo a herramientas de clase mundial:

“Hay un componente de infraestructura llamado LLVM, una cadena de herramientas de compiladores que permite compilar lenguajes de alto nivel a varios backends. Uno de esos backends es RISC-V. Así que si soportás RISC-V, automáticamente soportás todos los lenguajes de alto nivel soportados por LLVM”.

Esto reduce enormemente la barrera de entrada, permitiendo que millones de desarrolladores familiarizados con Rust, C++ y Go puedan sumarse fácilmente.

Filosofía de diseño minimalista El minimalismo de RISC-V es una característica deliberada, no una limitación. Su conjunto básico de instrucciones tiene solo unas 47, manteniendo el núcleo de la VM extremadamente simple. Esta simplicidad tiene ventajas de seguridad notables, ya que una base de código confiable más pequeña es más fácil de auditar y formalizar.

Estándar de facto en el ámbito Zero Knowledge Más importante aún, el ecosistema zkVM ya ha hecho su elección. Como señala Justin Drake, los datos de Ethproofs muestran una tendencia clara:

“RISC-V es la arquitectura líder de instrucciones (ISA) para el backend de zkVM”.

De los diez zkVM capaces de probar bloques de Ethereum, nueve han elegido RISC-V como arquitectura objetivo. Esta convergencia de mercado envía una señal poderosa: al adoptar RISC-V, Ethereum no está haciendo una apuesta especulativa, sino alineándose con un estándar ya validado y adoptado por proyectos que construyen el futuro ZK.

Nacido para la confianza, no solo para la ejecución

Además de su amplio ecosistema, la arquitectura interna de RISC-V es especialmente adecuada para construir sistemas seguros y verificables. Primero, RISC-V cuenta con una especificación formal y legible por máquina: SAIL. Esto representa un gran avance respecto a la especificación de la EVM (principalmente en el Yellow Paper), que es ambigua. SAIL proporciona un “estándar de oro” que permite pruebas matemáticas de corrección, crucial para proteger protocolos de alto valor. Como menciona Alex Hicks de la Ethereum Foundation en Ethproofs, esto permite que los circuitos zkVM se verifiquen directamente contra la especificación oficial de RISC-V. Además, RISC-V incluye una arquitectura privilegiada, una característica a menudo ignorada pero esencial para la seguridad. Define diferentes niveles operativos, principalmente el modo usuario (para aplicaciones no confiables como contratos inteligentes) y el modo supervisor (para el “núcleo de ejecución” confiable). Diego de Cartesi lo explica en detalle:

“El sistema operativo debe protegerse de otros códigos. Necesita aislar la ejecución de diferentes programas, y todos estos mecanismos son parte del estándar RISC-V”.

En la arquitectura RISC-V, los contratos inteligentes que corren en modo usuario no pueden acceder directamente al estado de la blockchain. En cambio, deben enviar una solicitud mediante la instrucción ECALL al núcleo confiable que corre en modo supervisor. Este mecanismo crea una barrera de seguridad reforzada por hardware, mucho más robusta y verificable que el modelo de sandboxing puramente software de la EVM.

La visión de Vitalik

Esta transformación está concebida como un proceso gradual y por etapas, para garantizar la estabilidad del sistema y la compatibilidad hacia atrás. Como explica el fundador de Ethereum, Vitalik Buterin, este enfoque busca una evolución “evolutiva” en lugar de una revolución total.

Primer paso: reemplazo de precompiladas

La etapa inicial adopta el enfoque más conservador, introduciendo capacidades limitadas de la nueva VM. Como sugiere Vitalik Buterin: “Podemos empezar usando la nueva VM en escenarios limitados, como reemplazo de funciones precompiladas”. Específicamente, esto pausará la adición de nuevas precompiladas EVM, reemplazándolas por programas RISC-V aprobados por whitelist. Este método permite probar la nueva VM en mainnet en un entorno de bajo riesgo, mientras los clientes de Ethereum actúan como intermediarios entre ambos entornos de ejecución.

Segundo paso: coexistencia de doble VM

La siguiente etapa “abre la nueva VM directamente a los usuarios”. Los contratos inteligentes pueden marcar su bytecode como EVM o RISC-V. La clave es la interoperabilidad sin fisuras: “ambos tipos de contratos pueden llamarse entre sí”. Esta función se implementará mediante llamadas de sistema (ECALL), permitiendo que ambas VMs colaboren en el mismo ecosistema.

Tercer paso: EVM como contrato simulado (estrategia “Rosetta”)

El objetivo final es la máxima simplificación del protocolo. En esta etapa, “la EVM se implementa como una aplicación dentro de la nueva VM”. La EVM estandarizada se convertirá en un contrato inteligente formalmente verificado corriendo sobre RISC-V nativo en L1. Esto asegura soporte permanente para aplicaciones antiguas y permite a los desarrolladores de clientes mantener solo un motor de ejecución simplificado, reduciendo la complejidad y el costo de mantenimiento.

El efecto dominó en el ecosistema

La transición de EVM a RISC-V no solo transforma el protocolo central, sino que tendrá un profundo impacto en todo el ecosistema de Ethereum. Esta transformación remodelará la experiencia del desarrollador, cambiará radicalmente la competencia entre soluciones Layer-2 y desbloqueará nuevos modelos de validación económica.

Reubicación de los Rollups: Optimistic vs ZK

Adoptar RISC-V como capa de ejecución en L1 tendrá efectos muy diferentes sobre los dos principales tipos de Rollup.

Los Optimistic Rollup (como Arbitrum y Optimism) enfrentan desafíos arquitectónicos. Su modelo de seguridad depende de reejecutar transacciones disputadas en la EVM de L1 para resolver pruebas de fraude. Si la EVM de L1 se reemplaza, este modelo colapsa. Estos proyectos deberán elegir entre una gran reingeniería para diseñar un sistema de pruebas de fraude para la nueva VM de L1, o abandonar por completo el modelo de seguridad de Ethereum.

En cambio, los ZK Rollup obtendrán una ventaja estratégica enorme. La gran mayoría ya usa RISC-V como su arquitectura interna de instrucciones (ISA). Un L1 que “hable el mismo idioma” permitirá una integración mucho más estrecha y eficiente. Justin Drake propone la visión de “Rollups nativos”: L2 se convierte en una instancia especializada del entorno de ejecución de L1, usando la VM nativa para liquidaciones sin fricción. Esto traerá los siguientes cambios:

· Simplificación del stack tecnológico: Los equipos de L2 ya no necesitarán construir puentes complejos entre su entorno RISC-V interno y la EVM.

· Reutilización de herramientas y código: Compiladores, depuradores y herramientas de verificación formal desarrolladas para RISC-V en L1 podrán ser usados directamente por L2, reduciendo drásticamente los costos de desarrollo.

· Alineación de incentivos económicos: Las tarifas de gas de L1 reflejarán con mayor precisión el costo real de la verificación ZK basada en RISC-V, creando un modelo económico más racional.

Una nueva era para desarrolladores y usuarios

Para los desarrolladores de Ethereum, esta transformación será gradual, no disruptiva.

Los desarrolladores accederán a un ecosistema de desarrollo de software más amplio y maduro. Como señala Vitalik Buterin, podrán “escribir contratos en Rust, y estas opciones podrán coexistir”. Al mismo tiempo, predice que “Solidity y Vyper seguirán siendo populares por su elegancia en la lógica de contratos inteligentes”. Usar el toolchain LLVM y las vastas librerías de lenguajes mainstream será revolucionario. Vitalik lo compara con una “experiencia tipo NodeJS”, donde los desarrolladores pueden escribir código on-chain y off-chain en el mismo lenguaje, unificando el desarrollo.

Para los usuarios, esta transformación traerá costos mucho más bajos y mejor rendimiento. Se espera que el costo de las pruebas baje unas 100 veces, de varios dólares por transacción a unos pocos centavos o menos. Esto se traduce en tarifas L1 y de liquidación L2 mucho más bajas. Esta viabilidad económica desbloqueará la visión de un “Gigagas L1”, con un objetivo de unos 10,000 TPS, allanando el camino para aplicaciones on-chain más complejas y valiosas.

Succinct Labs y SP1: construyendo el futuro de las pruebas hoy

Ethereum está listo para despegar. “Escalar L1, escalar el bloque” es una tarea estratégica urgente dentro del cluster de protocolos de la EF. Se espera una mejora significativa en el rendimiento en los próximos 6 a 12 meses.

Equipos como Succinct Labs ya han demostrado en la práctica las ventajas teóricas de RISC-V, validando la viabilidad de esta propuesta.

SP1, desarrollado por Succinct Labs, es un zkVM de alto rendimiento y código abierto basado en RISC-V, que valida la nueva aproximación arquitectónica. SP1 adopta una filosofía “precompile-centric”, resolviendo perfectamente el cuello de botella criptográfico de la EVM. En lugar de depender de precompiladas lentas y hardcodeadas, SP1 descarga operaciones intensivas como el hash Keccak a circuitos ZK especialmente diseñados y optimizados, invocados mediante instrucciones ECALL estándar. Este método combina el rendimiento del hardware personalizado con la flexibilidad del software, ofreciendo a los desarrolladores una solución más eficiente y escalable.

El impacto real de Succinct Labs ya es visible. Su producto OP Succinct utiliza SP1 para dotar de pruebas ZK a los Optimistic Rollups (ZK-ify). Como explica Uma Roy, cofundadora de Succinct:

“Con los Rollups que usan OP Stack, ya no hay que esperar siete días para la confirmación final y el retiro... ahora la confirmación se logra en solo una hora. Esta mejora de velocidad es increíble”.

Este avance resuelve un punto crítico en todo el ecosistema OP Stack. Además, la infraestructura de Succinct —Succinct Prover Network— está diseñada como un mercado descentralizado de generación de pruebas, mostrando un modelo económico viable para la computación verificable del futuro. Su trabajo no es solo una prueba de concepto, sino un plan de acción realista para el futuro, como se describe en este artículo.

Cómo Ethereum reduce riesgos

Una gran ventaja de RISC-V es que hace alcanzable el “santo grial” de la verificación formal: probar matemáticamente la corrección del sistema. La especificación de la EVM está escrita en lenguaje natural en el Yellow Paper, lo que dificulta la formalización. RISC-V, en cambio, tiene una especificación SAIL oficial y legible por máquina, que sirve como “referencia dorada” para su comportamiento.

Esto allana el camino para una mayor seguridad. Como señala Alex Hicks de la Ethereum Foundation, ya se está trabajando en “verificar formalmente los circuitos zkVM RISC-V contra la especificación oficial de RISC-V extraída a Lean”. Este es un avance histórico, que traslada la confianza de implementaciones humanas propensas a errores a pruebas matemáticas verificables, abriendo nuevas fronteras para la seguridad blockchain.

Principales riesgos de la transformación

Aunque L1 sobre RISC-V tiene muchas ventajas, también introduce nuevos desafíos complejos.

Problema de medición de Gas

Crear un modelo de Gas determinista y justo para una arquitectura de instrucciones general (ISA) es un reto aún no resuelto. Contar instrucciones simples es vulnerable a ataques de denegación de servicio. Por ejemplo, un atacante podría diseñar un programa que provoque repetidos fallos de caché, consumiendo muchos recursos a bajo costo de Gas. Esto desafía la estabilidad de la red y el modelo económico.

Seguridad de la toolchain y problema de “builds reproducibles”

Este es el riesgo más importante y subestimado del proceso de transformación. El modelo de seguridad pasa de depender de la VM on-chain a depender de compiladores off-chain (como LLVM), que son muy complejos y tienen vulnerabilidades conocidas. Un atacante podría explotar un bug del compilador para convertir código fuente aparentemente benigno en bytecode malicioso. Además, garantizar que el binario on-chain compilado coincida exactamente con el código fuente público (“build reproducible”) es muy difícil. Pequeñas diferencias en el entorno de compilación pueden producir binarios distintos, afectando la transparencia y la confianza. Estos problemas desafían la seguridad de desarrolladores y usuarios.

Estrategias de mitigación

El camino a seguir requiere defensas en múltiples capas.

Despliegue por etapas

Adoptar un plan de transición gradual y por etapas es clave para mitigar riesgos. Al introducir primero RISC-V como reemplazo de precompiladas y luego operar en un entorno de doble VM, la comunidad puede ganar experiencia y confianza en un entorno de bajo riesgo, evitando cambios irreversibles. Este enfoque progresivo proporciona una base estable para la transformación técnica.

Auditoría exhaustiva: fuzzing y verificación formal

Aunque la verificación formal es el objetivo final, debe combinarse con pruebas continuas e intensivas. Como mostró Valentine de Diligence Security en la llamada de Ethproofs, su herramienta Argus de fuzzing ya ha encontrado 11 vulnerabilidades críticas de solidez e integridad en zkVMs líderes. Esto demuestra que incluso los sistemas mejor diseñados pueden tener fallos que solo se detectan con pruebas adversariales rigurosas. La combinación de fuzzing y verificación formal refuerza la seguridad del sistema.

Estandarización

Para evitar la fragmentación del ecosistema, la comunidad debe adoptar una configuración única y estandarizada de RISC-V. Probablemente sea la combinación RV64GC con ABI compatible con Linux, ya que tiene el mayor soporte en lenguajes y herramientas mainstream, maximizando las ventajas del nuevo ecosistema. La estandarización no solo mejora la eficiencia del desarrollador, sino que sienta las bases para el desarrollo a largo plazo del ecosistema.

El futuro verificable de Ethereum

La propuesta de reemplazar la EVM por RISC-V no es una simple actualización incremental, sino una reconstrucción fundamental de la capa de ejecución de Ethereum. Esta ambiciosa visión busca resolver cuellos de botella de escalabilidad, simplificar la complejidad del protocolo y alinear la plataforma con el ecosistema más amplio de la computación general. Aunque la transformación enfrenta enormes desafíos técnicos y sociales, sus beneficios estratégicos a largo plazo justifican este esfuerzo audaz.

Esta transformación implica una serie de compensaciones clave:

· Equilibrio entre el enorme aumento de rendimiento de una arquitectura ZK nativa y la necesidad urgente de compatibilidad hacia atrás;

· Compensación entre la seguridad que aporta la simplificación del protocolo y la inercia de la vasta red de la EVM;

· Elección entre el poder de un ecosistema generalista y el riesgo de depender de toolchains de terceros complejos.

En última instancia, esta transformación arquitectónica será clave para cumplir la promesa de “Lean Execution” y es parte fundamental de la visión de “Lean Ethereum”. Convertirá la L1 de Ethereum de una simple plataforma de contratos inteligentes en una capa eficiente y segura de liquidación y disponibilidad de datos, diseñada para soportar el vasto universo de la computación verificable.

Como dice Vitalik Buterin, “el objetivo final es... ZK-snarkificar todo”.

Proyectos como Ethproofs aportan datos objetivos y plataformas de colaboración para esta transformación, mientras que el equipo de Succinct Labs, con la aplicación real de su SP1 zkVM, ofrece un plan de acción concreto para este futuro. Al adoptar RISC-V, Ethereum no solo resuelve su cuello de botella de escalabilidad, sino que se posiciona como la capa de confianza fundamental de la próxima generación de Internet, impulsada por el tercer gran primitivo criptográfico después del hash y la firma: el SNARK.

Demostrar el software del mundo, inaugura una nueva era cripto.

Más información: