Summary
The Ethereum network will be upgraded in the coming weeks (scheduled for May 7, 2025).
The following is a technical analysis for the Aave community regarding these upcoming and simultaneous upgrades: Prague (execution layer) and Electra (consensus layer).
No technical impact is expected for Aave systems.
Changes
The following EIPs are included in the Pectra upgrade:
- EIP-2537: Precompile for BLS12-381 curve operations
- EIP-2935: Save historical block hashes in state
- EIP-6110: Supply validator deposits on chain
- EIP-7002: Execution layer triggerable exits
- EIP-7251: Increase the MAX_EFFECTIVE_BALANCE
- EIP-7549: Move committee index outside Attestation
- EIP-7623: Increase calldata cost
- EIP-7685: General purpose execution layer requests
- EIP-7691: Blob throughput increase
- EIP-7702: Set EOA account code
- EIP-7840: Add blob schedule to EL config files
In the following we asses the impact of each EIP on Aave the protocol, and it’s users, focusing on the EL (Execution Layer).
For the EIPs 7251, 6110, 7002, we recommend reading the LlamaRisk insights, and also the study by Chaos Labs about LSTs/LRTs impact due to changes on staking/slashing rules.
On this side, there are no direct effects for the Aave protocol, but some secondary implications regarding the aforementioned LSTs and LRTs.
EIP-2537
Introduces a precompile to perform BLS12-381 curve operations efficiently, which are crucial for BLS signature schemes used in Ethereum consensus.
While the introduction of the BLS12-381 curve operations could open up some interesting new opportunities for Aave, the addition itself has no impact on the system and its users.
EIP-2935
Restores the ability to retrieve historical block hashes beyond the last 256 blocks by storing them in the state as a ring buffer of 8192 hashes.
Aave does not currently rely on historic block hashes, also the upgrade is fully backwards compatible. Therefore, we expect no impact on the system and its users.
EIP-7549
An internal optimization to the attestation structure in the consensus layer.
This EIP does not affect Aave and the EL at large.
EIP-7623
Increases the gas cost of calldata and scenarios where calldata is considered DA.
This EIP could slightly increase gas for complex transactions. We don’t expect any meaningful impact for normal interactions, though.
EIP-7685
Provides a general-purpose mechanism for the consensus layer to request information from the execution layer.
Similar to EIP-6110, EIP-7002 and 7251 there might be some optimization potential for LSTs integrated into Aave. Aave itself will not be impacted by the change.
EIP-7691
Enhances the throughput of blob data introduced in EIP-4844 (proto-danksharding), enabling more efficient L2 data posting.
Aaves L2 deployments might benefit from even lower DA cost. It’s hard to accurately estimate the exact impact, though, as EIP-7623 might push some L2s to move from calldata to blobs for DA. We don’t expect any meaningful impact.
EIP-7702
This EIP will likely be the most impactful for users and the protocol.
With EIP-7702 the lines between contracts and EOAs are further blurred. EOAs from now on can temporarily become contracts by doing a delegatecall to externally deployed code.
While the protocol still contains some validations based on isContract they are only used for additional validation - there is no actual logic that branches based on an address being a contract or not. All Aave operations work, no matter the type of address they are interacting with.
While there is no impact on the protocol, so no high priority, it could be considered to follow the example of OpenZeppelin and remove all isContract calls in a future upgrade. They no longer provide much value, and the removal as a side effect makes the code EOF-compatible.
For users and interfaces, EIP-7702 opens up a wide area of possibilities. On the flipside, the new delegatecall pattern might open new attack vectors.
We can only urge developers on top of Aave (e.g., wallets) to act responsibly and users to be very cautious.
EIP-7840
Improves configurability for blob parameters by standardizing scheduling in the EL config files.
No protocol impact.
Conclusion
To summarise, the Prague and Electra upgrades 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 vary slightly, but overall be more stable. Rollups that rely on calldata will likely migrate to blobs.
We encourage the community to use this thread if there are any questions of technical nature about the topic.
We are glad to see Ethereum’s scalability roadmap progressing!