Glossary

account abstraction

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

account contract

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

API

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.

See also

block

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

A block has the following identifiers:

block hash

A unique identifier that can be used to query and refer to the block.

block number

A number representing the location of the block in the sequence of accepted blocks in Starknet.

builtin

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.

Cairo step

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.

Cairo VM

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.

contract class

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

contract instance

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.

fri

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

full node

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.

Layer 1, L1

The base layer of a blockchain network, such as Ethereum, where transactions are directly recorded and validated. It includes the underlying protocol and consensus mechanism that establish the foundational rules for the blockchain.

Layer 2, L2

Exists on top of an L1 blockchain, such as Ethereum, in order to add value to the L1, by providing features such as massive computation scale without compromising on Ethereum’s composability and security.

multicall

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

prover

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.

See also

RPC

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.

See also

sequencer

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

SHARP

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.

Sierra

An intermediate representation between Cairo and Casm. Sierra code is then compiled into a Casm program with the property that, for any input, the program’s execution 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.

Additional resources

STARK

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

Starknet L1 Core Contract

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

  • The commitment to the L2 state.

  • The Starknet OS program hash – effectively defines the version of Starknet the network is running.

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:

  • It stores the list of allowed verifier contracts that can verify state update transactions

  • It deals with cross-layer interaction between L1 and L2.

Starknet

A permissionless Validity-Rollup, also known as a zero-knowledge rollup (ZK rollup) for Ethereum. Starknet is a Layer 2 (L2) blockchain, enabling any dApp to achieve massive computation scale without compromising Ethereum’s composability and security.

Starknet aims to achieve secure, low-cost transactions and high performance by using the STARK cryptographic proof system. Starknet contracts and the Starknet OS are written in Cairo, a custom-built and specialized programming language.

Starknet OS

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.

Starknet state

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

See also

transaction

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:

  • DECLARE

  • INVOKE

  • DEPLOY_ACCOUNT

state diff

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

trace cell

A unit of measurement of proving complexity. In the STARK protocol, a computation is translated into an execution trace that must satisfy a collection of constraints. Every Cairo step translates to ~50 trace cells.

verifier

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