Other terms

Application-specific rollup

A rollup that supports only a certain type of application or functionality. For example, a rollup that supports only ETH and ERC20 token transfers, or DEX swaps. This is in contrast to general-purpose rollups which support arbitrary computations.

Arithmetic circuit

The computation model of ZK-SNARKs.

Blind signature

A type of digital signature where the signer signs a message without knowing its content, allowing the signer to remain anonymous.

Blobs

The data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.

Blobspace

The storage area within Ethereum’s Beacon nodes where blobs are published by rollups and ephemerally stored.

Block

An ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.

Bridge

A message-passing protocol between two blockchains (between L1 and L2, and between L2s). At its most basic, a bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.

Bulletproofs

A type of zero-knowledge proof that enables efficient range proofs and other mathematical proofs without requiring trusted setup.

Bytecode

Generally, an instruction set designed for efficient execution by a software interpreter or a virtual machine. Unlike human-readable source code, bytecode is expressed numerically. Within the context of rollups, often related to the concept of compatibility: whether the bytecode of programs on the rollup are capable of being run as-is on Ethereum as well, and vice versa.

Challenge period

In optimistic rollups, the window of time wherein network participants can assert that some fraud was included in a prior block. Most optimistic rollups currently specify a challenge window of 7 days. By extending the period, there is more time for participants to guard against fraud (invalid state transitions), but also more time until finality is reached.

Circuit

A program written for the purposes of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, and is therefore sometimes referred to as an arithmetic circuit. Circuits can be written in different languages, ranging from low-level to high-level.

Client

Sometimes labelled interchangeably as a “node”, they are tasked with processing transactions and managing the rollup’s state. They run the computations for each transaction according to the rollup’s virtual machine and protocol rules. If comparing to Ethereum clients, these would be execution clients such as Geth, as opposed to consensus clients.

Consensus

An agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon.

Compatibility

The degree to which a rollup can make use of existing patterns, code, and tooling from another blockchain or development environment. Today, this typically refers to how well rollups and developers thereon can make use of the Ethereum Virtual Machine, existing smart contracts, and other Ethereum infrastructure.

Commitment Scheme

A cryptographic primitive that (i) allows one (usually a prover) to commit to a chosen statement and send this commitment to the verifier while keeping it hidden to others, and (ii) allows verifier to check the commitment and accept or reject it. The commitment scheme should satisfy two properties: (i) it should be binding; that is, once the prover has committed she is bound to the message she has committed, (ii) it should be hiding; that is, the commitment reveals nothing new about the message to the verifier.

Completeness

One of three properties of zero-knowledge proofs, completeness states that if a statement is true, an honest verifier will be convinced of this by an honest prover.

Danksharding

A sharding design proposed for Ethereum. Instead of providing more space for transactions, Ethereum sharding provides more space for blobs of data. Verifying a blob simply requires checking that the blob is available - that it can be downloaded from the network. The data space in these blobs is expected to be used by layer-2 rollup protocols. In comparison to other sharding mechanisms, where there are a fixed number of shards with distinct blocks and distinct block proposers, in Danksharding there is only one proposer that chooses all transactions and all data that go into that slot.

Determinism

The concept of some function or process having a single outcome that is knowable by all participants. In the context of a rollup, it generally refers to the new state being calculable given a prior state and a list of transactions to be executed.

Ethereum Virtual Machine (EVM)

A stack-based virtual machine that executes bytecode. In Ethereum, the execution model specifies how the system state is altered given a series of bytecode instructions and a small tuple of environmental data. In the context of rollups, the EVM is a choice of execution environment that rollups could implement, as in the case of EVM ZK-Rollups (ZK-EVMs) and EVM optimistic rollups.

Execution environment

Refers to both the environment where transactions are processed, constituted by the execution clients, as well as the virtual machine model which the clients run.

Equivalence

A perfect degree of compatibility; where one system or concept is indistinguishable from another in the domain being compared. In the context of rollups, it generally refers to the proximity to the EVM and to Ethereum architecture.

Escape hatch

The facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1.

Fast Fourier Transform (FFT)

An algorithm that computes the Discrete Fourier Transform (DFT) of a sequence in a more efficient manner; that is, taking O(n * log(n)) instead of O(n * n). It is used for extremely fast multiplication of large numbers, multiplication of polynomials, and extremely fast generation and recovery of erasure codes.

Fiat-Shamir heuristic

A method of converting interactive proofs into non-interactive proofs, commonly used in zero-knowledge protocols.

Fraud proof

Also referred to as a fault proof, it is the construction of an assertion that fraud was perpetrated on an optimistic rollup. More concretely, that an invalid state transition took place according to the protocol rules. The submitter of a fraud proof would expect a reward from the optimistic rollup protocol for helping maintain the integrity of the system.

FRI

A proximity test method that is used to determine whether a set of points is mostly on a polynomial with a degree less than a specified value. It resembles the FFT but the arithmetic complexity of its prover is strictly linear and that of the verifier is strictly logarithmic.

