The header of a block that contains a list of relevant metadata. This typically includes a Merkle root of the transactions in the block body, the hash of the previous block, the block height, and the timestamp, among others. The contents of the block header will also vary by sybil resistance mechanism (PoW or PoS) and by the specifications of the individual blockchain.

A group of blockchains that can communicate with each other in a trust-minimized way. Trust-minimized communication can be facilitated by fraud or validity proofs. Chains that can’t communicate in a trust-minimized way are in separate clusters that rely on trust-based communication.

For example, Ethereum and its rollups are a cluster of chains, and standalone layer 1s, such as Polygon, each sit in their own cluster.

Read more about the concept of clusters.

The ability for applications on a blockchain to read and write state to each other. Composability allows applications to coordinate with and build on top of one another such that it enables an ecosystem of interconnected applications.

For example, an application that automates liquidity strategies on Uniswap requires it to be reading and writing the state of Uniswap’s contracts.

A consensus algorithm is a set of rules that blockchains use to determine how nodes produce new blocks and agree to finalize them. Examples of blockchain consensus algorithms include Tendermint, commonly used by Cosmos chains, Casper, used by Ethereum and Nakamoto consensus used by Bitcoin. Proof of Work and Proof of Stake are commonly confused as consensus algorithms, when they are actually sybil resistance mechanisms.

A consensus layer refers to a modular blockchain that provides transaction ordering for other modular blockchains, like rollups. Modular blockchains that are a consensus layer may also provide data availability, like Celestia. ‘Consensus layer’ may also refer to the consensus mechanism of a monolithic blockchain.

Consensus refers to a function of modular blockchains where the ordering of transactions is agreed upon by a set of validators. To agree on the order of transactions in a block, validators follow a consensus algorithm.

The Cosmos SDK is a development kit for building applications to run on top of Tendermint consensus as a PoS layer 1 blockchain. The SDK provides a framework with which the business logic of new L1 blockchains can easily be created by separating the software components into distinct modules. Separation of components through modules enables flexibility and customization during the development process.

The ability for separate blockchains to communicate and interact with each other. Since blockchain interoperability has proven difficult, many pieces of infrastructure to support interoperability have arisen such as bridges, as well as blockchain architectures that are fundamentally designed to have interoperable chains, like Cosmos and their IBC network.

DA stands for Data Availability.

DAC stands for Data Availability Committee.

DAS stands for Data Availability Sampling.

A data availability committee (DAC) is a permissioned group of nodes responsible for providing data availability to a blockchain.DAC’s are an insecure source of data availability because they make an honest majority assumption and don’t have any stake to slash if a data withholding attack is attempted. Data availability committees are primarily used to provide a cheap and less secure source of data availability to L2s.

A data availability layer refers to a blockchain that provides data availability for other types of chains, like rollups. In the modular ecosystem, data availability layers make use of technologies like data availability sampling to provide scalable and trust-minimized data availability.

Data availability sampling is a mechanism for light nodes to verify data availability without having to download all data for a block. Data availability sampling (DAS) works by having light nodes conduct multiple rounds of random sampling for small portions of block data. As a light node completes more rounds of sampling for block data, it increases its confidence that data is available. Once the light node successfully reaches a predetermined confidence level (e.g. 99%) it will consider the block data as available.

When implemented in blockchain designs like Celestia, data availability sampling enables light nodes to contribute to both the security and throughput of the network with significantly cheaper hardware than that of full nodes.

Data availability answers the question, has this data been published? Specifically, a node will verify data availability when it receives a new block that is getting added to the chain. The node will attempt to download all the transaction data for the new block to verify availability. If the node can download all the transaction data, then it successfully verified data availability, proving that the block data was actually published to the network.

For an overview on data availability, read What is Data Availability?

A measurement of the data capacity of a blockchain. Data throughput is calculated by the amount of data that a blockchain can process, measured in kb/s or mb/s. For example, consider a blockchain that has a block size of 10MB and a block time of 20 seconds. The data throughput of the blockchain would be 0.5MB/s. Data throughput is most relevant to data availability layers because their primary job is to provide a high capacity for data.

A type of attack that occurs when a block producer proposes a new block but does not share the underlying transaction data that was used to create the block. Blockchains typically ensure proposed blocks are available by requiring validators to download the entire block and vote on whether the block was valid or not. If the majority of the validator set is malicious and votes that a block with unavailable data is valid, it will be added to the chain but rejected by full nodes.

