El posible futuro de Ethereum: The Purge

Uno de los desafíos que enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain tienden a aumentar con el tiempo. Esto ocurre en dos lugares: los datos históricos y las funcionalidades del protocolo. Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión opuesta a estas dos tendencias, reduciendo la complejidad y la expansión con el tiempo. Pero al mismo tiempo, necesitamos conservar una de las propiedades clave que hacen que la blockchain sea grandiosa: la persistencia.

El objetivo principal de The Purge:

• Reducir los requisitos de almacenamiento del cliente al disminuir o eliminar la necesidad de que cada nodo almacene permanentemente todos los registros históricos e incluso el estado final.
• Reducir la complejidad del protocolo eliminando funciones innecesarias.

Expiración de historia

¿Qué problema resuelve?

Hasta el momento de redactar este artículo, un nodo de Ethereum completamente sincronizado requiere aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de varios cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es histórica: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años de antigüedad. Esto significa que, incluso si el límite de Gas no aumenta en absoluto, el tamaño del nodo seguirá aumentando cientos de GB cada año.

¿Qué es esto y cómo funciona?

Una característica clave que simplifica el problema del almacenamiento histórico es que, dado que cada bloque está vinculado al bloque anterior a través de un hash ( y otras estructuras ), alcanzar consenso sobre el estado actual es suficiente para alcanzar consenso sobre la historia. Siempre que la red alcance consenso sobre el bloque más reciente, cualquier bloque histórico, transacción o estado (, saldo de cuenta, número aleatorio, código, almacenamiento ) puede ser proporcionado por cualquier participante individual, junto con una prueba de Merkle, y esta prueba permite a cualquier otra persona verificar su corrección. El consenso es un modelo de confianza N/2-of-N, mientras que la historia es un modelo de confianza N-of-N.

Esto nos da muchas opciones sobre cómo almacenar el historial. Una elección natural es una red donde cada nodo almacena solo una pequeña parte de los datos. Así es como han funcionado las redes de semillas durante décadas: aunque la red almacena y distribuye millones de archivos en total, cada participante solo almacena y distribuye algunos de esos archivos. Quizás, contrariamente a la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si al hacer que los nodos funcionen de manera más económica, podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato será copiado 10,000 veces - exactamente el mismo factor de copia que una red de 10,000 nodos, donde cada nodo almacena todo.