Gas

A virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources.

Gas limit

The maximum amount of gas a transaction or block may consume.

Gas price

Price in ether of one unit of gas specified in a transaction.

General-purpose rollup

A rollup that supports arbitrary computations, allowing for the development of arbitrary applications and functionalities.

Geth (Go Ethereum)

An Ethereum execution client, meaning it handles transactions, deployment and execution of smart contracts and contains an embedded computer known as the Ethereum Virtual Machine. Running Geth alongside a consensus client turns a computer into a full Ethereum node, or validator.

Halo

The first recursive proof composition without a trusted setup. A proof verifies the correctness of another instance of itself, meaning that the latest mathematical output (one single proof) contains within it a proof that all prior claims to the relevant secret knowledge have themselves been sufficiently proven through a similar process. It allows any amount of computational effort and data to produce a short proof that can be checked quickly.

Hash

A fixed-length fingerprint of variable-size input, produced by a hash function.

Homomorphic encryption

A type of encryption that allows computations to be performed on encrypted data without decrypting it, making it useful for privacy-preserving computation.

Interoperability

Refers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems.

KZG commitments

A polynomial commitment scheme that allows a prover to compute a commitment to a polynomial, with the properties that this commitment can later be opened at any position: The prover shows that the value of the polynomial at a certain position is equal to a claimed value. KZG is widely used as it’s applicable both for univariate and k-variate polynomials, is efficient for batch proofs, and is able to generate many proofs at once relatively fast. It is also proof generation time efficient: the time for prover to commit to a polynomial is linear on the degree of the polynomial.

Keccak

Cryptographic hash function used in Ethereum.

Lagrange Interpolation

A formula that helps to find a polynomial which takes on certain values at arbitrary points. Thanks to Lagrange Interpolation the time for a prover to commit to a polynomial in KZG is linear in the degree of the polynomial.

Layer 1

Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.

Lookup table

Lookup tables express a relation between variables in the format of a table. A prover can rely on such a table of precomputed values in generating a proof without having to do bit by bit arithmetic. These tables can help handle hash functions within circuits in a more friendly manner (that is speeding up decryption and reducing memory requirements).

Maximal Extractable Value (MEV)

The maximum profit that can be extracted from block production by including, excluding, and reodering transactions in a block. In rollups, proposers (sequencers) and prover are the network participants that receive rewards for building and proving blocks.

Merkle proofs

Hashing the pairs of values at each layer (hashing hashes starting from layer 2) and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the set.

Merkle tree

A hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs.

Modular blockchains

A blockchain that fully outsources at least one of the 4 components (Consensus, Data Availability, Execution, Settlement) to an external chain. For example, rollup is a modular blockchain as it handles transaction executions off-chain and ‘outsources’ data availability and consensus to Ethereum.

Multi-proof system

A rollup settlement concept that relies on a combination of multiple different proving systems. For example, a combination of fraud proof and validity proof. The goal is to reduce reliance on a single system-type or implementation. A more complex example of a multi-proof system: if anyone submits two conflicting state roots to a prover and both roots pass, that prover is turned off.

Multi-scalar multiplication (MSM)

The algorithm for calculating the sum of multiple scalar multiplications (products of a real number and a matrix) to reduce the number of group operations as much as possible. As MSM accounts for 80% of prover’s work fast MSM dominates prover’s costs improving ZKP efficiency.

Network

A constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes.

Node

A software client that participates in the network.

Opcode

A binary instruction code that defines a specific operation or computational task that the EVM or other VMs can perform. In the context of rollups, opcode- and bytecode-level compatibility refers to the ability to execute smart contracts with or without modification.

One-time pad

A type of encryption that uses a random key that is only used once to encrypt a message, providing perfect secrecy.

Operator

An operator is the entity charged with managing a rollup and progressing its state. While similar to the concept of a proposer, operator is often meant to convey a centralized rollup implementation, with a single operator acting as node, proposer (and prover if ZK).

Optimistic rollup

A rollup that optimistically updates state with the possibility of fraud proofs being generated to revert faulty state transitions. Optimistic rollups have primarily been EVM-compatible to date. Compared to ZK-Rollups, they have longer time to finality as there is a time window (challenge period) during which anyone can challenge the results of a rollup transaction by computing a fraud proof.

PLONK

A general-purpose zero-knowledge proof scheme relying on KZG polynomial commitment scheme. It uses a universal (or updateable) trusted setup. It is theoretically compatible with any (achievable) tradeoff between proof size and security assumptions. For example, if we substitute KZG for FRI PLONK will turn into a kind of STARK.

Polynomial commitment

A commitment scheme that commits to a univariate polynomial. It is used for Sonic, Marlin, and PLONK proof schemes.

Pre-compiles

Special contracts that include complex cryptographic computations, but do not require the EVM overhead. For example, some hashing and signature schemes.

