Escalabilidad en Ethereum

Introducción

A lo largo de su historia, tanto Ethereum como otras blockchains han recibido un número de mejoras con el objetivo de avanzar en lo respectivo a ciertos aspectos clave de su funcionamiento. En general, estas mejoras se centran en los tres pilares fundamentales de estas tecnologías, que son seguridad, descentralización, y escalabilidad.

Si bien grandes hitos han sido alcanzados en relación a estos aspectos, el trabajo aún no está terminado. Pero para poder entender cuáles son los límites actuales de esta tecnología, es necesario adentrarnos en su estado actual, y desglosar los componentes involucrados.

Hoy, nos centraremos en escalabilidad. Se trata de quizás el aspecto más crítico para la evolución de Ethereum - pero para explicar por qué, vamos a necesitar precisar qué entendemos por escalabilidad en el contexto de Ethereum.

¿Qué es la Escalabilidad?

En términos generales, escalabilidad significa la capacidad de un sistema de procesar una cantidad creciente de trabajo o tráfico. Para una blockchain, esto se traduce directamente en poder procesar un mayor número de transacciones por segundo (TPS), manteniendo al mismo tiempo bajos los costos de transaccionar, y los tiempos de confirmación.

Por supuesto, esto es muy importante para que la experiencia general de uso de Ethereum sea buena para los usuarios. Actualmente, la red procesa alrededor de 15 a 20 transacciones por segundo, lo que podemos fácilmente ver al inspeccionar los bloques en plataformas como etherscan.io (observando por supuesto el número de transacciones por bloque, y el tiempo de cada bloque, que es de 12 segundos).

Existen algunas complicaciones en este camino. No todas las transacciones son iguales - por ejemplo, una simple transferencia de $ETH es muy diferente de un llamado a un contrato donde los parámetros de la llamada (que viajan en el CALLDATA) pueden ocupar una gran cantidad de bytes. A su vez, toda la información de las transacciones vive en los bloques de la cadena, y estos bloques tienen restricciones de tamaño.

Para poder procesar más transacciones, una alternativa es aumentar el tamaño de los bloques en sí. Suena simple, pero esto trae consigo otros problemas. No olvidemos que para llegar al consenso, los bloques deben ser transmitidos entre los nodos de la red - y entre más grandes sean, más lentas serán las comunicaciones. La red tendrá más latencia, y todo el proceso se verá enlentecido. Es un equilibrio delicado.

Como si esto fuera poco, hay ciertos actores que complican aún más la situación: las soluciones de capa 2 (layer 2), o rollups. Éstos procesan miles de transacciones por segundo, y luego publican las transacciones procesadas a Ethereum. Es decir, lo usan como una capa de asentamiento: al publicar estos datos periódicamente, dejan un registro inmutable asentado en Ethereum. Estos datos solían publicarse también en forma de CALLDATA - por lo tanto, más rollups significa más dificultad de la red para escalar.

Este era el estado de la red antes del upgrade Dencun, que llegó a mainnet a inicios de 2024. El upgrade incluyó el EIP-4844, también conocido como Proto-Danksharding, que marcó el comienzo de un camino para intentar mejorar la escalabilidad en la layer 1.

Disponibilidad de Datos

La clave está en cuestionarnos si realmente debemos guardar la información en Ethereum a través de CALLDATA, o si existe alguna otra solución. Los rollups publican las transacciones con el fin de crear un registro no solo inmutable, sino además verificable, de manera que permite a actores como nodos e indexadores acceder a los datos de las transacciones, y entender cómo evoluciona la red.

Los datos guardados con CALLDATA quedan indefinidamente en la blockchain, y generan costos de procesamiento ya que la EVM los trata como cualquier otro payload. Un costo que los rollups deben pagar, y en última instancia trasladan a sus usuarios.

En otras palabras, lo que realmente necesitamos es garantizar la disponibilidad de estos datos. Y aquí es donde está la pregunta fundamental: ¿es realmente necesario que estos datos estén disponibles para siempre, o solamente el tiempo necesario para su verificación?

---

Proto-Danksharding

Para solucionar esto, Proto-Danksharding introduce la idea de blobs: simplemente datos que permanecen almacenados por un tiempo determinado (4096 epochs, actualmente, aproximadamente 18 días), y luego son descartados.

Los blobs tienen un tamaño máximo de 128 kilobytes, y pueden ser inspeccionados en sitios como blobscan.com.

Esto es más que suficiente tiempo para que quien necesita estos datos publicados pueda acceder a ellos. Crucialmente, estos blobs no se publican a través de CALLDATA, por lo que es una alternativa mucho más barata.

Sin dudas suena prometedor. Pero de forma natural, lo siguiente que nos preguntamos es: si no es en el estado de la blockchain, ¿dónde se guardan esos datos?

Pues bien, los datos se transmiten junto con los bloques, por lo que los nodos que los reciban simplemente los guardan en memoria. Lo que es claro es que al no ser parte del estado de la blockchain, debe existir algún mecanismo de verificación de los mismos. De otra forma, quien los consume no tendría mucha forma de verificar la integridad de los blobs: es decir, garantizar que no están corruptos o hayan sido alterados.

La forma de asegurar esto es guardando algún tipo de identificador corto de forma permanente en la red, que permita rápidamente verificar la integridad de los datos. Esto puede realizarse de diversas formas - por ejemplo, guardando el hash del blob, que es un identificador único del mismo a efectos prácticos, una suerte de "huella digital" criptográfica.

