Vitalik: El posible futuro del protocolo Ethereum: la purga

Autor: Vitalik, fundador de Ethereum;

Nota: Este artículo es la quinta parte de la serie de artículos publicados recientemente por Vitalik, fundador de Ethereum,Posibles futuros del Protocolo Ethereum, Parte 5: La purga«, Ver la cuarta parte»Vitalik: el borde de Ethereum«. Ver «Vitalik: Objetivos clave del Ethereum the Scourge Fase«, Vea la segunda parte»Vitalik: ¿Cómo debería desarrollarse el protocolo Ethereum en la etapa de sobretensión?«, Vea la primera parte»¿Qué más se puede mejorar en Ethereum POS?«.

---

Uno de los desafíos que enfrenta Ethereum es que, por defecto, la hinchazón y la complejidad de cualquier protocolo de blockchain aumentarán con el tiempo.Esto sucede de dos maneras:

• Datos históricos:Cualquier transacción y cualquier cuenta creada en cualquier momento histórico necesitará ser almacenado permanentemente por todos los clientes y descargados por cualquier cliente nuevo que esté completamente sincronizado con la red.Esto hace que la carga del cliente y el tiempo de sincronización aumenten con el tiempo, incluso si la capacidad de la cadena sigue siendo la misma.

• Funciones de protocolo:Agregar nuevas características es mucho más fácil que eliminar las características antiguas, lo que resulta en el aumento de la complejidad del código con el tiempo.

Para que Ethereum dure mucho tiempo, necesitamos poner contra la contraressura intensificada en ambas tendencias, reduciendo la complejidad y la hinchazón con el tiempo.Pero al mismo tiempo, yoNecesitamos retener uno de los atributos clave de blockchain: persistencia.Puede poner NFTS, cartas de amor en datos de llamadas de transacción o contratos inteligentes que contienen un millón de dólares en la cadena, ingresar a una cueva durante diez años y encontrar que todavía está esperando que lea e interactúe.Para que los DAPP estén completamente descentralizados y eliminen las claves de actualización con confianza, deben asegurarse de que sus dependencias no se actualicen de una manera que las rompe, especialmente L1.

The Purge, Hoja de ruta 2023.

Si nos centramos y equilibramos estas dos necesidades, minimizar o revertir la expansión, la complejidad y la recesión mientras mantenemos la continuidad, es absolutamente posible.Los organismos pueden hacer esto: si bien la mayoría de los organismos envejecen con el tiempo, por suerte, algunos organismos no envejecen.Incluso los sistemas sociales pueden tener una vida útil extremadamente larga.En algunos casos, Ethereum ha tenido éxito: la prueba de trabajo ha desaparecido, el código de operación de auto -inestructa ha desaparecido básicamente, y el nodo de la cadena de baliza ha almacenado datos antiguos por hasta 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 final para la escalabilidad a largo plazo de Ethereum, la sostenibilidad tecnológica e incluso la seguridad.

La purga: objetivos principales

• Reduzca los requisitos de almacenamiento del cliente reduciendo o eliminando la necesidad de que cada nodo almacene permanentemente todo el historial, e incluso puede finalizarlo

• Reducir la complejidad del protocolo al eliminar las características no deseadas

Los datos históricos expiraron

¿Qué problemas resuelve?

Al momento de escribir este artículo, un nodo Ethereum totalmente sincronizado requiere aproximadamente 1.1 TB de espacio en disco para ejecutar el cliente, y unos pocos cientos de GB de espacio para ser utilizado para el cliente de consenso.La mayoría de ellos son datos históricos: datos sobre bloques históricos, transacciones y recibos, la mayoría de los cuales son de hace años.Esto significa que incluso si el límite de gas no aumenta en absoluto, el tamaño del nodo aumenta en cientos de GB por año.

¿qué es?¿Cómo funciona?

Una característica simplificada clave 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 sobre la corriente es suficiente para llegar a un consenso sobre la historia.Mientras la red esté de acuerdo en el último bloque, cualquier bloque histórico, transacción o estado (saldo de cuenta, número aleatorio, código, almacenamiento) puede ser proporcionado por cualquier participante único con prueba de Merkle, y la prueba le permite a cualquier otra persona verificar que sea es sexo correcto.Aunque el consenso es el modelo de confianza N/2 de N, la historia es el modelo de confianza 1 de N.

Esto abre muchas opciones sobre cómo almacenamos la historia.Una elección natural es una red donde cada nodo almacena solo una pequeña porción de datos.Así es como la red Torrent ha funcionado durante décadas: mientras que la red almacena y distribuye millones de archivos en total, cada participante almacena y distribuye solo algunos de ellos.Quizás contraintuitivamente, este enfoque puede ni siquiera reducir la robustez de los datos.Si podemos implementar una red de 100,000 nodos reduciendo el costo de la operación del nodo, donde cada nodo almacena aleatoriamente el 10% del historial, entonces cada pieza de datos se copiará 10,000 veces, con 10,000 del contenido almacenado por nodo, el factor de replicación de cada red de nodo es exactamente la misma.

