Key Terms

TLDR

• STARKs are an exciting validity proof technology that is considered more scalable, trustless, and resistant to quantum computing than alternatives such as SNARKs. However, they are less tested in practice.
• StarkWare has demonstrated the enormous scaling potential of its technology with StarkEx products dYdX, Immutable, Sorare and Deversifi. It is now rolling out a permissionless smart contract platform in StarkNet which already has a number of high-quality teams building on it.
• StarkWare uses Cairo - a language it invented that is optimized for validity proofs. Potential issues include the language being relatively unfamiliar to developers and untested.
• StarkWare has plans to scale Ethereum to L3. L3 is to L2 what L2 is to L1. The potential scalability here is astounding, however, it remains to be seen how this plays out in practice.
• STARKs are not actually zero-knowledge, meaning that privacy isn’t incorporated by default. This is arguably a positive thing due to regulatory discomfort around privacy-preserving technologies such as Tornado Cash. However, StarkWare offers an excellent environment to build privacy-preserving applications.
• StarkWare is building some of the most exciting scaling technology that, if properly executed, could literally bring billions of people on-chain. In addition, they will likely launch a token in the future so it could be worthwhile paying attention to this ecosystem and playing around with some of the dApps.

Introduction

Ethereum Layer-1 (L1) is plagued with scalability issues as its decentralized consensus mechanism makes it slow and expensive. ZK-Rollups have long been heralded as the most exciting development in Ethereum scaling. Overall, many people share the view with Vitalik Buterin that Optimistic Rollups will be more prevalent in the short term because of their easy EVM compatibility and lesser technological complexity, while ZK-rollups are expected to prevail in the medium-to-long-term as the technology matures. Note that some Optimistic Rollups have stated intent to pivot towards Validity Proofs in the future if it becomes apparent that they can overcome EVM compatibility and equivalence challenges.

This report will explore StarkWare - which is developing some of the most exciting rollup solutions: StarkEx & StarkNet.

Introduction to ZK-Rollups

ZK-Rollups batch a large number of Layer-2 (L2) transactions that were executed off-chain, generate a validity proof regarding the transactions, and submit this validity proof as one transaction onto Ethereum where it is verified autonomously by a smart contract. Most ZK-rollups generate these proofs using zero-knowledge encryption, which enables one party to prove to another party that they know something without needing to tell them exactly what they know. Therefore, not all of the transaction data has to be included in the proof, making it efficient and also useful for privacy use cases. Proofs are verified on-chain instead of all the individual transactions, enabling huge scalability.

Note that because StarkWare does not actually use zero-knowledge technology, it does not implement any privacy by default. This is a point of confusion - however, given that the wider industry generally categorises StarkNet and StarkEx as ZK-Rollups - this report will do so as well.

Since ZK-Rollups do not depend on network participants to challenge transactions, withdrawals from L2 to L1 can occur as soon as the validity proof is confirmed on L1. However, generating these proofs is very complex and computationally intensive. Starkware has a centralized prover due to the challenges of decentralizing at this relatively early stage of development.

At a high level:

• ZK-Rollups batch a large number of off-chain transfers and generate a cryptographic proof regarding their validity.

• These proofs can be STARKs (StarkEx, StarkNet), or SNARKs (ZK-Sync, Aztec Network -(not covered in this report)). These validity proofs are then posted to the Ethereum L1. The proof is then verified on L1, therefore, benefiting from the decentralization and security of Ethereum.

• ZK-Rollups maintain the state of L2 transactions which is only updated by validity proofs.

• As a result, ZK-Rollups only require a validity proof rather than all the transaction data. This massive reduction in data means that transactions are far cheaper and faster. Verification is exponentially smaller than the size of the proof.

• Furthermore, as a result of this validity proof, there is no long delay (as seen with Optimistic Rollups) in moving from L2 to L1.

At a slightly lower level, a ZK-Rollup comprises 2 key actors - transactors and relayers/sequencers.

• Transactors broadcast their transfer across the network.
  • The smart contract stores this data in 2 Merkle trees, respectively:
    • The addresses
    • The transfer amount(s)
• Relayers collect a large number of transactions and create an aggregate, and generate the validity proof. This proof represents the change in the blockchain state.

Considerations

SNARKs (as used by zkSync) have an initial trusted setup whereby a small group of developers has asymmetric knowledge of the initial trusted state. This poses some centralization risk. Note that the STARKs used by StarkWare avoid this issue - there is no backdoor for developers.

