TL;DR
Technical analysis for the Aave community on why the upcoming Ethereum Shanghai/Capella network upgrade should NOT AFFECT Aave systems.
Shanghai? Capella? Two hard forks?
Since the Merge, technically the Ethereum network operates in 2 different layers: consensus, dealing with block validation via staking; and execution, dealing with the logic execution on the EVM.
Consequently, network upgrades from now on are planned to be, even if frequently grouped, in pairs of one upgrade for the consensus layer (in this case Capella), and another for execution (in this case Shanghai).
Shanghai and Capella are planned to happen at the same time.
How does Capella (consensus) affect Aave?
The Aave protocol is technically software (smart contracts) running in the EVM. Therefore, upgrades of the network on the consensus layer usually affect way less than on the execution layer.
Capella introduces a really significant general change for Ethereum post-merge: enabling withdrawals of ETH staked for validation. But as we could say that staked ETH at the moment lives completely isolated from the EVM for practical purposes, this doesn’t really have any technical impact on Aave.
However, apart from being just pure software, the Aave protocol also deals with assets representing staked ETH on the EVM, like stETH (and wstETH), cbETH, or rETH. So we have checked with the respective teams behind those assets (Lido, Coinbase, Rocket Pool) and these are the conclusions.
stETH (Lido)
An upgrade is planned for the stETH smart contract, but the Lido team has confirmed to us that there should not be any breaking affecting the Aave protocol, and its astETH aToken on Aave v2 Ethereum.
wstETH listed on Aave v3 Ethereum is an immutable smart contract, so there will be no impact.
cbETH (Coinbase)
No upgrade is expected on cbETH, as confirmed to us by Coinbase.
rETH (Rocket Pool)
The Rocket Pool network will go through an infrastructural update in order to support withdrawals, but this will not affect the rETH token.
From a pricing perspective, it is expected that all ETH LSTs will have a way more solid profile, given that the primary market will be completely bi-directional (stake & withdrawals).
Additionally, we encourage the community to check out the complementary and extensive risk analysis by @Pauljlei (Gauntlet), as an authorized voice on the topic.
How does Shanghai (execution) affect Aave?
The network upgrade of the execution layer, includes as usual multiple EIPs, in this case, with no impact on the Aave protocol, as they are focused on EVM optimizations and better structuring of bytecode.
To be more specific, the following is a summary of the EIPs included in Shanghai, together with a rationale on why they should not affect Aave.
New EVM Object format
Not an EIP itself, but a group of them, all of them surrounding the introduction of EOF (Ethereum Object Format) contracts.
Currently, on deployment time, bytecode of smart contracts is not structured and the validation of its correctness boils down to the node client executing certain static analyses.
This group of EIPs introduced certain structure and separation between logic and data of deployed smart contracts, in order to simplify logic on node clients, and other advantages like reducing complexity of adding/removing new features in further updates.
AAVE IS NOT AFFECTED by any of these EIPS, as only newly deployed contracts will respect EOF.
Basic definition and implementation of the EOF contracts, as explained before, introducing validations of new contracts respecting the EOF structure, together with logic/data separation.
Extra validations of bytecode, in this case validating the opcodes are correct, not only the EOF structure validated on EIP-3540.
Adding new “jump” opcodes, that compilers will able to use to optimize gas cost.
Adding the concept of “sections” within the bytecode, introducing new opcodes to move from/to them, and deprecating (not affecting any deployed contract) other opcodes
Additional validations for EOF contracts, in this case preventing under/overflows of stack, which will allow node clients to simplify its logic.
Additional EIPS
EIP-3651. Warm COINBASE
Minor gas improvement, adding the COINBASE address (the one receiving rewards of including a block) to the list of those who start “warm” at the beginning of a transaction, cheaper to read from.
AAVE IS NOT AFFECTED as there is no usage of COINBASE.
EIP-3855: PUSH0 instruction
Adding a new opcode to push the value 0 into the EVM stack, a quite common use case, making it cheaper gas-wise.
AAVE IS NOT AFFECTED as this doesn’t affect running contracts, it will just make more efficient those deployed post-upgrade.
EIP-3860: Limit and meter initcode
Adding size (in bytes) and gas limits to initcode (contract constructor) to make stricter its validation.
AAVE IS NOT AFFECTED as this doesn’t affect running contracts, it will just make more efficient those deployed post-upgrade.
EIP-4895: Beacon chain push withdrawals as operations
Adding a system-level operation for staked ETH withdrawals, which in practice will allow the increase of ETH balance on accounts.
AAVE IS NOT AFFECTED as there is no hard dependency on ETH balance assumptions on its smart contracts.
Conclusion
From a technical perspective, the Aave smart contracts will not be affected by Shanghai/Capella, we will only keep monitoring the programmed upgrades of the ETH LSTs (stETH/cbETH/rETH) systems to avoid any unexpected behavior.
Liquidity implications post-withdrawals activation is something on which the risk providers of the community should comment, but from our perspective, this should only increase the strength of LSTs.
Props to all Ethereum core teams/developers to keep the highest standards of quality on both execution and communication around network upgrades and Tim Beiko for the valuable AllCoreDevs recaps