El , programado para la activación en , es la próxima actualización importante de la red de Ethereum después de Pectra, y marca otro paso de escala tomado por el gigante de la criptografía. Fusaka Hard Fork December 3, 2025 Fusaka Hard Fork Las herramientas de la Pectra EIP se centran en mejorar el rendimiento, la seguridad y las herramientas de desarrollo. PeerDAS ( En la actualidad, la tecnología de la información se ha convertido en una herramienta para mejorar la calidad de la información y la calidad de la información, con el objetivo de mejorar la calidad de la información y la calidad de la información, así como mejorar la calidad de la información ( ), un límite en los límites de transacción de gases ( ), y actualiza los costos de gas ModExp ( El forco también mejora la producción de bloques con propositor determinista lookahead ( ) y mantiene las tasas de blob estables con límites vinculados a los costos de ejecución ( En la actualidad, la mayoría de las aplicaciones se encuentran disponibles en formato RLP ( ), añadiendo un nuevo opcode CLZ para operaciones de bits más rápidas ( ), y introduciendo una precompilación secp256r1 ( Para una mejor compatibilidad con las modernas claves de seguridad de criptografía y hardware. EIP-7594 EIP-7823 EIP-7825 EIP-7883 EIP-7917 EIP-7918 EIP-7934 EIP-7939 EIP-7951 Al igual que Pectra combinó “Prague” y “Electra”, Fusaka es un nombre combinado de y Representa el siguiente salto de Ethereum hacia un futuro altamente escalable, rico en datos, donde los rollups de capa 2 pueden operar más barato y más rápido. Fulu (execution layer) Osaka (consensus layer) En este blog, vamos a descomponer las características básicas del fork duro de Fusaka, explicar cómo funciona PeerDAS en la práctica, y pasar por los requisitos reales de red para los interruptores domésticos, supernodos y nodos completos - respaldados por los datos de devnet. Key Changes Introduced In Fusaka Hard Fork Cambios importantes introducidos en Fusaka Hard Fork : PeerDAS - Peer Data Availability Sampling EIP-7594 Página 7594 Ethereum necesitaba esta propuesta porque la red quiere proporcionar más disponibilidad de datos para los usuarios y especialmente para los rollups, pero con el actual El diseño, cada nodo todavía tiene que descargar demasiados datos de blob solo para comprobar que realmente se publicó. Esto crea un problema de escala porque si todos los nodos tienen que descargar todo, los requisitos de ancho de banda y hardware de la red aumentan, y la descentralización puede sufrir. Para corregir esto, Ethereum necesita una forma para que los nodos confirmen que los datos están disponibles sin descargar todo. Data Availability Sampling (DAS) resuelve esto permitiendo que los nodos comprueben solo pequeñas piezas aleatorias de los datos. Pero Ethereum también necesita un método DAS que se ajuste bien con la red de rumores existente y no añade cálculo pesado a los productores de bloqueo. PeerDAS fue creado para satisfacer estas necesidades y aumentar de forma segura el blobput a través de EIP-4844 PeerDAS es un sistema de red que permite a los nodos descargar sólo pequeñas piezas de datos de blob para comprobar que los datos completos fueron realmente publicados. En lugar de descargar todo, los nodos utilizan la red normal de chistes para compartir datos, descubrir cuáles pares tienen ciertas partes, y solicitar sólo las pequeñas muestras que necesitan. La idea principal es que al descargar solo pequeñas, partes aleatorias del blob, los nodos todavía pueden estar seguros de que el blob entero existe. Por ejemplo, en lugar de descargar un blob completo de 256 KB, un nodo podría descargar solo alrededor de 1/8 de él, pero porque muchos nodos muestran diferentes partes, cualquier dato perdido sería notado rápidamente. Para hacer el trabajo de muestreo, PeerDAS expande cada blob de Usando un tipo básico de codificación de borrado. —similar a cómo se puede completar un rompecabezas incluso si se pierden unas cuantas piezas. El rompecabezas se convierte en una "rueda" que contiene los datos originales más algunos datos codificados adicionales que le permiten ser reconstruido más adelante. Esta línea se divide en muchas piezas pequeñas llamadas células, que son las unidades verificadas más pequeñas vinculadas a un compromiso KZG. Todas las líneas se reorganizan en "columnas", donde cada columna contiene la celda en la misma posición de cada línea. Cada columna se asigna a una subred específica de rumores. Los nodos son responsables de almacenar ciertas columnas basadas en su ID de nodo y de recoger algunas columnas de cada slot de pares. Si un nodo recoge al menos el 50% de todas las colum EIP-4844 Erasure coding is a technique that adds extra redundant data so that the original data can be recovered even if some pieces are missing Además, la EIP introduce una regla importante: . This limit must be enforced during transaction validation, gossip, block creation, and block processing. This helps reduce extreme cases where a single transaction overloads the blob system. no transaction can contain more than 6 blobs PeerDAS añade algo llamado Una prueba de célula KZG muestra que un compromiso KZG realmente coincide con una célula específica (una pequeña pieza) de un blob. Esto permite a un nodo descargar sólo las células que desea muestrar, en lugar del blob completo, mientras que todavía garantiza la integridad de los datos. cell KZG proofs Pero generar todas estas pruebas de células es caro. Un productor de bloques tendría que calcularlas una y otra vez para muchos bloques, lo que es demasiado lento. para generar todas las pruebas celulares con antelación y incluirlas en el envoltorio de transacción. the blob transaction sender Debido a esto, el rumor de transacción (PooledTransactions) ahora utiliza un envoltorio modificado: rlp([tx_payload_body, wrapper_version, blobs, commitments, cell_proofs]) En el interior de la nueva capilla, es sólo una lista que contiene todas las pruebas para cada célula de cada blob (por ejemplo: Los otros campos - , de , y - son exactamente los mismos que estaban en EIP-4844.La diferencia es que el viejo campo de “probas” único se elimina y se sustituye por este nuevo lista, y un nuevo campo llamado is added to show which wrapper format is being used. cell_proofs [cell_proof_0, cell_proof_1, ...] tx_payload_body blobs commitments cell_proofs wrapper_version El es un solo byte, y en esta propuesta siempre se establece • El El campo contiene todas las pruebas de células para cada blob, incluidas las pruebas de las células de extensión adicionales creadas durante la codificación de la eliminación. Aunque la lista contiene pruebas para las celdas de extensión, los blobs mismos se envían en su forma normal (no extendida).Un blob sólo incluye su mitad original - el nodo receptor puede calcular la mitad de la extensión por sí solo, por lo que no hay necesidad de enviar datos innecesarios. wrapper_version 1 cell_proofs CELLS_PER_EXT_BLOB Más formalmente, es la prueba para la celda j-th del blob i-th después de correr , which produces both the original and extension cells. cell_proofs[i * CELLS_PER_EXT_BLOB + j] compute_cells(blobs[i]) Cuando un nodo recibe este envuelto, debe validar la transacción y comprobar que todo está en línea correctamente. Debe verificar que el número de hashes, blobs y compromisos de versión coinciden. Contiene exactamente Todos los elementos de la tabla deben ser hechos de una forma similar a la de la tabla ( Finalmente, el nodo debe comprobar que cada compromiso realmente coincide con el blob y sus pruebas. , y luego verifica todas las pruebas de células - se permite la verificación de lotes para hacer esto más rápido. cell_proofs CELLS_PER_EXT_BLOB * number_of_blobs kzg_to_versioned_hash(commitments[i]) == tx_payload_body.blob_versioned_hashes[i] compute_cells Imagina que un blob se divide en Después de la eliminación del código ( ). The original blob contains , y el nodo receptor calculará el En este caso, el remitente debe incluir en . Example 8 cells CELLS_PER_EXT_BLOB = 8 4 cells 4 extension cells all 8 proofs cell_proofs Por lo tanto, para 1 blob, el envoltorio de transacción contiene: blobs = [blob_0] (sólo 4 células originales) Compromisos = [compromiso_0] (proof for each of the 8 cells) cell_proofs = [proof_0, proof_1, …, proof_7] Cuando un nodo muestra muestras, puede solicitar solo la celda 2 o la celda 5, y puede verificarlas instantáneamente utilizando las pruebas de coincidencia, sin descargar nunca el blob completo. PeerDAS permite a Ethereum aumentar la disponibilidad de datos sin hacer que los nodos trabajen más duro. . In the future, this might even go down to , que permitiría a Ethereum escalar más. El sistema funciona bien porque cada nodo tiene muchos pares. Por lo tanto, si un peer no da los datos requeridos, el nodo puede simplemente pedir a otro peer. Esto crea redundancia natural y mejora la seguridad. Los nodos también pueden elegir almacenar datos de los requeridos, lo que fortalece aún más la red, incluso sin cambios de protocolo. 1/8 of the total blob data 1/16 or 1/32 more Los validadores tienen un poco más de responsabilidad que los nodos completos normales. Puesto que los validadores ya ejecutan un hardware más fuerte, PeerDAS les da una carga de custodia de datos que coincide con el número total de validadores. Esto asegura que un grupo estable de nodos esté siempre disponible para almacenar y compartir más datos, lo que hace que la red sea más confiable. En resumen, si hay 900.000 validadores, a cada validador se le podría asignar una pequeña porción de los datos totales de blob para almacenar y servir. PeerDas utiliza en lugar de la muestra de filas porque hace que la reconstrucción de los datos sea mucho más fácil. Si los nodos muestran filas completas (blobs enteros), tendrían que crear “blobs de extensión” adicionales que no existen naturalmente, lo que ralentizaría a los productores de bloques. Al tomar muestras de columnas, los nodos pueden preparar los datos de filas adicionales de antemano, y los remitentes de transacciones, no los productores de bloques, calcularán las pruebas necesarias. Imagínese que un blob es una red de células de 4×4. Sampling de filas significaría tomar todas las 4 células de una fila, pero algunas filas de extensión aún no están listas, por lo que el productor de bloques tendría que generarlas en el lugar. Sampling de columnas significa tomar una célula de cada fila (una columna). Las células adicionales necesarias para la reconstrucción se pueden preparar de antemano, por lo que los nodos pueden verificar los datos sin ralentizar la producción de bloques. column sampling Example: Trabaja plenamente con , por lo que no rompe nada ya en Ethereum.Todas las pruebas y las reglas detalladas están en las especificaciones de consenso y ejecución. EIP-7594 EIP-4844 The main security risk in any DAS system is a “data withholding attack,” where a block producer pretends that data is available but actually hides some of it. PeerDAS prevents this by using random sampling: nodes check random parts of the data. The more nodes that are sampled, the harder it is for an attacker to cheat. The EIP even provides a formula to calculate how likely such an attack could succeed, based on the total number of nodes (n), total samples (m), and samples per node (k). On the Ethereum mainnet, with about 10,000 nodes, the chance of a successful attack is extremely small, so PeerDAS is considered safe. La tabla muestra que las probabilidades de un ataque exitoso caen a un nivel insignificante, por lo que PeerDAS se considera seguro contra ataques de retención de datos. . El blog : Set upper bounds for MODEXP EIP-7823 Página 7823 Esta propuesta es necesaria porque la precompilación actual de MODEXP en Ethereum ha causado muchos errores de consenso a lo largo de los años. La mayoría de estos errores ocurrieron porque MODEXP permite tamaños de entrada extremadamente grandes e irrealistas, lo que crea casos infinitos e inusuales que los clientes deben manejar. Debido a que cada nodo tiene que procesar cualquier entrada que proporcione una transacción, no tener un límite superior hace que MODEXP sea más difícil de probar, más fácil de romper y más probable de comportarse de manera diferente entre diferentes clientes. Las entradas muy grandes también hacen que la fórmula del coste del gas sea difícil de predecir, porque es difícil de predecir algo cuando su tamaño puede crecer sin límites. Estos problemas también hacen que sea difícil reemplazar MODEXP con futuras herramientas de código de EIP-7823 introduce una regla simple: todos los tres campos de longitud utilizados por MODEXP —el tamaño de la BASE, el EXPONENTE y el MODULUS— deben ser: , que es 1024 bytes. las entradas MODEXP siguen el formato Como se define en , por lo que este EIP sólo restringe los valores de longitud. Si cualquier longitud excede de 1024 bytes, el precompilador se detiene inmediatamente, devuelve un error y quema todo el gas. Por ejemplo, si alguien intenta proporcionar un BASE que es de 2000 bytes de largo, la llamada fallará antes de que ocurra cualquier trabajo. Estos límites todavía soportan todos los casos reales de uso. La verificación RSA normalmente utiliza tamaños clave como 1024, 2048, o 4096 bits, todo bien dentro del nuevo límite. Las operaciones de curva elíptica utilizan tamaños aún más pequeños, a menudo por debajo de 384 bits, por lo que también no están afectados. 8192 bits or less <len(BASE)> <len(EXPONENT)> <len(MODULUS)> <BASE> <EXPONENT> <MODULUS> EIP-198 Estos nuevos límites también ayudan con futuras actualizaciones.Si MODEXP se reescribe en código EVM usando EVMMAX, los desarrolladores podrían agregar caminos optimizados para tamaños de entrada comunes como 256 bits, 381 bits, o 2048 bits, y usar un retroceso más lento para casos más raros. Con tamaños máximos fijos, los desarrolladores incluso pueden añadir manejo especial para valores de módulos muy comunes. Para confirmar que este cambio no rompería las transacciones pasadas, los autores analizaron todo el uso de MODEXP desde el bloque 5,472,266 (abril 20, 2018) hasta el bloqueo de 21,550,926 (4 de enero de 2025). , muy por debajo del nuevo límite de 1024 bytes.La mayoría de las llamadas reales usaron pequeñas longitudes como 32 bytes, 128 bytes, o 256 bytes.Había algunas llamadas inválidas o rotas, como entradas vacías, entradas llenas de bytes repetitivos como , y una entrada extremadamente grande pero inválida. Estos se comportarían de la misma manera bajo los nuevos límites porque ya eran inválidos. Así, mientras que el EIP es técnicamente un cambio revolucionario, en la práctica no habría cambiado el resultado de ninguna transacción pasada. 513 bytes 0x9e5faafc Desde un punto de vista de seguridad, reducir los tamaños de entrada permitidos no crea nuevos riesgos. En cambio, elimina los casos extremos innecesarios que previamente causaron errores e inconsistencias entre clientes. Al limitar las entradas MODEXP a tamaños realistas, este EIP hace que el sistema sea más previsible, reduce los extraños casos de esquina y reduce la posibilidad de errores entre diferentes implementaciones. Estas restricciones también ayudan a preparar el sistema para una transición más suave si futuras actualizaciones como EVMMAX introducen vías de ejecución optimizadas. : Transaction Gas Limit Cap EIP-7825 Página 7825 Ethereum necesitaba esta propuesta porque hoy en día una sola transacción puede usar casi todo el límite de gas de bloque. Esto crea varios problemas: una transacción podría consumir la mayor parte de los recursos del bloque y causar una desaceleración en el estilo DoS, las grandes operaciones de gas pesado pueden aumentar el estado de Ethereum demasiado rápidamente, y la validación de bloques se vuelve más lenta y más difícil para los nodos para seguir adelante. Si un usuario envía una gran transacción que utiliza casi todo el gas (por ejemplo, una transacción que consume 38 millones de gas en un bloque de gas de 40 millones), entonces otras transacciones normales no pueden encajar en el bloque, y cada nodo debe pasar más tiempo verificando ese bloque. Esto amenaza la estabilidad de la red y la descentralización porque la verificación más lenta significa EIP-7825 introduce una regla dura de que ninguna transacción puede usar más de Esto se convierte en un límite de nivel de protocolo, lo que significa que se aplica en todas partes: cuando un usuario envía una transacción, cuando el txpool la verifica, y cuando los validadores la incluyen en un bloque. Este límite es completamente independiente del límite de gas de bloque, por ejemplo, incluso si el límite de gas de bloque es de 40 millones, no se permite que una sola transacción use más de 16,7 millones de gas. 16,777,216 gas (2²⁴) MAX_GAS_LIMIT_EXCEED MAX_GAS_LIMIT_EXCEED Para entender mejor esto, imagina que un bloque tiene espacio para 40 millones de gases. Sin este capó, alguien podría enviar una única transacción que consume 35-40 millones de gases. Esa transacción monopolizaría el bloque y no dejaría espacio para otros, similar a una persona alquilando un autobús entero para que nadie más pueda embarcar. La propuesta también añade requisitos específicos a la forma en que los clientes validan las transacciones. El txpool debe rechazar una transacción si su gasLimit está por encima de 16,777,216, lo que significa que tal transacción nunca entra en la cola. Durante la validación de bloques, si un bloque contiene una transacción que excede el límite, el bloque mismo debe ser rechazado. Internamente, las implementaciones del cliente limitarán el parámetro GAS_LIMIT para todas las transacciones en este valor. El número Fue elegido porque es un límite limpio de dos potencias, lo que lo hace más fácil de implementar, y todavía es lo suficientemente grande como para manejar la mayoría de las transacciones del mundo real, como las implementaciones de contratos inteligentes, las interacciones complejas de DeFi o las llamadas de contratos en múltiples pasos. 16,777,216 (2²⁴) Este EIP también mantiene la compatibilidad con la mecánica del gas actual. La mayoría de los usuarios nunca notarán el cambio porque casi todas las transacciones existentes ya consumen mucho menos de 16 millones de gases. Los validadores y los constructores de bloques todavía pueden crear bloques que superen los 16,7 millones de gases totales, siempre que cada transacción individual respete el nuevo límite. Las únicas transacciones afectadas son extremadamente grandes que antes intentaron usar más que el nuevo límite. En términos de seguridad, la capa de gas hace que Ethereum sea más resistente a los ataques DoS basados en gas porque los atacantes no pueden forzar a los validadores a manejar transacciones extremadamente grandes más. También ayuda a mantener los tiempos de verificación de bloques predecibles para que los nodos puedan permanecer en sincronización más fácilmente. En general, EIP-7825 está diseñado para fortalecer la red contra el abuso, mantener los requisitos de los nodos razonables, mejorar la equidad en el uso del espacio de bloque, y garantizar que la cadena permanezca rápida y estable a medida que los límites de gas continúan aumentando con el tiempo. : ModExp Gas Cost Increase EIP-7883 Página 7883 La razón por la que Ethereum necesita esta propuesta es que el precompilador ModExp (utilizado para la exponenciación modular) ha sido en comparación con los recursos reales que consume. En algunas situaciones, las operaciones de ModExp requieren mucho más cálculo de lo que los usuarios están pagando actualmente. Esta descomposición crea un riesgo: si las llamadas complejas de ModExp se mantienen demasiado baratas, pueden convertirse en una Para corregir esto, Ethereum necesita ajustar la fórmula de precios ModExp para que el gas utilizado refleje correctamente el trabajo real realizado por el cliente.Es por eso que EIP-7883 introduce nuevas reglas que aumentan el coste mínimo, aumentan el coste general, y hacen que las operaciones con grandes entradas (especialmente exponentes, base o módulo sobre 32 bytes) sean más caras, por lo que el precio del gas coincide con el cálculo real necesario. underpriced bottleneck Esta propuesta modifica el algoritmo de precios ModExp definido originalmente en EIP-2565 aumentando el coste de varias maneras importantes. se eleva de 200 a 500, y la fórmula general ya no se divide por 3, lo que significa que el coste total efectivamente se Por ejemplo, si una llamada ModExp costó anteriormente 1.200 gases, ahora costará alrededor de 3.600 gases bajo la nueva fórmula. se duplica aumentando el multiplicador de 8 a 16. Para ilustrar esto: si la longitud del exponente era de 40 bytes, EIP-2565 agregaría a la cuenta de iteración, mientras que EIP-7883 ahora utiliza El precio es el doble que el precio, por lo que el precio es el doble que el and sharply increases the computation cost when these values exceed 32 bytes. For example, if the modulus is 64 bytes, the new rule applies a doubled complexity ( ) en lugar de la vieja fórmula más simple, reflejando el coste real de la aritmética de gran número. Juntos, estos cambios aseguran que las pequeñas operaciones de ModExp paguen una tarifa mínima justa y las operaciones grandes y pesadas escalen sus costes correctamente con el tamaño. minimum gas cost three times higher exponents larger than 32 bytes 8 × (40 − 32) = 64 16 × (40 − 32) = 128 minimum base/modulus size of 32 bytes 2 × words² La propuesta define una nueva función de cálculo de gas que actualiza las reglas de computación de complejidad e iteración.La complejidad de multiplicación ahora utiliza un valor predeterminado de 16 para longitudes de base / módulo de hasta 32 bytes, y para entradas más grandes cambia a la fórmula más pesada , donde "palabras" es el número de fragmentos de 8 bytes. La cuenta de iteración también se actualiza para que los exponentes de 32 bytes o más pequeños utilicen su longitud de bit para determinar la complejidad, pero los exponentes mayores de 32 bytes añaden una multa mucho mayor. Esto asegura que los exponentes muy grandes, que son computacionalmente caros en la práctica, ahora tienen un coste de gas mucho más alto. 2 × words² La motivación detrás de estos aumentos de precios proviene de los índices de referencia que muestran muchas situaciones en las que el precompilador de ModExp fue significativamente subestimado. Operaciones típicas en torno a , y operaciones muy grandes o desequilibradas por factores mucho más grandes -a veces más que —dependiendo de lo grande que sea el exponente, la base o el módulo. La intención no es cambiar la forma en que funciona ModExp, sino asegurarse de que incluso en sus casos de extremidad más intensivos en recursos ya no amenace la estabilidad de la red ni evita futuros aumentos al límite de gas de bloque. , pero la repricing de gas ha ocurrido muchas veces antes en Ethereum y se entiende bien. 150% 200% 80× backward-incompatible Los resultados de las pruebas muestran lo significativos que pueden ser los aumentos. ahora costará 500 gases (en aumento de 200) o tres veces su precio anterior. pero ciertos casos de pruebas pesadas ven enormes aumentos. Por ejemplo, en una prueba "exp-pesada", el coste salta de 215 gases a 16.624 gases —aproximadamente En otro caso que involucra una operación de base pesada, el coste va de 1.026 a 94.448 gas, lo que refleja cómo la multiplicación de grandes números realmente escala. 99.69% of historical ModExp calls 76× more En términos de seguridad, esta propuesta no crea nuevos vectores de ataque ni hace que cualquier operación sea más barata. En su lugar, se centra en prevenir un riesgo importante: las operaciones de ModExp de bajo precio podrían permitir que los atacantes llenen bloques con cálculos extremadamente pesados por un coste muy bajo. La única desventaja posible es que algunas operaciones de ModExp podrían ahora volverse sobrepreciadas, pero esto se considera un resultado mucho mejor que el actual problema de subpreciación. Test Case EIP-2565 Pricing EIP-7883 Pricing Increase modexp_nagydani_1_square 200 500 150% modexp_nagydani_1_qube 200 500 150% modexp_nagydani_1_pow0x10001 341 2048 501% modexp_nagydani_2_square 200 512 156% modexp_nagydani_2_qube 200 512 156% modexp_nagydani_2_pow0x10001 1365 8192 501% modexp_nagydani_3_square 341 2048 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 500% modexp_nagydani_4_square 1365 8192 501% modexp_nagydani_4_qube 1365 8192 501% modexp_nagydani_4_pow0x10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_pow0x10001 87381 524288 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_even 2298 51136 2125% modexp_guido_2_even 2300 51152 2124% modexp_guido_3_even 5400 32400 500% modexp_guido_4_even 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632% modexp_marcin_1_balanced 200 1200 500% modexp_marcin_2_base_heavy 867 5202 500% modexp_marcin_2_exp_heavy 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_heavy 677 2032 200% modexp_marcin_3_exp_heavy 765 4080 433% modexp_marcin_3_balanced 1360 4080 200% modexp_narrador_1_square 200 500 El 150% modexp_narrador_1_quebe 200 500 El 150% MODEXP_NACIDAD_1_POW0X10001 341 2048 El 501% modexp_narrador_2_square 200 512 El 156% modexp_narrador_2_quebe 200 512 El 156% modexp_nagydani_2_pow0x10001 1365 8192 El 501% modexp_nagydani_3_square 341 2048 El 501% modexp_nagydani_3_qube 341 2048 501% modexp_nagydani_3_pow0x10001 5461 32768 El 500% modexp_narrador_4_square 1365 8192 501% modexp_nagydani_4_qube 1365 8192 El 501% MODEXP_NACIDAD_4_POW0X10001 21845 131072 500% modexp_nagydani_5_square 5461 32768 El 500% modexp_nagydani_5_qube 5461 32768 500% modexp_nagydani_5_pow0x10001 87381 524288 El 500% modexp_marius_1_even 2057 45296 2102% modexp_guido_1_también 2298 51136 2125 por ciento modexp_guido_2_también 2300 51152 2124 por ciento modexp_guido_3_también 5400 32400 El 500% modexp_guido_4_también 1026 94448 9105% modexp_marcin_1_base_heavy 200 1152 476% modexp_marcin_1_exp_heavy 215 16624 7632 por ciento modexp_marcin_1_controlador 200 1200 500% modexp_marcin_2_base_heavy 867 5202 El 500% modexp_marcin_2_exp_pesado 852 16368 1821% modexp_marcin_2_balanced 996 5978 500% modexp_marcin_3_base_pesado 677 2032 200% modexp_marcin_3_exp_pesado 765 4080 El 433% modexp_marcin_3_balanced 1360 4080 200% *source: https://eips.ethereum.org/EIPS/eip-7883#test-cases* : Determine proposer lookahead EIP-7917 Página 7917 Ethereum needed this proposal because the network’s proposer schedule for the next epoch was not fully predictable. Even though the RANDAO seed for epoch is known during epoch , la lista actual de proponentes todavía podría cambiar debido a las actualizaciones de balance efectivo (EB) que ocurren dentro de la época Estos cambios EB pueden provenir de recortes, penalizaciones, recompensas por encima de 1 ETH, consolidaciones de validadores, o nuevos depósitos, especialmente después de que EIP-7251 elevó el saldo efectivo máximo más allá de 32 ETH. Esta incertidumbre crea problemas para los sistemas que dependen de conocer al siguiente proponente de antemano, como los protocolos de preconfirmación basados, que necesitan un horario estable y previsible para funcionar sin problemas. Un validador podría incluso intentar "grind" o manipular su balance efectivo para influir en quien se convierte en el proponente de la próxima era. Debido a estos problemas, Ethereum necesitaba una manera de hacer que el proponente planifique completamente determinista varias épocas por delante para que no pueda ser cambiado por las actualizaciones de EB de última hora y N+1 N N To implement this, the EIP introduces a deterministic proposer lookahead by pre-computing and storing the proposer schedule for the next MIN_SEED_LOOKAHEAD + 1 epochs at the start of every epoch. In simple terms, the beacon state now contains a list called that always covers two full epochs of proposers - 64 slots in total. For example, when epoch N begins, this list already includes the proposer for every slot in epoch N and epoch N+1. Then, when the network moves to epoch N+1, the list is shifted forward: the proposer entries for epoch N are removed, the entries for epoch N+1 move to the front, and new proposer entries for epoch N+2 are added at the end. This makes the schedule fixed, predictable, and easy for clients to read directly, instead of recomputing proposers every slot. proposer_lookahead Para mantener esto actualizado, la lista se mueve hacia adelante en cada límite de la época: se eliminan los datos para la época pasada, y se calcula y añade un nuevo conjunto de índices de proponentes para la próxima época futura. El proceso utiliza las mismas reglas de semilla y equilibrio efectivo como antes, pero ahora el calendario se calcula antes, eliminando la posibilidad de cambios EB que lo afectan después de que la semilla sea conocida. Imagine each epoch has 8 slots instead of 32 (just for simplicity). Without this EIP, during epoch 5, you know the seed for epoch 6, but the actual proposer for slot 2 of epoch 6 could still change if a validator gets slashed or earns enough rewards to change their effective balance inside epoch 5. With EIP-7917, at the de la era 5, Ethereum pre-calcula todos los proponentes para la era 5, 6 y 7 y los almacena en orden dentro . Now, even if balances change later in epoch 5, the proposer list for epoch 6 stays fixed and predictable. Inicio proposer_lookahead This EIP fixes a long-standing oversight in the beacon chain design. It guarantees that once the RANDAO from earlier epochs becomes available, the validator selection for future epochs cannot be altered. This also prevents “effective balance grinding,” where a validator tries to adjust their balance after seeing the RANDAO to influence the next epoch’s proposer list. With deterministic lookahead, that entire attack vector is eliminated, making the security analysis much simpler. It also gives consensus clients early visibility into who will propose upcoming blocks, which helps implementations and allows the proposer schedule to be easily verified by the application layer via a Merkle proof from the beacon root. Los autores consideraron alternativas, como el almacenamiento en caché de los saldos efectivos al comienzo de una época, pero eso requeriría almacenamiento adicional y no exponería el horario al EVM. También comprobaron la compatibilidad con futuras características como la elección de líderes secretos únicos (SSLE). El diseño actual sigue siendo compatible porque el lookahead podría un día almacenar IDs de proponentes cifrados, o posiblemente ser deshabilitado por completo si SSLE elimina el lookahead, sin romper nada. Antes de esta propuesta, los clientes sólo calculaban el proponente para la ranura actual. Con EIP-7917, ahora calculan la lista de proponentes para todas las ranuras de la próxima era a la vez durante cada transición de la época. Esto añade una pequeña cantidad de trabajo, pero el cálculo de los índices de proponentes es muy ligero y principalmente implica la toma de muestras de las listas de validadores usando la semilla. Sin embargo, los clientes necesitarán un análisis de referencia para asegurarse de que este cálculo adicional no cause problemas de rendimiento. Este EIP no cambia la forma en que funciona el retraso de RANDAO. todavía se deriva del RANDAO de la época El único cambio es que los saldos efectivos ahora están alineados con el mismo retraso, por lo que los validadores no pueden modificar su EB después de ver el resultado de RANDAO. Esto elimina una estrategia de manipulación potencial, incluso si ningún ataque había sido descubierto todavía. N N − MIN_SEED_LOOKAHEAD − 1 : Blob base fee bounded by execution cost EIP-7918 EIP-7918 Ethereum necesita esta propuesta porque el actual sistema de tarifas de blob (de ) se rompe cuando el gas de ejecución se convierte en el principal coste para los rollups. En este momento, la mayoría de los rollups pagan mucho más por el gas de ejecución (el coste de incluir su transacción de blob en el bloque) de lo que pagan por la tarifa de blob real. Esto crea un problema: incluso si Ethereum continúa bajando la tarifa de base de blob una y otra vez, el coste total del rollup no cambia realmente, porque la parte cara sigue siendo el gas de ejecución. Debido a esto, la tarifa de base de blob continúa cayendo hasta que alcanza el mínimo absoluto (1 wei), y el protocolo ya no puede usar la tarifa de blob para controlar la demanda. Luego, cuando el uso de blob sube repentinamente, la tarifa de blob necesita EIP-4844 For example, imagine a rollup wants to post its data: it pays about 25,000,000 gwei in execution gas (25 gwei per gas for roughly 1,000,000 gas), while the blob fee is only around 200 gwei. This means the total cost is roughly 25,000,200 gwei, where almost the entire cost comes from execution gas, not the blob fee. If Ethereum keeps lowering the blob fee—say from 200 gwei to 50 gwei, then to 10 gwei, and eventually down to 1 wei—the total cost barely changes at all, staying almost exactly 25,000,000 gwei. Because users don’t feel any difference, they don’t change their behavior, so the protocol keeps pushing blob fees down until they hit the minimum possible value. Then, when blob demand suddenly increases again, the blob base fee has to climb all the way up from 1 wei, causing sharp, unpredictable fee spikes. corregir esto mediante la introducción de un “precio de reserva” mínimo para las tarifas de blob que depende de la tarifa base de ejecución, evitando que los precios de blob caigan de forma irreal y manteniendo el precio de blob mucho más estable y previsible para los rollups. EIP-7918 The core idea of EIP-7918 is simple: the price of a blob should never be cheaper than the cost of a certain amount of execution gas (called ). In the EIP, this constant is set to . The mechanism works through a small change inside the function. Usually, this function increases or decreases the blob base fee depending on whether blocks are using more or less blob gas than the target. With this proposal, if a blob becomes “too cheap” compared to execution gas, the function stops subtracting the target blob gas. This makes the excess blob gas grow faster, which prevents the blob base fee from falling further. As a result, the blob base fee now has a minimum value equal to . BLOB_BASE_COST 2¹³ calc_excess_blob_gas() BLOB_BASE_COST × base_fee_per_gas ÷ GAS_PER_BLOB Para entender por qué esto es necesario, ayuda a mirar la demanda de blob. Un rollup se preocupa por el precio total que paga: costo de ejecución más costo de blob. Si la tasa de gas de ejecución es muy alta, por ejemplo, 20 gwei, entonces incluso si la tasa de blob cae de 2 gwei a 0,2 gwei, el coste total apenas cambia. Esto significa que reducir la tasa de base de blob no tiene casi ningún impacto en la demanda. .” It creates a situation where the demand curve is almost vertical: lowering price does not increase demand. When this happens, the blob base fee mechanism becomes blind—it keeps lowering the price even though demand does not react. That is why the blob base fee often slides down to 1 wei. Then, when real demand increases later, the protocol needs an hour or more of nearly full blocks to raise the fee back up to a reasonable level. EIP-7918 fixes this by establishing a reserve price tied to execution gas so that blob fees remain meaningful even when execution costs dominate. fee inelasticity Otra razón para agregar este precio de reserva es que los nodos tienen que hacer mucho trabajo extra para verificar las pruebas de KZG para los datos de blob. Estas pruebas son lo que garantiza que los datos dentro de un blob realmente coinciden con su compromiso. , a node only had to verify one proof per blob, which was cheap. But with (PeerDAS), blobs are broken into many small pieces called cells, and every cell has its own proof. This makes verification much heavier. For example, the execution layer now has to batch-verify 128 proofs for every single blob before a transaction can even enter the mempool—this is about fifteen times more expensive than the normal KZG proof verification that smart contracts pay for. On top of that, full nodes, supernodes, and validators must verify even more proofs depending on how many columns they store or sample. A typical full node must verify proofs for all blobs in the mempool, plus eight sampled columns every slot, plus four columns it permanently custodies. All of this uses real CPU time, and it isn’t free for node operators. If blob fees drop too low, users would get this expensive compute work from the network essentially for free. By linking the blob reserve price to execution gas fees, EIP-7918 makes sure blob users always pay at least a fair minimum amount for the load they put on nodes. EIP-4844 EIP-7594 A largo plazo, EIP-7918 también ayuda a preparar Ethereum para el futuro. A medida que la tecnología mejora, el costo de almacenar y compartir datos se vuelve naturalmente más barato, y se espera que Ethereum permita más datos blob a lo largo del tiempo. Cuando la capacidad de blob aumenta, las tarifas de blob (en ETH) deben bajar naturalmente. Esta propuesta apoya que porque el precio de reserva está ligado a los precios de gas de ejecución, no un número fijo, por lo que puede ajustarse a medida que la red crece. A medida que tanto el blobspace como el bloque de ejecución se expanden, su relación de precio permanece equilibrada. La única vez que el precio de reserva puede llegar a ser demasiado alto es en un futuro muy improbable donde Ethereum aumenta la capacidad de blob mucho pero no aumenta ) is considered safe and well-balanced. BLOB_BASE_COST = 2¹³ There is one small detail to understand when execution gas fees suddenly jump. Because the blob reserve price depends on the execution base fee, a sudden rise in execution costs can temporarily push blob fees into a state where execution fees are guiding them. For example, imagine execution gas suddenly jumps from 20 gwei to 60 gwei in one block. Since the reserve price for blobs is tied to that number, blob fees cannot drop below the new higher level. Blob fees will still increase normally if blobs are being used, but the protocol will not allow them to decrease until they have risen enough to match the higher execution cost. This means blob fees may climb more slowly than execution fees for a few blocks. This small delay is not harmful — it actually prevents sharp, sudden swings in blob prices and keeps the system smoother and more stable. The authors also performed empirical analysis by applying the reserve price rule to real blob activity from and Durante los períodos de alta ejecución (alrededor de ), the reserve threshold significantly increased the blob base fee compared to the old mechanism. During low-execution-fee periods (around ), the blob fee remained almost unchanged except when the calculated blob base fee dropped below the reserve price. By comparing thousands of blocks, the authors show that the new mechanism creates more stable pricing while still responding naturally to demand. A histogram of four months of blob fees shows that the reserve price prevents blob fees from collapsing toward 1 wei, which reduces extreme volatility. November 2024 March 2025 16 gwei average 1.3 gwei average En términos de seguridad, el cambio no introduce ningún riesgo.La tarifa de base de blob siempre se fijará en o por encima del coste de units of execution gas. This is safe because the mechanism only raises the minimum fee, and setting a lower bound on pricing does not interfere with protocol correctness. It simply ensures healthy economics. BLOB_BASE_COST : RLP Execution Block Size Limit EIP-7934 Página 7934 Before EIP-7934, Ethereum did Tener un límite superior estricto sobre lo grande que podría ser un bloque de ejecución codificado por RLP. En teoría, un bloque podría convertirse en extremadamente grande si contenía muchas transacciones o datos muy complejos. y . If a block was too large, it would take longer for nodes to download and verify it, which slowed block propagation and increased the chance of temporary blockchain forks. Worse, an attacker could deliberately create a very large block to overload nodes, causing delays or even knocking them offline — a classic denial-of-service scenario. At the same time, Ethereum’s consensus layer (CL) gossip protocol already refused to propagate any block over , lo que significa que los bloques de ejecución excesivamente grandes podrían no propagarse a través de la red, creando fragmentación o nodos en desacuerdo en la cadena. Debido a estos riesgos, Ethereum necesitaba una regla clara y a nivel de protocolo para prevenir los bloques excesivamente grandes y mantener la red estable y segura. not network instability DoS attack risks 10 MB EIP-7934 resuelve esto introduciendo una on the size of an RLP-encoded execution block. The maximum allowed block size ( ) se ha establecido , but because beacon blocks also consume some space ( ), Ethereum añade a Esto significa que el tamaño real máximo de bloque de ejecución codificado por RLP permitido es . If the encoded block is larger than this limit, the block is considered and nodes must reject it. With this rule in place, block producers must check the encoded size of every block they build, and validators must verify this limit during block validation. This size cap applies de los límites de gases -que significa incluso si un bloque es " ” it can still be rejected if its encoded size is too large. This ensures that both gas usage and real byte-size constraints are respected. protocol-level cap MAX_BLOCK_SIZE 10 MiB (10,485,760 bytes) SAFETY_MARGIN 2 MiB (2,097,152 bytes) MAX_RLP_BLOCK_SIZE = MAX_BLOCK_SIZE - SAFETY_MARGIN invalid independently under the gas limit, Elegir a was intentional because it matches the existing constraint in the consensus layer gossip protocol. Anything larger than 10 MiB would not be broadcast across the network anyway, so this EIP brings the execution layer into alignment with the consensus layer’s limits. This creates consistency across all components and prevents situations where a valid execution block becomes “invisible” because the CL refuses to gossip it. 10 MiB cap Este cambio es Con bloques más grandes que el nuevo límite, lo que significa que los mineros y validadores deben actualizar a sus clientes para respetar la regla. Sin embargo, dado que los bloques de gran tamaño ya eran problemáticos y no normales en el funcionamiento real, el impacto es mínimo. En términos de seguridad, este EIP fortalece significativamente a Ethereum contra ataques DoS de tamaño de bloque dirigidos asegurándose de que ningún participante pueda crear bloques que abrumen la red. En general, EIP-7934 añade un límite de seguridad importante, mejora la estabilidad, alinea el comportamiento de EL y CL y previene varias clases de ataques relacionados con la creación y propagación de bloques de gran tamaño. not backward-compatible : Count leading zeros (CLZ) opcode EIP-7939 EIP-7939 Antes de este EIP, Ethereum tenía to count the number of leading zero bits in a 256-bit number. Developers had to implement CLZ manually in Solidity using many bit-shift operations and comparisons. This was a big problem because the custom implementations were , y , lo que aumentó el uso de gas. Para los sistemas de prueba de conocimiento cero, el coste era aún mayor - los cambios de derecha son extremadamente caros para demostrar, por lo que las operaciones como CLZ ralentizaron significativamente los circuitos ZK. Dado que CLZ es una función de bajo nivel muy común utilizada en bibliotecas matemáticas, algoritmos de compresión, bitmaps, esquemas de firma y muchas tareas criptográficas o de procesamiento de datos, Ethereum necesitaba una forma más rápida y más barata de calcularlo. no built-in opcode slow, expensive used a lot of bytecode EIP-7939 solves this by introducing a . This opcode takes a 256-bit value from the stack and returns the number of leading zero bits. If the input number is zero, the opcode returns , because a 256-bit zero has 256 leading zero bits. This matches how CLZ works in many CPU architectures like ARM and x86, where this operation is native. Adding CLZ makes many algorithms significantly cheaper: operations like , , de , various math functions, byte-string comparisons, bitmap scanning, calldata compression/decompression, and post-quantum signature schemes all benefit from faster leading-zero detection. new opcode called CLZ (0x1e) 256 lnWad powWad LambertW Al igual que un , y ligeramente elevado del antiguo precio MUL para evitar subestimar el opcode y causar riesgos DoS. Benchmarks muestran que CLZ utiliza aproximadamente el mismo esfuerzo de computación que ADD, y en el entorno de prueba SP1 rv32im, CLZ es en realidad , reduciendo los costos de prueba de ZK. El EIP también explica por qué eligieron CLZ en lugar de : you can compute CTZ from CLZ using , but you reliably implement CLZ using CTZ, so CLZ is more fundamental. The gas cost for CLZ is set to 5 ADD cheaper to prove than ADD CTZ (count trailing zeros) x & -x cannot This EIP is fully backwards-compatible because it introduces a Opcode y no modifica ningún comportamiento existente. También cubre claramente los casos de borde: por ejemplo, el opcode devuelve 256 cuando la entrada es cero, y varios casos de prueba muestran entradas como valores de todo cero, conjunto de bits superiores y completamente no-nonzero. Dado que CLZ tiene un costo de gas previsible y bajo, no hay crecimiento de la memoria y no hay cambios de estado, es seguro de problemas de denegación de servicio. new En general, EIP-7939 hace que Ethereum sea más rápido, más barato y más amigable para los desarrolladores al agregar un primitivo simple y eficiente que las CPU modernas ya soportan: cortar gas, reducir el tamaño del bytecode y reducir los costes de prueba de ZK para muchas operaciones comunes. : Precompile for secp256r1 Curve Support EIP-7951 Página 7951 Antes de este EIP, Ethereum había tener una forma segura y nativa de verificar las firmas digitales creadas utilizando el Esta curva es el estándar utilizado en dispositivos modernos como Debido a esta falta de soporte, las aplicaciones y las carteras no podían usar fácilmente la seguridad de hardware a nivel de dispositivo para la firma.Hubo un intento anterior (RIP-7212), pero tuvo relacionados con el manejo de puntos a infinidad y la comparación incorrecta de firmas. Estos problemas podrían causar errores de verificación o incluso riesgos de fallos de consenso. not secp256r1 (P-256) curve Apple Secure Enclave, Android Keystore, HSMs, TEEs, and FIDO2/WebAuthn security keys two serious security vulnerabilities EIP-7951 fixes those security problems and introduces a safe, native precompile so Ethereum can finally support signatures from modern hardware securely and efficiently. EIP-7951 añade un nuevo at address called , que realiza la verificación de la firma de ECDSA utilizando la curva secp256r1. Esto hace que la verificación de la firma sea rápida y barata en comparación con la implementación del algoritmo directamente en Solidity. El precompilador utiliza los parámetros oficiales de curva definidos por NIST, incluyendo el módulo de campo, la ecuación de curva, el punto de base y el orden de subgrupo, lo que garantiza una fuerte seguridad criptográfica. Los puntos y escalares se codifican en un formato de big-endi estricto de 32 bytes, y un valor de 64 bytes de todo cero se utiliza para representar el punto en el infinito. El precompilador espera exactamente —the hash, signature (r, s), and public key coordinates (qx, qy)—and it returns Para el éxito o for failure. precompiled contract 0x100 P256VERIFY 160 bytes of input 32 bytes of 1 empty output The EIP also defines strict . It checks that r and s are within valid ranges, that the public key lies on the curve, and that it is not the point at infinity. If anything is invalid, the precompile returns failure without reverting and consumes the same gas as a successful call. The verification algorithm follows standard ECDSA: it computes s⁻¹ mod n, rebuilds the signing point R’, rejects if R’ is infinity, and finally checks whether the x-coordinate of R’ matches r (mod n). This corrects the mistake in RIP-7212, which compared r’ directly instead of reducing it mod n. input validation rules La curva secp256r1 está totalmente definida por el siguiente conjunto de parámetros: Base field modulus = p = 0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff Curve equation: y^2 = x^3 + ax + b (mod p) Curve coefficient a = 0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc Curve coefficient b = 0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b Base point G: Gx = 0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296 Gy = 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5 Subgroup order = n = 0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551 Cofactor = h = 0x1 Estos parámetros son estandarizados por NIST en SP 800-1861. El coste del gas para la operación se establece en , que es más alto que la versión RIP-7212, pero coincide con los estándares de rendimiento reales para la verificación secp256r1. Importante, la interfaz sigue siendo totalmente compatible con las redes Layer 2 que ya han desplegado RIP-7212 -la misma dirección, el mismo formato de entrada/salida- por lo que los contratos inteligentes existentes seguirán funcionando sin cambios. 6900 gas Input: P256VERIFY call excepts 160 Bytes as input that is interpreted as byte concatenation of: 32 bytes ----> message hash (h) 32 bytes ----> signature component (r) 32 bytes ----> signature component (s) 32 bytes ----> public key x-coordinate (qx) 32 bytes ----> public key y-coordinate (qy) Output: will be 32 bytes on successfull verification and 0 bytes on failure Input Validation: The precompile MUST perform the following validation checks and return `` (failure) if any check fails: 1. Input length: Input MUST be exactly 160 bytes 2. Signature component bounds: Both r and s MUST satisfy 0 < r < n and 0 < s < n 3. Public key bounds: Both qx and qy MUST satisfy 0 ≤ qx < p and 0 ≤ qy < p 4. Point validity: The point (qx, qy) MUST satisfy the curve equation qy^2 ≡ qx^3 + a*qx + b (mod p) 5. Point not at infinity: The point (qx, qy) MUST NOT be the point at infinity (represented as (0, 0)) From a security standpoint, the EIP restores proper ECDSA behavior, eliminates malleability concerns at the precompile level (leaving optional checks to applications), and clarifies that constant-time execution is not required for the precompile. The secp256r1 curve provides 128-bit security and is widely trusted and analyzed, making it safe for Ethereum adoption. En resumen, , solucionar los problemas de seguridad de la propuesta anterior, y proporcionar una forma fiable y estandarizada de verificar las firmas de P-256 en todo el ecosistema. EIP-7951 is needed to safely bring modern hardware-backed authentication to Ethereum La tabla a continuación resume qué clientes de Ethereum necesitan implementar cambios para cada Fusaka EIP. indica que el EIP requiere actualizaciones a los clientes de la capa de consenso, mientras que una marca de shows that the change affects execution-layer clients. Some EIPs require updates in both layers, while others are specific to just one. Consensus Client Execution Client EIP Number EIP Name Consensus Client Execution Client EIP-7594 PeerDAS - Peer Data Availability Sampling ✅ ✅ EIP-7823 Set upper bounds for MODEXP ✅ EIP-7825 Transaction Gas Limit Cap ✅ EIP-7883 ModExp Gas Cost Increase ✅ EIP-7917 Deterministic proposer lookahead ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7934 RLP Execution Block Size Limit ✅ EIP-7939 Count leading zeros (CLZ) opcode ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ Página 7594 PeerDAS - Sampling de disponibilidad de datos de pares ✅ ✅ EIP-7823 Establecer límites superiores para MODEXP ✅ Página 7825 Transaction Gas Limit Cap ✅ Página 7883 ModExp aumenta los costes del gas ✅ Página 7917 Determinista proponente lookahead ✅ EIP-7918 Blob base fee bounded by execution cost ✅ EIP-7934 RLP Execution Block Size Limit ✅ Página 7939 Count leading zeros (CLZ) el código opcional ✅ EIP-7951 Precompile for secp256r1 Curve Support ✅ In summary, these are the key EIPs included in the Fusaka hard fork. While several improvements touch both consensus and execution clients—ranging from gas adjustments and opcode updates to new precompiles—the , which introduces peer-to-peer data availability sampling, enabling more efficient and decentralized handling of blob data across the network. major change of this upgrade is PeerDAS
