You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets.
Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:
- Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
- Early access to future CORE ratings: Being early is sometimes just as important as being right!
- Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
- CORE report Audio playback: Don’t want to read? No problem! Listen on the go.
ZK-rollups and their proofs
ZK-rollups are significantly more computationally intensive than optimistic rollups but can scale much greater. This is because optimistic rollups require a witness for each transaction, whereas ZK-rollups bundle transactions into a fixed-size proof. Therefore, optimistic rollups scale linearly with the number of transactions, whereas ZK-rollups scale poly-logarithmically.
In the case of a ZK-rollup, the operator generates a cryptographic proof called validity proofs (SNARK or STARK) for the state root, which proves the rollup smart contract on Ethereum that the received state root was the result of execution of a valid series of transaction. This makes it impossible for the operator to send an invalid state root.
ZERO-KNOWLEDGE ROLLUPS TLDR
The process works as follows:
- Highly-compressed batches of transactions are combined with the current state root
- The combination is sent to an off-chain Prover
- Prover computes the transactions, generating a validity proof of the results
- Prover sends this to an on-chain Verifier (Ethereum nodes)
- Verifier confirms the validity proof
- Smart contract on Ethereum’s L1 that maintains the state of the rollup is updated to the new state
ZK-rollups use two types of validity proofs: SNARK and STARK. SNARKs are used by ZK sync, Scroll, Polygon ZkEVM, etc., while StarkNet and StarkEx use STARKs.
SNARKs and STARKs
Let's break down what the different aspects of "zkSNARK" actually mean.
zk: preserving user privacy
S: succinct proofs can be confirmed in a few milliseconds. Rather than confirming each transaction individually, Ethereum validators can examine a tiny proof to determine the legitimacy of transactions. Smaller proofs = faster verification = more transactions per second.
N: non-Interactive signifies that the prover just needs to send a single message to the verifier, as opposed to exchanging messages back and forth. Non-interactivity is necessary because the prover may generate a single evidence that can be verified by anyone, anywhere in the globe. Without ever having to communicate information with the prover
ARK: generates trusted proofs off-chain.
Under the hood, StarkNet compresses thousands of transactions into a single validity proof called ‘STARKs’ (Scalable Transparent Argument of Knowledge), co-invented by Starkware President Eli Ben-Sasson, that's submitted to the Ethereum L1. Starkware’s STARK technology has two primary advantages over SNARKs (used by ZKR-competitor ZkSync): 1) It doesn't require an initial trusted setup (like in zkSync v1), and 2) they’re ~10x faster to compute than SNARKs. Because the computational effort necessary to verify STARK proofs is significantly less than actually proving the computation, StarkNet can increase Ethereum scalability by orders of magnitude.
These are the most popular and widely used non-interactive zk proofs. They're both non-interactive zero-knowledge proofs, meaning there's little interaction between the prover and verifier. Both of these proofs are much smaller in size than an average Bitcoin transaction. They both scale the Ethereum network.
Image: Comparing STARKs and SNARKs. Source: Sdyshi\Twitter
zkSNARK proof sizes are smaller. Therefore, it takes less time to verify and costs less gas. While zkSTARKS proof sizes are bigger and take more time to verify, it costs more gas than zk SNARK. zkSTARK TPS limit is higher than zkSNARK and is more scalable.
Starkware
Starkware is a ZK-rollup company that pioneered zero-knowledge-based rollups in 2018, launched StarkEx in 2020, and recently released StarkNet in November 2021. StarkEx is a ZK-rollup with less functionality than its StarkNet successor. StarkEx supports the ability for smart contracts to run any arbitrary logic for specific use cases, such as trading and NFTs, while StarkNet enables more general use cases.
Since its creation in 2018, Starkware has raised $110+ million across three equity rounds and received a $12 million grant from the Ethereum Foundation. Not only is the project backed by heaps of money, but prominent crypto and financial figures, including Pantera Capital, Sequoia, Founders Fund, DCVC, Paradigm, ConsenSys, Multicoin, Polychain, Vitalik Buterin, Naval Ravikant, and others, have also invested in Starkware.
StarkEx is the first iteration “scalability engine” from Starkware that now supports two versions: ZK-Rollup mode and Validium mode (discussed below). Validiums can be custom-tailored to offer superior performance for specific dapps and use cases, such as DeversiFi, ImmutableX and Sorare.
StarkNet is Starkware’s next iteration of a ZK-rollup and the first ZK-rollup to feature general smart contracts on a fully composable network in a permissionless manner. Composability refers to the ability for applications to coordinate, build on top of one another, and interconnect—something for which StarkEx isn’t designed.
StarkEx
StarkEx is a framework used for creating permissioned, application-specific scaling dApps. StarkEx has been deployed on Ethereum since June 2020. Every application deployed on top of StarkEx has its business logic.
Transactions executed on the applications built on top of StarkEx are sent to the StarkEx service, where a group of transactions is put together in a batch. This batch is then sent to SHARP, i.e., a shared proving service where proof is generated. Any application can use this shared proving service called SHARP. A STARK proof generated from SHARP is then sent to the STARK verifier for verification purposes, and then an on-chain state update is sent to a StarkEx contract.
Image: The SHARP process on the Ethereum blockchain.
User data can be made available through various data availability modules:
- ZK-rollup mode (vault balances are published on-chain as call data, which provides built-in trustlessness)
- Validium mode (User balances are stored off-chain with well-known and trusted parties of a data availability committee. Data is accepted only if at least a quorum of the committee members signs on it.)
- Volition mode (User gets a choice between ZK-rollup mode and validium mode for every transaction)
Two key differences that make StarkNet and StarkEx different from other rollups are the use of validity proofs called STARKs and the use of Cairo as the native smart contract language. To understand how they're different from other rollups, consider the differences between STARKs used by Starkware scaling solutions and SNARKs used by other ZK-rollups
Cairo
StarkNet and StarkEX don’t use Solidity, the preferred Ethereum smart contracting language, because it isn’t the best language to compile to STARKs. This is because Solidity can't be efficiently encoded to STARKs and is costly in comparison.
StarkNet uses a new programming language developed by the team at Starkware called ‘Cairo.’ It’s a language for programming STARKs that achieves Turing completeness with STARKs. A breakthrough of the Cairo language is it lets just one verifier use a single proof to confirm the integrity of many different program executions. This amortizes costs across separate dApps, e.g., a single proof that includes both dYdX trades and SoRare transactions.
Initially, Cairo was designed as an assembly language and was written as a low-level language. This makes it harder to code in Cairo. After various feedback from developers, the Starkware team made Cairo more developer friendly and continuously improved it.
Cairo is a language for writing provable programs, and the execution of a Cairo program produces a trace that can then be sent to a prover. This generates a STARK proof of the validity of the instruction or calculation represented by the Cairo program. A verifier can then check this proof. StarkNet helps achieve scalability by lowering the barrier of entry to using proofs. This is because of Cairo—when written in Cairo, the code is proven off-chain, and once it’s validated on-chain, the dapp can use the result with confidence, as if it had run it on-chain.
Image: Cairo ~1% DeFi TVL (Mostly dYdX). Source: Delphi Digital\DeFiLlama
Therefore, Cairo ameliorates Ethereum’s expensive computation, transmission, and storage fees. To link the Cairo code to the smart contract, a Shared Prover (SHARP) is used. This involves a prover off-chain, a smart contract verifier on-chain, and a fact-logger contract on-chain. The prover proves the code is valid and sends this proof to the verifier, which then attests the proof’s validity in the fact register. This fact functions as a seal of approval without trust, certifying the validity of the Cairo program. Now, dapp’s smart contract needs to verify this fact exists and then it can rely on the computation that is performed off-chain.
As a result, the team is working with @nethermindeth to create Warp, a transpiler that seamlessly converts solidity smart contracts into Cairo to make Starkware EVM-compatible. WARP is the first automated Solidity compiler that allows programs written in Solidity to be deployed on StarkNet. It also provides a smoother transition for companies moving from ETH L1 to StarkNet L2. Finally, as of November 2022, Cairo 1.0 has been open-sourced, allowing anyone to review the code.
