TL;DR
On Epoch number 269’568 and Slot number 8’626’176 the Ethereum network will be upgraded.
The following is a technical analysis for the Aave community regarding these upcoming and simultaneous upgrades: Cancun (execution layer) and Deneb (consensus layer).
No technical impact is expected for Aave systems.
Context
The Cancun/Deneb Ethereum upgrades are quite focused on infrastructure, with arguably the most important EIP being 4844, introducing Proto-Danksharding.
High-level, Proto-Danksharding adds data “blobs” to Ethereum blocks, to be used for example by rollups to submit their data in a highly efficient manner and lower cost compared to how they were doing until now (via calldata).
The main implication of this is that cost of rollups (e.g. fees on L2) will be highly reduced in minimum an order of magnitude, and potentially more.
In addition to 4844, different other EIPs are introduced, that even if not really impacting Aave, we will want to present to the community for the sake of visibility.
Implications for Aave
How does Cancun (execution) affects Aave?
Cancun is the execution component of this Ethereum upgrade, and with Aave being an application running on Ethereum, the one that could potentially have bigger consequences, even if it doesn’t have any negative this time.
Extensive overview of all EIPs can be found HERE for Cancun, but the following is a summary of them and implications for Aave:
EIP-1153 - New transient storage opcodes
AAVE IS NOT AFFECTED
New opcodes are introduced for variables to be used in the context of the same transaction, with same approach as it they were storage, but with cost closer to memory, as they are not persisted.
Being a new opcode, current Aave contracts deployed in production (compiled with versions not including the new opcode) don’t included transient instructions, and so there is no effect.
EIP-4788 - Addition of beacon block root accessible from the EVM
AAVE GOVERNANCE V3 OFF-CHAIN INFRASTRUCTURE NEEDS SMALL ADAPTATION
This addition allows for execution layer logic to use the beacon (consensus layer) tree root.
Aave on-chain logic doesn’t depend on consensus layer, so no effect.
However, on Aave Governance v3, the block hash of Ethereum is used for storage proofs on voting networks like Polygon or Avalanche. As now the block will have extra components, the off-chain libraries building these proofs will need to consider these new fields before inputting the data on the DataWarehouse contracts.
We will be adapting these libraries to make the transition seamless for the Aave Governance v3 system.
EIP-4844 - Proto-Danksharding
AAVE GOVERNANCE V3 OFF-CHAIN INFRASTRUCTURE NEEDS SMALL ADAPTATION
As commented before, the introduction of shard blobs will theoretically make way cheaper rollups (L2s) settling to L1 Ethereum.
This is only positive for Aave users on rollups, and highly probable increasing the user base on those. In addition, Aave benefits even more than other systems, as on rollups the user interactions with v3 can happen via functions on the custom L2Pool contract (on top of the standard Pool), which compresses calldata in the Aave layer itself.
Similar as with EIP-4788, the addition of two extra fields on the Ethereum block (blob_gas_used and excess_blob_gas) requires an update of the off-chain libraries building storage proofs on Governance v3, that we will get adapted.
Other infrastructural changes have no effect for Aave.
EIP-5656 - New MCOPY instruction
AAVE IS NOT AFFECTED
MCOPY is a new opcode introduced to make memory movement in a slightly more efficient manner.
Similar as with EIP-1153, being a new opcode, current Aave contracts deployed in production (compiled with versions not including the new opcode) don’t included transient instructions, and so there is no effect.
EIP-6780 - Only allowing SELFDESTRUCT in the same transaction
AAVE IS NOT AFFECTED
This EIP starts the deprecation of SELFDESTRUCT, an opcode historically considered as dangerous and adding more complexity than benefits.
For that, it changes important the behaviour of the opcode, specially by only allowing the same behaviour as before (deleting contract code post-deployment) only whenever the creation and destruction happen on the same transaction.
Aave doesn’t use this SELFDESTRUCT dynamics, so there is no effect.
EIP-7516 - New BLOBBASEFEE opcode
AAVE IS NOT AFFECTED
Minor EIP linked with 4844, to provide data of blob cost for roll-ups infrastructure. Doesn’t affect Aave anyhow.
How does Deneb (consensus) affects Aave?
Deneb is the consensus component of this Ethereum upgrade, and with Aave being an application running on Ethereum, it doesn’t have any direct impact, only indirect regarding assets listed like Ethereum Liquid Staking tokens.
The main EIP affecting quite indirectly Aave is EIP-7514. 7514 reduces the “churn limit” parameter to 8, which means that only 8 validators will be able to join the network on each epoch.
The goal of this is to limit the percentage of staked ETH versus the total, which in turn limits the issuance of ETH. On the estimations of 7514, this predicts a 50% staked ETH scenario on October 2024, compared with May 2024 estimation before.
On what concerns Aave, this means that the deposit pool of LSTs like stETH will take more time to be processed into validation. We recommend risk contributors of the community like @ChaosLabs to study the implications, even if they don’t seem significant.
Extensive overview of all EIPs can be found HERE for Deneb.
Conclusion
To summarise, the Cancun and Deneb upgrades will be applied on Ethereum, with the following technical implications for Aave:
- NO negative impact for any Aave infrastructure.
- Only some minor adaptations on off-chain libraries of Aave Governance v3 are required, given that new fields are added to the Ethereum block. We will be doing this on our side, with no proposal for the DAO required, being a purely technical and off-chain topic.
- Cost of using of Aave instances on L2 (rollups) is expected to decrease significantly. Aave’s v3 optimization for rollups (L2Pool) becomes even more significant.
We encourage the community to use this thread for if there is any question of technical nature about the topic.
We are happy to see Ethereum’s scalability roadmap progressing!