Launch Aave V3 on Metis

Governance New Market
1

Launch Aave V3 on Metis Andromeda

Summary

Proposal for the deployment of Aave V3 on Metis Andromeda Mainnet.

Proposal

Founded in 2019, Metis launched its Layer 2 mainnet on November 19, 2021. We are building a hub for the entire Web3 economy in 3 stages: Layer 2 Ethereum scaling solution with fast and cheap transactions; no-code integration via a middleware layer powered by smart contract templates; and a Decentralized Autonomous Company (DAC) infrastructure enabling both blockchain and Web2 companies to build decentralized businesses on-chain, with all the functionalities of real-world enterprises and all the security and decentralization of Ethereum.

A mere eight weeks after launching Andromeda mainnet, Metis TVL surpassed the majority of its competitors, surging to the #3 spot as measured by L2Beat and reaching $500M+ TVL. As the fastest growing L2, Metis has taken the blockchain world by storm with its Optimistic Rollup technology, EVM-Equivalence, and incredible mutually-incentivized ecosystem. With a robust and secure infrastructure, a self-deployed Graph node, multiple oracle providers, on-chain explorers, and a dedicated integrations team ready to assist throughout every step of the porting process, Metis is ready for Aave integration.

Metis envisions and supports a multichain future and seeks to invite Aave to expand its own mission of creating a multichain future, by having Aave enable the Aave V3 front-end for Metis markets. Our robust and enterprise-grade network has a burgeoning DeFi ecosystem, and while there are borrowing/lending capabilities currently available, having a Flagship protocol like Aave would be incredibly valuable to our ecosystem, while fulfilling Aave’s multichain expansion. As well, there are many benefits Aave users and the DAO at large would benefit from.

Metis’ commitment to a decentralized future is built into its very structure, including the ethos of creating a sustainable and mutually beneficial ecosystem where its partners are set up to thrive. This is best exemplified by Metis’ Builder Mining Program. This program allows all DApps deployed on Andromeda to directly participate in the revenue Metis generates. For example: if Aave deployed on Andromeda, 30% of the fees accrued from every single transaction occurring through Aave would be kicked back directly back to Aave, in perpetuity.

The mission at Metis is to provide the infrastructure and incentive system to make deployment on our network a no-brainer. This additional revenue will be going to the Aave DAO’s treasury and as such, will be able to be utilized as seen fit by the Aave community at large.

Metis also has some of the fastest transactions in blockchain, often executing faster than your web browser can process them, and always executing faster than MetaMask can record them. Transactions on our Layer 2 network currently cost about $2-$3, considerably less than the gas fees on Layer 1 Ethereum. Metis will launch its own storage layer by the end of Q1 2022, which will enable cheap, secure storage of NFTs and other large blocks of data, while doubling as an additional scalability layer; as a result, transaction fees will drop to just cents by the end of Q1 2022.

The traction earned by our popular DeFi protocols are great case studies to the adoption and eagerness of the Metis community to engage with our DeFi ecosystem. Netswap, the first ever native Layer 2 DEX, surpassed $1B in trading volume in its first month of operation. Likewise, popular yield optimization protocols Beefy Finance and Pickle Finance have achieved great success since integrating and launching their protocols on Andromeda.

Metis is open and willing to work with Aave to determine the optimal strategy for liquidity incentivization, marketing and awareness campaigns, and additional benefits to bring to its users. We are considering the options of qualifying airdrops for interaction with the protocol on Andromeda and building Reputation Power (allowing for future whitelisting opportunities) for Aave holders voting on this proposal. We will also offer Aave the opportunity to set up a Verifier node for the Metis Layer 2 network, providing a steady stream of income to the Aave DAO in perpetuity and aligning incentives for the future decentralization and wellbeing of the Metis network.

Metis is ready to onboard Aave to its ecosystem and looks forward to the opportunity to build a long-term, sustainable, and mutually-beneficial relationship.

18 Likes
3

Will be great for both Aave & Metis community

4 Likes
4

This is a must for all parties!! Metis + AAVE = unstoppable

4 Likes
5

I would like to see it, Metis is up and coming nicely.

1 Like
6

Metis has a great future so it will be good for both Metis and Aave

1 Like
7

Wise choice! Exciting for both parties for sure! :slight_smile:

1 Like
8

Metis as a big promise, all would benefit from this

1 Like
9

The perfect partnership .

1 Like
10

Metis shutdown with very little notice today. Not decentralised at all. Why are we going to such a small chain that’s centralised when there are other chains to go on first?

1 Like
11

Metis abruptly ceased operations today. Its Not decentralised at all.

12

Not decentralised in any way!!!

13

I agree. A network shutdown is a huge issue. I don’t think it’s worth the risk.

