El posible futuro de Ethereum: The Purge

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

El objetivo principal de The Purge es:

• 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.
• Reduciendo la complejidad del protocolo al eliminar funciones innecesarias.

Historial de expiración

¿Qué problema resuelve?

A partir de la redacción de 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 necesitar varios cientos de GB de espacio en disco para el cliente de consenso. La mayor parte de esto es histórico: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales tienen varios años. Esto significa que incluso si el límite de Gas no aumenta en absoluto, el tamaño del nodo seguirá aumentando varios cientos de GB cada año.

¿Qué es eso y cómo funciona?

Una característica clave de simplificación del problema del almacenamiento histórico es que, dado que cada bloque está vinculado al anterior a través de un hash ( y otras estructuras ), alcanzar consenso sobre el actual es suficiente para alcanzar consenso sobre el histórico. Mientras la red alcance consenso sobre el bloque más reciente, cualquier bloque, transacción o estado histórico (, saldo de cuenta, número aleatorio, código, almacenamiento ) puede ser proporcionado por cualquier participante individual junto con una prueba de Merkle, y esa 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 ofrece muchas opciones sobre cómo almacenar el historial. Una elección natural es una red en la que 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, cada participante solo almacena y distribuye algunos de ellos. Quizás en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si al hacer que los nodos sean más económicos de operar, podemos construir una red de 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada dato se copiará 10,000 veces - exactamente el mismo factor de replicación que una red de 10,000 nodos, donde cada nodo almacena todo.

Ahora, Ethereum ha comenzado a desprenderse del modelo en el que todos los nodos almacenan permanentemente toda la historia. El bloque de consenso ( está relacionado con la parte del consenso de prueba de participación que solo almacena aproximadamente 6 meses. Blob solo almacena aproximadamente 18 días. EIP-4444 tiene como objetivo introducir un período de almacenamiento de un año para los bloques históricos y los 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, y luego establecer una red peer-to-peer compuesta por nodos de Ethereum que almacene datos antiguos de manera distribuida.

Los códigos de borrado pueden ser utilizados para mejorar la robustez, manteniendo al mismo tiempo el mismo factor de replicación. De hecho, 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 incluir los datos de ejecución y 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 se necesita hacer, qué se necesita sopesar?

El trabajo principal que queda incluye construir e integrar una solución distribuida concreta para almacenar registros históricos------al menos el historial de ejecución, pero que eventualmente incluirá consenso y blobs. La solución más sencilla es ###i( simplemente introducir una biblioteca torrent existente, así como )ii( la solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de estas, podremos activar el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí necesita una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo para todos los clientes al mismo tiempo, 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.

Las principales consideraciones implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más sencilla es dejar de almacenar historia antigua mañana y depender de los 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 la historia de forma distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:

• ¿Cómo nos esforzamos para asegurar que el conjunto de nodos más grande realmente almacene todos los datos?
• ¿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ía que cada validador de prueba de participación almacenara un cierto porcentaje de registros históricos y los verificara periódicamente de manera criptográfica para asegurarse de que lo hicieran. Un enfoque más moderado sería establecer un estándar voluntario para el porcentaje de historial 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 un archivo ERA que contiene toda la historia de Ethereum. Una implementación más completa implicará conectarlo realmente 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, puedan lograrlo a través de 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 podría considerarse más importante que la ausencia 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órico. Solo al lograr la ausencia de estado y el EIP-4444 se puede realizar la visión de ejecutar un nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.

Limitar el almacenamiento histórico también hace que los nodos de Ethereum más recientes sean más viables, 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 el cliente almacene el historial, la demanda de almacenamiento del cliente seguirá creciendo, aproximadamente 50 GB cada año, ya que el estado continúa creciendo: saldos de cuentas y números aleatorios, código de contrato y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que a la larga representa una carga para los clientes de Ethereum actuales y futuros.

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

( ¿Qué es, y cómo funciona?

Hoy, cuando crea un nuevo objeto de estado, ) puede ocurrir de una de las siguientes tres maneras: ### i ( enviar ETH a una nueva cuenta, ( ii ) crear una nueva cuenta utilizando código, ( iii ) establecer un slot de almacenamiento que no se haya 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 hacerlo de una manera que logre los tres objetivos:

• Eficiencia: no se necesitan grandes cálculos adicionales para ejecutar el proceso de vencimiento.
• Facilidad de uso: Si alguien entra en la cueva durante cinco años y vuelve, no debería perder el acceso a sus posiciones de ETH, ERC20, NFT, CDP...
• Amigabilidad para los desarrolladores: los desarrolladores no tienen que cambiar a un modelo de pensamiento completamente desconocido. Además, las aplicaciones que están actualmente rígidas y no se actualizan deberían poder seguir funcionando normalmente.

No cumplir con estos objetivos hace que resolver problemas sea muy fácil. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de caducidad. ) puede extender la fecha de caducidad al quemar ETH, lo que puede ocurrir automáticamente al leer o escribir en cualquier momento ), y hay un proceso que recorre el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce requisitos adicionales de cómputo ( e incluso de almacenamiento ), y definitivamente no puede satisfacer los requisitos de facilidad de uso. A los desarrolladores también les resulta difícil razonar sobre los casos límite que involucran valores de almacenamiento que a veces se reinician a cero. Si establece un temporizador de caducidad dentro del contrato, esto técnicamente haría la vida más fácil para los desarrolladores, pero haría la economía más complicada: los desarrolladores deben considerar cómo "trasladar" el costo de almacenamiento continuo a los usuarios.

Estos son problemas que la comunidad central de desarrollo de Ethereum ha estado tratando de resolver durante muchos años, incluidas 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":

• Soluciones para estados parcialmente expirados
• Sugerencias sobre el vencimiento del estado basado en el ciclo de direcciones.

(# Expiración parcial del estado

Algunas propuestas de estado que vencen siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan permanentemente el "mapeo superior", donde los bloques están vacíos o no vacíos. Los datos en cada bloque solo se almacenan si se han accedido recientemente. Existe un mecanismo de "resurrección" que se activa si ya no se almacenan.

Las principales diferencias entre estas propuestas son: ) 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 "hojas" introducido para el árbol Verkle (, aunque es compatible con cualquier forma de estado sin estado, como un árbol binario ). En este diseño, los encabezados, el código y los espacios de almacenamiento adyacentes se almacenan bajo el mismo "tronco". Los datos almacenados bajo un tronco pueden ser de hasta 256 * 31 = 7,936 bytes. En muchos casos, el encabezado completo y el código de la cuenta, así como muchos espacios de almacenamiento de claves, se almacenarán bajo el mismo tronco. Si los datos bajo el tronco dado no se leen ni se escriben en un plazo de 6 meses, esos datos ya no se almacenan, sino que solo se almacena un compromiso de 32 bytes de esos datos ( "muestra" ). Las transacciones futuras que accedan a esos datos necesitarán "revivir" los datos y proporcionar una prueba para verificar según la muestra.

También hay otras maneras de lograr 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 la árbol sea controlado por un mecanismo de tallo y hoja similar.

Debido a los factores de incentivo, esto se vuelve más complicado: los atacantes pueden "actualizar el árbol" al poner grandes cantidades de datos en un solo subárbol y enviar una sola transacción al año, obligando al cliente a almacenar permanentemente un gran estado. Si hace 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 poner 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; el enfoque basado en el tallo es simple y se pueden ajustar los incentivos, ya que generalmente bajo el tallo.