Transactionless Relay-chain

[gavofyork]

This would devolve the relay-chain to become a transaction-less chain, placing all public-interaction on special system-level parachains.

This has several advantages:

• No (traditional user-level) transactions on the relay-chain means much more additional bandwidth to allow important collator/fisherman/validator extrinsics through.
• No transactions means that there wouldn't be contention between important relay-chain logic like message-routing and bread-and-butter stuff like voting/cote-vounting/staking/Phragmen/transfers.
• We get slightly more security peace of mind with functional isolation.
• We get to show off having the first blockchain that doesn't have transactions(!)

To implement this cumulus would definitely be required. In addition, we would need:

• Downward messages for the Relay-chain to send messages (or replies) to parachains and have them recognise the message as originating from the Relay-chain.
• Permissioning of parachains to allow for a properly privileged parachain to dispatch a message from the Root origin.

This will pave the way to offloading governance, staking, sessions and maybe even balances on to one or more parachains. There are three possible routes to doing this:

• Retain balances on the Relay-chain as it is and move staking and governance onto a parachain. That parachain gets system-level permissions (to mutate storage, set code, mint & burn tokens and dictate the validator set). This is probably the easiest to achieve.
• Move balances, staking and governance onto a single parachain; any balance transfer would (initially, at least) happen on this chain. The Relay-chain would retain a cut-down balances module that tracked parachain balances not general account balances. This also shouldn't be too difficult to engineer.
• Move balances, staking and governance onto three separate parachains. This would give the biggest improvement but require somewhat sophisticated two-way asynchronous messaging between parachains in order to coordinate the locking of balances, which both staking and governance depend on to work. Possible but probably best left until after the one or both of the other two have been implemented.

If we don't launch with this logic in parachains already then we might also want to have modules storage placed in their own child-trie by default in order to help eventual migration (both for deleting a large range of trie entries and allowing an efficient and secure import of the storage items into a fresh parachain).

CC @bkchr @rphmeier @cheme

[rphmeier]

The hardest aspect is staking/slashing. Given that parachain reversion can occur, moving staking and individual balances entirely onto a parachain will make it hard to do reversion without reverting slashing. This indicates to me that the relay chain will almost certainly have to manage balances of individuals, and whatever chain handles staking would be dealing in relay-chain DOTs. Still, reversion poses a challenge as it will cause the accounting to go out-of-sync.

[burdges]

We've discussed this not so seriously occasionally. I though governance alone might be easiest but noticed these points:

We do not engage in governance all the time, so a governance parachain slot is largely wasted unless the system is optimized for idle parachains. For this, we'd shift almost all parachain validator assignments from assigned validators to secondary checks, so like 1 or 2 validators assigned to each parachains and 5-20 secondary checks, or maybe some scheme with all secondary checks but one who announces early.

We might want a governance parachain to run governance not just for the relay chain but for most other parachains, and to run parachain slot auctions, which sounds more complex. After launch, we could perhaps transition from relay chain governance to a governance parachain by introducing the governance parachain first to govern other parachains, and then add on the relay chain.

[burdges]

I suppose the relay chain would handle parachain blocks, along with incoming and outgoing messages. Also, slashing would start with relay chain and eventually become a message to the staking chain.

If we ignoring slashing related transactions, then we can tolerate almost arbitrary variance in block production time:

X has produced a block for their upcoming slot time i. Y produces a block at slot time j<i. Assume i-j is small. Let P denote a parachain candidate in X's block.

If Y included a candidate for P, then P cannot have time to build on Y's block, so X cannot be missing anything they might include for P, so X merely removes their candidate for P.

If Y included a message for P, but not a block, then the candidate for P that X picked still builds on some previous relay chain block, and may thus be included by X when building on Y's block.

In both cases, X could quickly convert their block into building upon Y's block by merely removing things, so an unusually short block update time i-j causes no problems for X.

We also avoid excessively long block times by producing the extra low-priority "aura" blocks, like in aurababe, but now with a delay of many babe slots.

[rphmeier]

In both cases, X could quickly convert their block into building upon Y's block by merely removing things, so an unusually short block update time i-j causes no problems for X.

The state-trie root update would be different, so the calculation would need to be redone. That's one of the heavier parts of block production

[burdges]

Ahh, I'd naively imagined parachain candidates could only be addressed UTX0 style, but.. Yes, at least message (count) must be stored in some state-trie, only a rather shallow trie, but still..

[rphmeier]

incomplete, but still super stale (system parachains are a larger overarching concern. can reopen)

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/multichain-friendly-account-abstraction/1298/1

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/the-future-of-polkadot-staking/1848/1