by Grant Griffith

Scalability is easily one of the most discussed topics regarding blockchains — and for good reason. At its simplest, scalability is about making blockchains faster without (hopefully) compromising on security or other features. If we take a minute to envision a future with billions of potential daily crypto users (spanning trading, banking/payments, gaming, etc.), the importance of having scalable blockchains is immediately obvious. If scaling solutions are not in place to meet this future demand (even on a much smaller scale), congestion will cause blockchain networks to become costly and time-consuming to use and mass adoption will be nearly impossible.

Creating a solution for scalability has therefore been a center of attention in the space. Some have attempted to innovate and address scalability at the base layer (i.e., at the Layer 1 level) — see Ethereum’s planned sharding for an example here. Others have attempted to build scalability off-chain — examples here include sidechains like Polygon as well as rollups like Arbitrum.

This article focuses on the latter form of off-chain scaling solution just referenced — rollups. In addition to touching on the distinction between the two main types of rollups in existence (optimistic and zero-knowledge rollups), this article takes a deeper dive into the emerging ZK-rollup ecosystem in particular. By the end of this article, you will have enough knowledge to be dangerous on almost any topic concerning rollups today.

Optimistic v. Zero-Knowledge Rollups

Before getting into the distinction between optimistic and zero-knowledge rollups, a refresher on what a rollup actually does will be helpful.

What Is the Purpose of Rollups?

Rollups are considered off-chain (or Layer 2) scaling solutions because they execute transactions outside of the core Layer 1 blockchain on which they are built. If this sentence does not fully make sense, I recommend reading the beginning sections of a previous article I wrote, which introduces modularity in blockchains and the role Layer 2s play in that context.

How does moving transactions off-chain increase scalability? Think of it like this — if every transaction on a blockchain network were executed and processed on the Layer 1, unless that network is capable of supporting high transaction speeds (i.e., the amount of time needed to fully confirm a transaction) and throughput (high transactions per second), bottlenecks will occur. Rollups help by alleviating the processing burden of Layer 1s. Rollups process transactions “offline” from the main network, bundle (or “rollup”) these transactions into a single block, and then send that block back to the Layer 1 for final publishing. In effect, by processing thousands of transactions off-chain and only submitting a single transaction to the main network, rollups can greatly increase the scalability and throughput of an underlying Layer 1 blockchain. Whereas the current Ethereum network can process about 30 transactions per second (TPS), rollups have the potential to increase throughput to hundreds or even thousands of TPS.

For purposes of this article, we will be limiting scope to rollups within the Ethereum ecosystem. With that context, it should also be noted that by publishing transactions on-chain, rollups inherit the security of the main Ethereum network. This structure is in contrast to some other off-chain scaling solutions like sidechains, which derive their security separately from Mainnet. As a result, rollups are generally considered safer scaling solutions than sidechains and other alternatives like, for example, validiums which do not store transaction data on the main network.

Optimistic Rollups

Now to the first of the two main types of rollups. Optimistic rollups derive their name from the way in which they post transaction data on-chain. They post this data in an “optimistic” way — i.e., when posting, they assume all off-chain transactions are valid.

Taking a step back, consider for a moment what is actually occurring when rollups post off-chain transaction data back on-chain. When transactions are initially executed off-chain on a rollup, the Layer 1 has yet to finalize and recognize their occurrence. However, when these transactions are posted on-chain, the main network must account for them and transition its “state” (i.e., its historical record of transactions, almost like a balance sheet at a single point in time) accordingly. The challenge becomes how to prevent potentially fraudulent transactions that have occurred off-chain from making their way on-chain through this posting process.

As noted above, when posting, optimistic rollups assume all off-chain transactions are valid. How can optimistic rollups do this while also ensuring fraudulent transactions do not make their way through? There is a fraud-proving scheme in place to help here. After a rollup batch is submitted to the main network, there is a time window (called a challenge period, lasting roughly seven days) during which anyone can challenge the results of a rollup transaction by computing a fraud proof. Without getting too into the details, if a fraud proof succeeds for a particular transaction, the rollup re-executes the batch that was previously submitted so that the invalid block / fraud is excluded the next time around. Alternatively, if the rollup batch remains unchallenged after the time window has expired, all transactions in a batch are deemed valid and accepted on the main network. Fraud proofs therefore facilitate what is known as “trustless finality” — as long as a transaction is valid, it is guaranteed to eventually be confirmed. However, one risk is that this security model requires at least one honest node executing rollup transactions and submitting fraud proofs to challenge results. Otherwise, malicious operators would be able to post invalid blocks and potentially steal funds without challenge or oversight.

