Se acerca el upgrade de Ethereum Cancun, repasando el pasado, presente y futuro del upgrade de Cancun

Autor: Fat Bird Finanzas

vidas pasadas

¿Por qué se necesita la actualización de Cancún?

La visión de Ethereum es volverse más escalable y más seguro bajo la premisa de la descentralización. La actualización actual de Ethereum también está comprometida con la solución de este trilema, pero se ha enfrentado a grandes desafíos.

Problemas con Ethereum:

En la actualidad, hay TPS y rendimiento bajos, tarifas de gas altas y una congestión grave. Al mismo tiempo, el espacio en disco necesario para ejecutar un cliente de Ethereum también está creciendo rápidamente. En el fondo, la carga de trabajo para garantizar la seguridad y la descentralización de Ethereum. El impacto del algoritmo de consenso en todo el entorno también se está volviendo cada vez más importante.

Por lo tanto, bajo la premisa de la descentralización, cómo transmitir más datos y reducir el gas para mejorar la escalabilidad y cómo optimizar el algoritmo de consenso para garantizar la seguridad son todos los esfuerzos que Ethereum está realizando actualmente.

Para resolver el trilema de seguridad, descentralización y escalabilidad, Ethereum ha utilizado el mecanismo PoW-to-PoS para reducir aún más el umbral del nodo, y también planea usar la cadena de balizas para asignar verificadores aleatoriamente para optimizar la seguridad. de escalabilidad, Ethereum considera usar sharding para reducir la carga de trabajo de los nodos, lo que también le permite a Ethereum crear múltiples bloques al mismo tiempo y mejorar su escalabilidad.

En la actualidad, el espacio de cada bloque de Ethereum es de aproximadamente 200 ~ 300 KB, el tamaño mínimo de cada transacción es de aproximadamente 100 bytes, aproximadamente 2000 transacciones, dividido por el tiempo de bloque de 12 segundos, el límite superior de TPS de Ethereum está limitado a alrededor de 100 Estos datos obviamente no pueden satisfacer las necesidades de Ethereum.

Por lo tanto, Ethereum Layer 2 se enfoca en cómo colocar una gran cantidad de datos en el espacio de bloques y garantizar la seguridad a través de pruebas de fraude y pruebas de validez. Es por eso que la capa DA determina el límite superior de seguridad, que también es el contenido central del Actualización de Cancún.

La ruta iterativa de la ecología de Ethereum no puede construir el rendimiento del benchmark Solana (en términos de retraso y rendimiento), y el rendimiento de fragmentación de Near no se verá a corto plazo, ni el rendimiento de ejecución paralela de Sui y Aptos. A corto plazo, Ethereum solo puede construir una estructura de múltiples capas con Rollup como núcleo, por lo que la actualización de Cancún para resolver TPS, la tarifa de gas y la experiencia del desarrollador es crucial para la hoja de ruta de Ethereum.

¿Cómo se planifica la hoja de ruta de Ethereum?

Actualizaciones importantes recientes y sus objetivos

El 1 de diciembre de 2020, se lanzó oficialmente la cadena de balizas, allanando el camino para las actualizaciones de POS

Actualización de Londres el 5 de agosto de 2021, EIP1559 cambió el modelo económico de Ethereum;

El 15 de septiembre de 2022, la actualización de París (TheMerge) completó el cambio de POW a POS;

El 12 de abril de 2023, Shanghai se actualizó para resolver el problema del retiro de compromisos;

El modelo económico y las actualizaciones relacionadas con POS se han completado, y las próximas actualizaciones han resuelto los problemas de rendimiento de Ethereum, TPS y experiencia del desarrollador;

El siguiente paso se centra en TheSurge en la hoja de ruta de Ethereum.

Objetivo: Lograr más de 100 000 TPS en Rollup.

Existen principalmente 2 soluciones, dentro y fuera de la cadena:

Solución fuera de la cadena: se refiere a Layer2, incluido el resumen, etc.

Esquema en cadena: se refiere a realizar cambios directamente en L1, que es un esquema de fragmentación popular. Una comprensión simple de la fragmentación es dividir todos los nodos en diferentes áreas y completar las tareas de cada área, lo que efectivamente aumentará la velocidad;

Análisis del esquema de fragmentación:

El dilema del esquema de fragmentación: la fragmentación solía incluir fragmentación de estado, fragmentación de transacciones, etc., pero la sincronización entre diferentes fragmentos es un problema. En la actualidad, es técnicamente difícil completar una sincronización de datos de nodo de red a gran escala. No solo no puede resolver la situación de MEV, sino que también se puede necesitar una gran cantidad de parches para compensar varios problemas que pueden surgir, que no se pueden realizar a corto plazo.

Danksharding es un nuevo diseño de fragmentación propuesto para Ethereum. Su idea central es la generación centralizada de bloques + verificación descentralizada + resistencia a la censura. Esto también está relacionado con el muestreo de disponibilidad de datos (DAS) y los productores de bloques que se mencionan a continuación. - Separación de paquetes (PBS) y censura Listas resistentes (Crlist) relacionadas. La mayor importancia de la idea central de Danksharding es convertir Ethereum L1 en una capa unificada de liquidación y disponibilidad de datos (DataAvailability).

El esquema de fragmentación se divide en pasos 2. En la actualidad, se divide en Proto-danksharding y Fully-Rollup.

Proto-húmedo:

Introducción: al introducir blobs para ayudar a L2 a reducir las tarifas y aumentar el rendimiento, también allana el camino para la fragmentación completa como un esquema previo para la fragmentación húmeda. Se espera que después de proto-danksharding, la implementación de danksharing tarde entre 2 y 5 años.

Contenido: la característica principal de proto-danksharding es introducir un nuevo tipo de transacción de blob. Blob tiene las características de gran capacidad y bajo costo. Agregar dichos paquetes de datos a Ethereum puede permitir que todos los datos acumulados se almacenen en blob, lo que reduce en gran medida el Almacenamiento de la presión de la cadena principal, pero también reduce el costo de acumulación.

Completamente resumido

Introducción: Rollup expande completamente la capacidad, enfocándose en la utilización de la disponibilidad de datos.

contenido:

Diseño P2P de DAS: algunos trabajos e investigaciones relacionados con el problema de conexión de la red de fragmentación de datos;

Cliente de muestreo de disponibilidad de datos: desarrolle un cliente ligero que pueda determinar rápidamente si los datos están disponibles mediante el muestreo aleatorio de unos pocos kilobytes;

Autorreparación eficiente de DA: capaz de reconstruir de manera eficiente todos los datos en las peores condiciones de red (por ejemplo, ataque de validador malicioso o tiempo de inactividad prolongado de nodos de bloques grandes).

Reunión de desarrolladores principales de Ethereum

Cada actualización de Ethereum depende de la reunión de desarrolladores principales, a través de la discusión conjunta de los principales contribuyentes y, de acuerdo con una serie de propuestas de los desarrolladores, se determina la dirección futura del desarrollo.

Definición: La reunión principal de desarrolladores es una conferencia telefónica semanal realizada por la comunidad de desarrollo de Ethereum, donde los colaboradores principales de diferentes organizaciones discuten problemas técnicos y coordinan el trabajo futuro en Ethereum. Determinan la dirección técnica futura del protocolo Ethereum y también son la autoridad que realmente toma decisiones sobre la actualización de Ethereum. Son responsables de decidir si EIP se incluye en la actualización, si es necesario cambiar la hoja de ruta y otros asuntos importantes. asuntos.

Proceso principal: el proceso de actualización centrado en EIP es más o menos el siguiente: primero, un EIP se acepta inicialmente en la conferencia de desarrolladores principales (ACD para abreviar) y luego el equipo del cliente lo probará independientemente de si el EIP está incluido en la actualización. Después de la prueba final, revíselo nuevamente y luego decida si incluirlo en la actualización real según la discusión.

Hay dos tipos de reuniones, a saber, la reunión de la capa de consenso y la reunión de la capa ejecutiva, que se llevan a cabo alternativamente cada dos semanas:

Conferencia de capa de consenso (AllCore Developers Consensus - ACDC), centrada en la capa de consenso de Ethereum (Prueba de participación, Beacon Chain, etc.);

Conferencia de capa ejecutiva (solución AllCore Developers - ACDE), que se centra en la capa de ejecución de Ethereum (EVM, horario de gas, etc.).

Hay tres tipos de mantenedores centrales de Ethereum, principalmente organizaciones oficiales o foros de voluntarios que discuten propuestas:

AllCoreDevs: mantenedores de código, responsables del cliente de red ETH1, actualizar, mantener el código Ethereum y la arquitectura central;

Sección "Gestión de proyectos": apoye a los desarrolladores de Ethereum, coordine bifurcaciones duras, monitoree EIP, etc., y ayude directamente a AllCoreDevs con la comunicación y las operaciones;

EthereumMagicians: un "foro" para discutir sobre EIP y otros temas técnicos.

Cronología de las reuniones relacionadas con la escalada en Cancún

De acuerdo con el contenido de la discusión, esta actualización de Cancún se puede dividir aproximadamente en cinco etapas.

La primera etapa: presentación del tema de actualización

Introducir nuevas tareas proto-danksharding, EOF y códigos de operación de "autodestrucción", discutir brevemente el contenido de actualización de Shanghai

Después de que se completó la fusión de Ethereum el 15 y 22 de septiembre, la reunión de desarrolladores se suspendió durante 4 semanas, lo que permitió a los desarrolladores verificar el EIP discutido en la actualización posterior durante un mes;

El 28 y 22 de octubre, la primera reunión de desarrolladores después de la fusión propuso la implementación de proto-danksharding, EOF y el código de operación de "autodestrucción" por primera vez. En este momento, el alcance específico de proto-danksharding no ha sido determinado, y algunos desarrolladores inicialmente piensan que la actualización de Shanghái se puede dividir en varias actualizaciones pequeñas, como habilitar primero los retiros de ETH comprometidos y luego actualizar EIP4844, pero algunos desarrolladores piensan que es más significativo implementar una actualización más grande en un solo paso.

Fase 2 - Determinación del marco de tiempo y preparación para la ceremonia KZG

A fines de 2022, la conferencia Ethereum se centrará principalmente en EOF y EIP4844. Al mismo tiempo, continuaremos promoviendo la ceremonia de configuración precreíble requerida por EIP4844: la ceremonia KZG. Los desarrolladores determinarán formalmente en qué actualización 4844 aparece el 23 de enero

El 22 de noviembre, EOF o proto-danksharding se mencionó en la conferencia telefónica n.º 149 de todos los desarrolladores principales de Ethereum. En este momento, los desarrolladores todavía están considerando colocarlo en la actualización de Shanghái;

En la reunión de Consensus Layer del 02/12/22, Trent Van Epps, jefe del ecosistema Ethereum, actualizó sobre el progreso de la ceremonia de configuración confiable requerida para la implementación de EIP4844, que tiene como objetivo generar una pieza de código seguro que será utilizado en EIP4844. VanEpps espera que la ceremonia sea una de las más grandes en el espacio criptográfico, recaudando entre 8000 y 10 000 contribuciones.El período de contribución pública de la ceremonia durará aproximadamente 2 meses y comenzará en algún momento de diciembre;

