The Rollup War - Overview of Starkware

Author: Madoka Kaname, IOBC Capital

Currently, the development trend of Ethereum is increasingly leaning towards modular blockchains.

Under the architecture of modular blockchains, transaction computation and execution on Ethereum are no longer handled by the mainnet; this part of the work is transferred to off-chain Layer 2, which alleviates the burden on the mainnet and significantly expands Ethereum's performance.

In the future, the Ethereum mainnet will only be responsible for achieving consensus and data availability, while Layer 2, which undertakes all computation and execution, will take on a role similar to that of cloud service providers, akin to today's Amazon Web Services and Alibaba Cloud.

Rollup

Among the Layer 2 scaling solutions, Rollup is considered the most promising.

Rollup completes transaction validation and computation off-chain on Ethereum and packages them, returning the compressed data along with the updated state root to the mainnet, thereby reducing the space occupied on the mainnet.

There are two implementation schemes within Rollup: Optimistic Rollup and zk-Rollup. Among them:

Optimistic Rollup uses fraud proofs, initially assuming that all transactions uploaded to the main chain are legitimate and setting a challenge period, allowing validators to present proofs to challenge problematic transactions. Once fraud is confirmed, the fraudster is punished, and the challenger is rewarded.

Zk-Rollup, on the other hand, uses validity proofs, validating and packaging all transactions off-chain, and when the validated transactions are submitted to the main chain, they are accompanied by zero-knowledge proofs to demonstrate the validity of the transactions. In the words of StarkWare CEO Uri, "It provides trustless computational integrity; it is the ability to ensure that the computation is executed correctly even without supervision." This is very similar to the early ideals of Bitcoin.

There are three main roles in Rollup:

• Sequencer: Primarily responsible for collecting transactions from users, ordering them, and sending the new Merkle root to the Layer 1 rollup smart contract, similar to miners.
• Prover: Responsible for computing and validating all transactions and generating a zk-proof to prove the validity of the transactions.
• Verifier: Typically deployed on Layer 1, responsible for completing part of the computation to verify the validity of the proof submitted by the Prover, ensuring that all necessary information for computational integrity is provided.

Optimistic Rollup is compatible with EVM, has a mature technical solution, and was implemented early, resulting in lower migration costs for developers. Representative projects like Arbitrum and Optimism currently hold the highest market share among rollups. In contrast, zk-Rollups are not EVM compatible, face greater technical challenges, and have slower development progress, making their applications less widespread compared to OP series rollups that can target smart contracts.

Despite this, zk-Rollup has several advantages over Optimistic Rollup, such as:

• Better scalability. This is because the data uploaded to the mainnet by zk-Rollups is smaller than that of Optimistic Rollups. Since zk-Rollups publish transaction information that has already been validated and accompanied by proof, others only need to verify the proof without needing to validate the transactions, thus avoiding the need to upload transaction-related data. In contrast, Optimistic Rollups require on-chain data due to the need to accept fraud proof challenges. In practical applications, zk-Rollup's performance enhancement capability is approximately ten times that of Optimistic Rollups.
• Shorter transaction finality time. Transactions published to the chain by zk-Rollups have already been validated and accompanied by proof, making verification relatively simple, usually taking around ten minutes. However, transactions submitted by Optimistic Rollups face fraud risks and must accept fraud proof challenges, which have a challenge time window of about one week, thus failing to achieve instant withdrawal functionalities.
• Higher security. Transactions uploaded by zk-Rollups are validated and accompanied by proof, reducing the likelihood of malicious behavior. In contrast, Optimistic Rollups may upload transactions containing fraudulent content, making zk-Rollups' data reliability and security higher.

Vitalik once said in 2021: "In the short term, optimistic rollups will win due to their EVM compatibility. In the medium to long term, as zk-SNARK technology improves, zk-rollups will win all use cases." It is evident that in the long run, Vitalik is more optimistic about zk-rollups.

zk-SNARK and zk-STARK

The two leading projects in the zk space are zksync and Starkware. Zksync uses zk-SNARK technology, while Starkware employs zk-STARK technology.