What are some examples of prominent optimistic rollups out there? As of writing, Arbitrum One and Optimism are the largest in terms of total value locked (TVL) ($2.41bn and $1.44bn, respectively).

Zero-Knowledge (ZK) Rollups

At a high level, zero-knowledge (ZK) rollups are not all too different from optimistic rollups. Like optimistic rollups, transactions are executed off-chain and subsequently bundled into batches. However, instead of then posting all transaction data on-chain like optimistic rollups, ZK-rollups submit validity proofs to the main network in order to finalize. We will get into the details of validity proofs a little later on in this article, but think of these proofs as cryptographic assurances verifying the correctness of batched transactions.

Comparing Optimistic and Zero-Knowledge Rollups

There are a few main pros and cons that are worth noting when comparing optimistic and zero-knowledge rollups.

Transaction Finality. Since ZK-rollup transactions are finalized as soon as validity proofs are verified, unlike with optimistic rollups which require a challenge period (~seven days), there is no delay when moving funds from a ZK-rollup to the main network. Although this delay for optimistic rollups can potentially be mitigated for users by employing liquidity providers (who may deliver early payment in exchange for a fee), this delay is something to consider.
Security. If you may recall, to work successfully the security model of optimistic rollups requires at least one honest node to submit fraud proofs to challenge invalid state transitions. In contrast, ZK-rollups rely on trustless cryptographic mechanisms for security. By not having to rely on the honesty of other actors, ZK-rollups are generally considered more secure than optimistic rollups.
Overhead and Cost. ZK-rollups require specialized hardware to produce validity proofs (which may encourage centralized control), and the cost associated with computing and verifying these proofs can be substantial. These considerations are not as relevant in the optimistic rollup context.
EVM-Compatibility. Although not touched on previously, it is important to note that optimistic rollups (but not ZK-rollups) are generally EVM-compatible. What EVM-compatibility actually means is a bit confusing. I like to think of it like this. The Ethereum blockchain, as essentially the world’s most popular network, has created a set of de facto global standards based on its early specifications, ranging from its programming language to its token standards. Developers have become accustomed to these standards and have created a huge number of existing dApps on Ethereum that are built in accordance with these specifications (technically, it is the Ethereum Virtual Machine’s / the EVM’s specifications). How can new blockchains ever compete against this first-mover advantage and attempt to onboard the countless Ethereum developers and users into their own respective ecosystems? The answer, in short, is to structure their blockchains in a way that allows Ethereum developers to deploy their existing smart contracts and applications on these new chains without much additional effort (like, for example, learning a new programming language). This conformance is what EVM-compatibility gets at — if developers can essentially copy / paste smart contract code that is readable on the Ethereum network and deploy it on a different blockchain, they are much more likely to build on this other blockchain as well. Blockchains that are not EVM-compatible miss out on the above and create instead entirely new ecosystems. Although this may allow other blockchains to fundamentally change the Ethereum toolset and differentiate themselves in various ways, it makes it much harder to attract developers who are used to the Ethereum standards. Given the complexity involved with zero-knowledge technology and proofs, we have not yet achieved EVM-compatibility for ZK-rollups (“zkEVMs”). Vitalik Buterin has even recently stated that Ethereum was not originally designed around ZK-friendliness, thus contributing to the delay in this regard. As a result, ZK-rollup developers have so far been unable to use zero-knowledge technology in an EVM setting, which has likely hindered development and the adoption of ZK-rollups to date. However, progress is being made. In July 2022 at the Ethereum Community Conference (EthCC), three separate projects (zkSync, Polygon Hermez, and Scroll) announced that they are striving to make zkEVMs a reality. Much progress is still to be made, but in the future, the advantage that optimistic rollups have in terms of EVM-compatibility may subside.