Hoy, Ethereum ha comenzado a deshacerse del modelo donde todos los nodos almacenan permanentemente toda la historia.El bloque de consenso (es decir, la porción relacionada con el consenso de prueba de estaca) se almacena durante solo unos 6 meses.Las manchas se almacenan durante solo unos 18 días.EIP-4444 está diseñado para introducir un período de almacenamiento de un año para bloques y recibos históricos.El objetivo a largo plazo es tener un período coordinado (probablemente unos 18 días), durante el cual cada nodo es responsable de almacenar todo, y luego hay una red de nodos Ethereum de pares que almacenan datos antiguos de manera distribuida. .

La codificación de borrado se puede usar para mejorar la robustez mientras mantiene el factor de replicación sin cambios.De hecho, para apoyar el muestreo de disponibilidad de datos, las blobs han adoptado códigos de borrado.La solución más fácil podría ser reutilizar este código de borrado y poner los datos de ejecución y bloqueo de consenso en el blob también.

¿Qué investigación están disponibles?

EIP-4444:>https://eips.ethereum.org/eips/eip-4444

Torrents y EIP-4444:https://ethresear.ch/t/torrents-and-eip-4444/19788

Red de portal:https://ethereum.org/en/developers/docs/networking-layer/portal-network/

Red de portal y EIP-4444:>https://github.com/ethereum/portal-network-specs/issues/308

Almacenamiento y recuperación distribuida de objetos SSZ en Portal:https://ethresear.ch/t/distributed-storage-and-cryptogricy-sacured-retrieval-of-ssz-objects-for-portal-network/19575

Cómo aumentar el límite de gas (parámetro):https://www.paradigm.xyz/2024/05/how-to-raise-the-gas-limit-2

¿Cuáles son el resto y qué compensaciones hay?

El trabajo principal restante implica construir e integrar una solución distribuida concreta para el historial de tiendas, al menos el historial de ejecución, pero en última instancia también incluye consenso y blobs.La solución más fácil es (i) simplemente introducir la biblioteca torrent existente, y (ii) una solución nativa de Ethereum llamada red de portal.Una vez que se introduce cualquiera de estos, podemos habilitar EIP-4444.EIP-4444 en sí no requiere una horquilla dura, pero sí requiere una nueva versión del protocolo de red.Por lo tanto, es valioso habilitarlo para todos los clientes al mismo tiempo, porque de lo contrario los clientes pueden fallar debido a la conexión a otros nodos que esperan descargar el historial completo pero que en realidad no se implementan.

La principal compensación implica cómo trabajamos para poner a disposición datos históricos «anteriores».La solución más fácil es dejar de almacenar datos anteriores mañana y confiar en 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 registro de datos permanentes.Un enfoque más difícil pero más seguro es construir e integrar una red de torrentes primero para almacenar la historia de una manera distribuida.Aquí hay dos dimensiones:

• ¿Cuánto esfuerzo necesitamos para asegurarnos de que el número máximo de nodos almacene todos los datos?

• ¿Qué tan profundamente integramos el almacenamiento histórico con protocolos?

Para (1), el enfoque más riguroso implicaría una prueba de custodia: de hecho, se requiere cada verificador de prueba de estaca para almacenar un cierto porcentaje de historia y verificar regularmente si lo hacen a través del cifrado.Un enfoque más modesto es establecer un estándar voluntario para el porcentaje de historia almacenado por cliente.

Para (2), la implementación básica solo implica lo que se ha hecho hoy: Portal ha almacenado un archivo ERA que contiene todo el historial de Ethereum.Una implementación más exhaustiva implicaría conectarlo en el proceso de sincronización para que si alguien quiera sincronizar el nodo de almacenamiento de historial completo o el nodo de archivo, incluso si no hay otros nodos de archivo en línea, puede hacerlo sincronizando directamente desde la red de portal.

¿Cómo interactúa con el resto de la hoja de ruta?

Si queremos que el nodo se ejecute o comience extremadamente simple, la reducción de los requisitos de almacenamiento histórico puede ser posiblemente más importante que el sin estado: del 1.1 TB requerido por el nodo, aproximadamente 300 GB es el estado, y el restante alrededor de 800 GB es la historia.La visión del nodo Ethereum que se ejecuta en un reloj inteligente y configuración en solo unos minutos se logra solo si se logran apátridas y EIP-4444 simultáneamente.