En la reunión principal de desarrolladores el mismo día, hubo una discusión sobre EOF y la desactivación del código de operación de autodestrucción. Cierto desarrollador de la Fundación Ethereum se opuso a posponer EOF a Cancún, argumentando que si los cambios de código no se incluyen en Shanghái, entrará La posibilidad de Cancún es muy pequeña. Con respecto al código de autodestrucción, algunos desarrolladores recomendaron avanzar EIP4758 en ese momento, pero deshabilitar directamente este código de operación romperá algunas aplicaciones. Los desarrolladores creen que antes de crear un caso extremo para proteger este tipo de contrato, Este EIP debe pesarse nuevamente por un período de tiempo;

En la reunión central de desarrolladores del 9 de diciembre de 22, se promovió la implementación de la ceremonia KZG con respecto a la actualización de Cancún, en la actualidad, la ceremonia de configuración creíble requerida por EIP4844 está lista;

En la reunión de Consensus Layer del 16/12/22, sobre el tema de EIP4844, los desarrolladores discutieron la fusión de dos solicitudes de extracción (PR) diferentes en la especificación para proto-danksharding, una relacionada con la forma en que los nodos manejan los datos eliminados de One is that cuando falta información sobre blobs en un determinado bloque, se introducirá un nuevo código de error para alertar a los nodos;

En la reunión principal de desarrolladores del 5 de enero de 23, los desarrolladores llegaron a un consenso sobre la eliminación de las modificaciones de código relacionadas con la implementación de EOF de la actualización de Shanghái. En este momento, Beiko sugirió decidir si EOF debería incluirse en el obstáculo después de dos semanas. Kun se está actualizando;

Fase 3 - Discusión Preliminar del Alcance de la Propuesta

A fines del 23 de enero, EOF se trasladó a Cancún para su actualización después de haber sido retirado de Shanghái. En los siguientes dos meses, las discusiones se centraron principalmente en otras propuestas, excepto EOF y EIP4844. Al mismo tiempo, se propuso que EOF se mudara fuera de Cancún. . Este período de tiempo se dedicó principalmente a delinear el alcance de las propuestas para la mejora de Cancún.

En la reunión principal de desarrolladores del 20 al 23 de enero, EOF se trasladó a Cancún para su actualización;

En la reunión principal de desarrolladores del 6 de marzo de 23, las propuestas preliminares para la actualización de Cancún fueron: EIP4788 (raíz del estado de la cadena de balizas públicas), EIP2537 (realizar de manera eficiente operaciones como verificación de firma BLS y verificación SNARK), EIP-5920 (introducción de nuevos opcode PAY), y una implementación combinada de EIP6189 (para hacer que SELFDESTRUCT sea compatible con los árboles de Verkle) y EIP-6190 (que cambia la función SELFDESTRUCT para causar solo un número limitado de cambios de estado);

En la reunión principal de desarrolladores del 16 y 23 de marzo, además de EOF y EIP4844, se consideraron las siguientes propuestas para su inclusión en Cancún: formato SSZ, eliminación de SELFDESTRUCT, EIP2537, EVMMAX, EIP1153, instrucciones SWAP y DUP ilimitadas, introducción de PAY Beacon estado raíz en código y EVM;

En la reunión de desarrolladores del núcleo del 30 de marzo de 23, se presentó por primera vez la propuesta EIP-6780 sobre deshabilitar SELFDESTRUCT, que también es la propuesta de deshabilitar SELFDESTRUCT que Cancún finalmente decidió usar. Pero con respecto a la implementación de EOF, un desarrollador del equipo cliente de Erigon(EL) afirmó que EOF "ha cambiado demasiado" para combinarse con la propuesta de mejora de Ethereum EIP4844 en la próxima actualización de Cancún, que se propuso actualizar en Cancún Implementar EOF en la bifurcación dura poco después;

La cuarta etapa: determine la dirección clara de la actualización de la propuesta y elimine las propuestas irrelevantes

El 23 de abril, hubo una dirección clara para las propuestas que deberían ser cubiertas por la actualización de Cancún. El nodo clave fue la reunión de desarrolladores del 13 de abril. Esta reunión propuso 9 EIP, y Tim mismo también tuvo una comprensión más profunda de las propuestas alternativas En la discusión, en la reunión del 27 de abril, se determinó que EIP6780, EIP6475 y EIP1153 se incluirían en Cancún, mientras que EOF y EVMMAX (subconjuntos de EIP relacionados con la implementación de EOF) se eliminaron de la actualización de Cancún, la actualización de EOF puede ayudar principalmente El control de versiones de EVM y varios conjuntos de reglas de contrato se pueden ejecutar al mismo tiempo, lo que favorece la expansión posterior de Ethereum. Sin embargo, teniendo en cuenta la viabilidad de la actualización completa, la actualización de EOF se puede promover con actualizaciones diarias a continuación. arriba

El 12 y 23 de abril se completó la actualización de Ethereum Shanghai;

Además de la reunión de desarrollo central el 13.04.23 donde los desarrolladores discutieron EIP4844 (para exponer datos sobre la raíz del estado CL en EL), hay al menos otros nueve EIP que se están considerando para la actualización, son EIP4844, eliminación de AUTODESTRUCT ( EIP-6780, EIP4758, EIP6046, EIP6190), EIP5920, EIP1153, EIP2537, EIP4788, EVMMAXEIP (EIP6601 y EIP6690), cambios SSZ (EIP6475, EIP6493, EIP 6465, EIP6404 y EIP6466), EIP 5656 y EIP6193;

