Parathreads: Pay-as-you-go Parachains
By: Joe Petrowski
Parathreads open up the parachain paradigm, lowering the barrier to gaining the benefits of shared security and connectivity. Polkadot is now even more accessible to projects that may not have the capital to secure a dedicated parachain slot and gives the opportunity to become a parachain if their application requires high throughput. Although parachains can borrow DOTs from users via a crowd-loan, they may not have the community to start. Using parathreads, any development team can get access to the relay chain and bootstrap their application.
Dedicated parachain slots offer high throughput, but require a large bond for up to two years. Why is this required? Shared security is not free security, and parachains make this bond for the security and access to the throughput of Polkadot. Parathreads have the exact same API and functionality as parachains, but on a “pay as you go” basis.
If you think about Polkadot as a giant computer, parachains are like applications that are in physical memory and highly available. Parathreads are like applications that are on disk and can be copied into memory when needed. For those already familiar with how Bitcoin and Ethereum work, users bid to enter a parathread block into the relay chain similar to how users bid to include a transaction in a Bitcoin or Ethereum block.
Parathreads are ideal for three types of applications:
- applications seeking an on-ramp to Polkadot,
- applications worried about losing parachain slots, and
- applications that have more reads than writes.
In our development of Polkadot, some teams have expressed concern about the bond required to secure a dedicated parachain slot. Nascent projects may not have the capital to set aside upwards of 20,000 DOTs for two years. Parathreads require a minimal bond (50-100 DOTs) and allow chains to submit a block to the relay chain whenever they have a full batch of transactions, while reaping the full security and connectivity benefits. If the application gains heavy adoption, it can raise the requisite DOTs and upgrade to a full parachain by swapping with an existing parachain.
Another concern with chain interoperability is dependency management. It’s great to have specialized chains to compose your application with, but what happens if one of the chains you use loses its parachain slot? Now, that chain can simply downgrade to a parathread and remain available. This lifecycle will allay fears of losing access to Polkadot.
For some applications, being a parathread simply makes more sense than being a parachain. Namely, these are applications that do not have frequent state updates. Take a domain name service, for example. Read requests come in large numbers, but it would be normal to update the registry on an hourly basis. DNS has no need of Polkadot’s six-second block time. Oracles also make sense as parathreads, say a daily weather or Bitcoin block oracle.
Polkadot will reserve some parachain slots for a pool of parathreads. Any number of parathreads can exist in the pool, but only a limited number can execute in each block.
In each relay chain block, parathreads will signal their desire to execute a block by participating in an auction. Parathread collators will tell the validators assigned to the pool how many DOTs they are willing to pay in order to have their block executed and finalized. The pay-per-block model differs from parachains, who have the right to execute a block in every relay chain block by grace of their dedicated slot.
There are several ways that parathreads could fund block execution. For example, they could raise funds and have a DOT account for their chain and give collators use of this account in order to finalize a block when necessary. Alternatively, the parathread could have an inflation model that offers more native tokens to collators as the relay chain progresses. Once the value of the native tokens exceeds the value of the DOTs required to win the auction, the collator will accept the block reward.
Parathreads are a powerful addition to Polkadot. As they have the same interface as parachains, they are both secured under Polkadot’s shared security and can send and receive messages over XCMP.
Polkadot will be able to support about 100 parachains. Parathreads increases the number of applications that can operate on Polkadot by pooling them to share parachain slots. This will allow more infrastructure chains and improve composability.
One group of parachains will be system-level chains. One of our goals with Polkadot is to have a relay chain without transactions. Proofs of Validity are the only information that would go into relay chain blocks. This means there will be a parachain for DOT transfers, one for governance, one for staking, one for smart contracts, etc.
Another group of parachains will be applications that lease dedicated parachain slots. These will be heavy-use chains like a decentralized exchange or stablecoin chain. For these chains, it is more economical to post a bond to harness the full speed of the relay chain rather than pay per block.
The third group will be parathreads, the majority of applications that need the security and connectivity of Polkadot, but don’t need the full throughput.
Parathreads are a huge step in making Polkadot more accessible and optimizing the resources available on the relay chain. With such a great on-ramp to Polkadot, any team can start developing their application in preparation for Polkadot’s launch with confidence that they can connect to the relay chain and harness the benefits of interoperability.
Start building your parathread with Substrate.
To learn more about parathreads, see the Polkadot Wiki. https://wiki.polkadot.network/en/latest/polkadot/learn/parathreads/
From the blog
Elevating Polkadot's Performance and Scale with Asynchronous Backing
Asynchronous backing is the latest step in the roadmap towards natively scaling Polkadot’s performance and flexibility for Web3 use cases across every industry.