Un agradecimiento especial a Justin Drake, Tim Beiko, Matt Garnett, Piper Merriam, Marius van der Wijden y Tomasz Stanczak por sus comentarios y revisiones.

Una de las desafíos que enfrenta Ethereum es que, por defecto, la complejidad y la expansión de cualquier protocolo de Cadena de bloques aumentarán con el tiempo. Esto ocurre en dos lugares:

· Datos históricos: Cualquier transacción realizada en cualquier momento de la historia y cualquier cuenta creada deben ser almacenadas permanentemente por todos los clientes y descargadas por cualquier nuevo cliente para sincronizarse completamente con la red. Esto puede resultar en una carga y un tiempo de sincronización cada vez mayores con el tiempo, incluso si la capacidad de la cadena permanece constante.

Función de protocolo: agregar una nueva función es mucho más fácil que eliminar una función anterior, lo que hace que la complejidad del código aumente con el tiempo.

Para mantener a Ethereum a largo plazo, necesitamos aplicar una fuerte presión de resistencia a estas dos tendencias, Soltar complejidad y expansión con el tiempo. Pero al mismo tiempo, necesitamos mantener una de las propiedades clave que hace que la cadena de bloques sea grande: la persistencia. Puede poner un token no fungible, una carta de amor en una transacción de datos o un Contrato inteligente que contiene $1 millón en on-chain, entrar en una cueva durante diez años y salir para encontrarlo todavía allí esperando que lo lea e interactúe con él. Para que los DApp estén completamente Descentralizados y eliminen la Llave secreta de actualización, deben estar seguros de que sus dependencias no se actualizarán de una manera que los destruya, especialmente L1 en sí mismo.

Si nos comprometemos a encontrar un equilibrio entre estas dos necesidades y a reducir o revertir la obesidad, la complejidad y el deterioro al mínimo posible sin perder la continuidad, es totalmente posible. Los organismos biológicos pueden lograr esto: aunque la mayoría de ellos envejecen con el tiempo, algunos afortunados no lo hacen. Incluso los sistemas sociales pueden tener una vida útil muy larga. En el caso de ETH, ya se ha logrado cierto éxito: la prueba de trabajo ha desaparecido, el código de operación SELFDESTRUCT ha desaparecido en su mayoría, y el beacon chain almacena datos antiguos de hasta seis meses. Encontrar este camino de una manera más generalizada para ETH y alcanzar un resultado final de estabilidad a largo plazo es el desafío definitivo para la escalabilidad a largo plazo, la sostenibilidad técnica e incluso la seguridad de ETH.

The Purge: Objetivo principal.

· Al Soltar requisitos de almacenamiento del cliente al reducir o eliminar la necesidad de que cada Nodo almacene permanentemente todos los registros históricos e incluso el estado final.

· Reducir la complejidad eliminando funciones innecesarias del protocolo.

Tabla de Contenidos:

Vencimiento de historial

· Vencimiento del estado

· Limpieza de características

Historial de caducidad

¿Qué problema se resuelve?

Hasta el momento de escribir este documento, 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 gran mayoría de esto es histórico: datos sobre bloques, transacciones y recibos históricos, la mayoría con varios años de antigüedad. Esto significa que incluso si no se incrementa en absoluto el límite de gas, el tamaño del nodo seguirá aumentando constantemente en varios cientos de GB cada año.

¿Qué es, cómo funciona?

