El creador de Ethereum, Vitalik Buterin, anunció el siguiente paso de la red: eliminar el peso extra. Lo llama "La Purga"
En la quinta entrada de su serie, Vitalik presentó un plan implacable para eliminar la sobrecarga de la blockchain, eliminar las funciones redundantes y optimizar el protocolo. La red de Ethereumestá saturada de transacciones obsoletas y funciones heredadas complejas.
¿La solución? Vitalik quiere eliminar los datos históricos y de estado, simplificar las funciones del protocolo y facilitar la ejecución de los nodos. Esta decisión drástica responde al rápido crecimiento de los datos de Ethereum.
En este momento, un nodo Ethereum completo requiere más de 1,1 terabytes de almacenamiento solo para el cliente de ejecución, y más para los datos de consenso.
A medida que se acumulan las transacciones y las cuentas, el almacenamiento debe crecer, lo que crea cuellos de botella. Sin cambios, Ethereum corre el riesgo de volverse lento, y los nuevos clientes se enfrentan a tiempos de sincronización extremadamente largos solo para actualizarse con la cadena.
Caducidad del historial: reducción de la carga de memoria de Ethereum
En lugar de que cada nodo conserve todas las transacciones registradas, Vitalik sugiere que los nodos conserven únicamente los datos recientes. Los bloques históricos, las transacciones más antiguas y los recibos se distribuyen entre los nodos en pequeñas porciones.
Para Vitalik, los datos históricos deberían funcionar como una red de torrents: los nodos almacenan fragmentos de datos, lo que garantiza su disponibilidad sin que un solo nodo los contenga todos. «Hablamos de cientos de gigabytes de bloques antiguos que se acumulan cada año», explicó.
El modelo actual, con nodos que almacenan todos los datos, ya se ha ajustado. Los bloques de consenso, vitales para la prueba de participación, se almacenan durante seis meses, mientras que los blobs (bloques de datos de transacciones más grandes) desaparecen después de 18 días.
La nueva propuesta de Vitalik, EIP-4444, promueve un límite de almacenamiento de un año para bloques y recibos históricos. ¿Su objetivo final? Una red distribuida donde cada nodo almacena solo una fracción del historial, utilizando pruebas de Merkle y codificación de borrado para garantizar la precisión.
Este almacenamiento distribuido del historial no reducirá la fiabilidad de los datos de Ethereum. Vitalik afirma que, al aumentar el número de nodos, las copias de datos se multiplicarán en la red, garantizando así un buen respaldo de cada fragmento del historial.
La codificación de borrado aumentará la resiliencia, similar a la tecnología que permite que los blobs permanezcan disponibles para el muestreo de datos. Vitalik también señala la Red Portal y los métodos peer-to-peer como posibles soluciones, permitiendo Ethereum gestionar la distribución de sus datos sin depender de un almacenamiento centralizado.
Caducidad del estado: limitar la permanencia de los datos
Más allá del historial, la purga de Vitalik incluye un problema más complejo: la "expiración del estado". A diferencia del historial, los datos de estado (como saldos de cuentas, nonces y almacenamiento detracinteligentes) son más difíciles de expirar. Una vez creado, un objeto de estado (como una cuenta con ETH o el espacio de almacenamiento de untrac) permanece accesible para cualquier transacción.
Y con cada objeto, los datos de Ethereumcrecen. Para contener esto, Vitalik propone la expiraciónmatic , eliminando los datos que no se han modificado recientemente. La clave está en equilibrar la expiración del estado con la permanencia de Ethereum.
Cree que los usuarios deberían poder "desaparecer durante cinco años, regresar y seguir accediendo a sus fondos". Este sistema necesita eficiencia: no requiere cálculos adicionales ni modelos complejos para los desarrolladores.
Ethereum ha probado varias ideas, como la "renta de blockchain", que cobraba a los usuarios por mantener sus datos activos, y la "regénesis", que intentaba reiniciar la blockchain para reducir los datos. Ninguna de ellas prosperó.
Dos nuevas propuestas abordan la sobreabundancia de estados. En primer lugar, está la "expiración parcial de estados". La red dividiría los datos en fragmentos, almacenando solo los fragmentos recientes y preservando los "stubs" (pequeños fragmentos de datos inactivos) para demostrar su existencia.
Si se elimina un fragmento, los usuarios pueden recuperarlo con evidencia de datos anteriores. La propuesta de diseño de Vitalik, EIP-7736, utiliza árboles Verkle y un modelo de "tallo y hoja" para agrupar los datos. Cualquier dato intacto durante seis meses se elimina, dejando solo un fragmento que se puede restaurar cuando sea necesario.
La segunda idea es la expiración basada en el período de dirección, que divide los objetos de estado por tiempo. Cada cuenta tiene un "período de dirección" y solo se almacenan los datos de los dos períodos más recientes.
Si alguien desea recuperar datos antiguos, deberá enviar una prueba de Merkle para restablecerlos. Esta configuración basada en períodos requerirá cambiar los formatos de dirección y ampliar el formato actual de 20 bytes para incluir números de versión y períodos.
Vitalik también sugiere latracdel espacio de direcciones para mantener la compatibilidad. El reto será entonces asegurar que los usuarios comprendan y confíen en este sistema temporal sin sacrificar la promesa fundamental de Ethereum: la disponibilidad.
Limpieza de funciones: Reducción de la complejidad del código de Ethereum
La fase final de la purga afecta la complejidad del protocolo. Vitalik afirma: «Cada nueva característica dificulta el uso Ethereum , pero eliminar cualquier característica es una pesadilla». El ejemplo más infame es SELFDESTRUCT, un código de operación que permite a los usuarios eliminar el almacenamiento detrac.
Originalmente, permitía la limpieza voluntaria del estado, pero prácticamente no se usa y presenta riesgo de ataques de denegación de servicio. La bifurcación dura Dencun de Ethereumdebilitó el código de operación, y Vitalik planea eliminarlo por completo pronto.
Otras características sofisticadas incluyen tipos de transacción antiguos, formatos de datos redundantes y una configuración de protocolo de endianidad mixta. Estas peculiaridades dificultan el desarrollo y la actualización Ethereum .
La lista de limpieza de Vitalik también incluye la transición de formatos de datos de RLP a SSZ, la simplificación de las reglas de gas para una mejor gestión de los recursos de los bloques y la eliminación de precompilaciones no utilizadas como RIPEMD160, MODEXP y BLAKE. También apoya la migración Ethereum a un modelo de cliente sin estado, lo que eliminaría la carga de almacenamiento para la mayoría de los nodos.
Algunos de estos cambios requerirán latracde cuentas, lo que permitirá a los usuarios gestionar tipos de transacciones heredados mediante el código EVM de cuenta predeterminado. Esto, según Vitalik, simplificará la Máquina Virtual Ethereum (EVM) y reducirá el tamaño del código. A largo plazo, la propia EVM podría actualizarse.
Explica que los desarrolladores Ethereum están considerando un nuevo modelo de ejecución como RISC-V o Cairo, o posiblemente usar un formato de objeto EVM (EOF) para estandarizar las reglas del código.
EOF modifica las reglas del gas y prohíbe ciertas instrucciones para permitir actualizaciones modulares, impulsando así la escalabilidad de Ethereum. Según se informa, este formato permitirá a los desarrolladores realizar mejoras graduales, lo que en última instancia ayudará Ethereum a mantener su eficiencia.
Pero Vitalik ofreció otra opción. Afirma : «Una estrategia de simplificación más radical Ethereum consiste en mantener el protocolo tal como está, pero trasladar gran parte de él de ser características del protocolo a trac ».
