La actualización de Cancún se lanzará el 13 de marzo de 2024 y EIP4844 estará en línea pronto. Danksharding es el núcleo de la hoja de ruta de Ethereum y esta actualización es el primer paso para implementar Danksharding.
Después de que Ethereum L2 se adapta a EIP4844, las tarifas de transacción se redujeron significativamente y el TPS de L2 se duplicó. **Los usuarios sentirán que las transacciones son más rápidas, más económicas, una experiencia más fluida y con mayor capacidad de respuesta. Habrá aplicaciones Dapp más complejas y más grandes en estas L2. **
Los rollups optimistas son más fáciles de adaptar a EIP4844, mientras que los rollups ZK son más complejos de adaptar**. Ethereum no tiene un contrato precompilado para soportar curvas elípticas BLS12-381, lo que dificulta la verificación de algunos ZKP y dificulta el progreso de los rollups de ZK que se adaptan a EIP4844. **
El problema de las curvas elípticas se puede resolver de dos maneras: ** 1. Espere a que Ethereum precompile las curvas elípticas BLS12-381; 2. Utilice otro método de prueba para lograr el mismo propósito, utilice BN254 compatible con la precompilación de Ethereum. **
Actualmente, Arbitrum, Optimistic, Starknet, zkSync, Scroll, Polygon zkEVM y el nuevo L2 Morph se están adaptando a EIP4844. Entre ellos, Arbitrum, Optimistic y Starknet declararon que implementarán la adaptación EIP4844 después de la actualización de Cancún. Morph tomó la iniciativa en el lanzamiento de la innovadora solución de adaptación zkSNARK zkEVM, que será el primer zkSNARK zkEVM en adaptarse a EIP4844
1. Antecedentes
En 2020, Ethereum lanzó la "Hoja de ruta de Ethereum centrada en Rollup", y la imagen final de Ethereum descrita en "Endgame" publicado por Vitalik el año siguiente, ** determinó el panorama general de Ethereum. Dirección: Optimizar la construcción de la capa básica de Ethereum para servir Rollup. **
Ethereum diseñó la tecnología de fragmentación de Danksharding para mejorar la usabilidad de Ethereum como capa de disponibilidad de datos. Reducirá significativamente las tarifas de transacción de L2, aumentará el TPS de Rollup y logrará una expansión sustancial de Ethereum.
Hasta este año, la actualización Ethereum Cancún-Dencun finalmente se lanzó el 13 de marzo de 2024 y EIP4844 está a punto de estar en línea. Se puede decir que esta bifurcación dura es el primer paso en la implementación de Danksharding de Ethereum, el núcleo de la hoja de ruta. **
Con respecto a qué es la capa DA, los principios técnicos de Danksharding y el contenido de EIP4844, consulte un artículo técnico que escribí el año pasado: DA (Disponibilidad de datos) ¿Se acerca el verano?
** 2. ¿Cómo beneficiará a L2 la actualización de Cancún? **
EIP4844 introduce un nuevo tipo de transacción llamada transacciones portadoras de blobs**. **Cada transacción que transporta blobs puede "llevar" una lista de blobs. Un blob es un paquete de datos de aproximadamente 125 KB. Los blobs se almacenan por un corto período de tiempo, solo 4096 épocas, que es un poco más de 18 días.
Las tarifas de transacción L2 han disminuido significativamente. Dado que los Blobs no requieren almacenamiento permanente, son más grandes y más baratos que el espacio en bloque. Blob puede almacenar 10 veces más datos que Calldata con el mismo consumo de gas. El paquete acumulativo adaptado a EIP4844 puede almacenar datos de transacciones en Blobs, lo que reduce las tarifas de transacción en un orden de magnitud.
Se duplica el TPS de L2. El objetivo actual es 3 blobs por bloque, con un máximo de 6 blobs permitidos. Los bloques tienen solo 90 KB y cada blob tiene aproximadamente 125 KB. La introducción de Blob equivale a expandir varias veces el espacio del bloque para almacenar datos Rollup, por lo que el TPS de Rollup también se puede duplicar. Y "Sobre el aumento del límite de gas del bloque", escrito por Toni y Vitalic, afirmaron que al aumentar el límite de gas del bloque y el precio de los bytes de Calldata distintos de cero, se logrará un tamaño de bloque más pequeño con menos variables, de modo que se puedan agregar más en el futuro Blob. Cuantos más blobs, mayor será el espacio de almacenamiento.
Para los usuarios finales, después de que **EthereumL2 se adapte a EIP4844, la velocidad de la transacción será más rápida, el costo será menor, la experiencia será más fluida y la respuesta será más ágil. Habrá aplicaciones Dapp más complejas y más grandes en estas L2. **
3. ¿Cómo se adapta L2 a EIP4844?
¿Cómo se adapta L2 a EIP4844? Necesitamos analizar Optimistic Rollup y ZK Rollup por separado.
Optimistic Rollups se adapta a EIP4844
El resumen optimista utiliza prueba de fraude para garantizar la exactitud de la ejecución del resumen. Es decir, el nodo primero elige creer que la transición de estado es correcta. A menos que alguien inicie un certificado de fraude dentro de un período de tiempo específico para demostrar que la transición de estado presentada anteriormente es ilegal, la transición de estado será revocada.
El resumen optimista es más sencillo de adaptar a EIP4844 que el resumen ZK. Envíe todas las transacciones L2 a L1 a través de transacciones portadoras de Blob para completar la adaptación. Además, la prueba de fraude debe ajustarse para adaptarse a EIP 4844. Esta parte se puede realizar lentamente. Después de todo, muchos informes optimistas aún no han presentado pruebas de fraude. Puse un certificado de fraude en línea, pero descubrí que no se había presentado ningún certificado de fraude durante más de dos años.
Envío de transacciones L2: cuando se envía el resumen, la transacción que lleva el blob se utiliza para almacenar los datos del resumen en el blob. La carga útil de la transacción que transporta Blob es rlp([tx_payload_body, blobs, commits,proofs]), donde
tx_payload_body- es el TransactionPayloadBody de la transacción de blob estándar EIP-2718.
blobs - Lista de blobs. Una transacción puede contener hasta dos blobs.
compromisos: lista de compromisos de KZG para el blob.
pruebas- Blob y lista de pruebas correspondientes al compromiso de KZG. Esta prueba será verificada por el nodo ETH.
Ajuste por prueba de fraude:
Primero, el demostrador y el retador necesitan múltiples rondas de interacción para encontrar el punto de disputa.
Luego envíe el punto en disputa a L1 para su juicio. Para adaptarse a EIP4844, puede ser necesario demostrar que los datos en cuestión están almacenados en un determinado Blob.
Dado que los datos de Blob se eliminarán después de aproximadamente 18 días, el período de desafío debe ser antes de que se eliminen, lo cual se cumple con los resúmenes optimistas actuales. Generalmente, el período de impugnación no supera los 7 días.
ZK Rollups se adapta a EIP4844
El resumen de ZK utiliza ZKP para demostrar que la transición del estado L2 es correcta. La adaptación del rollup de ZK a EIP4844 es más complicada que el rollup optimista.
Envío de transacciones L2: este paso del resumen optimista es similar.
**Envío de prueba ZK: en comparación con el ZK Rollup antes de la adaptación, además de la prueba de transición de estado ZKP, se requiere un proceso de prueba más. Es decir, se demuestra que el compromiso de blob y el lote de transacciones son correspondientes, lo que garantiza que la entrada de la prueba de transición de estado sea correcta. **
Por ejemplo: el circuito ZK de transición de estado puede generar una prueba del proceso de cálculo a + a = b. El ZKP generado cuando (a=1,b=2) y (a=2,b=4) es legal. Por lo tanto, también debo proporcionar una prueba de que la entrada que proporcioné en ese momento fue (a=1,b=2) en lugar de (a=2,b=4).
No es necesario hacer esto antes de adaptarse a EIP4844, porque los datos se almacenan directamente en Calldata y se pueden leer directamente, lo que garantiza que la entrada no se ajustará. Después de usar EIP4844, los datos del Blob no se pueden leer directamente y esto solo se puede probar a través de un nuevo circuito.
Es más fácil implementar este mecanismo de prueba utilizando el paquete acumulativo ZK de STARK (como Starknet). Este es un desafío para el rollup de ZK usando SNARK. La razón es: **La curva elíptica utilizada por el compromiso de blob de EIP4844 es BLS12-381, mientras que el contrato precompilado de ETH solo admite BN254. Debido a las diferentes curvas, es difícil para nosotros Verifique directamente la prueba de finalización del compromiso de blob en el contrato inteligente. **
**ZkEVM/zkVM que usa SNARK necesita resolver el problema mencionado en el punto 2 de que no se puede generar la prueba ZK debido a una discrepancia en la curva. **
Esperando que Ethereum admita contratos precompilados BLS12-381. Esto será largo.
*Utilizar otro método de prueba para demostrarlo. Para diseñar nuevos circuitos, debe utilizar la curva elíptica BN254 respaldada por el contrato precompilado. Actualmente, vemos a Morph adoptando este enfoque. Esto también convierte a Morph en el primer zkEVM en completar la adaptación de EIP4844.
La solución integrada EIP-4844 zkEVM de Morph, consulte:
** 4. ¿Qué L2 están adaptadas a EIP4844? **
En el paquete acumulativo Optimistic, Optimism y Arbitrum han expresado su compromiso de adoptar EIP-4844 y están trabajando estrechamente con sus comunidades para probar e implementar las actualizaciones necesarias. Arbitrum es un paquete acumulativo de Etapa 1 y tiene una seguridad relativamente buena. Implica la necesidad de adaptar la prueba de fraude a EIP4844. El paquete acumulativo optimista es un paquete acumulativo de etapa 0. Actualmente no existe prueba de fraude. Es más fácil de adaptar, pero la seguridad no es lo suficientemente alta.
En el resumen de ZK, la dificultad de adaptación del resumen usando STRAK y SNARK es diferente. Es más fácil adaptar EIP4844 con el paquete acumulativo de STARK, y Starknet es uno de los representantes. Starknet publicó un artículo indicando que Cancún implementará la adaptación EIP4844 después de la actualización (enlace del artículo). Utilizando el paquete acumulativo de SNARK, zkSync también está explorando cómo aprovechar las transacciones que contienen blobs para reducir aún más los costos y mejorar el rendimiento. Scroll publicó un artículo el año pasado presentando la idea de adaptar EIP4844 (enlace del artículo)
El más impresionante es Morph, que es un Optimistic ZK Rollup y fue el primero en lanzar una solución para adaptar zkEVM a EIP4844 **Se puede decir que es el primer zkEVM Rollup que completa EIP4844. **
Optimistic ZK Rollup combina las ventajas de ambos tipos de Rollup. Cree con optimismo en los resultados de ejecución presentados por Sequencer y permite a quienes dudan de los resultados iniciar desafíos. Solo cuando se emite una impugnación, el probador generará ZKP para demostrar la exactitud de los resultados de la ejecución. **Tiene la eficiencia del rollup Optimistic y la confiabilidad comprobada por ZK del rollup ZK. **
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.
Se acerca la actualización de Cancún ¿Qué adaptaciones han hecho las L2 convencionales?
TL;DR:
1. Antecedentes
En 2020, Ethereum lanzó la "Hoja de ruta de Ethereum centrada en Rollup", y la imagen final de Ethereum descrita en "Endgame" publicado por Vitalik el año siguiente, ** determinó el panorama general de Ethereum. Dirección: Optimizar la construcción de la capa básica de Ethereum para servir Rollup. **
Ethereum diseñó la tecnología de fragmentación de Danksharding para mejorar la usabilidad de Ethereum como capa de disponibilidad de datos. Reducirá significativamente las tarifas de transacción de L2, aumentará el TPS de Rollup y logrará una expansión sustancial de Ethereum.
Hasta este año, la actualización Ethereum Cancún-Dencun finalmente se lanzó el 13 de marzo de 2024 y EIP4844 está a punto de estar en línea. Se puede decir que esta bifurcación dura es el primer paso en la implementación de Danksharding de Ethereum, el núcleo de la hoja de ruta. **
** 2. ¿Cómo beneficiará a L2 la actualización de Cancún? **
EIP4844 introduce un nuevo tipo de transacción llamada transacciones portadoras de blobs**. **Cada transacción que transporta blobs puede "llevar" una lista de blobs. Un blob es un paquete de datos de aproximadamente 125 KB. Los blobs se almacenan por un corto período de tiempo, solo 4096 épocas, que es un poco más de 18 días.
Para los usuarios finales, después de que **EthereumL2 se adapte a EIP4844, la velocidad de la transacción será más rápida, el costo será menor, la experiencia será más fluida y la respuesta será más ágil. Habrá aplicaciones Dapp más complejas y más grandes en estas L2. **
3. ¿Cómo se adapta L2 a EIP4844?
¿Cómo se adapta L2 a EIP4844? Necesitamos analizar Optimistic Rollup y ZK Rollup por separado.
Optimistic Rollups se adapta a EIP4844
El resumen optimista utiliza prueba de fraude para garantizar la exactitud de la ejecución del resumen. Es decir, el nodo primero elige creer que la transición de estado es correcta. A menos que alguien inicie un certificado de fraude dentro de un período de tiempo específico para demostrar que la transición de estado presentada anteriormente es ilegal, la transición de estado será revocada.
El resumen optimista es más sencillo de adaptar a EIP4844 que el resumen ZK. Envíe todas las transacciones L2 a L1 a través de transacciones portadoras de Blob para completar la adaptación. Además, la prueba de fraude debe ajustarse para adaptarse a EIP 4844. Esta parte se puede realizar lentamente. Después de todo, muchos informes optimistas aún no han presentado pruebas de fraude. Puse un certificado de fraude en línea, pero descubrí que no se había presentado ningún certificado de fraude durante más de dos años.
Envío de transacciones L2: cuando se envía el resumen, la transacción que lleva el blob se utiliza para almacenar los datos del resumen en el blob. La carga útil de la transacción que transporta Blob es rlp([tx_payload_body, blobs, commits,proofs]), donde
Ajuste por prueba de fraude:
ZK Rollups se adapta a EIP4844
El resumen de ZK utiliza ZKP para demostrar que la transición del estado L2 es correcta. La adaptación del rollup de ZK a EIP4844 es más complicada que el rollup optimista.
** 4. ¿Qué L2 están adaptadas a EIP4844? **
En el paquete acumulativo Optimistic, Optimism y Arbitrum han expresado su compromiso de adoptar EIP-4844 y están trabajando estrechamente con sus comunidades para probar e implementar las actualizaciones necesarias. Arbitrum es un paquete acumulativo de Etapa 1 y tiene una seguridad relativamente buena. Implica la necesidad de adaptar la prueba de fraude a EIP4844. El paquete acumulativo optimista es un paquete acumulativo de etapa 0. Actualmente no existe prueba de fraude. Es más fácil de adaptar, pero la seguridad no es lo suficientemente alta.
En el resumen de ZK, la dificultad de adaptación del resumen usando STRAK y SNARK es diferente. Es más fácil adaptar EIP4844 con el paquete acumulativo de STARK, y Starknet es uno de los representantes. Starknet publicó un artículo indicando que Cancún implementará la adaptación EIP4844 después de la actualización (enlace del artículo). Utilizando el paquete acumulativo de SNARK, zkSync también está explorando cómo aprovechar las transacciones que contienen blobs para reducir aún más los costos y mejorar el rendimiento. Scroll publicó un artículo el año pasado presentando la idea de adaptar EIP4844 (enlace del artículo)
El más impresionante es Morph, que es un Optimistic ZK Rollup y fue el primero en lanzar una solución para adaptar zkEVM a EIP4844 **Se puede decir que es el primer zkEVM Rollup que completa EIP4844. **
Optimistic ZK Rollup combina las ventajas de ambos tipos de Rollup. Cree con optimismo en los resultados de ejecución presentados por Sequencer y permite a quienes dudan de los resultados iniciar desafíos. Solo cuando se emite una impugnación, el probador generará ZKP para demostrar la exactitud de los resultados de la ejecución. **Tiene la eficiencia del rollup Optimistic y la confiabilidad comprobada por ZK del rollup ZK. **