Una característica clave de la simplificación del problema de almacenamiento histórico es que, dado que cada bloque apunta al bloque anterior a través de enlaces hash (y otras estructuras), llegar a un consenso actual es suficiente para llegar a un consenso histórico. Si la red llega a un consenso sobre el último bloque, cualquier historial de bloque, transacción o estado (saldo de la 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-de-N, mientras que el histórico es un modelo de confianza N-de-N.

Esto nos ofrece muchas opciones para cómo almacenar registros históricos. Una opción natural es que cada Nodo almacene solo una pequeña parte de los datos de la red. Así es como ha funcionado la red de semillas durante décadas: aunque la red almacena y distribuye en total millones de archivos, cada participante solo almacena y distribuye algunos de ellos. Tal vez en contra de la intuición, este enfoque ni siquiera necesariamente liberará la robustez de los datos. Si haciendo que los Nodo sean más económicos de operar, podemos construir una red con 100, 000 Nodo, donde cada Nodo almacena aleatoriamente el 10% de los registros históricos, entonces cada dato se duplicará 10, 000 veces - igual que el factor de duplicación de los 10, 000 Nodo - red de Nodo, donde cada Nodo almacena todo el contenido.

Ahora, Ethereum ha comenzado a alejarse del modelo en el que los nodos almacenan permanentemente todo el historial. Los bloques de consenso (es decir, la parte relacionada con el consenso de Prueba de participación) solo se almacenan durante aproximadamente 6 meses. Los blobs solo se almacenan durante aproximadamente 18 días. El 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 uniforme (probablemente alrededor de 18 días) en el que cada nodo sea responsable de almacenar todo el contenido, y luego establecer una red peer-to-peer compuesta por nodos Ethereum para almacenar los 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 sido sometido a códigos de borrado para respaldar el muestreo de disponibilidad de datos. Lo más probable es que la solución más sencilla sea reutilizar estos códigos de borrado y colocar los datos de bloques de ejecución y consenso en el blob.

¿Qué conexiones tiene con la investigación existente?

· EIP-4444 ；

· Torrents y EIP-4444 ；

Red de puerta de enlace;

· Portal de red y EIP-4444 ；

· Almacenamiento y recuperación distribuidos de objetos SSZ en el Portal中;

· Cómo aumentar el límite de gas (Paradigma).

¿Qué más se necesita hacer y qué se debe considerar?

El trabajo principal restante incluye la construcción e integración de una solución distribuida concreta para almacenar registros históricos, al menos para ejecutar registros históricos, pero finalmente incluye Consenso y blob. La solución más simple es (i) simplemente introducir bibliotecas torrent existentes, y (ii) un solución nativa de Ethereum llamada Portal Network. Una vez que se introduzca cualquiera de ellas, podemos abrir EIP-4444. EIP-4444 en sí no requiere un hardfork, pero sí necesita una nueva versión de protocolo de red. Por lo tanto, habilitarlo para todos los clientes simultáneamente es valioso, de lo contrario existe el riesgo de que los clientes fallen al conectarse a otros Nodo esperando descargar el historial completo, pero en realidad no lo obtienen.

La consideración principal involucra cómo nos esforzamos por proporcionar datos históricos ‘antiguos’. La solución más sencilla sería dejar de almacenar datos históricos antiguos desde mañana y depender de los nodos existentes y diversos proveedores centralizados para la replicación. Esto sería fácil, pero debilitaría la posición de Ethereum como un lugar de registro permanente. El enfoque más difícil pero más seguro sería construir e integrar primero una red de torrents para almacenar el historial de forma distribuida. Aquí, ‘qué tan duro trabajamos’ tiene dos dimensiones:

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

2. ¿Qué tan profundo es la integración de almacenamiento histórico en el protocolo Profundidad?

Para un enfoque extremadamente paranoico de (1) implicaría una prueba de custodia: requerir efectivamente que cada validador de Prueba de participación almacene un cierto porcentaje de registros históricos y verificar periódicamente encriptación si lo hacen de esta manera. Una forma más suave sería establecer un estándar voluntario de porcentaje histórico almacenado para cada cliente.

Para (2), la implementación básica solo implica el trabajo que ya se ha completado hoy: el Portal ya ha almacenado el archivo ERA que contiene todo el historial de Ethereum. Una implementación más completa implicará conectarlo realmente al proceso de sincronización, de modo que si alguien quiere sincronizar un Nodo de almacenamiento o un Nodo de archivo con todo el historial, incluso si no hay otros Nodos de archivo en línea, puedan lograrlo mediante una sincronización directa desde la red del portal.

¿Cómo interactúa con otras partes del roadmap?

Si queremos que la ejecución o el inicio de Nodo sea extremadamente fácil, reducir la demanda de almacenamiento histórico es más importante que la inmutabilidad: de los 1.1 TB necesarios para Nodo, aproximadamente 300 GB son estado y los restantes 800 GB se han convertido en historia. Solo con la implementación de la inmutabilidad y el EIP-4444, se puede lograr la visión de ejecutar Nodo de Ethereum en un reloj inteligente y configurarlo en solo unos minutos.

La limitación del almacenamiento histórico también hace que sea más factible para los nodos ETH más nuevos implementar solo las últimas versiones del protocolo, lo que los hace más simples. Por ejemplo, ahora es seguro eliminar 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 el cambio a la prueba de participación ya es historia, los clientes pueden eliminar de forma segura todo el código relacionado con la prueba de trabajo.

Expiración del estado

¿Qué problema se resuelve?

Incluso si eliminamos la necesidad de almacenamiento de historial en el cliente, las necesidades de almacenamiento del cliente seguirán subiendo, alrededor de 50 GB por año, ya que el estado sigue subiendo: saldo de la cuenta y números aleatorios, código y almacenamiento de contratos. Los usuarios pueden pagar una tarifa única que alivie la carga para los clientes actuales y futuros de la red Ethereum.

El estado es más difícil de “caducar” que el historial 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 puede ser leído por cualquier transacción en cualquier momento. Si introducimos la apatridia, algunos argumentan que tal vez el problema no sea tan grave: solo la clase constructora dedicada Bloquear necesita almacenar realmente el estado, mientras que todos los demás Nodos (¡e incluso la generación de listas!) ) puede ejecutarse sin estado. Sin embargo, existe el argumento de que no queremos confiar demasiado en la apatridia, y eventualmente es posible que queramos expirar el estado para mantener la descentralización de Ethereum.

