Más
Guía para principiantes
Gate Post
Trasmisión en vivo
Chat
Eventos futuros
Noticias
Blog de Gate
Inicio
Recomendar
Destacados
Visión
Publicar

Pasado, presente y futuro de las mejoras en Cancún

金色财经_vip

Vida pasada

**¿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, el TPS y el rendimiento son bajos, la tarifa del gas es alta y la congestión es grave. Al mismo tiempo, el espacio en disco necesario para ejecutar un cliente Ethereum también está creciendo rápidamente. En el fondo, el trabajo de garantizar el seguridad y descentralización de Ethereum El impacto del algoritmo de consenso de volumen en todo el entorno también se está volviendo cada vez más significativo.
  • 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 permite a Ethereum crear múltiples bloques al mismo tiempo y mejorar su escalabilidad.
  • El espacio actual 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 aproximadamente 100. Estos datos obviamente no pueden satisfacer las necesidades de Ethereum.
  • Por lo tanto, Ethereum Layer 2 se enfoca en cómo poner una gran cantidad de datos en el bloque En el espacio, la seguridad está garantizada a través de pruebas de fraude y pruebas de validez, por lo que la capa DA determina el límite superior de seguridad, que también es el contenido central de la 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. En el corto plazo, Ethereum solo puede construir una estructura de múltiples capas con Rollup como núcleo, por lo que Cancún se actualiza para resolver TPS, gas Las tarifas y la experiencia del desarrollador son fundamentales para la hoja de ruta de Ethereum.

**¿Cómo está planificada la hoja de ruta de Ethereum? **

Las últimas actualizaciones importantes y sus objetivos

  • 2020año12mes1* Se lanza oficialmente Beacon Chain, allanando el camino para la actualización de POS*
  • 2021**8meses5** Actualización de Londres, EIP1559 cambia el modelo económico de Ethereum;
  • 2022año9mes15* Mejora de París (El Merge), completó POW cambiando POS;*
  • 2023año4mes12* Actualizado en Shanghai, resolvió el problema de retiro de compromiso;*
  • 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 la experiencia del desarrollador;
  • El siguiente paso es centrarse en la hoja de ruta de Ethereum El Aumento .
  • Objetivo: Consigue más de 100 000 TPS en Rollup.
  • Hay 2 esquemas, 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 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, pero también puede requerir una gran cantidad de parches para compensar varios problemas que puedan 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 Producción centralizada de bloques + Verificación descentralizada + **Resistencia a la censura,**Esto también está relacionado con la disponibilidad de datos mencionada a continuación Muestreo (DAS), Separación Productor-Envasador de Bloques (PBS) y Lista de Resistencia a la Censura (Crlist). La mayor importancia de la idea central de Danksharding radica en convertir Ethereum L1 en un acuerdo unificado (liquidación) y disponibilidad de datos (Disponibilidad de datos) Disponibilidad）层。

El esquema de fragmentación se divide en 2 pasos, actualmente se divide en Proto- **** fragmentación y **** resumen completo******. ***

  • Por lo tanto- Húmedo*：**
  • introducir: Ayude a reducir la tarifa L2 y aumente el rendimiento mediante la introducción de blobs , al mismo tiempo que una solución previa a la fragmentación para allanar el camino hacia la fragmentación completa. Se espera que después de proto-danksharding, la implementación de danksharing tome de 2 a 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 en gran medida alivia la carga en la cadena principal.La presión de almacenamiento también puede reducir el costo de acumulación.
  • Completamente resumido
  • Introducción: el resumen está completamente expandido y se centra en la utilización de la disponibilidad de datos.
  • contenido:
  • Diseño P2P de DAS: algunos trabajos e investigaciones relacionados con problemas de conexión de 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 a largo plazo 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 el actualice o no, y después de la prueba final, revíselo nuevamente y luego decida si incluirlo en la actualización real según la discusión.
  • Las conferencias se dividen en 2 categorías, que son 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:
  • ** Reunión de la capa de consenso (Todos Core Developers Consensus - ACDC), centrándose en la capa de consenso de Ethereum (prueba de participación, cadena de balizas, etc.);**
  • Reunión de nivel ejecutivo ( Todas Solución Core Developers - ACDE**), que se enfoca en la capa de ejecución de Ethereum (EVM, **Gas horario, etc.).
  • Hay 3 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;
  • Etéreo Magos: Un "foro" que quiere discusiones sobre EIP y otros temas técnicos.

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

*Según el contenido de la discusión, esta actualización de Cancún se puede dividir aproximadamente en 5 etapas. ***

Fase 1 - Presentación de temas de actualización

Introduce nuevas tareasproto-danksharding***,EOF y "autodestrucción" * Opcode, discusión superficial sobre el contenido de la actualización de Shanghái*

  • 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 son preliminares. En mi opinión, 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 EIP. 4844, pero otro grupo de desarrolladores cree que tiene más sentido 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 finales de 2022**, la conferencia de Ethereum girará principalmente en torno a ***EOF y EIP 4844 Discusión, sin dejar de promover EIP 4844 La ceremonia de configuración pre-creíble requerida para la ceremonia ***—KZG, los desarrolladores estarán el *******23 **** Año **** 1 **** mes confirmado oficialmente qué actualización **** 4844 **** aparecerá en ***

  • 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 la capa de consenso del 22 de diciembre, Trent, el jefe del ecosistema Ethereum Van Epps actualizó el EIP 4844 Progreso en la implementación de la ceremonia de instalación confiable requerida para generar un Código de seguridad utilizado en 4844. camioneta Epps espera que la ceremonia sea una de las más grandes en el espacio criptográfico, recaudando entre 8000 y 10 000 contribuciones, y el período de contribución pública para 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. Un desarrollador de la Fundación Ethereum se opuso a posponer EOF a Cancún, argumentando que si los cambios de código no se incluían en Shanghái, La posibilidad de entrar a Cancún es muy pequeña, respecto al código de autodestrucción, hay desarrolladores que abogan por adelantar el EIP en su momento 4758, pero deshabilitar este código de operación directamente romperá algunas aplicaciones, y el desarrollador cree que este EIP debe sopesarse nuevamente por un tiempo antes de crear un caso extremo para proteger este tipo de contrato;
  • En la reunión de desarrolladores del núcleo del 9 de diciembre de 22, se promovió la implementación de la ceremonia KZG con respecto a la actualización de Cancún y el EIP actual 4844 La ceremonia de instalación de confianza requerida está lista;
  • En la reunión de la capa de consenso el 16 de diciembre de 22, sobre EIP 4844, 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 la disponibilidad de datos más allá de cierto punto después de la poda de datos, y otra cuando un bloque Se introducirán nuevos códigos de error para alertar nodos cuando falta información sobre blobs en
  • Durante la reunión de desarrollo central el 5 de enero de 23, los desarrolladores llegaron a un consenso para eliminar las modificaciones de código relacionadas con la implementación de EOF de la actualización de Shanghái, Beiko en este momento sugirió decidir después de dos semanas si EOF debería incluirse en la actualización de Cancún;

Fase III - Discusión preliminar del alcance de la propuesta

