Starknet architecture: Overview

Starknet’s operation begins when a transaction is received by a gateway, which serves as the Mempool. This stage could also be managed by the sequencer. The transaction is initially marked as RECEIVED. The sequencer then incorporates the transaction into the network state and tags it as ACCEPTED_ON_L2. The final step involves the prover, which executes the operating system on the new block, calculates its proof, and submits it to Layer 1 (L1) for verification.

For more information on the transaction flow, see Transaction lifecycle.

In essence, Starknet’s architecture involves multiple components:

Starknet’s state is a comprehensive snapshot maintained through Merkle trees, much like in Ethereum. This establishes the architecture of the validity roll-up and the roles of each component.

Sequencers are the backbone of the Starknet network, similar to Ethereum’s validators. They usher transactions into the system.

Validity Rollups, also known as ZK-Rollups, excel at offloading some network chores, like bundling and processing transactions, to specialized players. This setup is similar to how Ethereum and Bitcoin delegate security to miners. Sequencing, like mining, demands hefty resources.

Validity Rollups like Starknet outsource transaction processing to specialized entities and then verify their work. These specialized entities, in the context of Validity Rollups, are known as sequencers.

Instead of providing security, as miners do, sequencers provide transaction capacity. They order, that is, sequence, multiple transactions into a single batch, execute them, and produce a block that is later proved by the prover and submitted to the Layer 1 network as a single, compact proof, known as a rollup. Just as validators in Ethereum and miners in Bitcoin are specialized actors securing the network, sequencers in Validity Rollup-based networks are specialized actors that provide transaction capacity.

This mechanism enables Validity Rollups to handle a higher volume of transactions while maintaining the security of the underlying Ethereum network, enhancing scalability without compromising on security.

Sequencers follow a systematic method for processing transactions:

Sequencers must be reliable and highly available, as their role is critical to the network’s smooth functioning. They need powerful and well-connected machines to perform their role effectively, as they must process transactions rapidly and continuously.

The current roadmap for Starknet includes decentralizing the sequencer role. This shift towards decentralization will enable more participants to become sequencers, contributing to the robustness of the network.

Provers serve as the second line of verification in the Starknet network. Their main task is to validate the work of the sequencers, when they receive the block produced by the sequencer, and to generate proofs that these processes were correctly performed.

A prover does the following:

Provers need even more computational power than sequencers because they have to calculate and generate proofs, a process that is computationally heavy. However, the work of provers can be split into multiple parts, allowing for parallelism and efficient proof generation. The proof generation process is asynchronous, meaning it doesn’t have to occur immediately or in real-time. This flexibility allows for the workload to be distributed among multiple provers. Each prover can work on a different block, allowing for parallelism and efficient proof generation.

The design of Starknet relies on these two types of actors—sequencers and provers—working in tandem to ensure efficient processing and secure verification of transactions.

The relationship between sequencers and provers in blockchain technology often sparks debate. A common misunderstanding suggests that either the prover or the sequencer is the main bottleneck. To set the record straight, let’s discuss the optimization of both components.

Starknet, which uses the Cairo programming language, currently supports only sequential transactions. Plans are in place to introduce parallel transactions in the future. However, as of now, the sequencer operates one transaction at a time, making it the bottleneck in the system.

In contrast, provers operate asynchronously and can execute multiple tasks in parallel. The use of proof recursion allows for task distribution across multiple machines, making scalability less of an issue for provers.

When it comes to defining what nodes do in Bitcoin or Ethereum, people often misinterpret their role as keeping track of every transaction within the network. This, however, is not entirely accurate.

Nodes serve as auditors of the network, maintaining the state of the network, such as how much Bitcoin each participant owns or the current state of a specific smart contract. They maintain network state by processing transactions and preserving a record of all transactions, but that is a means to an end, not the end itself.

In Validity Rollups and specifically within Starknet, this concept is somewhat reversed. Nodes don’t necessarily have to process transactions to get the state. In contrast to Ethereum or Bitcoin, Starknet nodes aren’t required to process all transactions to maintain the state of the network.

You can access network state data by using the Starknet API, which uses the JSON RPC protocol, to communicate with a node. Previously, Starknet’s Gateway and Feeder Gateway APIs enabled querying the sequencer, but as the network has matured, the JSON RPC has become the standard. Operating your own node is typically faster than using a shared architecture, like the gateway.

It’s worth noting that more people running nodes increases the resilience of the network and prevents server flooding, which has been an issue in other L2 networks.

Currently, there are primarily three methods for a node to keep track of the network’s state and nodes can implement any of these methods:

Each type of node setup comes with its own set of hardware requirements and trust assumptions.