zk-SNARK stands for Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, while zk-STARK stands for Scalable Transparent Argument of Knowledge. zk-SNARK was developed earlier and is relatively mature, with widespread applications. The early privacy coin project Zcash used zk-SNARK technology. zk-STARK is considered an improved version of zk-SNARK, offering a faster and more convenient implementation aimed at optimizing some of zk-SNARK's shortcomings.

From their names, it is evident that zk-STARK has advantages in scalability and transparency compared to zk-SNARK. Additionally, zk-STARK offers higher security. The specific reasons are:

1. Scalability. With zk-STARK technology, the prover's running time is at most quasi-linear with respect to the computation scale, while the verification time is polynomial logarithmic in relation to the computation amount. In zk-SNARK, the prover may face complex and costly proof processes, along with correspondingly longer verification times.
2. Transparency. zk-STARK does not require a trusted setup, unlike zk-SNARK, which needs a trusted public reference string; instead, it uses a random public verifier, eliminating concerns about parameter compromise and modification.
3. Security. Since zk-STARK relies on hash functions for symmetric encryption, the collision resistance of hash functions provides resilience against quantum attacks.

Due to its mature technology and early launch, zk-SNARK remains mainstream in the zk field, while zk-STARK faces challenges due to its technical complexity and lack of developers, leading to limited adoption. However, with its undeniable advantages, zk-STARK is expected to become a more accepted solution in the future.

Starkware

Eli Ben-Sasson, the co-founder of Starkware, is a world-class cryptographic scientist, a professor at the Technion in Israel, and a co-inventor of zk-SNARK and zk-STARK technologies. The project is developed using the Turing-complete Cairo language.

Working Principle

The workflow of Starkware's products is illustrated in the following diagram:

Taking StarkEx as an example, the workflow of StarkNet is roughly similar.

1. Users first perform operations in the application, typically through the application's client or web front end. After executing these actions, the application sends transactions to the StarkEx service.
2. The StarkEx service packages and executes these transactions, sending the package to SHARP (Shared Prover), with the execution process completed by programs written in the Cairo language. Notably, StarkWare uses the Turing-complete Cairo language to convert all smart contract computation results into provable polynomial equations, allowing compatibility between smart contracts and validity proofs.
3. SHARP is a Stark-based proof system that generates proofs to demonstrate the validity of this batch of transactions.
4. SHARP sends the Stark proof to the Verifier deployed on Layer 1, which completes the verification.
5. The StarkEx Service sends an on-chain state update transaction to the StarkNet smart contract deployed on Layer 1, which will only accept this new state change after the Verifier has completed the proof.

Products

Starkware currently has two products:

• StarkEx provides customized ToB services for applications, allowing applications running on StarkEx to define their business logic. StarkEx serves applications in DeFi and gaming, accelerating transaction speed, reducing transaction costs, and enabling data availability through either ZK-Rollup or Validium solutions.
• StarkNet is a permissionless, decentralized, censorship-resistant general Layer 2 network where any user and developer can deploy smart contracts written in Cairo.

These two products correspond to two different business models: the former provides customized services and sells them, while the latter offers permissionless general services and charges transaction fees on the network or extracts MEV as a node based on transaction fee priority.

Eli Ben-Sasson, co-founder of StarkWare, made an analogy, comparing StarkEx and StarkNet to computers and the cloud. Purchasing StarkEx is like owning a customized computer, where each client has their own scaling computer. StarkNet, on the other hand, provides a network and general services that everyone can pay for and use.

The workflow of StarkNet is illustrated in the following diagram. Its main difference from StarkEx is that in StarkNet, the Sequencer replaces the StarkEx Service to handle transaction validity verification, transaction packaging, and invoking Cairo programs for execution, while the proof generation work handled by SHARP is the responsibility of the Prover in StarkNet. Currently, both the Sequencer and Prover are designated by the StarkWare official team, raising concerns about centralization.

Roadmap

StarkNet previously released a roadmap on their blog, indicating that they would gradually achieve decentralization.

In their vision, the process of building StarkNet includes four phases:

• Step 0--Infrastructure
• Step 1--Planets: Single operator, single app rollup
• Step 2--Constellations: Single operator, multiple app rollup
• Step 3--Universe: Decentralized operators, multiple app rollup

In Step 1, a StarkNet instance (a rollup) runs only one application, with developers focusing on how to implement their business logic on the StarkNet scaling network.

