La versión de la red de prueba Dencun de actualización de la red Ethereum se lanzó en la red de prueba Goerli el 17 de enero de 2024, y la red de prueba Sepolia se lanzó con éxito el 30 de enero. La actualización de Dencun está cada vez más cerca.

Después de la actualización de la red de prueba de Holesky el 7 de febrero, será la actualización de la red principal. El lanzamiento de la red principal de la actualización de Cancún se ha determinado oficialmente el 13 de marzo de 2024.

Casi todas las actualizaciones de Ethereum van acompañadas de importantes tendencias del mercado. Si echamos la vista atrás a la última actualización del 12 de abril de 2023, conocida como la actualización de Shanghái, los proyectos relacionados con Proof-of-Stake (PoS) experimentaron un aumento de la demanda del mercado.

Si seguimos las experiencias anteriores, es probable que haya oportunidades de posicionamiento estratégico antes de la próxima actualización de Dencún.

Sin embargo, debido a la complejidad técnica involucrada en la actualización de Dencún, no se puede resumir tan sucintamente como la actualización de Shanghái con una sola frase como "Ethereum en transición de PoW a PoS". Esta complejidad hace que sea difícil comprender los puntos focales para el posicionamiento estratégico.

Por lo tanto, este artículo tiene como objetivo explicar los detalles técnicos de la actualización de Dencun en un lenguaje simple y comprensible. Guiará a los lectores a través de las complejidades de esta actualización, destacando sus conexiones con la disponibilidad de datos (DA), las soluciones de capa 2 y otros aspectos relevantes.

01. EIP 4484

EIP-4844 se destaca como la propuesta más crucial en la actualización de Dencún, marcando un paso significativo para Ethereum en su viaje de escalado descentralizado.

En términos sencillos, las soluciones actuales de la capa 2 de Ethereum requieren el envío de las transacciones que se producen en la capa 2 a los datos de llamada de la red principal de Ethereum. Estos datos de llamada son utilizados por los nodos para verificar la validez de los bloques en la red de capa 2.

Sin embargo, este enfoque presenta desafíos, ya que a pesar de los esfuerzos por comprimir los datos de las transacciones, el volumen sustancial de transacciones en la Capa 2, multiplicado por los altos costos de almacenamiento en la red principal de Ethereum, aún impone gastos significativos a los nodos y usuarios de la Capa 2. Este alto costo por sí solo puede llevar a la migración de usuarios a cadenas laterales.

EIP-4844 presenta una solución rentable mediante el establecimiento de un nuevo tipo de área de almacenamiento llamada Binary Large Object (BLOB). Introduce un nuevo tipo de transacción conocido como "BLOB-Carry Transaction" para reemplazar los datos de transacción almacenados previamente en calldata antes de la actualización. Este enfoque innovador ayuda al ecosistema de capa 2 de Ethereum a lograr ahorros en los costos de gas.

¿Por qué el almacenamiento BLOB es rentable?

Como todos sabemos, la rentabilidad suele tener una contrapartida. La razón por la que los datos BLOB incurren en costos más bajos en comparación con los datos de llamadas regulares de Ethereum de tamaño similar es que la capa de ejecución (EL) de Ethereum no puede acceder directamente a los datos BLOB en sí.

En cambio, el EL solo puede acceder a las referencias a los datos del BLOB, y los datos reales del BLOB solo pueden ser descargados y almacenados por la capa de consenso de Ethereum (CL, también conocida como nodos de baliza). Los requisitos de memoria y computación para almacenar datos BLOB son significativamente más bajos que los datos de llamada normales de Ethereum.

Además, BLOB tiene una característica distintiva: solo se puede almacenar durante un período limitado (generalmente alrededor de 18 días) y no se expande infinitamente como el tamaño del libro mayor de Ethereum.

Período de validez del almacenamiento de BLOB

A diferencia del libro mayor permanente de la cadena de bloques, los BLOB son un almacenamiento temporal que está disponible durante 4.096 épocas, o aproximadamente 18 días.

Después de la expiración, la mayoría de los clientes de consenso no podrán recuperar datos específicos en el BLOB. Sin embargo, la prueba de su existencia anterior permanecerá en la red principal en forma de compromisos de KZG y se almacenará permanentemente en la red principal de Ethereum.

¿Por qué 18 días? Se trata de un equilibrio entre el coste de almacenamiento y la eficacia.

En primer lugar, debemos tener en cuenta los beneficiarios más intuitivos de esta actualización, los Optimistic Rollups (como Arbitrum y Optimism), porque hay una ventana de tiempo de 7 días a prueba de fraude en los Optimistic Rollups. Los datos de transacción almacenados en el blob son exactamente lo que Optimistic Rollups necesita al lanzar un desafío.

Por lo tanto, el período de validez del blob debe garantizar que se pueda acceder a la prueba de fraude de Optimistic Rollups. En aras de la simplicidad, la comunidad de Ethereum eligió 2 elevado a 12 (4.096 épocas se derivan de 2^12, y una época es de aproximadamente 6,4 minutos).

