Dialogue with Arbitrum researchers: How to decentralize Rollup?

Introduction

When we look at the vision and roadmap of various rollup solutions, we will find that almost all rollups have an ultimate goal. If this goal is condensed into one sentence: build a technology stack, provide it to the community, solve The expansion of the blockchain, and ultimately the decentralization of the technology stack of operations and governance. This leads to the term decentralized rollup.

So what exactly is decentralization? What is the division of labor between the various parts of the Rollup system? Does decentralization mean maximizing system operation participants? What impact will a centralized sorter have? How should the shared orderer and L2 local consensus be designed? What is the function of the unique prover in ZK-Rollup? What would an open decentralized prover network look like? Why do we need zk hardware acceleration? What is the solution to the data availability problem? ....

There are endless discussions around decentralized Rollup in the community, so ECN curated a series of podcast interviews with the theme of "Decentralized Rollup", and invited outstanding founders and researchers in this field to talk about their understanding of decentralized Rollup. understanding.

The first issue invited Patrick McCorry, a researcher from the Arbitrum Foundation. This episode serves as a summary of the series, mainly talking about the problems that Layer2 wants to solve, the meaning of decentralized rollup, how to understand its security attributes, and how DAO governance It works in decentralized rollup.

This episode's guest: Patrick McCorry, twitter @stonecoldpat0

Moderator: Franci, twitter@FrancixDeng

Trailer

Phase 2: Shared Sequencer and L2 Consensus

Yao Qi, founder of AltLayer Network

Scroll Researcher Toghrul Maharramov

StarkNet Exploration Lead Abdelhamid Bakhta

Issue 3: Prover network and zk hardware acceleration

Scroll co-founder Ye Zhang

Cysic co-founder Leo Fan

Issue 4: Data Availability and Decentralized Storage

Qi Zhou, founder of EthStorage

Listen

Click to subscribe to the podcast to learn more:

Youtube：

Microcosm:

Timestamp

• 01:49 Patrick McCorry's personal background introduction

• 03:26 Why is there layer2 and what is it trying to solve?

• 11:56 What weapons are they using to keep users safe?

• 14:40 What does the safety and liveness of Rollup mean

• 17:47 Explain the security of rollup from data availability, state transition validity and anti-censorship

• 19:45 The role of the single honest entity, who acts as the rollup single honest entity?

• 28:47 What do you think of decentralized rollup? What is the most pressing goal at the moment?

• 37:21 The importance of DAO governance in a decentralized rollup

Interview section

Problems Layer2 wants to solve

Franci: What we're going to explore in this episode is what does it mean to have a decentralized rollup? why is it important What problem are they trying to solve? I hope that through this talk, readers and listeners can finally understand what a real decentralized rollup is and what goals they should meet. Let our guest, Patrick McCorry, introduce himself.

Patrick: Hello everyone. I think from experience, I am biased towards academic research. From 2013 to 2016, my doctoral direction was related to Bitcoin and Ethereum. Then from 2016 to around 2019, I was a researcher in universities like UCL, King's College London and UIUC. During this time, I've been very interested in Layer 2 protocols. Including Bitcoin Lightning Network, plasma, and of course rollup. So in 2019, I tried to do a startup. Then I left college, my friend and I, basically two people and a dog. We are trying to be a startup company focused on layer2. But it was a bear market, and then we were acquired by Infura. Then I left Infura and recently I joined the Arbitrum Foundation. So I went back to focusing on rollup research full-time. During this entire period, I have mainly focused on education, explaining why we should care about layer2 protocols.

Franci: Let's start with the most basic topics. In general, what is an L2 system? What does it mean when a user deposits money into the L2 system and makes a transaction there?

Patrick: Talking about this issue, I think we need to take a step back and think, what is the point of blockchain? What's the point of all these systems we're trying to build? Once we account for this, it makes a little more sense to explain L2. The real thing behind a blockchain network like Bitcoin or Ethereum is just a database. is a public database that anyone can read and write to. Therefore, it is a database of account balances, and of course, in Ethereum, there are various programs besides account balances. So I can deploy my code to the database. My program can have some state and I can do transactions on it, and everyone can see the updates to the database. Fundamentally, we're just dealing with databases. Sounds boring.

