Ethereum es la máquina virtual del mundo; vale la pena entender cómo va a evolucionar.

Es un tema que da para escribir un libro entero, así que haremos un esfuerzo consciente por ser lo más concisos posibles. Va a haber temas temas complejos que queden sin explicar y temas explicados demasiado simples como para transmitir la dimensión total de lo que implican a nivel tecnológico.

Pero va a ser un gran primer pantallazo, para que el Roadmap de Ethereum deje de sonarnos a trabalenguas y cobre sentido real.

Roadmap de Ethereum

Vamos por partes. Acá está el Roadmap. El que puede decirlo para adelante y para atrás sin equivocarse que me mande el video y le transfiero 200 $ETH.

  • the Merge
  • the Surge
  • the Scourge
  • the Verge
  • the Purge
  • the Splurge

Acá en versión gráfica.

Antes de entrar en detalles, hay que hacer 2 aclaraciones muy importantes.

El roadmap representa fases de desarrollo, no etapas propiamente dichas

Primero, estas no son necesariamente etapas. Si bien hay un cierto atisbo de orden cronológico, son investigaciones y desarrollos que avanzan de forma paralela superponiéndose en varios momentos.

Muchas veces parece que son 6 pasitos que tenemos que dar uno después del otro y no es así. Hay equipos de especialistas trabajando en todos estos puntos de forma simultánea. Dicho esto, podemos interpretar el orden de cada uno de los procesos como una lista de prioridades.

Por ejemplo, para la upgrade Shanghai de Ethereum, que tuvo lugar en Marzo. El plan original era que incluyese varios desarrollos, entre ellos la posibilidad de hacer retiros de los ETH en staking, un paso fundamental en el traspaso hacia Proof-of-Stake, y una implementación del EIP-4844, asociado a “The Surge”.

Sin embargo, con el propósito de evitar demoras, el grupo de core devs de Ethereum decidió patear para más adelante casi todo lo que no estuviese relacionado a los retiros de ETH. Esto nos lleva al segundo punto que quería destacar.

El roadmap es susceptible a cambios y actualizaciones, gracias a Dios

La famosa foto que pusimos arriba de todo es la mejor representación del Roadmap de Ethereum, hoy. ¿Qué quiere decir esto Santi? Que puede cambiar. Y seguramente cambie. Ethereum es, como diría un gran filósofo contemporáneo, “una cosa viva”. Y su Roadmap también. Hay muchos actores, muchas variables a considerar y muchas complicaciones u oportunidades posibles.

El objetivo principal de Vitalik es que Ethereum llegue a un punto tal de desarrollo y madurez que permita planificar a largo plazo con certeza y tranquilidad, pero aún estamos lejos de tal punto. Por lo que es posible que veamos modificaciones en el Roadmap. Que se prioricen otras cosas. Que aparezcan nuevas ideas o se desestimen algunas de las nuevas. Estamos en terreno tremendamente experimental.

Recordemos: Estamos presenciando la construcción del aparato de coordinación humana más grande jamás creado.

Así que a tomárnoslo con calma y a disfrutar del proceso, y de esa sensación tan única de ver en primera fila cómo el mundo y el desarrollo del potencial de nuestra especie avanza hacia fronteras inexploradas.

Ok, ahora sí, veamos cada etapa:

The Merge

Un mecanismo de consenso Proof of Stake que sea robusto, simple y descentralizado

El objetivo de esta etapa es pulir el mecanismo de consenso. Ya pasamos a Proof-of-Stake, pero aún hay varias cosas por mejorar. El merge no va a estar completo hasta no haber logrado llevar el consenso a un modelo simple, robusto y lo más descentralizado posible.

Defectos a mejorar del modelo actual:

  • es demasiado complejo
  • tiene una finalidad de 12 minutos

El objetivo final es la Single Slot Finality; lograr que las transacciones sean finalizadas (es decir, 100% confirmadas) con cada slot. Hay 12 segundos entre cada slot, o sea que lograr Single Slot Finality significaría que tu transacción va a estar confirmada en 12 segundos o menos. Más rápido que el Pocho Lavezzi por la banda derecha del Nuevo Gasómetro.

The Surge

Alcanzar las 100,000 transacciones por segundo sobre rollups

Surge, con “S” de “seremos capaces de procesar una bocha de transacciones”. También, podríamos decir que la “S” es de “Sharding”, aunque hoy estamos pensando en una versión bastante simplificada del sharding.