¿Qué es y cómo funciona?

Hoy, cuando creas un nuevo objeto de estado (puede ocurrir de una de estas tres formas: (i) enviando ETH a una nueva cuenta, (ii) creando una nueva cuenta con código, (iii) estableciendo una ranura de almacenamiento previamente no utilizada), ese objeto de estado permanece en ese estado para siempre. Por el contrario, 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 los tres objetivos.

1. Eficiencia: no se requiere un cálculo adicional importante para ejecutar el proceso de vencimiento.

2. Amigabilidad del usuario: si alguien entra en una cueva durante cinco años y regresa, no debería perder el acceso a ETH, ERC 20, Token no fungible, CDP posiciones…

3. Amigable para los desarrolladores: los desarrolladores no necesitan cambiar a un modelo mental completamente desconocido. Además, las aplicaciones que actualmente están obsoletas y no se actualizan deberían poder seguir funcionando correctamente.

Si no cumples con estos objetivos, es fácil resolver el problema. Por ejemplo, puede hacer que cada objeto de estado también almacene un contador de fecha de vencimiento (la fecha de vencimiento se puede extender mediante la quema de ETH, lo que puede suceder automáticamente en cualquier momento de lectura o escritura) y tener un proceso que recorra el estado para quitar la fecha de vencimiento del objeto de estado. Sin embargo, esto introduce requisitos informáticos adicionales (e incluso de almacenamiento), y ciertamente no cumple con los requisitos de facilidad de uso. También es difícil para los desarrolladores razonar sobre los casos extremos que involucran valores de almacenamiento que a veces se restablecen a cero. Si establece un temporizador de vencimiento dentro del alcance del contrato, esto técnicamente facilitará la vida del desarrollador, pero dificultará la economía: el desarrollador tendrá que pensar en cómo “transferir” los costos de almacenamiento continuos al usuario.

Estos son los problemas que la comunidad de desarrollo central de Ethereum ha estado trabajando para resolver durante muchos años, incluyendo propuestas como ‘Alquiler de cadena Bloquear’ y ‘Regeneración’. Al final, hemos combinado las mejores partes de las propuestas y nos hemos centrado en dos tipos de ‘soluciones menos malas conocidas’:

· Solución para el vencimiento parcial del estado

· Sugerencia de vencimiento del estado basada en el ciclo de DIRECCIÓN.

Vencimiento parcial del estado

Algunas propuestas de vencimiento de estado siguen el mismo principio. Dividimos el estado en bloques. Todos almacenan permanentemente el “mapeo superior”, donde el bloque puede estar vacío o no. Solo se almacenan los datos de cada bloque cuando se acceden recientemente. Existe un mecanismo de “resurrección” 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 “ramas y hojas” introducido para los árboles Verkle (aunque es compatible con cualquier forma de estado sin estado, como los árboles binarios). En este diseño, los encabezados, códigos y ranuras de almacenamiento adyacentes se almacenan en la misma “rama”. Los datos almacenados bajo una rama pueden ser de hasta 256 * 31 = 7,936 bytes. En muchos casos, el encabezado y código completo de una cuenta, así como muchas ranuras de almacenamiento de claves, se almacenarán en la misma rama. Si los datos bajo una rama no se leen ni se escriben durante 6 meses, los datos ya no se almacenan y solo se guarda un compromiso de 32 bytes de esos datos (una “referencia”). Las transacciones que accedan a esos datos en el futuro deberán “revivir” los datos y proporcionar una prueba basada en la referencia para verificarlos.

Existen otras formas de lograr ideas similares. Por ejemplo, si la granularidad a nivel de cuenta no es suficiente, podemos diseñar un esquema en el que cada una de las mitades de los 1/2 32 partes del árbol esté controlada por un mecanismo similar de ramas y hojas.

