paritytech
Block Wrapping to avoid dependence on relay parent and enable fast parachain "finality"
Polkadot currently limits the maximum age of a relay parent, which presents an issue if we try to build any kind of "finality" into parachains: a parachain block can be created, and then not included into Polkadot for some reason, and then it is literally impossible to include a block with that ancient relay parent. To be clear, this "finality" would typically operate at a much lower level of security, but it would be nice for users to have some guarantee that low-value transactions are likely to go in a particular order, and get that assurance quickly, without waiting for the relay chain to include and finalize the parachain block.
i.e. the low-economic-security guarantee we would like to get is about the ordering of transactions that will eventually go into the parachain, up to the level of economic security that the parachain can itself provide.
Let's discuss some kind of block "wrapping" from the Cumulus perspective, where we have an inner block or bundle of transactions that is not dependent on a particular relay parent, and this block can be "wrapped" into collations that do depend on a recent relay parent and manage the message queues accordingly. In the case that collation doesn't make it into the relay chain, it could simply be re-wrapped and submitted again.
If not wrapping, then I think that ordering of transactions should be enough. The poor man's version (that could be built today) is that nodes would run a background task that acquires consensus on transaction bundles, and then only justified transaction bundles can be posted to the parachain runtime.
The poor man's version (that could be built today) is that nodes would run a background task that acquires consensus on transaction bundles, and then only justified transaction bundles can be posted to the parachain runtime.
Not sure this is a poor man's solution as it already sounds quite involved :P
I think in general that could be done on the Substrate, as any kind of chain could use this mechanism to give some sort of "pre-finality". Sounds like a good solution for when you want really fast feedback on your transaction.