The next step will support running multiple applications on the same StarkNet instance, allowing these applications to share a global Layer 2 state. This will enable interoperability between different applications and reduce gas costs due to economies of scale. At this stage, StarkNet will become a fully functional framework capable of running multiple applications with arbitrary business logic on Ethereum, with each instance operated by a single operator. From the user's perspective, StarkNet will feel very similar to Ethereum, but with better scalability.

The final stage is the decentralization of operators in StarkNet. In this phase, the team will focus on two main tasks: (1) using rollups to achieve a better consensus mechanism and (2) utilizing an economic model to incentivize contributors and operators, attracting more participants to achieve network decentralization.

Cairo Language

Cairo (CPU Algebraic Intermediate Representation) is a Turing-complete programming language used by Starkware to generate STARK proofs for general computations. Application developers can define any business logic using Cairo and complete off-chain proofs and on-chain verifications without manually generating complex circuits or AIR (Algebraic Intermediate Representation).

Through the Cairo programming language, any computational proposition can be quickly and securely encoded for proof. An application written in Cairo can prove its corresponding execution logic, and a Cairo application can also integrate multiple Cairo applications to form SHARP.

SHARP (Shared Prover) can aggregate transactions from several independent Cairo applications and use them in the same STARK proof. Using STARK proofs, the time required to present a proof is roughly linear in relation to the time required to execute the statements. The time required to verify the proof is logarithmic in relation to the time taken to present the proof.

Since the verification time is much shorter than the proof time, recursive verification can be achieved: a Cairo program can verify the correctness of multiple transactions, and a Cairo program can also be written to verify multiple Stark proofs. Since only logarithmic time is needed for verification, such recursive verification can significantly reduce verification time.

The Starkware team has launched the Generic Proof Service (GPS) for Cairo, allowing developers to use this service to build their applications in the Cairo language. They can send their Cairo code containing business logic to GPS for proof and verify it on-chain.

Team and Funding

The Starkware team is based in Israel, primarily composed of computer science and cryptography developers with backgrounds from Hebrew University and the Technion, making it one of the strongest teams in the field of zero-knowledge proofs.

According to Starkware's official website, the team currently has 77 members, along with 7 academic advisors and 5 other advisors. Key members include:

• Eli Ben-Sasson: Co-Founder & Chief Scientist, PhD in Theoretical Computer Science from Hebrew University, long engaged in research on computational integrity, cryptography, and zero-knowledge proofs. Professor of Computer Science at the Technion. Founding scientist of Zcash, inventor of zkSNARK and zkSTARK.
• Uri Kolodny: Co-Founder & CEO, Bachelor's degree in Computer Science from Hebrew University, a commercially experienced and collaborative serial entrepreneur.
• Alessandro Chiesa: Co-Founder & Chief Scientist, Professor of Computer Science at UC Berkeley. Founding scientist of Zcash, co-inventor of zk-SNARKs, and core developer of the leading open-source library for succinct zero-knowledge proofs, libsnark.
• Michael Riabzev: Co-Founder & Chief Architect. PhD from the Technion, previously worked at Intel and IBM.
• Oren Katz: Vice President of Engineering. Graduated in Computer Science from Hebrew University, MBA from Tel Aviv University, and a senior engineer with 20 years of experience.

In terms of funding, StarkWare has disclosed seven rounds of financing, involving 45 investments, with a disclosed funding amount of $273 million. In 2022, the D round financing valued at $7.9 billion, with investors including Paradigm, Sequoia Capital, and Pantera Capital, as well as Vitalik.

Economic Model

In mid-July of this year, Starkware released their token economic model on their blog. Originally planned for a September token launch, they later announced a postponement, and as of the publication of this article, there has been no official announcement regarding the token launch.

The StarkNet token will primarily have three use cases: paying StarkNet network fees, staking to participate in network consensus, and community governance voting.

• Transaction Fees: Currently, fees in StarkNet are paid in ETH. However, the project expects that fees will soon only be paid using the native StarkNet token. To support a good user experience, an automated and decentralized on-chain mechanism will allow users to pay fees in ETH.
• Staking: Certain services crucial to the activity and security of StarkNet may require staking StarkNet tokens. These services may include ordering, achieving temporary L2 consensus before reaching L1 finality, STARK proof services, and data availability supply. These services are expected to achieve decentralization in 2023.
• Governance: Proposals to improve StarkNet will require a minimum token holding threshold. All changes to protocols critical to the activity, security, and maintenance of StarkNet will require voting either directly or through delegation. For example, all major updates to the StarkNet operating system will need approval from token holders.