And the significance of the blockchain itself, it's really just an audit trail. So it stores a list of transactions, and if I give you a copy of the blockchain, you can recalculate this database yourself. Fundamentally, we are building a public database that anyone can read, independently compute and write to. Well, this is layer1.

Whether it is Bitcoin or Ethereum layer1, the problem is that it needs to maximize decentralization. There are three different ways to think about decentralization. One is the operator: who runs the network, who produces blocks, who confirms transactions. With many of these networks, we always want to maximize the possibility that anyone can participate in the process. This way there is no single point of failure. On the other hand, you also need to consider who can verify every update of the database, who can verify that the operators are doing their work, that the database is correct, and whether there are other problems. Their work and databases are correct and valid at all times. At this point, you will have this kink. You want to maximize the number of people participating in validating the network, and you want to maximize the number of people running the network. So, it's kind of like the old Bitcoin block size fight. Update blocks and you can process more transactions. But then it will be more difficult, because you need higher hardware requirements to verify the network in real time, and finally become a network operator. This is the question of how to consider decentralization at the layer1 level. The third aspect is actually making it affordable. If we pay $200 to transact on a network, is it really decentralized? Apparently it's not. Therefore, in a sense, this is a trilemma problem left over from history.

For a long time, we were stuck with this trilemma, because if you try to process more transactions, one of the parties is going to be hurt in some way, either the fees go up, the hardware requirements go up, or it becomes an operational more difficult. This is a discussion of decentralization in the context of L1.

Franci: As you said, users will consider the cost of transactions. Then they might choose to deposit their money on a centralized exchange. Broadly speaking, is this a kind of L2?

Patrick: I think it's a good way to think about it in terms of exchanges. A centralized exchange is like a database. But the problem is, it's a private database. So basically the database of the exchange, only it can read and write. And users like you and me, we can't audit this database, we can't check that it's correct. But the advantage of trading on an exchange is that it is very cheap. The purpose of the L1 blockchain system is to be as decentralized as possible, but the cost is too high.

So when we think about the L2 world, in the L2 world, we don't really want to recreate the L1. We don't really want to have to build a decentralized network that maximizes the number of participants. Because we already know that, historically, it has been very difficult to build these kinds of systems and make them scale a lot in terms of throughput. So we would think, can we build a system that looks like an exchange, but still retains the properties of a blockchain system, where the database is public? Anyone can read the database, anyone can write to it, and anyone can protect it. This is the goal of L2.

When you dig deeper and compare the exchange to what we've built in L2, at the end of the day we're comparing the bridge engineering stuff. What I mean by bridge is that there will be a smart contract on Ethereum, and I lock assets in this smart contract called "bridge". Once it is locked on the bridge, it will appear in other databases. This database could be Coinbase, it could be Arbitrum, it could be Optimism. Then the question is, when I want to take my funds out of this other database and bring it back to Ethereum, how do I get authorized and how do I convince the bridge to unlock the funds?

For Coinbase, the user trusts Coinbase to authorize the withdrawal, the smart contract will check and say, oh, Coinbase authorized, I can withdraw the funds. But for L2, the focus is on the bridge, and how to make it believe that this off-chain database is safe, and then allow the funds to be unlocked.

So, back to your original question. I think Coinbase or these exchanges, they're basically what we want to build for L2. But we want to build it in a way that protects users. If Coinbase goes down, or if they do something bad and get hacked, users are always safe and secure. They don't have to trust the operators of the system. What it really focuses on is how assets are locked in the bridge of the system and then taken out of that system.

How to define a secure and decentralized Rollup

Franci: So what Rollup has to do is choose some compromise between these. What weapons do they use to keep users safe?