En la reunión principal de desarrolladores del 27 al 23 de abril, se enfocaron en varios avances y compensaciones. En primer lugar, se sigue identificando EIP4844 para su inclusión en la actualización de Cancún, mientras que se han agregado los siguientes EIP: EIP6780 (cambia la funcionalidad del código de operación SELFDESTRUCT), EIP6475 (un nuevo tipo de serialización simple (SSZ) para representar valores opcionales), EIP1153 ( agrega nuevo en segundo lugar, los EIP que se están considerando pero que no se incluyen oficialmente en la actualización son EIP6913 (que presenta la instrucción SETCODE), EIP6493 (que define el esquema de firma para transacciones codificadas en SSZ), EIP4788 (que revela la raíz de la cadena de balizas en el bloque EL encabezado), EIP2537 (agrega la curva BLS12-381 como precompilación) y EIP5656 (introduce nuevas instrucciones EVM para copiar regiones de memoria); finalmente, EOF y EVMMAX (subconjunto de EIP relacionado con la implementación de EOF) se eliminaron de la actualización de Cancún. La actualización EOF se eliminó de la actualización de Shanghái en la Conferencia de desarrolladores de Ethereum a principios de enero de 2023, y se prefirió aparecer en la actualización de Cancún desde finales de enero de 2023 hasta principios de abril de 2023, pero el desarrollo del 29 de abril de 23 EOF se elimina nuevamente durante la reunión de los autores.

La quinta etapa: determinación de la propuesta final y mejora de los detalles

El 23 de mayo, los detalles de la propuesta final se simplificaron y mejoraron principalmente. El cambio de SSZ->RLP significará que los dos SSZEIP en Cancún ya no serán necesarios, por lo que los EIP 6475 y 6493 se trasladarán fuera de Cancún para su actualización. También en el caucus del día 26, Tim Beiko sugirió que las futuras conversaciones sobre la expansión del alcance de Cancún se limiten a los siguientes cinco EIP: EIP-5920, 5656, 7069, 4788 y 2530. Los desarrolladores ahora han determinado el alcance total de la actualización de Cancún.

La reunión de consenso de Ethereum Core del 5 de mayo de 23 discutió EIP4788, que se mencionó la última vez, y agregó discusiones sobre EIP6987 y EIP6475, que se refieren a validadores y transacciones SSZ respectivamente;

En la reunión número 161 de la capa ejecutiva de Ethereum el 11 de mayo de 23, TimBeiko dijo que el alcance de la actualización de Cancún aún se puede modificar en las próximas semanas, pero si no hay una sugerencia clara del desarrollador, el alcance de la actualización de Cancún se modificará. be Mantenga el estado "predeterminado", y la discusión sobre EIP-4844 muestra que los desarrolladores acuerdan eliminar SSZ de la implementación EL de EIP-4844, pero no ha afectado el avance continuo de 6475. Además de esto, los desarrolladores también discutieron brevemente dos EIP para su consideración en Cancún, a saber, EIP6969 (una versión modificada de EIP1559) y EIP5656 (instrucciones EVM eficientes para copiar regiones de memoria);

El desarrollo de 4844 se discutió brevemente en la reunión de Consenso de Desarrolladores el 18.05.23, como permitir que las aplicaciones de contratos inteligentes en EL verifiquen las pruebas del estado de CL;

La desactivación de SELFDESTRUCT, los cambios de especificación EIP-4844, la gestión del código de operación y las posibles adiciones eventuales de Cancún se discutieron en la reunión 162 de Ethereum Core el 25 de mayo de 2023. Tim Beiko sugirió que las conversaciones futuras sobre la expansión del alcance de Cancún se limiten a los siguientes cinco EIP: EIP-5920, 5656, 7069, 4788 y 2530. El desarrollador determinará la gama completa de Dencun (Deneb+Cancun) en las próximas semanas;

En la 110.ª reunión de la capa de consenso de Ethereum el 1 de junio de 2023, un investigador de la Fundación Ethereum presentó los resultados de un experimento de datos sobre la capacidad de los nodos de la red principal de Ethereum para difundir grandes cantidades de datos. A partir de este resultado, el investigador sugirió que EIP4844 El la especificación aumentó de un máximo de 4 blobs a 6 por bloque. Al mismo tiempo, los desarrolladores están considerando incorporar EIP4788 en la actualización de Cancún;

En la reunión principal de desarrolladores del 13 de junio de 2023, los desarrolladores confirmaron oficialmente el alcance de la actualización, incluidos EIP4844, EIP1153, EIP5656, EIP6780 y EIP4788;

En la reunión de consenso del 15 de junio de 2023, se discutió qué EIP centrados en CL incluir en Deneb, entre los cuales se propuso agregar EIP-6988, EIP-7044, EIP-7045, y el equipo de cliente de CL acordó el próximo Pruebe el aumento del número de blobs en la red de prueba EIP-4844 Devnet6, y tome una decisión final sobre este asunto dentro de dos semanas Al mismo tiempo, Michael Neuder, investigador de la Fundación Ethereum, propuso cancelar el 32 ETH límite de compromiso para ayudar a reducir el crecimiento del conjunto de validadores activos;

En la reunión del 22 de junio de 2023, Tim propuso mover la dirección precompilada de 4844 a 0xA, empaquetarlos y mover BLS a otra dirección, aunque este precompilado se introdujo a través de EIP2537, no se considerará en el plan de Cancún;

En la reunión de consenso del 29 de junio de 2023, los desarrolladores continuaron discutiendo la cantidad de blobs, aumentaron el límite de blobs objetivo de 2 a 3 y aumentaron el límite máximo de blobs de 4 a 6. Al mismo tiempo, la red de prueba 4844 Devnet #7 se lanzará pronto.

esta vida

El contenido principal es EIP4844, Proto-Danksharding

Los rangos finales de EIP para la actualización de Cancún son: EIP4844, EIP1153, EIP5656, EIP6780 y EIP4788. Al mismo tiempo, en la reunión 111 de Ethereum ACDC el 19 de junio, los desarrolladores continuaron discutiendo EIP6988, EIP7044 y EIP7045 para su inclusión en Deneb. Los desarrolladores dijeron que planean fusionar los tres EIP antes mencionados en la especificación Deneb en las próximas semanas.

Análisis de EIP clave

####EIP4844

Introducción:

El nombre de la propuesta EIP4844 es Proto-Danksharding, que es la solución previa a la fragmentación para la versión completa de Danksharding.Todo el conjunto de esquemas de fragmentación en realidad gira en torno a Rollup para la expansión en cadena. El propósito de la solución es expandir el paquete acumulativo de capa 2, al ayudar a L2 a reducir las tarifas y aumentar el rendimiento, al tiempo que allana el camino para la fragmentación completa.

En la conferencia telefónica del 23 de febrero, los desarrolladores de Ethereum actualizaron EIP4844 y lo llamaron Deneb, que es el nombre de una estrella de primera clase en Cygnus. Es decir, el nombre de EIP4844 en la versión relevante de GitHub se actualizará a Deneb en el futuro; En la reunión del 1 de marzo, hubo algunos cambios en la próxima especificación de actualización de Ethereum, que se llama Deneb en el lado CL y Cancún en el lado EL;

En la reunión de desarrolladores del 23 de junio de 23, los desarrolladores iban a actualizar la dirección precompilada de EIP4844. Actualmente, los desarrolladores principales han agregado 9 precompilaciones a EVM y crearán dos precompilaciones en las direcciones "0xA" y "0xB" activando EIP4844 y 4788 respectivamente. En la reunión de consenso del 29 de junio, se preparó Devnet#7, una red de prueba a corto plazo dedicada para EIP4844.

EIP-4844 presenta un tipo de transacción completamente nuevo: BlobTranscation.

Introducción a las manchas:

Blob, similar a un paquete de datos de complemento, solo tiene un espacio de almacenamiento de 128 KB al principio. Al comienzo de la discusión de la propuesta, el objetivo y el límite de Blob eran 2/4. En la reunión de desarrolladores del 9 de junio. , 23, se ajustó a 3/6 . Es decir, en la actualidad, cada transacción en Ethereum puede llevar hasta tres transacciones Blob, que es de 384 KB, y la capacidad de targetBlob de cada bloque es de 6, que es de 768 KB, y puede llevar un máximo de 16 transacciones Blob, que es de 2 MB;

Puede tener cierto impacto en la estabilidad de la red, pero el equipo de desarrollo de Ethereum decidió probarlo primero para evitar la necesidad de bifurcaciones posteriores para expandir el bloque de blobs.

Blob usa KZGcommit Hash como Hash para la verificación de datos, similar a Merkle;

Después de que el nodo sincronice BlobTransaction en la cadena, la parte Blob caducará y se eliminará después de un período de tiempo, y el tiempo de almacenamiento es de tres semanas.

El papel de Blob: mejore el TPS de Ethereum mientras reduce los costos

En la actualidad, el volumen total de datos de todo Ethereum es solo de aproximadamente 1 TB, y Blob puede traer de 2,5 a 5 TB de volumen de datos adicional a Ethereum cada año, lo que supera directamente el propio libro mayor varias veces;

Para los nodos, la descarga de 1 MB a 2 MB de datos de blob por bloque no causará una carga de ancho de banda, y el espacio de almacenamiento solo aumentará la cantidad fija de datos de blob de aproximadamente 200 ~ 400 GB por mes, lo que no afectará la descentralización de todo. nodo Ethereum, pero la expansión en torno a Rollup ha mejorado mucho;

Y el nodo en sí no necesita almacenar todos los datos del blob, porque el blob es en realidad un paquete de datos temporal, por lo que, de hecho, el nodo solo necesita descargar una cantidad fija de datos durante tres semanas.

El papel de EIP-4844: apertura del primer capítulo de la narrativa Danksharding

Alta expansión: en la actualidad, EIP-4844 puede expandir inicialmente la capacidad L2. La versión completa de Danksharding puede expandir el volumen de datos Blob en EIP-4844 de 1 MB a 2 MB a 16 MB a 32 MB. Alta expansión;

Tarifas bajas: según los analistas de Bernstein, Proto-dank-sharding puede reducir las tarifas de la red de capa 2 a 10-100 veces el nivel actual;

Los datos reales:

La red de prueba Opside ha implementado 4844, y la observación actual puede reducir el costo de implementación en un 50 %;

La solución técnica DA de EigenLayer no revela demasiado para evaluar sus datos;

Estrictamente hablando, Celestia tiene poco que ver con Ethereum, y su costo de DA no se puede evaluar ahora, dependiendo de sus soluciones técnicas específicas;

La solución de Ethstorage es cargar su certificado de almacenamiento Layer2, y su costo de DA puede reducirse al 5% del original;

Topia espera reducir los costos entre 100 y 1000 veces, porque la red principal Danksharding también debe tener en cuenta la seguridad y la compatibilidad con la transmisión de red P2P de capa 1.

Solución DA: Danksharding (una solución de fragmentación para la expansión de Ethereum) actualmente puede causar problemas como una carga excesiva de nodos (más de 16 mb) y disponibilidad de datos insuficiente (período de validez de 30 días). Solución:

Muestreo de disponibilidad de datos: reduce la carga del nodo

Corte los datos en Blob en fragmentos de datos y deje que los nodos cambien de descargar los datos de Blob a verificar aleatoriamente los fragmentos de datos de Blob, de modo que los fragmentos de datos de Blob estén dispersos en cada nodo de Ethereum, pero los datos de Blob completos se almacenen. en todo el libro mayor de Ethereum In Fang, la premisa es que los nodos deben ser suficientes y descentralizados;

DAS utiliza dos tecnologías: codificación de borrado (ErasureCoding) y compromiso polinomial KZG (KZGCommitment);

Separación de proponente y empaquetador (PBS): resuelve el problema de la división del trabajo entre nodos, lo que permite que los nodos con configuraciones de alto rendimiento sean responsables de descargar todos los datos para la codificación y distribución, y permite que los nodos con configuraciones de bajo rendimiento sean responsables de las verificaciones puntuales. y verificaciones.

Los nodos con configuraciones de alto rendimiento pueden convertirse en constructores. Los constructores solo necesitan descargar datos de blob para codificar y crear bloques, y luego transmitirlos a otros nodos para verificaciones puntuales. Para los constructores, debido a que los requisitos de ancho de banda y volumen de datos de sincronización son altos, será relativamente centralizado;

Un nodo con configuración de bajo rendimiento puede convertirse en proponente (Proponente). El proponente solo necesita verificar la validez de los datos y crear y transmitir el encabezado del bloque (BlockHeader). Sin embargo, para el proponente (Proponente), la cantidad de datos síncronos y los requisitos de ancho de banda son relativamente altos o bajos, por lo que será descentralizado.

Lista anticensura (crList): resuelve el problema de que los empaquetadores pueden ignorar deliberadamente ciertas transacciones e insertar transacciones que desean obtener MEV debido a su excesivo poder de revisión.

Antes de que el constructor (Builder) empaquete las transacciones en bloque, el proponente (Proponente) publicará una lista anticensura (crList), que contiene todas las transacciones en el mempool;

El constructor (Constructor) solo puede elegir empaquetar y clasificar las transacciones en crList, lo que significa que el constructor no puede insertar su propia transacción privada para obtener MEV, ni puede rechazar deliberadamente una transacción (a menos que el Gaslimit esté lleno);

Después de empacar, el Constructor transmite la versión final de la lista de transacciones Hash al Proponente, y el Proponente selecciona una de las listas de transacciones para generar un encabezado de bloque (BlockHeader) y transmitirlo;

Cuando el nodo sincroniza los datos, obtendrá el encabezado del bloque del proponente (Proponente) y luego obtendrá el cuerpo del bloque del empaquetador (Generador), para garantizar que el cuerpo del bloque sea la versión final seleccionada.

PBS de doble ranura: resuelve el problema de que los empaquetadores centralizados se están volviendo cada vez más centralizados mediante la adquisición de MEV

Utilice el modo de oferta para determinar el bloque:

El constructor (Builder) crea el encabezado de bloque de la lista de transacciones después de obtener crList y bids;

El proponente (Proponente) selecciona el encabezado del bloque y el constructor (Constructor) que finalmente oferta con éxito, y el proponente recibe incondicionalmente la tarifa de la oferta ganadora (independientemente de si se genera un bloque válido);

El comité de verificación (Comités) confirma la cabecera del bloque ganador;

El Constructor revela el cuerpo del bloque ganador;

El comité de verificación (Comités) confirma el cuerpo del bloque ganador y realiza un voto de verificación (si se pasa el bloque, se produce el bloque, y si el empaquetador deliberadamente no le da Cuerpo al bloque, se considera que el bloque no existir).

significado:

En primer lugar, el constructor (Builder) tiene más poder para empaquetar transacciones, pero la crList mencionada anteriormente, en primer lugar, limita la posibilidad de insertar transacciones temporalmente y, en segundo lugar, si el constructor (Builder) quiere beneficiarse cambiando el orden de las transacciones, es es necesario pagar un alto costo de licitación al principio para asegurarse de que pueda obtener la calificación de la cabeza de bloque, luego la ganancia MEV que obtiene se reducirá aún más y, en general, tendrá un impacto en los medios y el valor real de obtener VEM;

Sin embargo, en la etapa inicial, solo una pequeña cantidad de personas pueden convertirse en empacadores (considerando los problemas de rendimiento de los nodos), mientras que la mayoría de las personas solo se convierten en proponentes, lo que puede llevar a una mayor centralización. pequeño En determinadas circunstancias, es más probable que algunos mineros experimentados con capacidades MEV presenten una oferta exitosa, lo que afectará aún más el efecto real de la solución MEV;

Esto tiene implicaciones para algunas soluciones MEV que utilizan subastas MEV.

significado:

EIP4844 es en realidad una versión súper simplificada de Danksharding: proporciona la misma interfaz de aplicación que Danksharding, incluido un nuevo código de operación llamado DataHash y un nuevo objeto de datos llamado BinaryLarge Objects, que es Blob;

proto-danksharding es una propuesta de "soporte" (es decir, formato de transacción y reglas de verificación) para implementar la especificación completa de Danksharding: sin embargo, aún no se ha implementado ningún sharding, y todos los verificadores y usuarios aún necesitan verificar directamente la disponibilidad de datos completos ;

¿Por qué elige proto-danksharding en lugar de EIP4488 para reducir directamente la tarifa de capa 2 a largo plazo, porque solo se requiere un pequeño ajuste cuando se actualiza a un fragmento completo en el futuro?

La principal diferencia práctica entre EIP4488 y proto-danksharding es que EIP-4488 intenta minimizar los cambios que Ethereum necesita hacer hoy, mientras que proto-danksharding realiza más cambios en Ethereum hoy para actualizar a Ethereum en el futuro. necesario para la fragmentación de la versión completa;

Si bien la implementación de la fragmentación completa (con muestreo de disponibilidad de datos, etc.) es una tarea compleja, y aún queda un trabajo complejo por realizar después de implementar la fragmentación protodanza, estas complejidades se controlarán en la capa de consenso. Una vez que se implementa proto-danksharding, el equipo de cliente de la capa ejecutiva, los desarrolladores de resumen y los usuarios no necesitan realizar ningún trabajo adicional al realizar la transición a la fragmentación completa.

Para lograr la fragmentación completa, es necesario completar la implementación real de PBS, prueba delegada y muestreo de disponibilidad de datos, pero dichas modificaciones se concentrarán en la capa CL y los desarrolladores no necesitan reajustarse: actualmente 4844 implementa un nuevo tipo de transacción , que es similar a El formato de transacción, la lógica de validación cruzada de consenso y la lógica de capa de ejecución requeridas en un fragmento completo son exactamente iguales, y también se deriva un precio de gas independiente autoajustable para blobs. en el futuro, PBS y las pruebas delegadas deben completarse y la implementación real del muestreo de disponibilidad de datos, pero estas modificaciones son solo en la capa CL y no requieren modificaciones por parte de la capa EL o los desarrolladores acumulativos, lo cual es conveniente para los desarrolladores.

Seguido de la eliminación de SELFDESTRUCT, finalmente se determinó que EIP-6780 era la solución más adecuada, pero en la reunión de desarrolladores del día 26, Tim propuso agregar otro código de operación SETCODE a esta propuesta para permitir que las cuentas programáticas aún se actualicen.

AUTODESTRUCCIÓNeliminación EIP-6780：X

fondo:

El 21 de marzo, Vitalik propuso que SELFDESTRUCT hace más daño que bien a la ecología de Ethereum. La razón principal es que es el único que puede cambiar una cantidad infinita de objetos de estado en un solo bloque, lo que resulta en cambios en el código del contrato, y puede ser modificado sin el consentimiento de la cuenta El código de operación del saldo de la cuenta tiene un gran peligro oculto para la seguridad de Ethereum;

La única forma de eliminar un contrato en cadena es AUTODESTRUCCIÓN. Si llama a la función de autodestrucción en el contrato, puede autodestruir el contrato. El Ethereum almacenado en el contrato será enviado a la dirección designada. El código restante y las variables de almacenamiento se eliminarán en la máquina de estado. De hecho, la acción de destrucción del contrato suena bien en teoría, pero en realidad es muy peligrosa. Aunque la función de autodestrucción puede ayudar a los desarrolladores a eliminar el contrato inteligente y transferir el saldo del contrato a la dirección especificada en caso de emergencia, los delincuentes también utilizan esta función, lo que la convierte en un medio de ataque.

En la reunión principal de desarrolladores del 13 y 23 de abril, se presentaron cuatro propuestas sobre SELFDESTRUCT para participar en la discusión, a saber, 6780, 4758, 6046 y 6190, y el seguimiento EIP6780 se determinó como la propuesta final.

Introducción: la autodestrucción es el botón de emergencia del contrato inteligente, que destruye el contrato y transfiere el ETH restante a la cuenta designada.

EIP6780: deshabilite SELFDESTRUCT a menos que estén en la misma transacción en el contrato.

ACTUALIZACIÓN: el 26 de mayo, Tim propuso que, además de eliminar SELFDESTRUCT, agregara otro código de operación: SETCODE, para permitir que las cuentas programáticas aún se actualicen. (Es decir, se agrega la función de actualización y la propiedad en el contrato inteligente se actualiza mediante actualización/actualización.) Aquí, se absorben las ventajas de EIP4758, lo que permite que dapp tenga espacio para la actualización.

Motivo: la manipulación del código SELFDESTRUCT originalmente requería cambios extensos en el estado de la cuenta, como eliminar todos los códigos y el almacenamiento. Esto crea dificultades para usar árboles de Verkle en el futuro: cada cuenta se almacenará en muchas claves de cuenta diferentes que no estarán conectadas explícitamente a la cuenta raíz.

CAMBIADO: este EIP implementa un cambio que elimina AUTODESTRUCT, con las siguientes dos excepciones

Las aplicaciones que solo se usan para retirar fondos de SELFDESTRUCT seguirán funcionando;

Tampoco es necesario cambiar el AUTODESTRUCT utilizado en la misma transacción en el contrato.

Importancia: mejorar la seguridad

Anteriormente, había un contrato en la red principal que usaba SELFDESTRUCT para restringir quién podía iniciar transacciones a través del contrato;

Para evitar que los usuarios continúen depositando fondos y comerciando en una bóveda después de SELFDESTRUCT, esta bóveda puede hacer que cualquiera robe tokens en la bóveda durante el uso repetido.

Las tres propuestas a continuación son propuestas relacionadas con SELFDESTRUCT que se eliminaron posteriormente. 6780 se seleccionó oficialmente en la reunión principal de desarrolladores el 28 y 23 de abril, y las tres propuestas restantes se abandonaron porque el equipo de desarrollo de Ethereum finalmente quería eliminar por completo el código de operación SELFDESTRUCT. y las siguientes tres propuestas se modifican más por medio de reemplazo.

EIP-4758 (OBSOLETO): deshabilite SELFDESTRUCT cambiando SELFDESTRUCT a SENDALL, que restaura todos los fondos a la persona que llama (envía todo el éter de la cuenta a la persona que llama), pero no elimina ningún código ni almacenamiento.

Motivo: igual que el anterior, la manipulación previa de los códigos SELFDESTRUCT requería cambios extensos en el estado de la cuenta, como eliminar todos los códigos y el almacenamiento. Esto crea dificultades para usar árboles de Verkle en el futuro: cada cuenta se almacenará en muchas claves de cuenta diferentes que no estarán conectadas explícitamente a la cuenta raíz.

Cambiar:

Opcode SELFDESTRUCT renombrado a SENDALL, ahora solo mueve todos los ETH en la cuenta a la persona que llama, el esquema ya no rompe el código y el almacenamiento, ni cambia los nonces;

Se han eliminado todos los reembolsos relacionados con SELFDESTRUCT.

significado:

La funcionalidad original se conserva en comparación con EIP-6780, porque algunas aplicaciones aún necesitan usar el código SELFDESTRUCT.

EIP-6046 (obsoleto): Reemplazar AUTODESTRUCCIÓN con DESACTIVAR. Cambie SELFDESTRUCT para no eliminar la clave de almacenamiento y use un valor especial en la cuenta nonce para indicar la desactivación

Motivo: igual que el anterior, con los árboles de Verkle, las cuentas se organizarán de manera diferente: las propiedades de la cuenta (incluido el almacenamiento) tendrán claves separadas, pero será imposible atravesar y encontrar todas las claves utilizadas. La manipulación de los códigos SELFDESTRUCT anteriormente requería cambios extensos en el estado de la cuenta, lo que hacía muy difícil continuar usando SELFDESTRUCT en los árboles de Verkle.

Cambiar:

Cambie las reglas introducidas por EIP-2681 para que los incrementos nonce regulares estén limitados por 2^64-2 en lugar de 2^64-1;

SELFDESTRUCT se cambia a:

No elimine ninguna clave de almacenamiento y deje la cuenta en su lugar;

Transfiera el saldo de la cuenta al objetivo y establezca el saldo de la cuenta en 0.

Establezca la cuenta nonce en 2^64-1.

Sin reembolsos desde EIP-3529;

La regla relevante SELFDESTRUCT de EIP-2929 permanece sin cambios.

significado:

Esta propuesta tiene más flexibilidad que otros comportamientos que eliminan directamente SELFDESTRUCT.

EIP-6190 (obsoleto): cambie SELFDESTRUCT, compatible con Verkle, para que solo provoque un número limitado de cambios de estado

Motivo: igual que el anterior, con los árboles de Verkle, las cuentas se organizarán de manera diferente: las propiedades de la cuenta (incluido el almacenamiento) tendrán claves separadas, pero será imposible atravesar y encontrar todas las claves utilizadas. La manipulación de los códigos SELFDESTRUCT anteriormente requería cambios extensos en el estado de la cuenta, lo que hacía muy difícil continuar usando SELFDESTRUCT en los árboles de Verkle.

Cambio: en lugar de destruir el contrato al final de la transacción, sucede lo siguiente al final de la transacción que lo llamó:

El código de contrato se establece en 0x1 y el número aleatorio se establece en 2^64-1.

El intervalo 0 del contrato se establece en la dirección que se publicará cuando el contrato utilice el código de operación CREATE (keccak256(contractAddress, nonce)). El número aleatorio siempre es 2^64-1.

Si el contrato se autodestruye después de que uno o más contratos de alias reenvían la llamada, establezca la ranura de almacenamiento 0 del contrato de alias en la dirección calculada en el paso 2;

Todo el saldo del contrato se transferirá a la dirección en la parte superior de la pila;

Se abre la parte superior de la pila.

significado:

Diseñado para permitir que SELFDESTRUCT forme posteriormente árboles Verkle con cambios mínimos;

El costo del gas aumentó con la aplicación de EIP-2929.

Luego está EIP1153, que ahorra gas y allana el camino para el futuro diseño de almacenamiento.

EIP1153X

Resumen: Códigos de operación de almacenamiento transitorios, agregue códigos de operación para manipular el estado que se comporta igual que las tiendas pero se descarta después de cada transacción.

razón:

Ejecutar una transacción en Ethereum puede generar múltiples marcos de ejecución anidados, cada marco creado por una instrucción CALL (o similar). Los contratos se pueden volver a ingresar en la misma transacción, en cuyo caso más de un cuadro pertenece a un contrato.

Actualmente, estos marcos pueden comunicarse de dos maneras: entrada/salida a través de instrucciones CALL y a través de actualizaciones de la tienda. La comunicación a través de E/S no es segura si hay un marco intermedio que pertenece a otro contrato que no es de confianza.

Tomando el bloqueo de reentrada como ejemplo, no puede depender de marcos intermedios para transmitir el estado del bloqueo: la comunicación SSTORE SLOAD a través del almacenamiento es costosa, y el almacenamiento transitorio es una solución dedicada y eficiente en gas al problema de la comunicación entre marcos.

Cambiado: se agregaron dos nuevos códigos de operación a EVM, TLOAD (0xb3) y TSTORE (0xb4).

El almacenamiento transitorio es privado para el contrato que lo posee y, al igual que el almacenamiento persistente, solo el marco del contrato propietario puede acceder a su almacenamiento efímero. Al acceder al almacenamiento, todos los marcos acceden al mismo almacenamiento efímero de la misma manera que el almacenamiento persistente, pero de manera diferente a la memoria.

Posibles casos de uso:

bloqueo de reentrada;

Direcciones CREATE2 computables en cadena: los parámetros del constructor se leen del contrato de fábrica, en lugar de pasarse como parte del hash del código de inicialización;

Aprobación EIP-20 de transacción única, por ejemplo, #temporaryApprove(addressspender, uint256 cantidad);

Contrato de tarifa de transferencia: pague una tarifa al contrato de token para desbloquear transferencias durante las transacciones;

Modo "hasta": permite al usuario realizar todas las operaciones como parte de la devolución de llamada y comprueba si "hasta" está equilibrado al final;

Metadatos de llamadas de proxy: Pase metadatos adicionales para implementar contratos sin usar datos de llamadas, como los valores de los parámetros inmutables del constructor de proxy.

significado:

Ahorre gas y tenga reglas de facturación de gas más simples;

Resolver el problema de la comunicación entre cuadros;

no cambia la semántica de las operaciones existentes;

No es necesario borrar la ranura de almacenamiento después de su uso;

Los futuros diseños de almacenamiento (como los árboles de Verkle) no necesitan considerar el problema de las devoluciones de cargo por el almacenamiento instantáneo.

Luego está 4788, que puede reducir la suposición de confianza del fondo de compromiso.

####EIP4788：X

Breve: Raíces de bloque Beacon en el EVM.

Actualización: en la reunión de desarrolladores del 15.06.23, los desarrolladores propusieron realizar cambios en el código para mejorar la experiencia del staker, este EIP revelará la raíz del bloque de la cadena de balizas, que contiene la información del estado de la cadena interna de EVM, para los desarrolladores de DApp de confianza. acceso minimizado.

Cambiado: envíe las raíces hash de cada bloque de cadena de balizas en el encabezado de carga útil de ejecución correspondiente, almacene estas raíces en un contrato en estado de ejecución y agregue un nuevo código de operación para leer ese contrato.

Importancia: Esta es una propuesta de modificación de código, que propone modificar la Máquina Virtual Ethereum (EVM) para que pueda divulgar los datos de la capa de contrato (CL) estado raíz en la capa de ejecución (EL), que puede hacer diferentes protocolos y aplicaciones en la red Ethereum La comunicación entre programas es más eficiente y segura. Permita diseños más confiables para replantear grupos, puentes y protocolos de replanteo.

Finalmente, está el 5656, que proporciona un nuevo código de operación de copia de memoria eficiente, pero actualmente se encuentra en un estado de inclusión temporal en una actualización debido a su ancho de banda de prueba.

####EIP5656X

Introducción: MCOPY- Instrucción de copia de memoria.

ACTUALIZACIÓN: El 06/09/23, el equipo de desarrollo declaró que inicialmente estaban divididos en MCOPY porque, si bien resolvía el problema de seguridad, estaban preocupados por el ancho de banda de implementación y prueba necesario para agregarlo a la actualización, pero finalmente acordaron incluir el EIP. Sin embargo, si el desarrollador encuentra problemas de capacidad en las pruebas o en el lado del cliente, se considerará su eliminación. Como tal, MCOPY está en estado de ser incluido temporalmente en la actualización de Cancún.

Cambiado: Proporcionó una instrucción EVM eficiente para copiar regiones de memoria.

Importancia: la copia de memoria es una operación fundamental, pero su implementación en el EVM tiene un costo.

Con la disponibilidad de la instrucción MCOPY, las palabras de código y las oraciones se pueden copiar con mayor precisión, lo que mejorará el rendimiento de la copia de memoria en aproximadamente un 10,5 %, lo que es muy útil para varias operaciones de computación intensiva;

También sería útil para los compiladores generar códigos de bytes más eficientes y más pequeños;

Puede ahorrar una cierta cantidad de costos de gas para la precompilación de identidades, pero en realidad no puede promover la realización de esta parte.

Lista de candidatos EIP

El 15 y 23 de junio, la reunión de consenso de desarrolladores discutió qué EIP centrados en CL incluir en Deneb, entre los cuales se propuso agregar EIP6988, EIP7044 y EIP7045.

####EIP6988：X

Resumen: evita que los validadores reducidos sean elegidos como proponentes de bloque.

Importancia: el aumento de las sanciones por violar los nodos beneficiará a la TVP.

####EIP7044：X

Resumen: Garantizar que las salidas del validador firmadas sean permanentemente válidas.

Importancia: Puede mejorar la experiencia del staker hasta cierto punto.

####EIP7045：X

Resumen: Amplíe el rango de inclusión de la ranura de atestación de una ventana móvil de una época a dos épocas.

Importancia: mejorar la seguridad de la red.

Eliminar el análisis de EIP

En la reunión número 160 de Ethereum ACDE el 29 y 23 de abril, se confirmó que EVMMAX y EOF se eliminarán de esta actualización, y es posible que se introduzcan cambios relacionados con EOF en actualizaciones diarias posteriores.

EVMMAXEIP:

Resumen: EVMMAX tiene como objetivo brindar una mayor flexibilidad a las operaciones aritméticas y los esquemas de firma en Ethereum. Actualmente, hay dos propuestas EVMMAX, una con EOF y otra sin EOF.

EIP6601: Extensiones aritméticas modulares EVM (EVMMAX)

Cambio: es una iteración de EIP5843, la diferencia con EIP5843 es:

6601 introduce un nuevo tipo de sección EOF que almacena el módulo, el parámetro de Montgomery precalculado, la cantidad de valores que se utilizarán (todavía se admite el módulo configurable en tiempo de ejecución);

6601 usa un espacio de memoria separado para los valores EVMMAX, con nuevos códigos de operación de carga/almacenamiento para mover valores entre la memoria EVM<->EVMMAX;

El 6601 admite operaciones en módulos de hasta 4096 bits (límite tentativo mencionado en EIP).

Importancia: EIP-5843 presenta sumas, restas y multiplicaciones modulares eficientes para la máquina virtual Ethereum, y EIP-6601 se basa en esto al presentar una sección de configuración, un espacio de memoria separado y nuevos códigos de operación para operaciones aritméticas modulares. Brinda una mejor organización y flexibilidad. al tiempo que admite módulos más grandes y mejora el rendimiento de EVM.

Como contrato EVM, que permite operaciones aritméticas de curvas elípticas en varias curvas, incluido BLS12-381;

MULMOD reduce el costo de gas de operar en valores de hasta 256 bits en un 90-95% en comparación con los códigos de operación ADDMOD existentes;

Permite que la precompilación de modexp se implemente como contratos EVM;

Reduzca significativamente el costo de la verificación ZKP en funciones hash algebraicas (como MiMC/Poseidon) y EVM.

EIP6690:

Cambio: EIP-6990 es una propuesta adaptada de EIP-6601 para introducir operaciones aritméticas modulares optimizadas en EVM sin depender de EOF. Mientras que EIP-6601 requiere EIP-4750 y EIP-3670 como dependencias, EIP-6990 proporciona una solución más independiente. Proporciona un enfoque más simplificado al eliminar la dependencia de EOF.

Importancia: conserva la funcionalidad central de EIP-6601 para realizar operaciones aritméticas modulares optimizadas en módulos impares de hasta 4096 bits, esta simplificación permite una implementación y adopción más eficientes al mismo tiempo que brinda los beneficios asociados con EIP-6601.

EOFcambios:

Introducción: EOF es una actualización de EVM, que introduce nuevos estándares de contrato y algunos códigos de operación nuevos. El código de bytes EVM tradicional (código de bytes) es una secuencia no estructurada de código de bytes de instrucciones. EOF introduce el concepto de contenedor, que implementa bytecode estructurado. El contenedor consta de un encabezado y varias secciones para estructurar el código de bytes. Después de la actualización, EVM podrá realizar el control de versiones y ejecutar varios conjuntos de reglas de contrato al mismo tiempo.

EIP663:

Breve: instrucciones SWAP y DUP ilimitadas

Importancia: mediante la introducción de dos nuevas instrucciones: SWAPN y DUPN, que difieren de SWAP y DUP al aumentar la profundidad de la pila de 16 elementos a 256 elementos.

EIP3540:

Introducción:

En el pasado, el bytecode de EVM implementado en la cadena no tenía una estructura predefinida, y el código solo se verificaba antes de ejecutarse en el cliente, lo que no solo es un costo indirecto, sino que también dificulta que los desarrolladores introduzcan nuevas funciones. O desaprobar la funcionalidad antigua.

Este EIP introduce un contenedor que se puede expandir y controlar la versión para el EVM, y declara el formato del contrato EOF. En base a esto, el código se puede verificar cuando se implementa el contrato EOF, es decir, la validación del tiempo de creación, lo que significa que puede evitar que se implementen contratos no razonables que se ajusten al formato EOF. Este cambio implementa el control de versiones EOF, lo que ayudará a deshabilitar las instrucciones EVM existentes o introducir funciones a gran escala (como la abstracción de cuentas) en el futuro.

significado:

El control de versiones conduce a la introducción o desaprobación de nuevas funciones en el futuro (como la introducción de la abstracción de cuentas);

La separación del código del contrato y los datos es beneficiosa para la verificación L2 (op), reduciendo el costo de gas de los validadores L2. Al mismo tiempo, la separación del código del contrato y los datos también es más conveniente para las herramientas de análisis de datos en la cadena.

EIP3670:

Introducción: Basado en EIP-3540, el propósito es garantizar que el código del contrato EOF se ajuste al formato válido, y se evitará la implementación del contrato que no se ajusta al formato, y Legacybytecode no se verá afectado.

Importancia: según el contenedor introducido por 3540, EIP-3670 garantiza que el código en el contrato EOF sea válido o evita que se implemente. Esto significa que los códigos de operación no definidos no se pueden implementar en contratos EOF, lo que tiene el beneficio adicional de reducir la cantidad de versiones EOF que se deben agregar.

EIP4200:

Introducción:

Se introducen los primeros códigos de operación específicos de EOF: RJUMP, RJUMPI y RJUMPV, que codifican destinos como valores inmediatos firmados. Los compiladores pueden usar estos nuevos códigos de operación JUMP para optimizar el costo de gas de implementar y ejecutar JUMP porque eliminan el tiempo de ejecución requerido para hacer el análisis de salto para los códigos de operación JUMP y JUMPI existentes. Este EIP es un complemento de dynamicjump.

En comparación con la operación JUMP tradicional, la diferencia es que las operaciones como RJUMP no especifican una posición de desplazamiento específica, sino que especifican una posición de desplazamiento relativa (desde saltos dinámicos -> saltos estáticos), porque los saltos estáticos suelen ser suficientes.

Importancia: optimizar la red y reducir costes.

EIP4750:

Lleve la función de 4200 un paso más allá: mediante la introducción de dos nuevos códigos de operación de CALLF y RETF, se realiza una solución alternativa para la situación que no puede ser reemplazada por RJUMP, RJUMPI y RJUMPV, por lo que JUMPDEST ya no es necesario en el contrato EOF, es decir, Por lo tanto, el salto dinámico está deshabilitado.

Importancia: Optimice el código dividiéndolo en varias partes.

EIP5450:

Antecedentes: el contexto sigue siendo que el contrato de Ethereum no se verifica cuando se implementa, y solo se realiza una serie de controles cuando se ejecuta, si la pila se desborda (el límite superior es 1024), si el gas es suficiente y pronto.

Contenido: se agregó otra verificación de validez para los contratos EOF, esta vez alrededor de la pila. Este EIP evita situaciones en las que las implementaciones de contratos EOF podrían provocar desbordamientos/desbordamientos de la pila. De esta forma, los clientes pueden reducir la cantidad de comprobaciones de validez que realizan durante la ejecución de los contratos EOF.

Importancia: una mejora importante es hacer que estas comprobaciones que se producen durante la ejecución sean lo menos posible y que se produzcan más comprobaciones cuando se implementa el contrato.

Después de la actualización de la reunión de desarrolladores del 26 de mayo, el cambio del tipo de transacción de SSZ a RLP relacionado con EIP4844 significó que los dos SSZEIP en Cancún ya no eran necesarios, por lo que EIPs6475 y 6493 se trasladaron fuera de Cancún para actualizar

####EIP6475X

Introducción: propuesta complementaria a EIP4844. Proto-danksharding presenta un nuevo tipo de transacción que utiliza la codificación SSZ en lugar de la codificación RLP utilizada por otros tipos de transacciones.

ACTUALIZACIÓN: Durante la 161.ª reunión de desarrolladores principales de la capa de ejecución de Ethereum, las discusiones sobre el formato de serialización SSZ para EIP4844 revelaron que inicialmente los desarrolladores tendían a introducir iteraciones tempranas del formato SSZ a EL a través de transacciones de blob y, finalmente, los desarrolladores planean traer todo el tipo de transacción se actualizó de RLP a SSZ, pero los desarrolladores han estado sopesando eliminar SSZ de EIP-4844 dada su ruta poco clara y, ciertamente, no poder implementarlo en la actualización de Cancún. Después de muchas discusiones, los desarrolladores acordaron eliminar SSZ de la implementación EL de EIP-4844, pero aún no han eliminado EIP6475. Después de la actualización del 26 de mayo, el cambio SSZ->RLP significará que los dos SSZEIP en Cancún ya no serán necesarios: por lo tanto, los EIP 6475 y 6493 se trasladarán fuera de Cancún para realizar actualizaciones.

####EIP6493X

Introducción: esquema de firma de transacciones SSZ. Este EIP define un esquema de firma para las transacciones codificadas de serialización simple (SSZ) y abordará cómo los nodos deben manejar los tipos de transacciones de blob que están formateados en formato SSZ en CL pero codificados de manera diferente en EL. Este EIP es parte de una actualización del formato de serialización de Ethereum para lograr coherencia entre capas;

Antecedentes: cambios SSZ

Introducción: SimpleSerialiZe es el método de serialización utilizado en la cadena de balizas.

SSZchanges también incluye otras tres propuestas de apoyo, esta vez solo se presentó 6465.

EIP6465: raíz de retiro SSZ, que define el proceso de migración de los compromisos Merkle-PatriciaTrie (MPT) existentes a retiros de serialización simple (SSZ);

EIP6404/ EIP6466:

Ambos definen un proceso para migrar los compromisos existentes de Merkle-PatriciaTrie (MPT) a Simple Serialization (SSZ).

EIP-6404: raíz de transacción SSZ

EIP-6466— Base de recibos SSZ

Tim Beiko sugirió en la reunión principal de desarrolladores del 26 de mayo que las conversaciones futuras sobre la expansión del alcance de Cancún se limiten a los siguientes cinco EIP: EIP5920, 5656, 7069, 4788 y 2537, y que se generarán propuestas posteriores dentro de este alcance. EIP5656 y EIP4788 subsiguientes se confirmaron como propuestas de actualización formales, y se eliminaron 5920, 7069 y 2537. Entre ellos, EIP5920 se debió a las preocupaciones de los desarrolladores sobre los posibles efectos secundarios de la forma de transferir ETH, así como razonamiento, pruebas, y trabajo de seguridad Eliminado de la actualización.

####EIP5920：X

Introducción: código de operación de pago. Introduce el nuevo código de operación PAY para transferencias de Ethereum, que envía Ether a una dirección sin llamar a ninguna de sus funciones.

Motivo: actualmente, enviar ether a una dirección requiere que el usuario llame a una función en esa dirección, lo que tiene varios problemas:

Primero, abre un vector para ataques de reentrada, ya que el receptor puede devolver la llamada al remitente;

En segundo lugar, abre un vector DoS, por lo que la función principal debe tener en cuenta que el receptor puede quedarse sin gasolina o devolución de llamada;

Finalmente, el código de operación CALL es innecesariamente costoso para transferencias simples de ether, ya que requiere expandir la memoria y la pila, cargar todos los datos del receptor, incluido el código y la memoria, y finalmente necesita realizar una llamada, posiblemente realizando otras operaciones no intencionales.

Cambiar:

Se ha introducido un nuevo código de operación: (PAY)PAY_OPCODE, donde:

Extraiga dos valores de la pila: addrthenval.

Transferir wei de la dirección de ejecución val a la dirección addr. Si addr es una dirección cero, valwei se programará desde la dirección de ejecución.

Peligros potenciales: los contratos existentes se utilizarán independientemente del saldo real de su billetera, ya que ya es posible enviar ether a una dirección sin llamarla.

Significado: ahorrar gasolina.

ACTUALIZACIÓN: El 09.06.23, PAY se eliminó de la actualización debido a preocupaciones sobre los posibles efectos secundarios que podrían existir en la forma en que se transfiere ETH y el trabajo de razonamiento, prueba y seguridad requerido para aprobar la propuesta.

####EIP7069X

Introducción: instrucción CALL modificada

Cambio: se introdujeron tres nuevas instrucciones de llamada, CALL2, DELEGATECALL2 y STATICCALL2, que tienen el efecto de simplificar la semántica. Tiene como objetivo eliminar la observabilidad del gas de la nueva directiva y abrir la puerta a una nueva clase de contratos que no se ven afectados por la revisión de precios.

fondo:

Regla 63/64: limite la profundidad de la llamada y asegúrese de que la persona que llama tenga gas restante para realizar cambios de estado después de que la persona que llama regrese;

Antes de que se introdujeran las reglas 63/64, era necesario calcular con cierta precisión el gas disponible para la persona que llama. Solidity tiene una regla compleja que trata de estimar el costo en el lado de la persona que llama de ejecutar la llamada para establecer un valor de gas razonable.

La regla 63/64 se introduce actualmente:

Se eliminó la inspección de profundidad de llamada;

Asegúrese de reservar al menos 5000 de gas antes de ejecutar el comportamiento llamado;

Asegúrese de que haya al menos 2300 gas disponible para el comportamiento llamado.

Reglas de subsidio: como el conocido subsidio 2300, cuando un contrato llama a otro contrato, el contrato llamado obtendrá 2300gas para realizar operaciones muy limitadas (lo suficiente para hacer un pequeño cálculo y generar un registro, pero no lo suficiente para llenar un espacio de almacenamiento ), dado que establece una cantidad fija de gas, siempre que el precio del gas se pueda ajustar, las personas no tienen forma de determinar qué tipo de cálculo pueden soportar estos gases.

Importancia: Allane el camino para la introducción de EOF en el futuro y facilite la ejecución de grandes contratos.

Eliminar opcionalidad de gas: el nuevo comando no permite especificar el límite de gas, sino que se basa en la "regla 63/64" (principalmente en referencia a la retarificación del gas utilizada para una gran cantidad de operaciones de IO en EIP-150, lo que aumenta la consumo de gas de operaciones específicas) para limitar el gas, esta importante mejora es para simplificar las reglas sobre el "subsidio", sin importar si el valor se envía o no, la persona que llama no necesita realizar cálculos sobre el gas;

Con la introducción de la nueva propuesta, los usuarios siempre pueden superar el error Outof Gas enviando más gas en la transacción (sujeto al límite de gas del bloque, por supuesto).

Algunos contratos que solo enviaban una cantidad limitada de gas a sus llamadas fueron cancelados por el nuevo mecanismo de costos cuando anteriormente aumentaban los costos de almacenamiento (por ejemplo, EIP-1884 aumentó el gas para ciertos códigos de operación). Anteriormente, algunos contratos tenían un tope de gasolina que limitaba permanentemente la cantidad de gasolina que podían gastar, incluso si la enviaban a sus subllamadas, no funcionaría, sin importar cuánta gasolina extra enviaran, porque la llamada limitaría el monto enviado.

Allane el camino para la introducción de EOF: una vez que se introduce el formato de objeto EVM (EOF), las instrucciones de llamada antiguas pueden rechazarse en el contrato EOF, lo que garantiza que sean en gran medida inmunes a los cambios en el precio del gas. Dado que estas operaciones son necesarias para eliminar la observabilidad del gas, EOF las requerirá en lugar de las instrucciones existentes;

Más códigos de devolución de estado de conveniencia: se han introducido funciones de conveniencia que devuelven códigos de estado más detallados: éxito (0), reversión (1), falla (2) y se pueden expandir en el futuro.

####EIP2537：X

Breve: una precompilación de la manipulación de curvas BLS12-381.

CAMBIADO: Se agregaron operaciones en la curva BLS12-381 como compilaciones previas al conjunto necesario para realizar operaciones de manera eficiente, como la verificación de la firma BLS y realizar la verificación de SNARK.

Importancia: Ethereum puede crear pruebas criptográficas más seguras y permitir una mejor interoperabilidad con la cadena de balizas.

PR3175 fue mencionado, pero nunca preseleccionado, no hay más discusión

PR3175：X

Resumen: esta propuesta evitaría que los validadores sancionados propongan bloques cuando estén fuera de la cola. Si más del 50% de los validadores son penalizados por comportamiento malicioso, esos validadores aún podrán proponer bloqueos mientras se los elimina por la fuerza de la red. Cambiar esta lógica es un cambio de capa CL relativamente menor que brinda protección contra "modos de falla altos", dicen los desarrolladores.

Según la 108.ª reunión de consenso de desarrolladores de Ethereum Core del 4 de mayo, PR3175 está en proceso de formatearse como EIP y se cambiará a EIP-6987, es decir, por razones de seguridad, para evitar que se seleccionen nodos de verificación recortados. proponente del bloque.

futuro

En base a la información anterior, hemos llegado a las siguientes conclusiones:

1. Los objetivos principales de la mejora de Cancún son, en orden de prioridad, expansión, seguridad, ahorro de gas e interoperabilidad:

No hay duda de que la expansión es la primera prioridad (4844);

La seguridad y el ahorro de gas son la segunda prioridad (6780, 1153, 5656 y 7045), teniendo en cuenta una determinada experiencia del desarrollador;

El tercero es la interoperabilidad, como optimizar la conexión, comunicación e interoperabilidad entre dapps (4788, 7044 y 6988);

Datos esperados: Testnet 4844 puede reducir el costo de opsiderollup en un 50 %; las soluciones técnicas de EigenLayer y Celestia no han revelado demasiado y sus datos no pueden evaluarse; Ethstorage estima que el costo de DA bajará al 5 % del original Se espera que Topia reduzca el costo entre 100 y 1000 veces.

2. Los próximos 2 a 5 años cuando Cancún se actualice a Danksharding es el período dorado de desarrollo para los proyectos de capa DA

El límite superior de seguridad de la Capa 2 depende de la capa DA que adopte. Proto-Danksharding beneficiará a los protocolos de almacenamiento, los protocolos modulares y las redes de expansión de almacenamiento L1 a través del almacenamiento de datos de estado más económico.

Primero, Danksharding vuelve a la esencia de la máquina de estado de Ethereum. V God mencionó que el propósito del protocolo de consenso de Ethereum no es garantizar el almacenamiento permanente de todos los datos históricos. En cambio, la intención es proporcionar un tablón de anuncios en tiempo real altamente seguro y dejar espacio para otros protocolos descentralizados para el almacenamiento a largo plazo (el propósito del protocolo de consenso de Ethereum no es garantizar el almacenamiento de todos los datos históricos para siempre. Más bien, el propósito es proporcionar un tablón de anuncios en tiempo real altamente seguro y dejar espacio para que otros protocolos descentralizados realicen almacenamiento a largo plazo).

En segundo lugar, Danksharding reduce el costo de DA, pero también deben resolverse los problemas de tiempo de aterrizaje real y disponibilidad de datos.

Reducción de costos de DA: antes de esta actualización, era necesario llamar a calldata para liberar datos del resumen a la cadena principal de Ethereum, y la tarifa de gas para llamar a este código era muy costosa, lo que representaba el mayor gasto en la capa 2. EIP4844 introduce blobs de datos como resúmenes El espacio de datos adicional único reducirá en gran medida los costos de almacenamiento, lo que reduce los costos de DA.

El tiempo de aterrizaje real es largo, y el TPS que se puede mejorar y el gas que se puede reducir aún son limitados, por lo que es bueno para el desarrollo continuo de proyectos de capa DA en el futuro:

En el artículo sobre fragmentación de datos de iablesecurity de polynya sobre danksharding, se muestra que la implementación tardará de 2 a 5 años;

Incluso si aterriza, el TPS que puede aumentar y el nivel de gas que puede reducir aún son limitados:

EIP4844 actualmente admite 6 blobs, y el problema de expansión futura solo puede resolverse mediante Danksharding;

El espacio de bloque actual de Ethereum es de aproximadamente 200 KB. Después de Danksharding, el tamaño planificado en la especificación es de 32 megabytes, lo que representa una mejora de aproximadamente 100 veces. En la actualidad, el TPS de Ethereum es de aproximadamente 15, y en un estado idealizado, será de aproximadamente 1500 después de aumentarse 100 veces, lo que no es una gran mejora en magnitud.

Por lo tanto, un tiempo de implementación prolongado + cambios reales limitados beneficiarán a los proyectos de capa DA. Algunos proyectos DA como Celestia y Eigenda aún pueden competir con Danksharding a través de costos más baratos y TPS más rápidos. Los nuevos proyectos DA como ETHstoragetopia también pueden llenar el vacío de mercado anterior.

También deben abordarse cuestiones técnicas como el almacenamiento de datos y la disponibilidad de datos:

Hay dos costos principales de DA, uno es el costo del ancho de banda de la red, el otro es el costo del almacenamiento y 4844 en sí mismo no resuelve el problema del almacenamiento y el problema del ancho de banda de la cadena de bloques.

El blob se almacenará en la capa de consenso de Ethereum durante aproximadamente 3 semanas y luego se eliminará.Si desea almacenar registros históricos completos y hacer que todos los datos estén disponibles, las soluciones actuales incluyen: dapp en sí mismo almacena datos relacionados con él mismo y la red del portal Ethereum (actualmente en desarrollo) en desarrollo) o protocolos de terceros como exploradores de bloques, datos históricos en BitTorrent o almacenamiento espontáneo por parte de usuarios individuales.