Hoy en día, Ethereum ha comenzado a deshacerse del modelo en el que todos los nodos almacenan permanentemente todo el historial. El bloque de consenso ( se relaciona con la parte del consenso de prueba de participación que solo almacena aproximadamente 6 meses. Blob solo se almacena durante aproximadamente 18 días. El EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para bloques históricos y recibos. El objetivo a largo plazo es establecer un período unificado ) que podría ser de aproximadamente 18 días (, durante el cual cada nodo es responsable de almacenar todo el contenido, y luego establecer una red peer-to-peer compuesta por nodos de Ethereum que almacenen datos antiguos de manera distribuida.

Los códigos de borrado se pueden usar para mejorar la robustez, manteniendo el mismo factor de replicación. De hecho, el Blob ya ha implementado códigos de borrado para soportar el muestreo de disponibilidad de datos. La solución más simple probablemente sea reutilizar estos códigos de borrado y también colocar la ejecución y los datos de bloques de consenso en el blob.

![Vitalik: El posible futuro de Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(

) ¿Qué más necesita hacerse, qué hay que sopesar?

El trabajo principal restante incluye la construcción e integración de una solución distribuida concreta para almacenar registros históricos------al menos el historial de ejecución, pero en última instancia también incluye consenso y blob. La solución más simple es ###i( simplemente introducir bibliotecas torrent existentes, así como )ii( llamada solución nativa de Ethereum conocida como Portal Network. Una vez que se introduzca cualquiera de ellas, podremos abrir EIP-4444. EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, tiene valor habilitarlo simultáneamente para todos los clientes, de lo contrario existe el riesgo de que un cliente falle al conectarse a otros nodos esperando descargar el historial completo pero en realidad no lo obtiene.

Los principales compromisos implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es detener el almacenamiento de historia antigua mañana y depender de nodos de archivo existentes y varios proveedores centralizados para la replicación. Esto es fácil, pero debilita la posición de Ethereum como un lugar de registro permanente. Un enfoque más difícil pero más seguro es construir e integrar primero una red torrent para almacenar el historial de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:

1. ¿Cómo nos esforzamos para garantizar que el conjunto de nodos más grande realmente almacene todos los datos?

2. ¿Qué tan profunda es la integración del almacenamiento histórico en el protocolo?

Un enfoque extremadamente paranoico para ) implicaría la prueba de custodia: en realidad, exigir que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y verifique periódicamente de manera encriptada si lo hace. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historia almacenado por cada cliente.

Para (2), la implementación básica solo implica el trabajo que ya se ha completado hoy: el Portal ya ha almacenado archivos ERA que contienen toda la historia de Ethereum. Una implementación más completa implicará realmente conectarlo al proceso de sincronización, de modo que, si alguien desea sincronizar un nodo de almacenamiento de historial completo o un nodo de archivo, incluso si no hay otros nodos de archivo en línea, pueden lograrlo mediante la sincronización directa desde la red del portal.

( ¿Cómo interactúa con otras partes de la hoja de ruta?

Si queremos que la ejecución o el inicio de nodos sea extremadamente fácil, entonces reducir los requisitos de almacenamiento histórico puede considerarse más importante que la falta de estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, y los restantes aproximadamente 800 GB se han convertido en históricos. Solo al lograr la falta de estado y EIP-4444 se puede realizar la visión de ejecutar nodos de Ethereum en un reloj inteligente y configurarlos en solo unos minutos.

La limitación del almacenamiento histórico también hace que la implementación de nodos de Ethereum más recientes sea más viable, ya que solo admiten la última versión del protocolo, lo que los hace más simples. Por ejemplo, ahora se pueden eliminar de manera segura muchas líneas de código, ya que todos los espacios de almacenamiento vacíos creados durante el ataque DoS de 2016 han sido eliminados. Dado que la transición a la prueba de participación se ha convertido en historia, los clientes pueden eliminar de manera segura todo el código relacionado con la prueba de trabajo.

![Vitalik: El posible futuro de Ethereum, The Purge])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp###

Expiración del estado

( ¿Qué problema resuelve?

Incluso si eliminamos la necesidad de que los clientes almacenen el historial, la demanda de almacenamiento de los clientes seguirá creciendo, aproximadamente 50 GB al año, ya que el estado sigue creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contrato. Los usuarios pueden pagar una tarifa única, lo que a largo plazo traerá una carga a los clientes de Ethereum, tanto actuales como futuros.

El estado es más difícil de "expirar" que la historia, porque la EVM está diseñada fundamentalmente en torno a la suposición de que, una vez creado un objeto de estado, siempre existirá y podrá ser leído en cualquier momento por cualquier transacción. Si introducimos la falta de estado, algunos piensan que el problema quizás no sea tan malo: solo las clases de constructores de bloques especializados necesitan almacenar realmente el estado, mientras que todos los demás nodos ) incluso los que generan listas! ### pueden funcionar sin estado. Sin embargo, hay una opinión que sostiene que no queremos depender demasiado de la falta de estado, y que eventualmente podríamos desear hacer que el estado expire para mantener la descentralización de Ethereum.

( ¿Qué es, cómo funciona?

Hoy, cuando crea un nuevo objeto de estado, ) puede ocurrir de una de las siguientes tres maneras: ### i ( enviando ETH a una nueva cuenta, ( ii ) creando una nueva cuenta usando código, ( iii ) configurando un slot de almacenamiento que no ha sido tocado anteriormente (, el objeto de estado permanece en ese estado para siempre. En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo. El desafío clave es lograr esto de manera que se cumplan los tres objetivos:

• Eficiencia: no se necesita una gran cantidad de cálculos adicionales para ejecutar el proceso de vencimiento.

• Facilidad de uso: si alguien entra en la cueva durante cinco años y regresa, no debería perder el acceso a sus posiciones de ETH, ERC20, NFT y CDP...

• Amigabilidad para desarrolladores: Los desarrolladores no necesitan cambiar a un modelo de pensamiento completamente desconocido. Además, las aplicaciones que están actualmente rígidas y no actualizadas deberían poder seguir funcionando normalmente.

No cumplir con estos objetivos hace que sea fácil resolver problemas. Por ejemplo, puedes hacer que cada objeto de estado también almacene un contador de fecha de expiración ) que se puede extender quemando ETH, lo que podría ocurrir automáticamente en cualquier momento de lectura o escritura ), y hay un proceso que recorre el estado para eliminar objetos de estado con fechas de expiración. Sin embargo, esto introduce requisitos adicionales de cálculo ( e incluso de almacenamiento ), y definitivamente no puede cumplir con los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre las situaciones límite en las que los valores de almacenamiento a veces se restablecen a cero. Si configuras un temporizador de expiración dentro del alcance del contrato, esto técnicamente haría la vida más fácil para los desarrolladores, pero complicaría más la economía: los desarrolladores deben considerar cómo "trasladar" el costo de almacenamiento continuo a los usuarios.

