Thread by @0x_armin

Optimistic rollups. zk rollups. While we wait for the merge, rollups are quite the rage.

So how do rollups work? What's the scalability gain we can get from them? And how do they compare with each other?

This is part 6 of #multichainfuture. Let's get rolling. 🧵 1/n

In the previous issue of #multichainfuture, you learnt about sharding.

The key idea was splitting verification of a block across many validators. Why?

There are too many transactions to be verified by all validators.

Rollups take a different approach. 😉 2/n

Instead of trying to process all the data/computations on the @ethereum network, rollups ask- do we even need to do that?

In fact, can we shift some of those computation/data publication to other platforms? 3/n

Let's distinguish between computation and data.

Computation of transactions gives the state transition. E.g. how much do you have after paying for that NFT. 🖼

Remember why we need data availability? (We talked about it in our last thread!) 4/n

Data availability is important as it allows @ethereum's participants to check validity of computation.

Keep this framework in mind- it'll help you as we design our very own rollups!

Let's go into the structure of rollups. 5/n

We know that rollups serve a separate platform to execute computations/save data. So how do rollups exist on the L1 chain?

On the main @ethereum chain, the rollup has a smart contract that maintains the state root.

Uh state root? 6/n

Just think of state root as a pointer to important information within the rollup- account balances, contract code etc.

An analogy- a state root is like a bullet journal. You use different bullet journals, and you point to a specific one to access your thoughts then.

Next. 7/n

If you want to move assets into and out of the rollup, the rollup's smart contract also acts as a "bridge".

Here's a diagram to aid your understanding! 8/n

When there are sufficient new transactions occurring in the rollup, someone will publish a *batch*.

A batch is just an update of the information in the smart contract- the pre and post state roots + transactions.

Let's go back to our analogy. 9/n

When you use up your current notebook, you change to a new one. Your old notebook is then the pre state root, while your current one is the post state root.

Easy yea?

We've talked about having "someone" to publish the batch. But who will that be? 10/n

This is where we need you to design rollups for us! No worries, I'll guide you along. 😁

Let's assume that anyone can publish a batch for the rollup. Why will you want this though? 11/n

Allowing anyone to publish the batch gives maximum decentralisation- no one is censored.

But this gives a clear problem- anyone can try to update a batch with wrongly executed transactions. This allows them to "give" some ETH to themselves.

How will you solve this? 12/n

Let's go through this- if you allow anyone to publish a batch, you need to allow people to challenge the update too!

And if deposits/withdrawals via the rollups are instantly finalised, people can "escape" with wrong balances!

What's the solution? 13/n

We implement a time window before finalising a batch update.

This allows people to challenge the batch.

More specifically, the challenger wants to prove there's at least a state transition that's wrongly computed.

Do we get the L1 to re-compute the whole transition? 14/n

Well, it'll be very expensive! In fact, doing so renders the rollup useless.

The challenger pinpoints the exact instruction- e.g. which is wrong?

Alice: 50-20=30
Bob: 10+20=40

Answers in the next tweet. ✅ 15/n

It's clearly the instruction to update Bob's balance that's wrong, so the L1 will re-execute that exact step.

If the challenger is right, he will get part of the malicious proposer's bond.

Wait- you've actually come up with one type of rollup! 16/n

This model is known as optimistic rollup- assume transactions are correct, and only compute on main chain when someone challenges.

Examples of optimistic rollups are @optimismPBC and @arbitrum.

Let's go through their pros and cons using the computation & data framework. 17/n

Pros:
1) Because the update is just a change in state root, the gas cost per batch is low
2) It is easier to implement optimistic rollups (no advanced tech)
3) Lower computation for off-chain transactions

Now try and guess the cons! 18/n

We've talked about how we need a delay for challengers, and that's exactly it！

1) Optimistic rollups suffer from long withdrawal period of a week.
2) To aid challenges, data for transactions have to be published on-chain.

You guessed it- here's where zk rollups come in. 19/n

This is it for today! I hope you've found this thread helpful.

Follow me @0x_armin. I'll be diving into zk rollups next, including how they work and their pros and cons vs optimistic rollups.

Like/RT the first tweet below to help your friend understand rollups 🍱:

https://twitter.com/0x_armin/status/1558438229912666112