Limitar el almacenamiento histórico también hace que las implementaciones de nodo Ethereum más nuevas sean más factibles para respaldar solo las últimas versiones del protocolo, lo que las hace mucho más simples.Por ejemplo, dado que todas las ranuras de almacenamiento vacías creadas durante el ataque DOS 2016 se han eliminado, muchas líneas de código se pueden eliminar de manera segura.Ahora que cambiar a Prueba de participación es el historial, el cliente puede eliminar de manera segura todo el código relacionado con la prueba de trabajo.

Los datos de estado expiraron

¿Qué problemas resuelve?

Incluso si eliminamos la necesidad del historial de almacenamiento del cliente, la demanda de almacenamiento del cliente continuará creciendo, aproximadamente 50 GB por año, a medida que el estado continúa creciendo: saldos de cuenta y números aleatorios, códigos de contrato y almacenamiento de contratos.Los usuarios pueden pagar una tarifa única, lo que siempre pondrá una carga para los clientes de Ethereum actuales y futuros.

El estado es más difícil de «espirarse» que la historia, porque la suposición básica de diseño de EVM es que una vez que se crea un objeto de estado, existirá para siempre y puede ser leído por cualquier transacción en cualquier momento.Si presentamos apátrate, algunas personas piensan que este problema puede no ser tan malo: solo una clase de constructores de bloques especializados requiere el almacenamiento real del estado, y todos los demás nodos (¡incluso la generación de listas!) Puede ejecutarse con estatuto.Sin embargo, algunas personas piensan que no queremos confiar demasiado en la apatridia, y eventualmente podemos querer que el estado expire para mantener descentralizado Ethereum.

¿qué es?¿Cómo funciona?

Hoy, cuando crea un nuevo objeto de estado (se puede hacer de una de tres maneras: (i) Envíe ETH a una nueva cuenta, (ii) cree una nueva cuenta con el código y (iii) configure el almacenamiento previamente no tocado) El objeto de estado siempre estará en ese estado.En cambio, lo que queremos es que el objeto expire automáticamente con el tiempo.El desafío clave es hacer esto de una manera que logre tres objetivos:

• eficiencia:No se requiere una gran cantidad de cálculo adicional para ejecutar el proceso de vencimiento.

• Uso de uso:Si alguien regresa cinco años en la cueva, no debe perder acceso a sus posiciones ETH, ERC20, NFT, CDP …

• Amigante del desarrollador:Los desarrolladores no tienen que cambiar a modelos de pensamiento completamente desconocidos.Además, las aplicaciones que ahora son rígidas y no comprendidas deben continuar funcionando razonablemente.

Sin cumplir con estos objetivos, el problema es fácil de resolver.Por ejemplo, puede hacer que cada objeto de estado también almacene un contador para registrar su fecha de vencimiento (que puede extenderse destruyendo ETH, que puede ocurrir automáticamente cuando lea o escriba), y tener un bucle a través del estado para eliminar el estado de vencimiento en el estado de vencimiento. proceso del objeto.Sin embargo, esto introduce cómputo adicional (incluso requisitos de almacenamiento) y ciertamente no cumple con los requisitos de facilidad de uso.También es difícil para los desarrolladores razonar sobre casos extremos que involucran valores almacenados a veces se restablecen a cero.Si establece el temporizador de vencimiento dentro del alcance del contrato, esto técnicamente facilita el trabajo del desarrollador, pero hace que la economía sea más difícil: los desarrolladores deben considerar cómo «pasar» los costos de almacenamiento continuos para sus usuarios.

Estos son problemas que la comunidad de desarrollo central de Ethereum ha estado trabajando duro para resolver durante años, incluidas propuestas como «alquiler de blockchain» y «regeneración».En última instancia, combinamos las mejores partes de la propuesta y nos centramos en dos categorías de «las soluciones menos malas conocidas»:

• Algunas soluciones de vencimiento del estado.

• Propuesta de vencimiento estatal basada en el ciclo de discursos.

Algún estado expirado

Algunas propuestas de vencimiento del estado siguen los mismos principios.Dividimos el estado en trozos.Todos almacenan permanentemente el «mapa de nivel superior» y qué bloques están vacíos o no vacíos.Los datos en cada bloque se almacenan solo si se ha visitado recientemente.Hay un mecanismo de «resurrección» en el que si un bloque ya no se almacena, cualquiera puede recuperar esos datos al proporcionar una prueba de lo que es.