Hay otras formas de lograr el mismo efecto, como a través del uso de Merkle trees (que de hecho, es la forma en la que operan los nodos de ejecución).

En Proto-Danksharding, se eligió usar un esquema de compromiso polinomial llamado KZG (Kate-Zaverucha-Goldberg), cuya función es exactamente la misma: reducir todo un blob a un pequeño identificador verificable. Esta decisión tiene que ver con potencial compatibilidad con pruebas de conocimiento cero (ZK proofs).

¡Perfecto! Con esto, podemos guardar datos de forma barata y verificable en Ethereum, permitiendo a los rollups operar de una forma que no congestione la red.

El problema podría parecer resuelto. Pero, como suele suceder… No es tan simple.

Limitaciones

Imaginemos que empezamos a adjuntar estos blobs a los bloques. ¿Cuántos podemos agregar?

Aunque los blobs en sí no son parte del estado de Ethereum, el problema es que los nodos tienen que transmitirlos a través de la red junto con los bloques. ¿Suena familiar? Es exactamente el mismo problema del que hablamos al principio de este artículo: entre más blobs, más latencia en la red. Y no solo por la transmisión en sí - recordemos que los blobs deben ser verificados.

Adicionalmente, podrían haber más requerimientos de memoria (hardware) para los nodos que guardan estos blobs. A modo ilustrativo, hagamos el ejercicio de calcular de cuánta memoria hablamos: imaginemos que pudiéramos guardar 100 blobs por bloque. Siendo que los blobs se almacenan por 4096 epochs, que son 131072 slots, y que cada blob tiene un tamaño máximo de 128 kilobytes, estaríamos hablando de una capacidad de almacenamiento solamente para blobs de 1.6 terabytes!

Así que de nuevo, hay un límite de cuántos blobs podemos guardar por bloque, de forma que la red no se vea demasiado afectada (y los slots puedan mantenerse en 12 segundos). Actualmente, la red soporta solamente 6 blobs por bloque.

Esto genera una cierta tensión: ahora los rollups compiten por este nuevo "blobspace", y en períodos de mucha actividad, el precio de este recurso puede tener picos, lo cuál por supuesto impacta a los rollups. Idealmente, quisiéramos poder incluir más blobs por bloque, de manera de aliviar esta tensión - pero ya vimos que no podemos hacer eso sin afectar significativamente la red.

Entonces, ¿cómo solucionamos este problema?

Danksharding

Proto-Danksharding fue creado como un paso intermedio entre la versión anterior de Ethereum, y la visión que se conoce como Danksharding.

La idea principal es poder aumentar el número de blobs por bloque, de 6 a 64. Pero para poder llegar a eso sin enfrentarnos a los problemas que mencionamos más arriba, hay ciertas condiciones que deben cumplirse, enmarcadas en otros hitos en la evolución de la red, como:

• Proposer-Builder Separation
• Data Availability Sampling.

Pronto profundizaremos sobre estos temas, explicando el rol de estas propuestas en la realización de Danksharding.

¿Y la Escalabilidad?

Es interesante notar que tanto Proto-Danksharding como Danksharding no buscan mejorar la escalabilidad de Ethereum de forma directa. Ninguno de estos updates cambia la frecuencia con la que se producen bloques, ni el tamaño máximo de los mismos. La consecuencia de esto es que Ethereum en sí mantendrá una cantidad transacciones por segundo baja.

A pesar de lo que sugieren los nombres de estos upgrades, ninguno de los dos es realmente una solución de sharding.

El sharding refiere a una arquitectura de bases de datos, donde la totalidad de los datos se divide en fragmentos llamados shards, los cuales pueden ser modificados de forma independiente. En Ethereum, esto se traduce en la capacidad de dividir a los validadores en grupos, y que estos puedan procesar transacciones en paralelo. Actualmente, todos los validadores asignados a un slot se dedican a validar la totalidad del bloque propuesto, y a su vez, el estado global es único, y no está separado en shards. Esto, en esencia, no cambiaría con el Danksharding. ¡Pero esta será una historia para otro momento!

Los verdaderos ganadores de todo esto son los rollups, que pueden enfocarse en procesar grandes cantidades de transacciones, y mantener sus costos bajos al tener más disponibilidad de blobspace. Esta es la verdadera (y actual) estrategia de Ethereum: lo que el mismo Vitalik ha llamado el rollup-centric roadmap.

Notas de Cierre

Queda claro que aún hay mucho por hacer. Ethereum apunta a ser mucho más que una blockchain, y en cambio convertirse en la infraestructura para un futuro donde los rollups sean los protagonistas.

El camino por recorrer aún es largo, y hay desafíos muy interesantes por delante. Al igual que otras blockchains, Ethereum es un sistema en constante evolución, y en los próximos años seguramente seamos testigos de una serie de cambios revolucionarios. La historia de blockchain se sigue desarrollando en vivo y en directo, y es importante entender dónde están los problemas que como comunidad aún debemos resolver.

---

Este artículo es parte de una de colaboración para la creación de contenido educativo sobre Ethereum entre Space Dev y ETH Kipu. Agradecemos a Juan Manuel Sobral por facilitar este encuentro y muy especialmente a Franco Mangone por la escritura del artículo.