To become an effective global payment system, a blockchain network must at least compete with current products on the market. Sadly, with Bitcoin and Ethereum currently capped at an average of 7 and 15 transactions per second (TPS) – compared to Visa and Mastercard’s 1,700 and 2,150 – its clear blockchains are still a long way away from achieving that goal. This week, we’ll dive into Part Three of what’s proven to be blockchain’s “kryptonite” to date: Scalability.
Please note, this article is Part Three of my series on blockchain scaling. If you missed Part One or Part Two, it may be worth you taking a quick pitstop to check them out.
In Part One of this series, we discussed why blockchain scaling is important, why it’s proven difficult, and some of the on-chain methods developers use to scale blockchains. In Part Two, we took our first dive into off-chain scaling mechanisms, including side chains, plasma chains, and channel networks. In this lesson, we’ll take a deep dive into (what I believe is) the most promising scaling tech in the blockchain world: Rollups.
Let’s get to it
Last week, we discussed two key off-chain scaling mechanisms explored by blockchain developers today. Each of these mechanisms has unique value and use cases but also comes with specific trade-offs. For example:
Side Chains and Plasma Chains can host a large variety of applications AND increase transaction throughput exponentially. Sadly, they compromise on security by using separate node networks and consensus mechanisms.
Channel Networks increase transaction throughput without compromising on security. Sadly, they are generally application-specific.
So, where does that leave us? Well, we could just implement both mechanisms and utilize them for different purposes. That would add complexity and make composability difficult, but it’s worth a try, right?
Maybe — But what if we could have the best of both worlds? A general-purpose scaling solution that still fully relies on the security of its main chain. Enter rollups.
Rollups
Rollups are quite similar to other off-chain scaling systems – They aim to handle computation and transaction execution outside of their L1. Luckily for us, they are also conceptually easy to understand. Effectively, rollups – get this – “roll up” hundreds or thousands of transactions into a single transaction batch, called a state transition. All funds in a rollup are held by a set of smart contracts that “live” on the main chain and facilitate interactions between the rollup and its chain.
If you read our post last week, you may notice rollups are eerily similar to state channels — They both utilize on-chain smart contracts to combine large batches of transactions and then only post the final result to the chain (see p2). Even so, there are a couple of key differentiators between rollups and other scaling solutions.
Rollups do not operate via a traditional consensus mechanism. Instead, an entity known as a sequencer (or a relayer depending on the type of rollup) processes and orders transactions. This entity sends either an “assertion” or a ZK-SNARK (once again, depending on the type of rollup) to the core chain describing how the chain state should be updated based on these transactions.
Rollups do not offer data storage capabilities for the transactions they facilitate. Within plasma chains and state channels, data storage is managed by the plasma node network and the channel participants, respectively. Within a rollup, transaction data is processed by a sequencer but must still be stored elsewhere (on Layer 1 or in a data availability layer). This means the scaling potential of a rollup is directly limited by the amount of data storage available to it.
A clever reader may have noticed something interesting about these differences – namely, that both transaction processing and transaction ordering are handled by a SINGLE entity. What in the world? How could that possibly be decentralized?
Well… It’s actually not.
That said, using various types of cryptography, we can replicate the trustlessness of a decentralized system, even while relying on a single party for transaction processing. The actual methods for this vary based on the type of rollup used: Optimistic or Zero-Knowledge. For this lesson, we’re going to explore Optimistic Rollups.
Optimistic Rollups (ORs)
Optimistic Rollups are simpler than their zero-knowledge counterpart, so we’ll dive into them first. Before we get deep in the weeds, let’s do a high-level overview. ORs are composed of four main parts:
Smart contracts, which hold users’ assets as they transact in the rollup and facilitate interactions between the rollup and the main chain.
Sequencers, who support the ordering and processing of transactions.
The virtual machine, which developers use to build applications the sequencers can process.
Finders, who use fraud proofs to keep sequencers honest.
Great! So how do these four pieces come together? It all starts off with the smart contracts. When a user wants to interact with an Optimistic Rollup, the user first must “bridge” their funds from the main chain to the rollup. This is a simple process, and it basically entails sending assets from the user wallet to the smart contract “wallet.”1 Remember, the rollups' smart contracts are the key connection between the rollup and its main chain. When users wish to add funds to the rollup or withdraw funds from the rollup, they are effectively "depositing" and "withdrawing" funds from that rollup's smart contracts.
Once a user has funds “in” the rollup, they can then submit rollup-powered transactions with those funds (cheaper and quicker). Transactions can be peer-to-peer or smart-contract based, but they are all powered by the rollup’s virtual machine and processed by the sequencer.
It may be worth taking a pitstop here to detail what I mean when I say “powered'“ vs. “processed.”
Within a blockchain, all applications are built on top of a virtual machine (VM). We’ll dive deeper into virtual machines in a later lesson but all you need to know right now is that VMs allow distributed systems to immitate the capabilities of a normal computer. Effectively, when a user transacts in a blockchain-based system, the VM sets the rules for how those transactions take place.
Importantly, while the VM sets the rules, it still requires some entity to actually process tranactions based on said rules. This processing is handled by the sequencer.
As these transactions are processed, the sequencer continuously updates the state of the assets within the rollup. After a certain threshold (blocks, transactions, etc.), the sequencer finalizes the state for that batch of transactions and sends it to the main chain in a data structure known as an “assertion.” After a set period of time (we’ll get to this in a second), this assertion is then accepted by the main chain, and the transactions are finalized.
We’ve now come full circle and are back to our point from earlier — How can something be trustless if it relies on a single party (the sequencer)? Well, let’s first start by listing out the tasks performed by a sequencer, and then we’ll dive into how ORs address each issue. Within a rollup, sequencers handle:
Transaction Verification: If the sequencer is the only entity that verifies the validity of a transaction, what’s to stop it from adding invalid transactions or “breaking” the rules set by the VM?
Transaction Inclusion: If the sequencer can censor your transaction and stop it from reaching the main chain, you may have assets stuck in the rollup forever!
Transaction Ordering: If the same sequencer always gets to choose the order of transactions, it will always be able to front-run its users. See our section on MEV.
Nice! Now we know what problems we’re up against. Luckily, ORs take a somewhat familiar approach to solve these problems. Let’s dive in!
Transaction Verification: “Innocent until proven guilty”
Ensuring transactions are valid is the single most important job of any blockchain scaling mechanism — Rollups are no exception. We’ve already discussed how transactions are processed within an OR, but what are the implications of this single-party system? If the sequencer is the only entity that verifies the validity of a transaction, what’s to stop it from adding invalid transactions to a block? What’s to stop it from “breaking” the rules set by the VM?
Just like Plasma chains, Optimistic Rollups use fraud proofs to tackle this issue. In simple terms, fraud proofs allow ORs to optimistically assume the sequencer is passing valid transactions to the chain unless shown otherwise. This may seem like a large assumption to make, but it has its benefits. When the assumption holds true, the main chain can add thousands of additional transactions to each block with ZERO adverse effects on the chain’s processing power. Incredible, right?
Yes, but what about when the assumption doesn’t hold true? This is where the fraud proofs come in. To pull from last week:
Fraud proof systems operate under the manta of “Innocent until proven guilty” — So how do we prove someone guilty? Within every fraud proof system, there exists a group of entities, known as finders, whose job is to constantly monitor the system for wrong-doings. When a finder notices a wrong-doing, they can publish a proof to the network, showing a rule was broken. This is essentially a little “red flag” that alerts the network something malicious may have occurred.
From a technical standpoint, that little “red flag” is the result of the following sequence:
A finder notices an invalid transaction or state in the sequencers assertion.
The finder requests that the sequencer split up the assertion into several sub-assertions.
The finder chooses the sub-assertion it has an issue with and then requests that the sub-assertion be further split into additional sub-assertions. (A sub-sub assertion, if you will).
This process continues until the finder is left with a sub-assertion small enough to be computed on-chain.
From here, the chosen sub-assertion is sent to the main chain to be run through its normal consensus and validation mechanisms. During this process, the chain will either find a malicious action or find nothing. If a malicious action is found, the sequencer is punished, and the proof publisher receives a reward from the network for raising the proverbial flag. If nothing is found, the proof publisher is punished for wasting the network’s resources.
This system is effective for a couple of reasons. First, blockchains are public, so the job of being a finder is an open market in which anyone can participate. Since you, your mom, or anyone else can profit from participating in the system, it’s improbable every finder would be malicious. What’s a lot more likely is, at minimum, one profit-motivated finder exists, ready to flag broken rules. Second, because finders are punished for false flags, there is a strong incentive against spamming the network by simply flagging every possible issue.
Importantly, finders have a limited amount of time (I told you we’d get to it) to publish a fraud proof on any given assertion. This period is arbitrary in length but generally spans anywhere from 24 hours to two weeks. Once the period passes, transactions from the assertion are finalized on-chain and can no longer be disputed. In other words, they achieve finality.
This is very important, so I’m going to repeat it — Optimistic Rollups do not achieve true finality until the verification period ends and the assertion is accepted on-chain. In practice, this means that while you can deposit funds to an OR almost instantaneously, it can take weeks to remove your funds.2 This is one of the largest drawbacks of Optimistic Rollups and has likely played a part in their slow adoption compared to alternative L1s.
Overall, the fraud proof system means Optimistic Rollups rely on both sequencers AND finders to monitor the validity of transactions. Next up, transaction inclusion!
Transaction Inclusion: “There’s always another way…”
Transaction inclusion can be described as your ability to get your transaction into a block. If you can get your transaction in a block, inclusion isn’t an issue. If you can’t, it is. Who would’ve guessed?
As we know, transaction inclusion within an Optimistic Rollup is handled by the ORs sequencer. Honest sequencers process batches of transactions, roll those transactions up into an assertion, and then send the assertion to a group of smart contracts on the main chain. Finders check the validity of the assertion, and then the contracts push the assertion into a block. Boom! Transaction included!
Well, great… but that doesn’t answer our question. What do we do if the sequencer decides not to include our transaction? It’s actually pretty simple.
One of the great things about smart contracts is they’re immutable and open – meaning anyone can access them at any time. In other words, the smart contracts on which rollups are based can receive transactions from a sequencer or any individual user on the blockchain. This means if you have your assets in a rollup, you can send individual transactions to that rollup’s smart contracts, completely bypassing the sequencer. Of course, bypassing the sequencer negates the benefits of using the rollup (cheaper transactions and quicker finality), but it also ensures sequencers cannot consistently censor transactions.
Furthermore, this feature incentivizes sequencers to act honestly or risk a direct impact on their bottom line. Sequencers make money through MEV or the ordering of transactions in the most profitable manner (see our piece on MEV if you’re unfamiliar). As a result, a sequencer’s potential profit is directly correlated to the number of transactions occurring in the rollup – more transactions mean more profitable ordering opportunities. What do you think would happen if a sequencer began trying to censor user transactions? I know I would pull my assets and move them over to another rollup. I imagine many other users would do the same.
In summary, while sequencers do have complete control over transaction inclusion within a rollup, users can easily go around the sequencer or choose a competing rollup in the event of a misuse of power.
Transaction Ordering: “Let’s have a raffle!”
On the topic of transaction ordering, it’s also a little worrying that a single entity has the sole ability to order every transaction coming through the rollup. If the same sequencer always gets to choose the order of transactions, it will always be able to front-run its users (see our section on MEV). This is obviously not ideal. As a result, ORs often implement other checks and balances, such as randomized sequencers or sequencer auctions, to solve this issue.
Randomized sequencers (to my knowledge) do not exist on the market today, but in theory, they would operate identically to a PoS chain – Potential sequencers buy and “stake” the rollup’s native coin for a chance to be the sequencer of the next assertion. The right to order the assertion is determined by a random selection from the pool of staked coins, and in the event of dishonest action, the sequencer’s “stake” can be slashed or burned. This method has the dual benefit of decentralizing the ordering process across many sequencers while also providing an extra incentive for each sequencer to act honestly.
Sequencer auctions are being pioneered by Optimism, one of the most popular Optimistic Rollups on the market today. The goal of sequencer auctions is to auction off the right to sequence a specific assertion to a pool of pre-approved sequencers. This operates similarly to how you might expect – The right to order an assertion is given to the highest bidder.
This requires sequencers to provide upfront capital, AND it provides a strong source of revenue to the DAO itself. This can then be used to fund other public goods / services to make the rollup faster, drive more transactions, and create a positive flywheel that benefits users, sequencers, and the rollup itself. All in all, this issue can not only be solved, but it can actually be flipped on its head to benefit the rollup in the long run. Who would’ve guessed?
Whew, that was a lot… Anything else?
I know we just covered a lot, but there is one final thing I’d like to highlight about Optimistic Rollups. Because ORs utilize generalized virtual machines (just like a normal blockchain), they’re often built to have almost identical “rules” to their main chain. In practice, this means most applications that operate on the main chain (an exchange, a lending protocol, etc.) can be ported over to the rollup with very little effort. Short term, this gives ORs a significant advantage over other scaling mechanisms. Why? They don’t require the development of a full new suite of applications to be useful. Instead, they can provide value to users right at launch. Take note of this because it will be very relevant in our piece next week on ZK-Rollups.
Let’s review
Optimistic rollups are smart-contract-based Layer 2’s that attempt to inherit the security of their main chain. As the name suggests, ORs optimistically assume the transactions submitted to the Ethereum network by sequencers are correct and valid. This assumption is checked by finders, which can be thought of as an “army” of bots that constantly run through the sequencer’s block proposals to flag invalid transactions. Whenever an invalid transaction is found, the finder can present fraud-proof (or a reason the transaction is invalid) to the main chain. After this is submitted, the suspicious transaction is cut from the sequencer’s block and re-executed on the main chain. The transaction then runs through the core chain’s validation model and is either confirmed or rejected.
Notably, both the sequencer and the finder in this situation have real value staked in the network, generally in the form of the L1 token. Similar to a Proof of Stake model, this value is used to incentivize honesty from both parties – in other words, dishonest actions by either party results in the party losing its stake.
Optimistic rollups are, by far and away, the most developed L2 solution, commanding roughly 47% of L2 market share as of June 2022. The most well-known optimistic-rollup L2s are Arbitrum and Optimism.
Wow! This ended up being way longer than I expected.
I had planned to do both Optimistic and ZK-Rollups in this piece, but I’ve now decided the piece into two parts. Our deep dive on ZK-Rollups is coming to you next week. Stay tuned!
To be clear, smart contracts don’t actually have wallets. That said, they do have “accounts” that can hold assets, and they can initiate state changes involving those assets based on their pre-set conditions. In this case, the preset conditions include all the little technicalities required by a rollup.