While full nodes can verify that the block is invalid by fully downloading it, light clients have no such mechanism as they only download the block header. Techniques such as data availability sampling can provide light clients with a method to verify data availability without having to download the entire block, allowing them to retain minimal resource requirements.

The handling and resolution of disputes, commonly used in relation to optimistic rollups and their fraud proof mechanism. Optimistic rollups submit transactions to an L1 under the assumption they are correct. If an eligible entity disagrees with the validity of the rollup’s transactions, they can issue a dispute and generate a fraud proof.

The dispute is considered resolved once the fraud proof has been verified, any offending parties are punished, and any required changes of the rollup’s chain are complete. The dispute resolution is said to be external if the process occurs on the L1 instead of on the rollup.

EE stands for Execution Environment.

The virtual environment within a blockchain where transactions are processed, and accounts and smart contracts live. The execution environment is also responsible for determining the rules that dictate how each block updates the state, known as a state transition function.

All blockchains have execution environments, however their functionality may vary based on how they are implemented. For example, the Ethereum virtual machine (EVM) is Ethereum’s native execution environment, where Ethereum transactions are executed, and accounts and smart contracts live. The EVM has also been implemented by other blockchains which allows smart contracts to be written in EVM-based programming languages, such as solidity.

An execution layer is a type of modular blockchain whose primary job is hosting smart contracts and executing transactions. A common example of an execution layer is a rollup. Execution layers utilize one or multiple other modular blockchains to fulfill any of the following functions: settlement, consensus, or data availability.

An execution layer may also refer to the execution environment of a monolithic blockchain.

Execution refers to a function of modular blockchains where transactions are executed and the new state of the chain is determined.

A type of market that blockchains implement to prevent malicious actors from spamming the network. Fee markets typically utilize an auction mechanism, where users can specify their transaction fee and bid to have their transaction included in the next block. Fee markets are most noticeable for blockchains that experience high fees where demand exceeds capacity, and users are forced to increasingly bid up their transaction fees to be included in a block.

An algorithm that nodes use to correctly identify and follow the canonical chain. In Nakamoto consensus, the consensus mechanism that Bitcoin uses, nodes follow the chain that has the most total difficulty - the most work put towards mining it. In Tendermint, the consensus mechanism used by Cosmos chains, nodes follow the chain that has valid blocks signed by ⅔ of the stake.

A software upgrade that causes a blockchain to split into two chains that may or may not be compatible with each other. Forks can also occur when there is a temporary split in the chain, such as in proof of work.

A type of node that fully verifies a blockchain. To fully verify a block, at minimum, a full node must download the block’s data and check that it has consensus. If full nodes are required to ensure that the transactions are valid, they must also re-execute them.

The assumption that a majority of blockchain participants (such as the validator set) are honest and follow the rules of the protocol. If a majority of participants are dishonest, attacks can be made that are within the rules of the protocol but cause negative effects.

Honest majority assumptions can come in many forms. For example, light clients make an honest majority assumption about state validity because they don't verify transactions. If a majority of validators are dishonest and create invalid blocks, light clients can't verify that the blocks are invalid because from their perspective the blocks received consensus from a majority of the validator set.

The assumption that only a minority of blockchain participants are honest and follow the rules of the protocol. If a certain majority of participants are dishonest, attacks can be made that are within the rules of the protocol but cause negative effects.

Honest minority assumptions can come in multiple forms, such as a 1-of-N assumption where only a single honest participant is required to be honest for the blockchain to hold a guarantee. For example, optimistic rollup users and nodes require a 1-of-N assumption for safety as at least one honest full node is required to monitor the rollup and submit fraud proofs in the event of fraud.

Communication that occurs between blockchains that are in different clusters. Since inter-cluster communication involves bridges that rely on an honest majority assumption to ensure that funds can’t be stolen, communication can’t be trust-minimized. The Ethereum-Polygon bridge is an example of inter-cluster communication because 2/3 of a committee is required to sign off on blocks.

Communication that occurs between blockchains that are in the same cluster. Since these blockchains can rely on bridges that don’t require an honest majority assumption to ensure that funds can’t be stolen, they can communicate in a trust-minimized way.

ISR stands for Intermediate State Root.

A type of node that only downloads and verifies block headers, relying on an honest majority assumption that the state of the chain indicated by the block header is valid.