Por lo tanto, Proto-Danksharding beneficiará a los protocolos de almacenamiento, los protocolos modulares y las redes de expansión de almacenamiento L1:

La demanda de datos históricos de llamadas conducirá a un nuevo canal de desarrollo para protocolos de almacenamiento descentralizados o protocolos de índice de terceros;

Los acuerdos modulares posteriores pueden ejecutar transacciones a través de un resumen de alta velocidad, la capa de liquidación segura es responsable de la liquidación y la capa de disponibilidad de datos de gran capacidad y bajo costo es responsable de la garantía;

Es bueno para la red de expansión de almacenamiento L1, como Ethstorage, que puede proporcionar una solución de segundo nivel para almacenamiento programable a un menor costo de almacenamiento.

3. La actualización de Cancún es buena para la diversidad L2, L3, RAAS y disponibilidad de datos y otras pistas

Análisis de pista L2:

Top Layer 2, se beneficiarán cinco proyectos como ArbitrumOrbit, OPStack, Polygon2.0, FractalScaling (bajo StarkWare) e HyperChain (bajo zkSync). La reducción de la tarifa de almacenamiento que trajo blob mejorará en gran medida la serie anterior de costos y problemas de escalabilidad que limitaban el desarrollo de la capa 2 y mejorará en gran medida el rendimiento de los datos. Después de resolver el problema de costos, la capa principal 2 tendrá la oportunidad de continuar implementando funciones, alto nivel Ecología L3 concurrente multicadena personalizada;