1 Like
14

Agree. I thought this was a good idea originally but a network shutdown is a big deal. I don’t think we should take the risk.

1 Like
15

Highly agreed on this!!!

16

is this some kind of a joke? The entire metis chain just stopped itself today giving users only 30 mins of notice. What kind of a chain does this? They are still to publish any kind of explaination on why they had to do this. Is AAVE going to take responsibility for loss of user funds? And why are we not prioritizing so many other chains that are far more battle tested?

1 Like
17

Almost 24 hours and no explaination of why Metis had to make an emergency upgrade. They posted a BS explainer about why the system went down (they had only one sequencer!) but no explainer as to why they had to push an upgrade at almost no notice. This is crazy stuff and not even Solana did this. This proposal is nonsense.

1 Like
19

Metis Bridge ETH to Metis Andromeda

There was a upgrade of the network on February 3rd 2022 due to a bug in the Optimism’s codebase found by a whitehat hacker:

This exploit was revealed to us and was quickly patched:

To improve network stability, Metis performed a scheduled upgrade on August 15, 2022:

20

reviving this thread as Metis just got Chainlink price feeds.

price feeds were technically required to proceed with this onboarding proposal.

if the community agrees to proceed to the snapshot phase of this deployment.

please consider the governance guideline for new chains deployments :

  • vote should start at least 24h after publication of the snapshot vote
  • vote should last at least 3 days (I would recommend at least 7 as summer is lower activity)
  • vote should have at least 3 options (YAE/NAE/ABSTAIN)

quorum for new chains deployment is currently set at 150k YAE votes.

3 Likes
21

Bridge Security

As there have been more cross-chain bridge attacks, we would like to post an overview to the Metis Smart L2 mechanism and outline more details and security processes in the system.

The Metis Bridge is a Natively Verified bridge, which means that it is secured by the native Smart L2 protocol. This means that there are no multisigs or external validators present that could compromise the security of the bridge. The Metis bridge does have a set withdrawal time of 7 days as it is verified Optimistically.

Comparison and Differences to other Rollups

Currently, both Optimism and Boba have similar security mechanisms as Metis. The key difference between the implementations is that the Metis Smart L2 mechanism stores the transaction batch data off-chain, but may bring the data on-chain at any time to execute a fraud proof. The off-chain data component is the actual transaction data and is posted by the Sequencer in the Memolabs decentralized storage, similar to IPFS. Transaction data can also be accessed by the Peer Network. If the Sequencer does not post the Transaction batch data to Memolabs, then a Verifier can request that the transaction data that the Sequencer has attested can be posted on-chain.

In any case, there are mechanisms in place to access the transaction batch data, bring it back on chain, and execute the fraud proofing process. If the transaction data cannot be brought on-chain, since the Sequencer has attested the transaction data that they submitted, then the batch can be invalidated and the Sequencer can be punished for not bringing it on-chain.

How do you deal with the Data Availability Problem / Speaker-Listener Dilemma?

Game Theory Mechanics

Both the Sequencers and Verifiers benefit from acting in the best interest of the network. The Sequencer would retain the fees that they would make from processing the transactions normally without withholding data. The Verifiers would benefit by not losing money for making needless data requests. Based on these mechanics, there is no direct guaranteed incentive by attacking the network.

Griefing

Griefing is the process of needlessly requesting data to be on-chain. It is done as a malicious action towards the Verifier or the Sequencer, where both parties lose monetary value.

If the Sequencer is griefing data requests to the Verifiers

This occurs when the Sequencer does not submit data to Memolabs and the Peer Network transaction data does not match what was posted on Layer 1. Since data is not available and cannot be retrieved, the only way to do so would be to request the data directly from the Sequencer. If the Sequencer provides it, and it turns out to be valid, then no direct punishment can occur.

This is an attack vector and can affect network security since the Sequencer can force all Verifiers to pay for transaction data to needlessly be brought on-chain. In the case when there are no Verifiers remaining because of attrition (fees), the Sequencer can submit a falsified Merkle Tree State Root (MTSR) and withdraw funds from the network after the 7-day withdrawal period. There are 2 flows to prevent this from happening:

The Rotation Flow

  • The Sequencer checks if it is selected by Layer 1 for the current rotation;
    • If the Sequencer is the current selected Sequencer:
      • The Sequencer continues with the regular flow, in this case they download the transaction data from the Peer Network.
    • If the Sequencer is NOT the current selected Sequencer:
      • The Sequencer waits for the selection into the next slot on Layer 1.

