Introducción al contenido de Ethereum Dencun

Dencun está compuesto por dos nombres Deneb y Cancún, que representa la horquilla dura entre la capa de consenso de Ethereum y la capa de ejecución.La bifurcación dura Dencun se ha completado en las redes de prueba Goerli, Sepolia y Holesky, y el principal se realizará en la época 269568 (aproximadamente el 13 de marzo de 2024).

Consejos de lectura

Antes de leer este artículo, el primer conocimiento que necesita saber incluye:

Horquilla dura
Ethereum se divide en una capa de consenso y una capa de ejecución.

La actualización de Dencun contiene 9 EIPS, a saber:

EIP-1153: Códigos de operación de almacenamiento transitorio (cambios de capa de ejecución)
EIP-4788: Raíz de bloque de baliza en el EVM (Cambios de capa de ejecución y de consenso)
EIP-4844: Transacciones de Blob de fragmentos (capa de ejecución y cambios de capa de consenso)
EIP -5656: McOpy – Instrucción de copia de memoria (Cambios en la capa de ejecución)
EIP-6780: SelfDestruct solo en la misma transacción
EIP-7044: salidas voluntarias firmadas perpetuamente válidas
EIP-7045: Incrementa la ranura de inclusión de certificación máxima (cambios en la capa de consenso)
EIP-7514: Añadir el límite de rotación de la época máxima (cambios de capa de consenso)
EIP-7516: BloBBaseFee OpCode (Cambios de la capa de ejecución)

Este artículo introducirá los cambios e impactos de estos EIP (excluyendo EIP-4844).

La gran adición de Rollup: Proto Danksharding (I)

https://medium.com/taipei-etereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6

La gran adición de Rollup: Proto Danksharding (ii)

https://medium.com/taipei-etereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

A continuación, introduciremos el orden aproximadamente dividido en «EIP relacionado con los cambios de la capa de ejecución», «EIP relacionado con los cambios de capa de consenso» y «EIP relacionado con EIP-4844».

EIP-1153

Cambios en la capa de ejecución
EIP-1153: Códigos de operación de almacenamiento transitorio

https://eips.ethereum.org/eips/eip-1153

EIP-1153: Página de fans

https://www.eip1153.com/

EIP-1153: Códigos de operación de almacenamiento transitorio

https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553

EIP-1153 ha agregado dos nuevos códigos de operación: Tstore y TLoad, que se utilizan para escribir y leer datos de almacenamiento «temporales».Ahorrarán muchos costos de gas para muchos desarrolladores de contratos.

fondo

El almacenamiento se refiere al contrato inteligente que escribe datos en el espacio de almacenamiento del contrato a través del código de operación de Sstore.La característica «temporal» es que en comparación con la «existencia permanente», los datos escritos por TSTORE son válidos hasta el final de la transacción.

Detalles de la operación

TSTORE es mucho más barata que Store, y su período de validez puede abarcar las llamadas entre diferentes contratos (hasta que finalice la transacción). el recuerdo del contrato B.Esto es muy útil para muchos usos:

Bloqueo de reingreso.Actualmente, el bloqueo de reingreso solo se puede simular con SSTORE.
Utilizado en ERC-20 aprueba dentro de una sola transacción.Si el contrato A interactúa con el contrato B y el contrato A necesita transferir ERC-20 del contrato B, el contrato B primero aprobará ERC-20 para contratar un contrato antes de llamar al contrato A.Debido a que la aprobación de ERC-20 es a través de SSTORE, el costo no es bajo, y cambiar a usar TSTORE reducirá en gran medida el costo.
Parámetros de implementación al implementar contratos a través de Create2.Debido a que el parámetro del constructor afectará la dirección del contrato de la implementación de Create2, si no desea verse afectado por el parámetro del constructor, el constructor del contrato estará diseñado para implementar los parámetros de lectura de almacenamiento del contrato, como el grupo de UNISWAP V3.Con Tstore, dicho modelo puede ahorrar muchos costos.

Cosas a tener en cuenta

