El creador de Ethereum , Vitalik Buterin, anunció el siguiente paso de la red, que es eliminar el peso extra. Lo llama "La Purga".
En la quinta publicación de blog de su serie, Vitalik presentó un plan despiadado para eliminar la inflación de blockchain, eliminar funciones redundantes y optimizar el protocolo. La red de Ethereum está atascada con transacciones obsoletas y características heredadas complicadas.
¿La solución? Vitalik quiere que se seleccionen los datos históricos y estatales, que se simplifiquen las funciones del protocolo y que los nodos sean más fáciles de ejecutar. Esta decisión agresiva es una respuesta al rápido crecimiento de 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 las transacciones y las cuentas se acumulan, el almacenamiento debe crecer, lo que genera cuellos de botella. Sin cambios, Ethereum corre el riesgo de volverse lento, y los nuevos clientes enfrentan tiempos de sincronización dolorosamente largos solo para ponerse al día con la cadena.
Caducidad del historial: Reducción de la carga de memoria de Ethereum
En lugar de que cada nodo contenga todas las transacciones jamás registradas, Vitalik sugiere que los nodos solo retengan 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 bits de datos, lo que garantiza la disponibilidad de los datos sin que un nodo lo contenga todo. "Estamos hablando de cientos de gigabytes de bloques antiguos que se acumulan cada año", afirmó.
El modelo actual, en el que los nodos contienen todos los datos, ya ha sido 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, impulsa 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 Merkle y codificación de borrado para garantizar la precisión.
Este almacenamiento de historial distribuido no reducirá la confiabilidad 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, lo que hará que cada fragmento del historial esté bien respaldado.
La codificación de borrado agregará resiliencia, similar a la tecnología que ayuda a 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 a Ethereum gestionar su distribución de datos sin depender del almacenamiento centralizado.
Caducidad del estado: limitar la permanencia de los datos
Más allá de la historia, la purga de Vitalik incluye una bestia más complicada: la “caducidad del estado”. A diferencia de la historia, los datos estatales (cosas como saldos de cuentas, nonces y almacenamiento de trac inteligentes) son más difíciles de vencer. Una vez creado, un objeto de estado (como una cuenta con ETH o la ranura de almacenamiento de un trac ) permanece accesible para cualquier transacción.
Y con cada objeto, los datos de Ethereum crecen. Para contener esto, Vitalik propone la matic automática, recortando los datos que no se han tocado recientemente. El truco consiste en equilibrar la caducidad del estado con la permanencia de Ethereum .
Él cree que los usuarios deberían poder “desaparecer durante cinco años, regresar y seguir accediendo a sus fondos”. Este sistema necesita eficiencia, sin cálculos adicionales ni modelos complejos para los desarrolladores.
Ethereum ha probado varias ideas como el "alquiler de blockchain", que cobra a los usuarios por mantener vivos sus datos, y la "regénesis", que intenta restablecer el blockchain para reducir los datos. Ninguno de los dos despegó.
Dos nuevas propuestas apuntan a la inflación del Estado. En primer lugar, está la “vencimiento parcial del estado”. La red dividiría los datos en fragmentos, almacenando solo fragmentos recientes y preservando "stubs" (pequeños fragmentos de datos inactivos) para demostrar su existencia.
Si se elimina un fragmento, los usuarios pueden revivirlo con prueba de datos anteriores. La propuesta de diseño de Vitalik, EIP-7736, utiliza árboles Verkle y un modelo de "tallo y hoja" para agrupar datos. Cualquier dato que no se haya modificado durante seis meses se elimina, dejando solo un talón para restaurar cuando sea necesario.
La segunda idea es la caducidad 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 datos de los dos períodos más recientes.
Si alguien quiere datos antiguos, presentará una prueba de Merkle para restablecerlos. Esta configuración basada en períodos requerirá cambiar los formatos de dirección, expandiendo el formato actual de 20 bytes para incluir números de versión y puntos.
Vitalik también sugiere la trac del espacio de direcciones para mantener la compatibilidad. El desafío entonces será asegurarse de que los usuarios comprendan y confíen en este sistema de período sin sacrificar la promesa principal de disponibilidad de Ethereum .
Limpieza de funciones: Recortar la complejidad del código de Ethereum
La fase final de la purga afecta a la complejidad del protocolo. Vitalik dice: "Cada característica nueva hace que Ethereum sea más difícil de usar, pero eliminar cualquier cosa es una pesadilla". El ejemplo más infame es SELFDESTRUCT, un código de operación que permite a los usuarios eliminar el almacenamiento de trac .
Originalmente, permitía la limpieza estatal voluntaria, pero en su mayor parte no se utiliza y corre el riesgo de sufrir ataques de denegación de servicio. La bifurcación dura Dencun de Ethereum debilitó el código de operación y Vitalik planea eliminarlo por completo pronto.
Otras características infladas incluyen tipos de transacciones antiguos, formatos de datos redundantes y una configuración de protocolo de endianidad mixta. Estas peculiaridades hacen que el desarrollo sea confuso y Ethereum sea más difícil de actualizar.
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 del gas para administrar mejor los recursos del bloque y la eliminación de precompilaciones no utilizadas como RIPEMD160, MODEXP y BLAKE. También apoya trasladar Ethereum a un modelo de cliente sin estado, lo que eliminaría las cargas de almacenamiento para la mayoría de los nodos.
Algunos de estos cambios requerirán la trac de la cuenta, lo que permitirá a los usuarios manejar tipos de transacciones heredadas a través del "código EVM de cuenta predeterminado". Esto, dice Vitalik, simplificará la máquina virtual Ethereum (EVM) y al mismo tiempo reducirá el tamaño del código. A largo plazo, el propio EVM podría recibir una actualización.
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 cambia las reglas del gas y prohíbe ciertas instrucciones para permitir actualizaciones modulares, lo que aumenta la escalabilidad de Ethereum . Según se informa, este formato permitirá a los desarrolladores realizar mejoras incrementales y, en última instancia, ayudará a que Ethereum se mantenga eficiente.
Pero Vitalik sí le dio otra opción. Dice : "Una estrategia de simplificación Ethereum más radical es mantener el protocolo como está, pero trasladar gran parte del mismo de características del protocolo a código de trac ".