OR vs ZKR Cheat Sheet

The following cheat sheet is provided to contextualize ZK-Rollups in the L2 space. Check out our report on Arbitrum here.

Proofs

ZK-Rollups Validity proofs relying on cryptography. Complex and computationally intensive.

Optimistic Rollups Fraud proofs are initiated by validators who identify incorrect transactions. Less complex.

EVM compatibility

ZK-Rollups Complex, only limited applications live today but a Solidity transpiler is being developed.

Optimistic Rollups Easy, live today and first to market.

Withdrawal back to L1

ZK-Rollups As soon as the proof is verified on L1 (can be up to a few hours). Instant withdrawals are also possible with bridging protocols such as Hop or Synapse.

Optimistic Rollups Up to 2 weeks to leave room for fraud disputes, but products like Synapse or Hop can mitigate this and reduce it to minutes.

Computation

ZK-Rollups

• On-chain: Lower
• Off-chain: High (Validity proving is very computationally intensive).

Optimistic Rollups

• On-chain: Higher (needs more data on-chain for fraud disputes). However, fraud proofs only occur in the event of a challenge.
• Off-chain: none (all assumed to be valid).

Operating

ZK-Rollups Requires powerful machines, currently done by one operator (StarkWare) for StarkEx and StarkNet.

Optimistic Rollups Sequencers are responsible for ordering transactions from L2 bundles that are then committed at L1. Currently centralized.

Sentiment

ZK-Rollups

• Short term: Dominant for “simpler” tasks (payments, exchanges, application-specific tasks etc.)
• Medium-Long term: Dominant overall as the technology matures.

Optimistic Rollups

• Short term: Dominant for general-purpose EVM computations due to “first-mover advantage” and ease of EVM compatibility
• Long term: Likely less competitive if ZK-Rollups fulfill their potential and decentralize satisfactorily.

General Approach

ZK-Rollups 'Guilty until proven innocent’ approach to verification.

Optimistic Rollups ‘Innocent until proven guilty’ approach to verification.

StarkWare

• StarkWare was created to solve the scalability and privacy problems with blockchains (currently focused on Ethereum). It offers two products - StarkEx and StarkNet.
• StarkWare recently closed an investment round at an $8b valuation. Additionally, it is openly supported by both the Ethereum Foundation - which gave a $12m grant, and Vitalik Buterin.

STARKs

• STARKs are a type of validity proof used by StarkWare and were co-invented by StarkWare co-founders Eli Ben-Sasson and Michael Riabzev. Some view STARKs as a superior ZK-Rollup technology to SNARKs because:

  1. STARKs remove this requirement of a trusted configuration that is needed with SNARKs, removing the risk of those parties compromising the entire system. Instead, STARKs use publicly verifiable randomness to create trustlessly verifiable computation systems.
  2. STARKs are more scalable than SNARKs regarding computational size and speed.
  3. It is currently understood that STARKs are quantum-resistant, whereas SNARKs are vulnerable to quantum computing attacks.

• However, STARKs do have larger proof sizes than SNARKs and therefore require ~10x more gas.

• With STARK proofs, computations occur on an off-chain prover which is then verified by an on-chain STARK verifier.

• Verifiers can confirm state changes based on the proof and without the requirement to view all information regarding the transactions. This lack of information required is how StarkEx and StarkNet derive their scalability.

• Moving the majority of computation off-chain using STARKs enables high scaling while maintaining the integrity of the cryptographic computations.

Considerations

• One potential pitfall of STARKs is that they are newer technology and therefore less tested than SNARKs. In addition, StarkWare uses Cairo, which is a relatively unknown computing language optimized for validity proofs. This is difficult to make compatible with the EVM, however, a Solidity to Cairo transpiler is currently being developed by Nethermind. It will be interesting to see how effective this is when it is shipped.

Cairo

• StarkWare created a language called Cairo in order to optimize for the generation and verification of validity proofs.

• On StarkEx (using Cairo), the off-chain component enables more complex business logic while still being able to communicate with on-chain smart contracts and ensuring security as all changes are verified by the validity proof. This off-chain computation is the key to StarkWare’s scalability.

A key benefit enabled by Cairo is The Shared Prover (SHARP).

This is the link between Cairo code and Smart Contract Solidity. SHARP comprises 3 main parts:

• An off-chain prover
  • This takes the execution of the program and proves that it is valid.
• An on-chain smart contract verifier
  • The proof is sent to the verifier - who confirms whether it is correct or not.
• An on-chain fact logger contract
  • This is a certification that the Cairo program was executed correctly,

This will be especially important for lower throughput dApps that would otherwise not be able to function with higher transaction fees. Following this, the dApp’s smart contract just needs to verify that the fact exists to rely on the off-chain computation.

Due to the nature of StarkEx and Cairo, a big uptick in market activity should actually result in cheaper transactions (which is an inverse of what happens on L1). However, this is only true to a certain extent as all technology has an upper limit (which is unclear with StarkWare’s products as of now).

Issues

• Although Cairo is a language optimized for generating STARK proofs, it is relatively untested in practice. STARKs themselves were first proposed only in 2018.
• The key disadvantage of Cairo is that it is a new and relatively inaccessible language that very few developers know. To build on StarkNet or StarkEx they would be required to learn this new language. However, this issue is being addressed with a Solidity-to-Cairo compiler.
  • However, this should not be seen as a ‘disadvantage’. The language is optimized for validity proofs, and in the longer-run developers could learn Cairo rather than Solidity - as they will be able to build superior applications.

StarkEx

StarkEx is a deployable self-custodial tool for high-performance dApps. It can be thought of as a scaling engine or ‘scaling-as-a-service’ for dApps. NFT minting, transfers, and trading are currently enabled on StarkEx.

Examples of projects using StarkEx include:

• dYdX (perpetual contracts trading)
• DeversiFi (trading)
• Immutable X (gaming and NFTs)
• Sorare (NFT sports game).

The following graphic shows the significant total activity on StarkEx.

Source: StarkWare

All dApps that use StarkEx have an off-chain component that executes transactions and holds the state of the off-chain system, while periodically sending updates to the on-chain component. This on-chain component ensures that state transitions are valid.

The following diagram offers a high-level overview of how StarkEx works: Source: StarkWare

Validium

Validium is a mode whereby the data is stored off-chain rather than on-chain. This makes transactions significantly cheaper, but the data is less available and more at risk of getting lost.

• Transaction fees are so low with Validium that users of Immutable X do not pay any fees (at present).
• Validium mode has less data availability compared to the typical rollup mode. This essentially means that data is less ‘available’ than what it would be if it was on-chain, meaning that Validium is less secure than rollup mode.
• Note that Validium is technically not a rollup, as data is not stored on L1. However, this is arguably semantics as the validity proof is still posted and the state root of the Merkle tree is also posted.

In rollup mode, on-chain data availability is secure and easy to access, however, it is more computationally expensive and therefore users need to pay more for this security.

Enter Volition

Volition enables users to decide at the per-tx level as to whether or not they want to use the Validium or on-chain data mode. In other words, users can select how much data availability they want to attach to their transaction.

Simply put, there is a choice between security and cost. If you keep data on L2 you will take an additional layer-2 security risk. If you pick an untrustworthy, faulty or malicious data availability provider you are at risk. In Validium mode, there is a data availability committee with multiple members. In order for the data to be lost, all would need to misbehave. A potential way this could be viewed is like cloud providers today. Your data is in the cloud - which can be hacked. This is similar to how L2 data availability in Validium works.

Users can therefore pay for the data availability/security that they actually need which will vary based on the level of security the specific application may need. For instance, a gaming application may need less security guarantees than a financial product for the goal of higher scalability and better gameplay mechanics.

Composability Currently there is no composability between StarkEx instances. However, in the future, StarkEx is proposed to send transactions to StarkNet which will, in turn, be confirmed on Ethereum L1. This is the L3 model which will be discussed below. StarkEx on L3 will have the advantage of much easier and cheaper interoperability between StarkEx instances.

Teams building using StarkEx will be able to tap into existing functionality (e.g. NFT minting, transfers, and trading) straight away. New functionalities, however, need to be assessed on a case-by-case basis. This means developers can get the same backend blockchain engineering as existing applications.

StarkNet

StarkNet is a permissionless ZK-Rollup network that will support sophisticated smart-contract applications. StarkNet is designed for general-purpose computation e.g. similar to what Ethereum is like today. StarkNet uses the Cairo programming language, and already has a large number of applications building atop it. A Solidity to Cairo compiler is currently being developed to make it easy for legacy Ethereum dApps to launch on StarkNet. Unlike StarkEx, StarkNet will have mechanisms for governance and become community-owned and governed.