Las principales diferencias entre estas propuestas son: (i) ¿Cómo definimos «recientemente» y (ii) cómo definimos «bloques»?Una propuesta específica es EIP-7736, que se basa en el diseño de «tallo y hoja» introducido para los árboles verkle (aunque compatibles con cualquier forma de árboles sin estado, como árboles binarios).En este diseño, los encabezados, los códigos y las ranuras de almacenamiento adyacentes entre sí se almacenan bajo el mismo «tallo».Los datos almacenados debajo del vástago pueden ser de hasta 256 * 31 = 7,936 bytes.En muchos casos, todo el título y el código de la cuenta, así como muchas ranuras de almacenamiento clave, se almacenarán en la misma columna vertebral.Si los datos bajo una columna vertebral dada no se leen o escriben dentro de los 6 meses, los datos ya no se almacenan, sino solo el compromiso de 32 bytes con los datos («Stub»).Las transacciones futuras que acceden a estos datos requerirán «resucitar» los datos y proporcionar pruebas de verificación con el stub.

Hay otras formas de implementar ideas similares.Por ejemplo, si el intervalo de cuenta no es suficiente, podemos desarrollar un plan en el que cada parte 1/232 del árbol esté controlada por un mecanismo de tallo y hoja similar.

Esto es aún más complicado debido a los factores motivacionales: 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, obligando al cliente a almacenar permanentemente una gran cantidad de estado.Si hace el costo de actualización proporcional al tamaño del árbol (o la duración de la actualización inversamente proporcional al tamaño del árbol), alguien podría dañar a otro usuario al poner muchos datos en el mismo subárbol que ellos.Puede intentar limitar estos dos problemas regulando dinámicamente los intervalos de cuenta en función del tamaño del subárbol: por ejemplo, cada 2^16 = 65536 objetos de estado puede tratarse como un «grupo».Sin embargo, estas ideas son más complejas;

Propuesta de vencimiento estatal basada en el ciclo de direcciones

¿Qué pasa si queremos evitar cualquier crecimiento estatal permanente por completo, incluso un trozo de 32 bytes?Aquí hay un rompecabezas: ¿qué pasa si se elimina el objeto de estado, y luego la ejecución de EVM pone otro objeto de estado en la misma posición, pero luego la persona que se preocupa por el objeto de estado original regresa e intenta restaurarlo?Para alguna expiración del estado, el trozo evita que se creen nuevos datos.Para una expiración de estado completo, ni siquiera podemos almacenar trozos.

El diseño basado en ciclo de dirección es la mejor manera de resolver este problema.En lugar de almacenar todo el estado con un árbol de estado, tenemos una creciente lista de árboles estatales, y cualquier estado leído o escrito se guarda en el último árbol estatal.Agregue un nuevo árbol de estado vacío cada ciclo (piense: 1 año).Los árboles estatales más antiguos son fijos.El nodo completo solo necesita almacenar los dos árboles más cercanos.Si el objeto de estado no se toca en dos ciclos y, por lo tanto, cae en el árbol caducado, aún se puede leer o escribir, pero la transacción debe demostrar que es a prueba de merkle; una vez hecho, la copia se guardará nuevamente en el último árbol medio .

Una idea clave para hacer que todo esto sea amigable para los usuarios y desarrolladores es el concepto de ciclos de dirección.El ciclo de dirección es un número que forma parte de la dirección.Una regla clave es que las direcciones con un período de dirección n solo se pueden leer o escribir durante o después del período N (es decir, cuando la lista de árbol de estado alcanza la longitud n).Si desea guardar un nuevo objeto de estado (por ejemplo, un nuevo contrato o un nuevo saldo ERC20), si se asegura de poner el objeto de estado en un contrato con un período de dirección de N o N-1, puede guardarlo inmediatamente sin proporcionarle ninguna prueba de nada antes.Por otro lado, cualquier adición o edición de estado en el ciclo de direcciones anterior requiere prueba.

Este diseño conserva la mayoría de las propiedades actuales de Ethereum, con un cálculo adicional muy pequeño, lo que permite que las aplicaciones se escriban casi como son ahora (ERC20 debe reescribirse para garantizar que el saldo de las direcciones con el período de dirección n se almacene en sí mismo con la dirección. Período n) y resolvió el problema del «usuario que ingresa a la cueva durante cinco años».Sin embargo, tiene un gran problema:La dirección debe extenderse a más de 20 bytes para adaptarse al ciclo de dirección.

Extensión del espacio de direcciones

Una propuesta es introducir un nuevo formato de dirección de 32 bytes que incluya el número de versión, el número de período de dirección y el valor de hash extendido.

0x01000000000157AE408398DF7E5F4552091A69125D5DFCB7B8C2659029395BDF

Red es el número de versión.Aquí los cuatro ceros naranjas representan espacios en blanco y pueden acomodar números de fragmentos en el futuro.El verde es el número de período de dirección.El azul es un hash de 26 bytes.