Cuando los desarrolladores de contratos usan TSTORE para reescribir su propio bloqueo de reingreso, recuerde despejar el bloqueo cuando sea hora de despejarlo. De lo contrario, si hay alguna necesidad durante el proceso de transacción, si ingresa el contrato, es posible que no pueda ingresar porque el bloqueo no se desbloquea (no se borra).
EIP-1153 se ha lanzado en la versión de solidez 0.8.24, y los desarrolladores pueden probarlo por adelantado.Aquí están los ejemplos mutex implementados por los desarrolladores.Uniswap V4, que se basa en TStore, también se lanzará después de que se complete la actualización de Dencun.
Este EIP tiene un nuevo código de operación, por lo que si los desarrolladores desean implementar contratos en múltiples cadenas, deben prestar atención a si todas las cadenas admiten el último código de operación, de lo contrario no estará disponible.

EIP-4788

Cambios en la capa de ejecución
EIP-4788: raíz de bloque de baliza en el EVM

https://eips.ethereum.org/eips/eip-4788

EIP-4788: Root de baliza en EVM

https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

EIP-4788 agregó un contrato de Beacon_roots_Address para permitir a las personas leer datos de los bloques de capa de consenso, es decir, la capa de ejecución podrá leer datos de la capa de consenso.A través de este contrato, los protocolos de replanteación y reposición pueden leer y usar datos de capa de consenso sin confiar en ningún tercero, como leer el estado de un cierto verificador.

Detalles de la operación

Los usuarios o contratos pueden consultar la raíz del bloque de baliza en un cierto punto en el tiempo llamando al contrato.La raíz de bloques es como el valor hash del contenido de bloque (hash del bloque de baliza), que es la raíz del árbol de Merkle del contenido del bloque a través de la codificación SSZ.La persona que llama codifica la marca de tiempo en el valor de UINT256 y la trata como el contenido de la llamada.

Si un desarrollador quiere usar la información de la capa de consenso, su contrato consultará la raíz de bloque del bloque de capa de consenso que quiere leer el contrato Beacon_roots_Address y luego coincidirá con la información del bloque de capa de consenso (por ejemplo, el equilibrio de un verificador ) y la prueba de Merkle para verificar si la información pertenece a la raíz del bloque.(SSZ Debido a que el contenido se convierte en Merkle Tree, cualquier información en el contenido puede generar la prueba de merkle correspondiente para verificar que la información existe en el contenido).

△ El usuario proporciona la marca de tiempo de la prueba de Merkle y los bloques de capa de consenso

△ La prueba de Merkle se usa para verificar el equilibrio del verificador en un cierto punto en el tiempo.

Sin embargo, la raíz de bloque de capa de consenso almacenada en el contrato Beacon_roots_Address es en realidad la raíz de bloque del bloque «principal» (es decir, el bloque anterior), en lugar de la raíz de bloque del mismo bloque que la capa de ejecución.

△ La marca de tiempo del bloque 11001 (1234567) corresponde a la raíz del bloque del bloque 11000.Del mismo modo, la marca de tiempo del bloque 11000 (1234555) corresponde a la raíz del bloque del bloque 10999.

Cosas a tener en cuenta

El contrato de Beacon_roots_Address almacena hasta 8191 raíces de bloque de capa de consenso, y se sobrescribirán 8191 raíces de bloque anteriores.Por ejemplo, si ahora es el bloque 18191, el rango de raíz de bloque actual al que se puede acceder será la raíz de bloque del bloque 10000 para el bloque 18190.

EIP-5656

Cambios en la capa de ejecución
EIP -5656: McOpy – Instrucción de copia de memoria

https://eips.ethereum.org/eips/eip-5656

EIP-5656 ha agregado un Código de opto McOPY, que se usa específicamente para copiar los valores almacenados en la memoria durante la ejecución del contrato.El contrato se beneficiará de los ahorros de costos de gas de este código de operación.

Para usar McOpy Opcode, los desarrolladores de contratos deben especificar la versión del compilador como 0.8.24 (o arriba) y la versión EVM como Cancun:

△ Para usar mcopy, debe establecer la versión del compilador y la versión EVM

Nota: El compilador de la versión 0.8.24 solo está abierto a usar mcopy (mcopy (), enlace) a través del ensamblaje.

