Celestia docs
Celestia is the modular blockchain powering unstoppable apps with full-stack
control.
---
Title: Audits
URL: https://docs.celestia.org/learn/audits.md
Source: app/learn/audits/page.mdx
---
# Audits
This page provides a comprehensive list of audits conducted on various Celestia software, including OP Stack, Nitro, celestia-app, Blobstream, and more. Each audit is linked to its respective report.
| Software | Auditor | Link |
| -------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------- |
| OP Stack | OtterSec | [Link](https://docs.celestia.org/audits/Celestia_OP_Stack_Audit.pdf) |
| Nitro | OtterSec | [Link](https://github.com/celestiaorg/nitro/blob/celestia-v2.3.3/audits/celestia/arbitrum_nitro_celestia_audit_report.pdf) |
| v2 celestia-app Lemongrass | Informal Systems | [Link](https://github.com/celestiaorg/celestia-app/blob/main/docs/audit/informal-systems-v2.pdf) |
| v3 celestia-app | Informal Systems | [Link](https://github.com/celestiaorg/celestia-app/blob/main/docs/audit/informal-systems-authored-blobs.pdf) |
| Blobstream SP1 | OtterSec | [Link](https://docs.celestia.org/audits/SP1_Blobstream_Ottersec_Audit.pdf) |
| Blobstream SP1 | Multiple | [Link](https://github.com/succinctlabs/sp1/tree/dev/audits) |
| Blobstream X | Informal Systems | [Link](https://docs.celestia.org/audits/Blobstream_X-Informal_Systems_Audit.pdf) |
| Blobstream X | OtterSec | [Link](https://docs.celestia.org/audits/Blobstream_X-OtterSec_Audit.pdf) |
| Blobstream X | Veridise | [Link](https://docs.celestia.org/audits/Blobstream_X-Veridise_Audit.pdf) |
| Blobstream X | Zellic | [Link](https://docs.celestia.org/audits/Blobstream_X-Zellic_Audit.pdf) |
| Shwap | OtterSec | [Link](https://docs.celestia.org/audits/celestia_shwap_audit_final.pdf) |
| High throughput recovery | Informal Systems | [Link](https://github.com/celestiaorg/celestia-app/blob/main/docs/audit/informal-systems-recovery.pdf) |
---
Title: Blobstream
URL: https://docs.celestia.org/learn/blobstream.md
Source: app/learn/blobstream/page.mdx
---
# Blobstream
[Blobstream](https://blog.celestia.org/introducing-blobstream/)
allows Ethereum developers to build high-throughput L2s using Celestia,
the first DA layer with Data Availability Sampling.
This section covers Blobstream and how validators on Celestia can run it.
If you're looking to learn more, you can view
[the `orchestrator-relayer` repository](https://github.com/celestiaorg/orchestrator-relayer),
and [read more about Blobstream](https://github.com/celestiaorg/blobstream-contracts#how-it-works).
## Overview
Blobstream consists of two components: an [orchestrator](/operate/blobstream/orchestrator)
and a [relayer](/operate/blobstream/relayer).
In the following diagram, we show how a layer 2 would post data to
Celestia and then verify that it was published in the target EVM chain.
Data is first attested to by the Celestia validator set—they sign commitments to the data. Then, these signatures are relayed to the target EVM chain (in this case, Ethereum). Finally, the layer 2, or any party, can verify that the data was published to Celestia directly on the EVM chain via the Blobstream smart contract. You can reference [the Blobstream smart contract](https://github.com/celestiaorg/blobstream-contracts/blob/v3.0.0/src/Blobstream.sol).
The specification of Blobstream `Valset`s, which track the Celestia validator set changes, can be found in [ADR 002](https://github.com/celestiaorg/celestia-app/blob/main/docs/architecture/adr-002-qgb-valset.md).
Blobstream data commitments, which represent commitments over sets of blocks defined by a data commitment window, are discussed more in-depth in [ADR 003](https://github.com/celestiaorg/celestia-app/blob/main/docs/architecture/adr-003-qgb-data-commitments.md).
The orchestrator is part of the validator setup and works as follows:
- **Celestia App**: Creates an attestation on the state machine level that needs to be signed
- **The orchestrator**: Queries the attestation, signs it, then submits the signature to the Blobstream P2P network
The diagram below illustrates this process:
The relayer submits the attestations' signatures from the Blobstream P2P network to the target EVM chain.
> **Note:** If the contract is still not deployed, it needs to be deployed before it's used by the relayer. Check the [deployment documentation](/operate/blobstream/deploy-contract) for more details.
The diagram below illustrates the relayer process:
You can learn more about the mechanics behind the relayer in [ADR 004](https://github.com/celestiaorg/celestia-app/blob/main/docs/architecture/adr-004-qgb-relayer-security.md).
## Blobstream vs Data Availability Committees (DACs)
### Decentralization and security
Blobstream is built on Celestia, which uses a CometBFT-based proof-of-stake system. An incorrect data availability attestation in this system will ultimately be penalized (currently not implemented), ensuring validators act in good faith. Thus, Blobstream shares the same security assumptions as Celestia.
In contrast, data availability committees (DACs) are typically centralized or semi-centralized, relying on a specific set of entities or individuals to vouch for data availability.
### Mechanism of verification
Blobstream uses data availability attestations, which are Merkle roots of the batched L2 data, to confirm that the necessary data is present on Celestia. The L2 contract on Ethereum can check directly with Blobstream if the data is published on Celestia.
Similarly, a DAC would rely on attestations or confirmations from its permissioned members.
### Flexibility and scalability
Blobstream is designed to offer high-throughput data availability for Ethereum L2s, aiming to strike a balance between scalability and security. It operates independently of Ethereum's gas costs, as Celestia's resource pricing is more byte-focused rather than computation-centric.
On the other hand, the scalability and flexibility of a DAC would depend on its specific design and implementation.
In summary, both Blobstream and DACs aim to ensure offchain data availability, but Blobstream offers a more decentralized, secure, and scalable solution compared to the potential centralized nature of DACs.
## Build with Blobstream
If you are a developer looking to build on top of Blobstream, check out the [Build section](/build/blobstream/integrate-contracts).
## Operate Blobstream
If you are a validator or node operator looking to run Blobstream, check out the [Operate section](/operate/blobstream/install-binary) to learn how to deploy your own instance.
---
Title: Data availability FAQ
URL: https://docs.celestia.org/learn/celestia-101/data-availability-faq.md
Source: app/learn/celestia-101/data-availability-faq/page.mdx
---
# Data availability FAQ
# What is data availability?
Data availability is about proving that a block's transactions have been published to the network. In most chains this means downloading all transaction data for a new block; in Celestia, light nodes can answer this question via DAS without full downloads.
## What is the data availability problem?
If a block producer withholds data for a proposed block (a data withholding attack), other nodes cannot update state or verify the chain. The risk varies by architecture—for example, rollups and validiums are especially sensitive.
## How do nodes verify data availability in Celestia?
Full nodes can download entire blocks as usual. Light nodes leverage DAS: they request random shares with Merkle proofs from the extended data matrix. See [Data availability sampling](#data-availability-sampling-das) for details.
## What is data availability sampling?
DAS lets light nodes make repeated random sampling requests for small portions of a block. As more samples succeed, confidence that the full block is available rises (e.g., to 99%+). A simple analogy is coin flips: enough successful flips (samples) give high confidence the data exists.
## What security assumptions does DAS rely on?
- Enough light nodes sample for the given block size so an honest bridge node can reconstruct the full block from their collected shares.
- Light nodes connect to at least one honest bridge node to receive fraud proofs for incorrectly erasure-coded blocks; eclipse attacks can break this assumption.
## Why is block reconstruction necessary for security?
Blocks are erasure coded; malicious encoders could extend data incorrectly. Bridge nodes need the full block to produce fraud proofs of bad encoding. If only light nodes receive data and bridge nodes cannot reconstruct the block, the network could miss invalid encoding.
## What is data storage and how is it different?
Data storage concerns keeping and retrieving historical transaction data. The security assumption for storage is 1-of-N honesty—only one honest keeper of history is needed—while data availability is about new blocks being publishable and verifiable.
## What problems arise around data storage?
If historical data cannot be retrieved, users may lose access to transaction history and nodes cannot sync from genesis. This is a retrieval problem, not an availability problem.
## Where does blockchain state fit into this?
State (balances, contract storage, validator set) is a snapshot derived from transaction data. Its growth poses different challenges than DA or data retrieval.
## Why doesn’t Celestia incentivize storing historical data?
Guaranteeing permanent storage is not the DA layer’s role, and storage needs only 1-of-N honest providers. Celestia focuses on securely publishing data; third parties store history based on their incentives.
## Who might store historical data?
- Block explorers serving past transactions
- Indexers with query APIs
- Applications or rollups needing history for processes
- Users who want their own transaction history
## How can chains improve data retrievability?
- Reward nodes for storing and serving data (e.g., storage networks like [Filecoin](https://filecoin.io)).
- Publish transaction data to an incentivized storage layer.
- Offer paid archival access or snapshots so others can sync from known good data.
---
Title: Celestia's data availability layer
URL: https://docs.celestia.org/learn/celestia-101/data-availability.md
Source: app/learn/celestia-101/data-availability/page.mdx
---
# Celestia's data availability layer
Data availability (DA) answers a simple question: **has this block's data been published and can it be downloaded? In other words, is the data available?** When a node receives a new block, it must be able to retrieve the associated transaction data; otherwise, the chain can stall or be exploited. Celestia provides a modular DA layer so light nodes can verify availability efficiently without downloading whole blocks.
## tl;dr
1. Celestia is a modular data availability network: it orders blobs and keeps them available while execution and settlement live on layers above.
2. It scales by decoupling execution from consensus and using data availability sampling (DAS) so light nodes can verify availability without downloading whole blocks; more light nodes sampling safely unlocks larger block sizes.
3. Namespaced Merkle trees (NMTs) let each app fetch only its own namespaced data and prove availability.
4. Block producers erasure-code blobs into a $2k \times 2k$ matrix, commit to every row and column, and put that root in the header.
5. Light nodes sample within a rolling window; archival nodes (or providers) keep older data retrievable.
Celestia is a data availability (DA) layer that provides a
scalable solution to the [data availability problem](https://coinmarketcap.com/academy/article/what-is-data-availability).
Due to the permissionless nature of the blockchain networks,
a DA layer must provide a mechanism for the execution and settlement
layers to check in a trust-minimized way whether transaction data is indeed available.
Two key features of Celestia's DA layer are [data availability sampling](https://blog.celestia.org/celestia-mvp-release-data-availability-sampling-light-clients)
(DAS) and [Namespaced Merkle trees](https://github.com/celestiaorg/nmt) (NMTs).
Both features are novel blockchain scaling solutions: DAS enables light
nodes to verify data availability without needing to download an entire block;
NMTs enable execution and settlement layers on Celestia to download transactions
that are only relevant to them.
## Data availability sampling (DAS)
In general, light nodes download only block headers that contain
commitments (_i.e._, Merkle roots) of the block data (_i.e._, the list of transactions).
To make DAS possible, Celestia uses a 2-dimensional Reed-Solomon
encoding scheme to encode the block data: every block data is split
into $k \times k$ shares, arranged in a $k \times k$ matrix, and extended with parity
data into a $2k \times 2k$ extended matrix by applying multiple
times Reed-Solomon encoding.
Then, $4k$ separate Merkle roots are computed for the rows and columns
of the extended matrix; the Merkle root of these Merkle roots is used
as the block data commitment in the block header.
To verify that the data is available, Celestia light nodes are sampling
the $2k \times 2k$ data shares.
Every light node randomly chooses a set of unique coordinates in the
extended matrix and queries bridge nodes for the data shares and the
corresponding Merkle proofs at those coordinates. If light nodes
receive a valid response for each sampling query, then there is a
[high probability guarantee](https://github.com/celestiaorg/celestia-node/issues/805#issuecomment-1150081075)
that the whole block's data is available.
Additionally, every received data share with a correct Merkle proof
is gossiped to the network. As a result, as long as the Celestia light
nodes are sampling together enough data shares (_i.e._, at least
$k \times k$ unique shares),
the full block can be recovered by honest bridge nodes.
For more details on DAS, take a look at the [original paper](https://arxiv.org/abs/1809.09044).
### Scalability
DAS enables Celestia to scale the DA layer. DAS can be performed by
resource-limited light nodes since each light node only samples a small
portion of the block data. The more light nodes there are in the network,
the more data they can collectively download and store.
This means that increasing the number of light nodes performing DAS allows
for larger blocks (_i.e._, with more transactions), while still keeping DAS
feasible for resource-limited light nodes. However, in order to validate
block headers, Celestia light nodes need to download the $4k$ intermediate
Merkle roots.
For a block data size of $n^2$ bytes, this means that every light node must
download $O(n)$ bytes. Therefore, any improvement in the bandwidth capacity
of Celestia light nodes has a quadratic effect on the throughput of Celestia's
DA layer.
### Fraud proofs of incorrectly extended data
The requirement of downloading the $4k$ intermediate Merkle roots is a
consequence of using a 2-dimensional Reed-Solomon encoding scheme. Alternatively,
DAS could be designed with a standard (_i.e._, 1-dimensional) Reed-Solomon encoding,
where the original data is split into $k$ shares and extended with $k$ additional
shares of parity data. Since the block data commitment is the Merkle root of the
$2k$ resulting data shares, light nodes no longer need to download $O(n)$ bytes to
validate block headers.
The downside of the standard Reed-Solomon encoding is dealing with malicious
block producers that generate the extended data incorrectly.
This is possible as **Celestia does not require a majority of the consensus
(_i.e._, block producers) to be honest to guarantee data availability.**
Thus, if the extended data is invalid, the original data might not be
recoverable, even if the light nodes are sampling sufficient unique shares
(_i.e._, at least $k$ for a standard encoding and $k \times k$ for a
2-dimensional encoding).
As a solution, _Fraud Proofs of Incorrectly Generated Extended Data_ enable
light nodes to reject blocks with invalid extended data. Such proofs require
reconstructing the encoding and verifying the mismatch. With standard Reed-Solomon
encoding, this entails downloading the original data, _i.e._, _n²_ bytes.
Contrastingly, with 2-dimensional Reed-Solomon encoding, only $O(n)$ bytes are
required as it is sufficient to verify only one row or one column of the
extended matrix.
## Namespaced Merkle trees (NMTs)
Celestia partitions the block data into multiple namespaces, one for
every application (e.g., rollup) using the DA layer. As a result, every
application needs to download only its own data and can ignore the data
of other applications.
For this to work, the DA layer must be able to prove that the provided
data is complete, _i.e._, all the data for a given namespace is returned.
To this end, Celestia is using Namespaced Merkle trees (NMTs).
An NMT is a Merkle tree with the leaves ordered by the namespace identifiers
and the hash function modified so that every node in the tree includes the
range of namespaces of all its descendants. The following figure shows an
example of an NMT with height three (_i.e._, eight data shares). The data is
partitioned into three namespaces.
When an application requests the data for namespace 2, the DA layer must
provide the data shares `D3`, `D4`, `D5`, and `D6` and the nodes `N2`, `N8`
and `N7` as proof (note that the application already has the root `N14` from
the block header).
As a result, the application is able to check that the provided data is part
of the block data. Furthermore, the application can verify that all the data
for namespace 2 was provided. If the DA layer provides for example only the
data shares `D4` and `D5`, it must also provide nodes `N12` and `N11` as proofs.
However, the application can identify that the data is incomplete by checking
the namespace range of the two nodes, _i.e._, both `N12` and `N11` have descendants
part of namespace 2.
For more details on NMTs, refer to the [original paper](https://arxiv.org/abs/1905.09274).
## Building a PoS blockchain for DA
### Providing data availability
The Celestia DA layer consists of a PoS blockchain. Celestia is dubbing this
blockchain as the [celestia-app](https://github.com/celestiaorg/celestia-app),
an application that provides transactions to facilitate the DA layer and is built
using [Cosmos SDK](https://docs.cosmos.network/sdk/v0.53). The following figure
shows the main components of celestia-app.
celestia-app is built on top of [celestia-core](https://github.com/celestiaorg/celestia-core),
a modified version of the [Tendermint consensus algorithm](https://arxiv.org/abs/1807.04938).
Among the more important changes to vanilla Tendermint, celestia-core:
- Enables the erasure coding of block data (using the [2-dimensional Reed-Solomon
encoding scheme](https://github.com/celestiaorg/rsmt2d)).
- Replaces the regular Merkle tree used by Tendermint to store block data with
a [Namespaced Merkle tree](https://github.com/celestiaorg/nmt) that enables
the above layers (_i.e._, execution and settlement) to only download the needed
data (for more details, see the section below describing use cases).
For more details on the changes to Tendermint, take a look at the
[ADRs](https://github.com/celestiaorg/celestia-core/tree/v0.34.x-celestia/docs/celestia-architecture).
Notice that celestia-core nodes are still using the Tendermint p2p network.
Similarly to Tendermint, celestia-core is connected to the application layer
(_i.e._, the state machine) by [ABCI++](https://github.com/tendermint/tendermint/tree/master/spec/abci%2B%2B),
a major evolution of [ABCI](https://github.com/tendermint/tendermint/tree/master/spec/abci)
(Application Blockchain Interface).
The celestia-app state machine is necessary to execute the PoS logic and to
enable the governance of the DA layer.
However, the celestia-app is data-agnostic -- the state machine neither
validates nor stores the data that is made available by the celestia-app.
## Monolithic vs. modular blockchains
Blockchains instantiate [replicated state machines](https://dl.acm.org/doi/abs/10.1145/98163.98167):
the nodes in a permissionless distributed network apply an ordered sequence
of deterministic transactions to an initial state resulting in a common
final state.
In other words, this means that nodes in a network all follow
the same set of rules (_i.e._, an ordered sequence of transactions) to go from a
starting point (_i.e._, an initial state) to an ending point
(_i.e._, a common final state). This process ensures that all
nodes in the network agree on the final state
of the blockchain, even though they operate independently.
This means blockchains
require the following four functions:
- **Execution** entails executing transactions that update the state correctly.
Thus, execution must ensure that only valid transactions are executed, _i.e._,
transactions that result in valid state machine transitions.
- **Settlement** entails an environment for execution layers to verify proofs,
resolve fraud disputes, and bridge between other execution layers.
- **Consensus** entails agreeing on the order of the transactions.
- **Data Availability** (DA) entails making the transaction data available.
Note that execution, settlement, and consensus require DA.
Traditional blockchains, _i.e._ _monolithic blockchains_, implement all four
functions together in a single base consensus layer. The problem with
monolithic blockchains is that the consensus layer must perform numerous
different tasks, and it cannot be optimized for only one of these functions.
As a result, the monolithic paradigm limits the throughput of the system.
As a solution, modular blockchains decouple these functions among
multiple specialized layers as part of a modular stack. Due to the
flexibility that specialization provides, there are many possibilities
in which that stack can be arranged. For example, one such arrangement
is the separation of the four functions into three specialized layers.
The base layer consists of DA and consensus and thus, is referred to
as the Consensus and DA layer (or for brevity, the DA layer), while both
settlement and execution are moved on top in their own layers. As a result,
every layer can be specialized to optimally perform only its function, and thus,
increase the throughput of the system. Furthermore, this modular paradigm
enables multiple execution layers, _i.e._,
[rollups](https://vitalik.eth.limo/general/2021/01/05/rollup.html), to use the
same settlement and DA layers.
---
Title: Data, dashboards, and analytics
URL: https://docs.celestia.org/learn/celestia-101/resources.md
Source: app/learn/celestia-101/resources/page.mdx
---
# Data, dashboards, and analytics
A collection of useful tools, dashboards, and analytics platforms for exploring the Celestia network.
## Useful links
1. Learn category of celestia.org: https://celestia.org/learn/
2. Celestia glossary: https://celestia.org/glossary/
3. Celestia-app specifications: https://celestiaorg.github.io/celestia-app/
4. Awesome-celestia repo: https://github.com/celestiaorg/awesome-celestia/
## Data analytics & dashboards
| Resource | Description | URL |
| ----------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------ |
| **Celenium** | Blockchain explorer and analytics platform for Celestia | [celenium.io](https://celenium.io/) |
| **Celestia Data** | Comprehensive analytics and metrics for the Celestia network | [celestiadata.com](https://celestiadata.com/) |
| **L2 Beat** | Data availability tracking and metrics by L2BEAT | [l2beat.com](https://l2beat.com/data-availability/projects/celestia/no-bridge) |
| **Validao** | Validator and network visualization tools | [validao.xyz](https://validao.xyz/#maps-celestia-da) |
## Bridge & node data
| Resource | Description | URL |
| ------------------------------ | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| **Bridge node data dashboard** | Looker Studio dashboard for Celestia bridge metrics | [View dashboard](https://lookerstudio.google.com/u/0/reporting/73fc0733-5f3e-4a85-be1f-081f99991f4c/page/Tn17D) |
## Research & analytics
| Resource | Description | URL |
| ------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| **Blockworks research (paid)** | In-depth analytics and research on TIA and the Celestia network | [View analytics](https://app.blockworksresearch.com/analytics/tia?dashboard=celestia&interval=weekly) |
| **Numia blocks dashboard** | Blocks analytics dashboard | [View dashboard](https://lookerstudio.google.com/u/0/reporting/6d5530fd-4115-4951-8a79-644842f6a2b3/page/Tn17D) |
| **Numia rollups dashboard** | Rollups analytics dashboard | [View dashboard](https://lookerstudio.google.com/u/0/reporting/8853db32-fe0b-4a39-b4d7-3b9efd9e5226/page/p_da0hhwxfjd) |
## Rollup tracking
| Resource | Description | URL |
| -------------- | --------------------------------------- | -------------------------------- |
| **rollup.wtf** | Rollup ecosystem tracking and analytics | [rollup.wtf](https://rollup.wtf) |
---
Title: Data retrievability and pruning
URL: https://docs.celestia.org/learn/celestia-101/retrievability.md
Source: app/learn/celestia-101/retrievability/page.mdx
---
# Data retrievability and pruning
The purpose of data availability layers such as Celestia is to ensure
that block data is provably published, so that applications
and rollups can know what the state of their chain is, and store that data.
Once the data is published, data availability layers
[do not inherently guarantee that historical data will be permanently stored](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#If-data-is-deleted-after-30-days-how-would-users-access-older-blobs)
and remain retrievable.
In this document, we discuss the state of data retrievability and
pruning in Celestia, as well as some tips for rollup developers in
order to ensure that syncing new rollup nodes is possible.
## Data retrievability and pruning in celestia-node
As of version v6 of celestia-app, celestia-node has implemented a light node
sampling window of 7 days, as specified in
[CIP-36](https://github.com/celestiaorg/CIPs/blob/main/cips/cip-036.md).
Light nodes now only sample blocks within a 7-day
window instead of sampling all blocks from genesis. This change
introduces the concept of pruning to celestia-node, where data
outside of the 7-day window may not be stored by light nodes,
marking a significant update in how data retrievability and
storage are managed within the network.
Data blobs older than the recency window will be pruned by default
on light nodes,
but will continue to be stored by archival nodes that do not prune data. Light
nodes will be able to query historic blob data in namespaces from archival
nodes, as long as archival nodes exist on the public network.
## Suggested practices for rollups
Rollups may need to access historic data in order to allow new rollup nodes
to reconstruct the latest state by replaying historical blocks. Once data has
been published on Celestia and guaranteed to have been made available, rollups
and applications are responsible for storing their historical data.
While it is possible to continue to do this by using the `GetAll` API method in
celestia-node on historic blocks as long as archival nodes exist on the public
Celestia network, rollup developers should not rely on this as the only method
to access historical data, as archival nodes serving requests for historical
data for free is not guaranteed. Below are some other suggested methods to
access historical data.
- **Use professional archival node or data providers.** It is expected that
professional infrastructure providers will provide paid access to archival
nodes, where historical data can be retrieved, for example using the `GetAll`
API method. Providers like QuickNode offer archival node services that maintain
complete historical data, ensuring reliable access to past transactions and state.
This provides better guarantees than solely relying on free archival nodes on the
public Celestia network. For a list of available providers, see the
[network's](/operate/networks/mainnet-beta) page, and for specific archival
node endpoints, refer to the [archival DA RPC endpoints](/operate/networks/mainnet-beta#archival-da-rpc-endpoints)
section.
- **Share snapshots of rollup nodes.** Rollups could share snapshots of their
data directories which can be downloaded manually by users bootstrapping new
nodes. These snapshots could contain the latest state of the rollup, and/or
all the historical blocks.
- **Add peer-to-peer support for historical block sync.** A less manual version
of sharing snapshots, where rollup nodes could implement built-in support for
block sync, where rollup nodes download historical block data from each other
over a peer-to-peer network.
- [**Namespace pinning.**](https://github.com/celestiaorg/celestia-node/issues/2830)
In the future, celestia-node is expected to allow nodes to choose to "pin"
data from selected namespaces that they wish to store and make available for
other nodes. This will allow rollup nodes to be responsible for storing their
data, without needing to implement their own peer-to-peer historical block
sync mechanism.
---
Title: The lifecycle of a celestia-app transaction
URL: https://docs.celestia.org/learn/celestia-101/transaction-lifecycle.md
Source: app/learn/celestia-101/transaction-lifecycle/page.mdx
---
# The lifecycle of a celestia-app transaction
Users request the celestia-app to make data available by
sending `PayForBlobs` transactions. Every such transaction consists
of the identity of the sender, the data to be made available, also
referred to as the message, the data size, the namespace, and
a signature. Every block producer batches multiple `PayForBlobs`
transactions into a block.
Before proposing the block though, the producer passes it to the
state machine via ABCI++, where each `PayForBlobs` transaction is
split into a namespaced message (denoted by `Msg` in the figure below),
i.e., the data together with the namespace ID, and an executable
transaction (denoted by `e-Tx` in the figure below) that does not
contain the data, but only a commitment that can be used at a later
time to prove that the data was indeed made available.
Thus, the block data consists of data partitioned into namespaces
and executable transactions. Note that only these transactions are
executed by the Celestia state machine once the block is committed.
Next, the block producer adds to the block header a commitment
of the block data. As
[described in the "Celestia's data availability layer" page](/learn/celestia-101/data-availability),
the commitment is the Merkle root of the $4k$ intermediate Merkle roots
(i.e., one for each row and column of the extended matrix).
To compute this commitment, the block producer performs the following operations:
- It splits the executable transactions and the namespaced data
into shares. Every share consists of some bytes prefixed by a
namespace. To this end, the executable transactions are associated
with a reserved namespace.
- It arranges these shares into a square matrix (row-wise). Note that
the shares are padded to the next power of two. The outcome square
of size $k \times k$ is referred to as the original data.
- It extends the original data to a $2k \times 2k$ square matrix using
the 2-dimensional Reed-Solomon encoding scheme described above.
The extended shares (i.e., containing erasure data) are associated
with another reserved namespace.
- It computes a commitment for every row and column of the extended
matrix using the NMTs described above.
Thus, the commitment of the block data is the root of a Merkle tree
with the leaves the roots of a forest of Namespaced Merkle subtrees,
one for every row and column of the extended matrix.
## Checking data availability
To enhance connectivity, the celestia-node augments the celestia-app
with a separate libp2p network, _i.e._, the so-called _DA network_,
that serves DAS requests.
Light nodes connect to a celestia-node in the DA network, listen to
extended block headers (i.e., the block headers together with the
relevant DA metadata, such as the $4k$ intermediate Merkle roots), and
perform DAS on the received headers (i.e., ask for random data shares).
Note that although it is recommended, performing DAS is optional -- light
nodes could just trust that the data corresponding to the commitments in
the block headers was indeed made available by the Celestia DA layer.
In addition, light nodes can also submit transactions to the celestia-app,
i.e., `PayForBlobs` transactions.
While performing DAS for a block header, every light node queries Celestia
Nodes for a number of random data shares from the extended matrix and the
corresponding Merkle proofs. If all the queries are successful, then the
light node accepts the block header as valid (from a DA perspective).
If at least one of the queries fails (i.e., either the data share is not
received or the Merkle proof is invalid), then the light node rejects the
block header and tries again later. The retrial is necessary to deal with
false negatives, i.e., block headers being rejected although the block
data is available. This may happen due to network congestion for example.
Alternatively, light nodes may accept a block header although the data
is not available, i.e., a _false positive_. This is possible since the
soundness property (i.e., if an honest light node accepts a block as available,
then at least one honest bridge node will eventually have the entire block data)
is probabilistically guaranteed (for more details, take a look at the
[original paper](https://arxiv.org/abs/1809.09044)).
By fine tuning Celestia's parameters (e.g., the number of data shares sampled
by each light node) the likelihood of false positives can be sufficiently
reduced such that block producers have no incentive to withhold the block data.
---
Title: Celestia.org Code of Conduct
URL: https://docs.celestia.org/learn/code-of-conduct.md
Source: app/learn/code-of-conduct/page.mdx
---
# Celestia.org Code of Conduct
## Our Pledge
We as Celestia.org members, contributors, and leaders pledge to make
participation in our community a harassment-free experience for everyone,
regardless of age, body size, visible or invisible disability, ethnicity,
sex characteristics, gender identity and expression, level of experience,
education, socio-economic status, nationality, personal appearance, race,
caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
- Demonstrating empathy and kindness toward other people
- Being respectful of differing opinions, viewpoints, and experiences
- Giving and gracefully accepting constructive feedback
- Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
- Focusing on what is best not just for us as individuals, but for the overall
community
- Contributing to conversations about Celestia’s technology and ecosystem
Examples of unacceptable behavior include:
- The use of sexualized language or imagery, and sexual attention or advances of
any kind
- Trolling, insulting or derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or email address,
without their explicit permission
- Focusing on the prices of digital assets or tokens, or where they can be purchased
- Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at Celestia.org Discord.
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series of
actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within the
community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.1, available at
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
Community Impact Guidelines were inspired by
[Mozilla's code of conduct enforcement ladder][Mozilla CoC].
For answers to common questions about this code of conduct, see the FAQ at
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
[https://www.contributor-covenant.org/translations][translations].
[homepage]: https://www.contributor-covenant.org
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
[Mozilla CoC]: https://github.com/mozilla/diversity
[FAQ]: https://www.contributor-covenant.org/faq
[translations]: https://www.contributor-covenant.org/translations
---
Title: Using Hyperlane with Celestia
URL: https://docs.celestia.org/learn/features/bridging/hyperlane.md
Source: app/learn/features/bridging/hyperlane/page.mdx
---
# Using Hyperlane with Celestia
## Live bridge
- [Hyperlane Nexus UI](https://nexus.hyperlane.xyz/?origin=celestia&token=TIA&destination=base)
## Summary
[Hyperlane](https://hyperlane.xyz/) is a permissionless interoperability layer that lets blockchains send messages and trigger actions on one another. Along with [IBC](/learn/features/bridging/ibc), it is one of the standards used on Celestia for cross-chain asset transfers and messages.
You can use Hyperlane to bridge TIA between Celestia and other EVM-compatible chains, as well as send arbitrary cross-chain messages.
## How bridging works
```mermaid
flowchart LR
%% --- Chain A ---
subgraph ChainA["Chain A"]
A_App["Application"]
A_Mailbox["Mailbox Contract"]
A_ISM["Interchain Security Module"]
end
%% --- Chain B ---
subgraph ChainB["Chain B"]
B_App["Application"]
B_Mailbox["Mailbox Contract"]
B_ISM["Interchain Security Module"]
end
%% Internal flows (Chain A)
A_App --> A_Mailbox
A_Mailbox --> A_ISM
A_ISM -->|Verify Message| A_Mailbox
%% Internal flows (Chain B)
B_App --> B_Mailbox
B_Mailbox --> B_ISM
B_ISM -->|Verify Message| B_Mailbox
%% Cross-chain relayer messages
A_Mailbox <-->|Relayers