Rather than solely scaling Ethereum through native Layer 1 (L1) architecture changes, the Ethereum community has pushed for a rollup-centric roadmap. Layer 2s (L2s) are third-party solutions that exist in conjunction with the main blockchain. As we’ll touch on later, this second layer is critical to the network’s development - you can only “boost” scalability once. From state channels, sidechains, and plasma, the industry and market has largely converged on Optimistic Rollups (ORs) and Zero Knowledge Rollups (ZKRs) as the preferred method. Rollups execute transactions outside of the L1 blockchain and send the data back to the main Ethereum network. As such, rollups’ primary function is to address two bottlenecks for Ethereum - data and computation (e.g. fraud proofs or SNARKs).
That said, rollups are not perfect in their design. While SNARKs can be embedded into other SNARKs in perpetuity in terms of computation, data is the limiting factor. As we’ll touch on in the following section, this can be achieved because an L3’s validity proof is combined into the L2’s validity proof, which is then posted to L1. This directly ties back to how rollups can scale almost limitlessly in terms of computation: only a few actors are required to actually verify a block. All other actors perform a very small computation only to ensure validity. Hence, SNARKs on SNARKs on SNARKs are great in terms of computation as it results in a single proof for the L1. Rollups also compress on-chain data. ZK solutions are particularly exciting here, as they offer ~8x data compression. For a simple token transfer, they reduce the data from 100 to 16 bytes. Or for a concrete example, accounts could be represented by an index rather than an entire address. However, rollups still need the data available to be accessible and verifiable on-chain. In terms of the L1, once the data has been compressed once, there is no “second compressor” that can achieve another round of compression (e.g. the same logic put into the first data compression can be put in a “second compressor,” but it will only result in the same net benefit to the L1). In simpler terms, unlike computation, data cannot be compressed again and again. In this sense, it doesn’t exponentially scale the blockchain by stacking rollup upon rollup.
The differences between ZK-SNARK and ZK-STARK :
• ZK-STARKs can also prove 10x faster than ZK-SNARKs.
• However, ZK-STARKs’ one present downside is that the technology is not very mature, which limits its generalizability.
Comparing the Layer 2 landscape
We will primarily focus on the zero-knowledge rollups in this section, specifically zkSync and StarkWare. That said, there are many teams working on rollup technology, including Arbitrum and Optimism’s optimistic rollups, as well as Type-I and Type-2 zkEVMs from Taiko, Consensys, the Ethereum Foundation, and more. It should be noted that ZKRs offer greater throughput than Optimistic Rollups (~2000 TPS vs ~500 TPS), the withdrawal period is minutes/hours vs 1-2 weeks, and privacy is easier and cheaper to achieve. However, EVM/Solidity compatibility is more difficult for ZKRs and L2 transactions are more hardware-intensive. EVM-compatibility is a spectrum. Projects that opt to be more compatible (or even Ethereum-equivalent) aren’t inherently “better” than alternatives. Greater EVM-compatibility means less friction for developers, but it comes with significant downsides such as handicapping the speed with which teams can innovate and ship upgrades. For ZKRs, the primary differences between STARKs and SNARKs lie in proof size, the setup procedure, and quantum computer attack resilience. STARKs generally have more favorable setup conditions in terms of decentralization and they are post-quantum secure. ConsenSys notes that “once quantum computing is largely available,” SNARKs’ privacy technology will largely be broken. At that point however, the industry will have many more problems, such as the breaking of most wallet infrastructure. SNARKs were also discovered much earlier than STARKs, so the technology for the latter is less mature. Also, SNARKs have a far smaller proof size (meaning less gas and time are required). For a brief comparison of the rollup technologies, refer to the graphic below.
Beginning with zkSync, the MatterLabs team launched to mainnet in 2020 with a SNARK-based rollup and later released v2 to testnet in early 2022, a 99% EVM-compatible ZKR. Commendably, the team is markedly committed to open source software development when compared to other ZKRs. Because MatterLabs chose SNARK technology, the team underwent a one-time trusted setup period, which temporarily sacrificed decentralization and increased trust assumptions; STARK-based systems comparatively use trustless verifiable systems from the outset. At the same time, SNARKs are slower than STARKs. With zkSync v2, Solidity and Vyper first compile to an intermediate language (Yul), then compile it to zkEVM bytecode through LLVM. To compile directly to bytecode using LLVM and increase developer ease-of-use, zkSync is working on their native language, Zinc (a Rust-like framework for ZKPs). As of December 2022, zkSync sits at $54m TVL for a 1.27% of the Ethereum L2 market share. There are 219 projects listed as building in their ecosystem.
StarkNet launched to testnet their STARK-based ZKR over one year after zkSync in late 2021. Two core advantages of STARKs over SNARKs lies in the ~10x increase in the speed and smaller computation size, plus they don’t require an initial trusted setup; the tradeoff is generalizability. The network leverages Cairo, a STARK-provable language. An important design decision to consider for application builders, StarkNet is less focused on EVM-compatibility; that said, the team at Nethermind developed a transpiler to convert Solidity code to Cairo called Warp. A core part of StarkWare’s stack, StarkEx is a SaaS toolkit for scaling applications like decentralized exchanges. StarkNet has 0.11% of the total L2 market and has $4.8m TVL. There are 121 projects building in the StarkNet ecosystem. Currently, both ecosystems are focused on decentralization of their protocols with airdrops speculated to launch in the near future.
Layer 3s and beyond
While Layer 2s increase the performance of mainnet Ethereum - inheriting its security - Layer 3s further implement a degree of customized scaling. Vitalik Buterin discussed in a recent blog post the feasibility of certain types of L3s. Although we cannot simply stack “layer upon layer” to achieve infinite scalability, Layer 3s, in combination with practical programming languages, could be a significant step towards wider crypto adoption.
L3s carry a few magical properties. From a user perspective, one can deposit and withdraw cheaply between L2s and L3s, all without ever interacting with the L1. While this would require waiting for the proof window and typically would incur a high cost of batching a large number of transactions to the chain, this can be mitigated by the efficiency of a “ZKRs within ZKRs” structure. As mentioned earlier, only a small handful of actors perform most of the computation in this setup, and many validity proofs can be combined into the L2’s validity proof, which is then funneled into a single proof on the L1. L3s are also a natural fit for application-specific rollups. This structure enables huge amounts of customizability over your own environment (such as fees, throughput, value capture, etc) while retaining the network effects of a shared settlement layer. Once more app-chains begin to launch and prove to be successful, we could very well see a snowball into an app-specific ZKR-dominated future. They uphold most of the advantages of shared execution layers without the downsides; the token now captures execution fees and MEV, along with each app’s native token utility and value capture mechanisms. Incentives are important in crypto. These are all factors that incentivize developers to deploy ZKRs rather than mainnet smart contracts, depending on the specific needs of the application.
Let’s look at a practical example. Starkware laid out their vision for an app-specific L3 architecture atop their network. There are a few main design considerations to go over with regards to their approach. First, L3s do not offer generalized scaling in the way StarkNet or zkSync does. Rather, each L3 should be thought of as an app-specific, customized scaling solution. Second, this structure has diminishing trust the higher up you go; StarkNet offers trustless scaling while L3s and L4s are weakly-trusted. One might wonder why L3s like Validiums and privacy solutions would anchor to the L2 as opposed to the L1 (as is most common today). One of the primary benefits of this approach lies in interconnectedness. The widespread bridge hack problem is well-known within the industry. Of course, other ecosystems including Cosmos opted to solve for interoperability and decentralization first, working towards security later (see: Atom 2.0 and Interchain Security). Conversely, Ethereum prioritized security and decentralization, pushing “cross-chain” infrastructure out to the L2s. If we see widespread adoption of a handful of L2s with blossoming L3 networks, this is essentially Ethereum’s answer to interoperability. This is a critical step for widespread adoption of crypto, similar to the point in internet history when we began agreeing upon protocol standards. Barriers to entry lower, institutions and retail enter safely, and the network’s architecture is solidified.
Rollups inherently have drawbacks in their approach to scalability, notably in their data bottleneck. Scaling through Layer 3 is one way to solve for native interoperability - app-specific use cases that are optimized for different purposes. Similarly, much has been written on the real bottleneck within crypto: applications that users want to use. While the past two years have seen great advancements in terms of infrastructure, we are now reaching a point beyond the chicken-and-egg problem; that is, do we first build better infrastructure and enable better UX and innovative use-cases for apps, or do we first try and get wider adoption on our existing rails? Today, we have ample blockspace. Now, we need applications with orders of magnitude more users. L3s will likely play a large part in this narrative shift.
We see a need for both approaches to EVM compatibility, and StarkNet and zkSync are well-positioned for adoption of their respective application layers. Both ecosystems are primed for growth as the bear market sees more and more developers looking to leverage efficient scaling technologies without sacrificing security or Ethereum’s economic bandwidth. If there’s anything this year has highlighted it’s the importance of security and decentralization. When compared to optimistic rollups, zk-rollups are far less mature, but we expect that to change over the next 5-10 years.
Bearmarkets are for building, reading and fundamental analysis. No spam, just alpha