Cosas a tener en cuenta

Este EIP tiene un nuevo código de operación, por lo que si los desarrolladores desean implementar contratos en múltiples cadenas, deben prestar atención a si todas las cadenas admiten el último código de operación, de lo contrario no estará disponible.

EIP-6780

Cambios en la capa de ejecución
EIP-6780: SelfDestruct solo en la misma transacción

https://eips.ethereum.org/eips/eip-6780

EIP-6780: Desactivar la autoestructura, excepto donde ocurre en la misma transacción en la que se creó un contrato

https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-except-where-it-curs-in-the-same-transaction-in-which-a-condact-wa s-created/135339

EIP-6780 modificó el comportamiento de la opción de operación de autohestrucción para prepararse para el árbol Verkle y la eliminación del código de operación auto-inestructa.Los desarrolladores que usan el código de operación autodestruyente necesitan atención especial.

fondo

El comportamiento actual de Opcode de selfDestruct es: (1) Eliminar el código y el almacenamiento del contrato, y (2) transferir todo el ETH a la dirección especificada.

Al principio, diseñamos un código de operación autodestruado con mecanismo de reembolso para alentar a los desarrolladores a eliminar contratos y espacio de almacenamiento no utilizados para ayudar a mantener el estado de Ethereum de un tamaño adecuado.Pero no muchas personas realmente hacen esto, pero hay accidentes como Parity MultiSig que causaron que cientos de miles de ETH se congelen debido a la autocomprobación, por lo que la comunidad de Ethereum espera eliminar gradualmente el código de operación de autodestrucción.Ha habido muchas propuestas para modificar o eliminar el código de operación de autodestrucción en el pasado, y EIP-6780 es una de ellas y finalmente se incluyó en la horquilla dura de Dencun.

Nota: En la bifurcación dura de Shanghai a principios de 2023, EIP-6049 ha anunciado oficialmente que se eliminará la autoestructura.

Verkle Tree es una estructura de almacenamiento estatal que actualmente está investigada y desarrollada activamente por la comunidad Ethereum y se utilizará para reemplazar el árbol actual de Merkle Patricia.Verkle Tree hará que el tamaño de prueba del estado de Ethereum sea más pequeño, por lo que también es clave en el diseño del cliente sin estado.Con el cliente sin estado, el hardware de los nodos se reducirá, lo que permitirá que más personas ejecuten nodos con hardware más ligero y barato, mejorando la descentralización de la red.

Detalles de la operación

Después de EIP-6780, el código de operación de autocontrol eliminará (1) el comportamiento y solo retendrá la función de (2) «Transfiera todo ETH en su cuerpo a la dirección especificada».El código y el almacenamiento del contrato permanecerán sin cambios a menos que el contrato se cree en la misma transacción y luego se realiza la autoestructura.

Entonces, cuando se desencadena la autoestrucción:

Si el contrato no se crea en la misma transacción, el código del contrato y el almacenamiento permanecen sin cambios, pero el ETH se transfiere a la dirección especificada.
Si el contrato se crea en la misma transacción, el comportamiento es el mismo que antes (antes de EIP-6780): el código y el almacenamiento del contrato se eliminarán y el ETH se transferirá a la dirección especificada.

Para el árbol Verkle, el comportamiento de (1) debe eliminarse

En el diseño del árbol Verkle, su estado de almacenamiento es diferente al del árbol de Merkle Patricia.El estado de almacenamiento del árbol de Merkle Patricia se puede imaginar como una estructura de dos capas (árboles en los árboles): la primera capa es un árbol compuesto por todas las direcciones, y la segunda capa es un árbol compuesto por todo el almacenamiento y síntesis para cada dirección; y el árbol Verkle se puede imaginar como una estructura en capas y completamente plana.Por lo tanto, en el árbol de Merkle Patricia podemos localizar fácilmente el almacenamiento de una dirección y eliminarla, pero en el árbol de Verkle, es casi imposible localizar el almacenamiento de una dirección, porque todas las direcciones y cada valor de almacenamiento de la dirección es Distribuido uniformemente en el mismo árbol, es imposible saber fácilmente qué valor pertenece al almacenamiento de la dirección, por lo que no podemos eliminar el código de contrato y todo su almacenamiento en el árbol de Verkle.

