Resumen

• Las crecientes demandas de almacenamiento presentan desafíos significativos para los nodos de Ethereum.
• Algunos clientes han comenzado a podar los datos históricos debido a limitaciones de almacenamiento, lo que ha dado lugar a comportamientos de almacenamiento inconsistentes entre los nodos completos en la red.
• Para garantizar la alineación en todos los clientes, la poda de datos históricos se está estandarizando en EIP-4444 y EIP-4844
• En consecuencia, recuperar el estado más reciente de L1 o L2 mediante la reproducción de datos históricos depende de servicios centralizados, fuera del protocolo, lo que ha llevado a la exploración de soluciones alineadas con Ethereum más descentralizadas
• La red del portal de Ethereum es una red P2P ligera y descentralizada para todo tipo de datos de Ethereum, incluidos los datos históricos. Está diseñada para dispositivos con recursos limitados y proporciona el servicio JSON-RPC de Ethereum. La red histórica y la red de beacons están casi listas para usar.
• La red de almacenamiento de EthStorage es una red de almacenamiento modular incentivada para BLOBs EIP-4844. Para almacenar un BLOB, un usuario llama al contrato de almacenamiento L1 put()método con el hash BLOB y una tarifa en ETH. La tarifa se distribuirá gradualmente a los proveedores de almacenamiento al enviar una prueba válida de almacenamiento de BLOB fuera de la cadena con el tiempo. La red de prueba EthStorage se ejecuta en la red de prueba Ethereum Sepolia con múltiples participantes de la comunidad que demuestran con éxito su almacenamiento local.
• Las iniciativas futuras incluyen el desarrollo de una red estatal descentralizada, la implementación de la prueba de almacenamiento para datos de tamaño dinámico y el acceso descentralizado directamente desde los navegadores.

Agradecimiento: Muchas gracias a Piper Merriam de EF, Karthik Raju de Polychain, Qiang de EthStorage por proporcionar comentarios sobre el artículo.

Antecedentes

El 22 de octubre de 2023, Péter Szilágyi, el renombrado líder de desarrollo de Go-Ethereum (Geth), expresó sus profundas preocupaciones en Twitter. Señaló que mientras los clientes Geth conservan todos los datos históricos, otros clientes de Ethereum como Nethermind y Besu pueden configurarse para funcionar sin ciertos datos históricos de Ethereum, como cuerpos y encabezados de bloques históricos. Esto hace que todos los clientes sean inconsistentes y es injusto para Geth. Provocó intensas discusiones y debates en torno al problema de almacenamiento de Ethereum dentro del plan de trabajo de Ethereum.

El Desafío de Almacenamiento

¿Por qué Nethermind y Besu optan por dejar de almacenar datos históricos? ¿Qué problemas subyacen a esta decisión? Desde mi perspectiva, hay dos causas raíz principales:

• Los requisitos de almacenamiento para un cliente de Ethereum son cada vez más exigentes.
• No hay incentivo o penalización en el protocolo para almacenar datos históricos de Ethereum.

La primera razón se deriva de las crecientes demandas de almacenamiento para ejecutar un cliente de Ethereum. Para adentrarse en los requisitos específicos, el siguiente gráfico circular ilustra la distribución de los costos de almacenamiento para un nodo Geth recién instalado, a partir del bloque 18.779.761 el 13 de diciembre de 2023.

Como muestra la imagen:

• Requisito total de almacenamiento: 925.39 GB
• Datos históricos (bloques/recibos): Aproximadamente 628.69 GB
• Estado en el árbol trie de Patricia Merkle (MPT): Aproximadamente 269.74 GB

La segunda razón es la falta de incentivos o penalizaciones en el protocolo para almacenar bloques históricos. Si bien el protocolo exige a los nodos que almacenen todos los datos históricos, no proporciona ningún mecanismo para fomentar el almacenamiento o penalizar el incumplimiento. Almacenar y compartir datos históricos por parte de los nodos se convierte en algo puramente altruista, y un nodo es libre de podar todos los datos históricos sin enfrentar ninguna consecuencia adversa. Por el contrario, los validadores, por ejemplo, deben mantener el estado completo más reciente para evitar proponer/votar por un bloque inválido, arriesgando la pérdida de incentivos en ambos casos.