Source: StarkWare

• StarkNet is in the process of being deployed with full functionality. StarkNet Alpha has been launched and is live on mainnet.

• Applications such as MakerDAO have pledged to deploy on Starknet - which will allow direct minting of DAI there.

StarkNet has three phases:

1. Planets

• This phase comprised single-app rollups, enabling the first phase of developers to build and deploy smart contracts.

2. Constellations

• This is the current stage of StarkNet, in which composability between applications has been enabled.

3. Universe

• This is the phase by which StarkNet will be decentralized. As of now, it is highly centralized, and there is much to be done before it reaches the Universe phase. The team is working on developing sequencing and proving software suitable for widespread use in pursuit of this decentralization. Furthermore, the team has tentatively set the goal of achieving some meaningful progress on decentralizing by the end of 2022.

• StarkNet seeks to decentralize the sequencer layer eventually so that anyone can be a sequencer (handle proofs and state updates). It remains to be seen how this will actually transpire in practice, and how profound the influence of StarkWare will remain.
• StarkNet currently has no fees. Fees will be introduced in the future to cover the cost of gas on L1.

L3

The ambition of the StarkWare ecosystem is to expand beyond L2 scaling to L3 scaling. L3 is to L2 what L2 is to L1. The proposed L3 would be an application-specific layer built atop L2 (StarkNet). This means that StarkEx, which currently operates as an L2 solution, will be ported to L3. This opens up enormous scalability potential for the StarkWare ecosystem.

The following diagram shows how the L1-L3 ecosystem would operate in practice, with all layers inheriting the security of L1, directly (L2), and indirectly (L3+).

Source: StarkWare

At a high level:

• Transactions processed on L3
• Proofs of batches sent to L2
• Proofs are verified on L2
• Multiple proofs are rolled into a single proof that is submitted to Ethereum L1

L3 Enables:

• Increased developer control of their technology stack, optimizing for their specific application.

This includes:

• Customized data availability
• More deterministic cost and performance

• Faster deployment of new features

• Hyper-scalability by leveraging the multiplicative effect of recursive proving.
  • E.g. if each layer results in a 100x reduction from the previous layer.
    • L2 (100x reduction) x L3 (100x reduction) = 10,000x reduction from L1.
• Privacy
• Easier interoperability between L2 ←-> L3 vs L1 ←-> L2.
  • On/off ramping is highly expensive between L2-L1. The massive cost reduction of L2 makes L3-L2 interoperability far easier and cheaper.
  • StarkWare argues that the latency of moving assets between L2-L3 is longer than applications on the same L2, however, the cost and throughput are still comparable.
• L3-L3 interoperability improves for the same reasons discussed above.
• StarkWare proposes that L3 could be used as a ‘Canary Network’ - similar to the Polkadot-Kusama model. This would be an interesting development and could even foster greater innovation in the Ethereum ecosystem.

Source: StarkWare

The diagram above illustrates the envisioned rollup-centric hyper-scalable Ethereum ecosystem. As demonstrated above, the hypothetical L3s are application-specific, whereby they can have greater freedom in optimizing their application than building on a more generalized system in L2.

Issues

One thing that should be noted is that L3 is obviously a layer further away from L1 than L2. The additional risk of this added layer of separation is yet to be properly determined. Of this, there can be smart contract risk, censorship risk, runtime risk, and more.

Interestingly, StarkEx will move from L2 to L3, as well as certain instances of StarkNet. This is an exciting prospect, however, it should be noted that it is currently theoretical and has not yet been implemented in practice - this will be the true test of whether or not it will operate as intended. As of now, it is unclear what scaling limit there is for this technology, meaning there could be some unintended consequences of pursuing an aggressive L2-L3 strategy.

Privacy

It is a common misconception that StarkWare is a zero-knowledge protocol and therefore has privacy-preserving transactions by default. This is not true, and all transactions are visible on the Voyager explorer.

That said, privacy protocols may be deployed atop StarkNet - which should be suited to them due to the high levels of computation such applications generally require and the scalability and cost-effectiveness of deploying on StarkNet.

