The Ultimate Guide to Rollups
What is the most promising way for the blockchain industry to scale smart contracts and move forward with the least amount of trade-offs, from a pure decentralization perspective?
To help you answer this for yourself, I’ll walk you through an elemental understanding of the different kinds of Layer 1 (L1) and Layer 2 (L2) architectures that are available, and give you some basic awareness of recent advancements in scalability tech which will become available very soon on Syscoin NEVM. In the end, I will share my own conclusions.
To begin, we’ll overview the three main types of blockchain architecture. Then we’ll explain the basics of two kinds of rollups, Optimistic & Zero-Knowledge, how they differ, and then get into some important details about ZK-Rollups in particular.
By the end, you should have the basic understanding needed to develop a proper a smart contract scaling solution.
Each of these primary design paths handle computation/execution and data-availability differently; see Table 1 (near the bottom of the article) for architecture comparisons of top smart contract platforms..
Monolithic chains rely on L1 (Layer 1) handling all execution and data storage. L1 alone is used to prove to network participants that the blockchain is valid at any point in time. In Monolithic chains, data is required in order to execute each transaction because the chain arrives at the correct conclusion based on consensus policies coded into the blockchain as well as the smart contracts. Examples include every current smart-chain alternative to Ethereum; (eg. Binance Smart Chain, Avalanche, Solana, etc.)
Modular chains rely on “rollups”, and are designed as systems of systems. Computation is moved off-chain. Flexible mechanisms handle the data required to prove the validity of the blockchain and/or rollups. Sequencers supply state updates to the main-chain and these updates are based on off-chain computation. In Modular chains, data is required for users to be able to withdraw without needing help from anyone else. This the data availability problem. Rollups allow separation of concerns between one another and the main chain, including in the areas of such as computation and data storage. Examples include Ethereum 2.0 and Syscoin NEVM.
Fully Succinct chains function in such a way that no data or previous state is required to prove the state of the blockchain. There are no rollups; everything happens on L1. However, all validators (or sequencers) execute users’ transactions and create validity proofs on L1. In fully succinct chains, data is used for historical purposes, to prove that something happened and to keep accounting records intact. Although fully succinct chains do offload computation off-chain, they still operate under the monolithic umbrella as validating nodes or sequencers are computing state for one single chain. Examples include Mir Protocol and Mina Protocol.
A General Explanation of Rollups
You might have heard the term “rollups” while researching or reading about recent happenings in the blockchain industry. The term was introduced along with Plasma chains as a way to create a system of systems architecture for Ethereum. This enables the creation of a form of scaling which is not as cost prohibitive on the Ethereum blockchain as smart contract executions (computation) are moved elsewhere, through the use of merkle trees and fraud proofs, and later, validity proofs. Don’t worry if you do not understand what merkle trees are. Understanding the mechanics isn’t required in order to appreciate why these advancements are important for unlocking greater potential for smart contract blockchains generally. The idea is that execution work is done off-chain, and some nodes or a sequence of nodes provide a state update to the Ethereum main chain, which if valid, unchallenged or unsuccessfully challenged (depending on rollup type), will represent the new state of the rollup. This “state” is essentially a database which represents new balances and adjustments to accounts as users transact with their accounts inside of the rollup. Inside the rollup, everything functions just like Ethereum mainnet but much faster and cheaper, and in a way that is basically transparent to the user. The user doesn’t have to interact directly with L1 very much, if at all.
Plasma and Optimistic Rollups (fraud proofs)
OMG and Polygon are examples of production level Plasma integrations for side-chaining the Ethereum network. However, Plasma by itself suffers from theoretical censorship attacks as the validators executing the smart contracts and proposing state updates to Ethereum can prevent users from exiting such systems. Thus, risks exist for a loss of funds in certain scenarios. The research to address this led to Optimistic Rollups, an innovation on top of Plasma. They follow most of the same principles, except that some small amount of data which represents the account balances of every user within the rollup is provided alongside the state updates to Ethereum. This enables users to provide a commitment to the state, proving they own some balance inside of the rollup. With this, they can initiate a withdrawal without the help of any validator or sequencer. Thus, Optimistic Rollups remove some of the risks of censorship and help scale the Ethereum chain by a factor of 50 or more. Theoretically, if all transactions were happening on a rollup, Ethereum nodes would not have to process and execute each transaction individually. That would alleviate the bottleneck that nodes have as they can only execute a certain amount of computations per second before they cannot keep up with the network (currently this equates to about roughly around 14 transactions per second). If rollups represent these transactions, these checks are much simpler. Furthermore, the transactions can potentially be executed in parallel because global state access is minimized should the softwares (parity/geth) of the Ethereum ecosystem wish to increase the amount of processing the network is capable of at any time. Given the fact that the transactions are actually happening off-chain and the amount of computation can be unbounded (the state represents a non-fixed amount of transactions), the only bottleneck is then the data associated that comes along with the state update to Ethereum. Some Ethereum engineers got these individual account updates down to a few bytes (8–12 bytes depending on the implementation) which means that a block with 1 megabyte of bandwidth would be able to roughly process 83k — 125k account adjustments per block and around 5500 to 8300 TPStps theoretically assuming 15 second block times. This is a wonderful scaling proposition that promises to deliver Visa-like speeds to a smart contract network that so badly needs it. As you know, Ethereum remains clogged as DeFi activities are exponentially increasing through utility, awareness and developer curiosity.
Optimistic Rollups use fraud proofs to avoid re-computations. The state is proposed to Ethereum by a “bonded” actor. If anyone wants to challenge the actor, they may claim a bounty by proving that the state update is inaccurate. To accomplish this, the challenger must provide the data required by the smart contract to prove the inaccuracy.
Due to Optimistic Rollups’ use of fraud proofs, they make trust/security assumptions which aren’t strictly inherited from the Ethereum chain. Optimistic Rollups work based on the assumption that someone will always be around to submit a proof in time. This results in lengthy delays to exit a rollup due to the need to wait a theoretically sufficient amount of time for challenges to arise. In the end, a safety assumption is made that the proposed state is valid.
ZK-Rollups (validity proofs)
In yet another successive innovation, ZK-Rollups have taken root and are beginning to rise in their adoption. In this Zero-Knowledge Proof based rollup, validity proofs eliminate the need for fraud proofs. ZK-Rollups do not need the security assumptions required by Optimistic Rollups and impose no such exit time constraints. An exit can happen after a single confirmation. There is no need to prove fraud as the zero-knowledge based validity proof offers mathematical assurance of the correctness of the state.
With a ZK-Rollup, the computation is done and the result is batched-up in a proof off-chain, just like with Optimistic Rollups. However, ZK-Rollups use math instead of fraud proofs and gamification. The trade-off here is the extra complexity required to make the executions compatible with standard Solidity and EVM tooling. It is not very convenient for Web 3.0 developers to make complex changes to their smart contracts. By doing that, they lose the Lindy effects which have helped harden the security of contracts coded in solidity and executed on Ethereum through the EVM.
The perspective of Ethereum developers the past few years was that Optimistic Rollups would be ready for general smart contracts and EVM compatibility sooner than ZK-Rollups. Naturally, some projects quickly began to integrate and implement Optimistic Rollups. However, academics have recently made some very interesting advancements in ZK-Rollups compatibility with EVM, and discovered viable ways to convert Solidity to the mathematical language needed to compute validity proofs. These advancements enable complete translation of existing smart contracts into this new mechanism that requires no fraud proofs and no security/trust assumptions. It is as if the blockchain extends itself without sacrificing decentralization or security! Coupled with the system of systems design where many rollups can exist in parallel without any communication complexity between them, this means massive parallelized computation and exponential gains in scaling and cost efficiencies. Because ZK-Rollups use validity proofs to assure correctness of computation, the data-availability policy can also be adjusted depending on the level of scale needed. By moving data-availability requirements off-chain, as well as computation, you essentially remove the bottleneck to achieve exponential scaling attributes. Now L1 can represent any amount of off-chain computation without worrying about data storage capping-out the state change due to a block size limit.
Let’s explain sequencers and how they work with ZK-Rollups. A sequencer can be any cloud server or even a blockchain node running in some consensus system. A sequencer calculates a validity proof which does requires CPU/memory and a bit of network bandwidth, but is still far cheaper than invoking a blockchain to run an EVM. These costs are amortized by the number of transactions happening. The more activity within a ZK-Rollup, the more “bang for the buck” one gets when finally settling the state on-chain. That means as more users adopt the ZK-Rollup you begin to see true economies of scale for the first time in our industry, without sacrificing decentralization.
What is also very exciting is that you can finally achieve gas-less transactions with flexible arrangements, such as the one https://mute.io introduces in their ZK-Rollup based AMM. This is possible because economies of scale allow for negligible costs per transaction. The AMM token model sufficiently covers costs while at the same time holders of the AMM tokens are rewarded through the volume of transactions paying liquidity and conversion fees. Furthermore, for those projects or rollups that will still prefer to charge transaction fees, they may deem those be paid in currencies or tokens other than the gas currency required on the L1. For example, they can accept a USD stablecoin or even any token that happens to be transacted (ie: send Token A to a user and sequencer covers the transaction via a small amount of Token A). Behind the scenes the sequencers provide a state transition to L1 and pay the L1 gas fees. Again, as the number amount of users picks-up and volume increases, the on-chain fees start to become negligible to the overall revenue collected by the sequencers. As stated above, sequencers can also run their own custom consensus systems using their own (d)PoS or PoW systems and guarantee instant executions, such as zkSync. This means you will be able to interact with Web 3.0 distributed applications at the speed of existing internet applications and their equivalent cost models, to onboard and manage users’ experiences.
One of the interesting features of ZK-Rollups is the flexibility designers have on consensus on L2. It does not affect L1 consensus and thus differing ideologies and practices may be implemented to achieve Web 2.0-like convenience. One of the unique features of zkSync of Matter-labs is the ability to have a decentralized sequencer for their ZK-Rollup yet at the same time offer instant transaction receipts to users without waiting for the state to be posted to L1. This receipt is a guarantee of a slot in which a sequencer must include a transaction that pays a nominal fee that will be included in the L1 transition and if it is skipped the sequencer will be slashed. In the event the sequencer misses or is slashed a subsequent sequencer could then be required to include that transaction and so on and so forth guaranteeing the inclusion of a transaction in order of execution. This strategy is a minimalistic approach to transaction inclusion very much like L1 protocols try to achieve by optimizing consensus policies on monolithic chains. By only focusing on transaction inclusion and not security or validity of the state itself, it achieves convenience with minimal security risks. Of course for larger values of transactions the policy can always be that these transactions simply would need to wait for L1 state confirmation before being confirmed on L2. The myriad of options available at the disposal of developers makes ZK-Rollups a clear winner in the scaling game for blockchain.
Regular, Validium, and Volition
The use of validity proofs with ZK-Rollups does not require external consensus to prove that smart contracts were executed correctly. That translates to protocols having some flexibility in determining data storage and availability requirements. This can range from completely decentralized operation, to allowing users to store their accounts off-chain for further scaling and cost considerations. These modes are “Regular”, “Validium”, and “Volition’’.
Regular ZK-Rollups work essentially without presenting new security, trust, or assumptions, that would otherwise affect the decentralization of the L1 they are running on. This is pure scaling without any trade-off. It is favoured as a way to scale a blockchain by a factor of 50–100x, at minimum. A regular ZK-Rollup extends the main blockchain and offers computational consistency via validity proofs, and on-chain data-availability to remove censorship concerns. There is also no concern around how the L1 blockchain will cope with high demand because the risk is offloaded to the off-chain sequencers which can scale their hardware horizontally or vertically as needed based on load. You may have cases where the rollup gets overwhelmed for a short period of time, but it will not affect the security or service level of L1 as they are separate systems. Even so, there are fewer issues scaling-up validity proof systems than regular monolithic consensus systems, by far.
Validium is a style of ZK-Rollup that removes the need for data to be stored on-chain. Just the validity proof for the state transition is stored. Remember, no fraud proof is required here. The validity proof ensures correctness of the computations of the smart contracts on the rollup as well as the data through a commitment in the proof as input. With Validium, users either store the data themselves and have the ability to move off of the rollup back into L1, or they rely on the consensus or service of the sequencer network to provide the data required to move off of the rollup. Use-cases include federated, consortium, or even regulation-compliant rollups.
Volition, another style of ZK-Rollup, serves as a “happy medium” between the Regular and Validium modes. It abstracts the account to allow either on-chain or off-chain data storage for their account slot. A user could, for example, transact cheaper using off-chain data storage and then settle their account on-chain when they complete their DeFi activities. In this case users get to decide which data-availability policy they require for a particular transaction.
The evolution of scaling smart contract systems has evolved from Plasma to Optimistic Rollups and now to Zero-Knowledge Proof based Rollups. In ZK-Rollups, there are flexible arrangements of designs and consensus systems that can be built on top, and at least three different data-availability approaches. Designers, developers, and users can choose between them based on business requirements. Likely we will see a mix of all three of these approaches be tried as we venture further into the modular paradigm of blockchain architecture.
After considering the three main types of blockchain architectures (monolithic, modular, and succinct), the modular blockchain design appears to be the most promising way for our industry to move forward with the least amount of trade-offs from a pure decentralization perspective, due to the most recent tech advancements of rollups. At first succinct blockchains seem to be positioned as a holy grail design for blockchain L1 but are factored down to be essentially a ZK-Rollup without data-availability guarantees which comes with its own security tradeoffs. It’s worth noting that all smart-chain alternatives to Ethereum are considered monolithic designs at the time this is being written. Tezos has a ZK-Rollup roadmap but does not offer any production based systems. Monolithic chains approach scaling on L1 through optimizations at the networking and/or smart contract execution layer.
Ethereum has adopted a rollup-centric approach with their immediate roadmap to 2.0, so now you have a clear picture of what all of this means. Syscoin is also another blockchain that has adopted this strategy while employing security/decentralization as its first principle in regard to L1. With Syscoin, L1 consensus is secured by Bitcoin through merged-mining, along with quorum-based chainlocks for finality and resistance to attacks like MEV and 51%. Ethereum’s focus is becoming a highly available data-layer for rollups through sharding and Proof-of-Stake whereas Syscoin remains Proof-of-Work in-line with a security-first mentality. I expect engineers and users will create applications leveraging both as Ethereum and Syscoin will be used inter-operably (UX will be abstracted for the most part between L2 rollups). Users will have the choice on which security model they prefer for securing their accounts, and which rollups they prefer to interact with.
Below is a visual depiction of the style of chains that are on the market and their design philosophies translated into a few key metrics. The key take away is that a modular design will scale more securely and likely higher in absolute numbers than a monolithic chain based on the observations made above.
Besides the “Type” field you may be wondering about the metrics as they may not be totally clear. We will go over those in detail, in another post focused on an ideal blockchain design. Stay tuned!
Special thanks to Bradley Stephenson/Dr. Ian Moore of the Syscoin Foundation and Angela Wu of Matter Labs for their valuable input and feedback.