El desafío clave aquí es la compatibilidad atrasada.Los contratos existentes están diseñados en alrededor de 20 direcciones y a menudo se usan con técnicas de empaque de bytes ajustadas, lo que deja en claro que la dirección es exactamente de 20 bytes de largo.Una idea para resolver este problema es utilizar un gráfico de transformación donde un contrato de estilo antiguo que interactúe con una dirección de estilo nuevo verá un hash de 20 bytes de la dirección de estilo nuevo.Sin embargo, se necesita un esfuerzo considerable para garantizar su seguridad.

Abordar la contracción del espacio

Al revés: inmediatamente deshabilitamos algunas subrangos de dirección del tamaño 2128 (como todas las direcciones que comienzan con 0xffffffffff), y luego usamos ese rango para introducir direcciones con períodos de dirección y hash de 14 bytes.

0xfffffff000169125d5dfcb7b8c2659029395bdf

El sacrificio clave de este enfoque es que introduce riesgos de seguridad para las direcciones contrafactuales: direcciones que poseen activos o permisos, pero cuyo código no se ha publicado en la cadena.El riesgo involucra a alguien que crea una dirección que afirma tener un código (aún no publicado), pero hay otro código válido con el valor hash que apunta a la misma dirección.El cálculo de tales colisiones hoy requiere 280 hashes de dirección;

El área de riesgo crítico, no la dirección contrafactual de una billetera en poder de un solo propietario, es una situación relativamente rara hoy en día, pero a medida que ingresamos al mundo multi-L2, esta situación puede volverse más común.La única solución es simplemente aceptar este riesgo, pero identificar todos los casos de uso comunes donde los problemas pueden surgir y encontrar soluciones efectivas.

¿Qué investigación están disponibles?

Propuestas tempranas

Tarifa de alquiler de blockchain:https://github.com/ethereum/eips/issues/35

Regénesis:https://ethresear.ch/t/regenesis-resetting-ethereum-to-reduce-the-burden-of–large-blockchain-and-state/7582

Teoría de la gestión del tamaño del estado de Ethereum:https://hackmd.io/@vbuterin/state_size_management

Varios caminos posibles para el vencimiento de estado y estatal:https://hackmd.io/@vbuterin/state_expiry_paths

Algunas propuestas de expiración de estado

EIP-7736:https://eips.ethereum.org/eips/eip-7736

Documento extendido del espacio de dirección

Propuesta original:https://ethereum-magicians.org/t/increing-address-size-from-20-to-32-bytes/5485

Comentarios de iPsilon:https://notes.ethereum.org/@ipsilon/address-space-extension-exploration

Comentarios de la publicación del blog:https://medium.com/@chaisomsri96/statessness-series-part2-ase-address-space-extension-60626544b8e6

¿Qué sucede si perdemos la resistencia a la colisión?https://ethresear.ch/t/whatwould-break-if-we-lose-1dress-collision-resistant/11356

¿Qué más queda por hacer?¿Qué pesar?

Creo que hay cuatro caminos viables en el futuro:

• Practicamos la apatridia y nunca introducimos el vencimiento del estado.El estado está creciendo (aunque es más lento: es posible que no lo veamos más de 8 TB en décadas), pero solo necesita ser retenida por categorías de usuarios relativamente profesionales: incluso los validadores de POS no necesitan estado.

  Una característica que requiere acceso al estado parcial es incluir la generación de listas, pero podemosImplementar esto de manera descentralizada:Cada usuario es responsable de mantener la parte del árbol de estado que contiene su propia cuenta.Cuando transmiten transacciones, transmiten pruebas del objeto de estado a la que se accede durante el paso de verificación (esto se aplica a las cuentas EOA y ERC-4337).El validador sin estado puede combinar estas pruebas en la prueba completa que contiene la lista.

• Implementamos el vencimiento del estado parcial y aceptamos una tasa de crecimiento del tamaño de estado permanente mucho más baja pero aún no cero.Este resultado puede ser similar a una propuesta de vencimiento histórica que involucra redes entre pares, que acepta una tasa de crecimiento de almacenamiento histórico permanente que cada cliente debe almacenar un porcentaje más bajo pero fijo de datos históricos, pero es mucho más baja, pero aún no cero.

• Declaramos la fecha de vencimiento y extendemos el espacio de direcciones.Esto implicará un proceso de varios años para garantizar que los métodos de conversión del formato de dirección sean efectivos y seguros, incluso para las aplicaciones existentes.

• Declaramos la fecha de vencimiento y encogemos el espacio de direcciones.Esto implicará un proceso de varios años para garantizar que se manejen todos los riesgos de seguridad que involucran conflictos de abordación, incluidas situaciones de cadena cruzada.

