Reviewing Rollup Architecture: Optimistic vs. Zero Knowledge

This report will review the differences between Optimistic and ZK Rollups

Although Ethereum has experienced significant growth in the past two years, with TVL increasing by over 240x to reach $120 billion, it’s clear that the network is limited by a general scalability issue. Due to Ethereum’s design, the network at full capacity can process roughly 15 transactions per second. Ethereum’s centralized counterparts, such as Visa, can handle roughly 65,000 transactions per second. Since the demand for using Ethereum far exceeds 15 transactions per second, the resulting network congestion leads to long wait times and high gas fees. This presents a significant barrier to mass adoption and limits the types of applications that Ethereum can handle.

The goal is to find a solution that increases throughput without sacrificing decentralization or security. The main bottleneck for Ethereum is that each full node in the network has to process every transaction to verify that each miner’s work is valid and maintain an accurate copy of the current network state. Nodes have large computational requirements to participate in the network and keeping a high node count is critical to the network’s security and decentralization. This means that making simple changes such as increasing the block size would be infeasible as it reduce the amount of node operators and compromises the decentralization of the network. With this in mind, there are generally three approaches to scaling Ethereum:

• L1 Scaling
• Sidechains
• L2 Scaling

The Ethereum network is currently progressing towards a layer one scaling solution referred to as ETH 2.0. This entails transitioning from a proof-of-work consensus mechanism to proof-of-stake which replaces resource-intensive mining with validators who stake ETH on the network. Proof-of-stake additionally lays the foundation for sharding which alleviates network congestion by breaking transactions into shards of smaller data sets to expedite processing. Sharding is expected to increase throughput on Ethereum to 1,000–2,000 transactions per second.

Source: Introduction to Blockchain Technology

Sidechains are EVM-compatible, independent blockchains that run parallel to mainnet via a two-way bridge. Rather than leveraging Ethereum’s consensus mechanism, sidechains create their own architecture which can be optimized for speed and scalability. Although sidechains scale general-purpose applications effectively, their consensus algorithms often compromise decentralization and security relative to Ethereum. Examples of sidechains include Polygon and Gnosis chain.

Layer two scaling is a collective term for solutions designed to help scale applications on Ethereum, while taking advantage of Mainnet’s decentralized security model. Layer two scaling solutions include channels, nested blockchains (plasma), and rollups. Channels consist of state channels and payment channels (a subset of state channels). Channels require participants to lock a portion of Ethereum’s state (ETH) into a multisig contract which opens up the channel for the participants to transact off-chain. Once the off-chain interaction is finished, the channel is closed by submitting the final state signed by both participants. While this greatly improves throughput and cost, there are many downsides including the lack of open participation and inability to scale general purpose smart contracts. The lightning network is an example of a layer-2 scaling solution applied to Bitcoin that leverages payment channels to conduct transactions more efficiently.

Another L-2 scaling solution is referred to as “nested blockchains” which were popularized by Plasma technology. This method involves creating ‘child’ blockchains that use the main Ethereum chain as a trust and arbitration layer. Child chains can be configured to match specific use cases and can have their own consensus mechanisms, block sizes, and confirmation times. State updates conducted on child chains can always be brought back to the Ethereum network in the case of dispute or if the user wants to stop transacting on the child chain. Similar to channels, plasma is application-specific and cannot support general purpose smart contracts due to issues with data availability. Additionally, plasma is powered through fraud proofs which means withdrawals can be delayed by several days to allow for a challenge period (more on fraud proofs later).

Introducing Rollups

Rollups are a layer-2 scaling solution that aim to combine the best aspects of channels and sidechains to scale general-purpose smart contracts while relying on Ethereum for security. Rollups settle transactions outside of the main network but post the transaction data back to the Ethereum network using proofs to ensure that the transactions are valid. When transactions are executed on the rollup specific chain, the transaction data is batched, compressed, and sent to specific contracts deployed on the main Ethereum network. This alleviates congestion on the main chain since it moves transaction computations off-chain and only stores the compressed transaction data on Ethereum. Rollups are able to produce gains in scalability while enabling redeployment of all existing Ethereum smart contracts to a rollup chain with little or no change. This is possible because rollups solve the data availability problem inherent in Plasma by publishing some data for each transaction via the L1 network. The method of verifying transaction data is the key distinction between the two types of rollups — Zero-Knowledge rollups and Optimistic Rollups.

Optimistic Rollups

Optimistic rollups verify state transitions through the use of fraud proofs. A third party called a sequencer is responsible for executing and storing transactions off-chain. In order to solve the data availability problem which enables censorship-resistance, sequencers periodically submit a merkle root of the transactions they receive and the resulting state roots on the main Ethereum chain. The sequencers are kept honest by fraud proofs, submitted by verifiers who monitor the state of both layer 1 and layer 2. Anytime the sequencer publishes a batch of state transitions, there is a dispute period in which verifiers can publish a fraud proof to prove one of the state transitions is invalid. The fraud proof is tested by replaying the transaction that caused the state transition on-chain and comparing the resulting state root with the state root published by the sequencer. If the state roots do not match, the fraud proof is successful and the state transition is considered invalid. The state is then rolled back to the point directly prior to the invalid state transition.

