Data availability commitment upgrades via soft forks

On the current roadmap, we plan to launch with the rsmt2d scheme for mainnet. In the future however, we may want to add support for new data availability schemes (such as ones that don’t require fraud proofs). We should consider how to do this, without breaking backwards compatibility with existing light clients.

One way to do this would be via a soft fork that adds a new data availability commitment type to the block header, alongside the existing rsmt2d data root. Once the soft fork is activated, consensus nodes only include blocks where both data commitments have availability.

The caveat is that data availability sampling light clients (e.g. for trustless bridges) that haven’t been upgraded could fork from the network, if the validators finalise a block where the rsmt2d root is available, but the new data commitment isn’t. However, this wouldn’t break the data availability guarantees of the rsmt2d root, assuming that there are sufficient light clients in the forked chain.

Another caveat is that if we wanted to upgrade to a data availability scheme that doesn’t require data availability fraud proofs, but still keep the rsmt2d root, then light clients will still need to wait for fraud proofs for the rsmt2d root. This could be resolved eventually by encouraging everyone to upgrade their light clients by limiting the maximum block size for rsmt2d roots, such that it’s small enough that light clients can download the whole data without waiting for fraud proofs.


Some further analysis on the implications of having two data roots, but some clients don’t verify one of the data roots.

Recall that Tendermint BFT halts if there’s a fork, so it’s fork-free. So in the case where one type of data root becomes invalid but the other remains valid, clients that only follow the valid root will still have a ‘canonical’ chain even though other clients may have halted. Data availability guarantees should still therefore be intact. When social consensus reboots the chain, they ought to keep the valid roots in the canonical but invalid chain.

This is also true if the light client doesn’t take an interest in the validity of state transitions of the Celestia proof of stake main chain via fraud or ZK proofs, which may not be possible anyway if they’re not following the correct data root where main chain transactions are posted.