Vitalik ha mencionado conjuntamente un tema en la reciente Korean Blockchain Week, en el discurso de Singapur e incluso en la Ethereum Executive Core Developer Conference (ACDE): el estado, y lo que sigue está relacionado con él. Varios conceptos de solución, como sin estado, vencimiento del estado (State Expiry ), caducidad de datos históricos (EIP-4444), árbol Verkle e incluso expansión\compresión del espacio de direcciones (Expansión del espacio de direcciones\Compresión). Por supuesto, este no es en realidad un nuevo plan de ajuste de la hoja de ruta. En la última hoja de ruta de Ethereum publicada por Vitalik en noviembre del año pasado, estos pertenecen principalmente a las rutas clave de The Verge y The Purge.
Este artículo combina estas dos rutas clave y algunos nuevos desafíos de pensamiento para revisar la ruta de solución estatal de Vitalik.
Estado
Estado en Ethereum se refiere a un libro de contabilidad completo que incluye todas las cuentas de propiedad externa (EOA), sus saldos, implementaciones de contratos inteligentes y almacenamiento asociado. Este estado no es estático; continúa expandiéndose a medida que se agregan nuevos usuarios y se implementan nuevos contratos inteligentes.
Actualmente, los nodos completos deben almacenar este conjunto de datos en constante crecimiento para validar adecuadamente los bloques y garantizar transiciones de estado correctas, lo que hace que el proceso de validación tenga un estado por naturaleza. Este creciente requisito de almacenamiento, que aumenta así los requisitos de hardware para ejecutar nodos completos, conducirá a validadores cada vez más centralizados.
Según los datos de etherscan.io/, actualmente ejecutar un nodo completo de sincronización rápida requiere al menos 1200 Gb (tomando el cliente Geth como ejemplo). Esto ocurre después de que se ha realizado la poda de estado, los datos del estado anterior se eliminan y solo los datos más Se mantiene el estado reciente. La premisa. Si es un nodo de archivo, es decir, el nodo completo conservará todos los estados históricos, incluido el estado de cada bloque, entonces la capacidad requerida será de unos 15.400 Gb y seguirá creciendo en el futuro, que es lo que La comunidad a menudo llama "explosión estatal".
Esto es lo que Vitalik enfatizó en la Korea Blockchain Week: la centralización de nodos es uno de los mayores problemas que enfrenta la red Ethereum y debería resolverse haciendo que los nodos sean más baratos y más fáciles de ejecutar.
Para hacer frente a esta serie de desafíos, la comunidad Ethereum ha estado trabajando arduamente para encontrar formas de mejorar y optimizar, es decir, los diversos conceptos de solución que ejemplificamos al principio.
Solución de estado
Apatridia
El concepto central de stateless es externalizar datos de estado, eliminando la necesidad de que cada nodo almacene el estado completo. En este modo, los nodos solo necesitan mantener los encabezados de los bloques y la información de transacciones relacionadas, y verificar y reconstruir el estado a través de pruebas de estado (Pruebas de estado).
La función principal y la importancia de la apatridia es reducir la carga de almacenamiento de los nodos, mejorar la escalabilidad de la red y permitir que más nodos participen fácilmente en la verificación, manteniendo al mismo tiempo la naturaleza descentralizada de Ethereum.
Árbol Verkle
Actualmente, Ethereum depende de los árboles Merkle-Patricia para realizar hash y comprimir sus datos de estado. Sin embargo, el tamaño de las pruebas de Merkle en tales estructuras de árbol puede volverse demasiado grande, haciéndolas menos adecuadas para los testigos requeridos por los modelos sin estado.
Para resolver este problema, Ethereum planea hacer la transición a árboles Verkle, una estructura de datos más eficiente. Los árboles Merkle-Patricia y Verkle comparten una habilidad importante, que es generar testigos: pruebas criptográficas que permiten a cualquiera confirmar fácilmente la existencia y disponibilidad pública de información específica en la raíz del estado.
La ventaja de los árboles Verkle es que son más eficientes a la hora de generar tamaños de prueba más pequeños.
Caducidad del historial, EIP-4444
EIP-4444 tiene como objetivo implementar la caducidad de datos históricos, una actualización que requiere que los nodos dejen de alojar bloques históricos de más de un año en la red peer-to-peer. La eliminación de datos históricos alivia significativamente los requisitos de espacio en disco para los operadores de nodos. Al mismo tiempo, también simplifica el software del cliente al eliminar la necesidad de adaptar el código para diferentes versiones de bloques históricos. Además, la combinación de EIP-4444 y PDS (Proto-danksharding) garantiza una poda de datos regular; EIP-4444 poda una vez al año, mientras que PDS poda los bloques de datos una vez al mes. Si bien esto ayuda a reducir las necesidades de almacenamiento de datos de los nodos, también genera preocupaciones sobre la preservación y recuperación de datos históricos.
Caducidad del estado
La apatridia elimina la necesidad de que los validadores mantengan el estado completo al validar bloques. Pero el estado no va a desaparecer; su crecimiento continuo sigue siendo un desafío a largo plazo para la web.
Para resolver este problema fundamental, la comunidad propuso la solución State Expiry.
La expiración del estado podará automáticamente aquellas partes del estado que permanezcan sin cambios durante, digamos, un año, moviéndolas a una estructura de árbol separada y eliminándolas del protocolo principal de Ethereum.
Vale la pena mencionar que la caducidad del estado solo es factible después de migrar a los árboles Verkle. Además, Vitalik dijo en la Korean Blockchain Week KBW 2023: Si hay apatridia y PBS, la caducidad del estado puede ser de baja prioridad.
Porque si para entonces se implementa la Separación Proponente-Constructor (PBS), en el estado sin estado, aunque el constructor de bloques todavía necesita acceder al estado para crear el bloque, en ese momento ya se esperaba que el constructor de bloques pudiera hacerlo de manera efectiva. Manejar el crecimiento del estado, debido a que esta área permite un cierto grado de centralización, el rendimiento del nodo de los constructores puede naturalmente satisfacer las necesidades.
Aunque el PBS a nivel de protocolo aún no se ha incluido en la red principal de Ethereum, podemos comprender aproximadamente la tendencia futura de la red principal al comprender la distribución actual del mercado de Mev-Boost PBS. Las estadísticas de datos de mevboost.pics son las siguientes:
Además, la implementación de State Expiry implica cambios en el formato de dirección de Ethereum. Actualmente existen dos soluciones: extensión del espacio de direcciones versus compresión del espacio de direcciones. El primero aumenta la longitud de la dirección a 32 bytes (el formato de dirección actual es de 20 bytes), pero requiere una lógica compleja para la compatibilidad con versiones anteriores y el contrato existente también debe actualizarse; aunque el segundo conserva el formato de 20 bytes, cambia el anterior. Se utilizan 6 bytes para identificar el prefijo y el ciclo de direcciones. Aunque esto reduce en gran medida el problema de compatibilidad, también genera otro problema: la longitud de la dirección es de solo 14 bytes y ya no tiene la capacidad de resistir colisiones, lo que introduce algunas direcciones. Los posibles problemas de seguridad creados también son un desafío importante que enfrenta actualmente la comunidad.
Resumir
Ahora, podemos eliminar aproximadamente las prioridades delantera y trasera (2 \ 3 \ 4 pueden ser iguales) según los problemas de implementación y las prioridades de las soluciones técnicas anteriores:
árbol verkle
PBS
Apátrida
Datos históricos caducados (EIP-4444)
Cambios en el formato de dirección de Ethereum (compresión/expansión)
Caducidad del estado
En resumen, se puede reducir el umbral de operación del nodo, se pueden mantener la descentralización del nodo y los posibles problemas de explosión del estado, y se puede reducir el crecimiento del estado para optimizar la carga de comunicación de la red.
Por supuesto, todavía queda un largo camino por recorrer.
Enlaces de referencia:
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
¿Qué es "apátrida" que Vitalik mencionó frecuentemente en sus últimos discursos?
Compilación original: GaryMa Wu Shuo Blockchain
Vitalik ha mencionado conjuntamente un tema en la reciente Korean Blockchain Week, en el discurso de Singapur e incluso en la Ethereum Executive Core Developer Conference (ACDE): el estado, y lo que sigue está relacionado con él. Varios conceptos de solución, como sin estado, vencimiento del estado (State Expiry ), caducidad de datos históricos (EIP-4444), árbol Verkle e incluso expansión\compresión del espacio de direcciones (Expansión del espacio de direcciones\Compresión). Por supuesto, este no es en realidad un nuevo plan de ajuste de la hoja de ruta. En la última hoja de ruta de Ethereum publicada por Vitalik en noviembre del año pasado, estos pertenecen principalmente a las rutas clave de The Verge y The Purge.
Este artículo combina estas dos rutas clave y algunos nuevos desafíos de pensamiento para revisar la ruta de solución estatal de Vitalik.
Estado
Estado en Ethereum se refiere a un libro de contabilidad completo que incluye todas las cuentas de propiedad externa (EOA), sus saldos, implementaciones de contratos inteligentes y almacenamiento asociado. Este estado no es estático; continúa expandiéndose a medida que se agregan nuevos usuarios y se implementan nuevos contratos inteligentes.
Actualmente, los nodos completos deben almacenar este conjunto de datos en constante crecimiento para validar adecuadamente los bloques y garantizar transiciones de estado correctas, lo que hace que el proceso de validación tenga un estado por naturaleza. Este creciente requisito de almacenamiento, que aumenta así los requisitos de hardware para ejecutar nodos completos, conducirá a validadores cada vez más centralizados.
Según los datos de etherscan.io/, actualmente ejecutar un nodo completo de sincronización rápida requiere al menos 1200 Gb (tomando el cliente Geth como ejemplo). Esto ocurre después de que se ha realizado la poda de estado, los datos del estado anterior se eliminan y solo los datos más Se mantiene el estado reciente. La premisa. Si es un nodo de archivo, es decir, el nodo completo conservará todos los estados históricos, incluido el estado de cada bloque, entonces la capacidad requerida será de unos 15.400 Gb y seguirá creciendo en el futuro, que es lo que La comunidad a menudo llama "explosión estatal".
Esto es lo que Vitalik enfatizó en la Korea Blockchain Week: la centralización de nodos es uno de los mayores problemas que enfrenta la red Ethereum y debería resolverse haciendo que los nodos sean más baratos y más fáciles de ejecutar.
Para hacer frente a esta serie de desafíos, la comunidad Ethereum ha estado trabajando arduamente para encontrar formas de mejorar y optimizar, es decir, los diversos conceptos de solución que ejemplificamos al principio.
Solución de estado
Apatridia
El concepto central de stateless es externalizar datos de estado, eliminando la necesidad de que cada nodo almacene el estado completo. En este modo, los nodos solo necesitan mantener los encabezados de los bloques y la información de transacciones relacionadas, y verificar y reconstruir el estado a través de pruebas de estado (Pruebas de estado).
La función principal y la importancia de la apatridia es reducir la carga de almacenamiento de los nodos, mejorar la escalabilidad de la red y permitir que más nodos participen fácilmente en la verificación, manteniendo al mismo tiempo la naturaleza descentralizada de Ethereum.
Árbol Verkle
Actualmente, Ethereum depende de los árboles Merkle-Patricia para realizar hash y comprimir sus datos de estado. Sin embargo, el tamaño de las pruebas de Merkle en tales estructuras de árbol puede volverse demasiado grande, haciéndolas menos adecuadas para los testigos requeridos por los modelos sin estado.
Para resolver este problema, Ethereum planea hacer la transición a árboles Verkle, una estructura de datos más eficiente. Los árboles Merkle-Patricia y Verkle comparten una habilidad importante, que es generar testigos: pruebas criptográficas que permiten a cualquiera confirmar fácilmente la existencia y disponibilidad pública de información específica en la raíz del estado.
La ventaja de los árboles Verkle es que son más eficientes a la hora de generar tamaños de prueba más pequeños.
Caducidad del historial, EIP-4444
EIP-4444 tiene como objetivo implementar la caducidad de datos históricos, una actualización que requiere que los nodos dejen de alojar bloques históricos de más de un año en la red peer-to-peer. La eliminación de datos históricos alivia significativamente los requisitos de espacio en disco para los operadores de nodos. Al mismo tiempo, también simplifica el software del cliente al eliminar la necesidad de adaptar el código para diferentes versiones de bloques históricos. Además, la combinación de EIP-4444 y PDS (Proto-danksharding) garantiza una poda de datos regular; EIP-4444 poda una vez al año, mientras que PDS poda los bloques de datos una vez al mes. Si bien esto ayuda a reducir las necesidades de almacenamiento de datos de los nodos, también genera preocupaciones sobre la preservación y recuperación de datos históricos.
Caducidad del estado
La apatridia elimina la necesidad de que los validadores mantengan el estado completo al validar bloques. Pero el estado no va a desaparecer; su crecimiento continuo sigue siendo un desafío a largo plazo para la web.
Para resolver este problema fundamental, la comunidad propuso la solución State Expiry.
La expiración del estado podará automáticamente aquellas partes del estado que permanezcan sin cambios durante, digamos, un año, moviéndolas a una estructura de árbol separada y eliminándolas del protocolo principal de Ethereum.
Vale la pena mencionar que la caducidad del estado solo es factible después de migrar a los árboles Verkle. Además, Vitalik dijo en la Korean Blockchain Week KBW 2023: Si hay apatridia y PBS, la caducidad del estado puede ser de baja prioridad.
Porque si para entonces se implementa la Separación Proponente-Constructor (PBS), en el estado sin estado, aunque el constructor de bloques todavía necesita acceder al estado para crear el bloque, en ese momento ya se esperaba que el constructor de bloques pudiera hacerlo de manera efectiva. Manejar el crecimiento del estado, debido a que esta área permite un cierto grado de centralización, el rendimiento del nodo de los constructores puede naturalmente satisfacer las necesidades.
Aunque el PBS a nivel de protocolo aún no se ha incluido en la red principal de Ethereum, podemos comprender aproximadamente la tendencia futura de la red principal al comprender la distribución actual del mercado de Mev-Boost PBS. Las estadísticas de datos de mevboost.pics son las siguientes:
Además, la implementación de State Expiry implica cambios en el formato de dirección de Ethereum. Actualmente existen dos soluciones: extensión del espacio de direcciones versus compresión del espacio de direcciones. El primero aumenta la longitud de la dirección a 32 bytes (el formato de dirección actual es de 20 bytes), pero requiere una lógica compleja para la compatibilidad con versiones anteriores y el contrato existente también debe actualizarse; aunque el segundo conserva el formato de 20 bytes, cambia el anterior. Se utilizan 6 bytes para identificar el prefijo y el ciclo de direcciones. Aunque esto reduce en gran medida el problema de compatibilidad, también genera otro problema: la longitud de la dirección es de solo 14 bytes y ya no tiene la capacidad de resistir colisiones, lo que introduce algunas direcciones. Los posibles problemas de seguridad creados también son un desafío importante que enfrenta actualmente la comunidad.
Resumir
Ahora, podemos eliminar aproximadamente las prioridades delantera y trasera (2 \ 3 \ 4 pueden ser iguales) según los problemas de implementación y las prioridades de las soluciones técnicas anteriores:
árbol verkle
PBS
Apátrida
Datos históricos caducados (EIP-4444)
Cambios en el formato de dirección de Ethereum (compresión/expansión)
Caducidad del estado
En resumen, se puede reducir el umbral de operación del nodo, se pueden mantener la descentralización del nodo y los posibles problemas de explosión del estado, y se puede reducir el crecimiento del estado para optimizar la carga de comunicación de la red.
Por supuesto, todavía queda un largo camino por recorrer.
Enlaces de referencia: