What surprises can Celestia's Ginger upgrade bring?

Source: Celestia; Compiled by: Deng Tong, Golden Finance

The Lemongrass upgrade was deployed to the mainnet beta in September and was Celestia's first consensus upgrade. The upcoming Ginger upgrade, Celestia-App V3, is the second.

Ginger doubles efficiency, and Celestia's data availability throughput has increased by 2 times immediately!In v3, this is achieved by reducing the block time from 12 seconds to 6 seconds, which also improves the user experience through faster transaction single-slot finalization time.

Ginger also lays the foundation for community governance, increasing the block size to a maximum of 8MB every 6 seconds, equivalent to 1.33 MB/s.

Ginger activated at Arabica block 2348907 (expected November 5, 2024). It is expected to enter the Mocha testnet in November and the mainnet beta in December.

Celestia is about to change

The CIPs included in the Ginger upgrade are specified in CIP-25, a meta-CIP.

CIPs in Ginger include:

• CIP-21: Introducing blob type with verified signers

• CIP-24: Versioned Gas Scheduler Variables

• CIP-26: Versioned Timeouts

• CIP-27: Block limits on number of PFBs and non-PFBs

• CIP-28: Transaction size limits

In addition to the above CIPs, celestia-app v3 includes an important non-consensus change: requiring BBR by default.

Default to black box recorder

Real-life p2p networks have to send large amounts of data over long distances. This becomes a problem because the most common congestion control algorithms significantly reduce the number of packets sent as more losses occur—in other words, reduce throughput. The longer data takes to transmit, the more packets are lost, and bandwidth utilization plummets. Worse, buffers start to accumulate, causing massive delays even for small packets. Worse, in a decentralized network, nodes don't wait for messages in their buffers; they just move on to the next block, causing those buffered messages to become stale and wasting even more bandwidth when they are finally sent.

Researchers at Google discovered that packet loss isn't actually a good mechanism for detecting congestion. Instead, we can simply use round-trip time. That's what BBR does, and has led to massive increases in throughput on real-life, geographically distributed networks.

This opens the door to future throughput and performance improvements, such as those demonstrated in the Mammoth Mini testnet. celestia-app v3 requires BBR to be turned on by default.

Introducing blob types with verified signers

CIP-21 introduces “authored blobs” where the signer’s address is included directly in the blob metadata. Celestia validators now verify that this signer matches the address of the payment blob, eliminating the need for aggregates to retrieve and process the PayForBlobs transaction separately. This simplifies the verification process for aggregates, allowing them to directly check the blob’s signer field to ensure authenticity.

Versioned Gas Scheduler Variables

CIP-24 sets the Gas Scheduler variables GasPerBlobByte and TxSizeCostPerByte to be modifiable only through network upgrades, removing the ability to change them through on-chain governance. This change is intended to make transaction costs more stable and predictable. It allows for a simpler off-chain Gas calculation method without the need to query the network before each transaction.

Versioned Timeout Settings

CIP-26 sets block times and related timeouts to be controlled by the application version and reduces block times from 12 seconds in v3 to 6 seconds. This change is intended to increase network throughput and reduce transaction finalization time. It also increases the ttl-num-blocks parameter of the mempool from 5 to 12 to maintain consistent transaction behavior with faster block times.

Block Limits on Number of PFB and Non-PFB

CIP-27 imposes limits on the number of PayForBlob (PFB) and non-PFB messages per block. The proposal implements limits of 600 PFB messages per block and 200 non-PFB messages per block. These limits are soft limits in the PrepareProposal phase, meaning they are not strictly enforced at the consensus level. The rationale for this change is to prevent long block processing times by limiting the number of transactions that can be validated in each block. These limits were determined based on benchmarks, with a goal of approximately 0.25 seconds per block processing time under the recommended validator configuration.

Transaction Size Limits

CIP-28 limits the size of a single transaction to 2MiB (2,097,152 bytes) on Celestia. This limit will be enforced at all stages of transaction processing (CheckTx, PrepareProposal, and ProcessProposal), and is therefore a consensus-breaking change. The rationale is to prevent issues with gossip about large transactions, even for blocks of 8 MiB or larger. It also leaves the door open to reducing block times and increasing block sizes to increase throughput in the future.