Essentially each state transition is assumed to be correct, until proven otherwise by a fraud proof. This is why it is important for optimistic rollups to create incentives that encourage users to run verifiers and discourage sequencers from submitting invalid state transitions. Optimistic rollups achieve both of these incentives through “fidelity bonds” which the sequencer is required to lock up in order to operate on the network. If a verifier submits a successful fraud proof, the sequencer’s bond is slashed and used to reward the verifier and pay the gas fee associated with testing the fraud proof. Disincentivizing the sequencers through bonds is important as it reduces the need to issue fraud proofs on Ethereum, which congests the network. In the ideal scenario, fraud never happens, and fraud proofs never get issued. Although this scenario may disincentivize verifiers since they receive their reward from successful fraud proofs, the network theoretically only needs one honest verifier to monitor the network which is a fairly weak assumption.

ZK Rollups

Similarly to Optimistic rollups, a zero-knowledge rollup performs computations and storage off-chain, while funds are held in a smart contract on the mainchain. The key difference, however, is that ZK-rollups use validity proofs rather than fraud proofs to validate transitions of state. These validity proofs are referred to as zero-knowledge proofs which allow one party to prove to another party that a statement is true without the prover having to share anything beyond the validity of the statement itself. As an example, instead of providing a username and password to gain access to a service, one could convince the verifier with a zero-knowledge proof that they know a valid username and password combination. In this way, the verifier is given proof that the prover knows a username and password that grants access without actually having to share that information. The prover would input the information into the zero knowledge proof program which would create a proof that cannot be linked back to the actual data. This means it is impossible for the verifier to derive the underlying information. There are two popular forms of zero knowledge proofs which differ in the methods by which the two parties prove their knowledge. As both methodologies have their own trade-offs, it will be important for both technologies to develop over time. These two flavors of zero knowledge proofs are referred to as SNARKs and STARKs

First, let’s break down SNARKs:

Although the math underpinning the ZK-SNARK algorithm is outside the scope of this article, we can explore how ZK-SNARKs work in greater depth. A ZK-SNARK consists of three key algorithms:

1. The key generator is a program that takes a secret parameter as an input to generate two public keys. A proving key and a verification key which only need to be generated once for a given program.
2. The prover uses 3 inputs to generate a proof: The proving key, a public input, and the private input (witness).
3. The verifier uses 3 inputs to verify if the proof is correct: The verification key, the public input and the proof generated from the prover. This is a boolean function that returns true if the prover knows the private input which satisfies the program.

Importantly, anyone who knows the secret parameter used to run the generator can generate fake proofs that evaluate to true without knowing the private input. This is why running the generator requires a very secure process in order to ensure the integrity of the proofs.

Although ZK-SNARKs have made significant headway to being well-established and adopted, ZK-STARKs are regarded as the new and improved version to generate zero-knowledge proofs.

The main difference between the ZK-STARK and ZK-SNARK protocols is that ZK-STARK does not require a trusted key set up and instead relies on publicly verifiable randomness via hash functions rather than elliptical curves. This means that ZK-STARKS do not need a trusted entity to generate keys and is more cryptographically secure than ZK-SNARKs.

Zero-knowledge proofs can be implemented into a rollup architecture to improve upon existing scaling technologies. For every rollup block, a state transition zero-knowledge proof is generated and verified by the mainchain contract. This proof includes the proof of validity for every transaction in the rollup block which the verifier contract is able to confirm when it runs the proof. This ensures that data is always available even if verifiers stop cooperating and there is no need for third-party monitors to prevent fraud.

High-Level Comparison

Optimistic and ZK Rollups each have their own advantages and will likely be used in concert to scale Ethereum in the medium term. Although both optimistic and ZK rollups are constantly innovating on their design and infrastructure to improve their existing limitations, it is generally accepted that ZK Rollups are a more sophisticated technology that will reach wider adoption once fully developed. ZK Rollups have the following advantages over optimistic rollups:

• ZK Rollups achieve finality much quicker… minutes rather than hours
• ZK Rollups leverage built-in privacy by default
• ZK Rollups have a higher throughput than Optimistic Rollups
• No need for third party monitors to prevent fraud

Currently, ZK Rollups need more research to implement general-purpose smart contracts and support composability. ZK-Sync has shipped the “zkEVM” on test net which shows the progress teams have made in efficiently wrapping the EVM in zero-knowledge proofs. Since Optimism can already support general purpose smart contracts, it will allow Ethereum to scale while ZK rollups are being developed. It will also allow for applications that only become feasible through the higher throughput available on rollups to scale more meaningfully before being ported to ZK rollups.

Conclusion

Rollup technology is expected to play a key role in scaling Ethereum and preparing it to handle mass adoption. Sharding combined with rollups could achieve scale that handles higher levels of throughput than traditional payment networks such as Visa or Mastercard. This could be the missing piece to solving the blockchain trilemma and simultaneously achieving scalability, decentralization, and security. Despite their promise, rollups are still being developed and will encounter many roadblocks before being fully realized. Optimistic and ZK rollups will likely both have a place in Ethereum’s future as each is better suited for handling certain types of transactions. Regardless, It will be exciting to view the progression of rollups and how it tracks against Ethereum’s broader scaling roadmap.