Futuro posible 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:

• Datos históricos: Cualquier transacción realizada y cualquier cuenta creada en cualquier momento de la historia debe ser almacenada permanentemente por todos los clientes y descargada por cualquier nuevo cliente, de modo que se sincronice completamente con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten constantemente con el tiempo, incluso si la capacidad de la cadena se mantiene constante.

• Funcionalidad del protocolo: agregar nuevas funciones es mucho más fácil que eliminar funciones antiguas, lo que lleva a un aumento de la complejidad del código con el tiempo.

Para que Ethereum pueda mantenerse a largo plazo, necesitamos ejercer una fuerte presión contraria sobre 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 hace que la cadena de bloques sea grande: la persistencia. Puedes poner un NFT, una carta de amor en los datos de una transacción, o un contrato inteligente que contenga un millón de dólares en la cadena, entrar en una cueva durante diez años y salir para descubrir que todavía está allí, esperando que lo leas e interactúes. Para que las DApp se descentralicen completamente y eliminen las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de una manera que las perjudique, especialmente L1 en sí.

Si nos comprometemos a equilibrar estas dos demandas y a minimizar o revertir la inflación, la complejidad y el deterioro manteniendo la continuidad, es absolutamente posible. Los organismos pueden hacer esto: aunque la mayoría de los organismos envejecen a lo largo del tiempo, unos pocos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En ciertos casos, Ethereum ha tenido éxito: la prueba de trabajo ha desaparecido, la mayoría de los códigos de operación SELFDESTRUCT han desaparecido, y los nodos de la cadena de beacon han almacenado datos antiguos por un máximo de seis meses. Encontrar este camino para Ethereum de una manera más general y avanzar hacia un resultado final estable a largo plazo es el desafío definitivo para la escalabilidad a largo plazo de Ethereum, la sostenibilidad técnica e incluso la seguridad.

The Purge: Objetivo principal.

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

• Reducir la complejidad del protocolo eliminando funciones innecesarias.

Índice del artículo:

• History expiry（历史记录到期）
• Estado de expiración
• Limpieza de características

Expiración de la historia

¿Qué problema resuelve?

Hasta el momento de redactar este documento, un nodo de Ethereum completamente sincronizado necesita aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, además de necesitar 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 parte de los cuales tiene varios años. Esto significa que incluso si el límite de Gas no aumenta en absoluto, el tamaño del nodo continuará aumentando cientos de GB cada año.

¿Qué es, 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 bloque anterior a través de un hash (y otras estructuras), basta con alcanzar consenso sobre el actual para alcanzar consenso sobre el histórico. Siempre que 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 la prueba de Merkle, y dicha 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 proporciona muchas opciones sobre cómo almacenar los registros históricos. Una elección natural es una red en la que cada nodo solo almacena 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 unos pocos de esos archivos. Tal vez en contra de la intuición, este enfoque ni siquiera necesariamente reduce la robustez de los datos. Si podemos construir una red con 100,000 nodos, donde cada nodo almacena aleatoriamente el 10% de los registros históricos, 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 de almacenamiento permanente de toda la historia por parte de todos los nodos. Los bloques de consenso (es decir, la parte relacionada con el consenso de prueba de participación) solo almacenan aproximadamente 6 meses. Los Blob solo almacenan aproximadamente 18 días. 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 (posiblemente 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 se pueden utilizar para aumentar 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 del bloque en el blob.

¿qué conexiones hay con la investigación existente?

• EIP-4444；
• Torrents y EIP-4444；
• Red de portal;
• Red de portal y EIP-4444;
• Almacenamiento y recuperación distribuida de objetos SSZ en Portal;
• ¿Cómo aumentar el límite de gas (Paradigm)?

¿Qué más se necesita hacer, qué se debe sopesar?

El trabajo principal que queda incluye construir e integrar una solución distribuida específica para almacenar historiales ------ al menos el historial de ejecuciones, pero en última instancia también incluye consenso y blobs. La solución más simple es (i) introducir simplemente una biblioteca torrent existente, así como (ii) una solución nativa de Ethereum llamada Portal Network. Una vez que introduzcamos cualquiera de estas, podremos abrir el EIP-4444. El EIP-4444 en sí no requiere un hard fork, pero sí requiere una nueva versión del protocolo de red. Por lo tanto, es valioso habilitarlo al mismo tiempo para todos los clientes, de lo contrario existe el riesgo de que los clientes fallen al conectarse a otros nodos esperando descargar el historial completo pero en realidad no lo obtienen.

Los principales compromisos implican cómo nos esforzamos por proporcionar datos históricos "antiguos". La solución más simple es dejar de almacenar datos históricos antiguos 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 los registros de manera distribuida. Aquí, "cuánto nos esforzamos" tiene dos dimensiones:

1. ¿Cómo nos esforzamos por 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 extremado y paranoico para (1) implicaría la prueba de custodia: de hecho, exigir que cada validador de prueba de participación almacene un cierto porcentaje de registros históricos y los verifique periódicamente de manera encriptada. 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 ha almacenado archivos ERA que contienen 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, pueda 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 puede considerarse más importante que la ausencia de estado: de los 1.1 TB que necesita el nodo, aproximadamente 300 GB son estado, mientras que los restantes aproximadamente 800 GB se han convertido en históricos. Solo logrando la ausencia de estado y EIP-4444 se podrá 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 nuevos 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 forma 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 forma segura todo el código relacionado con la prueba de trabajo.

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 por año, ya que el estado sigue 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 su vez generará una carga para los clientes de Ethereum actuales y futuros.

El estado es más difícil de "expirar" que la historia, porque la EVM está fundamentalmente diseñada en torno a la suposición de que una vez que se crea un objeto de estado, siempre existirá y podrá ser leído por cualquier transacción en cualquier momento. Si introducimos la falta de estado, algunos creen que este problema tal vez 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 en última instancia podríamos desear 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 (lo que puede ocurrir de alguna de las siguientes tres maneras: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta con código, (iii) configurando una ranura de almacenamiento que no haya sido tocada anteriormente), ese 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 una manera que cumpla con tres objetivos:

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

2. Amigabilidad del usuario: Si alguien entra en la cueva durante cinco años y regresa, no debería perder el acceso a ETH, ERC20, NFT, posiciones de CDP...

3. 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 satisfacer estos objetivos hace que sea fácil resolver problemas. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de caducidad (que se puede extender quemando ETH, lo que puede suceder automáticamente al leer o escribir en cualquier momento), y tener un proceso que recorra el estado para eliminar los objetos de estado con fecha de caducidad. Sin embargo, esto introduce cálculos adicionales (incluso requisitos 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 en los que los valores de almacenamiento a veces se restablecen a cero. Si establece un temporizador de caducidad dentro del alcance del contrato, esto técnicamente facilitará la vida a los desarrolladores, pero complicará la economía: los desarrolladores deben considerar cómo "trasladar" los costos de almacenamiento continuos a los usuarios.

Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado tratando de resolver durante años, incluidos los conceptos de "renta de blockchain" y "regeneració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 caducado
• Sugerencias sobre la expiración del estado basado en el ciclo de direcciones.

Expiración parcial del estado

Algunas propuestas de estado que expiran siguen los mismos principios. Dividimos el estado en bloques. Todos almacenan permanentemente un "mapeo superior", donde los bloques pueden estar vacíos o no vacíos. Solo se almacenan los datos en cada bloque si se han accedido recientemente. Hay un mecanismo de "resurrección" que se activa si ya no se almacenan.