△ El diseño actual del árbol de estado (árbol de Merkle Patricia) es una estructura de dos capas: la raíz de estado corresponde a un árbol compuesto por todos los conjuntos de direcciones, y la raíz de almacenamiento corresponde a todos los árboles de almacenamiento y sintéticos bajo una dirección.

Fuente: https://fisco-bcos-documentation.readthedocs.io/en/latest/docs/design/storage/mpt.html

△ Verkle Tree State Tree es un árbol completamente plano.

En la figura, el nodo rojo es la dirección, y el nodo verde es el valor de almacenamiento de la dirección.

Fuente: https://youtu.be/s7fm6zz_g0i?t=572

△ Si solo eliminamos el nodo rojo pero no el almacenamiento (nodos verdes), si el contrato se vuelve a implementar a la misma dirección, heredará directamente el almacenamiento antiguo y no

Fuente: https://youtu.be/s7fm6zz_g0i?t=572

Entonces, para dar la bienvenida a Verkle Tree, debemos prohibir que la opción de operación autodestride elimine los códigos de contrato y el almacenamiento.

Cosas a tener en cuenta

Si el desarrollador usa CREAT2 + SelfDestruct para implementar repetidamente en la misma dirección, esto solo ocurrirá simultáneamente dentro de la misma transacción después de DENCUN para completar.
Si el desarrollador usa CREATE2 + SelfDestruct para lograr el efecto de las actualizaciones del contrato (por lo que Crear2 + SelfDestruct no se completará en la misma transacción), no podrá continuar después de Dencun.

EIP-7044

Cambios de capa de consenso
EIP-7044: salidas voluntarias firmadas perpetuamente válidas

https://eips.ethereum.org/eips/eip-7044

EIP-7044: salidas voluntarias firmadas perpetuamente válidas

https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

EIP-7044 permite que la firma utilizada por el verificador salga de POS sea permanentemente válida, evitando que la firma sea inválida debido a la bifurcación dura de la red.Se mejorará la experiencia del usuario y la protección de los verificadores a los servicios de compromiso no administrados (como LIDO): no hay necesidad de pedirle a un tercero que vuelva a firmar cada vez que tenga que bifurcarse duro.

fondo

El verificador de Ethereum POS debe tener dos claves privadas: una se usa para la participación diaria en la verificación (como la producción de bloques y la firma), llamada clave de validador; La clave de la dirección se llama clave de retiro.Cuando el validador está a punto de salir de POS, firmará con la tecla Validator, y el contenido firmado contiene la versión de red actual (Hard Forked).

En los servicios de compromiso no alojados actuales, el proveedor de servicios mantendrá la clave de validador en su mano, y el usuario mantendrá la clave de retiro. Activos de compromiso y tarifas de manejo para lograr el propósito de la no alcustodia.Para evitar que los proveedores de servicios amenazen con extorsionar a los usuarios «no salir de POS», los proveedores de servicios firmarán el certificado de salida de salida al principio y entregarán la prueba al usuario, para que los usuarios puedan salir en cualquier momento POS, no afectado por proveedores de servicios.

Detalles de la operación

Pero porque el contenido de la firma que sale POS contiene la versión de red actual (Hard Fork), como el Shanghai actual o la versión anterior de Capella.La red comparará la «Versión de la bifurcación dura en el certificado de salida» y la «versión actual de la red».En otras palabras, a medida que la red continúa actualizándose, después de la bifurcación dura y la actualización a una nueva versión, la prueba de salida que es demasiado antigua no será válida.

Por ejemplo, las versiones con bifurcación dura de la capa de consenso de antigua a nueva son Altair, Bellatrix y (actual) Capella.El certificado de salida firmado en Altair se volverá inválido ahora;Para hacer frente a esta situación, el usuario debe solicitar otro certificado de salida del proveedor de servicios cada vez que el usuario se hunda. Salir POS «amenaza con los usuarios de chantaje.

Nota: Sin embargo, dado que «Salir POS» solo está abierto después de Capella, nadie puede cerrar el certificado de salida en Altair o Bellatrix por adelantado.