Al final del 231EOF se mudó a Cancún para la promoción después de ser trasladado de la promoción de Shanghái, desde entonces 2 meses giran principalmente en torno a excepto EOF y EIP Se discutieron otras propuestas además de 4844* y, al mismo tiempo, se propuso que ***EOF se mudara 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, la propuesta preliminar para la actualización de Cancún fue: EIP 4788 (raíz del estado de la cadena de balizas públicas), EIP 2537 (realice operaciones de manera eficiente, como la verificación de firma BLS y la verificación de SNARK), EIP-5920 (introduce el nuevo código de operación PAY) y EIP Una implementación combinada de 6189 (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 el 16 y 23 de marzo, excepto EOF y EIP 4844, se consideraron las siguientes propuestas para su inclusión en Cancún: formato SSZ, eliminación SELFDESTRUCT, EIP 2537, EVMMAX, EIP
  1. Instrucciones SWAP y DUP ilimitadas, introduciendo códigos PAY y raíces de estado de baliza en el 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 es también la propuesta de deshabilitar SELFDESTRUCT que Cancún finalmente decidió usar. Pero con respecto a la implementación de EOF, de Erigon (EL) Un desarrollador del equipo del cliente dijo EOF 'Demasiados cambios' para competir con la propuesta de mejora de Ethereum EIP en la próxima actualización de Cancún 4844, hubo una propuesta para implementar EOF en la bifurcación dura poco después de la actualización de Cancún;

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

En 234meses, hay una dirección clara para las propuestas que deberían ser cubiertas por la actualización de Cancún, y los nodos clave están en 4 ************************************************ **************************************************** *********** EIP y tim también tuvieron un debate más profundo sobre las propuestas alternativas, en 4mes En la reunión del 27,EIP 6780、EIP 6475 yEIP 1153** se determina que se incluye en Cancún, y al mismo tiempo *EOF y EVMMAX (con * ***EOF **subconjunto EIP relacionado con la implementación) se eliminó de la actualización de Cancún, la actualización EOF ayuda principalmente EVM realiza el control de versiones y puede ejecutar múltiples conjuntos de reglas de contrato al mismo tiempo, lo que ayudará a la expansión posterior de Ethereum, pero considerando la viabilidad de la actualización completa, ** * EOFLa actualización puede continuar con la actualización diaria

  • 23****4mes12****, se completó la actualización de Ethereum Shanghái;
  • Durante la reunión de desarrollo central el 13.04.23, los desarrolladores discutieron el EIP 4844 (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, a saber, EIP 4844**, AUTODESTRUCCIÓN ELIMINADO (EIP-6780, EIP 4758, EIP 6046, EIP 6190）、EIP 5920、EIP 1153、EIP 2537、EIP 4788、EVMMAX EIP（EIP 6601 y EIP 6690), SS cambios（EIP 6475, EIP 6493, EIP 6465, EIP 6404 y EIP 6466 ）、EIP 5656 y **EIP 6193;
  • 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, con la adición de los siguientes EIP: EIP 6780 (cambia la funcionalidad del código de operación SELFDESTRUCT), EIP 6475 (un nuevo tipo de serialización simple (SSZ) para representar valores opcionales), EIP 1153 (agregue un nuevo código de operación para operar el estado); en segundo lugar, el EIP que se está considerando pero que no se incluye oficialmente en la actualización es EIP 6913 (introducción de la instrucción SETCODE), EIP 6493 (Definir un esquema de firma para transacciones codificadas en SSZ), EIP 4788 (Exponer la raíz del bloque de la cadena de balizas en el encabezado del bloque EL), EIP 2537 (agrega la curva BLS12-381 como precompilación) y EIP 5656 (introduce nuevas instrucciones EVM para copiar regiones de memoria); finalmente, EOF ** y ** EVMMAX** (** EOF ** depende de la implementación ** * EIP* subconjunto) se eliminó de la actualización de Cancún. **EOF La actualización se trasladó fuera de Shanghái en la Conferencia de Desarrolladores de Ethereum a principios de ****2023****1****, y posteriormente se actualizó de * *** Desde el final del 1 hasta el comienzo del 4 en 23****, aparecerá en la actualización de Cancún por defecto, pero en ** 23** **EOF **se eliminó nuevamente en la reunión de desarrolladores el 29, 4. **

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

235mes principalmente agiliza y mejora los detalles de la propuesta final,SSZ-> Los cambios del RLP significarán que las dosSSZ en Cancún ya no son necesarias EIP**, así queEIP 6475 y 6493 se trasladarán fuera de Cancún para realizar mejoras. Al mismo tiempo, en la reunión central del día 26, Tim Beiko recomienda que las conversaciones futuras sobre la expansión del alcance de Cancún se limiten a los siguientes cincoEIP:*EIP-5920 * ,5656,7069,4788 y ****2530 * ****. Los desarrolladores ahora han determinado el alcance total de la actualización de Cancún. ***

*Reunión de consenso de Ethereum Core el 5/5/23, discutiendo el último EIP mencionado 4788, al agregar el EIP 6987 y EIP Discusión en 6475, estas dos propuestas son sobre verificadores y transacciones SSZ respectivamente;

  • En la reunión 161 de la capa ejecutiva de Ethereum el 11 y 23 de mayo, Tim Beiko dijo que el alcance de la actualización de Cancún aún puede modificarse en las próximas semanas, pero sin un consejo explícito de los desarrolladores, el alcance de la actualización de Cancún permanecerá en el estado "predeterminado", y la discusión sobre EIP-4844 muestra que el desarrollo El autor acordó eliminar SSZ de la implementación EL de EIP-4844, **pero aún no ha afectado el progreso continuo de ** 6475 **. **Además de esto, los desarrolladores también discutieron brevemente dos EIP para su consideración en Cancún, a saber, EIP 6969（EIP
  1. y EIP 5656 (instrucciones EVM eficientes para copiar regiones de memoria);
  • Los desarrollos en 4844 se discutieron brevemente en la reunión de Consenso de Desarrolladores el 18 de mayo de 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 finales de Cancún se discutieron en la reunión 162 de Ethereum Core el 25 de mayo de 2023. Tim Beiko recomienda 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**. Los desarrolladores confirmarán en las próximas semanas ** Dencun** (****Deneb
  • toda la gama de Cancún****);**
  • 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. EIP La especificación 4844 aumentó de un máximo de 4 blobs a 6 por bloque. Al mismo tiempo, los desarrolladores están considerando el EIP 4788 incluido 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, incluido EIP 4844、EIP 1153、EIP 5656、EIP 6780、EIP 4788;
  • 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 estuvo de acuerdo. a lo siguiente Una red de prueba EIP-4844 Devnet6 probará el mayor número de blobs y tomará una decisión final al respecto dentro de dos semanas, mientras que el investigador de la Fundación Ethereum, Michael Neuder propuso eliminar el límite de participación de 32 ETH 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 el BLS a otra dirección, aunque la precompilada vía EIP 2537, pero no será considerado en Cancún;
  • En la reunión de consenso del 29 de junio de 2023, los desarrolladores continuaron discutiendo la cantidad de blobs, limitando el blob de destino Aumentó de 2 a 3, aumentó el límite máximo de blobs de 4 a 6 y 4844 prueba la red Devnet #7 llegará pronto.

esta vida

  • El contenido principal es EIP 4844，即 Proto-Danksharding
  • El rango final de EIP para esta actualización de Cancún es: EIP 4844**、EIP 1153、EIP 5656、EIP 6780、EIP 4788. Mientras tanto, en la reunión 111 de Ethereum ACDC el 19 de junio, los desarrolladores continuaron discutiendo EIP 6988、** EIP 7044**、**EIP 7045 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 ClaveEIP

EIP 4844

  • Introducción:
  • El nombre de la propuesta EIP4844 es Proto-Danksharding, que es el preprotocolo de la versión completa de la expansión de sharding Danksharding.Todo el conjunto de esquemas de sharding se basa en realidad en Rollup para la expansión en cadena. **El propósito del programa es expandir la ** 2 capa **Resumen——****Ayudando a L2 a reducir las tarifas y aumentar el rendimiento , mientras allana el camino para la fragmentación completa (fragmentación). **
  • En la conferencia telefónica del 23 de febrero, los desarrolladores de Ethereum EIP La actualización 4844 se llama Deneb, que es el nombre de una estrella de primera magnitud en la constelación Cygnus, que es el EIP en la versión relevante de GitHub en el futuro. El nombre de 4844 se actualizará a Deneb, en la reunión del 1 de junio 23, habrá algunos cambios en la especificación de la próxima 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 se prepararon para actualizar el EIP La dirección precompilada de 4844. Actualmente, los desarrolladores principales han agregado 9 precompilaciones al EVM y activarán el EIP al 4844 y 4788 crean dos precompilaciones bajo las direcciones "0xA" y "0xB" respectivamente. En la reunión de consenso del 29 de junio, EIP está listo para ser lanzado Red dedicada de prueba a corto plazo de 4844 Devnet #7。
  • EIP-4844** introduce un nuevo tipo de transacción: Blob Transacción。** *Perfil de la mancha:
  • Blob, similar a un paquete de datos de complemento, solo 128 al principio El espacio de almacenamiento de KB, al comienzo de la discusión de la propuesta, el objetivo y límite de Blob era 2/4, y se ajustó a 3/6 en la reunión de desarrolladores del 9 de junio de 23. Es decir, actualmente cada transacción en Ethereum puede llevar hasta tres transacciones Blob, es decir, 384 KB, el objetivo de cada bloque La capacidad de blobs es 6, es decir 768 KB, que puede transportar hasta 16 blobs, que son 2 MB;
  • Puede tener un cierto impacto en la estabilidad de la red, pero el equipo de desarrollo de Ethereum aún decidió probar primero para evitar la necesidad de bifurcaciones posteriores para expandir el bloque de blobs.
  • Mancha **en ** KZG commit Hash Como ** Hash, utilizado para la verificación de datos, la función es similar a ** Merkle ;
  • El nodo sincroniza el Blob en la cadena Después de la Transacción, la parte del blob caducará y se eliminará después de un período de tiempo, y el tiempo de almacenamiento es de tres semanas.
  • Función Blob - mejora el TPS de Ethereum, mientras reduce 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, superando directamente el propio libro mayor varias veces;
  • Para los nodos, la descarga de 1 MB a 2 MB adicionales 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á el descentralización de todo el nodo Ethereum, pero la expansión en torno a Rollup ha mejorado mucho;
  • De hecho, 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** - para abrir el primer capítulo de la narrativa Danksharding**
  • **Expansión de alta capacidad: **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, lo que garantiza la descentralización y la seguridad. lograr una mayor expansión;
  • ** Tarifas bajas: ** Los analistas de Bernstein muestran que 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, que puede reducir el costo de implementación en un 50 % según las observaciones actuales;
  • 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 el costo 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.
  • **DA****Solución: Danksharding (una solución fragmentada para la expansión de Ethereum) actualmente, si la expansión continúa, la carga del nodo puede ser demasiado grande (****16mb **** arriba) y disponibilidad de datos insuficiente (30 días de validez). Solución: **
  • Muestreo de disponibilidad de datos (Datos Muestreo de disponibilidad): reduce la carga en los nodos
  • Cortar los datos en Blob en fragmentos de datos y dejar que el nodo cambie 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 son almacenado en todo el libro mayor de Ethereum, la premisa es que los nodos deben ser suficientes y descentralizados;
  • DAS utiliza dos tecnologías: código de borrado (Erasure Codificación) y Compromiso polinomial KZG (KZG Compromiso);
  • Separación de proponente-empaquetador (PBS): resolvió el problema de la división del trabajo de los nodos, deje que los nodos con configuración de alto rendimiento sean responsables de descargar todos los datos para codificar la distribución y deje que los nodos con configuración de bajo rendimiento sean responsables de verificación de verificación al azar.
  • Un nodo con una configuración de alto rendimiento puede convertirse en un constructor. El constructor solo necesita descargar los datos del blob para codificar y crear un bloque (Bloque), y luego transmitirlo a otros nodos para verificaciones puntuales. Para los constructores, debido al volumen de datos de sincronización y los requisitos de ancho de banda son altos, por lo que estará relativamente centralizado;
  • Un nodo con configuración de bajo rendimiento puede convertirse en proponente (Proponente), y el proponente solo necesita verificar la validez de los datos y crear y transmitir el encabezado del bloque (Bloque Encabezado), pero para el proponente (Proponente), el volumen de datos de sincronización y los requisitos de ancho de banda son bajos, por lo que será descentralizado.
  • Lista anticensura (crList): resuelve el problema de que los empaquetadores pueden ignorar deliberadamente ciertas transacciones y ordenar e insertar aleatoriamente las transacciones que desean obtener MEV debido a su excesivo poder de revisión.
  • Antes de que el constructor (Constructor) empaquete las transacciones en bloque, el proponente (Proponente) primero publicará una lista resistente a revisión (crList), que contiene todas las transacciones en el mempool;
  • El constructor (Builder) 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 Gas el límite 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 el encabezado del bloque (Bloque Encabezado) y difusión;
  • Cuando el nodo sincroniza los datos, obtendrá el encabezado del bloque del proponente (Proponente) y luego obtendrá el cuerpo del bloque del empaquetador (constructor), 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 centralizan cada vez más al adquirir MEV
  • Utilice el modo de subasta 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 aprueba el bloque, se producirá el bloque, y si el empaquetador deliberadamente no le da Cuerpo al bloque, se considerará que el bloque no existe).
  • 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, entonces necesita pagar una gran cantidad de costos de licitación al principio para asegurarse de que puede obtener la calificación de la cabeza del bloque, luego la ganancia de MEV que obtiene se reducirá aún más y, en general, tendrá un impacto en los medios y el valor real. de obtención de MEV;
  • Sin embargo, en la etapa inicial, solo una pequeña cantidad de personas pueden convertirse en empacadores (considerando los problemas de rendimiento del nodo), mientras que la mayoría de las personas solo se convierten en proponentes, lo que puede conducir a una mayor centralización. Al mismo tiempo, la cantidad de empacadores es muy pequeña. En el caso de , es más probable que algunos mineros experimentados con capacidades MEV presenten una oferta exitosa, lo que afectará más el efecto real de la solución MEV;
  • Tiene cierto impacto en algunas soluciones MEV que utilizan subastas MEV.
  • Significado:
  • EIP 4844 En realidad, una versión súper simplificada Danksharding**: **Proporciona la misma interfaz de aplicación que Danksharding, incluido un nuevo código de operación llamado Data Hash y un nuevo objeto de datos llamado Binary Objetos Grandes, es decir, Blob;
  • proto-danksharding ** se usa para implementar el ** Danksharding ** especificación completa "soporte"** (** es el formato de transacción y las reglas de verificación****) * * Propuesta: Sin embargo, aún no se ha implementado la fragmentación y todos los verificadores y usuarios aún deben verificar directamente la disponibilidad de los datos completos;
  • Por qué la perspectiva a largo plazo elige proto-danksharding no EIP 4488 ** reduce directamente la tarifa de ** layer2 , porque solo se requiere un pequeño ajuste cuando se actualiza a un fragmento completo en el futuro:
  • PIE La principal diferencia práctica entre 4488 y proto-danksharding es que EIP-4488 intenta minimizar los cambios que Ethereum necesita hacer hoy, mientras que proto-danksharding hace más cambios en Ethereum hoy para actualizar a Ethereum en el futuro. necesario para la fragmentación de la versión completa;
  • Aunque es una tarea muy compleja lograr la fragmentación completa (con muestreo de disponibilidad de datos, etc.), y aún queda mucho trabajo por hacer después de implementar la fragmentación proto-danksharding, estas complejidades se controlarán en la capa de consenso. Una vez que se implementa proto-danksharding, el equipo del cliente de la capa de ejecución, los desarrolladores de resumen y los usuarios no necesitan hacer ningún trabajo adicional para 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 de delegación y muestreo de disponibilidad de datos, pero dichas modificaciones se concentrarán en ** CL * * capa, los desarrolladores no necesitan reajustar **: 4844 actualmente implementa un nuevo tipo de transacción, que es exactamente el mismo que el formato de transacción, la lógica de validación cruzada de consenso y la lógica de capa de ejecución requerida en el fragmento completo, y también derivado para blobs, precios de gas independientes autoajustables, para lograr una fragmentación completa en el futuro, es necesario completar la implementación real de PBS, prueba de delegación y muestreo de disponibilidad de datos, pero estas modificaciones son solo en la capa CL, y no requieren que los desarrolladores de capa o acumulación de EL modifiquen, lo cual es conveniente para el desarrollo Por.

seguido de*** AUTODESTRUCCIÓN eliminación******,EIP-6780 finalmente se determinó que era la solución más adecuada, pero el desarrollador en 26** En el reunión tim** propuso agregar otro código de operación a esta propuestaSETCODE para permitir que las cuentas programáticas aún se actualicen***

AUTO DESTRUCCIÓN eliminació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 los códigos de contrato. y puede usarse sin el consentimiento de la cuenta puede modificar el código de operación del saldo de la cuenta, lo que tiene grandes peligros ocultos en 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 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 AUTODESTRUCCIÓN para participar en la discusión, a saber, 6780, 4758, 6046 y 6190, y el EIP posterior. 6780 se fijó como 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.
  • PIE 6780: 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í está la absorción de EIP Las ventajas de 4758, que pueden dar espacio a dapp para actualizar.

  • 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 plantea una dificultad para usar árboles de Verkle en el futuro: cada cuenta se almacenará en muchas claves de cuenta diferentes que no estarán vinculadas explícitamente a la cuenta raíz.
  • CAMBIADO: este EIP implementa cambios para eliminar SELFDESTRUCT, excepto en los siguientes dos casos
  • Las aplicaciones que solo se usan para AUTODESTRUCCIÓN para retirar fondos seguirán funcionando;
  • SELFDESTRUCT utilizado en la misma transacción en el contrato no necesita ser cambiado.
  • Importancia: Mayor 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;
  • Evite que los usuarios continúen depositando fondos y comerciando en una bóveda después de la AUTODESTRUCCIÓN, entonces esta bóveda puede hacer que cualquiera robe tokens en la bóveda durante el uso repetido.

Las tres propuestas a continuación son las propuestas sobre AUTODESTRUCCIÓN que se eliminaron posteriormente, en 23año****4 *** 6780 fue seleccionado oficialmente en la reunión de desarrolladores principales el **28, y las otras tres propuestas fueron abandonadas. es que el equipo de desarrollo de Ethereum finalmente quiere eliminar por completo el código de operación SELFDESTRUCT, y las siguientes tres propuestas se modifican en su mayoría por reemplazo. ***

  • EIP-4758 (DEPRECADO): 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 del código SELFDESTRUCT requería cambios extensos en el estado de la cuenta, como eliminar todos los códigos y el almacenamiento. Esto plantea una dificultad para usar árboles de Verkle en el futuro: cada cuenta se almacenará en muchas claves de cuenta diferentes que no estarán vinculadas 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, este esquema ya no destruye el código y el almacenamiento, ni cambia números aleatorios;
  • Todos los reembolsos relacionados con SELFDESTRUCT han sido eliminados
  • Significado:
  • Se conservó la funcionalidad original en comparación con EIP-6780, porque algunas aplicaciones todavía/necesitan usar el código SELFDESTRUCT.
  • EIP-6046 (DEPRECADO): 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 recorrer 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:
  • Cambiar las reglas introducidas por EIP-2681 para que el aumento regular de nonce esté limitado 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;
  • Transferir el saldo de la cuenta al destino **, **establecer 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 otras supresión directa de AUTODESTRUCT.
  • EIP-6190 (DEPRECATED): SELFDESTRUCT modificado, compatible con Verkle, para que solo provoque un número limitado de cambios de estado
  • Motivo: igual que el anterior, con un árbol Verkle, las cuentas se organizarán de manera diferente: las propiedades de la cuenta (incluido el almacenamiento) tendrán claves separadas, pero será imposible recorrer 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.
  • CAMBIADO: En lugar de destruir el contrato al final de una 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.
  • La ranura de almacenamiento 0 del contrato se establece en el contrato mediante el código de operación CREAR ( keccak256(dirección del contrato, nonce)) se emitirá cuando la dirección. 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;
  • El saldo del contrato se transferirá en su totalidad 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;
  • Costo de gas aumentado con EIP-2929 aplicado.

Seguido porEIP 1153***, al mismo tiempo que ahorragasolina, allanando el camino para el futuro diseño de almacenamiento***

EIP 1153X

  • 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 mediante instrucciones CALL y mediante 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.
  • con reentrada lock como ejemplo, no puede depender de marcos intermedios para comunicar el estado del bloqueo: la comunicación SSTORE a través del almacenamiento SLOAD 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, TLOAD (0xb3) y TSTORE (0xb4), al EVM.
  • El almacenamiento transitorio es privado para el contrato que lo posee, al igual que el almacenamiento persistente, solo el marco del contrato propietario puede acceder a su almacenamiento temporal. 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:
  • reentrada cerrar con llave;
  • 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(dirección gastador, cantidad uint256);
  • 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 acciones 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 gasolina**, con reglas de facturación más sencillas** gasolina ;
  • ** Resolver el problema de la comunicación entre cuadros; **
  • ** No cambiar la semántica de las operaciones existentes; **
  • No es necesario limpiar el tanque de almacenamiento después de su uso;
  • ** Los futuros diseños de almacenamiento (como ** Verkle ** árboles) no necesitan considerar reembolsos por almacenamiento instantáneo. **

Seguido de 4788, puede reducir la suposición de confianza en el fondo de compromiso**

EIP 4788*：**X

  • Introducción: Beacon block root en EVM. *Actualización: en la reunión de desarrolladores del 15 y 23 de junio, los desarrolladores propusieron realizar cambios en el código para mejorar la experiencia del staker, este EIP divulgará la raíz del bloque de la cadena de balizas, que contiene información del estado de la cadena interna de EVM, para el desarrollo de DApp. la confianza del autor minimiza el acceso.
  • CAMBIADO: confirme las raíces hash de cada bloque de cadena de balizas en el encabezado de carga útil de ejecución correspondiente, almacene esas 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 exponer el estado de la capa de contrato (CL) Los datos raíz en la capa de ejecución (EL) pueden hacer que la comunicación entre diferentes protocolos y aplicaciones en la red Ethereum sea más eficiente y segura**. **Permita diseños más confiables para agrupaciones de replanteo, puentes y protocolos de replanteo.

El último es5656***, 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 la actualización debido a su ancho de banda de prueba** *

EIP 5656X

  • Introducción: MCOPY
  • Instrucción de copia de memoria. Actualización: 09.06.23, el equipo de desarrollo declaró que inicialmente estaban divididos en MCOPY porque, si bien resolvía el problema de seguridad, todavía estaban preocupados por agregarlo al ancho de banda de implementación + prueba requerido para la actualización, pero finalmente acordaron incluir el EIP, pero se considerará su eliminación si el desarrollador encuentra problemas de capacidad en las pruebas o en el lado del cliente. Por lo tanto, 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 básica, 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 aumentará el rendimiento de la copia de memoria en aproximadamente un 10,5 %, lo cual es muy útil para diversas operaciones de cálculo intensivo;
  • También será ú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 precompilados de identidad, pero en realidad no puede promover la implementación de esta parte.

Preselección****EIP

El 236mes15***, la reunión de consenso de desarrolladores discutida en *** ¿Qué EIP** centrados en CL están incluidos en Deneb, donde **** ** EIP 6988******、EIP 7044、******EIP 7045 *** *** se propone unirse. ***

EIP 6988*：**X

  • Breve: Evitar que los validadores reducidos sean elegidos como proponentes de bloque.
  • Importancia: el aumento de las sanciones por violar los nodos beneficiará a la TVP.

EIP 7044*：***X

  • Resumen: Garantizar que las salidas del validador firmadas sean permanentemente válidas.
  • Importancia: puede mejorar la experiencia de los participantes hasta cierto punto.

EIP 7045*：***X

  • Introducción: atestación de testamento El rango de inclusión de ranuras se extiende desde una ventana móvil de una época hasta dos épocas.
  • Importancia: Mejorar la seguridad de la red.

Eliminar análisis de EIP

El **** día de 29**************************** ********************************************** En ** 160****ACDE reunión de Ethereum, EVMMAX y EOF Se confirma que **** se eliminó de esta actualización, es posible que se introduzcan cambios relacionados con EOF en actualizaciones diarias posteriores

EVMMAX EIP**：**

  • 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.
  • PIE 6601: Extensiones aritméticas modulares EVM (EVMMAX)
  • Cambio: es EIP 5843 iteraciones, con EIP La diferencia de 5843 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 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, EIP-6601 realiza más actualizaciones sobre esta base, mediante la introducción de una sección de configuración, un espacio de memoria separado y nuevos códigos de operación, para que las operaciones aritméticas modulares proporcionen una mejor organización y flexibilidad al tiempo que admite un módulo más grande y mejora el rendimiento de EVM.
  • Como contrato EVM, que permite operaciones aritméticas de curva elíptica en varias curvas (incluido BLS12-381);
  • MULMOD reduce el costo de gas de las operaciones 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 un contrato EVM;
  • Reduce significativamente el costo de la verificación ZKP en funciones hash algebraicas (por ejemplo, MiMC/Poseidon) y EVM.
  • PIE 6690:
  • 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, que puede 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.

EOF cambios**:**

  • 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 tradicional de EVM (código de bytes) es una secuencia de instrucciones no estructurada secuencia de instrucciones) bytecode. 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.
  • PIE 663:
  • Breve: instrucciones SWAP y DUP sin restricciones
  • 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.
  • PIE 3540:
  • Introducción:
  • En el pasado, el código de bytes 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. Esto no solo es un costo indirecto, sino que también impide que los desarrolladores introduzcan nuevos funciones o funciones antiguas en desuso.
  • Este EIP introduce un contenedor que se puede expandir y controlar la versión para EVM, y declara el formato del contrato EOF. Con base en esto, el código se puede verificar al implementar el contrato EOF, es decir, la creación La validación de tiempo significa que se puede evitar que se implementen los contratos que no se ajustan 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 favorece 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 el trabajo de análisis de datos en cadena. herramientas.
  • PIE 3670:
  • Introducción: Basado en EIP-3540, el propósito es garantizar que el código del contrato EOF se ajuste al formato y sea válido, y se evitará la implementación de contratos que no se ajusten al formato sin afectar a Legacy código de bytes
  • Importancia: según el contenedor introducido por 3540, EIP-3670 garantiza que el código en el contrato EOF es 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.
  • PIE 4200:
  • Introducción:
  • Introdujo 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 al implementar y ejecutar JUMP porque eliminan la necesidad de los códigos de operación JUMP y JUMPI existentes para hacer jumpdest. El tiempo de ejecución requerido para el análisis. Este EIP es para dinámica La adición de salto.
  • En comparación con las operaciones JUMP tradicionales, la diferencia es que las operaciones como RJUMP no especifican una posición de compensación específica, sino que especifican una posición de compensación relativa (desde dinámica saltos -> saltos estáticos), porque muchas veces estáticos los saltos son suficientes.
  • Importancia: optimizar la red y reducir costes.
  • PIE 4750:
  • Lleve la función de 4200 un paso más allá: introduciendo CALLF Los dos nuevos códigos de operación de y RETF implementan 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, por lo que se prohíbe la dinámica. saltar.
  • Significado: optimizar el código dividiendo el código en varias partes.
  • PIE 5450:
  • Antecedentes: el trasfondo 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, etcétera.
  • 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 la implementación del contrato EOF puede causar un desbordamiento o desbordamiento de la pila (desbordamiento de la pila). subdesbordamientos/desbordamientos). 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 gran mejora 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.