Un punto importante es que se implementa si se implementa un esquema de vencimiento estatal que se basa en los cambios en el formato de dirección, el problema de la expansión del espacio de las direcciones y la contracción deben resolverse en última instancia.Hoy, se requieren aproximadamente 2^80 hash para generar conflictos de dirección, y esta carga de cómputo ya es factible para participantes extremadamente ricos en recursos: la GPU puede hacer aproximadamente 2^27 hashes, por lo que se puede ejecutar durante un año. se calculan, por lo que alrededor de 2^30 GPU en el mundo pueden calcular los conflictos en aproximadamente 1/4 del año, y los FPGA y los ASIC pueden acelerar aún más este proceso.En el futuro, tales ataques estarán abiertos a más y más personas.Por lo tanto, el costo real de implementar una expiración estatal completa puede no ser tan alto como parece, ya que tenemos que resolver este problema de dirección muy desafiante de todos modos.

¿Cómo interactúa con el resto de la hoja de ruta?

La ejecución de la expiración del estado puede facilitar la conversión de un formato de árbol de estado a otro porque no hay necesidad del proceso de conversión: simplemente puede comenzar a hacer un nuevo árbol con un nuevo formato y luego endurecerlo más tarde para convertir el árbol antiguo.Entonces, si bien la expiración del estado es compleja, ayuda a simplificar otros aspectos de la hoja de ruta.

Limpieza funcional

¿Qué problemas resuelve?

Uno de los requisitos previos clave para la seguridad, la accesibilidad y la confiabilidad es la simplicidad.Si el protocolo es hermoso y simple, se reduce la posibilidad de errores.Aumenta la posibilidad de que los nuevos desarrolladores puedan unirse y usar cualquier parte de ella.Es más probable que sea justo y sea más probable que se resistiera a intereses especiales.Desafortunadamente, los protocolos, como cualquier sistema social, se vuelven más complejos de forma predeterminada con el tiempo.Si no queremos llevar a Ethereum a un agujero negro cada vez más complejo, necesitamos hacer una de las dos cosas:(i) Deje de hacer cambios y rige el protocolo, (ii) poder eliminar las características y reducir la complejidad.También son posibles rutas intermedias, es decir, hacer menos cambios en el protocolo al tiempo que eliminan al menos un poco de complejidad con el tiempo.Esta sección analiza cómo reducir o eliminar la complejidad.

¿qué es?¿Cómo funciona?

No hay una sola solución grande que reduzca la complejidad del protocolo;

Un ejemplo básicamente hecho que puede usarse como un plan sobre cómo lidiar con otros problemas, a saber, eliminar el código de operación de autodestrucción.El código de operación de SelfDestruct es el único código de operación que puede modificar un número ilimitado de ranuras de almacenamiento dentro de un solo bloque, lo que requiere una mayor complejidad de los clientes para evitar ataques de DOS.El propósito original de este código de operación es lograr la limpieza del estado voluntario, lo que permite que el tamaño del estado disminuya con el tiempo.De hecho, pocas personas terminan usándolo.Este código de operación se debilita, lo que permite solo cuentas de autodestrucción creadas en la misma transacción en la bifurcación dura de Dencun.Esto resuelve problemas de DOS y permite una simplificación significativa del código del cliente.En el futuro, puede tener sentido eventualmente eliminar el código de operación por completo.

Algunos ejemplos clave de oportunidades de simplificación de protocolo identificadas hasta la fecha incluyen los siguientes.Primero, algunos ejemplos fuera de EVM;

• RLP → Conversión SSZ:Inicialmente, los objetos de Ethereum se serializaron utilizando una codificación llamada RLP.Hoy, las cadenas de baliza usan SSZ, que es significativamente mejor de muchas maneras, incluida no solo la serialización de apoyo sino también el hashing.En última instancia, queremos deshacernos de RLP por completo y mover todos los tipos de datos a la estructura SSZ, lo que a su vez facilita la actualización.Los EIP actualmente propuestos para esto incluyen [1] [2] [3].

• Eliminar tipos de transacciones antiguos:Hoy hay demasiados tipos de transacciones, y muchas de ellas pueden eliminarse.Una alternativa más modesta a la eliminación por completo es la función de abstracción de la cuenta, a través de la cual las cuentas inteligentes pueden contener códigos para procesar y verificar las transacciones heredadas (si lo desean).

• Reforma de registro:Los registros crean filtros Bloom y otra lógica, agregando complejidad al protocolo, pero debido a que es demasiado lento, el cliente en realidad no lo usa.Podemos eliminar estas características y, en su lugar, dedicar nuestra energía a alternativas, como las herramientas de lectura de registro descentralizadas fuera del protocolo utilizando tecnologías modernas como Snark.

• Finalmente, el mecanismo del Comité de Sincronización de la Cadena de Beacon se cancelará:El mecanismo del comité de sincronización se introdujo originalmente para permitir la autenticación de los clientes ligeros para Ethereum.Sin embargo, agrega la complejidad del protocolo.En última instancia, podremos usar Snark para verificar directamente la capa de consenso de Ethereum, que eliminará la necesidad de un protocolo de verificación de cliente de luz dedicado.Al crear un protocolo de cliente de luz más «nativo» que implica validar firmas de un subconjunto aleatorio del validador de consenso de Ethereum.