Estos son los problemas que la comunidad de desarrolladores centrales de Ethereum ha estado tratando de resolver durante años, incluyendo propuestas como "renta de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos tipos de "soluciones conocidas como las menos malas":

• Solución para el estado de parte caducada
• Sugerencia de expiración de estado basada en el ciclo de direcciones.

(# Expiración parcial del estado

Las propuestas de estado que han expirado siguen los mismos principios. Dividimos el estado en bloques. Cada uno almacena permanentemente un "mapeo de nivel superior", donde los bloques pueden estar vacíos o no. Los datos en cada bloque solo se almacenan si se han accedido recientemente. Hay un mecanismo de "resurrección", que se activa si ya no se almacenan.

La principal diferencia entre estas propuestas es: ) i ### ¿cómo definimos "reciente" y ( ii ) ¿cómo definimos "bloque"? Una propuesta concreta es EIP-7736, que se basa en el diseño de "hoja y tallo" introducido para los árboles Verkle (, aunque es compatible con cualquier forma de estado sin estado, como los árboles binarios ). En este diseño, las cabeceras, el código y los espacios de almacenamiento adyacentes se almacenan bajo el mismo "tallo". Los datos almacenados bajo un tallo pueden ser de hasta 256 * 31 = 7,936 bytes. En muchos casos, toda la cabecera y el código de la cuenta, así como muchos espacios de clave de almacenamiento, se almacenarán bajo el mismo tallo. Si los datos bajo un tallo dado no se leen ni se escriben en un plazo de 6 meses, esos datos ya no se almacenan, sino que solo se guarda el compromiso de 32 bytes de esos datos ( "stub" ). Las transacciones futuras para acceder a esos datos necesitarán "revivir" los datos y proporcionar una prueba para verificar con respecto al stub.

Hay otras formas de implementar ideas similares. Por ejemplo, si el nivel de granularidad de la cuenta no es suficiente, podemos desarrollar un esquema en el que cada 1/232 de un árbol esté controlado por un mecanismo similar de tallo y hoja.

Debido a los factores de incentivo, esto se vuelve más complicado: un atacante puede "actualizar el árbol" al colocar grandes cantidades de datos en un solo subárbol y enviar una sola transacción al año, forzando al cliente a almacenar permanentemente una gran cantidad de estados. Si haces que el costo de renovación sea proporcional al tamaño del árbol ( o inversamente proporcional a la duración de la renovación ), entonces alguien podría perjudicar a otros usuarios al colocar grandes cantidades de datos en el mismo subárbol que ellos. Las personas pueden intentar limitar estos dos problemas dinamizando la granularidad según el tamaño del subárbol: por ejemplo, cada 216= 65536 objetos de estado continuos pueden considerarse un "grupo". Sin embargo, estas ideas son más complejas; los métodos basados en tallos son simples y se pueden ajustar los incentivos, ya que generalmente los tallos.