In terms of total value locked (TVL), optimistic roll-ups are currently more popular than ZK-rollups. This state of affairs may seem counterintuitive given that ZK-rollups appear to offer clear benefits in terms of transaction finality and security. However, if we consider how complicated zero-knowledge technology is to build and the fact that ZK-rollups are yet to be EVM-compatible, things start to make more sense. As technology improves and EVM-compatibility increases, developers will likely begin to leverage ZK-rollups more which will help close the gap.

Zero-Knowledge (ZK) Rollups Explored Further

Now for a deeper dive into the ZK-rollup ecosystem, which is emerging as one of the more promising scaling alternatives out there.

Understanding How Proofs Work

If you have gotten this far in the article, you may be wondering — why do these types of rollups have “zero-knowledge” in their name? When we previously explained at a high level how ZK-rollups work, there was only a reference to validity proofs and cryptographic assurances, not to anything zero knowledge-related. As you will soon see, the “zero knowledge” part is a bit misleading without understanding the underlying mechanics of how proofs work.

Defined, zero-knowledge proofs provide a way to cryptographically prove that one possesses knowledge of certain information without actually revealing what that information is. For those familiar with the “tell me without telling me” meme going around, that is an easy way to wrap your ahead around it.

For example, say you want to take out a loan, but do not wish to show your credit score to a bank. A ZK proof would be able to help prove to a bank that you have good credit without actually showing your score. Just for illustration, this might be done by inviting your banker over to your $100mm mansion for cocktails. Although the banker has “zero knowledge” of your actual credit score, this visit might convince them you have sufficient credit for the loan.

Understanding how these proofs work in the ZK-rollup context is conceptually similar. Here, one produces a proof that some succinct representation of the batch of transactions that occurred off-chain is accurate with respect to the new “state” of the blockchain that is being proposed by the rollup (which accounts for all the transactions in the batch). Since the proof here is smaller than the data it represents, this method is significantly faster than verifying every single transaction and reduces the computation required for verifiers to validate transactions (thereby reducing transaction costs and improving throughput).

Forms of Validity Proofs (ZK-SNARKs and ZK-STARKs)

As it currently stands, there are two main forms of validity proofs utilized in the ZK-rollup context — ZK-SNARKs and ZK-STARKs. Although both of these have the same end goal of helping to attest to the integrity/validity of batched off-chain transactions, each proof type has distinct features worth noting.

ZK-SNARKs were the first of these forms introduced in 2011 and later proposed by Vitalik Buterin as a potential scaling solution for Ethereum in 2018 (note: the first blockchain protocol to implement ZK-SNARKS was Zcash, a privacy-focused cryptocurrency developed in 2014). The SNARK acronym stands for “Succinct Non-interactive Arguments of Knowledge.” Note the “succinct” and “non-interactive” parts of the acronym, which help for purposes of scaling in particular — i.e., a succinct ZK-SNARK proof makes it easy for a verifier to quickly check that a proof is correct, and a non-interactive proof saves the need for back-and-forth between provers and verifiers, which could otherwise be a very time-intensive process.

One of the more important features (and criticisms) to highlight regarding SNARKs is the fact that a trusted set up is required. See below for a simple definition of a trusted set up from a Vitalik article on the topic.

“A trusted setup ceremony is a procedure that is done once to generate a piece of data that must then be used every time some cryptographic protocol is run.” — Vitalik Buterin

For our purposes, what is essentially happening is that a group of people are coming together and creating a public key (via some secret/private information or other inputs) at the initial formation of a SNARK. This public key is used when proving and verifying validity proofs on the SNARK protocol moving forward, and no further participation from the creators is required. However, unless at least one honest creator destroys or forgets their particular private input, there is the potential to use the combined inputs to maliciously generate false validity proofs. This is where the “trust” comes into play — users of the SNARK protocol must rely on the fact that the private inputs associated with the trusted public set up key are destroyed and not otherwise being held by the those who oversaw the formation.