Since light clients aren’t required to download and execute transactions like full nodes, they are able to run on considerably cheaper hardware, at the expense of weaker security guarantees.

However, Celestia light clients (known as light nodes) do not make an honest majority assumption for state validity because they can also verify the body of the block through data availability sampling.

In Celestia, a light node is a type of node that verifies block headers and does data availability sampling. Data availability sampling gives Celestia light nodes increased security compared to typical light clients because it lets them detect invalid blocks that have had data withheld by block producers.

Since light nodes don’t download all block data or execute transactions, they can run on considerably cheaper hardware than full nodes.

Liveness is a property of blockchains where validators produce new blocks and successfully finalize transactions. In the case where a blockchain stops producing blocks, it is said to have halted and had a liveness failure. An example of a liveness failure would be if ⅓ of stake in a Tendermint chain stops signing new blocks so no new blocks can get finalized. Simply put, liveness should guarantee that something good eventually happens.

Modular blockchains are specialists that only perform one or two functions. The functions that modular blockchains can specialize in are:

1. Execution
2. Settlement
3. Consensus
4. Data availability

Modular chains don’t sit alone, though. Multiple of them combine to perform all the tasks a monolithic chain does by itself. This combination of chains is what we call a modular stack.

For example, Celestia is a modular blockchain that specializes in providing consensus and data availability for other types of chains.

A modular stack is a combination of multiple modular blockchains. Multiple different types of modular stacks are possible because of how modular blockchains can be customized and combined with each other. Though, a modular stack must be made up of all functions.

Visit this Learn Modular article to learn more about the modular stack.

Monolithic blockchains are generalists that perform all functions by themselves. This is the opposite of modular blockchains, which specialize and outsource the remaining functions to other modular chains.

A Namespaced Merkle Tree (NMT) is a type of binary Merkle tree where each node in the tree is tagged by the minimum and maximum namespace of their children. The leaves in the tree are ordered by the namespace identifiers of the messages. This enables Merkle proofs of inclusion to be created that prove to a verifier all elements of the tree of a specific namespace have been included. Celestia uses an NMT to make it easy to prove inclusion of data for rollups.

NMT stands for Namespaced Merkle Tree.

A node is a device that participates in a blockchain protocol by running its software. Blockchains typically have multiple different node types that carry out different tasks. Some of those tasks include sending and receiving transactions, storing blocks, and participating in consensus.

Off-chain data availability occurs when an L2 publishes its transaction data somewhere separate from the L1 it settles on. For example, if an L2s settles to Ethereum but publishes its data to Celestia, it is using Celestia for off-chain data availability. If that L2 is settling and publishing its data to Ethereum, it is using on-chain data availability. L2’s that use on-chain data availability are called rollups while L2’s that use off-chain data availability are called validiums or plasma.

On-chain data availability occurs when an L2 publishes its transaction data to its designated L1. For example, a Celestia L2 that publishes its transaction data to Celestia is using on-chain data availability. If that Celestia L2 publishes its transaction data somewhere other than Celestia, it is using off-chain data availability. L2’s that use on-chain data availability are called rollups while L2’s that use off-chain data availability are called validiums or plasma.

A type of rollup that posts its blocks to a parent chain without any cryptographic proofs that attest to their validity. The parent chain receives the block with the corresponding signatures and optimistically assumes the transactions are correct.

If a block is suspected to be invalid, a dispute window is provided where the blocks are open to be challenged. If a block is challenged, a fraud proof will be used to verify whether it is invalid. Once the dispute window has closed, the block is considered final and no new challenges can be made.

Read more about optimistic rollups.

ORU stands for Optimistic Rollup.

A type of transaction, submitting a payload of arbitrary bytes (like a serialized block), paying for the amount of block space that the submitted data takes up.

PayForData is a Core transaction type that the Celestia node will deal with, and a main way that data will be submitted to Celestia.

A network in which nodes are connected and can communicate directly with each other without reliance on a third party to facilitate communication. Peer-to-peer networks are used in blockchains as a way for nodes to connect and send data between each other, such as transactions and block headers, among other things.

PFB stands for PayforBlob.

Proof of Stake is a mechanism that requires blockchain participants to stake a token to participate in consensus. For example, Ethereum requires nodes to stake the ETH token to become a validator. A validator’s stake can be slashed as a way to punish misbehavior.

