Closed gavofyork closed 1 year ago
We'll need upward messages for full parachains who adjust their core usage but..
Afaik there is no reason to use upward messages in the scheduling system for on-demand parachains. A payment on the relay chain can increase the balance, and enqueue a message for the parachain, then whenever the parachain makes a block it can pull from this balance and do whatever it does with the message.
We're planning to remove as much functionality as possible from the Relay-chain, including currency. This isn't much of a problem; non-transferable DOT "vouchers" can still be hosted on the Relay-chain and payment can happen in them instead, so it's pretty much the same thing.
blake2_256 hash of the 33d45a8 text is 9cbabfa80598d2935830c09c18e0a0e4ed8227b8c8f744f1f4a41d8597bb6d44
.
blake2_256 hash of System.remark("APPROVE_RFC(0005,9cbabfa80598d2935830c09c18e0a0e4ed8227b8c8f744f1f4a41d8597bb6d44)")
is 0x7ef1a62ce4f40336fdc43fd41214bff389e79ca21b6c15982d7ec6344a4500c8
; preimage length is 86 bytes.
In the Agile Coretime model of the Polkadot Ubiquitous Computer, as proposed in RFC-1 and RFC-3, it is necessary for the allocating parachain (envisioned to be one or more pallets on a specialised Brokerage System Chain) to communicate the core assignments to the Relay-chain, which is responsible for ensuring those assignments are properly enacted.
This is a proposal for the interface which will exist around the Relay-chain in order to communicate this information and instructions.