La brecha en los costos operativos entre la Capa 2 de segundo nivel y la Capa 2 principal se reducirá, lo que brindará a algunos proyectos pequeños más oportunidades de desarrollo, como Aztec, Metis, Boba, ZKspace, layer2.finance, etc.;

Aunque las necesidades reales de los proyectos de cadenas de bloques modulares aún deben verificarse, todavía son posibles diversos lenguajes de programación, como Cario de Starkware, lenguajes de la serie Move, lenguajes de la serie C, c ++, C # y Go compatibles con Wasm, que pueden introducir más Muchos web2 desarrolladores

Análisis de seguimiento de Raas:

La ventaja de Raas en sí radica en su alto grado de personalización, requisitos personalizados > puro costo y eficiencia, por lo que la reducción de costos es una gran ventaja del Rollup personalizado.

Pero el problema con la pista RAAS es que puede ser OverHype, e incluso hay dudas sobre la pista RAAS en sí. Frente a la competencia de los 5 mejores estratos2 y la aparición de varios nuevos DA, tenemos que poner un signo de interrogación sobre si los nuevos proyectos pueden formar una pista.

En primer lugar, la ventaja del despliegue de la cadena de aplicaciones head layer2 radica en la integridad del marco de la red y la seguridad de la ecología entre cadenas, y la ventaja de RAAS radica en su personalización y libertad;