The Governance Flow

  • A proposal is submitted to the Governance Protocol to remove the Sequencer;
  • The affected Verifiers can get compensated for any lost transaction fees through the data requests made by the Sequencer;
  • If the Governance Protocol succeeds, the Sequencer gets removed from the Sequencer pool. The Sequencer will also lose a portion of their funds that are present in Layer 1 to pay for the affected data requests that the Verifiers made;
  • A Sequencer rotation is executed.

Using a rotated Sequencer would enable network resilience, as the Sequencer has a limited amount of transactions that it can process per slot. Because of the automatic Sequencer rotation, the damage that a single Sequencer can produce is minimized per slot. In combination with the Protocol Governance, the malicious Sequencer can be manually removed from the Sequencer Pool to prevent further damage to the network.

If the Verifier is griefing data requests to the Sequencer

This occurs when the data is present on Memolabs or the Peer Network transaction data matches what was posted on Layer 1, but the needless request is sent to the Sequencer for execution. This is significantly less serious than a griefing attack done by the Sequencer, as it only affects the efficiency of the network. This griefing attack does NOT affect the security of the network and the worst-case scenario is that there would no longer be any Sequencers on the network to process transactions, halting the network and freezing the funds until a new Sequencer is rotated. Since this only affects the efficiency of the platform, a governance flow is included to prevent this attack:

  • A proposal is submitted to the Governance Protocol to remove the Verifier;
  • The Sequencer can get compensated by any lost transaction fees through the data requests made by the Verifier.
  • The Verifier gets banned from making requests to the Sequencer. The Verifier will also lose any funds that are present in Layer 1. There is no rotation needed since other Verifiers work asynchronously.

Diagram

Metis Smart L2 Flowchart
Metis Smart L2 Flowchart1920Ă—1544 93.8 KB

For additional process descriptions, please see the Metis Documentation

1 Like
22

l2beat would like to add few points of consideration to the discussion:

Bridge Security

Right now, similarly to Optimism and Boba, bridge is not secured at all as fraud proofs are not deployed since the upgrade from OVM 1.0. So it is strictly not true that the bride is “natively verified”. We are looking forward to Optimism, Boba and Metis to deploy fraud proof mechanism in near future so that the bridge is not secured solely by the centralised Sequencer. Until then, end users - if they spot erroneous L2 state root commit to L1 - have 7 days to alert the community with no ability to challenge Sequencer.

Data Availability Problem

Metis, as of April 2022, is not posting transaction data to the Ethereum chain. The mechanism, as described in the documentation, that will allow Validators to request data from Sequencer, is not yet fully implemented. Again, we are looking forward to the final implementation to fully assess the severity of the grieving problem that such constructions suffer from. Having said that, in general, Ethereum community regards grieving problem as unsolvable and the ultimate security, in the worst case scenario where Sequencer is grieving Validators, falls back to the Governance that would need to boot out malicious Sequencer. The ultimate fallback to Governance is acknowledged by Metis themselves.

Sequencer Rotation

We would like to ask Metis team to point out the exact code that implements Sequencer Rotation and other mechanism mentioned in the documentation. Currently deployed system does not seem to implement this mechanism and there is only one Sequencer (0xcDf02971871B7736874E20B8487c019D28090019) that is whitelisted to post transaction batches.

System Validators

Metis relies on Data Availability Validators so that potentially malicious Sequencer can be challenge, if data is withheld, however right now there is only one address (0x48fE1f85ff8Ad9D088863A42Af54d06a1328cF21) that is whitelisted to perform such challenge. Our understanding is that ultimately this functionality will be permissionless and open to everyone, in the meantime end users have to fully trust Sequencer that it posts data to external data store. This is in stark contrast to Optimism and Boba that post data on-chain and even though there is no fraud proof mechanism implemented, users can always verify the state by re-executing posted L2 transaction batches and they have 7 days to alert the community if anything malicious was going on. With Metis, as it stands, if data is not posted to MEMO, there is no way to know for end users if L2 state root is correct or not so - in a way - any potential fraud might go undetected in practice.

Summary

We are very much looking forward for the Metis team to fully implement all the mechanisms described in their blog posts and documentation so that full assessment of the security of their proposed architecture can be performed. Until then, in our opinion, Metis users have to fully trust that Sequencer is honest.

Disclaimer

Above assessment is derived purely from the analysis of deployed smart contracts listed in Metis Andromeda – L2BEAT. These contracts were deployed in April 2022. If this list is inaccurate and Metis was recently upgraded to new implementation that we are unaware of, we are more than happy to change the current risk profile, however the only change that we have observed was the recent change of the Metis Manager from EOA address 0xDD6FFC7D9a4Fb420b637747edc6456340d12d377 to the Gnosis Safe 0x48fE1f85ff8Ad9D088863A42Af54d06a1328cF21

1 Like