Next to ZK-STARKs, which are a more recent innovation and first described in 2018. The STARK acronym stands for “Scalable Transparent Argument of Knowledge.” You may have noticed that the acronym replaces “succinct” with “scalable.” Although STARK proofs are significantly longer than that of SNARKs in terms of byte size (hence the removal of “succinct”) and generally take longer to verify as a result, STARKs are more effective at verifying proofs with increasingly complex underlying computations. Therefore, while it may seem like SNARKs are more scalable due to their smaller proof size, STARKs can actually scale better during periods of high transaction volume when large and complex datasets are involved.

STARKs also replace “non-interactive” with “transparent.” Despite this replacement, ZK-STARKs are still ‘non-interactive’ in the same way described previously with SNARKs. However, they provide an upgrade in terms of the trusted set up process that SNARKs use, which is what the addition of “transparent” is getting at. STARKs found a way around the trusted set up process, and instead use a process that involves publicly-verifiable (i.e., transparent) randomness to generate the initial parameters required for set up. Avoiding this initial point of centralization is favorable from a risk perspective for STARKs.

Lastly, there is one more point of difference that I think is worth noting regarding SNARKs and STARKs, and it concerns security once again. As noted before, SNARKs rely on a trusted set up to generate a greater public key that is used on the protocol moving forward (more technically, elliptic-curve cryptography is being used). Unless someone is able to gather all the inputs used to form that public key at inception, theoretically the protocol is safe. I use the word “theoretically” because in the future, this might not be the case. With the rise of quantum computing, this set up might still be vulnerable to attacks. In the not-too-distant future (potentially within 15 years), quantum attackers could potentially solve their way to the same outcome as if they had access to all of the original inputs, without needing any further information as to how the initial set up occurred. This outcome, of course, can lead to malicious actions and essentially destroy the protocol. STARKs, on the other hand, do not have a trusted set up and instead rely on what is known as collision-resistant hash functions (see top of pg. 5 of the original paper that introduced STARKs). Although we can never say for sure whether something is quantum-resistant, STARKs can be considered higher on the scale in terms of resistance because of this difference.

Are SNARKs or STARKs Better?

ZK-SNARKs are currently more prevalent than ZK-STARKs. However, STARKs are clearly portrayed favorably in comparison to SNARKs based on the above. Although they have larger proof sizes and can take longer to verify, STARKs provide more scalability, transparency, and security for blockchains compared to SNARKs.

Therefore, probably the main reason why SNARKs are more popular today is because of first-mover advantage. SNARKs were the first practical application of zero-knowledge technology in the blockchain space, and with that has come a larger developer ecosystem. Having more tooling and support as a developer has its benefits, which has likely fed upon itself and led to SNARKs having greater market share today.

However, STARKs are not without their supporters. The Ethereum community in particular has been an outspoken advocate. In 2018, the Ethereum Foundation, a nonprofit supporting the Ethereum ecosystem and related technologies, awarded Starkware (to be discussed in more detail below) a $12 million grant to further build out its STARK-related technology.

“The grant will allow StarkWare to explore STARK-friendly hash functions, to develop its technology, and to offer open source code to the ecosystem” — Starkware Twitter post acknowledging the $12 million grant from the Ethereum Foundation

Starkware

This would not be a complete introduction to the world of ZK-rollups without highlighting a few of the teams developing in the space.

First is Starkware, whose activity is worthy of an entire article all for itself. In short, Starkware is the pioneer when it comes to ZK-STARKs, and one of its co-founders (Eli Ben-Sasson) contributed to the original STARK whitepaper in 2018 and co-invented the technology. The company has built two scaling solutions to note — StarkNet and StarkEx. The difference between these can be confusing, but at a high level, think of StarkNet as a broader public version of StarkEx to reach a bigger ambition.

*Uri Kolodny and Eli Ben-Sasson, co-founders of Starkware. Image Credit: Natalie Schor*

StarkNet operates as a permissionless and decentralized ZK-rollup (utilizing STARKs) on Ethereum. Think of it as a general purpose blockchain upon which projects and developers can build and interact with each other publicly. Although still in the early stages in terms of traction, there are over a hundred projects developing and starting to go live on StarkNet spanning gaming, DeFi, and more.