The lack of privacy by default is arguably a positive feature of StarkNet. Privacy-preserving applications such as Tornado Cash have attracted negative attention from many regulators as they have been used for laundering stolen funds. A privacy-first protocol could suffer in a regulatory environment that bans untraceable funds from entering the system. However, there is interesting potential for privacy-preserving applications that are GDPR compliant for example.

Ecosystem

Immutable X will be launching their entire product suite on StarkNet. It will support multiple rollups in the StarkWare ecosystem, each of which is able to optimize its respective ecosystems for various games. Beyond that, Immutable envisions that projects will build different parts of their Game in parallel on different StarkWare Rollups. Immutable’s rollups will be interconnected and interoperable with trust-minimized bridges (as they are Ethereum bridges). All transactions will benefit from the security and decentralization of the Ethereum mainnet.

With regards to L3, projects going alone will encounter some liquidity and composability issues. However, if building an Immutable supported rollup - the project can tap into the entire Immutable X ecosystem.

Immutable X claim that their indexing APIs will enable them to support assets across the StarkWare ecosystem, with trust minimized bridges enabling the free and secure flow of liquidity between compatible rollups.

Note that none of this can be seen in practice yet.

Read more about it here.

StarkGate StarkNet’s native bridge called ‘StarkGate’ has been live since May 9th 2022 and has a TVL of 260 ETH (~$520k) at the time of writing. There is a hard cap total bridge limit of 175 ETH that routinely gets lifted. StarkGate Alpha currently only supports ETH. Additional tokens such as WBTC, USDC, USDT, and DAI.

In order to reduce risks involved in using an Alpha version, the bridge will limit the amount of ETH, in addition to limiting the maximum amount of ETH per transaction too. There will be plans to gradually ease the limitations and lift them completely as confidence grows.

Check out the StarkGate Bridge on Nansen here.

List of Projects

Check out a comprehensive list of projects building on StarkNet here. The sheer number of projects and the quality of the projects is a bullish indicator for StarkNet.

DeFi

ZigZag Exchange (Website/Twitter)

• ZigZag Exchange is an order-book based DEX and will be launching on both zkSync and StarkNet

JediSwap (Website/Twitter)

• Jediswap is a fully permissionless and composable AMM on Starknet. The protocol is built by the same team behind Mesh Finance.

zkLend (Website/Twitter)

• zkLend is a lending and borrowing protocol built on StarkNet. The protocol offers a dual solution: a permissioned and compliance-focused solution for institutional clients and a permissionless service for regular DeFi users.

Check out their AMA with Nansen Alpha here.

StarkSwap (Website/Twitter)

• StarkSwap is building the next generation of DeFi on StarkNet. The first offering is an AMM, with other DeFi products to follow.

DeFi Bluechips Notable DeFi protocols that have announced intentions to launch on StarkNet include:

• MakerDAO
• Aave

NFTs/Gaming

Aspect (Website/Twitter)

• PlayOasis is an NFT marketplace powered by StarkNet.

Loot Realms (Website/Twitter)

• Loot Realms is a multiplayer on-chain game of economics and chivalry.

Wallets

Argent X (Website/Twitter)

• Argent X is the primary StarkNet wallet to interact with DApps and tokens.

Braavos (Website/Twitter)

• Braavos is another key wallet for StarkNet.

Key Takeaways

• StarkWare offers validity-proof rollups - not ZK-Rollups. StarkWare’s inherent lack of ZK technology is arguably a positive thing, as its scaling potential combined with increased regulatory scrutiny make privacy-focused technologies vulnerable to being shut down. An example of the problems with privacy is Tornado Cash - which has been used for laundering stolen cryptocurrency and has (rightly or wrongly) drawn the ire of regulators. That said, StarkWare’s products are well suited to hosting computationally intensive privacy-preserving applications, which will also be an important part of the economy going forward with regards to GDPR etc.
• The scalability issues that StarkWare claims to be capable of solving are extremely exciting, however, some caution should be exercised. Claims of an unknown upper limit to scalability are exciting, but untested in practice. Further, the Cairo language is relatively new and untested. In particular, it will be interesting to see how the L3 concept plays out in practice. The additional layer undoubtedly adds security risk, making the entire system highly reliant on the quality of StarkWare’s coding.
• StarkNet is an extremely exciting development if executed correctly. It will be interesting to see how the team decentralizes it. It is difficult to see how they could do this without a token, which they are widely expected to launch at some point.