paritytech
Parathreads: Take II
Based on the original work done by @gavofyork in 2019: #341
Board: https://github.com/orgs/paritytech/projects/67
Background and Motivation
Polkadot currently only supports parachains, running leases of between 6-24 months. Kusama leases run from either 6 weeks to 48 weeks. If a chain has a slot and loses one, it simply stops running. If a project can't afford a slot due to limited supply or intense competition, it simply doesn't get off the ground.
Parathreads are pay-as-you-go parachains: they pay for security on a block-by-block basis as opposed to leasing an entire core for a prolonged period of time. Parathreads only differ from parachains in terms of how they are scheduled, collated, and backed. Availability, approval-checking, and disputes all function the exact same way.
Parathreads provide an on-ramp and off-ramp for projects, as well as the option for chains which produce blocks only occasionally. They provide another class of offering in the market for shared security which will lead to better pricing of security for longer leases as well.
The idea of parathreads is to allocate a number of parachain availability cores specifically to parathreads, and these parathread cores multiplex blocks from a backing queue of 'claims', which represent upcoming parathread blocks. The queue of claims is populated by an auction process which runs in every or almost every relay chain block, allowing collators to bid in the relay chain's native token in order to earn a claim. Claims are processed in order of submission, or close to it. Each claim is associated with the specific collator.
The parachain scheduler should attempt to schedule pending parathread claims onto available parathread cores. Once scheduled, parachain backers should connect to the specific collator mentioned in the claim and get the candidate and PoV from them.
Design Considerations
Spam-resistant Auctions: Bids from collators who don't win auctions should appear on-chain in some form so that useless bids still have some cost associated with them, meaning that spam isn't free.
Stacked Claims: It should be possible for multiple claims from a single parachain to be present, and for some kind of dependency relationship to be expressed between them. This will allow parathreads to have fast blocks during bursty periods if they so desire.
Data Unavailability: Polkadot only keeps data available for 24 hours. This means that it is possible that the data proving a prior block might be lost if the last block was produced more than 24 hours ago. In the past, we've discussed forcing parathreads to author blocks at least once every 24 hours. This probably isn't necessary - parathread clients should just make sure that they're fully syncing within 24 hours of the last block and gathering data from the data availability system if necessary.
Wasm Execution Risks: related to https://github.com/paritytech/polkadot/issues/1269 ; if there are underlying issues with PVF execution that we aren't aware of, it'll be far cheaper and easier to exploit them on parathreads than it is on parachains.
Asynchronous Backing: We should expect parathread blocks to be built 12-30s ahead of time and accordingly for validators to know that the parathread will or might be scheduled 12-30s ahead of time. The claim should probably not commit to the candidate hash, or if it does, claims will have to be retired across sessions.
Leniency and Censorship: When a claim is scheduled, it's possible that it's either not fulfilled because of the collator not producing a block or because the backers haven't managed to back the block in time. Claims should stay scheduled for a few relay chain blocks, and potentially should be scheduled onto cores where other backing groups are assigned.
Runtime
Claims queue: Manages all pending parathread claims.
Auction Mechanism: for pushing onto the claims queue
Runtime API: for informing validators of scheduled or soon-to-be-scheduled parathreads
Node-side
Collator networking: Connecting to the specific collator and/or accepting connections from specific collators Prospective parachains: detecting scheduled parathreads as well as parachains
Collator-side and Parachain Side
Auction Bidder: logic to control a hot wallet to participate in auctions under configurable conditions. We should expect some sidecar process to run alongside the node and take into account information that's not easily generalized: for example, users might create strategies incorporating the relay-chain token price, the parachain token price, unconfirmed transaction rewards, and the block reward mechanism of the parathread. Parathread Consensus: logic to detect when a block should be authored based on the state of the claims queue / scheduled cores
This issue has been mentioned on Polkadot Forum. There might be relevant details there:
https://forum.polkadot.network/t/parachain-scaling-by-parablock-splitting/341/5
