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:
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.
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:
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).
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.”
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?
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.
While ETH can be *pushed* with contract calls on Ethereum, ERC-20 tokens cannot. `approve` and `transferFrom` must be used (in two separate transactions) to first approve an amount of tokens for a receiving contract to *pull*, then for the receiving contract to actually pull.
This leads to poor UX and higher cost: 2 txs instead of 1.
To work around this, many apps use infinite approvals, where you approve the contract to use your entire token balance. Problem: if the contract is exploitable, *all* your tokens are gone.
Last episode, we discussed rewards. On today's episode, the other half of the Nakamoto Incentive: penalties. We will show how Avalanche does not provide the accountable safety property that modern PoS protocols have.
The Nakamoto Incentive is both an incentive (rewards + fees) and a disincentive (penalties for both individuals and majorities). Both are necessary for permissionless consensus protocols to function without having to heavily rely on altruism.
Note that it is absolutely critical that incentives be in place. It is *not* sufficient to prove that a permissionless consensus protocol is live and safe under an honest majority. It must also be shown that the protocol incentivizes an honest majority.
Last episode, we discussed fees and how it's impossible for Avalanche's X-Chain to have non-fixed fees without making fundamental trade-offs. On today's episode: rewards, and how they're similarly impossible.
Let's start by clearing up some confusion from last time. It's not “impossible, period” to have non-fixed fees in Avalanche; rather, it's impossible without making some additional trade-offs to fundamental assumptions or guarantees provided by AC.
The recurring thesis of these threads is that there's no silver bullet solution. Everything is simply a point in the trade-off space. And we'll explore the concessions Avalanche needs to make in order to provide the guarantees and performance it promises.
This is the first in a series of tweet threads that will discuss fundamental shortcomings or pitfalls of the Avalanche Consensus protocol, and its instantiation in Avalanche. On today’s episode: fees.
Now that the Avalanche mainnet has launched, “we have a secret plan that will fix this issue and we won’t tell you until mainnet” is no longer an excuse. So let’s dig in and find out which issues were actually unfixed, and more interestingly, unfixable.
You may have seen comparison tables like this one being circulated. But remember that when it comes to decentralized protocols, there’s always a catch. There is no free lunch and there are always trade-offs. We’ll find out in these threads what those are.
Just published "Nakamoto Consensus Requires Social Coordination and Subjectivity"
TL;DR Nakamoto Consensus, contrary to popular belief, is not objective. It has a subjective component, just like the weak subjectivity assumption required in PoS protocols.
We've been told for years now by Bitcoin maximalists that PoS protocols require *fundamentally* stronger trust assumptions than PoW, in the form of weak subjectivity (asking a trusted third-party for a checkpoint if you've been offline for a while). We've been told a lie.
It's not that PoS protocols do not require social coordination; rather, it is that Nakamoto Consensus does require social coordination!