Esto se complica aún más por los incentivos: un atacante puede “actualizar el árbol” colocando una gran cantidad de datos en un solo subárbol y enviando una sola transacción cada año, lo que obliga al cliente a almacenar permanentemente una gran cantidad de 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), alguien podría perjudicar a otros usuarios al colocar una gran cantidad de datos en el mismo subárbol que ellos. Se puede intentar limitar estos dos problemas haciendo que la granularidad sea dinámica en función del tamaño del subárbol: por ejemplo, cada objeto de estado consecutivo 2 16 = 65536 puede considerarse un “grupo”. Sin embargo, estas ideas son más complejas; El enfoque basado en el tallo es simple y los incentivos se pueden ajustar, ya que a menudo todos los datos debajo del tallo son relevantes para la misma aplicación o usuario.

Propuesta de vencimiento de estado basada en el ciclo de DIRECCIÓN

Si queremos evitar por completo cualquier subida de estado permanente, incluso un stub de 32 bytes, ¿qué podemos hacer? Esto es un problema debido a los conflictos de resurrección: si se elimina un objeto de estado, más tarde, cuando se ejecuta la EVM, se colocará otro objeto de estado en exactamente la misma posición, pero ¿qué sucede cuando alguien que se preocupa por el objeto de estado original regresa e intenta recuperarlo? Cuando expira parte del estado, el ‘stub’ impide la creación de nuevos datos. A medida que el estado expira por completo, ni siquiera podemos almacenar el stub.

El diseño basado en el ciclo de DIRECCIÓN es la idea más famosa para resolver este problema. No almacenamos todo el estado en un árbol de estado, sino que tenemos una lista de árboles de estado que suben constantemente, y cualquier estado que se lea o escriba se guarda en el árbol de estado más reciente. Se agrega un nuevo árbol de estado vacío en cada período (por ejemplo, 1 año). Los árboles antiguos se mantienen congelados. El Nodo completo solo almacena los dos árboles más recientes. Si un objeto de estado no ha sido tocado en dos períodos y ha caído en un árbol caducado, todavía se puede leer o escribir, pero la transacción debe demostrar su prueba de Merkle: una vez demostrada, se guarda una copia nuevamente en el árbol más reciente.

Una idea clave que hace que esto sea amigable para los usuarios y desarrolladores es el concepto de ciclo de DIRECCIÓN. El ciclo de DIRECCIÓN es un número que pertenece a una parte de DIRECCIÓN. La regla clave es que un DIRECCIÓN con ciclo N solo puede ser leído o escrito durante o después del ciclo N (es decir, cuando la lista de árboles de estado alcanza la longitud N). Si desea guardar un nuevo objeto de estado (por ejemplo, un nuevo contrato o un nuevo saldo ERC 20), puede guardarlo de inmediato si asegura colocar el objeto de estado en un contrato con ciclo de DIRECCIÓN N o N-1, sin necesidad de proporcionar evidencia de que no había nada antes. Por otro lado, cualquier adición o edición realizada durante el ciclo anterior de DIRECCIÓN requiere evidencia.

Este diseño conserva la mayoría de las propiedades actuales de Ethereum, no requiere cálculos adicionales, permite escribir aplicaciones casi como ahora (ERC 20 necesita ser reescrito para asegurar que el saldo de la dirección con ciclo N se almacene en un subcontrato, en sí mismo con ciclo N), resolviendo el problema de ‘el usuario entra en la cueva durante cinco años’. Sin embargo, tiene un gran problema: la dirección debe ampliarse a más de 20 bytes para adaptarse al ciclo de dirección.

Extensión del espacio de direcciones  DIRECCIÓN

Una sugerencia es introducir un nuevo formato de DIRECCIÓN de 32 bytes, que incluye el número de versión, el número de ciclo de DIRECCIÓN y el hash extendido.

0x01（rojo）0000（naranja）000001（verde）57 aE408398 dF7 E5 f4552091 A69125 d5dFcb7B8C2659029395bdF（azul）。

El rojo es el número de versión. Los cuatro ceros en naranja aquí están destinados a ser espacios en blanco para acomodar el número de Fragmentación en el futuro. El verde es el número de ciclo de DIRECCIÓN. El azul es un valor hash de 26 bytes.

El desafío clave aquí es la compatibilidad hacia atrás. Los contratos existentes están diseñados en torno a la dirección de 20 bytes y generalmente utilizan técnicas estrictas de empaquetado de bytes, asumiendo explícitamente que la dirección tiene exactamente 20 bytes de longitud. Una idea para abordar este problema implica una conversión de mapeo, donde los contratos antiguos que interactúan con la nueva dirección verán el valor hash de 20 bytes de la nueva dirección. Sin embargo, garantizar su seguridad presenta una gran complejidad.

Espacio de DIRECCIÓN contracción

