The architecture shown in this article has inaccuracies. Do not use it as a reference until updated (if ever). In the meantime, refer to the official Starknet docs.
tl;dr
- Starknet’s user accounts (wallets) are implemented as smart contracts.
- The system has 3 off-chain components (Sequencer, Prover and Full Nodes) and 2 on-chain (Verifier and Core).
- The current system architecture is able to handle more transactions than Ethereum but with a higher delay for finality.
- A dual checkpoint mechanism has been proposed to reduce time to finality without compromising cost.
- An L2 transaction can be on any of these states: NOT_RECEIVED, RECEIVED, PENDING, ACCEPTED_ON_L2, ACCEPTED_ON_L1 or REJECTED.
Introduction
In a previous article I compared Starknet (zk-rollup), Optimism (optimistic rollup) and Solana (alt. L1) as scalability alternatives to Ethereum. In this article I’m going to delve deeper into Starknet’s architecture and the life cycle of its L2 transaction.
System Architecture
Starknet’s architecture is composed of User Accounts (wallets), Full Nodes, a Sequencer, a Prover, a Verifier and a Core smart contract.
On Starknet User Accounts are implemented as smart contracts. This is in contrast to Ethereum where there is a clear distinction between Externally Owned Accounts (EOA) and the smart contracts they interact with. By being smart contracts themselves, Starknet’s User Accounts are much more flexible than the rigid EOA’s of Ethereum. This flexibility allows for the creation of more sophisticated wallet recovery mechanisms that rely on peers (friends, family, coworkers, etc.) performing off-line authentication instead of seed phrases that can be lost or stolen. This type of wallets are known as “social recovery wallets” and it’s a feature already available on Argent X, a Starknet wallet similar to MetaMask. Social recovery wallets are an important precursor to soul bound tokens that provide rich on-chain identity for users.
Another feature possible with this type of wallets is to be able to support custom logic for validating transaction signatures. Braavos takes advantage of this to implemente additional security measures like 3 Factor Authentication (3FA) while at the same time supporting the standard curve secp256r1.
A Sequencer is an off-chain server that receives all the transactions, orders, validates and bundles them into blocks. At the moment there is a single Sequencer in the system and it is controlled by StarkWare but the company has a plan to decentralize block creation in the future. For a Sequencer to validate transactions it has to execute them using the Cairo OS, an alternative to the Ethereum Virtual Machine (VM) for smart contracts written in Cairo.
The Prover is in charge of generating a cryptographic proof that attest to the integrity of the computation performed by the Sequencer when deriving the new global state by executing the transactions contained in a new block. For the Prover to generate the validity proof it requires to be given the “execution trace” of the computation performed by the Sequencer, something that only a language like Cairo can generate. There is currently a single Prover in the system that not only generates proofs for StarkNet but also for all the other applications that run on their own StarkEx rollup (Immutable X, dYdX, Sorare, etc.). This is why the service is called “Shared Prover” or SHARP.
Full Nodes are machines that run the Pathfinder client to keep a record of all the transactions performed in the rollup and to track the current global state of the system. Full Nodes receive this information through a p2p network where changes in the global state and the validity proofs associated with it are shared everytime a new block is created. When a new Full Node is set up it is able to reconstruct the history of the rollup by connecting to an Ethereum node and processing all the L1 transactions associated with StarkNet.
A Verifier is a smart contract on Ethereum that receives the newly generated proofs from the Prover as L1 transactions and validates them on-chain. The result of the validation is sent to the StarkNet’s Core smart contract for record keeping and to trigger a new set of L1 transactions from StarkNet to update the global state on-chain for record keeping.
StarkNet Core is a smart contract that receives changes to the L2 global state from StarkNet everytime a new L2 block is created and its cryptographic proof has been successfully validated on-chain by the Verifier. The state transition is sent as “call data” to save on gas over multiple L1 transactions given limitations on individual block’s space. This “metadata” about StarkNet is decodified by StarkNet’s Full Nodes to reconstruct the history of the network when synchronizing for the first time.
Improvement Proposal
For StarkNet to be cheap to use it has to maximize the number of transactions on L2 blocks to reduce the frequency validity proofs are submitted on chain, a fairly expensive operation on Ethereum. Waiting to capture enough transactions to make the process financially viable has the downside of creating significant delay until settlement occurs on Ethereum. This is especially acute now when StarkNet has almost no traffic and finality could take hours.
Changes to StarkNet have been proposed to decrease the time to finality without sacrificing cost using “checkpoints”.
Most of the system works the same as before but now, instead of waiting for a new block to be created by the Sequencer to start the process of creating a validity proof and submitting state changes to Full Nodes and to Ethereum, state transition checkpoints are submitted at intervals of 1 minute and 1 hour.
Every minute, a validity proof is generated corresponding to all the transactions that have occurred during the last 60 seconds. The validity proof and the state transition during the interval is submitted to the Full Nodes to achieve a “weaker” one minute finality. Every hour, the system generates a validity proof derived from all the validity proofs created every minute and submits it to Ethereum along with all the changes to the state that happened during the interval to create a “stronger” one hour finality.
Transaction Lifecycle
A StarkNet transaction goes through several different state transitions from the moment it’s triggered and until is either rejected by the system or settled on Ethereum.
When a user starts a transaction from their User Account, it is sent to an L2 whisper network where both Full Nodes and the Sequencer add them to their mempool. A transaction that has not yet arrived to the Sequencer’s mempool is in the NOT_RECEIVED state.
When a transaction finally arrives at the Sequencer’s mempool it is then marked as RECEIVED. Transactions from the mempool are then added to a “pending block”, a block that remains unsealed until enough transactions have arrived. A transaction that has been added to the pending block is in the PENDING state.
Every transaction that enters the pending block is then executed and validated by the Sequencer. An example of a validation performed by the Sequencer is checking if a wallet has enough funds when attempting to send money. If the transaction passes the validation it enters the ACCEPTED_ON_L2 state but if not is marked as REJECTED and discarded.
In the next one hour checkpoint to L1, if the proof for the batch of transactions is validated by the on-chain Verifier and the associated data is stored on Ethereum, the transaction is marked as ACCEPTED_ON_L1. If the on-chain Verifier rejects the cryptographic proof then the transaction is marked as REJECTED.
Conclusion
StarkNet introduces a new layer of off-chain servers with dedicated roles that allows for the execution of transactions outside of Ethereum while providing a cryptographic proof on-chain to attest for the integrity of the computation and the state transition that comes with it. Today the Sequencer and the Prover are centralized services controlled by StarkWare so we need to take into account the risk of the Sequencer selectively dropping transactions or the network stopping its block production if any of these services go offline.
The current rollup architecture is in theory able to handle a higher throughput at a lower cost than Ethereum but at the cost of an increased delay for finality (settlement). An improvement proposal has been discussed to create a dual checkpoint mechanism that could provide the best of both worlds by handling two different levels of finality.
StarkNet is not yet open to the public to deploy their smart contracts on mainnet, only whitelisted projects will be allowed for the time being. For now the Goerli testnet is the best place to interact with StarkNet and learn how the network works.
Acknowledgments
Special thanks to @Charles for helping me fill the gaps in my understanding of StarkNet’s architecture.
[…] StarkNet’s Architecture Reviewtl;dr StarkNet’s user accounts (wallets) are implemented as smart … […]
[…] StarkNet’s Architecture Reviewtl;dr StarkNet’s user accounts (wallets) are implemented as smart … […]