QGB stands for Quantum Gravity Bridge.

A rollup is a type of blockchain that offloads some work to a layer 1, like Celestia. Rollups host applications and process user transactions. Once those transactions get processed, they are then published to layer 1. It’s layer 1s job to order those transactions and check that they are available, at minimum.

Over time, two primary designs emerged for rollups: optimistic and zk rollups.

Safety is a property of blockchains that a chain will not fork. If there are two conflicting blocks at the same height, then that chain is said to have had a safety failure. Simply put, safety should guarantee that a bad thing never happens.

Scalability is the ability of a blockchain to increase its capacity without an equal increase in the cost to run a node that verifies the chain. The key component of scaling is that a blockchain should keep hardware costs minimal while increasing its capacity.

A sequencer is a type of rollup node that is responsible for collecting transactions and producing new blocks.

A settlement layer refers to a modular blockchain whose primary role is to provide proof verification and dispute resolution for rollups. A settlement layer may also provide other features for rollups, such as a liquidity source or bridging hub. 'Settlement layer' may also refer to a monolithic blockchain used by rollups for the function of settlement.

Settlement primarily refers to a function of modular blockchains where transaction proofs from rollups are verified and disputes are resolved. Modular blockchains that specialize in settlement (e.g. settlement layers) may also provide other features, such as a liquidity source or bridging hub.

The process of separating a blockchain from a single chain into multiple chains (shards). Sharding provides scalability to a blockchain as it allows transactions to be executed in parallel so that nodes are only required to process a subset of all transactions.

Security that a blockchain inherits from an external source. This security can come in the forms such as preventing invalid state transitions or re-org attacks. Since security of the external blockchain can be shared, multiple blockchains can derive benefits from harnessing its security.

For example, Celestia will provide shared security to blockchains that deploy on it because they will inherit security from the consensus and data availability Celestia provides, which is shared among all chains that will utilize it.

Interchain security is another example of shared security where security isn’t inherited from the blockchain itself. Rather, the Cosmos Hub validator set will be able to opt-in to become a validator for other zones.

A mechanism employed in PoS blockchains that is used to deter and punish malicious behavior. Slashing was originally conceived as a method to solve the nothing at stake problem, which presented the problem that validators weren’t restricted by the number of forks they could vote on – unlike in PoW where miners only have a limited amount of hash power to dedicate to forks.

To become a validator, a node is typically required to stake a minimum amount of the network’s native token. If the validator is caught double-voting or voting for any competing fork other than the canonical chain, the validator's stake is reduced (slashed). The degree by which validators are slashed varies by network and the severity of the malicious behavior.

Slashing can also occur for behavior that is deemed dishonest despite any lack of malicious intent. Dishonest behavior can include going offline or missing network duties. Slashing as a deterrent for dishonest behavior is important for blockchains that employ BFT-like consensus mechanisms, where ≥1/3 of voting power can halt the network if they are offline or refuse to vote.

A smart contract is a program that runs on a blockchain. Smart contracts are written in programming languages such as Solidity or Rust and are used to create many applications that run on a blockchain, like decentralized exchanges, borrowing and lending protocols, and social media.

Social consensus is a process where individuals come to agreement on a change that will be made to a blockchain. Changes that require social consensus are typically outside the scope of the consensus protocol, such as governance-led upgrades or responses to attacks and network outages.

An application that is deployed on its own sovereign blockchain. Applications that are deployed to a shared environment with other applications don't retain sovereignty because they are bound by the social consensus of the underlying environment.

A blockchain that has independent control over itself and its applications via social consensus. A sovereign chain has the ability to respond to hacks and push upgrades.

In the context of a modular stack, a modular blockchain can only be considered sovereign if it has the ability to fork through social consensus without the permission of any underlying layers it utilizes. Rollups that utilize a modular stack to retain sovereignty are known as sovereign rollups.

A type of rollup that does not use a settlement layer to determine its canonical chain and validity rules. Instead, the canonical chain of the rollup is determined by the nodes in the rollup's peer-to-peer network. This means that settlement occurs on the rollup, rather than a separate settlement layer.

Sovereign rollups have three key benefits:

1. More freedom over the execution environment
2. No sharing of computation resources
3. Ability to hard fork if something goes wrong

For more information on sovereign rollups, view the blog post Rollups as sovereign chains.

