Rollup vs Parachain

This is a conversation that comes up a lot, and as I’m adding a ETH 2.0 rollups to the comparisons section part in the wiki, I think it’s a good convo to bring to the forums.

I’ve gotten some good insight into how a Parachains compare to rollups from Rob H:

  1. Architecture: Parachains are most similar in implementation to an Optimistic rollup and most similar in architecture to a ZK-rollup, because we actually run a validity proof. In our case, the proof (the approvals protocol) is interactive, unlike ZK-rollups which are non-interactive.

  2. Unlike ZK-rollups, there are no difficulties in creating parachains with turing-complete logic. (this is a fundamental weakness of ZK rollups, because turing completeness within ZK circuits is not easy)

  3. Optimistic rollups are required by architecture to have their ‘sequencer selection’ logic live in their host contract. This is because the contract needs to accept blocks which may be bad, and may not be executed, and needs to filter out spam. Parachains, like ZK rollups, can encapsulate the sequencer-selection logic within their validation code.

And will leave this here for any other insights from those that might have good thoughts around how to best articulate this comparison.


I am still trying to wrap my head around lot of these concepts, so happy to be corrected.

One really interesting property of a Parachain I find is the free proof submissions to the relay chain while they are leasing the auctioned slot. The Rollups need to pay gas in Eth per transaction which is more similar in model to what I believe Parathread will look like (i.e. pay per use).

Also, if am not wrong, it should be fairly straightforward to plug in the ETH rollups on top of a Parachain like Moonbeam?

1 Like

Parachain is more like heterogeneous sharded execution. The sharding/validity proof mechanism is built in on relay chain’s protocol layer. Ethereum doesn’t have this mechanism built in, so Ethereum L2s has to use implemented Rollup mechanisms as a smart contracts. Currently, there are two rollup mechanisms:

  1. Optimistic Rollup, which relies on optimistic block production and fraud-proof.
  2. ZK-Rollup, which uses zero-knowledge proofs for validity proof. (It actually does not have to be zero-knowledge, SNARK proof more precisely).

The significant difference is on data availability, currently, major Ethereum L2s are using Ethereum L1 as DA layer. For example, writing L2’s calldata directly on L1’s block. While in Polkadot, there is a in-house DA mechanism: Availability and Validity · Polkadot Wiki

The DA protocol of Polkadot doesn’t requires all the relay chain nodes keep the parachain states. However, the details of DA protocol on Polkadot is quite sparse. Perhaps @burdges or @rphmeier can give better answer here.

Imho, sharding and roll up are synonymous, in that both say “mechanisms for sharding trust”.

ZK roll ups are non-interactive proofs in a cryptographic threat model, which shard trust using cryptography, but do still depend upon byzantine assumptions for safety and liveness, including double spending defense.

Optimistic roll ups are interactive or semi-interactive schemes whose security model is either undefined or much worse than byzantine assumptions, like watch towers aka fishermen being honest and online, or losses being recoupable post-finality. An optimistic roll up can choose safety over liveness however, like by permitting any one watch tower to halt the block.

Polkadot is an interactive proof in a byzantine threat model. We shards trust by delaying finality until our cut-n-choose-like approval checker game finishes. An adversary must commit to their attack before learning their approval checkers, so assuming we tune everything right then they’ll loose by gamblers ruin.

A “sharding” scheme like omniledger are semi-interactive proofs in a byzantine threat model. These shard trust by assuming fewer adversarial nodes like say 80%, shuffling nodes among the shards according to strong randomness (interactivity), and then arguing via a concentration inequality that say 1000 nodes per shard suffices. We’ll use this to go beyond 1000 validators.

Imho we need an adjective to describing these “sharding” schemes that argue security by concentration inequalities because we should use the word sharding for other things too.

Cosmos is a bridge-like scheme which simply makes users trust both chains. Although this sound bad, it’s beats bridges and optimistic roll ups when mostly the same people run nodes on both chains, so ideally they should ideally build a repeated trust set instead of sharded trust.

Real banks are kinda like optimistic roll ups, in that they get audited after stuff happens, but also in theory kinda like polkadot in that miss-behavior should result in massive penalties, like jail. Also, their government insurance more resembles optimistic roll ups than polkadot.

It’d be funny if we write the machine elves paper on polakdot’s approval checkers as a paper about making banks provably secure. lol


In Polkadot, the erasure codes are used to keep parachain state available to the system without requiring all validators to keep tabs on all the parachains. Instead, validators share smaller pieces of the data and can later reconstruct the entire data under the assumption that 1/3+1 of the validators can provide their pieces of the data.

The 1/3+1 threshold of validators that must be responsive in order to construct the full parachain state data corresponds to Polkadot’s security assumption in regard to Byzantine nodes.

The DA assumption of Polkadot is stronger than the HMM (Honest Majority Money, or more than 2/3 of stake is honest) assumption, since it requires 1/3+1 number of validators to be responsive.

While this assumption is stronger than the current “simply using L1 block space” Ethereum L2 DA solution. Not sure how this compares with Ethereum’s DA solution after protodanksharding/danksharding.

We do want parachains to explore “whole block” optimizations. Among these, schnorr half-aggregation and snarkpack should save parablock space and considerable CPU time on validators.

We also think off-chain single-hop state channels appears promising whenever you’ve real locality. If you’re running some role playing game then you might want a state channel for each dungeon room.

We hope however that polkadot’s cut n choose roll up hits a sweet spot between costs and security, as well as development ease, latency, and performance, eventually making other roll ups effectively obsolete:

A zk roll up parachain is more secure than polkadot itself, and can even be recursive like mina, but they’re expensive in CPU time. An a16z guy recently estimated zk roll up provers cost one million times the CPU of single verifiers, so like 20,000 times polkadot’s CPU costs, and likely much worse once you consider opportunity costs. I’d never trust estimates from a16z of course, but they’re expensive in CPU terms.

An optimistic roll up run fewer verifiers than polkadot, but they’ll wind up being much less secure, due to their verifiers being know in advance.

We think polakdot works out competitive on security vs bandwidth too, like maybe a zk roll up running 20 or 30 nodes could’ve a third or half our bandwidth, but they too loose liveness and safety if they’ve too few nodes, and some roll up tools like celestia look bandwidth heavy too.

You cannot recursively use byzantine security assumptions in the way you can recursively use cryptographic assumptions. In particular, we cannot simply recursively nest relay chains into parachain slots because polakdot’s 2/3rd honest assumption only concerns validators, and collators can do whatever evil they like. Any optimistic roll up parachain similarly introduces extra security assumptions, like bridges do.

As I said, we want multiple parallel-ish relay chains via sharding techniques, once we’ve enough validators, good enough randomness, and trust like 80% honest validators or so. We’re adding security assumptions here too, but ones we understand better.