Patrick: I think the real focus is on the bridge itself. For example, Arbitrum's bridge, which is a set of smart contracts deployed on Ethereum. The bridge currently holds about $6 billion or so. It's actually a set of smart contracts on Ethereum holding $6 billion. You need to convince the bridge that I have the right to take my funds off the bridge and back on Ethereum.

So what weapons do we have to keep users safe? One of the nice things about being in L2 is that we can make a really good assumption. We can assume that there is already an L1, such as Bitcoin or Ethereum, that already exists and is running. We can assume that there is already this decentralized platform and build on it. And think of this platform as a trusted third party, trust this third party, and guarantee that we will always do the right thing. So that's the basis of all these systems. If you have a good decentralized platform, leverage and reuse it and build on top of it.

So the problem statement actually becomes, now we have this off-chain database that records account balances and program states. Can we use a trusted third party to check that every update to this database is correct and valid? This is what L2 is really about. To give a concrete example, say in the Arbitrum database there are account balances, program states, and then Arbitrum's smart contract is a trusted third party that guarantees that the bridge will always function correctly. The people who run the Arbitrum network, the orderers, the validators, periodically send checkpoints or proofs to the bridge to convince it that the updates applied to the database are correct and valid. If the bridge is convinced, it will allow users to withdraw their funds from Arbitrum. So this is our weapon.

Franci: You just said that Rollup is built on top of Ethereum. So this reminds me of a saying that the community always says that Rollup inherits the security of Ethereum. So does this mean that Rollup's security is equivalent to that of Ethereum?

Patrick: I think that's a good way to think about it. The answer is yes and no. I think there are different ways of thinking about this. The easiest way is safety and liveness. In terms of security, we only consider this issue in the database, which means that every update of the database is valid. It is impossible to have an invalid update, because if there is an invalid update to the database, then you can steal the assets. This breaks basic security. And that's a big part of it.

The next part is liveness, which means can we make sure that people can make updates to the database? In a database, in order to keep it alive, we need to guarantee, can we always update it? Or is there an honest side? They can propose an update, which is eventually processed. This is important because if Coinbase or Kraken goes down or does something evil, your funds are stuck. So that's where it's slightly different from Ethereum because in Ethereum you have to trust the PoS and the honest majority to keep the system alive. Whereas in rollup, we already assume that this activity has been obtained for free from Ethereum. We just have to assume there is an honest party out there. As long as there is an honest person willing to do the work and propose updates to the database, then of course the system will stay alive. This is what we mean by inheriting security from Ethereum.

So when we think about the security of rollups, we're not really thinking about a decentralized network. There might be a decentralized rollup network, but that doesn't matter. The security of Rollup really depends on its smart contract as a bridge, and it needs to be convinced from three aspects.

The first is a data availability problem: the bridge believes that anyone in the world can access the database, and anyone can recompute a copy of the database and the latest copy. So this is the first thing you have to convince the bridge. Can anyone in the world access a copy of the database we care about?

The second property, you could call it the state transition integrity problem, and this goes back to the security issue. The bridge needs to trust that every update to the database is correct and valid. And this is to ensure that no one can steal your funds. So the rollup operator has to periodically convince the bridge that every update they make to the database is correct. Only then will the bridge release the funds or withdrawals that should be processed.

The last one is anti-censorship, which can ultimately be attributed to the attribute of activity. If the whole system goes down, does anyone come and propose an update to the database, which is then handled by the bridge.

To sum up, when we consider the security of rollup, it is really considered from the perspective of the smart contract on Ethereum, that is, the bridge contract, and the bridge must be sure that every update to the database is correct. It's not really about a decentralized web. Our real concern should be this honest party who helps bridge the security of locked assets.

Franci: In one of your articles, you made a metaphor, comparing Gandalf in the movie "Lord of the Rings" to an honest party against evildoers. For the honest side of this, can you explain a bit more?