A method for proving that a state transition is invalid. Optimistic rollups are a type of blockchain that utilize fraud proofs to prove invalid state transitions. Since fraud proofs only assess if fraud took place, they are only required during situations where a state transition is disputed.

A simple construction of a fraud proof requires nodes to re-execute the transaction(s) that were part of the disputed state transition. However, this can become prohibitively expensive if the blockchain they are being re-executed on has high gas fees. To avoid this, fraud proofs have been constructed that involve interactive verification games (IVGs) that narrow down the disputed state transition to just the key computation step in question, which is then re-executed to assess if it is fraudulent.

An assumption that the network is synchronous such that when a message is sent it will be received within a certain amount of time.

The problem with data availability occurs when the transaction data for a newly proposed block cannot be downloaded and verified. This type of attack by a block producer is called a data withholding attack, which sees the block producer withhold transaction data of a new block.

Since transaction data is withheld, nodes cannot update to the latest state. Such an attack can have numerous consequences, from halting a chain to gaining the ability to steal funds. The severity of the consequences will depend on the type of blockchain (L1 or L2) and whether data availability is kept on-chain or off-chain. The data availability problem commonly arises around L2 scaling solutions like rollups and validiums.

Read more about the data availability problem.

A measurement of the capacity of a blockchain. Throughput primarily measures two elements: data throughput and transaction throughput. Data throughput determines a blockchain’s data capacity, which is measured in kb/s or mb/s. Data throughput is most relevant to data availability layers because their primary job is to provide a high capacity for data.

Transaction throughput measures the computational capacity of a blockchain, which is commonly calculated by the number of transactions that can be processed per second (TPS). However, TPS is a subjective measure of throughput as transactions can vary in size. An objective measurement of throughput is the number of computational units that can be performed per second.

The computational capacity of a blockchain. Transaction throughput is commonly calculated by the number of transactions that can be processed per second (TPS). However, TPS is a subjective measure of throughput as transactions can vary in size. Therefore, larger transactions will result in lower TPS, and smaller transactions will lead to higher TPS. An objective measurement of throughput is the number of computational units that can be performed per second.

For example, consider a blockchain that has a limit of 15M computational units per block with a block time of 10 seconds. The objective throughput of the blockchain would be 1.5M units per second. Additionally, throughput can also be used to measure other parameters of a blockchain, such as data capacity.

A bridge between two blockchains that doesn’t require an intermediary, a committee, or an honest majority assumption to ensure that funds can’t be stolen. An example of a trust-minimized bridge is one between Ethereum and a rollup built on top of it.

A trust-minimized bridge is more secure than a trusted bridge. For that reason, chains that share trust-minimized bridges with each other can be thought of as a “cluster” or chains.

Read more about clusters and bridging.

A bridge between two blockchains that requires either a trusted intermediary, committee or an honest majority assumption to ensure that funds can’t be stolen. A trusted bridge can be exploited more easily than a trust-minimized bridge because it provides weaker guarantees for its security.

Examples of trusted bridges are the bridge for WBTC which is run by BitGo, a committee based bridge like Axelar, or the IBC bridge between Osmosis and the Cosmos Hub.

Read more about clusters and bridging.

A group of validators that are responsible for directly participating in the consensus of a blockchain through either voting, producing, or proposing blocks.

A full node that is part of the validator set in a PoS blockchain. Validators participate in consensus by voting on proposed blocks, and when elected leader they produce and propose blocks to the validator set.

A type of cryptographic proof that can be used to attest to the validity of a state transition. For example, zk-Rollups utilize validity proofs to prove valid state transitions to a parent chain - commonly used with proof systems such as SNARKs and STARKs.

A type of zero-knowledge rollup that posts its data off-chain rather than to its parent chain. The off-chain environment that data is posted to could be a committee of trusted parties or a separate chain, such as Celestia.

A zero-knowledge rollup with options for both on-chain and off-chain data availability. Users at the individual transaction level are given the choice to publish data on-chain, to a parent chain, or off-chain, to a separate environment. The off-chain mode acts as a validium, where data is published to a separate environment, which could be to a committee of trusted parties or a data availability chain.

A type of rollup that posts its blocks to a parent chain with a validity proof that attests to the correctness of the block. Since transactions are considered final once the validity proof is verified, there is no dispute window to challenge the zk-Rollup block’s validity.

ZKR stands for ZK Rollup.