Por consiguiente, cuando el costo de almacenamiento se convierte en una carga sustancial para un nodo, no es sorprendente que algunos operadores de nodos opten por podar datos históricos. Optar por ejecutar sin datos históricos puede resultar en ahorros significativos en el costo de almacenamiento, reduciéndolo de aproximadamente 1TB a alrededor de 300GB.

Ilustración: La configuración de Nethermined para ejecutar un nodo sin cuerpos de bloque históricos, ahorrando aproximadamente ~460GB de costos de almacenamiento por el momento.

Se espera que el desafío del almacenamiento se intensifique con la próxima actualización de Disponibilidad de Datos (DA) de Ethereum. El caminoHacia la escalabilidad total de Ethereum DA comienza con EIP-4844 en DenCun, introduciendo un objeto binario grande de tamaño fijo (BLOB) acompañado de un modelo de tarifas independiente conocido como blobGasPrice. Cada BLOB está configurado en 128 KB, y EIP-4844 permite que cada bloque contenga hasta 6 BLOBs. Para mejorar la escalabilidad de datos, el plan implica implementar el código Reed-Solomon 1D, lo que permite 32 BLOBs por bloque inicialmente y eventualmente alcanzar 256 BLOBs por bloque en la escalabilidad total.

Con el Ethereum DA operando a plena capacidad de datos con 256 BLOBs por bloque, se proyecta que un año de la red Ethereum DA aceptará aproximadamente 80 TB de datos, superando las capacidades de almacenamiento de la mayoría de los nodos Ethereum.

Hoja de ruta de almacenamiento de Ethereum y consecuencia

Vitalik’stweetdel Ethereum roadmap, en el que el Purge trata principalmente del almacenamiento.

Los crecientes costos de almacenamiento han captado la atención de los investigadores dentro del ecosistema de Ethereum. Para abordar esto y garantizar la alineación en todos los clientes, varias propuestas están en desarrollo para podar explícitamente el almacenamiento. Las dos propuestas principales son:

1. EIP-4444: Datos históricos vinculados en clientes de ejecución: Esta propuesta permite a un cliente podar bloques históricos con más de un año de antigüedad. Suponiendo un tamaño de bloque promedio de 100K, los datos de bloques históricos están limitados a aproximadamente 250 GB (100K (3600 24 * 365) / 12, dado el tiempo de bloque = 12s).
2. EIP-4844: Transacciones BLOB de fragmentos: EIP-4844 descarta BLOBs más antiguos de 18 días. Este es un enfoque más agresivo en comparación con EIP-4444, limitando el tamaño histórico de BLOB a alrededor de 100 GB ((18360024) 128K 6 / 12, dado el tiempo de bloque = 12s).

¿Cuál es la consecuencia de podar datos históricos de todos los clientes? La principal es que un nodo nuevo no puede sincronizarse con el estado más reciente a través de una “sincronización completa” - una sincronización para reproducir las transacciones desde el bloque génesis hasta el bloque más reciente. En cambio, tenemos que recurrir a una “sincronización rápida” o “sincronización de estado” para sincronizar el estado más reciente desde pares de Ethereum. Este enfoque ya está implementado en Geth y se ejecuta como la sincronización predeterminada.

De igual manera, esta consecuencia también se aplica a todos los L2, es decir, un nodo recién creado de L2 no puede volver a reproducir completamente el estado más reciente desde el génesis de L2 desde Ethereum volviendo a reproducir los bloques de L2 desde el génesis de L2. Además, dado que los nodos L1 no mantienen el estado L2, el enfoque de "sincronización instantánea" para L2 no puede derivar el estado L2 más reciente de L1, rompiendo una importante suposición de L2 de heredar las garantías de seguridad de Ethereum. La solución proyectada dependerá de servicios de terceros como Infura / Etherscan / los propios proyectos L2 para almacenar una copia de los datos o estado históricos de L2, que está centralizado con un incentivo indirecto fuera del protocolo.

Las preguntas fundamentales que estamos haciendo son

• ¿Podemos tener una mejor solución descentralizada, tanto en términos de almacenamiento como de acceso, al problema?
• ¿Es posible construir una solución de confianza minimizada alineada con Ethereum (por ejemplo, sobre un contrato L1) con una solución de incentivos directos?
• Con todo esto, ¿podemos allanar el camino hacia una solución de incentivos directos en el protocolo para el almacenamiento de Ethereum y acceder a ellos de manera completamente descentralizada en la hoja de ruta de Ethereum?

Soluciones