Patrick: Gandalf is a great example, because in this scene, he's actually standing on a bridge and he says, "You can't go through." Then he destroys the bridge and the opponent falls down. He was the honest side, stepped forward and protected his teammates. The situation is exactly the same here. The bridge contract is ultimately responsible for securing assets locked in this off-chain system. The honest side is a sidekick, and Gandalf is the team's sidekick to make sure the ring can be destroyed. And the honest party is helping to bridge the contract. Because these contracts are deployed on Ethereum, they cannot really interact with the outside world. So they need someone to look at the off-chain system, and that's what the honest party does.

Franci: As you said, Arbitrum is using a fraud proof system, so they already assume there is an honest party. So what about other types of Rollups? Who is the single honest party in a zk-Rollup using validity proofs?

Patrick: As we mentioned earlier, the bridge contract is responsible for checking every update applied to the database. Well, an honest party, a relay, or anyone can submit a database update to the bridge, but at the same time they should also provide proof that this database update is correct. And that's what we do. We just want the smart contract to believe that updates to the database are valid, correct, and should be accepted and processed.

There are two ways to do this, using two different types of evidence. One is the fraud proof currently used by Arbitrum: anyone can come and submit a potential update to the bridge, and also verify it. Then there will be about two weeks where anyone can come and challenge it. When someone initiates a challenge, the bridge will coordinate this fraud proof game mechanism, moving back and forth until it finds a very small state transition that we don't agree on. The bridge will then check independently to find out who is at fault. This is how fraud proof systems work. Its disadvantage is that there is a two-week or one-week challenge period, because it needs to provide enough time for challengers to stand up and protect the system.

As for the validity proof system, the mechanism used by zk-Rollup, such as Starknet, zkSync, Polygon Hermez, Scroll, Taiko, etc. When users or operators submit database updates to the bridge, they also provide a proof of validity. This is a mathematical proof, beyond all reasonable doubt, and shows that this database update is correct and valid. This is a very powerful property because anyone can submit an update with a proof to the bridge, and the bridge can immediately trust that the update is correct and valid and process it.

These are two different approaches, each with pros and cons. But again, they only address that one question: Are the updates to the database correct? That's all. There are other issues that need to be addressed, such as censorship issues, data availability issues, and more.

How to Decentralize Rollup and Adoption of DAO Governance Scheme

Franci: There are still many trusted and permissioned parties in the Rollup system. How do you see the process of decentralized rollup? What do you think is the most important goal, and which part of it do we need most urgently to decentralize?

Patrick: Let's go back to the centralized exchange example mentioned earlier to think about this issue. Like centralized exchanges, there is actually a sorter behind them. For example, if I log in to the Coinbase website to submit a transaction, its sorter will accept my transaction and sort it. These transactions are then passed to the server, where they are processed and updated by the database. That's the current architecture of these exchanges, which is very centralized. During the whole process, we don't know what happened in this black box. We have to completely trust this entity to protect billions of dollars, and basically rely on human processes to do so. This is bad.

We don't want to rely on humans because humans are not good at enforcing rules. So on the rollup side, what we're really trying to do is try to replicate that architecture, but at the same time make it more transparent and auditable. This means that each of us can check that it is functioning properly. We rely on software to enforce the rules, not humans.

Based on this background, we need to care about two aspects. The first is the sorter, their only job is to have a user-facing website or interface or API, accept user transactions and decide the order of execution, and then pass the sorted transactions to the next party. They can submit the transaction directly to the bridge smart contract on Ethereum, or they can pass the chair to a group of executors. The executor accepts the transactions, executes them in order, creates a database update, and finally proposes the update to the bridge.

Well, with these three different actors, now comes the real discussion of what is decentralization. As I already mentioned, for a rollup we just have to assume that there is an honest person who can secure the system. The question then is, who acts as this honest party? Is it a sorter or an executor?

One benefit in rollup is that the orderer that accepts user transactions is optional. You don't actually need a sequencer, it's just a nice promise of getting instant acknowledgments for a nice user experience. The reason for this is that the bridge contract on Ethereum is the ordering that is ultimately responsible for finalizing transactions. That is to say, any user or any smart contract can send transactions that they want to execute on the system or on the off-chain system directly to the bridge. After the bridge receives the transaction, it will eventually sort and execute it. So the nice thing is that since we can trust the bridge contract to always do the right thing, we don't care what happens to the orderer. So, sorters are trusted, but they are optional. They exist only to provide a good user experience, not really to protect the system. They just provide a promise in which order the transactions will be executed, but not any guarantees.

