If you're coming to Polkadot from Ethereum – whether out of curiosity or necessity – you'll probably be wondering how it differs from Ethereum 2.0, and what they'll have in common. This series will help you learn about their differences and shared ground. Note that we assume basic knowledge of Ethereum 2.0.
Note – to learn more about Ethereum 2.0, please check out this series.
Parachains / Parathreads vs. Shards
Shards
Ethereum 2.0 was originally going to consist of 1024 shards and one beacon chain to coordinate them all via crosslinks – messages stored on the beacon chain that reference the latest state of each individual shard. Validators – of which there would be hundreds of thousands – are randomly shuffled into committees of 128 members who then produce blocks on the shard chains. Every time a block on a shard chain is produced, other validators attest to it (confirm it). That block's hash is then stored as a crosslink on the beacon chain, at which point other shards can become aware of it.
Cross shard communication depends on shards reading this information and learning that the shard they're interested in has experienced a change. To load that change, they need to query that shard (i.e. connect to the nodes validating that shard). Communication across shards is thus not atomic and can be slow, depending on how many hops the execution of a stack of transactions requires. Composability of smart contracts may or may not break, further possibly stabilized by yanking, but it's all in the air right now.
A discussion on reducing shard count by a factor of 16 exists, which would drop the number to a mere 64 and approach the numbers that Polkadot is initially aiming for with parachains. This would improve composability (higher chance of contracts being on the same shard) and reduce the required number of validators for optimal security (128 * 64 is 8192, versus 131k before), but this is still under heavy discussion and has other tradeoffs (notably – more bandwidth to run a validator, you'd need a stable 5Mbit+ connection).
Parachains
Polkadot's Relay Chain is similar in concept to the beacon chain in Ethereum 2.0. It provides shared security to all the shards, here called Parachains (parallel chains). Parachains are independent blockchains which produce their own blocks and those blocks are then candidates for inclusion on the relay chain, much like crosslinks in Eth2. The main difference in parachains and shards is that parachains will be free to implement local logic any way they see fit. They will be application specific, but will share the security of both the relay chain and all other parachains.
A chain optimized for DeFi use might exist, while another optimized for anonymous transactions might exist alongside it. Both will produce their blocks independently based on their own rules, but every X seconds where X is the target block time of the relay chain (depending on network performance – we're aiming for ~6 seconds) the hash of those blocks along with proofs that validators need to verify a state transition will be included into the relay chain.
In other words:
- Ethereum shards: identical (homogenous) chains with shared security, splitting the network's load by evenly distributing it
- Parachains: different (heterogenous) chains with shared security, splitting the network's load by making sure each chain deals with its own specific context
Parathreads
Logically, parathreads are almost identical to parachains, but economically they differ in that they don't lease a parachain slot long term (see Parachain Auctions below). Because the number of DOTs required to register a parathread slot is far lower than the amount one would need to register a parachain through an auction, parathreads get to enjoy the shared security of the relay chain at a much lower cost. However, they have to bid for block production (in non-refundable DOTs) at desired intervals along with other parathreads in the same parachain slot. Parathreads are users of a special, shared parachain slot.
When it's time for this slot to produce a block to send to the relay chain, the parathreads enter an auction for that block slot on the parachain slot. The top bids get into the relay chain, up to a block limit – currently 50 for the entire relay chain. On the surface, this seems like it would slow down some parathreads (i.e. some app specific blockchains deployed as parathreads) if there are more than 50 in the system, but this is not so – parathreads are designed to be used as “read often, write as needed” blockchains.
For example, a copyright or certification parathread which logs new registrations every so often does not need to submit this information to the relay chain on every block, but only as new information is added into the thread. It can batch these writes and execute them in a single block once per day, week, or any other arbitrary period.
One thing that should be noted is that if a parathread is using a local currency to reward collators, the collator must be natively aware of a DOT->local conversion rate if they are to be able to submit appropriate bids for block production in DOTs. That's an economic problem for a parathread to solve on its own.
Parachain Auctions
Parachains are added to Polkadot through a candle auction system – candidates bid on up to four 6-month intervals of parachain slot leases. Initially, there will be ~20 parachain slots with the aim to increase this number to 100 shortly after launch, and further if the network performance allows it.
Auctions are of the candle auction type where the end of an auction is decided retroactively and randomly. This incentivizes people to bid to as close as their intended maximum as soon as possible, given that a late bidder that's perhaps higher than the one before might lose because the auction ended before this bid.
DOTs of the lease auction's winner are locked up for the lease duration and returned afterwards. There will be few parachain slots to lease, so it should be a competitive market but this also means not every application-specific chain can expect to be able to get in on this scarce resource.
In the future, Polkadot will support parachains as relay chains, so a nested relay chain architecture where a chain is another relay chain with its own parachains is also a possibility (similar to shards having shards in Ethereum 2). This part of Polkadot is still in the research phase.
In the next part, we'll look at chain-wide decision making or, as it's usually called, on-chain governance.