5mes26**************************** **************************************************** **************************************** 4844El cambio de tipo de transacción relacionado deSSZ****** aRLP significa que Cancún tiene dos ****** SSZ EIP******, así queEIP 6475 y 6493** se mudan fuera de Cancún para actualizar***

EIP 6475X

  • Introducción: EIP Propuesta complementaria a 4844. 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 ejecutiva de Ethereum, hubo una discusión sobre el EIP La discusión sobre el formato de serialización SSZ para 4844 mostró que inicialmente los desarrolladores favorecían la introducción de una iteración temprana del formato SSZ a EL a través de transacciones de blob y, finalmente, los desarrolladores planearon actualizar todos los tipos de transacciones de RLP a SSZ, pero dada su ruta poco clara y ciertamente no implementado en la actualización de Cancún, los desarrolladores han estado sopesando la eliminación de SSZ de EIP-4844. Después de mucha discusión, los desarrolladores acordaron eliminar SSZ de la implementación EL de EIP-4844**, pero no se eliminó EIP6475****. **SSZ-> Los cambios en el RLP significarán que las dos SSZ en Cancún ya no serán necesarias EIP: ** Por lo tanto EIP 6475 y 6493 se trasladarán fuera de Cancún para realizar mejoras. **

EIP 6493X

  • 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: SSZ cambios
  • Introducción: Sencillo SerialiZe, es el método de serialización utilizado en la cadena de balizas.
  • SS Los cambios también incluyen otras tres propuestas de apoyo, esta vez solo se introdujo 6465.
  • PIE 6465: raíz de retiro SSZ, define Merkle-Patricia existente Compromisos de migración de Trie (MPT) a retiros de serialización simple (SSZ);
  • PIE 6404 / EIP 6466:
  • Ambos definen un Merkle-Patricia existente Las promesas de Trie (MPT) están en proceso de migración a Simple Serialization (SSZ).
  • EIP-6404 — Raíz de transacción SSZ
  • EIP-6466 — Base de recepción SSZ