El objetivo es modificar el protocolo para favorecer a los rollups, por eso se habla de “rollup centric roadmap”.

El primer paso es agregar un nuevo tipo de transacción, los blob, con el EIP-4844. Se trata de transacciones diseñadas específicamente para almacenar la data de los rollups, que tendrían su propio mercado de gas.

Esa implementacion se conoce como proto-danksharding, y sienta las bases para el danksharding, que es el proceso a partir del cual se va a fragmentar la gestión de los datos o la “data availability” de la red. Se apunta que la data esté disponible siempre que alguien la necesita (lo cual es mucho más eficiente que apuntar a que todos tengan que descargar y guardar la data).

Es una versión simplificada del sharding total, que podría o no implementarse a nivel de procesamiento de transacciones. Veremos cómo evoluciona. Por ahora basta acordarnos que la “S” es de “Sharding” y que los blobs son la posta para rollups baratos.

The Scourge

Asegurar que las transacciones sean incluidas de forma creíble, neutral y confiable, evitando riesgo de centralización

Esta es bastante nuevita, y consiste en resolver el problema del MEV y de posibles censuras a la red. En pocas palabras, Scourge apunta a separar el rol de validador en 2: una parte que construye un bloque y otra que toma un bloque construido y lo propone a la red.

La idea es que un grupo de actores agrupe transacciones en bloques cerrados y los ofrezca a los proposers para que los propongan a la red. De esta manera se distribuyen las ganancias de ser validador. La primera parte, el block builder, se lleva la ganancia del MEV que logra extraer al agrupar los bloques. La segunda parte, el block proposer, se lleva el premio de haber participado en el consenso de la red (además de un pequeño fee que el builder le paga).

Este diseño se conoce como…. proposer-builder-separation. Sí, muy original.

The Verge

Permitir que verificar bloques sea mucho más fácil, para que cualquiera pueda hacerlo desde un teléfono

El Scourge arruinó una regla memotécnica que he usado mucho, pero ahora podemos retomarla. Esta etapa es The Verge con “V” de… Verkle Trees. Son una forma de agrupar la información más eficiente que los famosos Merkle Trees que nos permiten guardar más datos en menos espacio.

Para verificar un bloque, un validador debe tener toda la historia de la blockchain guardada. Si podemos guardarla de forma tal que ocupe menos espacio, los validadores van a requerir menos memoria. Es decir, los requisitos para convertirse en validador van a ser más bajos, aumentando en última instancia la participación y la descentralización de la red.

Una segunda parte de este proceso es la inclusión de tecnología Zero Knowledge Proof en el proceso de validación. Esto permitiría validar un bloque sin la necesidad de tener toda la historia de la blockchain guardad. Si todo sale bien, vamos a poder correr un nodo desde el celu.

The Purge

Simplificar el protocolo y eliminar deuda técnica e información vieja

Ya nos acercamos al final… el final del Roadmap, pero además el fin de todos aquellos datos viejos que la blockchain fue acumulando. Este proceso consiste en deshacerse de gran parte de los registros históricos de la blockchain y de encontrar un modo de que la información se vaya guardando en otro lado a medida que se vuelve obsoleta.

Imaginálo así: en 35 años no va a ser necesario tener el registro de todas tus compras de NFTs falopa. Entonces ¿para qué guardar toda esa información on-chain? La purga es el proceso de limpieza de la red: el objetivo es simplificar el proceso, reduciendo la cantidad de información almacenada, de deuda técnica acumulada y de complejidad.

Fundamental tener la pieza ordenada para poder seguir construyendo el futuro.

The Splurge

Arreglar todo lo demás, je

¡Llegamos al Splurge! Felicitaciones. Por suerte no hay tanto detalle complejo por aquí, me voy a limitar a una frase de Vitalik: “The splurge is simply all the other fun stuff”.


Se incluye en esta línea de trabajo a todas las mejoras relacionadas a arreglar otros problemas dentro de Ethereum. Algunos ejemplos son la implementación del EIP-1559 o los avances a nivel de Account Abstraction.


Y eso me deja el pie para cerrar el artículo de hoy. Si te quedaste con ganas de saber más acerca de algunos de los conceptos mencionados en este resumen.. atento a los próximos artículos 😉