Sin embargo, las barreras técnicas de RAAS de las series OP y ZK no son sólidas en la actualidad, y todavía se encuentran en la etapa de red de prueba a corto plazo, y no hay una interacción real del producto. Teniendo en cuenta el progreso real de RAAS, formas técnicas y las ventajas ecológicas de la capa 3 en el futuro, la demanda real de RAAS es dudosa.

Serie OP: aunque la actualización base +4844 de la pila OP ha traído algunas pequeñas mejoras en costo y eficiencia, el atractivo de las mejoras no es fuerte;

Serie ZK: en la actualidad, muchos proyectos líderes siguen la ruta ZKEVM y prestan más atención a la compatibilidad con Ethereum, por lo que el diseño del circuito sacrificará cierta eficiencia y no es tan específico como la serie OP. Sin embargo, la mayoría de los ZKRAAS actualmente en el mercado todavía usan proyectos líderes (como ZkSync) para bifurcar la cadena, y las barreras aún no son fuertes.

Por lo tanto, a corto plazo, OPRAAS todavía tiene espacio para el desarrollo antes de que llegue Layer 3. A largo plazo, ZKRAAS y Layer 3 pueden ser la tendencia futura.

ZKRAAS tiene una mayor desventaja de costos después de 4844 y consume mucha más potencia de cómputo que OP. Aunque el costo de cargar a L1 es menor que el de OP, esto es solo una gota en el océano en comparación con el costo del proceso de prueba. mientras OP La ventaja es que puede construir rápidamente una ecología en un corto período de tiempo, y todavía hay espacio para el desarrollo antes de que la capa 3 aterrice;