Otra forma de proceder en la dirección opuesta: prohibimos de inmediato algunos subrangos de DIRECCIÓN de tamaño 2^128 (por ejemplo, todas las DIRECCIÓN que comienzan con 0xffffffff), y luego introducimos un DIRECCIÓN con un período de DIRECCIÓN y un valor hash de 14 bytes en ese rango.

0xffffffff000169125 d5dFcb7B8C2659029395bdF

El principal sacrificio hecho por este método es la introducción de riesgos de seguridad de DIRECCIÓN contrafácticos: poseer activos o permisos de DIRECCIÓN, pero su código no ha sido publicado en la cadena. El riesgo implica que alguien cree una DIRECCIÓN que afirme poseer un código (aún no publicado), pero también tenga otro código válido que se ha dispersado al mismo DIRECCIÓN. Hoy en día, calcular tales colisiones requeriría 2^80 hashes; la contracción del espacio de DIRECCIÓN reduciría este número a 2^56 valores de hash accesibles.

En áreas críticas de riesgo, es relativamente raro que la Billetera antifáctica DIRECCIÓN no sea propiedad de un solo propietario, pero a medida que entramos en un mundo L2 múltiple, puede volverse más común. La única solución es simplemente aceptar este riesgo, pero identificar todos los casos de uso comunes con posibles problemas y proponer soluciones efectivas.

¿Qué conexiones tiene con la investigación existente?

Propuesta temprana

Cadena de bloques清洁；

Reciclaje;

Teoría de gestión de tamaño de estado de Ethereum;

Algunos posibles caminos sin estado y caducados de estado;

Propuesta de vencimiento parcial de estado

EIP-7736 ；

Documento de expansión de espacio de DIRECCIÓN

Propuesta original;

Comentario de Ipsilon;

Comentario del artículo del blog;

¿Qué se destruirá si perdemos la resistencia a los choques?

¿Qué más se necesita hacer y qué se debe considerar?

Creo que hay cuatro caminos viables para el futuro:

· Nos mantenemos sin estado, y nunca introducimos la expiración del estado. El estado está subiendo constantemente (aunque lentamente: es posible que no lo veamos subir a más de 8 TB durante décadas), pero solo necesita ser conocido por usuarios de categorías relativamente especiales: incluso los validadores de PoS no necesitan el estado.

Una característica que requiere acceso a una parte del estado es la generación de una lista, pero esto se puede lograr de forma descentralizada: cada usuario es responsable de mantener una parte del árbol de estado que contiene su propia cuenta. Cuando difunden una transacción, la envían junto con una prueba del objeto de estado al que accedieron durante la validación (esto se aplica a cuentas EOA y ERC-4337). Luego, un validador sin estado puede combinar estas pruebas en una prueba que contiene toda la lista.

· Realizamos una expiración parcial de estados y aceptamos una tasa de crecimiento del tamaño de estado permanente mucho menor pero aún no nula. Este resultado puede considerarse similar a cómo se aceptan las propuestas de caducidad histórica que involucran redes de igual a igual, donde cada cliente debe almacenar una tasa de crecimiento de almacenamiento histórico permanente mucho menor pero aún no nula, en términos de un porcentaje más bajo pero fijo de datos históricos.

· Estamos llevando a cabo la expiración de estados a través de la extensión del espacio DIRECCIÓN. Este será un proceso de varios años para garantizar que el método de conversión de formato DIRECCIÓN sea efectivo y seguro, incluidas las aplicaciones existentes.

· Realizamos una reducción del espacio de DIRECCIÓN para el vencimiento del estado. Esto implicará un proceso de varios años para garantizar que se aborden todos los riesgos de seguridad relacionados con conflictos de DIRECCIÓN (incluidas las situaciones de interacción entre cadenas).

Un punto importante es que, independientemente de si se implementa o no un plan de vencimiento del estado que dependa de los cambios de formato de DIRECCIÓN, eventualmente se deberá abordar el desafío de la expansión y contracción del espacio de DIRECCIÓN. En la actualidad, generar una colisión de DIRECCIÓN requiere aproximadamente 2^80 valores hash, lo cual es factible para participantes con recursos extremadamente abundantes: las GPU pueden realizar aproximadamente 2^27 valores hash, por lo que se pueden calcular 2^52 en un año, lo que significa que todas las aproximadamente 230 GPU del mundo pueden calcular una colisión en aproximadamente 1/4 de año, y los FPGA y ASIC pueden acelerar aún más este proceso. En el futuro, este tipo de ataque estará al alcance de cada vez más personas. Por lo tanto, el costo real de implementar un vencimiento completo del estado puede no ser tan alto como parece, ya que de todos modos debemos abordar este desafío muy desafiante de DIRECCIÓN.