• Coordinación de coordinación del formato de datos:Hoy, el estado de ejecución se almacena en el árbol de Merkle Patricia, el estado de consenso se almacena en el árbol SSZ y las blobs se presentan como promete KZG.En el futuro, tiene sentido crear un solo formato unificado para datos de bloque y estado.Estos formatos cubrirán todas las necesidades importantes: (i) prueba simple de clientes sin estado, (ii) serialización y borrado de la codificación de datos, y (iii) estructuras de datos estandarizadas.

• Comité de Delete Beacon Chain:Inicialmente, este mecanismo se introdujo para apoyar versiones específicas de fragmentación de ejecución.En cambio, terminamos fragmentando a través de L2 y Blob.Por lo tanto, el comité es innecesario y está trabajando para eliminarlo.

• Eliminar el orden de bytes mixtos:EVM es una orden de bytes de grandes endian, y la capa de consenso es una orden de bytes pequeña.Puede tener sentido volver a coordinar y hacer todo en Big-Endian Endian (probablemente endian endian grande, ya que EVM es más difícil de cambiar).

Ahora, algunos ejemplos dentro de EVM:

• Simplifique el mecanismo de gas:Las reglas de gas actuales aún no han sido bien optimizadas, y es imposible limitar explícitamente el número de recursos necesarios para verificar el bloque.Los ejemplos clave de esto incluyen (i) costos de lectura/escritura de almacenamiento, diseñados para limitar los tiempos de lectura/escritura en un bloque, pero actualmente son muy arbitrarias, y (ii) reglas de relleno de memoria, que actualmente son difíciles de estimar el consumo máximo de memoria de el evm.Las soluciones recomendadas incluyen cambios de costos de gas sin estado, conciliar todos los costos relacionados con el almacenamiento en una fórmula simple y recomendaciones de precios de memoria.

• Eliminar la precompilación:Muchas de las precompilaciones que Ethereum tiene hoy en día son innecesarias y relativamente no utilizadas, y representan una gran proporción de riesgos de falla de consenso, pero en realidad no son utilizados por ninguna aplicación.Dos formas de lidiar con este problema son (i) eliminar directamente la precompilación y (ii) reemplazarlo con el código EVM (e inevitablemente más caro) que implementa la misma lógica.Este borrador de EIP recomienda que haga esto primero para la precompilación de identidad;

• Eliminar la observabilidad del gas:Hace que la ejecución de EVM ya no pueda ver cuánto gas le queda.Esto rompe algunas aplicaciones (la mayoría de las ofertas obviamente patrocinadas), pero se puede actualizar más fácilmente en el futuro (por ejemplo, para versiones de gas multidimensionales más avanzadas).La especificación EOF ha hecho que el gas no sea observable, pero para facilitar la simplificación del protocolo, el EOF debe ser obligatorio.

• Mejoras al análisis estático:El código EVM de hoy es difícil de realizar un análisis estático, especialmente porque los saltos pueden ser dinámicos.Esto también hace que sea más difícil hacer una implementación EVM optimizada (precompilar el código EVM a otros idiomas).Podemos resolver este problema eliminando saltos dinámicos (o haciéndolos más caros, por ejemplo, los costos de gas están relacionados linealmente con el número total de saltos en el contrato).Esto es lo que hace EOF, pero obtener los beneficios de la simplificación del protocolo de la misma requiere hacer que EOF sea obligatorio.

¿Qué investigación están disponibles?

Siguientes pasos para la purga:https://notes.ethereum.org/i_aihysjttcyau_adoy2ta

Self Destruct:https://hackmd.io/@vbuterin/selfdestruct

EIPS de SSZ-ificacióne: [1] [2] [3]

Cambios de costos de gas sin estado:https://eips.ethereum.org/eips/eip-4762

Precio de memoria lineal:https://notes.ethereum.org/ljptsqbgr2knssu0yurwxw

Precompilado y eliminado:https://notes.ethereum.org/iwtx22ymqde1k_fz9psxig

Extracción del filtro de floración:https://eips.ethereum.org/eips/eip-7668

Un método para la recuperación de registro segura fuera de la cadena utilizando cálculos verificables incrementales (léase: Stark recursivo):https://notes.ethereum.org/xzuqy8znt3keg1pkzpefxw

¿Qué más debo hacer y qué compensaciones hay?

