BGD. Technical analysis Aave <> Ethereum Fusaka (Osaka/Fulu) upgrade

Development
1

Summary

The Ethereum network is expected to be upgraded on ~December 3, 2025. The following is a technical analysis for the Aave community regarding these upcoming simultaneous upgrades: Osaka (execution layer) and Fulu (consensus layer), collectively known as Fusaka.

No technical impact is expected for Aave systems.


Changes

The following EIPs are included in the Fusaka upgrade:

In the following, we assess the impact of each EIP on Aave the protocol, and its users, focusing mainly on the EL (Execution Layer).


EIP-7594: PeerDAS - Peer Data Availability Sampling

Introduces new networking protocol that allows nodes to verify blob data availability through sampling rather than downloading complete blobs. Nodes store only assigned fractions of data while verifying total data availability.

Aave’s Layer 2 deployments may benefit significantly from increased blob capacity and reduced data availability costs. Only positive impact.


EIP-7823: Set upper bounds for MODEXP

Sets upper bounds on input sizes for the MODEXP precompile (modular exponentiation), which is used for cryptographic operations.

No protocol impact.


EIP-7883: MODEXP Gas Cost Increase

Adjusts gas pricing for the ModExp precompile to more accurately reflect computational complexity, raising the base cost from 200 to 500 gas and increasing costs for larger inputs.

No protocol impact.


EIP-7825: Transaction Gas Limit Cap

Implements transaction gas limit cap of 16,777,216 gas (2^24), preventing individual transactions from consuming excessive block gas. The goal is to ensure fairer access to block space and improve network stability.

This EIP could potentially be the most impactful on Aave, but all major Aave operations consume significantly less than ~16M gas, so it should have no direct impact.
However, it is recommended for integrators using complex flash loan operations or batch transactions to validate against the new limit. Extra care should be taken on governance proposals payloads to not consume gas more than the limit, but it is never the case with operational updates.


EIP-7917: Deterministic proposer lookahead

Consensus layer optimization that affects validator coordination, making Ethereum’s block proposer schedule completely predictable ahead of time.

No protocol impact.


EIP-7918: Blob base fee bounded by execution cost

This EIP Links blob fees to execution layer gas costs by establishing a proportional reserve price floor, preventing the blob fee market from becoming ineffective at 1 wei.

No protocol impact.


EIP-7934: RLP Execution Block Size Limit

Introduces a cap on the maximum RLP-encoded execution block size to 10MB to prevent network instability and denial-of-service attacks.

No protocol impact.


EIP-7939: Count leading zeros (CLZ) opcode

Adds a new CLZ (Count Leading Zeros) opcode to the EVM that efficiently counts the number of zero bits at the start of a 256-bit number.

No protocol impact, potential for future optimizations.


EIP-7951: Precompile for secp256r1 Curve Support

Adds native support for the secp256r1 (P-256) elliptic curve through a new precompiled contract. This allows Ethereum to verify signatures from devices like iPhones, Android phones, hardware wallets, and other systems that use this standard curve.

No protocol impact.


EIP-7642: eth/69 - History expiry and simpler receipts

An update to EL networking that handles receipts more efficiently and removes old data from sync, cutting sync bandwidth by around 530GB.

No protocol impact.


EIP-7892: Blob Parameter Only Hardforks

This EIP adds an easy way to tweak blob storage settings so Ethereum can adjust capacity more often as L2 demand changes, instead of waiting for a big upgrade.

No protocol impact.


EIP-7910: eth_config JSON-RPC Method

Adds a JSON-RPC method that describes the configuration of the current and next fork.

No protocol impact.


EIP-7935: Set default gas limit to 60M

This EIP recommends a new block gas limit from 36M to 60M and update execution layer client default configs.

No protocol impact.



Conclusion

To summarise, the Fusaka upgrade will be applied on Ethereum, with the following technical implications for Aave:

  • NO negative impact on any Aave infrastructure.
  • NO code changes are necessary.
  • The cost of using Aave instances on L2 (rollups) is expected to be slightly reduced.
  • With the 16M gas cap per tx introduced, integrators using large batch operations should be careful and validate/test against the new limit.

We encourage the community to use this thread if there are any questions of a technical nature about the topic.

As always, we are happy to see Ethereum’s roadmap progressing!

3 Likes