¿Cómo interactúa con otras partes del roadmap?

La expiración del estado puede hacer que la transición de un formato de árbol de estado a otro sea más fácil, ya que no se necesita un proceso de conversión: simplemente puede comenzar a usar el nuevo formato para crear un nuevo árbol y luego realizar un hard fork para convertir el árbol antiguo. Por lo tanto, aunque el vencimiento del estado es complicado, ciertamente beneficia a la simplificación de otros aspectos del mapa de ruta.

Limpieza de características

¿Qué problema resuelve?

Uno de los requisitos previos clave para la seguridad, accesibilidad y neutralidad confiable es la simplicidad. Si el protocolo es atractivo y simple, se reducirá la probabilidad de errores. Aumenta la oportunidad para que nuevos desarrolladores se involucren en cualquier parte de él. Es más probable que sea justo y más resistente a intereses especiales. Desafortunadamente, el protocolo, al igual que cualquier sistema social, tiende a volverse más complejo con el tiempo de forma predeterminada. Si no queremos que Ethereum caiga en un agujero negro de creciente complejidad, debemos hacer una de las dos cosas: (i) detener los cambios y hacer que el protocolo sea rígido, (ii) ser capaces de eliminar funciones y Soltar complejidad. También es posible seguir un camino intermedio, es decir, hacer menos cambios en el protocolo y, con el tiempo, al menos reducir algo de complejidad. Esta sección discutirá cómo reducir o eliminar la complejidad.

¿Qué es, cómo funciona?

No hay una sola solución importante que pueda reducir la complejidad del protocolo; la esencia del problema es que hay muchas pequeñas soluciones.

Un ejemplo parcialmente completado es eliminar el código de operación SELFDESTRUCT y puede servir como un plan para manejar otros ejemplos. El código de operación SELFDESTRUCT es el único que puede modificar un número ilimitado de ranuras de almacenamiento dentro de un solo bloque, lo que requiere una mayor complejidad de implementación del cliente para evitar ataques de DoS. El propósito original de este código de operación era permitir una liquidación de estado voluntaria, lo que permite que el tamaño del estado disminuya a lo largo del tiempo. En realidad, muy pocas personas lo usaron en última instancia. El código de operación se ha debilitado para permitir solo la creación de cuentas de autodestrucción en la misma transacción creada en el tenedor duro Dencun. Esto resuelve el problema de DoS y puede simplificar significativamente el código del cliente. En el futuro, puede tener sentido eliminar completamente este código de operación.

Algunos ejemplos clave de la simplificación del Consenso del protocolo que se han determinado hasta ahora incluyen lo siguiente. En primer lugar, algunos ejemplos fuera del EVM; estos son relativamente no invasivos, por lo que es más fácil llegar a un Consenso y implementarlos en un tiempo más corto.

· Conversión de RLP a SSZ: Inicialmente, los objetos de Ethereum se serializaban utilizando una codificación llamada RLP. RLP es sin tipo y innecesariamente complejo. Actualmente, beacon chain utiliza SSZ, que es notablemente mejor en muchos aspectos, incluyendo soporte no solo para la serialización, sino también para hash. En última instancia, esperamos eliminar completamente RLP y trasladar todos los tipos de datos a la estructura SSZ, lo que a su vez hará que las actualizaciones sean más fáciles. Los EIP actuales incluyen [1] [2] [3].

· Eliminar los tipos de transacciones antiguos: Hay demasiados tipos de transacciones en la actualidad, muchos de los cuales podrían ser eliminados. Una alternativa más suave a la eliminación completa es la función de abstracción de cuentas, mediante la cual las cuentas inteligentes pueden incluir el código para procesar y verificar transacciones antiguas (si así lo desean).

· Reforma de LOG: La creación de filtros bloom y otras lógicas en los registros aumentó la complejidad del protocolo, pero en realidad no se utiliza en el cliente porque es demasiado lento. Podemos eliminar estas funciones y enfocarnos en alternativas, como herramientas de lectura de registros descentralizados utilizando tecnologías modernas como SNARK en lugar del protocolo.

· Finalmente eliminar el mecanismo de comité de sincronización beacon chain: El mecanismo de comité de sincronización fue introducido inicialmente para lograr la verificación de cliente ligero de Ether. Sin embargo, aumenta significativamente la complejidad del protocolo. Finalmente, seremos capaces de utilizar la verificación SNARK en la capa de consenso de Ethereum directamente, lo que eliminará la necesidad de un protocolo de verificación de cliente ligero dedicado. Potencialmente, los cambios en el consenso nos permitirán eliminar el comité de sincronización antes creando un protocolo de cliente ligero más “nativo” que implica la verificación de firmas de un subconjunto aleatorio de validadores de consenso de Ethereum.

