Vitalik Buterin quiere que Ethereum sea «tan sencillo como Bitcoin» en 2030

Portada/ilustración vía CryptoSlate. La imagen incluye contenido combinado que puede incluir contenido generado por IA.

El cofundador de Ethereum, Vitalik Buterin, cree que la resiliencia y escalabilidad a largo plazo de la blockchain dependen de hacerla simple, como Bitcoin. En una publicación de blog del 3 de mayo, describió cómo “Ethereum dentro de 5 años puede llegar a ser casi tan simple como Bitcoin”. Buterin escribió:

“Una de las mejores cosas de Bitcoin es lo increíblemente simple que es su protocolo.”

Según Buterin, el diseño minimalista y la simplicidad de Bitcoin lo hacen accesible, de modo que incluso un estudiante de secundaria puede entender el concepto y la arquitectura del protocolo. La simplicidad, argumentó Buterin, también trae otros beneficios, como reducir el costo de crear nueva infraestructura y mantener la infraestructura existente, además de disminuir el riesgo de errores.

Actualizaciones recientes como la prueba de participación (PoS) y la integración de pruebas de conocimiento cero (zk-SNARKs) han hecho a Ethereum más robusto. Sin embargo, descuidar la simplicidad del diseño ha incrementado los costos de Ethereum. Buterin explicó:

“Históricamente, Ethereum a menudo no ha hecho esto (a veces por decisiones mías), y esto ha contribuido a un gasto excesivo en desarrollo, todo tipo de riesgos de seguridad y un aislamiento en la cultura de I+D, muchas veces persiguiendo beneficios que resultaron ser ilusorios.”

Simplificación de la capa de consenso de Ethereum

En noviembre, el investigador de la Fundación Ethereum, Justin Drake, propuso una actualización de la capa de consenso llamada ‘Beam Chain’. Buterin cree que Beam Chain está “bien posicionada para ser mucho más simple” que su predecesora obsoleta, la actual beacon chain.

Esto se debe a que Beam Chain permitirá rediseñar la finalidad en 3 slots, lo que eliminará conceptos complejos como slots separados, epochs y comités de sincronización, señaló Buterin. También destacó que una implementación básica de la finalidad en 3 slots puede lograrse con unas 200 líneas de código, lo cual la hace mucho más sencilla.

Beam Chain también reducirá el número de validadores activos al mismo tiempo, lo que haría “más seguro utilizar implementaciones más simples de la regla de elección de bifurcación”, escribió Buterin.

Beam Chain también incorporará protocolos de agregación basados en STARK, lo que significa que cualquiera podrá ser un agregador. Buterin indicó:

“La complejidad de la criptografía de agregación en sí es significativa, pero al menos es una complejidad altamente encapsulada, lo que implica un riesgo sistémico mucho menor para el protocolo.”

Buterin añadió que la reducción de validadores activos y la incorporación de agregadores basados en STARK “probablemente permitirá una arquitectura P2P más simple y robusta”. Añadió que existe una oportunidad para repensar y simplificar varios aspectos, desde la entrada y salida de validadores hasta la penalización por inactividad. Esto puede lograrse tanto reduciendo la cantidad de líneas de código como creando “garantías más legibles”.

Buterin destacó que la capa de consenso está “relativamente desconectada” de las ejecuciones de la Máquina Virtual de Ethereum (EVM), lo que brinda un “margen relativamente amplio” para realizar mejoras en comparación con la capa de ejecución.

Simplificación de la capa de ejecución de Ethereum

El mes pasado, Buterin propuso reemplazar el lenguaje de contratos de la EVM por RISC-V para aumentar la eficiencia hasta 100 veces. Buterin argumentó que la adopción de RISC-V también aumentará la simplicidad, ya que “la especificación de RISC-V es absurdamente simple comparada con la de la EVM”.

Sin embargo, esto implicaría garantizar la compatibilidad hacia atrás con las aplicaciones existentes. Buterin escribió:

“Lo primero que es importante entender es: no hay una única forma de delimitar lo que es la ‘base de código de Ethereum’ (incluso dentro de un solo cliente).”

Según Buterin, el área naranja no se puede reducir. El objetivo, afirmó, es minimizar el área verde, trasladando código al área amarilla, que indica “código muy valioso para entender e interpretar la cadena hoy en día, o para construir bloques óptimos, pero que no forma parte del consenso.” Buterin comparó este proceso con la forma en que Apple logra compatibilidad hacia atrás a largo plazo mediante capas de traducción. Escribió:

“Lo importante es que las áreas naranja y amarilla son complejidad encapsulada, cualquiera que quiera entender el protocolo puede ignorarlas, las implementaciones de Ethereum pueden omitirlas, y cualquier error en esas áreas no representa riesgos para el consenso.”

Por eso la complejidad del código en las áreas naranja y amarilla tiene “muchos menos inconvenientes” que la complejidad del código en el área verde.

Para reducir el área verde, Buterin propuso los siguientes pasos:

Fase 1: Los nuevos precompilados se escribirán en RISC-V.

Fase 2: Los desarrolladores tendrán la opción de escribir contratos en RISC-V.

Fase 3: Todos los precompilados serán reemplazados por implementaciones en RISC-V mediante una bifurcación dura.

Fase 4: Implementar un intérprete de EVM en RISC-V y desplegarlo en la cadena como un contrato inteligente.

Los pasos anteriores garantizarían que el consenso de Ethereum “entienda de forma nativa” únicamente RISC-V, afirmó Buterin.

Estándares comunes para la simplificación del protocolo

Buterin propuso compartir “un estándar único en distintas partes del stack” como camino hacia la simplificación.

Por ejemplo, sugirió usar un único código de borrado para el muestreo de disponibilidad de datos, la transmisión P2P y el almacenamiento distribuido del historial. Esto minimizaría el número total de líneas de código, aumentaría la eficiencia y garantizaría la verificabilidad, argumentó.

De manera similar, propuso un formato de serialización compartido entre las tres capas de Ethereum: la capa de ejecución, la capa de consenso y la interfaz ABI de llamada a contratos inteligentes. Buterin sugirió usar SSZ, que es fácil de decodificar y ampliamente utilizado.

Por último, una vez que la EVM haya sido reemplazada por RISC-V u otro lenguaje simple, Buterin propone cambiar del árbol Merkle Patricia hexario a un árbol binario, tanto para la capa de consenso como para la de ejecución. Esta transición podría mejorar la eficiencia y reducir costos, asegurando que todas las capas de Ethereum puedan ser accedidas e interpretadas usando el mismo código, escribió Buterin.

Un cambio de filosofía

Buterin concluyó proponiendo que Ethereum, siguiendo el ejemplo de Tinygrad, adopte un objetivo explícito de líneas máximas de código. El objetivo, reiteró, es hacer que “el código crítico para el consenso de Ethereum sea casi tan simple como el de Bitcoin”.

Pero más importante aún, Ethereum debe adoptar una filosofía donde se elija la opción más simple siempre que sea posible. Esto significaría preferir la complejidad encapsulada sobre la complejidad sistémica.

Buterin aseguró que el código que se encarga de procesar las reglas históricas de Ethereum seguirá existiendo con su propuesta más reciente. Sin embargo, dicho código debería mantenerse fuera del código crítico para el consenso, es decir, fuera del área verde.