| cip | 38 |
|---|---|
| title | Increase maximum block, square and transaction size |
| description | Increases the maximum block size to 128MB, square size to 512, and transaction size to 8MB, enabled by a new high-throughput recovery mechanism |
| author | Evan Forbes @evan-forbes, Callum Waters @cmwaters |
| discussions-to | https://github.com/celestiaorg/celestia-app/pull/4285 |
| status | Final |
| type | Standards Track |
| category | Core |
| created | 2025-06-23 |
Abstract
This CIP proposes a novel blob propagation mechanism that uses pull-based broadcast trees and erasure coded block parts to efficiently distribute block data across consensus nodes. In conjunction, these changes allow the network to safely increase the maximum block size to 128MB, the maximum original data square size to 512 and the maximum transaction size to 8MB.
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.
The complete specification for the high-throughput block recovery mechanism is being reviewed at: https://github.com/celestiaorg/celestia-app/blob/353f21116b2edb2b22df454df907567b50558b07/specs/src/recovery.md
Implementations MUST follow the specification as defined in the referenced document.
Parameters
The following parameter changes are proposed for the Celestia network:
| Parameter | Current value | Proposed value | Description | Changeable via Governance |
|---|---|---|---|---|
MaxBlockSizeBytes | 100 MiB | 128 MiB | Hardcoded value in CometBFT for the protobuf encoded block. | No |
SquareSizeUpperBound | 128 | 512 | Hardcoded maximum square size which limits the number of shares per row or column for the original data square | No |
MaxTxSize | 2 MiB | 8 MiB | Maximum size of a transaction in bytes. | No |
Rationale
Celestia currently relies on full replication of block data across all validators before voting. The protocol described in the spec does this.
Backwards Compatibility
This requires a major upgrade as these are network wide parameters. Nodes who upgrade will run both the old propagation and new propagation reactors. Upon the upgrade height, nodes will shutdown the old propogation reactor and communication will solely be across the new propagation reactor. If the need to fallback arises, nodes can coordinate amongst them to switch back to the old propagation reactor.
Security Considerations
The referenced specification includes comprehensive security considerations for defending against sybil attacks and denial-of-service attacks, even when combining pull based logic with broadcast tree logic.
The implementation has been audited and the results can be found in the celestia-app repository.
Copyright
Copyright and related rights waived via CC0.