Tim Beiko** sugirió desarrollos futuros en torno a la expansión de Cancún en una reunión central de desarrolladores el 5mes26*** Las conversaciones son limitado a los siguientes cincoEIP:EIP 5920,5656,7069,4788 y 2537, dentro de este alcance se generarán propuestas de seguimiento. SeguimientoEIP 5656*** yEIP 4788 se confirmó como propuesta de actualización oficial,5920,7069 y2537 ***** eliminado donde ****** EIP 5920 se debe a la preocupación del desarrollador sobre los posibles efectos secundarios de la forma de transferir ETH*, así como el razonamiento, las pruebas y el trabajo de seguridad inconclusos, por lo que desde la actualización eliminar. ***

EIP 5920*：**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 combustible 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 los datos completos del receptor, incluido el código y la memoria, y finalmente necesita realizar una llamada, posiblemente haciendo otras cosas sin querer. operación.
  • Cambiar:
  • Se introduce un nuevo código de operación: (PAY) PAY_OPCODE donde:
  • Extraiga dos valores de la pila: addrthen val.
  • Transferir wei desde 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: 09.06.23 PAY se eliminó de la actualización debido a preocupaciones sobre los posibles efectos secundarios de la forma en que se transfiere ETH y el trabajo de razonamiento, prueba y seguridad requerido para aprobar la propuesta.

