Rollup vs Parachain

Tech Talk
1

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.

6 Likes
2

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
3

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.

4

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

4 Likes
5

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.

6

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.

2 Likes
7

I gave a presentation at ETH Denver on the topic “What is Shared Security?”

You can see a recording of that talk here:

And the presentation:

Before describing how Polkadot achieves shared security, I touch on some other “shared security” models:

Different Forms of Shared Security Today

  • Native: Native shared security is implemented at the protocol level, and is represented as a Layer 0 blockchain, working underneath Layer 1 chains.
  • Rollups: Optimistic and zero knowledge rollups use a settlement layer to provide security and finality to their transactions.
  • Re-Staking: Some protocols allow the use of already staked tokens to secure another network, usually through the creation of a derivative token.

but these different forms are not equal…

Then, at the end, I do a quick pros and cons of each of these models:

Re-Staking Solutions

Pros

  • Seems to be protocol agnostic, and can be “backported” to new and existing chains.
  • Smaller / newer chains can rely on more valuable and stable economies.

Cons

  • As tokens are continually re-staked, the economic “costs” needed to attack secured chains decreases.
  • No real computational verification or protection provided by these systems.
  • Seems to ultimately fall back on centralized sources of trust.

Optimistic Rollups

Pros

  • Not limited by the complexity of the on-chain VM.
  • Can be parallelized.
  • They can stuff a lot of data in their STF.
  • They can use compiled code native to modern processors.

Cons

  • Concerns around centralization and censorship of sequencers.
  • Long time to finality due to challenge periods. (could be days)
  • Settlement layers could be attacked, interfering with the optimistic rollup protocols.
  • Suffers from the same problems allocating blockspace as on-chain transactions.
    • On-chain costs to perform the interactive protocol.
    • Congestion of the network.

Zero Knowledge Rollups

Pros

  • Honestly, they are pretty great.
  • Proven trustlessly.
  • Minimal data availability requirements.
  • Instant Finality (at high costs).
  • Exciting future if recursive proofs work out.

Cons

  • Concerns around centralization of sequencers and provers.
  • Challenging to write ZK Circuits.
    • Turing complete, but usually computationally complex.
    • Hard to bound complexity of circuits when building apps.
  • Suffers from the same problems allocating blockspace as on-chain transactions.
    • On-chain costs to submit and execute proofs on settlement layer.
    • Congestion of the network.

Polkadot Native Shared Security

Pros

  • Protocol level handling of sharding, shared security, and interoperability.
  • Easy to develop STF.
    • Anything that compiles to Wasm.
  • Probably the best time to finality, usually under a minute.
  • Data availability provided by the existing validators.
  • Much less concern of centralization from collators vs sequencers and provers.

Cons

  • Wasm is unfortunately still 2x slower than native compilation.
  • Requires lot of data being provided and available in PoV.
  • Certain limitations enforced to keep parachains compatible with the parachains procol.

I wanted to a twitter thread with this same information, but also get feedback from the community before I start sharing it further.

What do you all think of what I wrote? What did I get right? What did I get wrong? What did I miss all together?

cc @pepyakin @rphmeier @burdges

Related: ZK Rollups as Parachains

10 Likes
8

My apologies, but where would be a good place to start that would teach me what these things are, where i can understand the terminology being used? I can read the question, and then the answer, but have no clue what the answer is saying. What trade/area of learning teaches this? Im probably making myself look silly but i want to understand this stuff. Thanks for any help in advance.