The initial issuance of the StarkNet token is 10 billion tokens, with 17% allocated to StarkWare investors, 32.9% to core contributors, and 50.1% to the foundation. Additionally, the token has a minting mechanism, where newly minted tokens and a portion of transaction fees will be granted to core infrastructure developers and smart contract developers.

The specific uses of the 51% allocated to the foundation are:

• 9% ------ Ecosystem developers, users, and community. Including some users who interacted with StarkEx before June 1.
• 9% ------ Community Rebates ------ Refunds of StarkNet tokens to partially cover the costs of joining StarkNet from Ethereum.
• 12% ------ Funding for researchers and workers developing, testing, deploying, and maintaining the StarkNet protocol.
• 10% ------ Strategic reserves for funding ecosystem activities that align with the foundation's mission.
• 2% ------ Donations to outstanding institutions and organizations in related fields, such as universities and NGOs, decided by StarkNet token holders and the foundation.
• 8.1% Unallocated ------ To further support the StarkNet community, with specific methods determined by the community.

Considering the customary allocation practices of decentralized ecosystems and the long-term interests of the community, the 49.9% allocated to investors and core contributors will have a four-year lock-up period, with a one-year cliff and linear release of tokens.
From the token distribution, it is evident that StarkNet token rewards prioritize core infrastructure and dApp developers, with less inclination towards ordinary users.

Operational Data

StarkEx, this ToB product, has accumulated some users due to its early launch and relatively mature Scale as a Service model, such as dYdX (which has since left), Immutable X, rhino.fi, celer, and Sorare. According to data displayed on the official website, the cumulative transaction amount on StarkEx has reached $732 billion, with a current TVL of $461 million.

The other product, StarkNet, according to data from www.starknet-ecosystem.com, currently has about 100 applications in its ecosystem, with the largest number being in DeFi (45), NFTs (24), and infrastructure (18).

Among the more well-known projects, AAVE and Maker are both deploying on StarkNet. Just two days ago (October 29), it was officially announced that Aave's first phase of cross-chain cooperation with StarkWare has completed development. This phase involves the cross-chain aToken smart contract infrastructure from Aave v2 on Ethereum to StarkNet, allowing network users to obtain cross-chain aTokens on StarkNet. Earlier in June, Maker had already launched DAI transfers between the mainnet and StarkNet.

It is worth mentioning that dYdX, which previously held the majority of TVL in StarkEx, left in June, opting for an independent blockchain based on Cosmos SDK to launch its v4 version of the product. This event has somewhat affected investors' confidence in Layer 2 and Starkware.

This departure also illustrates that applications with real users and influence have more say and initiative when choosing underlying infrastructure; they do not rely on a single underlying chain and can actively choose other public chains or even build their own application chains that meet their needs.

The past narrative of "fat protocols and thin applications" may be redefined. For various underlying infrastructure projects, how to capture quality applications within their ecosystems and ensure retention has become a question that needs to be rethought. After all, to capture more value, one must capture more users, and the real interaction occurs at the application level rather than the underlying layer. Users do not care about the principles of underlying technology implementation; they will migrate along with applications.

Conclusion

With a strong technical team, Starkware is currently gradually developing products according to their plans: on October 26, they announced the completion of ZK-EVM written in the STARK proof programming language Cairo.

At the same time, they face some challenges, such as the current technical difficulty of zk-STARK, slow development speed, and a shortage of developers, which pose many difficulties for the development and retention of ecosystem applications. The departure of dYdX took away most of the TVL from the project, exposing the underlying infrastructure's insufficient binding capability with high-quality upper-layer applications, and highlighting the strong voice of quality applications when selecting underlying chains.

However, due to the superiority of the technology, we remain optimistic about the long-term development of zk-rollup and STARK. In the future, with the incentive effects brought by token releases and the gradual shift of the network towards decentralization, Starkware will continue to be one of the strongest competitors in the Rollup space.