EIP 7069X

  • Introducción: instrucción CALL modificada
  • CAMBIADO: 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, se requería un cálculo un poco más preciso del gas disponible de 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 en sí misma para establecer un valor de gas razonable.
  • **Actualmente presentamos **63/64th Reglas:
  • Inspección de profundidad de llamada eliminada;
  • 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 de 2300, cuando un contrato llama a otro contrato, el contrato llamado obtendrá 2300 el gas se usa 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), y dado que establece una cantidad fija de gas, no hay forma de que las personas determinen esto como siempre que se pueda ajustar el precio del gas ¿Qué tipo de cálculos admite el gas?
  • Importancia: ** Allana el camino para la introducción de ** EOF ** en el futuro, y es más conveniente para la operación de grandes contratos. **
  • Eliminada la opcionalidad del gas: las nuevas directivas no permiten especificar el gas limite, pero confíe en la "regla 63/64" (principalmente refiriéndose al cambio de precio del gas para una gran cantidad de operaciones IO en EIP-150, lo que aumenta el consumo de gas de operaciones específicas) para limitar el gas. Esta importante mejora simplifica el proceso en torno a la regla "Asignación", sin importar si el valor se envía o no, la persona que llama no necesita realizar cálculos relacionados con el gas;
  • Después de presentar la nueva propuesta, los usuarios siempre pueden superar Out enviando más gas en la transacción (por supuesto, sujeto al límite de gas del bloque) de error de gas.
  • Anteriormente, al aumentar los costos de almacenamiento (por ejemplo, EIP-1884 aumentó el gas para ciertos códigos de operación), algunos contratos que solo enviaban una cantidad limitada de gas a sus llamadas se rompieron con el nuevo mecanismo de costos. 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.
  • Allanar 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;
  • Códigos de retorno de estado más convenientes: se han introducido funciones convenientes que devuelven códigos de estado más detallados: éxito (0), restauración (1), falla (2) y pueden ampliarse en el futuro.