Por lo tanto, EIP-7044 corrige la versión Hard Fork en el certificado de salida a Capella, de modo que todos los certificados de salida firmados en la versión actual sean permanentemente válidos.No importa cuántas actualizaciones se realicen en el futuro, Capella estará firmada en el certificado de salida y ya no se verá afectado por la versión de bifurcación dura.

Cosas a tener en cuenta

Debido a que la versión Hard Fork del certificado de salida ya está solucionada en Capella, si un verificador o proveedor de servicios firma el certificado de salida de la versión Deneb por adelantado, se volverá inválido después de Deneb.

EIP-7045

Cambios de capa de consenso
EIP-7045: Incrementa la ranura de inclusión de atestación máxima

https://eips.ethereum.org/eips/eip-7045

EIP-7045: Incrementa la ranura de inclusión de atestación máxima

https://ethereum-magicians.org/t/eip-7045-crasege-max-attestation-inclusion-slot/14342

EIP-7045 extiende el período de validez de la votación de los validadores, lo que permite obtener más tiempo y aumenta la estabilidad de la red.No hay impacto en los usuarios generales o los verificadores.

fondo

Originalmente, la votación del verificador (certificación) tiene un tiempo de época (32 espacios) que se puede obtener. Problemas de tiempo de espera o solo después de la votación de la ranura 10020 que se transmitió con éxito a la red P2P, pero sus votos aún se ganarían.Pero si su voto solo aparece hasta 10033 Slot, entonces no hay forma de incluir su voto y se considera que no hay voto.

Detalles de la operación

EIP-7045 extiende el período de validez de la inclusión de votación hasta la última «antes de que termine la próxima época de la votación».Por ejemplo, suponga que el verificador Alice se asigna para votar en la ranura 3205 en la época 100, y antes de EIP-7045, su votación es válida hasta la ranura 3237 (3237 = 3205 + 32); Ranura 3237 (3237 = 3205 + 32);

Nota: la época 0 contiene ranuras 0 a 31;

EIP-7514

Cambios de capa de consenso
EIP-7514: Añadir el límite de rotación de la época máxima

https://eips.ethereum.org/eips/eip-7514

EIP-7514: Añadir el límite de rotación de la época máxima

https://ethereum-magicians.org/t/eip-7514-addmax-epoch-churn-limit/15709

fondo

Después de que Shanghai actualizó y abrió validadores para salir de POS en 2023, ha atraído a más usuarios a unirse y convertirse en validadores, lo que resulta en que la secuencia de espera de validador (cola de entrada) siempre esté llena, y el número total de validadores también está aumentando rápidamente.

△ La cola de entrada ha surgido después de salir de POS desde el abierto.Fuente: https://www.validatorqueue.com/

Si el validador espera que la secuencia permanezca completamente cargada, el 50% de ETH se comprometerá a POS en aproximadamente ocho meses a partir de septiembre de 2023 (cuando se propuso el EIP) a mayo de 2024; 2019.Existen varias desventajas de tantas estancadas ETH, como demasiados validadores, lo que lleva a demasiados validadores de votación y firmas de agregación, aumentando la carga de la red P2P de los validadores y la expansión de la cadena de consenso.Además, algunas personas piensan que la seguridad requerida por Ethereum no requiere tanta estaca ETH.

¿Y por qué continúa tantos ETH?Porque incluso si ETH alcanza el 100% de participación, la tasa anualizada aún es aproximadamente el 1.6%. una opción muy atractiva.

Afortunadamente, el boom de compromiso retrocedió gradualmente en la segunda mitad de 2023, frenando el crecimiento del número de validadores.

△ El crecimiento del número de validadores se ralentizó en la segunda mitad de 2023, con aproximadamente un 25% de ETH prometido en febrero de 2024.Fuente: https://www.validatorqueue.com/

Detalles de la operación

El número original de colas de entrada varía con el número actual de validados. es aproximadamente 950,000).

EIP-7514 arreglará el límite de la cola de entrada a 8, ya no aumenta con el número de validadores actuales, frenando así el crecimiento de los validadores y dando a la comunidad más tiempo para encontrar soluciones a largo plazo, como la próxima bifurcación dura puede ganar EIP-7251.

