La evolución del protocolo Ethereum a través de la degradación: la estrategia de simplificación de Vitalik Buterin

El 18 de enero, Vitalik Buterin publicó en la plataforma X un artículo en el que planteaba los problemas fundamentales del protocolo de Ethereum. La afirmación es que, por muy avanzada que sea una diseño técnicamente superior, una complejidad excesiva puede impedir que se mantengan los principios básicos de confiabilidad, autonomía y seguridad. Esta declaración, reportada por PANews, plantea una cuestión importante sobre la dirección de desarrollo de Ethereum.

La complejidad del protocolo de Ethereum: ¿por qué es necesaria la simplificación?

Vitalik Buterin enfatizó que “la confianza cero”, “la omisión de pruebas” y “la soberanía personal” son las tres características clave del protocolo. Sin embargo, actualmente Ethereum enfrenta dificultades para mantener estos principios fundamentales.

Con decenas de miles de nodos operando, una tasa de tolerancia a fallos bizantinos del 49%, y todos los nodos verificando mediante tecnologías criptográficas resistentes a la computación cuántica como PeerD and Stark, el problema radica en la complejidad. Si la estructura es un entramado de decenas de miles de líneas de código y criptografía de nivel doctoral, al final fallará en las pruebas de confiabilidad.

Depender de un pequeño grupo de expertos para los usuarios amenaza la verdadera naturaleza de un sistema sin confianza (trustless). Además, surge el problema de la “prueba de rotación”, donde si el equipo de desarrollo principal cambia, resulta difícil mantener un nivel de calidad equivalente. Incluso los mejores desarrolladores no pueden comprender y gestionar completamente estructuras excesivamente complejas.

El ciclo vicioso de la sobreabundancia del protocolo: añadir vs modificar

El problema más fundamental en el desarrollo de Ethereum radica en el proceso de añadir funciones. Al agregar nuevas funcionalidades rápidamente para satisfacer requisitos específicos, el protocolo se vuelve cada vez más complejo, incorporando nuevos elementos de interacción o tecnologías criptográficas avanzadas como dependencias centrales.

A corto plazo, esto ayuda a ampliar las capacidades, pero a largo plazo socava la autonomía y dificulta la construcción de una estructura verdaderamente descentralizada que pueda perdurar siglos. La raíz del problema es que, debido al deseo de mantener la compatibilidad hacia atrás, las modificaciones al código son mucho menores en número que las adiciones. Con el tiempo, el protocolo inevitablemente se volverá más grande y complejo.

Tres estrategias para la recolección de basura (garbage collection)

Vitalik propuso que para resolver este problema, el proceso de desarrollo de Ethereum necesita una función clara de “simplificación” o “recolección de basura”.

Tres criterios para la simplificación:

Primero, minimizar la cantidad total de líneas de código del protocolo. Segundo, eliminar dependencias innecesarias en componentes tecnológicos fundamentalmente complejos. Tercero, agregar más propiedades inmutables para definir claramente las características confiables del protocolo.

Por ejemplo, EIP-6780 eliminó la función de autodestrucción y limitó a un máximo de N los slots de almacenamiento que pueden cambiarse por bloque, simplificando significativamente el desarrollo del cliente.

La recolección de basura puede realizarse de dos maneras:

Un enfoque parcial consiste en rediseñar funciones existentes de forma concisa y lógica. Un ejemplo de un enfoque completo es la migración total del mecanismo de prueba de trabajo (PoW) a prueba de participación (PoS), como en la actualización “The Merge”.

Gestión de compatibilidad con versiones anteriores mediante retroceso

Una estrategia más innovadora es la “compatibilidad hacia abajo estilo Rosetta”. Este método elimina funciones complejas y poco utilizadas del núcleo del protocolo y las downgrada a código de contratos inteligentes. Así, los nuevos desarrolladores de clientes no necesitan gestionar estas funciones directamente.

Por ejemplo, tras una actualización completa con la abstracción de cuentas nativas, ya no será obligatorio tratar todos los tipos de transacciones existentes como funciones esenciales. Los códigos precompilados existentes se downgraden a código EVM o RISC-V, y eventualmente, la máquina virtual puede cambiarse de EVM a RISC-V.

El núcleo de esta estrategia de downgrade es eliminar la complejidad mientras se mantiene la compatibilidad con funciones existentes. El objetivo final es que los desarrolladores de clientes ya no tengan que gestionar el código legado de versiones anteriores de Ethereum.

Recomendaciones para la sostenibilidad a largo plazo de Ethereum

La declaración de Vitalik Buterin de esta semana va más allá de una simple observación técnica; plantea un tema crucial para el futuro de Ethereum. A largo plazo, es necesario desacelerar el ritmo de cambios y evitar que la complejidad innecesaria obstaculice el desarrollo del protocolo.

Mediante una verdadera reducción y recolección de basura, Ethereum puede evolucionar hacia un protocolo más simple, transparente y confiable. Esto también puede considerarse un intento de incorporar en Ethereum los valores de inmutabilidad y simplicidad que Bitcoin ha promovido. La forma en que la simplificación y el downgrade se reflejen en la hoja de ruta futura de Ethereum jugará un papel importante en la realización de una verdadera descentralización y autonomía en la cadena de bloques.