EIP 2537*：***X

  • Introducción: Precompilación de manipulación de curvas BLS12-381.
  • Cambiado: Se agregaron operaciones en la curva BLS12-381 precompiladas al conjunto requerido para realizar de manera eficiente la verificación de firma BLS y realizar operaciones de verificación de SNARK, etc.
  • Importancia: Ethereum puede crear pruebas criptográficas más seguras y permitir una mejor interoperabilidad con la cadena de balizas**. **

PR 3175 *** Mencionado pero no preseleccionado, sin discusión adicional ***

PR 3175*：***X

  • Breve: esta propuesta evitaría que los validadores penalizados propongan bloques cuando estén fuera de 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 el 4 de mayo, PR 3175 está en proceso de formatearse como EIP y se cambiará a EIP-6987, que es por razones de seguridad para evitar que los validadores reducidos sean elegidos como proponentes de bloque.

futuro

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

**1.**Los principales objetivos de la actualización de Cancún son, en orden de prioridad, la expansión de la capacidad, la seguridad, el ahorro de gasolina y la 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 lado opuesto 50% del costo del rollup; las soluciones técnicas de EigenLayer y Celestia no han revelado demasiado, y sus datos no pueden ser evaluados; Ethstorage estima que el costo de DA bajará al 5% del original; Topia espera reducir el costo por 100 ~ 1000 veces.

