Altering Polkadot's fork-choice to reduce DA Load

Let’s not argue about the tech merits of different kinds of rollups here (I would propose to move it out to another thread since it’s rather complex topic), and let’s assume that they are good competition just for the sake of this conversation.

We can provide a platform for rollups to be deployed on Polkadot (and that’s in fact how this topic first popped up). However you spin it, the data availability requirements for parachains will be always higher than rollups:

  • Parachains need the block and the witness (storage proofs) required to execute it to be placed in DA.
  • ZKRs need to place batches, equivalent of block bodies, into DA and proofs. Assuming one proof per batch, it would make up at most several hundred of KiB.
  • ORUs, need to place only batches. We can assume fraud proofs ≈never happen.

Once again, if we assume future constructions solve their problems (proving costs and composibility issues), that would diminish the value prop of parachains compared to them.

That’s why I think the fact that cumulus utilizing the DA space more efficently is irrelevant. The other optimizations mentioned here are important but tangential, cause those would be still useable by rollups and can still stack up on the Rob’s proposal. However, unlike those solutions, the proposed solution won’t be useful by rollups, cause those would need to go through the strict DA process, at least in the model we had in mid (I might write up more about the rollups on polkadot when time comes).

Polkadot’s DA is already far ahead of Danksharding/Celestia and the like in terms of available bandwidth.

This is an interesting claim @andronik. Broke out into the following thread:

1 Like