1 Introduction
Preface blogs are:
The goals of all Rollup projects should be:
- Build technology stack
- Decentralize operations and governance and hand it over to the community
Thus, a decentralized world can be realized. The term "decentralized" inspires an open, permissionless philosophy, and a whole host of participants with a happier philosophy.
- Most L1 blockchain systems derive their source of truth from the Honest Majority (or supermajority majority) of active participants. On top of that, the appointment protocol is biased towards prioritizing honest participants to join, and honest participants will always outnumber hostile/dishonest participants.
- Rollup relies on a fundamentally different assumption of trust to find the source of truth. The truth is not determined by an honest majority, but by a trusted third party (TTP). In Rollup, TTP is a validating bridge smart contract on a secure L1 blockchain such as Ethereum .
Therefore, the decentralization of Rollup is different from the decentralization of the L1 chain. Rollup decentralization focuses on:
- Aid decision making— The goal is not to make sure the right decision is collectively agreed upon by an honest majority, but to ensure all potential decisions can be delivered and presented to the smart contract bridge in a timely manner。
The Rollup system only needs one honest party to step up at the right time and deliver all messages (potential decisions) to the bridge contract - the contract makes the final decision on behalf of all participants.
Therefore, the purpose of Rollup decentralization is not to introduce 100,000 active Validators, but the exact opposite:
- It is necessary to ensure that 1 honest party always has the opportunity to step up at the right time and send all potential decisions to the bridge contract. The final decision is made by the contract rather than by the participating majority.
There is Honest Majority to 1 honest party :
- Rollup transfers decision-making power from validators/system operators to smart contracts.
Therefore, Rollup decentralization should focus on:
- The appointment agreement can ensure that an honest party can participate when necessary and single-handedly assist the bridge smart contract and protect the entire system when it is under attack by an all powerful adversary . Just as Gandalf stood on a bridge to defend his friendship against Balrog, who was eventually defeated at the summit of Zirazigil.
2. Rollup: centralized front-end + decentralized back-end
Rollup is an off-chain system different from CEX, which makes the system change from "Won't be evil" to "Can't be evil".
Rollup has a centralized front-end + a decentralized back-end:
- On-chain bridge: Maintain all assets of the off-chain system
- Off-chain database: record the debt transactions of the off-chain system
Bridge needs to be convinced that the off-chain system accurately reflects all debts, and that assets can cover all debts before users withdraw money. To solve this problem, Rollup introduces 3 types of actors:
- On-chain bridge: An automated smart contract that verifies the integrity of all updates to the database.
- Sequencer: An operator takes a set of pending transactions and sorts the transactions for Executor to execute. [Provide front-end services for users to collect transactions. It has less impact on the security of the off-chain system. 】
- Executor: An open-membership set of operators obtains sorted transactions from Sequencer, executes the transactions, and attests to their execution with the bridge mart contract. 【Backend service, processing and securing all transactions. 】
The main difference between Rollup and trusted off-chain systems is that the bridge is a smart contract (rather than a centralized CEX). With an open-membership group of executors, the bridge can check the integrity of all attested updates to the off-chain database before a customer withdrawal is processed. In other words, Rollup provides a decentralized backend for off-chain systems, which enables a swarm of network bumblebees to process and secure all valid updates to off-chain databases.
Patrick McCorry recommends that Rollup be implemented as an SDK and open source, as a Web3 software stack for community use.
3. How to introduce One Honest Party to Rollup ?
The two key roles in the Rollup protocol are:
- Sequencer: An operator takes a set of pending transactions and sorts the transactions for Executor to execute. [The impact on the security of the off-chain system is small. 】
- Executor: An open-membership set of operators obtains sorted transactions from Sequencer, executes the transactions, and attests to their execution with the bridge mart contract.
3.1 Sequencer is optional
Sequencer is not required, but optional because:
- Users can skip the Sequencer and submit their transactions directly to the bridge contract. 【Sequencers are not essential as a user can bypass them and forcefully order their transaction for execution via the bridge contract.】
There are 2 paths to submit the transaction:
- fast path: contains user transactions through Sequencer.
- slow path: users skip all Sequencers and directly submit their transactions to the bridge contract for ordering. This is also called forced inclusion safeguard , and only the Rollup that implements this function can be considered safe. [All Rollups must provide a slow path. 】
- The core difference between Rollup and sidechain is: whether users can forcefully order a transaction for execution.
- The forced inclusion safeguard is used to ensure the safety of the user exiting in the last case.
However, if only the average-case is considered, an honest party to participate as the Sequencer is very much needed:
- Prevent or fairly extract MEV
- Guaranteed inclusion of time sensitive transactions (liquidations)
- Reliable user experience (no dropped transactions, up to date info, etc)
Interestingly, the pursuit of a decentralized Sequencer may have a major impact on Rollup's long-term architecture and roadmap based on user experience requirements, which will not be discussed in this article.
However, as discussed here, this is completely unnecessary since users can bypass all of the Sequencer and order their trade executions individually.
3.2 An Honest Executor
Only one honest execution is needed to assist the bridge smart contract and protect the off-chain database。
Executors form the backend of Rollup and are responsible for updating the off-chain database.
The main tasks of Executor include:
- Get the sorted list of user transactions
- Based on the database, execute the sorted user transaction list
- Submit a new database update to the bridge contract
Executor is located between the on-chain bridge and the off-chain database, and is responsible for sending messages from the off-chain world to the on-chain contract.
For this, one honest executor is required to enforce the following properties:
- Liveness attribute: Both sorted and pending transactions will eventually be executed by Executors.
- Safety attribute: There is convincing evidence to prove that each submitted database update is valid.
It depends on whether the convincing evidence adopted by Russia is fraud proof or validity proof, which will affect the execution rules of honest executor:
- Optimistic Rollup: an honest executor needs to protect both safety and liveness.
- Validity Rollup: an honest executor only protects liveness.
3.2.1 Honest Executor for Safety
An honest party is only needed in an optimistic rollup as they monitor and ready to challenge all posted attestations.
The goals of Adversary are:
- Convincing the bridge smart contract of a database update that has a single invalid state transition (i.e., steals all funds).
to this end:
- Validity proof → cryptography: A cryptographic proof replaces the need for an honest party to protect the database update's integrity. An adversary needs to break the underlying cryptography before they can produce a fake proof — which is no small feat (which is not a small feat, it is more difficult to forge proofs).
- Fraud proof → honest executor：When an executor attests to a database update via the bridge, all other executors have an opportunity to review the attestation and potentially issue a challenge for it.
For this reason, we only need to pay attention to how the honest executor guarantees safety in the case of fraud proof:
- 1) Break safety: There is no honest executor available, and the bridge convinces an invalid update.
- Under the Fraud proof mechanism, its security requires the existence of an honest executor, which can initiate a challenge against all adversarial executors. As long as an executor is honest, it is guaranteed to win every challenge against the adversary.
- 2) Delay attacks: Deliberate forfeiture of collateralized funds with the purpose of delaying the finality of executed transactions. [It represents an attack on liveness, not an attack on safety. 】
- Delay attacks are a side-effect of the proof-of-fraud game challenge mechanism. The fundamental problem of the game challenge mechanism is that it is not to prove that a certain attestation is invalid, but that a certain player lost the game. Adversaries can take advantage of this limitation by extending the challenge game for the full allotted time (approximately 1 week) and issuing new invalidation proofs before the previous challenge game ends. By repeating these two steps, it prevents the finalization of honest attestations.
- Every challenge requires the opponent to forfeit staked assets, so this is an expensive attack. There is a trade-off between the financial cost of performing a delay attack and the benefits of doing so.
A delay attack represents an attack on liveness, not safety.
3.2.2 Honest Executor for Liveness
An honest executor can single-handedly push forward and execute all ordered and pending transactions.
An honest executor "picks up the slack" and enforces all ordered transactions. The ultimate success depends on the honest executor cutting in at the right time and how the adversary blocks it.
The purpose of adversary attacking Rollup liveness is to:
- Block execution of user-generated transactions
In almost all pooled designs, the current appointment protocol for selecting honest executors relies on a first-come, first-served basis, which basically depends on who can publish the proof first.
The first-come, first-served approach has a subtle race condition problem that an adversary can exploit to prevent the honest party from participating indefinitely. For example, if two or more executors submit a proposed database update at the same time, the adversary can simply front-run the honest executors with minimal database updates.
At first glance, the obvious solution is to give one honest executor, and all executors, a dedicated time period for proposing database updates, and completely remove the potential race condition. The validity of a dedicated slot depends on how long it takes for an honest party to acquire the slot. The most important threat to guard against is an adversary filling up all slots, again delaying the chance for honest executors to participate.
Another aspect to consider is the database update content. Imagine an appointment protocol that slams and evicts executors who fail to propose database updates on time. In this case, it may be desirable to prevent the adversary from issuing empty database updates, and effectively stop those transactions from being executed by refusing to execute those updates.
Arbitrum's solution to avoid liveness attacks is:
- Forces a minimum amount of computation per database update.
- Deterministic transaction fees that cannot be tampered with by system operators.
Enforces a minimum execution progress, since executors must propose meaningful database updates. Furthermore, this makes it expensive for adversaries to fill the ordered transaction queue with "garbage".
4. Outlook
In summary, make sure that:
- Honest executors have guaranteed slots to submit database updates
- The honest side will get a slot in time
- Filling the rollup with garbage execution is very expensive for adversary.
The above goals provide some rules of thumb to help design new appointment protocols for executors and ensure that an honest executor will come forward at the right time. However, while the rules of thumb are good, there is currently a lack of clear appointment protocols that can be adopted by Rollup projects.
Beyond that, the whole discussion assumes that one executor will do all the work to generate a database update, and that the entire executors do not cooperate with each other. This is likely to be the case for Optimistic Rollup, but not for ZK-Rollup.
Additional tasks: In ZK-Rollup, the executor needs to replay all transactions and generate proof of validity of the correct transaction execution, which is an additional task compared to the executor in Optimistic Rollup.
It is well known that proof generation can be outsourced and parallelized across multiple Provers, but there is still a lack of a mechanism that can fairly split the transaction load, enable Open Membership Provers to work together, and ultimately aggregate all independent proofs into a single on-chain publication. Proven appointment agreement.
For example, one executor will attest transactions 1 to 1000, while the next executor will attest transactions 1001 to 2000. Finally, all subtask proofs can be aggregated/recursively combined into a single proof.
There is already a trusted third party - the bridge smart contract - which can be used to assign transaction segments to specific executors and hold them accountable (slash/evict) if they fail to meet deadlines. So there are all the materials available, but it's still a largely untapped research and design space to take advantage of the bridge's additional strength.
Hopefully someone will come up with an appointment protocol that 99.9% of the time allows a group of open-membership Provers to work together, but in the worst case an honest executor can force progress for all participants.
References
[1] What Does It Mean to Decentralise a Rollup?
[2] Where Is the One Honest Party for a Rollup?
[3] Rollups: Centralised front-end, decentralised back-end