2.** Ascenso a Cancún En el futuro 2~5 años de Danksharding**, es el período dorado de desarrollo de los proyectos de capa DA****

  • Capa El límite superior de seguridad de 2 depende de la capa DA que adopte. Proto-Danksharding beneficiará el protocolo de almacenamiento, el protocolo modular y la red de expansión de almacenamiento L1 a través del almacenamiento de datos de estado más económico.
  • **Primero, **Danksharding regresa 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 tablero de anuncios en tiempo real altamente seguro y dejar espacio para otros protocolos descentralizados para almacenamiento a largo plazo. (El El propósito del protocolo de consenso de Ethereum no es garantizar almacenamiento de todos los datos históricos para siempre. Más bien, el propósito es proporcionar un tablero de anuncios en tiempo real altamente seguro y dejar espacio para otros protocolos descentralizados para hacer almacenamiento a largo plazo. ）；
  • **En segundo lugar, **Danksharding **reduce el costo de **DA **, pero también es necesario resolver los problemas reales de tiempo de aterrizaje y disponibilidad de datos. **
  • Reducción de costos de DA**: **Antes de esta actualización, era necesario llamar a calldata para publicar datos del resumen en la cadena principal de Ethereum, y la tarifa de gas para llamar a este código era muy costosa, lo cual es una capa El pago más grande de 2, el EIP 4844 introduce el blob de datos como un espacio de datos adicional exclusivo para los resúmenes, lo que reducirá en gran medida los costos de almacenamiento y, por lo tanto, reducirá los costos de DA.
  • **El tiempo de aterrizaje real es largo, y el ** TPS ** mejorado y el ** gasolina ** reducido aún son limitados, por lo que es bueno para ** DA * * proyectos de capa en desarrollo continuo posterior: **
  • iable sobre danksharding en polynya En el artículo de fragmentación de datos de seguridad, se indica que la implementación tardará de 2 a 5 años;
  • ** Incluso si aterriza, puede aumentar ** TPS ** y reducir ** gasolina ** Las magnitudes siguen siendo limitadas:**
  • PIE 4844 actualmente admite 6 blobs, y el problema de expansión futura solo puede resolverse mediante Danksharding;
  • El espacio actual de bloques 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. En un estado ideal, será de aproximadamente 1500 después de aumentarse 100 veces, lo que no es una gran mejora en magnitud.
  • Por lo tanto, mucho tiempo para aterrizar + Los cambios reales limitados beneficiarán DA Proyectos de capa, algunos como Celestia, ** Eigenda** ** ** DA ** el proyecto aún puede superar un costo más económico y más rápido ** TPS ** para competir con ** Danksharding ** en el futuro , Almacenamiento ETH Topia* y otros nuevos proyectos DA también pueden llenar el vacío del mercado antes de aterrizar. **
  • Los problemas técnicos, como el almacenamiento de datos y la disponibilidad de datos, también deben abordarse:
  • 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: el propio dapp almacena datos relacionados con él mismo, la red del portal Ethereum (actualmente en desarrollo) o protocolos de terceros como exploradores de bloques, datos históricos en BitTorrent o almacenamiento espontáneo por usuarios individuales.
  • Por lo tanto, Proto-Danksharding beneficiará el protocolo de almacenamiento, el protocolo modular y la red 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;
  • Buena red de expansión de almacenamiento L1, como Eth almacenamiento, que puede proporcionar una solución de segundo nivel para el almacenamiento programable a un menor costo de almacenamiento.

**3.**Actualización a Cancún beneficia L2diversidad, L3, RAAS y Disponibilidad de datos y otras pistas

  • Análisis de pista L2:
  • Head Layer2, como Arbitrum Órbita, OP Pila, Polígono 2.0, Fractal Se beneficiarán 5 proyectos, incluidos Scaling (bajo StarkWare) e HyperChain (bajo zkSync). La reducción de la tarifa de almacenamiento que trajo blob hará que la serie anterior de capa restringida 2 El costo de los problemas de desarrollo y escalabilidad se ha mejorado en gran medida, y el rendimiento de datos se ha mejorado en gran medida.Después de resolver el problema de costos, la capa principal 2 Habrá una oportunidad de continuar implementando una ecología L3 concurrente multi-cadena altamente personalizada para funciones específicas;
  • La brecha en los costos operativos entre Layer2 de segundo nivel y Layer2 convencional se reducirá, dando a algunos proyectos pequeños más oportunidades de desarrollo, como Aztec, Metis, Boba, ZKspace, layer2.finance, etc.;
  • Aunque aún no se han verificado las necesidades reales de los proyectos de blockchain modular, 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 puede presentar Más desarrolladores web2.
  • 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 ** 5 ** jefes** capa2 **, la aparición de varios nuevos ** DA **, ¿pueden los nuevos proyectos constituir un Tenemos que poner un signo de interrogación en la pista. **
  • Primero, la capa de encabezado 2 La ventaja del despliegue de la cadena de aplicaciones radica en la integridad del marco de la red y la seguridad de la ecología entre las 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 fuertes en la actualidad, y todavía se encuentran en la etapa 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.
  • Departamento OP: Aunque OP actualización del lecho rocoso de stack+ El lanzamiento del 4844 ha supuesto un pequeño aumento de coste y eficiencia, pero el aumento no es muy atractivo;
  • 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. Pero el ZK actualmente en el mercado La mayoría de los RAAS todavía usan proyectos líderes (como ZkSync) para bifurcar la cadena, y las barreras aún no son fuertes.
  • SO, corto plazo OP RAAS** **Todavía hay espacio para el desarrollo antes de que ** layer3 ** aterrice. A la larga, ** ZK RAAS ** y ** layer3 ** pueden ser la tendencia futura. **
  • ZK RAAS 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 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

  • Cancún mejora la segunda propuesta importante SELFDESTRUCT la eliminación mejorará aún más la seguridad de Ethereum. Al mismo tiempo, para los posibles problemas de actualización de cuentas programáticas después de la eliminación, se prepara un nuevo código de operación SETCODE para mejorar esta situación;
  • Tercera Propuesta EIP para Upgrade Cancún 1153 agrega un código de operación de almacenamiento transitorio, que en primer lugar puede ahorrar gas, 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, que no necesitará considerar el problema de reembolso de transitorio almacenamiento;
  • Cuarta propuesta EIP para la actualización de Cancún 5656 presenta la instrucción de copia de memoria MCOPY, que puede copiar con mayor precisión palabras y oraciones codificadas, lo que mejorará el rendimiento de copia de memoria en aproximadamente un 10 %;
  • La quinta propuesta para la actualización de Cancún es EIP 4788 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 grupos de promesas, puentes y protocolos de recuperación;
  • Cancún actualiza las últimas actualizaciones de EIP centradas en CL propuestas (15 y 23 de junio): EIP 6988, EIP 7044, EIP 7045, que mejora la seguridad y la usabilidad de Ethereum en detalles, como mejorar la experiencia de los contribuyentes y mejorar la seguridad de la red.
  • Entre las propuestas eliminadas, SSZ-> La transformación del RLP hace que los dos SSZ EIP（EIP 6475 y EIP
  1. se eliminó de la actualización de Cancún; las propuestas relacionadas con EOF se eliminaron de la actualización de Cancún después de eliminarse de la actualización de Shanghái, y actualmente se considera que puede implementarse directamente en la actualización diaria posterior; EVMMAX se debe a algunos EIP relacionado con el Subconjunto de implementación de EOF, por lo que también se trasladó fuera de Cancún para actualizarlo junto con EOF; considerando los posibles efectos secundarios que pueden existir en la forma de transferir ETH, así como el trabajo de razonamiento, prueba y seguridad requerido para aprobar la propuesta. , PIE 5920 eliminado de la actualización.

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

Poco efecto en zkml

  • ZKML es prueba de conocimiento cero (Zero Conocimiento) y aprendizaje automático (Machine Learning); la combinación de **blockchain y ML modelo resuelve la protección de la privacidad y los problemas de verificabilidad 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 la máquina para el entrenamiento, la confidencialidad de la información personal es un requisito importante; o los parámetros del modelo son la competitividad central del proyecto, y el cifrado también es necesario para mantener las barreras a la competencia. Cuando existen problemas de confianza como estos, los modelos de ML no pueden 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 **: **Necesita algo como Espacio La tecnología central de esta estructura de almacenamiento separada es el nuevo protocolo de seguridad "a prueba de SQL". En pocas palabras, es un almacén de datos junto a la cadena de bloques, lo que permite a los desarrolladores conectarse dentro y fuera de la cadena en un formato SQL simple. cargar los resultados directamente en el contrato inteligente;
  • ZK-SNARKs ** es la forma principal de ** ZK ** en ** ZKML **, y puede adaptarse al cálculo en cadena de ** **ML ** ** Con el desarrollo de la criptografía, especialmente el recursivo **SNARK la prueba será beneficiosa ZKML Aterrizaje en la cadena:
  • Los ZK-SNARK se caracterizan por su gran compacidad. El uso de ZK-SNARK permite al probador generar una prueba breve, y el verificador no necesita interactuar y solo necesita realizar una pequeña cantidad de cálculo para verificar su validez. Este tipo de prueba solo necesita una vez La naturaleza de la interacción entre el verificador y el verificador hace que los ZK-SNARK sean eficientes y prácticos en aplicaciones prácticas, y es más adecuado para los requisitos de potencia informática de ML en la cadena.
  • Actualmente es imposible entrenar en la cadena, y solo los resultados de los cálculos fuera de la cadena pueden almacenarse 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). Las pruebas ZK de modelos grandes requieren una potencia informática más alta, que no se puede admitir en la cadena. Los ZK-SNARK solo admiten la prueba de conocimiento cero de ML con una pequeña escala 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 las aplicaciones de cadena de bloques ZKML, y la cadena solo puede almacenar los resultados de off- cálculos en cadena.

Buena abstracción de cuenta

  • En primer lugar, la actualización de Cancún puede reducir hasta cierto punto ZK resumen Prueba de pago:
  • La tarifa de transacción actual de zkSync depende de 3 aspectos:
  • El costo de los recursos fijos consumidos por el verificador para generar pruebas SNARK y verificarlas 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. Aunque no es mucho en comparación con el costo de generar pruebas, teniendo en cuenta que ZK aún se encuentra en sus primeras etapas, no se debe subestimar la tendencia de desarrollo futuro de la serie ZK.
  • En segundo lugar, la abstracción de cuenta transforma ** tx ** transacciones tradicionales en ** operaciones de usuario, y luego ** operaciones de usuario uso ECDSA * * Empaquetado en bloques, el almacenamiento en la cadena ocupa más que antes, por lo que los requisitos de almacenamiento son más altos;
  • **Siguiente, abstracción de cuenta y ** ZK rollup pueden complementarse:
  • El problema actual de abstracción de cuenta es Gas La tarifa es costosa, porque hay demasiados pasos y contratos inteligentes involucrados, por lo que hay una gran cantidad de datos, lo que lleva a Gas La tarifa es cara y ZK La ventaja de Rollup es que puede reducir datos;
  • La abstracción de cuentas dificulta garantizar la seguridad: dado que AA implica múltiples contratos, la seguridad es un problema, pero después de la formación gradual de L2 en el futuro, la capa de consenso no cambiará, los contratos inteligentes tendrán más usos y la seguridad de abstracción de cuenta también se puede garantizar, con la ayuda de ZK La verificación confiable del resumen mejorará aún más la seguridad.
  • **Finalmente, considerando el auge de la tecnología ** 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;
  • IA y optimización de actividades en la 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 proporcionar 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 será desde la expansión del espacio de almacenamiento, hasta la integración con ** ZK La complementariedad del resumen ** y la combinación con la tecnología ** AI ** beneficiará gradualmente el desarrollo futuro de la abstracción de cuentas. **