It is then the job of the next actor, who accepts and executes the transaction, and then proposes a state update to the bridge. So this needs to talk about three levels of finality. Only after the transactions are sequenced and executed in that order, does the bridge take action, for example, allowing users to withdraw their funds.

Going back to the original question, who acts as the honest party? According to what was said before, the sorter does not have to be honest. Moreover, it does not necessarily need a large group of sorters, it can be one, three, five.

The executors responsible for executing transactions are the decentralization we need to worry about. But the decentralization here is very different from the way we think on layer1. We don't really want to maximize the number of active participants in a rollup. There are 500,000 stakers on the Ethereum protocol layer. In rollup, not so many people are required to be executors, because what we really need is an honest party. So decentralization is really saying, can the system be open enough to allow an honest person to step up and protect the system? Without wasting resources so much.

The second part of decentralization is about how to govern the network. How can we collectively participate in deciding how the system should be upgraded? Including software upgrades to smart contracts and upgrades to off-chain components. How does the community come to a consensus on this? That's a whole different sphere of discussion about decentralization. This is more of a governance issue. How do we manage this system? This is probably where you want to maximize engagement.

So to sum up, there are two aspects to decentralization. Decentralization of real-time systems requires only one honest party or one honest executor. That's the basic assumption baseline we're after. Then we have things about the governance of the system and the governance of software upgrades, where DAOs can be used, and here is the part that requires human intervention. Sometimes we need humans to decide on escalations, and this requires a DAO or some way to achieve consensus on this, maximizing governance participants.

Franci: So in terms of governance, do you think removing upgrade keys is the ultimate goal of decentralized governance?

Patrick: Let's give the audience a little background first. For example, when we need to consider the real-time deployment of a certain system, we will face a problem: how to perform the upgrade? One is that there might be an admin key, assuming an admin is there, they have exclusive access to upgrade the smart contract as they see fit. The second method is more like a multi-signature. Instead of trusting a single entity, we can trust 5/9 or 9/12 multi-signatures. Then the third approach, which is unique to these rollup systems (Arbitrum uses this approach), introduces an on-chain governance component. Could a DAO of entire token holders, potentially thousands of people, be introduced to come to a consensus on how to upgrade the system? Once you have a DAO, decisions can be made about upgrades, and decisions can be made around different types of delegation. For example, maybe the DAO is ultimately responsible for authorizing upgrades to the system, but they could also appoint a security committee (multisig on 9/12) that could step in in case of emergency to upgrade and secure the system, and fix bugs very quickly .

What's really cool about this whole process is that it's transparent, anyone can look at these layers of authorization, and of course the responsibilities of each party. So, to answer your question, I don't think we should remove the admin key itself. I think it's important that the process is transparent, and that the DAO that manages the governance or the form of governance that ultimately applies allows the community to reach consensus. Because I think that when we look at rollup as a software stack, 99.99999% of the time, the software will run autonomously, enforce rules to protect the users of the network. This is true most of the time. Then 0.000001% of the time, some form of human intervention is required. Either make a suggestion to upgrade the software, or step in and fix the bug in time. This is actually not that different from something like Bitcoin or Ethereum.

The only difference is that this management process and responsible parties are clear and it is very transparent. We know exactly who should step in at the right time and do the right thing. Whereas on Bitcoin and Ethereum, they rely more on rough consensus. They don't really want to define the process because they want to defend against governance attacks. There has been a recent partial PoS crash on Ethereum. Due to some bugs in the Prysm client, the finality gadget was broken. So Prysm had to come out and fix their bug, and redeploy. So even in these real-time, layerable networks, we sometimes run into places where human intervention is required in order to protect the system. I think this is still required for rollup as well. But we need to have some effective procedures in place so that we know who has authority and hold them accountable for the rollup system.