Para las aplicaciones DeFi convencionales y los mercados NFT, la transformación del rollup no es un requisito rígido. Solo las aplicaciones de pago o los juegos que requieren una alta eficiencia tienen una mayor demanda de rollup. En el futuro, los proyectos defi pueden estar en l2, los proyectos sociales pueden estar en l3 o fuera de la cadena y, finalmente, los datos centrales y las relaciones se colocan en l2. Los juegos en cadena son esencialmente Fondos, y la incapacidad de los tokens para circular externamente ha provocado cuellos de botella en el desarrollo, junto con la aparición de juegos en toda la cadena, el atractivo ecológico de l3 en sí es mucho mayor que el de rollup.

4. La actualización de Cancún mejora la experiencia del desarrollador y del usuario

La segunda propuesta importante de la actualización de Cancún, SELFDESTRUCTremoval, mejorará aún más la seguridad de Ethereum. Al mismo tiempo, para los problemas de actualización de la cuenta de procedimiento que puedan existir después de la eliminación, se planea introducir un nuevo código de operación SETCODE para mejorar esta situación. ;

La tercera propuesta EIP1153 actualizada por Cancún agrega códigos de operación de almacenamiento transitorio, que en primer lugar pueden ahorrar gasolina, en segundo lugar resolver el problema de la comunicación entre marcos y finalmente allanar el camino para el diseño de almacenamiento futuro, como Verkle Tree no tendrá que considerar el reembolso de cuestión de almacenamiento transitorio;

EIP5656, la cuarta propuesta de la actualización de Cancún, presenta la instrucción de copia de memoria MCOPY, que puede copiar con mayor precisión palabras y oraciones en código, lo que mejorará el rendimiento de copia de memoria en aproximadamente un 10 %;

La quinta propuesta de la actualización de Cancún es EIP4788, que puede hacer que la comunicación entre diferentes protocolos y aplicaciones en la red Ethereum sea más eficiente y segura, y también permite diseños más confiables para staking pools, puentes y protocolos de restake;

La última actualización de Cancún (15 y 23 de junio) propone agregar actualizaciones EIP centradas en CL: EIP6988, EIP7044 y EIP7045, que mejoran la seguridad y la usabilidad de Ethereum en detalles, como mejorar la experiencia del contribuyente y mejorar la seguridad de la red, etc.

Entre las propuestas eliminadas, la transición SSZ->RLP provocó la eliminación de dos SSZEIP (EIP6475 y EIP6493) de la actualización de Cancún; las propuestas relacionadas con EOF se eliminaron nuevamente de la actualización de Cancún después de eliminarse de la actualización de Shanghái, y actualmente se consideran posible Se implementa directamente en las actualizaciones diarias posteriores; EVMMAX también se elimina de Cancún para actualizaciones junto con EOF porque es un subconjunto de EIP relacionado con la implementación de EOF; considerando los posibles efectos secundarios que pueden existir en la forma de transferir ETH, y la necesidad de aprobar la propuesta El trabajo de razonamiento, prueba y seguridad, EIP5920 se elimina de la actualización.