**6.**Revisando la hoja de ruta de Ethereum, ¿qué sigue?

  • **Actualmente, **Layer2 ** no tiene un rendimiento (en términos de latencia y rendimiento) similar a ** Solana **, ni ** Near ** Tal rendimiento de fragmentación y sin rendimiento de ejecución paralela como ** Sui ** y ** Aptos **, la actualización de Cancún ha mejorado la posición de liderazgo de Ethereum como líder; **
  • Después de la actualización de Cancún, se estiman varios tiempos de desarrollo importantes Fully-Danksharding** (2~5 años), *MEV * y ** Aterrizaje de 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 Azotar

  • Objetivo: Centrarse en resolver problemas 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 protecciones de preferencia.
  • PBS es la separación de productores 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á los problemas de MEV, que es la idea de la externalización de MEV.
  • El grado de avance de los PBS es aún muy bajo, y los más maduros son Colaboración con soluciones MEV externas - mevboost by flashbots.
  • Versión avanzada de "Consagrado Proposer-Builder Separation (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 Optimistic Retransmisión, 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 ligera 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 para cambios de estado de consenso; Consagrado acumulaciones。
  • 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 Parte de Verkle Las pruebas son 3 veces más eficientes que las pruebas de Merkle.
  • Consagrado Rollup 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.

El purga

  • El La purga 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 prestar servicios en el nivel P2P.
  • Estado latente. Cuando se trata de lidiar con el crecimiento del estado, hay dos objetivos principales: la apatridia débil, que se refiere al objetivo de solo usar el estado para construir un bloque, pero no verificarlo; el estado al que se accede. La hibernación del estado debería reducir el estado que un nodo necesita almacenar en un total de 20-50 ES。
  • En la quinta etapa Purga, EIP 4444 está escrito explícitamente en Roadmap, EIP-4444 requiere que el cliente borre los datos anteriores a 1 año, y todavía hay algunos trabajos de optimización de EVM en esta etapa, como la simplificación del mecanismo de precompilación de GAS y EVM, etc.;

El Derroche

  • En la final sexta etapa Splurge, EIP También se mencionó 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, las billeteras de recuperación social, etc.;

Materiales de referencia:

  • Actualización de la reunión de desarrollo central de Ethereum:
  • Etéreo Todos los desarrolladores principales llaman al n.º 148 redacción
  • Etéreo Todos los desarrolladores principales llaman al informe n.º 149
  • Etéreo Llamada de la capa de consenso #99 redacción
  • Etéreo Todos los desarrolladores principales llamen al n.º 150 redacción
  • Etéreo Todos los desarrolladores principales llamen al n.º 151 redacción
  • Etéreo Llamada de la capa de consenso #100 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 152 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 153 redacción
  • Etéreo Discusión en el foro de magos originales:
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 156 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 157 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 158 redacción
  • Etéreo Todos los desarrolladores principales ución llamada n.º 159 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 160 redacción
  • Etéreo Llamada de consenso de todos los desarrolladores principales n.º 108 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 161 redacción
  • Etéreo Llamada de consenso de todos los desarrolladores principales n.º 109 redacción
  • Etéreo Todos los desarrolladores principales ución Llamada n.º 162 redacción
  • Etéreo Llamada de consenso de todos los desarrolladores principales n.º 110 redacción *Tim tuiteó sobre la última actualización de Ethereum Cancún (09.06.23):
  • Ethereum All Core Developers Consenso Call #111 redacción
  • Etéreo Llamada de consenso de todos los desarrolladores principales n.º 112 redacción
  • Contenido relacionado con la actualización de Ethereum:
  • Introducción al código de autodestrucción:
  • Explore la propuesta EVMMAX y BLS12-381
  • Además de EIP-4844, ¿qué más incluirá la actualización de Cancún? Un vistazo a la última llamada de consenso de Ethereum
  • ¿Qué contenido nuevo se ha agregado en la actualización de Ethereum Shanghai?
  • tuits:
  • DE ACUERDO Ventures: después de la actualización de Ethereum Shanghai, Cancún mejora las oportunidades potenciales de inversión- Noticias prospectivas
  • Además del EIP-4844 de alto perfil, ¿qué propuestas incluirá la actualización de Cancún?
  • V God: función EVM que vale la pena considerar para su eliminación
  • Proto-Danksharding Preguntas más frecuentes
  • Recomendado por V God 丨 Comprensión profunda de la hoja de ruta de fragmentación de Ethereum, leer este informe es suficiente
  • Un artículo para entender Danksharding, el nuevo plan de actualización de Ethereum
  • Descifra datos interesantes y secretos ocultos en la última hoja de ruta de Ethereum
  • Vitalik: Por qué SELFDESTRUCT hace más daño que bien a la ecología de Ethereum
  • Visión Etérea:
  • Bloques Investigador Brrr: Cómo Proto-Danksharding acelera el L1 de Ethereum Escalabilidad acumulativa
  • La reunión 111 de Ethereum ACDC: discuta el alcance final de la actualización de Deneb y tres propuestas, incluida EIP-7044
  • COL El vistazo de Stacy Muur a la evolución de las soluciones de escalado de Ethereum: OP Apilar, arbitrario Órbita, Polígono 2.0
  • Comparación horizontal de tres tipos de Rollups: Rollups clásicos (Optimistic/ZK Rollups）、Consagrado Paquetes acumulativos, Soberano resúmenes
  • [AMA] Somos EF Research (Pt. 8: 07 julio, 2022):
  • 3 pistas populares que vale la pena repensar en 2023
  • Montenegro EDCON Reflexiones sobre el final de 2023: una mirada a las tendencias de infraestructura y aplicaciones
  • Fantasía infinita de la posibilidad de combinar AI y Web3
  • AI+Web3: Explorando la integración de inteligencia artificial y blockchain
  • Comparando zk-rollup y op-rollup: analizando por qué el zkSync actual del método de verificación La tarifa de gas es alta
  • "Agregar volúmenes a volúmenes": soluciones de abstracción de cuentas en la era Rollup
  • Interpretación en profundidad de ZKML: principios técnicos, escenarios de aplicación, ventajas y desafíos
  • ZKML: una tecnología de implementación modelo que integra IA y blockchain para lograr la protección de la privacidad
  • responsable datos de seguridad fragmentación
  • Diálogo con Qi, fundador de EthStorage Zhou | Disponibilidad de datos y almacenamiento descentralizado
  • Lea la última versión de la hoja de ruta de desarrollo de Ethereum en un artículo
  • Sobre el espacio y Una breve introducción al tiempo
  • Propuesta original:
  • PIE 4844:
  • PIE 6780:
  • PIE 1153:
  • PIE 5920:
  • PIE 5656:
  • PIE 7069:
  • PIE 4788:
  • PIE 2537:
  • EVMMAX EIP:
  • PIE 6601:
  • PIE 6990:
  • EOF cambios:
  • PIE 663:
  • PIE 3540:
  • PIE 3670:
  • PIE 4200:
  • PIE 4750:
  • PIE 5450:
  • PIE 6475:
  • PIE 6493:
  • relaciones públicas 3175:
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
  • Recompensa
  • Comentar
  • Compartir
Comentar
0/400
Sin comentarios
  • Anclado
Mapa del sitio
Comercie con criptomonedas en cualquier lugar y en cualquier momento
qrCode
Escanee para descargar la aplicación Gate.io
Comunidad
Español
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)
    • Acerca de nosotrosEmpleoSociosAcuerdo de usuarioAdvertencia de riesgosPolítica de privacidadCookie PolicyKit de mediosPrueba de reservas del 100 %LicenciaSeguridadPrivilegios de usuarios de GTGate ChainCalendarioAplicación de la leyCumbresGate Ventures
    Comprar criptomonedasVender criptomonedasTrading de spotTransacciones a futurosTokens apalancadosNFTGate PayGate LifeTarjeta de regaloGate OTCGate CharityGate CardTienda Gate
    Ventajas VIPComentarios de los usuariosAnuncioTarifasAyudaEnviar una solicitudListadoSeguridad de los contratos inteligentesDesarrolladoresBúsqueda de verificaciónSolicitud de comerciante P2PAplicación P2P cheque azulPrograma de afiliados
    Gate LearnCursos de criptomonedasGlosario sobre criptomonedasPrecios de criptomonedasMacrodatosReducción a la mitad del bitcoinCrypto Wiki
    Gate.io © 2013-2025.