EIP-4844 y EIP-7516

EIP-4844: Transacciones de Blob de fragmentos

https://www.eip4844.com/

La gran adición de Rollup: Proto Danksharding (I)

https://medium.com/taipei-etereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6

La gran adición de Rollup: Proto Danksharding (ii)

https://medium.com/taipei-etereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8

EIP-4844 agregó un nuevo tipo de transacción, una transacción utilizada específicamente para almacenar datos de blob.Al colocar los datos en un blob, el acurrucado reducirá aún más las tarifas de transacción.

EIP-4844 no es un cambio para expandir y actualizar la capacidad, pero es más como «actualizar el límite de gas de bloque» y «reducir los costos», lo que permite que el bloque ponga más transacciones (roll-) en él.Pero EIP -4844 también está allanando el camino para el plan de expansión real: humedecer.

Además, la Feria General y la Feria General son mercados de tarifas separados e independientes, cada uno con su propia tarifa base y tarifa de prioridad. transacciones).

Resumen y enfoque

La bifurcación dura Dencun consiste en la bifurcación deneb deneb de la capa de consenso y la bifurcación dura de Cancún de la capa de ejecución.
El protagonista de esta actualización es EIP-4844.
Los cambios en la capa de consenso incluyen EIP-7044, EIP-7045 y EIP-7514.
EIP-7044 permite a los validadores que utilizan servicios estacados no administrados para evitar futuras horquillas duras al optar de POS.
EIP-7045 y EIP-7514 pueden considerarse actualizaciones que aumentan la estabilidad de la red POS.
Los cambios en la capa de ejecución incluyen EIP-1153, EIP-4788, EIP-5656, EIP-6780 y EIP-7516.
EIP-1153 permite que muchos modelos de diseño de contrato ahorren mucho gas;
EIP-4788 permite que la capa de ejecución lea la información de la capa de consenso de una manera que no requiere confiar en terceros, lo que permite más posibilidades para instalar servicios relacionados.
EIP-6780 elimina aún más la autocomprobación y elimina su capacidad para «eliminar los códigos y estados de contrato».
Los desarrolladores deben prestar atención a la suposición de que «el almacenamiento temporal se eliminará después de las transacciones» al usar EIP-1153, y asegúrese de prestar atención a si su contrato se verá afectado si se ve afectado.
Los usuarios ordinarios no necesitan prestar atención especial.

Datos de referencia y lectura extendida recomendada

EIP-1153

https://eips.ethereum.org/eips/eip-1153
https://www.eip1153.com/
https://ethereum-magicians.org/t/eip-1153-transient-storage-opcodes/553
https://hackmd.io/@-_wyfkbvsmip5m7mnb4b8a/sjfh66eca

EIP-4788

https://eips.ethereum.org/eips/eip-4788
https://ethereum-magicians.org/t/eip-4788-beacon-root-in-evm/8281

EIP-5656

https://eips.ethereum.org/eips/eip-5656

EIP-6780

https://eips.ethereum.org/eips/eip-6780
https://ethereum-magicians.org/t/eip-6780-deactivate-selfdestruct-except-where-it-curs-in-the-same-transaction-in-which-a-condact-wa s-created/135339
https://www.youtube.com/watch?v=s7fm6zz_g0i

EIP-7044

https://eips.ethereum.org/eips/eip-7044
https://ethereum-magicians.org/t/eip-7044-perpetually-valid-signed-voluntary-exits/14348

EIP-7514

https://eips.ethereum.org/eips/eip-7514
https://ethereum-magicians.org/t/eip-7514-addmax-epoch-churn-limit/15709

EIP-4844 & amp;

https://www.eip4844.com/
https://medium.com/taipei-etereum-meetup/rollup-and-the-boost-from-proto-danksharding-85d2fe0566b6
https://medium.com/taipei-etereum-meetup/rollup-proto-danksharding-implementation-detail-913a3c61fde8
https://eips.ethereum.org/eips/eip-7516
https://ethereum-magicians.org/t/eip-7516-lobbasefee-opcode/15761