Introducing the Ginger upgrade: faster finality, higher throughput

John Adler, Josh Stein

Oct 24, 2024 • 3 min read

The Lemongrass upgrade, deployed to Mainnet Beta in September, was Celestia’s first consensus upgrade. The upcoming Ginger upgrade, i.e. celestia-app v3, is the second.

Ginger brings The Doubling, an immediate 2x increase to Celestia’s data availability throughput! In v3, this is achieved by decreasing block times from 12 seconds to 6 seconds, which also improves UX with faster transaction single-slot finality times.

Ginger also sets the stage for community governance to increase the block size up to a maximum of 8MB per 6 seconds, equating to 1.33 MB/s.

Ginger activates at Arabica height 2348907 (expected 5 November, 2024). It is expected to reach Mocha testnet in November and Mainnet Beta in December.

Changes coming to Celestia

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

The CIPs in Ginger include:

CIP-21: Introduce blob type with verified signer
CIP-24: Versioned gas scheduler variables
CIP-26: Versioned timeouts
CIP-27: Block limits for number of PFBs and non-PFBs
CIP-28: Transaction size limit

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

BBR by default

Real-life p2p networks have to send large amounts of data over very long distances. This becomes problematic as the most common congestion control algorithms dramatically reduce the number of packets sent as more losses occur—in other words, reduce throughput. The longer the data has to travel, the more packets that are lost, and the bandwidth utilization plummets. Worse yet, buffers start to build up, causing massive delays even for small packets. Even worse yet, in a decentralized network, peers won't wait for messages in a buffer; they'll simply move on to the next block, causing these buffered messages to become stale and waste even more bandwidth as they're eventually sent.

As found by researchers at Google, packet loss isn’t actually a good mechanism to detect congestion. Instead, we can simply use the round-trip time. This is what BBR does, and results in massive throughput increases for real-life geographically distributed networks.

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

Introduce blob type with verified signer

CIP-21 introduces “authored blobs” which include the signer’s address directly in the blob metadata. Celestia validators now verify that this signer matches the address that paid for the blob, eliminating the need for rollups to separately retrieve and process PayForBlobs transactions. This streamlines the verification process for rollups, allowing them to directly check the blob’s signer field to ensure authenticity.

Versioned gas scheduler variables

CIP-24 sets gas scheduler variables, GasPerBlobByte and TxSizeCostPerByte, to be modifiable only through a network upgrade, removing the ability to change them via onchain governance. This change aims to make transaction costs more stable and predictable. It allows for simpler offline gas calculation methods without needing to query the network before each transaction.

Versioned timeouts

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

Block limits for number of PFBs and non-PFBs

CIP-27 introduces limits on the number of PayForBlobs (PFBs) and non-PFB messages per block. The proposal implements a limit of 600 PFB messages per block and 200 non-PFB messages per block. These limits are soft limits in the PrepareProposal stage, meaning they’re not strictly enforced at the consensus level. The rationale of this change is to prevent long block processing times by bounding the number of transactions that can be verified in each block. The limits were determined based on benchmarks targeting a processing time of about 0.25 seconds per block on the recommended validator configuration.

Transaction size limit

CIP-28 sets limits on the size of individual transactions 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 thus a consensus-breaking change. The rationale is to prevent issues with gossiping large transactions, even with 8 MiB blocks and larger. It also leaves the door open for decreasing the block time and increasing the block size, to increase throughput, in the future.

See the Ginger network upgrade docs for more details on timing and how to update your Celestia consensus node to run the Ginger upgrade.