Transacción portadora de BLOB y BLOB

Comprender la relación entre los dos es importante para comprender el papel de los BLOB en la disponibilidad de datos (DA).

La primera es la propuesta general EIP-4484 y es un nuevo tipo de transacción, mientras que la segunda puede entenderse como una ubicación de almacenamiento temporal para transacciones de capa 2.

La relación entre ambos puede entenderse como que la mayoría de los datos del primero (datos de transacción de capa 2) se almacenan en el segundo. Los datos restantes, es decir, el compromiso de datos BLOB, se almacenarán en los datos de llamada de la red principal. En otras palabras, las promesas pueden ser leídas por la EVM.

El compromiso se puede imaginar como la construcción de todas las transacciones en el BLOB en un árbol de Merkle, y entonces solo se puede acceder a la raíz de Merkle, que es el compromiso, mediante el contrato.

Esto se puede lograr de manera inteligente: aunque la EVM no puede conocer el contenido específico del BLOB, el contrato EVM puede verificar la autenticidad de los datos de la transacción conociendo el Compromiso.

02. La relación entre BLOB y la capa 2

La tecnología Rollup logra la disponibilidad de datos (DA) cargando datos en la red principal de Ethereum, pero no está pensada para que los contratos inteligentes de L1 lean o verifiquen directamente estos datos cargados.

El propósito de cargar los datos de la transacción en L1 es simplemente permitir que todos los participantes vean los datos.

Antes de la actualización de Dencún, como se mencionó anteriormente, Optimistic Rollups publicará los datos de las transacciones en Ethereum como datos de llamada. Por lo tanto, cualquiera puede usar esta información de transacción para reproducir el estado y verificar la corrección de la red de capa 2.

No es difícil ver que los datos de las transacciones acumulativas deben ser baratos, abiertos y transparentes. Los datos de llamadas no son un buen lugar para almacenar datos de transacciones específicamente para la capa 2, y la transacción de transporte de blobs está hecha a medida para el resumen.

Llegados a este punto, es posible que se pregunte sobre la importancia de los datos de las transacciones.

En realidad, los datos de transacción solo se usan en escenarios específicos:

• En el caso de Optimistic Rollup, basado en una suposición de confianza, existe la posibilidad de deshonestidad. En tales casos, los registros de transacciones cargados por el rollup se vuelven útiles, lo que permite a los usuarios iniciar pruebas de fraude.
• En el caso de ZK Rollup, la prueba de conocimiento cero ha demostrado que la actualización de estado es correcta. La carga de datos es solo para permitir que los usuarios calculen el estado completo por sí mismos. Cuando el nodo de capa 2 no puede funcionar correctamente, se habilita el mecanismo de escotilla de escape, que requiere un árbol de estado L2 completo. Esto se discutirá en la última sección de este artículo.

Esto implica que el uso real de los datos de las transacciones por parte de los contratos es muy limitado. Incluso en las pruebas de fraude de Optimistic Rollup, solo se requiere una prueba de que los datos de la transacción "existieron" en un momento determinado, y no es necesario almacenar los detalles de cada transacción en la red principal por adelantado.

Al colocar los datos de transacción en el BLOB, aunque no sean accesibles para los contratos, el contrato de la red principal puede almacenar el compromiso del BLOB.

Si el mecanismo a prueba de fraude necesita una transacción específica en el futuro, proporcionar los datos para esa transacción, siempre que coincida, puede convencer al contrato y proporcionar los datos de la transacción para el mecanismo a prueba de fraude.

Esto no solo aprovecha la apertura y transparencia de los datos de las transacciones, sino que también evita el enorme costo de gas de ingresar todos los datos en el contrato por adelantado.

Al registrar solo el compromiso, los datos de las transacciones son verificables al tiempo que optimizan en gran medida los costos. Se trata de una solución inteligente y eficiente para cargar datos de transacciones utilizando la tecnología Rollup.

Cabe destacar que en el funcionamiento real de Dencun, no se utiliza el árbol de Merkle similar a Celestia para generar compromiso, sino que se utiliza el algoritmo KZG (Kate-Zaverucha-Goldberg, Compromiso Polinómico).

En comparación con Merkle tree proof, el proceso de generación de KZG Proof es relativamente complejo, pero su volumen de verificación es menor y los pasos de verificación son más simples. Sin embargo, la desventaja es que requiere configuraciones confiables (ceremony.ethereum.org, que ya ha terminado) y no tiene la capacidad de prevenir ataques de computación cuántica (Dencun utiliza el método Version Hash, y otros métodos de verificación pueden ser reemplazados si es necesario).

Para el ahora popular proyecto de DA Celestia, utiliza una variante del árbol de Merkle. A diferencia de KZG, se basa en cierta medida en la integridad de los nodos, pero ayuda a reducir el umbral de recursos computacionales entre nodos, manteniendo la naturaleza descentralizada de la red.

