Who would pay for it? The teams?
Yes. Teams looking to benefit from these airdrops would pay the super low costs for blockspace that Polkadot offers.
It could also be designed that users pay the costs for blockspace through transaction fees included in the blocks, if the chain becomes popular enough.
I think chain forks look important too, especially for validator ellections.
A chain fork would copy the entire state of one or more parachains, like say AssetHub, onto new collators or new processes on the same collators, and launch a new parachain with that state root in a subtree. After which, they launch the parachain using modified code, which say runs the validator ellection, and then the final block and/or state gets used elsewhere.
Airdrops could use a chain fork if they really wanted everyone. A priori, air drops should use off-chain messages, so a chain fork saves the complexity of user code doing cross chain proofs, but thatâs likely minor. A chain fork would not save âworse caseâ computation over off-chain messages, since the âworse caseâ merkle proofs work out similarly.
Instead, chain forks would more likely fit heavy computations, or multi-party computations like maybe resharing DKGs, although not sure even there.
As an aside, you can simulate JAMâs accumulate function on existing pokadot using chain forks btw, by having an asynchronous accumulate function in the original parachain, which merges the computation from the forked parachain back into the main parachain. âAsynchronous accumulationâ like this winds up like 30 x cheaper than JAMâs accumulate, does not impose the restrictive runtimes, and supports multiple relay chains better. Anything âasynchronousâ like this winds up being harder to program for though. In particular, you need some locking mechanism for âmust mergeâ computations, just like off-chain messaging requires more work to be âmust deliverâ. JAMâs synchronous accumulate would inherently be âmust mergeâ, just like on-chain XCM are inherently âmust delieverâ.
How do you will know, from the original parachain view, that the forked parachain is unique and in a valid state to be merged back? Will it be a continuous process committing state roots in some kind of accumulator (MMR, double-batched merkle,âŚ) from the fork to the mainline, without witness and function to validate the witness and transition of state or how?
Itâs being validated by polkadot, using some runtime you control, so itâs ready whenever it says so, and gets included in teh relay chain.
Got it! 