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.