5. Relación con zkml y abstracción de cuenta

Poco efecto en zkml

ZKML es la combinación de Zero Knowledge Proof (ZeroKnowledge) y Machine Learning (Machine Learning); la combinación de blockchain y el modelo ML resuelve los problemas de verificación y protección de la privacidad del aprendizaje automático:

Protección de la privacidad: la confidencialidad de los datos de entrada, como el uso de una gran cantidad de información personal como datos para alimentar máquinas para capacitación, la confidencialidad de la información personal es un requisito importante; o los parámetros del modelo, como la competitividad central del proyecto, también necesitan cifrarse para mantener las barreras a la competencia. Cuando existen problemas de confianza como estos, los modelos de ML no podrán obtener datos y aplicaciones a mayor escala.

Verificabilidad: la tecnología de prueba de conocimiento cero tiene una amplia gama de aplicaciones, y ZKP permite a los usuarios conocer la exactitud de la información sin verificación. Y debido a que el modelo de aprendizaje automático requiere muchos cálculos, el modelo ML puede generar pruebas a través de ZK-SNARK, lo que reduce el tamaño de la prueba y alivia la demanda de potencia informática de ML.

Los requisitos de almacenamiento de ZKML tienen poco que ver con DA: se requiere una estructura de almacenamiento separada como Space and Time, y su tecnología central es el nuevo protocolo de seguridad "SQL Proof". O conecte datos dentro y fuera de la cadena en un simple Formatee SQL y cargue los resultados directamente en contratos inteligentes;

ZK-SNARKs es la forma principal de ZK en ZKML, que puede adaptarse a los requisitos de potencia informática de ML en la cadena. Con el desarrollo de la criptografía, las pruebas SNARK especialmente recursivas beneficiarán la implementación de ZKML en la cadena:

Los ZK-SNARK se caracterizan por su alta compacidad. El uso de ZK-SNARK permite que el probador genere una prueba corta, y el verificador no necesita interactuar y solo necesita realizar una pequeña cantidad de cálculo para verificar su validez. Esto requiere solo un probador. La naturaleza de la interacción con los verificadores hace que ZK-SNARK sea eficiente y práctico en aplicaciones prácticas, y es más adecuado para los requisitos de potencia informática en cadena de ML.

Actualmente es imposible entrenar en la cadena, y solo los resultados de los cálculos fuera de la cadena se pueden almacenar en la cadena:

El problema actual de ML se debe más a los requisitos de potencia informática insatisfechos y al bajo rendimiento causado por las limitaciones del algoritmo (no se puede calcular en paralelo). Los ZK-SNARK solo admiten pequeñas pruebas de escala de conocimiento cero de ML y una pequeña cantidad de cálculo, es decir, la limitación de la potencia informática es un factor clave que afecta el desarrollo de aplicaciones de cadena de bloques ZKML, y la cadena solo puede almacenar los resultados de fuera -cálculos en cadena.

Buena abstracción de cuenta

En primer lugar, la actualización de Cancún puede reducir el costo de la prueba ZKrollup hasta cierto punto:

La tarifa de transacción actual de zkSync depende de 3 aspectos:

El costo de recursos fijos consumidos por el verificador para generar el certificado SNARK y verificarlo es relativamente alto;

La tarifa de gas cuando el verificador envía la prueba SNARK a la red principal de Ethereum, esta parte de la tarifa aumentará en consecuencia debido a la congestión de la red principal;

La tarifa de servicio pagada por el usuario al verificador, incluida la confirmación de la transacción, la transmisión del mensaje, etc.

Por lo tanto, si se introduce 4844, se aliviará el problema del aumento de las tarifas de gas causado por la congestión de la red principal, y el costo de las pruebas ZKP se puede reducir hasta cierto punto.La tendencia de desarrollo de la serie ZK no debe subestimarse.

En segundo lugar, la abstracción de cuentas transforma las transacciones tradicionales de tx en operaciones de usuario y luego empaqueta las operaciones de usuario en bloques con ECDSA, que ocupa más almacenamiento en la cadena que antes, por lo que los requisitos de almacenamiento son mayores;

Entonces, la abstracción de cuenta y ZKrollup pueden complementarse entre sí:

En la actualidad, el problema de la abstracción de cuentas es que GasFee es costoso. Debido a que hay demasiados pasos y contratos inteligentes involucrados, hay una gran cantidad de datos, lo que hace que GasFee sea costoso. La ventaja de ZKRollup es que puede reducir los datos;

La abstracción de cuentas dificulta garantizar la seguridad: Dado que AA involucra múltiples contratos, la seguridad es un problema. Sin embargo, después de que L2 se forme gradualmente en el futuro, la capa de consenso ya no se cambiará, los contratos inteligentes tendrán más usos y la seguridad de abstracción de cuenta también aumentará. Se puede garantizar, y con la verificación confiable de ZKrollup, la seguridad mejorará aún más.

Finalmente, considerando el auge de la tecnología de IA, puede ayudar a mejorar la seguridad de los contratos en cadena y optimizar las transacciones en cadena o los pasos de actividad:

IA y seguridad: la tecnología de IA se puede utilizar para mejorar la seguridad y la protección de la privacidad de las transacciones en cadena. Por ejemplo, la plataforma de seguridad Web3 SeQure utiliza IA para detectar y prevenir ataques maliciosos, fraudes y fugas de datos, y proporciona mecanismos de monitoreo y alarma en tiempo real para garantizar la seguridad y estabilidad de las transacciones en la cadena;

Optimización de la IA y las actividades en cadena: las actividades en la cadena de bloques incluyen transacciones, ejecución de contratos y almacenamiento de datos. A través de las capacidades inteligentes de análisis y predicción de la IA, las actividades en cadena se pueden optimizar mejor y mejorar la eficiencia y el rendimiento general. La IA puede ayudar a identificar patrones de transacciones, detectar actividades inusuales y brindar recomendaciones en tiempo real para optimizar la asignación de recursos para las redes de cadena de bloques a través del análisis de datos y la capacitación de modelos.

Por lo tanto, la actualización de Cancún beneficiará gradualmente el desarrollo futuro de la abstracción de cuentas desde la expansión del espacio de almacenamiento hasta la complementariedad con ZKrollup y luego la combinación con la tecnología de IA.

6. Mirando hacia atrás en la hoja de ruta de Ethereum, ¿qué sigue?

En la actualidad, Layer2 no tiene un rendimiento similar a Solana (en términos de latencia y rendimiento), ni tiene un rendimiento de fragmentación como Near, ni tiene un rendimiento de ejecución paralela como Sui y Aptos. La actualización de Cancún ha mejorado el liderazgo de Ethereum como líder;

Después de la actualización de Cancún, se estima que varios tiempos importantes de desarrollo serán totalmente danksharding (2~5 años), aterrizaje de MEV y PBS (1~3 años), abstracción de cuenta (1~2 años), ZK todo (3~ 6 años), EOF y experiencia de desarrollador (¿cuántas veces has visto la extensión?).

El azote

Objetivo: Centrarse en resolver problemas de MEV.

Solución: Minimice MEV en la capa de aplicación a través de "Separación de creador de propuestas (PBS)". En este momento, se pueden optimizar los blobs y se pueden introducir servicios de confirmación previa o protección de preferencia.

PBS es la separación de creadores y clasificadores de bloques. El clasificador solo es responsable de clasificar, independientemente de la cadena, y el creador del bloque no se preocupa por la transacción, y selecciona directamente el paquete hecho por el clasificador y lo coloca en la cadena. Este proceso hará que todo el proceso sea más justo y aliviará el problema de MEV, que es la idea de externalizar MEV.

El grado de finalización de PBS todavía es muy bajo en la actualidad, y el más maduro es la cooperación con soluciones MEV externas: mevboost de flashbots.

La versión avanzada de "Separación Proponente-Constructor Consagrada (ePBS)" tiene un menor grado de cumplimiento y un ciclo más largo, y se estima que no se implementará en el corto plazo. Además, existen versiones progresivas de PEPC y Retransmisión optimista, que mejora la flexibilidad y adaptabilidad del marco PBS

El borde

Objetivo: usar el árbol de Verkel para reemplazar a Merkle, introducir una solución de minimización de confianza, permitir que los nodos ligeros obtengan la misma seguridad que los nodos completos y hacer que la verificación de bloques sea lo más simple y portátil posible.

Al mismo tiempo, la ZKización de L1 se agrega claramente a la hoja de ruta de Verge.ZK será la tendencia general de expansión y aceleración futuras;

Solución: Introducir zk-SNARK para reemplazar el antiguo sistema de prueba, incluidos los clientes ligeros basados en SNARK; SNARK con cambios de estado de consenso; EnshrinedRollups.

Los árboles de Verkle son una alternativa más eficiente a los árboles de Merkle específicos del estado que no necesitan proporcionar una ruta desde cada nodo hermano (nodos que comparten el mismo padre) hasta el nodo elegido, sino solo la ruta como prueba. En parte, las pruebas de Verkle son 3 veces más eficientes que las pruebas de Merkle.

EnshrinedRollup se refiere a un Rollup que tiene algún tipo de integración de consenso en L1. La ventaja es que hereda el consenso de L1 y no necesita tokens de gobernanza para realizar actualizaciones de rollup. Al mismo tiempo, al realizar cálculos fuera de la cadena y solo publicar los resultados a la cadena de bloques, puede aumentar el número de transacciones, pero la dificultad técnica de implementación es relativamente grande. La combinación de estos paquetes acumulativos en el futuro podrá satisfacer la mayoría de las necesidades del ecosistema blockchain en las próximas décadas.

La purga

ThePurge se refiere al objetivo de simplificar el protocolo al reducir los requisitos de almacenamiento para participar en la validación de la red. Esto se logra principalmente a través de la hibernación y la gestión de la historia y el estado. La latencia de datos históricos (EIP-4444) permite a los clientes eliminar los datos históricos anteriores a un año y dejar de brindar servicios a nivel P2P.

estado latente. Cuando se trata de manejar el crecimiento del estado, hay dos objetivos principales: la apatridia débil, que se refiere al objetivo de usar el estado solo para construir bloques pero no verificarlo; El estado al que se accede. La hibernación de estado debería reducir la necesidad de almacenamiento de los nodos de estado en un total de 20 a 50 GB.

En la quinta etapa de Purga, EIP4444 se escribe explícitamente en la hoja de ruta. EIP-4444 requiere que el cliente borre los datos anteriores a un año. Al mismo tiempo, hay algunas tareas de optimización de EVM en esta etapa, como simplificar el mecanismo de precompilación de GAS y EVM, etc.;

El Derroche

En la sexta etapa final de Splurge, también se mencionó EIP 4337. Como una propuesta de diseño a largo plazo para la ecología de la billetera, la abstracción de cuentas mejorará aún más la facilidad de uso de las billeteras en el futuro, incluido el uso de monedas estables para pagar la gasolina y las billeteras de recuperación social. , etc.;