Starknet
Key Takeaways
- Starknet is a ZK-rollup operating as an L2 network over Ethereum, with STARK proof providing more secure and high scalability
- A Sequencer executes transactions in a specialized CairoVM, while a Shared Prover generates a zk proof of the state transition.
- Plans are in place to decentralize the sequencer role and to reduce latency by producing proofs more frequently.
1. Overview
Starknet is a permissionless decentralized ZK-Rollup operating as an L2 network over Ethereum. This enables any dApp to achieve unlimited scale for its computation while leveraging Ethereum’s security. Developers can write Starknet contracts and deploy them on the network, and users can send transactions to these contracts (in a similar manner to how this is done on Ethereum).
- A Sequencer executes transactions in a specialized CairoVM
- SHARP (Shared Prover) generates a zk proof of the state transition in
- Smart contracts in L1 (Ethereum) verify the proof
(Source: Sequencers in Starknet :: The Starknet Book)
2. Execution
A single Sequencer in StarkOS (CairoVM) is dedicated to performing transaction execution. The Starknet transaction execution environment, known as Starknet OS (similar to the Ethereum Virtual Machine), is implemented in Cairo to optimize proving performance of each transaction execution.
Sequencers are the entry point for transactions in the Starknet system, and they are crucial in networks that use Zero-Knowledge (ZK) rollups. Sequencers collect multiple transactions, process them into a single batch, and produce a block.
Sequencers operate in an organized manner by following several steps:
- Aggregation: Collecting transactions from users.
- Processing: Processing these transactions according to the network's rules.
- Batching: Grouping transactions together into batches to improve efficiency.
- Block Production: Creating blocks that contain these batches of processed transactions.
After the Prover verifies this block, it sends it to the Layer 1 network as a compact proof. This mechanism enables ZK rollups to handle more transactions while maintaining the underlying Ethereum network's security. It enhances scalability without sacrificing security.
2.1 Sequencing
Starknet's current roadmap includes plans to decentralize the sequencer role, allowing for more network participants to become sequencers. This decentralization will enhance the network's robustness and security.
Also, to avoid the network failure incurred by less client diversity, multiple sequencer softwares are being developed.
| SW Sequencer | StarkWare | In production |
|---|---|---|
| Madara | Community | In development |
| LC Sequencer | LambdaClass | In development |
(Source: The Starknet Stack’s Growth Spurt - Starkware)
2.2 Notable Infra Tools
- Warp: Since Starknet does not natively support EVM, the Warp team at Nethermind is developing a Solidity to Cairo transpiler.
- Execution Clients: Pathfinder (mainly used), Papyrus, and Juno
3. Settlement
Shared Provers (SHARP) generates a zero-knowledge proof from L2 blocks, which is verified through a contract in L1.
There are two major components in the settlement layer:
- Prover: that generates zk proof from block data from the sequencer
- Verifier Contract: that verifies the proof from the Starknet Core contract
3.1 Provers
Provers act as a secondary verification layer in Starknet, validating sequencers' work and generating proofs of correct transaction processing. Their main responsibilities include receiving blocks of processed transactions from sequencers, processing these blocks a second time to confirm all transactions were correctly handled, and generating a proof of correct transaction processing. The proof is then sent to the Ethereum network for validation via a smart contract called the Verifier smart contract. If the proof is valid, the transaction's status changes to 'accepted on L1', signifying the transaction's security by Ethereum consensus.
As Provers require greater computational power than sequencers due to the demanding nature of proof generation, Starknet utilizes a Shared Prover system called SHARP to generate proof in a parallel manner.
The SHARP mechanism in Starknet operates in several steps. First, it collects multiple Cairo programs from different users, each embodying distinct logic. These collected programs are then processed together, generating a shared proof applicable to all the programs. Instead of forwarding the proof directly to the Solidity Verifier in Ethereum, it is first sent to a STARK Verifier program written in Cairo for initial verification. The STARK Verifier creates a fresh proof to confirm the verification of the initial proofs, which can be looped back into SHARP and the STARK Verifier in a recursive proof process. Ultimately, the last proof in the series is forwarded to the Solidity Verifier on Ethereum, indicating the final verification step after several proofs have been generated.
The major advantage of the SHARP system is its ability to reduce costs and increase efficiency within the Starknet network. This is achieved by consolidating multiple Cairo jobs, or distinct sets of computations, allowing the protocol to take advantage of the exponential amortization provided by STARK proofs. As the computational load of the proofs amplifies, the cost of verifying these proofs escalates at a slower, logarithmic rate, resulting in considerably diminished costs per transaction within the aggregated set. This makes the entire process more economical and user-friendly.
3.2 Verifier Contract
SHARP generally takes the execution trace of the Cairo program, verifies its validity, and sends the proof to the Verifier contract on Ethereum. Once the proof is verified, the on-chain verifier writes a fact in the Fact Registry that confirms the proof's validity. This fact serves as a trustless stamp of approval that certifies the correctness of the Cairo program's computation. The dApp's smart contract only needs to verify the existence of this fact to depend on the off-chain execution.
Nodes
Nodes: verify the integrity of the proof
There are three primary methods for a node in Starknet to monitor the network's state:
- Replaying Old Transactions: Like Ethereum or Bitcoin, nodes can re-execute all transactions, ensuring accuracy but requiring powerful machines due to scalability issues.
- Relying on Layer 2 (L2) Consensus: Nodes trust Sequencers to correctly execute the network, accepting their state updates as accurate.
- Checking Proof Validation on Layer 1 (L1): Nodes can keep track of the network by observing L1 and confirming every proof sent. Nodes only need to track the latest valid transaction, eliminating the need for trust.
Nodes that replay transactions require powerful hardware but make no trust assumptions. Nodes that rely on L2 consensus need less computational power but must trust Starkware not to disrupt the network. Nodes that check proof validation on L1 require the least hardware, similar to Ethereum nodes, but face latency issues due to intermittent proof sending. However, plans are in place to reduce latency by producing proofs more frequently.
4. Data Availability: stores input and output
After an on-chain state update is approved, the state diff between the previous and new state is transmitted as calldata to Ethereum. To accommodate the large amount of data, the diff is split into several Ethereum transactions, each containing a portion of the array as calldata. These transactions are included in every new Starknet block.
To extract this data from Ethereum, one can utilize the code available at Pathfinder's repo. Pathfinder serves as the initial implementation of a Starknet full node. Additionally, one can refer to the Python script that extracts the same information.
5. Team
- Eli Ben-Sasson (President, Co-Founder)
- Uri Kolodny (CEO, Co-Founder)
