bkchr
commented
9 months ago In order to avoid having hot keys on the collator, we will with RFC-1 implemented have credits on the relay chain which can only be used for ordering a core. Until then we added an additional proxy kind, which restricts the proxy account to only placing orders. We intend to harden this further, so restricting the proxy to even just ordering cores for a particular on-demand para will be possible.
We should go directly for core time. The pallet is ready and the parachain also almost. So, only the relay chain side is missing.
All we need is to force collators to produce blocks that will refund and reward the nodes placing the order.
If you need to force collators, the protocol is broken. Collators should be incentivized by something to build these blocks, otherwise they will just do nothing.
So how do we do that? We can prove that an order was placed in a block, but we can not prove that it did not happen. Thus block producers can chose to omit any such proof.
Can we not just record alongside the latest head of the para in the relay chain who paid for this core time? Could be some vector for when there was multiple core time purchases to make one state transition happening.
eskimor
Polkadot-Forum
Daanvdplas
evilrobot-01
On-demand functionality present on the relay chain, which means technically on-demand is implemented.
This works, but leaves room for desire on (1). Who is going to place an order when? For very early on this might just be a developer with a laptop, trying things out, but at some point people will need this automated and decentralized.
Automation
Collators should be able to monitor some condition over time, e.g.:
and then when that condition becomes true, should automatically place an order.
In order to avoid having hot keys on the collator, we will with RFC-1 implemented have credits on the relay chain which can only be used for ordering a core. Until then we added an additional proxy kind, which restricts the proxy account to only placing orders. We intend to harden this further, so restricting the proxy to even just ordering cores for a particular on-demand para will be possible.
EDIT: Before proxy hardening, we should likely go for RFC-1 credits directly.
Now with security considerations out of the way, we need to:
Block Production Conditions
This is mostly about exposing some state that is relevant to the on-demand order placing logic. For actual decentralization, it will also be important that we have a condition that can also be verified/proven to be true in the para runtime.
Coordination
All collators will see any block production condition come true at approximately the same time, yet only one of them should be placing an order. To coordinate this, we introduce a mechanism similarly to Aura:
Where
his the relay chain block height andwis the slot width. 0 would mean an order slot is exactly one relay chain block, 1, would mean a slot is two relay chain blocks.The slot width has to be picked based on the expectation how long it will take for a placed order to actually show up in a block. (How long will it need to be gossiped, how long will it linger around in the mem pool?)
The idea is, we have an asynchronous network and we still need to avoid having two collators place an order. To avoid this we pick a sensible
wwhich should allow for orders to easily go into a block most of the time. The order placing collator will use transaction mortality to ensure that the order will either end up in a block still in its slot or is dropped.The lowest transaction mortality possible is 4. Therefore the collator will always pick the first relay chain block of its slot as the base, with mortality 4 - even if the block production condition became only true later. We need to ensure that the order is already invalid when it's the next collator's turn.
The next collator, if also seeing the block production condition to be true, will then check the last 4 relay chain blocks for an order, if it finds one, it does nothing. If it does not find one, it will place an order by itself.
Summary:
With this, it should not be possible on a single relay chain fork for collators to place redundant orders by accident.
The only caveat is, that we limit our block rate to maximum 1 block every 4 relay chain blocks, because we don't check for already produced blocks: If the block production condition is true, but we have seen an order within the last 4 relay chain blocks, it might still had been served already and the condition is just still true or already true again. This should be easily fixable by adjusting above algorithm to also check whether an order has been served already. I would consider this low priority as at least in the beginning, on-demand is meant for chains that don't have high throughput requirements. Later when we might want to use on-demand for boost, this might become more important. Therefore do it, if it is easy enough, but certainly don't block a release on this. Also for boost/elastic scaling, the parachain is producing blocks already on a bulk core, which means it can place on-demand orders for elastic scaling by itself and non of this here is needed.
Decentralization
With the above we have achieved automation. Collators now know who should place an order when. But placing an order incurs costs. Why would collators bother placing orders, assuming we have decentralization? (They are not intrinsically motivated somehow.) The answer is, they would not. The collators would need to have orders placed in order to produce blocks, which gets them rewards, but they would also gain those rewards if someone else placed the order and they just produce a block when it is their Aura slot for example. Initial ideas for solving this dilemma aimed at strategies for ensuring that the one placing an order will also always be the block producer - so there is an incentive in placing the order, because you will the block producer and will gain rewards/refunds from the parachain logic. Those initial designs can be found here. The problem with those is, that they couple consensus very tightly on the on-demand feature, which is a pity by itself, because we wanted to make on-demand as transparent as possible, but it would especially be annoying to do the switch from an on-demand parachain to a reserved chain and back: You would need to swap out consensus!
We can fortunately think of order placement completely (almost) separate from actual block production. We only need to find a way for order placement to be incentivized. We need to have someone do it - it does not matter who. All we need, is to make sure collators produce blocks that will refund and reward the nodes placing the order.
So how do we do that? We can prove that an order was placed in a block, but we can not prove that it did not happen. Thus block producers can chose to omit any such proof. A related problem: How do we check that an order placing machine did not just ignore a previous order which would make it illegal for it to place an order as well (see section Automation above): What if nobody provides the proof of that earlier order?
To mitigate proof omission, we don't pay out refunds and rewards immediately, but will wait for each payout until at least f+1 collators produced a block since the payout in question (and had a chance of including the proof). We call this the challenging period.
We need two kinds of proofs that should be accepted at the ordered block, but also at any later block within the challenging period:
By adding sequence numbers to the orders (parachain advances it whenever an order proof was processed), we can make (2) a self contained proof that does not require the parachain to keep a lot of state.
Point (2) needs more explanation: We do want it to be possible for the next collator/order placing node to cover for the previous node failing to place an order, but it should only be able to be refunded if the previous node indeed failed to place an order.
Sequence numbers also help in making block producers honest: If they don't include the proof, their own next order would not be accepted, except if they picked the same sequence number, but if they did that they risk getting challenged and would lose their reward/refund.
Orders will only be refunded, if a block was produced for that order (ensured via sequence numbers). This is necessary, because otherwise collators could just order cores, without the block production rule being met. The block producer is incentivized to produce a block. On top of that we do have small order placement rewards, which should cover the risk of the block producer not producing and thus making us lose out on our refund.
WIP Implementation steps:
Node:
Runtime:
Runtime API
Call for collators, telling them whether an order should be placed/will be refunded - Option.
Nonein case the parachain gained a reserved slot.Proofs:
Order proof:
Merkle proof that order is in block + proof that the including block is a parent of some recent relay parent. (Full header chain)
Fraud proof:
Merkle proof of our order in a block, merkle proof of offending order in a block. Full header chain between those two and up to some recent relay parent.
Size considerations: By keeping in state not only the current relay parent, but also the relay parents of some
nolder blocks, required header chains should be relatively small, more sophisticated data structures are likely not needed, but worth a consideration.