El posible futuro de Ethereum: The Purge

Uno de los desafíos a los que se enfrenta Ethereum es que, por defecto, la expansión y complejidad de cualquier protocolo de blockchain aumentan con el tiempo. Esto ocurre en dos lugares:

Datos históricos: En cualquier momento de la historia, cualquier transacción realizada y cualquier cuenta creada deben ser almacenadas permanentemente por todos los clientes y descargadas por cualquier nuevo cliente, para estar completamente sincronizados con la red. Esto llevará a que la carga del cliente y el tiempo de sincronización aumenten con el tiempo, incluso si la capacidad de la cadena se mantiene constante.

Función del protocolo: agregar nuevas funciones es mucho más fácil que eliminar las funciones antiguas, lo que provoca que la complejidad del código aumente 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 grande a la blockchain: la persistencia. Puedes poner un NFT, una carta de amor en los datos de una llamada de transacción, o un contrato inteligente que contenga 1 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 puedan estar completamente descentralizadas y eliminar las claves de actualización, necesitan estar seguras de que sus dependencias no se actualizarán de una manera que las destruya, especialmente L1 en sí.

Si nos proponemos equilibrar estas dos demandas y minimizar o revertir la obsolescencia, la complejidad y el declive mientras mantenemos la continuidad, es absolutamente posible. Los organismos pueden lograr esto: aunque la mayoría de los organismos envejecen con el 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, el opcode SELFDESTRUCT ha desaparecido en su mayor parte, y los nodos de la cadena de beacon han almacenado datos antiguos durante 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 e incluso el estado final.

Reducir la complejidad del protocolo eliminando funciones innecesarias.

Índice del artículo:

Historial de expiración(registro histórico de expiración)

Estado de expiración( estado de expiración)

Limpieza de características ( limpieza de características )

Historia de caducidad

¿Qué problema se resuelve?

A partir de la fecha de redacción de este artículo, un nodo de Ethereum completamente sincronizado necesita 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 parte 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 varios cientos de GB cada año.

¿Qué es, y cómo funciona?

Una característica clave de simplificación del problema de almacenamiento histórico es que, dado que cada bloque está vinculado a través de un hash ( y otras estructuras ) al bloque anterior, alcanzar consenso sobre el actual es suficiente para alcanzar consenso sobre la historia. Siempre que la red logre 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 así como por una 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 ofrece muchas opciones sobre cómo almacenar el historial. 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. Quizás contrariamente a la intuición, este enfoque puede incluso no reducir 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 almacene aleatoriamente el 10% del historial, entonces cada dato será copiado 10,000 veces - exactamente igual al factor de copia de 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 toda la historia. El bloque de consenso ( está relacionado con la parte del consenso de prueba de participación que solo almacena datos durante aproximadamente 6 meses. Blob solo almacena datos durante 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 ) 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 almacenarán datos antiguos de manera distribuida.

Los códigos de borrado se pueden utilizar 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 apoyar el muestreo de disponibilidad de datos. La solución más sencilla probablemente sea reutilizar estos códigos de borrado y también colocar la ejecución y los datos de bloques de consenso dentro del blob.

)# ¿Qué relación tiene con la investigación existente?

EIP-4444;

Torrents y EIP-4444;

Portal de red;

Portal Network 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 restante incluye construir e integrar una solución distribuida concreta para almacenar registros históricos------al menos registros históricos de ejecución, pero finalmente también incluye consenso y blobs. La solución más sencilla es ###i( simplemente introducir una biblioteca torrent existente, así como )ii( una solución nativa de Ethereum llamada red Portal. Una vez que introduzcamos cualquiera de estas, podremos abrir EIP-4444. 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 para todos los clientes al mismo tiempo; 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 historia antigua mañana y depender de los nodos archivados 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 camino 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:

¿Cómo nos esforzamos para garantizar 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: de hecho, exigiría que cada validador de prueba de participación almacene un porcentaje determinado de historial y lo verifique criptográficamente de forma regular para asegurarse de que lo están haciendo. 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 involucra 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, puede 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, se puede decir que reducir la demanda de almacenamiento histórico es más importante que la ausencia de estado: de los 1.1 TB requeridos por el nodo, aproximadamente 300 GB son estado, mientras que los restantes aproximadamente 800 GB se han convertido en históricos. Solo al lograr la ausencia de estado y 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 la implementación de nodos más nuevos de Ethereum 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 parte de la historia, los clientes pueden eliminar de manera segura todo el código relacionado con la prueba de trabajo.

) Estado de expiración

¿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 al año, debido al crecimiento continuo del estado: saldos de cuentas y números aleatorios, código de contratos y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única, lo que trae una carga permanente a los clientes de Ethereum actuales y 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 que se crea un objeto de estado, siempre existirá y podrá ser leído en cualquier momento por cualquier transacción. Si introducimos la sin estado, algunos piensan que el problema quizás no sea tan malo: solo las clases de constructores de bloques especializadas 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 de que no queremos depender demasiado de la sin estado, y que eventualmente podríamos querer 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 con código, ( iii ) configurando una ranura de almacenamiento que no se ha 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.

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

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

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

Estos son problemas en los que la comunidad de desarrollo central de Ethereum ha estado trabajando durante años, incluyendo propuestas como "alquiler de blockchain" y "renovación". Al final, combinamos las mejores partes de las propuestas y nos centramos en dos categorías de "las soluciones conocidas menos malas":

• Solución para el estado de expiración parcial
• Sugerencia de expiración del estado basada 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. Cada uno almacena permanentemente un "mapeo superior", donde los bloques están vacíos o no vacíos. Solo cuando el más