Parathreads

The main idea of having parathread slot is to enable temporary participation in Polkadot.

A number of collators run a parathread. Parathreads register their code by locking DOTs as a deposit. If there is an upper limit to how many parathreads that are allowed, then it's first come first serve. The deposit is only for the effort of registering their code, while maintaining costs happen on a per-block basis through the parathread fee.

Lets assume there will be a number of parathreads, the current protocol for adding a parathread block into the relay chain is as follows.

Parathread Protocol:

For a given block \(b\) of the relay chain:

• A collator from a a parathread may submit a bid to the relay chain that includes the hash of a parathread block candidate and an associated fee in DOT.
• From the pool of bids (where some still valid for block \(b\)) the top \(x\) highest bids are selected and assigned designated to parathread slots.
• The collator needs to figure out if he has won.
• The collator needs to connect to corresponding parathread validator and submit PoV. This can be done via bootstraping nodes.
• Parathread validators validates PoV and publishes summary.
• VRF assigns the relay chain block author for block \(b\).
• block author picks the summary and adds it to the relay chain block \(b\).
• The parathread validators need to broadcast the inclusion to all the collators of that parathread that the parathread block has been added (the question here is whether this is going to be easy enough to be done in time in terms of networking?).

Economics:

Similar to the transaction fee for inclusion in block, for parathreads a new block candidate is added to the relay chain in return for a fee in DOTs. The users of the parathread will add a tx fee denominated either in the local parathread currency or in DOT. The collator takes some part of that and forwards the rest to the relay chain block author. The relay chain block author gets 20 % of the parathread block inclusion fee and 80 % of the fee will go to the treasury.

Alice adds her tx and a fee of 6 tokens (lets assume in DOTs). She sends this to a parathread collator, which takes 1 DOT and collates the transaction with others into a block candidate and submits it to the relay chain with a fee of 5 DOTs as a bid. If the bid wins, the corresponding relay chain block authors get 1 DOT and 4 DOTs go to the treasury.

New suggestions

Adding a Grace Period

A problem we have is that many of the bids might now be invalid until the collator finds out and is able to submit its PoV on time to the parathread validator to be added to block \(b\).
To solve this issue, we can add a grace period. The bid would be valid for block \(b+5\) next blocks. This way the collator has some breathing period to find out he has won, connect to corresponding parathread validators, and submit his block.

Alternative Way of Implementing Parathreads:

An alternative way to carry the procedure out would be to make the bidding process go through the parathread validator instead.

• the parathread validator would agree on the pool of bids (removing duplicate bids that multiple parathread validators might have received) and their assigment to them. The parathread validators should agree on assigments that they can handle in case they win the auction.
• an auction on the realy chain picks the top x bids.
• Then the parathread validator immidiately find out which bid have won and can continue to validate the winning PoVs and add the summaries. They get rewarded a portion of the tx fee.