On the other hand, StarkEx is a more tailor-made scaling engine (i.e., a permissioned blockchain). Whereas StarkNet can be viewed more as like an open Ethereum-like environment, StarkEx is an application-specific tooling suite for individual projects looking to scale via ZK-rollups (STARKs). Some notable clients using StarkEx include Sorare, Immutable X, and dYdX. As StarkNet development progresses, projects using StarkEx will also be able to migrate to StarkNet if they so choose — which provides them the opportunity to leverage a more fully-decentralized network in the future.

Have StarkNet and StarkEx gained significant traction compared to other rollups and blockchains when it comes to transaction volume? Very much so. See the below images for some context.

A three-month (July through September 2022) cumulative comparison of daily transaction volume occurring on (i) the combined StarkEx/StarkNet networks, (ii) the two largest Ethereum rollups by TVL (Optimism and Arbitrum), and (iii) Bitcoin and *Lightning* *(a Bitcoin Layer 2). Image Credit: @odin_free* *Twitter post*

A more extensive comparison (July 2020 through September 2022) of daily transactions occurring on (i) the combined StarkEx/StarkNet networks, (ii) the two largest Ethereum rollups by TVL (Optimism and Arbitrum), (iii) Bitcoin and *Lightning* *(a Bitcoin Layer 2), and (iv) Ethereum Mainnet. Image Credit: @odin_free* *Twitter post*

A lot of the Starkware transaction volume can be attributed to popular games utilizing StarkEx, such as Gods Unchained on Immutable X. When people say gaming may be the gateway to mass crypto adoption, they may be on to something.

“As a gaming company, NFTs are at the core of our platform. We were looking for a solution that will enable us to scale not only NFT trading, but also NFT minting. After considering several solutions and providers, we decided to partner with StarkWare — StarkEx, their scaling solution, ticked all our boxes. The tradeoffs fit our principles, and were aligned with our customers’ desires, the StarkWare’s team is the most professional in the industry, and they were committed to a long-term relationship with us.” — James Ferguson, co-founder and CEO of Immutable, on partnering with Starkware

Following its $100mm Series D funding round in May 2022, Starkware is now valued at $8 billion. The company has also recently indicated that it will be launching a token for the StarkNet ecosystem — stay alert for future details.

If you had not heard of Starkware before this article, I hope this overview has opened your eyes to one of the more promising and innovative players in the entire space.

A Note on Other Projects Building

Starkware utilizes ZK-STARK technology, so what about projects using SNARKs — i.e., the more prevalent form of ZK-rollup today?

For purposes of this article, we unfortunately will not be getting into the details of these other projects. However, I recommend exploring protocols like Loopring and zkSync (created by Matter Labs) to get a feel for how SNARKs and this technology in general is being deployed elsewhere. For example, Loopring (which utilizes SNARKs) has built a decentralized exchange (DEX) on Ethereum that has been able to achieve massive throughput (over 2000 trades per second) at 0.15–0.30% of the cost of most Layer 1 DEXs like Uniswap. For context, this throughput has approached approximately 1000x that of Ethereum Mainnet.

Final Words

In January 2021, Vitalik Buterin published an article exploring some of the differences between optimistic and ZK-rollups. Near the end of the comparison, he made the below statement.

“In general, my own view is that in the short term, optimistic rollups are likely to win out for general-purpose EVM computation and ZK rollups are likely to win out for simple payments, exchange and other application-specific use cases, but in the medium to long term ZK rollups will win out in all use cases as ZK-SNARK technology improves.” — Vitalik Buterin

*Vitalik Buterin, co-founder of Ethereum. Image Credit: Nation World News*

Granted, a lot in the world has changed since then including continued advances with respect to Ethereum scaling (e.g., the Merge) and rollup technology. However, not all is that different. Rollups will continue to play a significant role in the Ethereum ecosystem for the foreseeable future (see Endgame and here), and the topics raised in this article regarding optimistic and ZK-rollups all remain just as relevant now as they did then.

The main point being, if you had read Vitalik’s quote above before reading this article, it may not have made any sense at all. But now, I imagine you can form your own opinion and carry a conversation on the topics that were raised. Go let your thoughts be known.