Glossary

Refers to the capability of users to define their own account logic instead of it being dictated by the protocol.

An L2 smart contract, with programmable logic, that implements a user account on Starknet. An account contract implements special methods that enable initiating transactions.

The Starknet Node API uses the Remote Procedure Call (RPC) architectural style, written in JSON format. For complete information on the Starknet Node API in JSON RPC format, see starknet_api_openrpc.json on Github.

An ordered set of Starknet transactions. Blocks are built by the sequencer.

A block has the following identifiers:

An optimized low-level execution unit that is added to the Cairo CPU board to perform predefined computations that are expensive to perform in standard Cairo, including range-checks, Pedersen hash calculations, and ECDSA.

The smallest unit of execution within the Cairo VM, typically involving mathematical, logical, or control-flow operations that collectively define the behavior of a program.

The Cairo Virtual Machine (VM) is software that knows how to execute compiled Cairo byte-code. The result of this execution is the program trace that can then be sent to a STARK prover in order to prove the validity of the instruction expressed in the Cairo code.

The definition of a contract. It includes Cairo byte code, entry point names, and everything that defines its semantics.

A deployed contract that corresponds to a class. Only contract instances act as true contracts, in that they have their own storage and can be called by transactions or other contracts.

The smallest denomination of STRK. 1 fri = 10^-18 STRK.

A machine that runs the Starknet execution protocol. A full node stays synchronized with the latest state of the network, stores past blocks and transactions, and enables users to interact with the network, such as by querying its state or by broadcasting new transactions.

A single transaction that executes multiple bundled transactions, which are signed once on Starknet. If one call fails, the entire operation is aborted.

The entity that receives the output of Cairo programs and generates proofs to be verified. In the context of Starknet, the prover generates proofs of the computational integrity of the work performed by the sequencer. It then submits the proof to the verifier on L1, which registers the fact.

The Starknet RPC API provides clients an interface to retrieve information on the state of the chain and to interact with it, such as by posting transactions or estimating the fee of a transaction before it is sent.

A set of services that together receive transactions from the network, put them in order, check their validity, and build blocks.

The Shared Prover (SHARP), is a mechanism used in Starknet that aggregates multiple Cairo programs from different users, each containing different logic. These Cairo programs are then executed together, generating a single proof common to all the programs.

An intermediate representation between Cairo and Casm. Sierra code is then compiled to a Casm program with the property that, for any input, the execution of the program is provable. In particular, it ensures that the execution of a transaction is provable regardless of whether the execution succeeded or was reverted due to an error.

A proof system that uses cryptography to provide polylogarithmic verification resources and proof size, with minimal and post-quantum-secure assumptions.

A smart contract deployed on Ethereum. Its address is 0xc662c410c0ecf747543f5ba90660f6abebd9c8c4. It defines the state of Starknet by storing:

The committed state on the L1 Core Contract acts as the consensus mechanism of Starknet,that is, 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:

The Cairo program that, upon receiving a set of transaction as input, executes the state transition. For more information, see Starknet state. The integrity of this computation is what is actually proven and verified.

The set of all the contracts' code and all the memory slots and their values, in every contract’s storage.

A transaction can be seen as a message containing a set of instructions that describe a state transition. The Starknet protocol has the following types of transactions, which affect different parts of the state:

The data describing the difference between two states. It contains information on every contract whose storage was updated and additional information on contract deployments.

A set of L1 smart contracts whose purpose is to verify STARK proofs submitted by the Shared Prover (SHARP).