Glossary

The users of Starknet that develop Starknet applications. They write and deploy Starknet and Ethereum contracts.

Ordered sets of Starknet transactions that are run using the Starknet OS, resulting in one aggregated state change that is then committed to the Starknet L1 core contract. A block has:

• … a block hash – a unique stable identifier that can be used to query and refer to the block.
• … a block number – an ordinal number representing the location of the block in the sequence of accepted blocks in Starknet. Note, a block’s number may change over time. Also, a given number may refer to different blocks at different points in time, e.g., in the event of L1 chain re-orders.

A node in the Starknet network that is used only for querying the current Starknet state. It can independently (i.e., without/o querying additional nodes) answer queries about the current state of the Starknet network, including the L1 state. It does not batch transactions or prove batches.

A separate process (either an online service or internal to the node) that receives the output of Cairo programs and generates STARK proofs to be verified. The Prover submits the STARK proof to the verifier that registers the fact on L1.

A collection of contracts (L1 and L2) that collectively implement a business flow.

The program that encodes the implemented application business logic. This includes the application data structures and handling of specific transactions sent by users. Specifically, the Starknet contract encodes valid state transitions for the application.

• Starknet Account Contracts: Given account abstraction, user accounts are not implemented at the protocol level. Some contracts will, therefore, need to implement the concept of user accounts; these are called Account Contracts. The exact implementation depends on the contract; but, technically, these are Starknet contracts that are implemented in Cairo.

This L1 contract defines the state of the system by storing the commitment to the L2 state. The contract also stores the Starknet OS program hash – effectively defining the version of Starknet the network is running. The committed state on the L1 core contract acts as the consensus mechanism of Starknet, i.e., the system is secured by the L1 Ethereum consensus. In addition to maintaining the state, the Starknet L1 Core Contract is the main hub of operations for Starknet on L1. Specifically:

• It stores the list of allowed verifiers (contracts) that can verify state update transactions
• It facilitates L1 ↔ L2 interaction

Updates the L2 state of the system based on transactions that are received as inputs. Effectively facilitates the execution of the (Cairo-based) Starknet contracts. The OS is Cairo-based and is essentially the program whose output is proven and verified using the STARK-proof system. Specific system operations and functionality available for Starknet contracts are available as calls made to the OS.

The main node of the Starknet network. It implements the core functionality of sequencing transactions submitted to it. It executes the Starknet OS Cairo program with the relevant inputs, proves the result using the Proving Service or some internal STARK prover, and eventually updates the network state on the Starknet Core Contract.

The state is composed of contracts’ code and contracts’ storage.

An invocation of a specific state-transition logic that’s defined by a contract. Syntactically, a transaction has a well-defined structure that includes all the necessary metadata and an arbitrary data payload. The semantics of the transaction is defined by the invoked contract.

The users that interact with Starknet sequencer nodes and, if necessary, with L1 contracts. These users, whether human or automated, are the agents that submit transactions to the Starknet network.