Solución 1: Red del Portal Ethereum

La red Portal de Ethereum sirve como una red de acceso ligera y descentralizada al protocolo Ethereum. Ofrece la interfaz JSON-RPC de Ethereum, como eth_call, eth_getBlockByNumber, que traduce las solicitudes JSON-RPC en solicitudes P2P a una tabla hash distribuida, similar a la red IPFS. A diferencia de IPFS, que permite el almacenamiento de cualquier tipo de datos y es susceptible al spam, la red P2P de Portal aloja exclusivamente datos de Ethereum, como encabezados y cuerpos históricos. Esto se logra a través de una técnica de verificación de cliente ligero incorporada dentro de la red Portal.

Una característica significativa de la red Portal es su diseño para operación ligera y compatibilidad con dispositivos de recursos limitados. Puede ejecutarse encima de un nodo con unos pocos megabytes de almacenamiento y memoria baja, promoviendo la descentralización. Incluso un teléfono móvil o un dispositivo Raspberry Pi podría potencialmente unirse a la red y contribuir a la disponibilidad de datos de Ethereum.

El desarrollo de la red Portal se alinea con la filosofía de diversidad de clientes de Ethereum, con clientes escritos en Rust, JavaScript, Nim y Go. La red beacon y la red de historial están listas para su uso, mientras que la red de estado está activamente en desarrollo. Cabe destacar que la red Portal no proporciona incentivos directos para el almacenamiento de datos, todos los nodos en la red operan altruistamente.

Ilustración: Ejecutar una red Portal (Trin) con un límite de almacenamiento de 100MB.

Solución 2: Red EthStorage

La red EthStorage es una red de almacenamiento descentralizada incentivada diseñada específicamente para almacenar EIP-4844 BLOBs, con el respaldo de una subvención del programa ESP.

• Confianza mínima: A diferencia de las soluciones existentes que necesitan un puente de datos centralizado, EthStorage se basa en el consenso de Ethereum y el modelo de confianza de $1/m$ de los proveedores de almacenamiento de EthStorage sin permisos. El procedimiento de almacenar un BLOB es el siguiente: un usuario firma una transacción que transporta un BLOB que llama al método _put(key, blob_idx)_ del contrato de almacenamiento. El contrato de almacenamiento luego registrará el hash del BLOB y notificará a los proveedores de almacenamiento con un evento. Los proveedores de almacenamiento, después de recibir el evento, descargarían y almacenarían el BLOB directamente desde la red de Ethereum DA, evitando así el problema del puente de datos.
• Alinear el costo de almacenamiento con el incentivo: al llamar put()método, se debe enviar una tarifa de almacenamiento (a través msg.value) y depositado en el contrato. Esta tarifa de almacenamiento se distribuye gradualmente a los proveedores de almacenamiento con el tiempo tras la presentación exitosa y verificación de una prueba de almacenamiento. En comparación con el modelo de tarifa de almacenamiento actual de Ethereum que paga una tarifa de almacenamiento única al proponente, la tarifa de almacenamiento pagada con el tiempo sigue un modelo de flujo de efectivo descontado, asumiendo que el costo de almacenamiento disminuye con respecto a ETH con el tiempo. Esta innovación significativa introducida por EthStorage alinea la tarifa pagada por los usuarios y las contribuciones de los proveedores de almacenamiento con el tiempo.
• Prueba de Almacenamiento: La prueba de almacenamiento está inspirada en el muestreo de datos disponibles, mientras que el muestreo en EthStorage se realiza contra BLOBs con el tiempo en lugar de los de un bloque propuesto. Para verificar eficientemente el muestreo en cadena, EthStorage aprovecha en gran medida los contratos inteligentes y los últimos avances en tecnologías SNARK.
• Red de permisos: Cualquier nodo en EthStorage puede ser remunerado como proveedor de almacenamiento siempre y cuando almacene datos y periódicamente presente pruebas de almacenamiento en la cadena.

Desde la perspectiva de la modularidad de la cadena de bloques, EthStorage funciona como una Capa 2 de Ethereum, pero cobra tarifas de almacenamiento en lugar de tarifas de transacción. Al indexar los hashes de BLOB en cadena, EthStorage es una capa de almacenamiento modular de Ethereum con una escalabilidad de almacenamiento significativa y ahorros de costos, apuntando a aproximadamente 1000 veces.