· Formato de datos unificado: Actualmente, el estado de ejecución se almacena en un árbol Merkle Patricia, el estado del Consenso se almacena en un árbol SSZ, y el blob se envía mediante un compromiso KZG. En el futuro, tiene sentido establecer un formato único y unificado para los datos de bloque y un formato único y unificado para el estado. Estos formatos cumplirán con todos los requisitos importantes: (i) una prueba simple para el cliente sin estado, (ii) serialización de datos y codificación de borrado, (iii) estructuras de datos estandarizadas.

· Eliminar el comité de la cadena de señales: este mecanismo se introdujo originalmente para respaldar la Fragmentación de ejecución de versiones específicas. En cambio, finalmente logramos la Fragmentación a través de L2 y blob. Por lo tanto, el comité es innecesario y se está tomando medidas para eliminarlo.

· Eliminar el orden de bytes mixto: EVM es big-endian, mientras que la capa de consenso es little-endian. Sería significativo armonizar y hacer que todo sea de una forma u otra (posiblemente big-endian, ya que es más difícil cambiar EVM)

Ahora, algunos ejemplos en EVM:

· Simplificación del mecanismo de gas: las reglas actuales de gas aún no están bien optimizadas y no pueden proporcionar una restricción clara en la cantidad de recursos necesarios para verificar un Bloquear. Ejemplos clave en este sentido incluyen (i) el costo de lectura/escritura de almacenamiento, que tiene como objetivo limitar el número de veces que se leen/leen en un bloque, pero actualmente es bastante arbitrario, y (ii) las reglas de llenado de memoria, que actualmente es difícil de estimar el consumo máximo de memoria de EVM. Las medidas de reparación propuestas incluyen cambios en el costo de gas sin estado (unificar todos los costos relacionados con el almacenamiento en una fórmula simple) y propuestas de precios de memoria.

· Eliminar precompilaciones: Ethereum actualmente tiene muchas precompilaciones que son innecesariamente complejas, relativamente no utilizadas y constituyen una gran parte del fracaso del Consenso, ya que casi ninguna aplicación las utiliza. Dos enfoques para abordar este problema son (i) eliminar solo las precompilaciones, y (ii) reemplazarlas con código EVM que implemente la misma lógica (inevitablemente más costoso). Esta propuesta de EIP sugiere comenzar por eliminar las precompilaciones de identidad; más tarde, RIPEMD 160, MODEXP y BLAKE podrían ser candidatos para su eliminación.

· Eliminación de la gas observabilidad: hace que la ejecución de EVM ya no pueda ver cuánta gas queda. Esto romperá algunas aplicaciones (más notablemente patrocinadas transacciones), pero hará futuras actualizaciones más fáciles (por ejemplo, para versiones más avanzadas de gas multidimensional). La especificación EOF ya ha hecho que el gas sea no observable, pero para simplificar el protocolo, el EOF debe ser obligatorio.

· Mejora del análisis estático: Actualmente, es difícil realizar un análisis estático del código EVM, especialmente porque los saltos pueden ser dinámicos. Esto también dificulta la optimización de la implementación de EVM (compilar el código EVM en otro lenguaje). Podemos resolver este problema eliminando los saltos dinámicos (o haciéndolos más costosos, como el costo en Gas lineal de la cantidad total de JUMPDEST en el contrato). Esto es lo que hace EOF, aunque se requiere la ejecución forzada de EOF para obtener los beneficios de simplificación del protocolo.

¿Qué conexiones tiene con la investigación existente?

· Pasos siguientes para la limpieza;

Auto-destrucción

· SSZ transforma las EIPS: [1] [2] [3];

· Cambios en el costo de gas sin estado;

· Precios de memoria lineal;

Eliminación previa a la compilación;

· Eliminar filtro bloom；

· Un método para recuperar de forma segura registros de seguridad utilizando cálculos verificables incrementalmente fuera de la cadena (lea: STARK recursivo);

¿Qué más se necesita hacer y qué se debe considerar?

La principal consideración en la simplificación de esta funcionalidad es (i) el grado y la velocidad de simplificación y (ii) la compatibilidad hacia atrás. El valor de Ethereum como una cadena proviene de ser una plataforma en la que se pueden implementar aplicaciones y tener la certeza de que seguirá funcionando en los próximos años. Al mismo tiempo, este ideal también puede llegar demasiado lejos, como dijo William Jennings Bryan, ‘clavando a Ethereum en la cruz de la compatibilidad hacia atrás’. Si solo hay dos aplicaciones en toda la red Ethereum que utilizan una determinada funcionalidad, y una de ellas no ha tenido usuarios durante años, mientras que la otra apenas se ha utilizado y tiene un valor total de 57 dólares, entonces deberíamos eliminar esa funcionalidad y compensar a los afectados con 57 dólares de nuestro propio bolsillo.

Un problema más amplio en la sociedad es crear un canal estandarizado para cambios de incompatibilidad no urgentes hacia atrás. Una forma de abordar este problema es examinar y ampliar los precedentes existentes, como el proceso de autodestrucción. El canal se ve así:

1. Empezar a hablar sobre la función de eliminación X;

2. Analizar y determinar el impacto de eliminar X en la aplicación, dependiendo de los resultados: (i) abandonar la idea, (ii) continuar según lo planeado o (iii) identificar la forma modificada menos destructiva para eliminar X y continuar;

3. Elaborar un EIP oficial para descontinuar X. Asegurarse de que infraestructuras de nivel superior populares (como lenguajes de programación, billetera) respeten esto y dejen de utilizar esta función.

4. Finalmente, elimine realmente X;

Debe haber un largo canal entre los pasos 1 y 4, que dure varios años, y se debe especificar claramente qué proyectos están en qué etapa. En este punto, es necesario equilibrar la energía y la velocidad del proceso de eliminación de características con la prudencia y la asignación de más recursos a otras áreas de desarrollo del protocolo, pero todavía estamos lejos de la frontera de Pareto.

EOF

Un conjunto principal de cambios propuestos para EVM es el formato de objeto de EVM (EOF). EOF introduce muchos cambios, como la prohibición de la observabilidad de gas, la observabilidad de código (es decir, sin CODECOPY) y solo permite saltos estáticos. El objetivo es permitir que EVM se actualice más con propiedades más fuertes y, al mismo tiempo, mantener la compatibilidad hacia atrás (ya que EVM anterior a EOF todavía existe).

La ventaja de hacerlo así es que crea un camino natural para agregar nuevas funcionalidades EVM y fomenta la migración a un EVM más estricto con garantías más sólidas. El inconveniente es que aumenta significativamente la complejidad del protocolo, a menos que encontremos una forma de eventualmente descontinuar y eliminar el antiguo EVM. Un problema principal es: ¿Qué papel juega EOF en la propuesta de simplificación de EVM, especialmente si el objetivo es reducir la complejidad de todo el EVM?

¿Cómo interactúa con otras partes del roadmap?

Muchas de las sugerencias de “mejora” en el resto de la hoja de ruta también son oportunidades para simplificar las funciones heredadas. Repita algunos de los ejemplos anteriores:

Cambiar a la finalidad única nos brinda la oportunidad de cancelar comités, rediseñar la economía y simplificar otros aspectos relacionados con la Prueba de participación.

· La implementación completa de la abstracción de cuentas nos permite eliminar una gran cantidad de lógica de procesamiento de transacciones existente y moverla al “código EVM de cuenta predeterminado” que puede ser reemplazado por todas las EOA.

· Si trasladamos el estado de Ethereum a un árbol de hash binario, esto puede ser coherente con la nueva versión de SSZ, de modo que todas las estructuras de datos de Ethereum puedan ser procesadas de la misma manera con hash.

Método más radical: Convertir gran parte del protocolo en código de contrato inteligente

Una estrategia más radical de simplificación de ETH consiste en mantener el protocolo intacto, pero trasladar gran parte de sus funciones al código del contrato.

La versión más extrema es hacer que L1 de ETH sea simplemente beacon chain “técnicamente” e introducir una Máquina virtual mínima (por ejemplo, RISC-V, Cairo o incluso una más pequeña específicamente para sistemas de prueba), permitiendo a otros crear sus propias agregaciones. Entonces, EVM se convertiría en la primera de estas agregaciones. Irónicamente, esto es completamente igual al resultado de la propuesta de entornos de ejecución de 2019-20, aunque SNARK lo hace más factible en la implementación real.

Una forma más suave sería mantener la relación entre la beacon chain y el entorno de ejecución actual de Ethereum sin cambios, pero intercambiar el EVM localmente. Podríamos elegir RISC-V, Cairo u otra Máquina Virtual como el nuevo ‘VM oficial de Ethereum’, y luego forzar la conversión de todos los contratos EVM a código de nuevo VM que interprete la lógica del código original (a través de compilación o interpretación). En teoría, esto incluso podría lograrse a través de una versión de ‘Máquina virtual objetivo’ como EOF.

Enlace al original