03. Oportunidades en Dencun

Si bien EIP-4844 reduce los costos y aumenta la eficiencia de la capa 2, también aumenta los riesgos de seguridad, lo que también brinda nuevas oportunidades.

Para entender por qué, tenemos que volver al mecanismo de escotilla de escape o mecanismo de retirada forzada mencionado anteriormente.

Cuando el nodo de capa 2 está deshabilitado, este mecanismo puede garantizar que los fondos de los usuarios se devuelvan de forma segura a la red principal. El requisito previo para activar este mecanismo es que el usuario debe obtener el árbol de estado completo de la capa 2.

En circunstancias normales, los usuarios solo necesitan encontrar un nodo completo de capa 2 para solicitar datos, generar una prueba de merkle y luego enviarla al contrato de la red principal para demostrar la legitimidad de su retiro.

Pero no olvide que el usuario quiere activar el mecanismo de escotilla de escape para salir de L2 precisamente porque los nodos L2 han actuado maliciosamente. Si esto sucede, existe una alta probabilidad de que no obtengan los datos que desean de los nodos.

Esto es a lo que Vitalik se refiere a menudo como un ataque de retención de datos.

Antes de EIP-4844, los registros permanentes de Capa 2 se registraban en la red principal. Cuando ningún nodo de capa 2 podía proporcionar un estado completo fuera de la cadena, los usuarios podían implementar un nodo completo por sí mismos.

Este nodo completo puede obtener todos los datos históricos liberados por el secuenciador de capa 2 en la red principal a través de la red principal de Ethereum. Los usuarios pueden construir la prueba de Merkle requerida y enviar la prueba al contrato en la red principal para completar de manera segura el retiro de activos L2.

Después de EIP-4844, los datos de la capa 2 solo existen en el BLOB de los nodos completos de Ethereum, y los datos históricos antes de 18 días se eliminarán automáticamente.

Por lo tanto, el método del párrafo anterior para obtener todo el árbol de estados mediante la sincronización de la red principal ya no es factible. Si desea obtener el árbol de estado completo de la capa 2, solo puede confiar en los nodos de la red principal de terceros que hayan almacenado todos los datos BLOB de Ethereum (que deberían haberse eliminado automáticamente después de 18 días) o en los nodos nativos de la capa 2 (que son raros).

Después de que EIP-4844 se ponga en marcha, será muy difícil para los usuarios obtener el árbol de estado completo de la Capa 2 de una manera completamente confiable.

Sin una forma estable para que los usuarios obtengan el árbol de estado de la capa 2, no pueden realizar operaciones de retiro forzado en condiciones extremas. Por lo tanto, EIP-4844 se ha convertido en una deficiencia de seguridad para la Capa 2 hasta cierto punto.

Para compensar esta falta de seguridad, necesitamos tener una solución de almacenamiento sin confianza con un ciclo económico positivo. El almacenamiento aquí se refiere principalmente a la retención de datos en Ethereum de una manera sin confianza, que es diferente del espacio de almacenamiento en el pasado porque hay una palabra clave "sin confianza" en este caso.

Ethstorage puede resolver el problema de la falta de confianza y ha recibido dos rondas de financiación de la Fundación Ethereum.

En realidad, este concepto realmente puede satisfacer el potencial que aporta la actualización de Dencún, y es digno de nuestra atención.

La importancia más intuitiva de Ethstorage es que puede extender el tiempo disponible de DA BLOB de una manera completamente descentralizada, compensando las deficiencias de la seguridad de la capa 2 después de EIP-4844.

Además, la mayoría de las soluciones L2 existentes se centran principalmente en escalar la potencia informática de Ethereum, es decir, aumentar el TPS. Sin embargo, la demanda de almacenar de forma segura grandes cantidades de datos en la red principal de Ethereum ha aumentado, especialmente debido a la popularidad de las dApps como los NFT y DeFi.

Por ejemplo, la demanda de almacenamiento de NFT on-chain es enorme, porque los usuarios no solo poseen tokens de contratos NFT, sino también la imagen on-chain. Ethstorage puede resolver los problemas de confianza adicionales que conlleva el almacenamiento de estas imágenes en un tercero.

Por último, Ethstorage también puede resolver las necesidades de front-end de las dApps descentralizadas. Las soluciones existentes actualmente están alojadas principalmente en servidores centralizados (con DNS). Esta configuración hace que los sitios web sean vulnerables a la censura y otros problemas, como el secuestro de DNS, la piratería de sitios web o las caídas del servidor, como lo demuestran incidentes como Tornado Cash.

Ethstorage todavía se encuentra en la etapa de prueba inicial, y los usuarios que son optimistas sobre las perspectivas de esta pista pueden probarlo.

Renuncia:

1. Este artículo es una reimpresión de [Biteye], Todos los derechos de autor pertenecen al autor original [Biteye]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.