This article will provide a brief explanation of the important components in StarkNet, without going into too much technical detail or code. However, it is hoped that readers will have a basic understanding of ZK-Rollup (Validity-Rollup).
At the same time, since the system design of StarkNet involves a large number of data structures related to zero-knowledge proofs and Merkle trees, readers also need to have a rough understanding of what zero-knowledge proofs and related Merkle trees are. This will help facilitate the reading process! In the future, there may be further discussions on various system components.
Introduction
StarkNet OS (Operating System) is mainly written in Cairo, the native language of StarkNet. Cairo is like Solidity on StarkNet and can be used to write (Cairo-based) smart contracts, but it is also a zero-knowledge proof language that can be used to build the core operating system and various functionalities of StarkNet.
All the logic on StarkNet will be included in StarkNet OS, such as how to define account states, transaction principles, contract execution, and even how to perform bitwise operations, hash operations, and native signature algorithms.
In general, the operating system needs to generate output after receiving input from transactions and contracts, and update this output to the state of StarkNet L2.
So why use a zero-knowledge proof language to write StarkNet OS instead of other common languages?
As we all know, one of the major directions for scalability is to "offload complex calculations to Off-Chain and only verify them On-Chain". As a member of ZK-Rollups, StarkNet will use the STARK-proof system to prove the content executed by the Cairo-written ZK-STARK program and verify it on Ethereum.
If you don't have a clear understanding yet, the next few sections will sequentially explain these terms and use cases!
Overview of StarkNet System
StarkNet Sequencer
As a Rollup, StarkNet does not have a traditional miner role, but it still needs a role to "verify transactions," "determine transaction order," and "build blocks." The person responsible for these tasks is the Sequencer.
The Sequencer is an off-chain server. The first step in its workflow is to receive transactions submitted by users (multiple transactions from different users), and then the Sequencer will determine the order of the transactions and build L2 blocks.
The Sequencer needs to confirm that the transactions are authorized by the account owners (since StarkNet uses a native AA account system, this may not be a simple confirmation of correct signatures, but may involve multi-signature or other verification logic). Then, the Sequencer executes the transaction once through StarkNet OS, which is conceptually similar to EVM. It executes the contract logic and generates output after receiving input.
The Sequencer's execution of transactions will produce a trace (note that this trace is not a function return, but a proof of the execution process), and then it will send the "process proof" of these execution contents to the Prover, telling everyone, "I have executed this piece of code."
After the Prover and Verifier, which will be discussed next, successfully verify the proof, the Sequencer will update the state in the L1 StarkNet core contract.
StarkNet Prover & Verifier
The Prover is also an off-chain server whose main task is to receive the trace generated by the Sequencer after executing the code and generate the corresponding STARK proof. It then submits the proof to the Verifier contract running on L1 for verification. After the verification is successful, the Prover registers the fact for future queries by the L1 StarkNet core contract.
The Verifier contract on L1 is responsible for verifying the legality of everything. It accepts input and STARK proofs to make decisions.
Additional note: Currently, there is only one Prover in StarkNet. It not only generates proofs for StarkNet but also generates proofs for all other applications running on StarkWare's own StarkEx rollup, such as Immutable X, dYdX, Sorare, etc. That's why this service is called Shared Prover or SHARP.
StarkNet L1 Core Contract
The StarkNet L1 core contract stores the proof of the state on L2. The security of Rollups is ensured by Ethereum's L1. After our trace is generated by the Prover and verified by the L1 Verifier contract, we inform the L1 core contract that this "state update" is correct.
"State update" refers to the fact that the state changes after executing transactions in StarkNet. We need to find a way to correctly convey to the L1 core contract that the state on L2 has been updated from S to S'.
When the L1 core contract knows that this state update is valid through the Verifier, the Sequencer will update the State Root in the contract.
In other words, knowing that "this state update is valid" means that we have proven through ZKP that the off-chain computation has been correctly executed, rather than fabricating a random transaction result and calling it a state update in the L1 core contract.
In addition, if StarkNet has some operations that need to be defined on L1, they will also be defined in the StarkNet L1 core contract, such as:
Officially recognized Verifiers contract (Addresses List)
Logic for L1 ↔ L2 interaction (message passing method)
Discussion
Decentralization and Open Source
The roles of Sequencers and Provers in Rollups being controlled by the official team of the chain can raise questions from the community. Therefore, open source is very important for long-term development. Not only can more eyes scrutinize the code, but the system can also become more secure and efficient through community collaboration and contributions. In the worst-case scenario, the community can independently develop and maintain the entire network.
In the StarkNet community, decentralization has two main discussion aspects:
Sequencers and Provers that can operate without permission can ensure that the network is censorship-resistant.
Because STARK proofs are used, anyone can verify the correctness of the entire chain with low hardware costs, without trusting any third-party entities.
Currently, StarkNet has open-sourced the latest Sequencer, and the Prover will also be open-sourced soon. Interested individuals can refer to the following resources:
StarkNet Decentralized Protocol III - Consensus
Open Source: StarkNet's New Sequencer
Open Source StarkNet Prover
Performance and Bottlenecks
In my own use of StarkNet's performance and gas fees over the past few months, it has not been very good (sometimes even poor or completely unusable). However, StarkNet officials have stated that they have focused on functionality in the past, and now (after the upcoming Cairo 1.0 release) they have completed the basic infrastructure and will shift their development focus to performance.
StarkNet believes that the best way to increase TPS is to increase the transaction volume that can be accommodated under the same block generation time, that is, the block limit. Therefore, any components related to block generation need to improve efficiency. For example, the Sequencer is the biggest bottleneck, so there are plans to switch to different algorithms (from first-come, first-served to parallel processing), different data structures (originally Patricia-Trie), and a new Sequencer called Blockifier written in Rust (originally Python).
The new parallelized Sequencer can refer to the following resources:
https://twitter.com/starkience/status/1615502502773903361?s=20
https://twitter.com/Starknet/status/1595341405655683072
https://www.youtube.com/watch?v=9IszIArEt1M
Regarding this issue, StarkNet has put forward an explanation of why increasing the block limit is useful for L2 but not for L1. The reason is that if the block size is too large, the requirements for full nodes become higher (so that they can keep up with the growth rate of the chain and perform verification). If this requirement is so high that most users cannot afford it and cannot verify independently, it means that most people need to participate in the network in an untrusted manner.
Conclusion
Writing an introduction to StarkNet requires a lot of reference materials, and I have tried to include all the referenced content (in the text or at the end of the text). I hope it can help people who are willing to delve into StarkNet and I am very grateful to the kind-hearted people who are willing to share their research results on StarkNet!