Celestia Improvement Proposals (CIPs)

Abstract

This CIP proposes Fibre, a validator-operated protocol for publishing blobs whose payload bytes are stored and served outside the normal block data path. Fibre keeps an on-chain record of publication through MsgPayForFibre transactions and synthesized system blobs that commit to the Fibre blob version and commitment.

Fibre adds a blob encoding, validator shard assignment, a validator gRPC service, validator endpoint registration, and an x/fibre escrow and settlement module. These components allow clients to upload erasure-coded blob shards to validators, collect validator signatures, settle payment on-chain, and allow readers to reconstruct the blob from validator-served shards.

Motivation

Celestia’s normal blob path stores payload data directly in the original data square. Fibre provides a complementary path for higher-throughput blob publication by committing to blob data on-chain while distributing the payload through validator-operated services.

This reduces pressure on the block data path for large blobs while preserving an on-chain commitment, fee settlement path, and deterministic verification rules for clients and validators.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Fibre MUST be implemented according to the versioned Fibre specifications in the reference implementation:

• https://github.com/celestiaorg/celestia-app/blob/main/specs/src/fibre_encoding.md
• https://github.com/celestiaorg/celestia-app/blob/main/specs/src/fibre_module.md
• https://github.com/celestiaorg/celestia-app/blob/main/specs/src/fibre_client.md
• https://github.com/celestiaorg/celestia-app/blob/main/specs/src/fibre_server.md
• https://github.com/celestiaorg/celestia-app/blob/main/specs/src/fibre_registry_module.md

At a high level, Fibre introduces:

1. A Fibre blob encoding and commitment scheme.
2. Deterministic assignment of encoded blob shards to validators.
3. A validator-operated Fibre gRPC service for shard upload and download.
4. Validator-endorsed TLS identity for Fibre gRPC connections.
5. The x/fibre module for escrow accounts, delayed withdrawals, payment-promise settlement, timeout settlement, replay protection, parameters, messages, and queries.
6. The x/valaddr module path for validator Fibre provider host registration.
7. Data-square construction rules for accepted standalone MsgPayForFibre transactions and synthesized Fibre system blobs.

Fibre payload bytes MUST NOT be stored in the original data square through the normal blob payload path. An accepted Fibre publication MUST be represented on-chain by a standalone MsgPayForFibre transaction and a synthesized system blob containing the Fibre blob version and commitment.

Fibre is state-breaking and MUST be activated as part of a coordinated network upgrade. The upgrade MUST enable the x/fibre module, the validator provider registry, Fibre data-square construction, and Fibre-compatible binaries.

Parameters

The following x/fibre parameters are introduced:

The following hardcoded Fibre constants are introduced:

Rationale

Fibre keeps a compact on-chain record while moving blob payload transfer to validator-operated services. This allows Celestia to support a higher-throughput publication path without requiring every Fibre payload byte to be included in the normal block data square.

Escrow-backed payment promises let validators verify payment before storing shards. Validator signatures confirm that assigned shards were accepted by validators, while timeout settlement prevents an escrow owner from avoiding payment indefinitely after creating a valid promise.

Routing Fibre payments to the fee collector mirrors regular data-availability fee distribution and avoids making settlement depend on the exact validators that signed a payment promise.

Backwards Compatibility

This change is not backwards compatible. Consensus nodes must upgrade to Fibre-compatible software before the activation height. Older nodes will not understand the new modules, messages, and Fibre data-square construction rules.

Existing normal blob submission remains supported. Fibre introduces an additional publication path rather than replacing MsgPayForBlobs.

Clients and indexers that parse data-square contents SHOULD be updated to recognize Fibre PayForFibre transactions and synthesized Fibre system blobs.

Test Cases

The reference implementation includes tests for Fibre encoding, shard assignment, upload and download verification, escrow settlement, timeout settlement, validator host registration, data-square construction, and validator-endorsed TLS.

Reference Implementation

The reference implementation is the Fibre implementation in celestia-app:

• https://github.com/celestiaorg/celestia-app/tree/main/fibre
• https://github.com/celestiaorg/celestia-app/tree/main/x/fibre
• https://github.com/celestiaorg/celestia-app/tree/main/x/valaddr
• https://github.com/celestiaorg/celestia-app/tree/main/proto/celestia/fibre/v1

Security Considerations

Fibre availability depends on enough validator-operated Fibre servers storing and serving assigned shards until the payment-promise expiration time. If too many assigned validators are unavailable, pruning early, misconfigured, or unreachable, readers may fail to reconstruct the blob even though the on-chain commitment exists.

Validators MUST verify payment promises and shard assignments before signing. A validator signature means the validator accepted and stored its assigned shard. Signing without storing weakens Fibre availability.

The Fibre commitment binds bytes, not application meaning. Applications that consume Fibre blobs remain responsible for checking namespace, signer, and application-level validity.

Fibre gRPC endpoints are exposed validator services. Servers MUST enforce message-size limits, proof verification, assignment checks, and validator-endorsed TLS identity verification. Clients MUST authenticate the server as the intended validator before uploading shards or accepting downloaded shards.

Copyright

Copyright and related rights waived via CC0.