La principal compensación para dicha simplificación funcional es (i) el grado y la velocidad de nuestra simplificación con (ii) compatibilidad con versiones anteriores.El valor de Ethereum como cadena es que es una plataforma donde puede implementar aplicaciones y asegurarse de que aún funcionará correctamente después de muchos años.Al mismo tiempo, también es posible poner este ideal demasiado lejos, en palabras de William Jennings Brian, «clavar Ethereum en la cruz de la compatibilidad hacia atrás».Si solo dos aplicaciones en todo Ethereum usan una función, una de las cuales no tiene usuarios durante años y la otra casi no tiene uso y ha recibido un total de $ 57, entonces debemos eliminar la función, si es necesario, puede pagar $ 57. de tu propio bolsillo a la víctima.

El problema social más amplio es crear una tubería estandarizada para los cambios disruptivos no urgentes de compatibilidad hacia atrás.Una forma de resolver este problema es verificar y extender los precedentes existentes, como el proceso de autocontrol.La tubería se ve así:

• Paso 1:Comience a discutir la función de eliminación X.

• Paso 2:Realice un análisis para determinar cuánto destructiva se debe hacer la aplicación eliminando X, elija (i) abandonar la idea, (ii) proceder según lo planeado, o (iii) para determinar un método de X de eliminación «mínimo» modificado que elimina X y continuar.

• Paso 3:Cree un EIP formal para desaprobar X.Asegúrese de que las infraestructuras avanzadas populares (como los lenguajes de programación, las billeteras) respeten esto y deje de usar la función.

• Paso 4:Finalmente, en realidad elimina X.

Debe haber un proceso de años entre los pasos 1 y 4, y establecer claramente qué proyectos están en qué paso.En este punto, existe una compensación entre la fuerza y ​​la velocidad del proceso de eliminación de características y las áreas más conservadoras y otras áreas de invertir más recursos en el desarrollo del protocolo, pero todavía estamos lejos de la vanguardia de Pareto.

EOF

Uno de los principales cambios propuestos para EVM es el formato de objeto EVM (EOF).EOF introduce muchos cambios, como prohibir la observabilidad del gas, la observabilidad del código (es decir, sin codecopia) y permitir solo saltos estáticos.El objetivo es permitir que los EVM realicen más actualizaciones para tener propiedades más potentes mientras mantienen la compatibilidad hacia atrás (porque EVMS antes de EOF todavía existen).

El beneficio de esto es que crea un camino natural para agregar nuevas capacidades EVM y alentar la migración a EVM más estrictas con garantías más fuertes.Su desventaja es que aumenta significativamente la complejidad del protocolo a menos que podamos encontrar formas de desaprobar y eliminar los viejos EVM.Un problema importante es:¿Qué papel juega EOF en las propuestas de simplificación EVM, especialmente si el objetivo es reducir la complejidad de todo el EVM?

¿Cómo interactúa con el resto de la hoja de ruta?

Muchas de las propuestas de «mejoras» en el resto de la hoja de ruta también son oportunidades para simplificar las características antiguas.Repita algunos ejemplos anteriores:

• Cambiar a la finalidad de un solo ranura nos brinda la oportunidad de cancelar los comités, la economía de reingenieras y hacer otras simplificaciones relacionadas con la prueba de participación.

• La implementación de la abstracción de la cuenta completamente nos permite eliminar muchas lógicas de procesamiento de transacciones existentes al moverla a un «código EVM de cuenta predeterminado» con el que todos los EOA pueden ser reemplazados.

• Si trasladamos el estado de Ethereum al árbol hash binario, esto puede coordinarse con la nueva versión de SSZ para que todas las estructuras de datos de Ethereum se puedan hacer de la misma manera.

Un enfoque más radical: convertir la mayor parte del protocolo en código de contrato

Una estrategia de simplificación de Ethereum más radical es mantener el protocolo tal como es, pero transformar gran parte del protocolo de la funcionalidad del protocolo al código de contrato.

La versión más extrema es hacer que Ethereum L1 «técnicamente» solo las cadenas de baliza e introducir una VM mínima (como RISC-V, El Cairo o VM más simples utilizadas específicamente para probar el sistema) que permiten a cualquier otra persona crearse resumen.Entonces, el EVM será el primero de estos resúmenes.Irónicamente, este es exactamente el mismo resultado que la propuesta de entorno de implementación 2019-20, aunque Snark hace que sea más factible implementarlo realmente.

Un enfoque más modesto es mantener la relación entre la cadena de baliza y el entorno de ejecución de Ethereum actual sin cambios, pero intercambiar EVM en el lugar.Podemos elegir RISC-V, El Cairo u otras máquinas virtuales como la nueva «VM oficial de Ethereum» y luego emitir todos los contratos EVM en un nuevo código VM que interpreta la lógica del código original (por compilación o interpretación).En teoría, incluso es posible hacer esto con la «VM objetivo» como la versión EOF.

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