Thread by @jadler0

Optimistic rollups have taken Ethereum by storm as a promising avenue for exploring different execution models and enabling dynamic heterogeneous sharing on Ethereum today.

Here’s a thread on the precursors to ORU: scaling techniques that were so close, but didn’t quite make it.

I’ll be covering two techniques in this thread: the earlier “shadow chains” and the more recent “plasma rollup.” There are many more techniques (too many to enumerate) that share many common features with ORU, but none of these have the exact same properties as ORU.

First up, shadow chains, proposed in 2014. Are shadow chains *literally* optimistic rollups? Let’s find out! Here’s the original post on the Ethereum blog:

blog.ethereum.org/2014/09/17/sca…

Now, I did cover why shadow chains are not the same thing as optimistic rollups in a previous post, The “Why”s of Optimistic Rollup, but let’s expand on that analysis.

https://twitter.com/jadler0/status/1192064849444032513

Going into the post itself, here’s the relevant bit. Looks a lot like optimistic rollups! There’s a chain, computation is off-chain, it’s fork-free, there’s fraud proofs, there’s rollbacks, and there’s even a bond that gets burned if fraud is proven.

But there’s one line that pops out...why are state transitions applied to Ethereum? In rollups, in addition to computation, state is also kept *entirely* off-chain. Only explicit manual withdrawals apply state on-chain.

The post mentions complete code, so let’s take a look. The Serpent (ugh) code can be found here:

github.com/ethereum/serpe…

Here we see an explanation of the logic. The shadow chain data format is a bit different than rollup (shadow chains have both transactions and state diffs), but surely that’s just an implementation detail.

Next up, how the contract’s storage (i.e. Ethereum state) is mapped. Wait, why is “data in uncommitted block format above” part of the Ethereum *state*? Does that mean that shadow chain blocks are stored in *state*, not just calldata?

Then, the logic to automatically apply state transitions, as per the post. The loop reads shadow chain state transitions from storage slots, then applies them. Using lots of state is exactly what optimistic rollups try to avoid!

As we can see, shadow chains move computation (and computation of state transitions) off-chain, but not state. The defining feature of a rollup (both optimistic and ZK) is that both computation and state is off-chain.

TL;DR: shadow chains are *literally not* optimistic rollups.

Next up, plasma rollups and the related “optimistic rollup” (a different technique with the same name as the optimistic rollup we know and love---more on this soon).

gist.github.com/karlfloersch/4…

The linked gist gives some numbers for potential transaction throughput and payload sizes...

...with the plasma rollup technique described in the accompanying post on the Plasma developers forum.

plasma.build/t/rollup-plasm…

Let’s start by analyzing the gist. It’s divided into two sections, mostly for plasma rollup, and “optimistic rollup” only on the last line. There are some weird things in this post that don’t align with optimistic rollups as we know them 🤔.

1. Why is this about exits, not transactions?
2. Why are exits only 64 bytes? Transactions in optimistic rollup must include signatures.
3. Why do dispute period and halt time have anything to do with “optimistic rollup”’s safe throughput? Optimistic rollup has no such property.

To answer our questions, let’s check out the post!

“This gives us plasma scalability in the optimistic case, and then pessimistically we fall back to rollup-level TPS without use of zkProofs.”

Wait, that doesn’t sound like optimistic rollups!

“We get plasma-level scale optimistically, and then in the worst case fallback to rollup scalability.”

That also doesn’t sound like optimistic rollups!

So, what are plasma rollups? It’s like Plasma, except you post the *exits* as calldata, and only process them in state in case of a dispute. There’s no blockchain, no rollbacks, no signatures, and no bond. In other words, not optimistic rollups.

So, what are the “optimistic rollups” mentioned here? It’s about posting data or not, in plasma rollups. Since we’re dealing with a Plasma, data doesn’t always have to be put on-chain. Therefore we can optimistically *not* post data on-chain, and only post it when challenged.

This clip from the 21st Plasma Implementers Call confirms our understanding. Data isn’t posted on-chain all the time, but can be excluded optimistically.

TL;DR: plasma rollup and what was called “optimistic rollup” in this post *are not* optimistic rollup as we now know it.

To understand why this seemingly nonsensical naming scheme is used, we have to look back at the history of rollups, and the etymology of the name.

ZK rollups were first concretely developed by @barrywhitehat under the name “roll_up.”

github.com/barryWhiteHat/…

In June 2019, there wasn’t “ZK rollup” and “optimistic rollup.” There was just one “rollup,” and it used validity proofs. ZK rollup and rollup were actually equivalent names used interchangeably for the same technique.

As a result, the “plasma rollup” name was actually somewhat controversial when it was first introduced. And “optimistic rollup” as used then was short for “optimistic plasma rollup,” and NOT as a distinction between rollups using fraud or validity proofs, as we use nowadays.

So when were optimistic rollups as we now know them first published? This post from the end of August 2019 used the expression “optimistic rollups” to describe the technique, but was the technique itself published prior to this?

medium.com/plasma-group/e…

Turns out it was! “Some people at ConsenSys” (to quote @sunnya97) actually created *the exact technique we now know as optimistic rollups* (but not under that name), and published it in the middle of June 2019.

ethresear.ch/t/minimal-viab…

With that, today’s thread is a wrap. For more blockchain history and analyses in the future, don’t forget to like, comment, and subscribe.