Thank you for the response. Some points for clarification, as the purpose of the risk analysis is to outline criticisms in the overall architecture and to provide clarity into how the system functions as a whole. The current state of the system is similar in the state of how both Optimism and Boba are currently implemented. Working fraud proofs and the decentralization of the Sequencer role are both technical challenges that are the main barriers to the system functioning in a decentralized way. We are aligned with the bedrock release of Optimism, which would introduce fraud proofs into Metis as well; the decentralization of the Sequencer will follow shortly after. As our technological innovation is to reduce gas costs below what Optimism and Boba currently costs, we still maintain similar security mechanisms as both those solutions, with a 1 of N trust model.
Pavel, can you post a list of all things that Metis has to complete in order to meet all AAVE requirements?
Currently, the understanding of the Metis community is that there are major problems that the Metis team has to solve. If this is not the case, please clarify it here.
You donât want your core followers and early adopters to feel concerned about all that. Instead, we should know that you are in control of everything. Currently, it doesnât look this way.
Letâs clarify this and keep on!
Thank you.
We have fulfilled all of the requirements listed for an AAVE proposal. The requirements for the AAVE proposal are listed by Marc Zeller in the previous post in this thread. We can launch the proposal at any time, but we would like to take the time to answer any questions.
Optimism, Boba, and Metis use the same core codebase, we have originated as a hardfork from Optimism. All 3 implementations do not have a working fraud proof mechanism currently. This means that you need to rely on the Sequencer to post the correct transaction data and if false data is posted, then network funds can potentially be at risk. Because of this, all 3 implementations currently have a trusted centralized Sequencer to post the requests.
One of Metisâ main focus has been the decentralization of the network, we have mentioned this within 2 of our roadmaps:
In order for Sequencer Rotation and fulfillment of data requests, working fraud proofs must be implemented, hence the current whitelisting for both. Working fraud proofs will be implemented in Q4 (our 2nd-half roadmap).
As a recap, we have described the security mechanisms of our architecture and the overall process flow, no criticisms for the overall architecture was mentioned. The implementation of the process flow relies on the fraud proofing mechanism, this mechanism does not currently exist for any Optimism-based projects (Optimism, Boba, Metis). After fraud proofing is implemented, the Sequencer rotation and the fulfillment of on-chain data requests will be implemented with it. We are as secure as both Optimism and Boba in the current stage, which have both passed the AAVE proposal for deployment.
Thank you Pavel!
This is a great response!
How long are you still going to leave it open for question before you submit the proposal?
Thank you for asking and appreciate the questions. We want to give it some more time and we will likely make an announcement within the coming weeks.
This is actually not true, as both Optimisms and Boba post data on-chain while Metis does not. This significantly changes the security assumptions, even with fraud proofs disabled.
The ability to bring data back on-chain is outlined in the architecture above, and we already have the ability to do so, which is currently whitelisted until fraud proofs are enabled.
In the scenario that transaction data is not supplied, all participants will know that the transaction data cannot be downloaded and it will be automatically flagged as a security concern of the associated states, See insecure transaction state. Since the request is attributed to the Sequencer that initially posted it, they can be punished if the data is not provided on-chain within a set amount of time (currently 24 hours).
Please let me know the scenario that you are referring to that changes the security assumptions, since everything can be attributed to the Sequencer and all you need is 1 honest Verifier to secure the network, even in the case that data is not available.
If the outcome is the same currently, in this case, the inability to act upon invalid state roots and the architecture holds the 1 of N trust model, then we currently have the same security as both Boba and Optimism.
@psinelnikov letâs go with the proposal and voting!
The Marathon + AAVE + positive sentiment in markets will bring a great combination.
What else are we waiting for? It looks like there are no more questions and everything is all clear for voting. Or?
Can you provide a link to the deployed source code (and not to the documentation) of such punishment mechanism ?
The goal of all the efforts at l2beat is to provide transparency, not judgement. We are trying to make sure that projects are honest about their claims, they verify source code of the deployed contracts so that others can audit them, they make sure that there is no discrepancy between whitepaper / documentation and the deployed code. Ultimately users should be aware of the security assumptions of the given scaling solutions. We are not trying to pick sides or winners. Is there anything specific that we said that you found factually incorrect ?
I am concerned by the lack of real community engagement here. At the moment, it seems the excitement and support @MarcZeller outlines in his comment is lacking.
Many of these original commentators are brand new accounts with very little substance. The discussion was fragmented and reignited in August; its state is not indicative of community enthusiasm
The Metis team is welcome to proceed to Snapshot but feels a bit ambitious. It seems there is more support and education needed for voters to better evaluate this proposal.
@psinelnikov, I do not quite agree with @fig, but he is right that not too much is happening here.
It really looks strange. Pavel, can you once and for all share what your plan is. Please be more specific, because the vagueness hurts Metis, of which I am a big supporter.
We want to hear a clear plan:
1.
2.
3âŚ
and timeline.
Or at least be sincere and share with the community whether you are postponing it for a later stage.
Something specific, please. Currently, it is not enough. Thank you very much!
Hello AAVE community. This is Peter from Metis and one of the cofounders. My team made me aware of this post and some questions from supporters. First of all, thank you Pavel for helping answer the concerns and questions. Pavel is very knowledgeable about what we want to achieve and the inner workings of L2. I think he has provided enough material to the community for everyone to get an idea of our approach to provide enterprise level fee structure while minimizing the additional security assumptions.
But the I saw there are some specific implementation questions, which I will help to answer.
First all, @l2beat when we chat about this, I recall I also highlighted that we are aware of the lack of punishment because currently the fraud proof is disabled. Without punishment, it is also dangerous to enable the sequencer rotation and open it to public. thus we have been delaying to release the sequencer rotation.
As for why we stopped adding rotation code to the existing contract, it is simply because our partners are all hoping we can move to the bedrock architecture as well. Moving into that architecture is a lot of additional work for us because we have changed quite a lot based on the optimismâs code. yes we have also done a large number of geth changes, which we are trying to minimize in the same spirit of bedrock architecture. For this transition to happen, we also need to reevaluate the smart contracts especially the one relate to the transaction commits.
I always want to point out every time when people say metis doesnât upload any transaction data to l1, it is not entirely true. We submitted all the transaction metadata info such as timestamp, l1 block number and etc along with a computer merkletree root of all call data in the batch. If Metis truly doesnât upload any transaction data at all, the price would be even cheaper. And I also made very clear in multiple occasions that I simply donât like the idea of having data availability committee.
But with fraud proof disabled, it is factually wrong to claim Metis security assumption difference is significant compared to the current state of other optimismâs chains. Because as soon as the sequencer, which currently is a trusted entity, does not make the data available offline, the verifiers who are constantly checking and reporting verified blocks will immediately flag the issue and report to the community. This is exactly the same as optimismâs sequencer submitting fabricated transaction and state roots. Because the fraud proof is disabled, there isnât a punishment implemented on chain yet. However, we are all honest entities. Optimism has 2b TVL. Metis at one point also had 800M TVL. Both of us have very strong track record of being honest. Both of our goal is to promote adoption of ethereum, while Metisâs goal is more on the enterprise side and optimismâs is more general. IMHO, I failed to find facts to support your claim.
Finally, I saw a community member asking for roadmap. We tried to provide roadmap every 6 months. And I have explained the reasons of the delay earlier. However, I want to point out that we are working on some very challenging stuff, including the recent zkp effort, that is being developed in the open. We can only give a very high level roadmap. There are many different challenges that we face everyday when we progress through the tasks. I believe people that worked on the blockchain core infrastructure code understand what I mean. so please bear with us with some vagueness. Cuz it is very hard to make promises until itâs close to the release. If you look at our history, when we actually announce the dates, we honor them very well.
Sorry for the long notes. I do feel guilty not reaching out to aave community earlier. But as a tech guy, most of my time is spent on tech development. But I hope it will help aave community to understand who Metis is, what mission we are on and why we made certain decisions.
Ciao
Hey @Peter88 , thank you very much for your candid answers.
As we have stated before, our goal at l2beat is to provide transparency. While it is fine to say that Metis ** will support Sequencer rotation as part of the roadmap, we believe it is not ok to claim - as could be read from @psinelnikov post, that this functionality is already implemented and deployed.
We understand that virtually all Rollups have training wheels and we still - as the community - have a long way to go. Today the main difference between Metis and Optimism/Boba is that Metis is not posting tx data on-chain. There was a lot of community discussions how much this reduces the security of the system.
The main difference between posting and not posting data comes down to the ability of independent observers to verify if posted state root is correct. If data is posted, anyone can verify the state root. If data is not posted the state of the system is simply unknown. This is a fundamental difference that changes how fraud proofs should be designed and eventually deployed.
Thank you for the response @l2beat . Fully understood the concern. but in the current metis setup, any independent observer can also monitor the transaction data submission to memolabâs storage. There is no gate. Itâs just that people need to run the verifier dtl to do so. And this open source program will automatically flag if data is missing or the data does not match the commit on l1. anyone can do it. There is no whitelisting.
If the concern is that people run a program, instead of directly looking at etherscan, I admit that it is a difference. But IMHO, not a significant one. I appreciate the discussion which I believe will give AAVE community more confidence in Metis.
Thanks
That is obviously not a concern. The concern is that if data is missing from MEMO, then independent users donât really know what to do. In case of Optimism/Boba they can prove that state root is invalid and notify community that fraud is happening. The community has 7 days to react using whatever social means they have at hand. In case of Metis, all users can do is to complain that - according to them - data is missing in MEMO w/out knowing if posted state root is valid or not.
As Pavel mentioned earlier, we treat missing data availability the same as invalid state root. They donât need to prove whether the state riot is indeed invalid or not. Because the trusted sequencer will not and should not submit the state roots without making sure the data is available on MEMO. The community will be notified and the rest is the same as other op-based chains.
In the future when we have the punishment implemented and deployed, the unfulfilled data availability request will allow verifiers to always win the fraud proof challenge. We do have a version of data availability request deployed barring the punishment. Though the code is subject to change in light of the bedrock transition, you may notice that the verifier can actually provide the data when the grave period of the data availability request expires. It is in the same line of thoughts as the eventual punishment mechanism.
Hope it helps clarifying things.
Hi dnm, thank you for reaching out. We are continuing to answer questions from the AAVE community to make sure we address all of them before the vote. Thank you for your patience.