Proposer

An entity that creates a block of transactions, and propagates it to the network for inclusion in the blockchain.

Proto-danksharding (EIP-4844)

A proposal to implement most of the logic and architecture that make up a full Danksharding spec (eg. transaction formats, verification rules), but not yet actually implementing any sharding. In a proto-danksharding implementation, all validators and users still have to directly validate the availability of the full data.

Prover

An entity that generates the cryptographic proof to convince the verifier that the statement is true (without revealing its inputs). In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. If used in the context of an optimistic rollup, the prover generates the fraud proof to show that an incorrect state was submitted.

Random oracle

A theoretical cryptographic primitive that is used to model the behavior of hash functions in security proofs.

Rewards

In the context of a rollup, an amount of some token allotted as a reward to the participant—proposer and/or prover—who performed a service for the network.

Rollup-as-a-service

An SDK or service that allows anyone to launch rollups quickly. Emphasis may be placed on the ability to customize the modular components of a rollup: VM, DA layer, proof system.

Rollup contracts

A bundle of smart contracts running on Ethereum that controls a rollup protocol. It includes the main contract which stores rollup blocks, tracks deposits, and monitors state updates, and the verifier contract which verifies zero-knowledge proofs submitted by provers.

RPC (Remote Procedure Call)

A protocol that a program uses to request a service from a program located on another computer in a network without having to understand the network details.

Secure multiparty computation

A type of computation where multiple parties jointly compute a function without revealing their inputs to each other, allowing for privacy-preserving computation.

Sequencer

A party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the batch to Ethereum L1 as a single transaction. Often synonymous with proposer.

Settlement

The mechanism with which the execution of rollup blocks and the resultant state is verified and possible disputes are resolved. In the context of rollups or other modular blockchains, it often refers to the proof system used--validity (ZK) or fraud proofs, or a combination thereof. Sometimes it will refer to this mechanism along with where the mechanism's outputs are ultimately published and verified, as in Ethereum being a settlement layer by verifying the proof(s).

Schnorr signature

A type of digital signature that is more efficient than traditional digital signatures and can be used in conjunction with threshold signatures to enable multisignature schemes.

Smart contract

A program that executes on the Ethereum computing infrastructure, or other blockchain.

SNARK

Short for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs.

STARK

Short for "scalable transparent argument of knowledge", a STARK is a type of zero-knowledge proof that resolves one of the primary weaknesses of ZK-SNARKs, its reliance on a "trusted setup”. STARKs also come with much simpler cryptographic assumptions, avoiding the need for elliptic curves, pairings, and the knowledge-of-exponent assumption and instead relying purely on hashes and information theory. This means that they are secure even against attackers with quantum computers.

Succinctness

A property of ZKP that stands for the following terms: (i) the proof of statement is shorter than the statement itself, (ii) the time to verify the proof is faster than just to evaluate the function from scratch.

Time Delay

In regards to upgradeability, a predefined amount of time that must elapse before the rollup smart contracts or parameters are updated. This protects users from malicious upgrades by giving them time to exit the rollup before upgrades come into effect.

Transaction

Data committed to the Ethereum Blockchain signed by an originating account, targeting a specific address. The transaction contains metadata such as the gas limit for that transaction.

Threshold cryptography

A type of cryptography where multiple parties jointly hold a secret key and must cooperate to perform cryptographic operations, enabling more secure and decentralized system.

Trusted setup (ceremony)

Generation of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact that a person generates a secret, uses it to generate the data, and then publishes the data and forgets the secret. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setup: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal (updatable) setup where it can be used for as many circuits as we want.

Trustlessness

The ability of a network to mediate transactions without any of the involved parties needing to trust a third party.

Turing completeness

A system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be "Turing-complete" or "computationally universal" if it is able to recognize or decide other data-manipulation rule sets.

Validator

A node in a blockchain system responsible for processing transactions, and adding or verifying new blocks to the blockchain.

Validity proof

The output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed.

Validium

An off-chain solution that uses validity proofs to improve transaction throughput. Unlike Zero-knowledge rollups, validium data isn't stored on layer 1 Mainnet.

Verifier

An entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.

Verkle tree

A data storage format of which you can make a proof that it contains some pieces of data to anyone who has the root of the tree. While similar to Merkle Patricia Trees, key differences include a much wider tree format which leads to smaller proof sizes.

Volition

A hybrid data availability mode, where the user can choose whether to place data on-chain or off-chain.

Zero-knowledge

A cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information.

Zero-knowledge proof (ZKP)

A zero-knowledge proof is the resulting output of a zero-knowledge cryptographic method.

ZK-Rollup

A rollup that uses ZKPs (also often called validity proofs to validate the correctness of the state transition function and update the rollup state. This is one of two main types of rollup constructions, along with optimistic rollups. In general, ZK-Rollups do not provide privacy preserving properties; privacy preserving ZK-Rollups are sometimes called ZK-ZK-Rollups.