As is well known throughout the Ethereum community, for a long time the teams involved in the Ethereum consensus and execution layers have been working on what is actually considered the next phase of the Ethereum network: transitioning from proof-of-consensus to computational power-based consensus mechanisms ; A proof-of-stake mechanism based on block verification involving ETH pledges.

Launched in December 2020, the so-called Beacon Chain represents a new consensus layer to be used on Ethereum Proof-of-Stake, allowing depositing (staking) ETH to participate in the new block validation model. So far, this layer has been run independently of the ethereum mainnet as a way of testing such a critical system over time.

Merge actually connects the running beacon chain to the Ethereum mainnet, replacing the current proof-of-work mechanism for validating blocks. It will consist of 2 Ethereum upgrades: Bellatrix, which affects the beacon chain; and Paris, which affects the execution layer currently processing Ethereum transactions, so from Aave's perspective, this is the most important.

secondary title

How will the Merge/Paris upgrade affect Aave?

Even though important from a high-level perspective of the Ethereum network, the Merge/Paris upgrade should have a minor impact on the Aave system and no immediate action is required. This is because the upgrade is designed to be as least disruptive as possible for applications running on Ethereum.

Regarding differences that may affect Aave:

AAVE is not affected. In general, upgrades preserve all previous fields on block headers, but the Aave smart contract currently does not really depend on the structure of block headers, as techniques such as proof-of-storage are not used.

Only AAVE governance is slightly affected. In practice, the duration of block slots becomes shorter, from a variable time of about 13.5 seconds to a fixed time of 12 seconds (except for lost blocks, which should only happen 1% of the time). Aave systems, like liquidity pools, don't do calculations based on blocks, but in seconds, so they won't be affected. However, certain governance parameters such as voting duration are defined in blocks, so in practice they will be slightly shorter. This will result in a little under 3 days for main voting and a little under 1 day for queues. We don't think this is an immediate issue, but we recommend that the community re-evaluate these parameters to accommodate 12 second block slot times.

AAVE is not affected. Only the block hash and difficulty are affected, but the Aave smart contract does not depend on these.

AAVE is not affected. The Aave smart contract does not have a random running mechanism.

AAVE may be slightly affected, but not by smart contracts. 2 new states have been introduced in the "confirmation" lifecycle of proposals. This may break some of Aave's off-chain infrastructure (such as Aave's decentralized UI), but we hope that the Web3 library will abstract this behavior, maintaining full backwards compatibility.

secondary title

But what if the Ethereum chain had a fork?

Given the importance and change in the Ethereum consensus layer paradigm, there have been some rumors circulating about a potential fork of The Merge to keep parallel Ethereum and proof-of-work consensus running.

There isn’t much substance to this fork, so in practice, the merge should happen like any other Ethereum upgrade before it. The aspects that support the transparent transition of Aave and Ethereum to the proof-of-stake application layer (and only exist) are:

1. From the perspective of an application layer like Aave, The Merge is just another update similar to Gray Glacier, or any other previous update. The consensus layer does change, which is an important paradigm shift, but there isn't much reason to think that the proof-of-work ethereum fork will get more attention and be considered the norm than proof-of-stake.

2. The Aave protocol does not exist completely in isolation on a network like Ethereum, it communicates with other systems such as listed assets, other liquidity venues (such as DEX), oracle systems (such as Chainlink), wallets provide Merchant etc. We have confirmed with Chainlink and their stance will naturally align with Ethereum Proof-of-Stake, the same as other liquidity venues such as Parawap. The Aave system cannot really function without any external liquidity and functional oracles.

3. The Beacon chain, even if it is not connected to the consensus layer of Ethereum, has been actively running for nearly 2 years. There are tens of thousands of validators, and even brand new products and systems based on future proof-of-stake, such as Lido and their stETH assets.

4. All the major Ethereum node clients (and new clients) with a long history are preparing their software for The Merge, so the movement to run an outdated version of the software to gain major traction seems unnatural.

5. Centralized stablecoin issuers are expected to fully support The Merge transition. On Aave v2 Ethereum, this includes USDC, USDT, TUSD, BUSD, PAX, GUSD, and USDP.

6. There are other assets (specifically listed on Aave v2 Ethereum) that do not have any immediate reason to exist on upgraded non-proof-of-stake Ethereum. This includes DAI, WBTC, and most other assets generally listed on Aave v2 Ethereum, considering that in addition to assets, the entire system is built on top of them (e.g. governance). Specifically stETH, of which ~$1.4B is held on Aave, and was created around Ethereum's transition to Proof-of-Stake and its staking mechanism.

7. Aave has supported (and received support for) the Ethereum ecosystem since its inception in Aave v1. The Aave community and ethos have significant overlap with Ethereum. It seems natural to follow an approach that supports the direction of the Ethereum community.

in conclusion

in conclusion

The merger is scheduled to go through its final stages next week, with the Bellatrix and Paris upgrades taking place on the Goerli testnet.

Soon after, The Merge will take place on the Ethereum mainnet, according to the analysis:

1. Smart contracts related to the liquidity agreement will not be affected.

2. Aave governance voting and queuing duration will be slightly lower than 3 days and 1 day, it can be updated in one of the upcoming governance proposals, but it doesn't matter.

3. Aave UI may (but should not) need some minor adjustments.

4. As always, Aave will only work properly on the adopted majority chain, in this case, Ethereum PoS (chainId == 1). Therefore, any potential forks should be ignored initially.

5. The Aave decentralized UI should only be regarded as the Ethereum mainnet, which is the merged Ethereum Proof of Stake. If any user decides to directly interact with the Aave smart contract on any fork, it is their own responsibility.

6. There may be more volatility and bridging activity between Ethereum. This topic should be further evaluated by other entities working with the community, such as Gauntlet. BGD will monitor the situation as any technical response is required (e.g. through governance proposals).