En términos de desarrollo, EthStorage ya está integrado con EIP-4844 en la red de prueba Ethereum Sepolia. Se ha realizado una prueba de estrés en EthStorage y la red de prueba Ethereum Sepolia, que involucra la escritura de aproximadamente cientos de gigabytes de BLOBs en EthStorage. Más de 50 participantes de la comunidad se unieron a la red y demostraron con éxito sus almacenamientos locales.

La principal ventaja de la red EthStorage radica en proporcionar un incentivo descentralizado y directo sobre Ethereum, una característica pionera, según nuestro conocimiento actual. Sin embargo, una limitación de la red es que está específicamente diseñada para BLOBs de tamaño fijo.

El panel de EthStorage en Ethereum Devnet

Proyectando el Futuro

El almacenamiento de Ethereum, aunque menos destacado, tiene una importancia significativa dentro del ecosistema de Ethereum. A medida que la red de Ethereum experimenta un crecimiento rápido, el almacenamiento y la accesibilidad de los datos de Ethereum surgen como desafíos críticos. Si bien la red Portal y la red EthStorage se encuentran en sus primeras etapas, visualizamos varias direcciones intrigantes a largo plazo:

• Acceso descentralizado de baja latencia al estado de Ethereum. Acceder al estado de Ethereum de manera descentralizada y verificable es una tarea crítica pero desafiante. Dado un arreglo DHT tradicional, consultar una cuenta típicamente requiere múltiples consultas a los nodos trie internos almacenados en diferentes nodos P2P. Esto a menudo conlleva a una considerable latencia prolongada. Cómo emplear la estructura del árbol de estado para acelerar el acceso es clave, como se aborda en la próxima red de estado de la red del Portal Ethereum.
• Integración entre Portal Network y EthStorage Network: La red Portal puede extender de forma transparente su soporte para incluir BLOBs dentro de la red, un paso que ya ha sido dado parcialmente por el equipo de EthStorage. Una progresión natural sería unir estas redes para ofrecer una red JSON-RPC descentralizada capaz de llamar contratos con acceso a BLOBs. Combinando la lógica de aplicación en los contratos y el almacenamiento escalado de BLOB por EthStorage, permitimos nuevas dApps en Ethereum como sitios web descentralizados dinámicos (por ejemplo, twitter/youtube/wikipedia/etc descentralizados).
• Acceso descentralizado desde navegadores: Similar al protocolo ipfs:// utilizado para acceder a los datos en la red IPFS, hay una creciente necesidad de un protocolo de acceso nativo de Ethereum desde los navegadores para desbloquear el vasto potencial de los ricos datos de Ethereum. Estos datos abarcan un amplio espectro, que va desde la propiedad y saldos de tokens hasta imágenes de NFT y sitios web descentralizados dinámicos, todo ello posible gracias a las capacidades de los contratos inteligentes y el almacenamiento futuro de Ethereum. En este ámbito, el protocolo web3://, según se define en ERC-4804/6860, está actualmente en pleno desarrollo para cumplir con este propósito.
• Prueba avanzada de almacenamiento para datos de tamaño dinámico: Más allá de los BLOB fijos, explorar una prueba avanzada de almacenamiento se vuelve imperativo para abordar datos de tamaño dinámico, como bloques históricos o incluso objetos de estado. El desarrollo de algoritmos sofisticados puede mejorar la adaptabilidad de las soluciones de almacenamiento.

En nuestra búsqueda, aspiramos a que estos esfuerzos contribuyan colectivamente al mapa de ruta de Ethereum, sentando las bases para futuras soluciones de almacenamiento descentralizado dentro del ecosistema de Ethereum.

declaración:

1. Este artículo es reproducido de [flujo tecnológico profundo marea], el título original es “Hoja de ruta de almacenamiento de Ethereum: desafíos y oportunidades”, los derechos de autor pertenecen al autor original [EthStorage], si tiene alguna objeción a la reimpresión, por favor contacteEquipo de Aprendizaje de Gate, el equipo lo manejará lo antes posible de acuerdo con los procedimientos relevantes.

2. Descargo de responsabilidad: Las opiniones expresadas en este artículo representan únicamente las opiniones personales del autor y no constituyen ningún consejo de inversión.

3. Otras versiones del artículo son traducidas por el equipo de Gate Learn, no mencionadas en Gate.io, el artículo traducido no puede ser reproducido, distribuido o plagiado.