Join Kelvin from Optimism for a talk titled " How Rollups *actually* work".

As new users flock to web3, critical infrastructure advancements are needed to scale. Scaling Ethereum is your chance to shape the future of Ethereum. Join us March 10th-29th for three weeks of hacking and summits featuring teams like Gnosis Chain, Scroll, Hyperlane, UMA, IPFS/Filecoin, and more. 


-----------------


Follow us: https://twitter.com/ETHGlobal​
Check us out: https://ethglobal.co​m
Email us at: hello@ethglobal.com

So, without further ado, let's welcome Kelvin to tell us about how rollups actually work.

And I can't wait to see what you have for the next 30 minutes, because I got some good news on Twitter and I'm excited.

This is a talk for all of you who think you know how roll-ups work, but you don't.

I know you don't because I don't even know how roll-ups work and I've been working on them for far too long.

I've been working on them since before you were born.

This is a talk about how rollups actually work, also known as...

I'm building the Optimism Collective because I believe that we can actually change the world with the stuff that we're doing and not just build a whole bunch of garbage.

I want to tell you about how you think roll-ups work because I know exactly how you think roll-ups work and I'm gonna tell you in this story.

You're happy, you're on Ethereum, and you got some money.

Then there's this scary bridge smart contract, right?

And the bridge smart contract kind of gets you over to optimism land or kind of protects optimism.

I know you think that this is how it works.

So so you know you send your your your money over to the bridge smart contract, the scary bridge, and it goes nom, nom, nom, and it eats it and spits it out on the other end.

that the Sequencer can be malicious or something.

And so we need to turn the, uh, we need to turn the, the bridge smart contract into, into a security guard and

we need to give it some sort of a ability to protect the rollup.

And so we add these things, these proofs, right?

We add these like fault proofs that protect the roll up with the fault proofs.

It's like, you know, so I'm giving the security guard an AK 47 and then everybody knows that obviously, uh, Zekiel rubs are better than optimistic robes because, because, uh, the marketing department told you so.

So that's like adding a second AK-47, but this time it's gold-plated.

And now we're roughly protecting the rollup.

Nobody's getting past the security guard bridge contract with 2 AK-47s.

And everyone knows that the bridge to our contract is how we protect the rollup, right?

that this is basically how rollups work, you're wrong.

And that's okay because everybody is wrong.

They all think that rollups work like this and they don't.

So I'm gonna tell you how rollups really work.

All right, so I want you to forget everything you've learned.

I want you to take your mind eraser and blast yourself in the face with it.

When we think about a rollup, we always have a data availability layer.

We have some sort of, well, there's actually 2 important things about this input array that there's 2 really important properties.

There's ordering and there's data availability and those those 2 things are both critical.

Ordering is really really important because if the order of my input array changes then the outputs that I get change.

And data availability is really, really important because if I don't know what the inputs are, then I can't compute over them.

So in a rollup, you have an input array, right?

And we usually think that that's a blockchain, but it could even be more than 1 blockchain put together.

But let's just say it's 1 blockchain for now.

And we run some kind of code over that input array and we generate an output array.

And I want to note that there's not necessarily a one-to-one correspondence between the inputs and the outputs.

It could be that 1 input produces multiple outputs or that multiple inputs are required to produce a single output.

But the point is that this picture right here, what you are staring at right here is the rollup.

When you think of a rollup, it's this thing, right?

There's some inputs, that's the L1 blockchain.

There's some code, that's the rollup node software, and it produces some outputs, and that's the rollup blockchain itself.

And so there's a very important question which is how do you actually append stuff to this input array because a rollup is not useful unless we can put data into it and add transactions to it.

And so we need to be able to append things to the input array.

So generally, 1 way of appending inputs is to append things directly.

Depending on the capabilities of the layer 1 blockchain that we're interacting with, you can usually just insert a transaction directly, right?

There's some sort of smart contract that you can interact with, where you can send a transaction to that smart contract and you can insert a transaction into the L1 directly, that adds stuff to the input array, which also, as we see in this picture, will produce outputs, right?

And then a very common secondary approach is this thing called a sequencer.

Now, a sequencer, the idea of a sequencer is that this is very inefficient.

Posting data like this is very inefficient because there's a lot of fixed overhead when you submit transactions to a blockchain like Ethereum.

gas base cost for every single transaction.

That's actually a lot of gas for most transactions, when most transactions can be compressed down into a lot less.

So we tend to want to be able to batch things together, which allows us to do this fancy compression stuff and really take advantage of sort of economies of scale.

So we create this thing called a sequencer.

The sequencer is our little king of the castle.

And essentially all the sequencer does is that it takes user transactions and it bundles them together.

And what it's going to do is it's going to create bundles of these transactions and it's going

to publish them to the data availability layer to your L1 system.

But the important thing is that we want a really good user experience.

Publishing these, getting these bundles together can take quite a while.

We don't always want to publish these bundles immediately.

And so what the sequencer does is the sequencer pinky promises that they're going to include this bundle in the future.

And you see, I've represented this pinky promise by highlighting this in gray.

And essentially what we can do is that we can run our rollup code over what we think the input array is going to look like in the future.

And we can generate these outputs and we know what the outputs are going to look like in the future.

And this is before the sequencer has even published anything to the L1.

We just know that this is what it's going to look like, assuming that the sequencer comes through on their pinky promise.

And eventually the sequencer sends off the transaction to the actual data availability layer, and this becomes real.

So the inputs become real and the outputs become real.

This thing that I've represented to you is the rollup.

And I'll note that I haven't talked about any sort of proof mechanisms or ZK rollups or optimistic rollups because all of that stuff is fake.

And I'll explain to you that in a minute.

So the next thing is, well, we have systems, right?

And we want to connect these systems with other systems because connecting with other systems is useful.

You know, if we just had this roll-up, I guess we could interact in our own little bubble here.

And this is what you might call a sovereign roll-up, right?

You can post data to this data availability layer, you can interact in your own little bubble, but if we want to interact with other things, we need to be able to connect with other systems.

Well, we have an automatic connection to the parent system where the parent system is where the L1 data lives, where the inputs live, because sort of, where is the,

It is defined by the data and the ordering of that data.

So we have this automatic connection to the parent system, which is why I can include transactions by sending a transaction directly to the parent system, because just by definition, I am deriving the rollup from that parent system.

But what about other data sources where you don't have this type of trustless connection, this definitional connection to these other data sources?

There's, you know, there's, you know, Kelvin's Super Rollup 2, and I want to bridge Kelvin's super rollup 2 and Kelvin's super rollup 1, right?

I want to get information from this other rollup into my rollup.

Well, like we said, anything from the input is trustless because the rollup is defined by the input.

But for anything else, we need a convincing argument, right?

Why should smart contracts on my rollup listen to stuff that you're saying over on your roll up or that smart contracts are saying on your roll up.

Why should I listen because at the end of the day, they are 2 separate independent systems and I don't have this direct connection.

How do we generally be convinced of things on other chains?

Well, there's a lot of different ways that we can make bridge code protocols work.

People do authority based bridge protocols, right?

God coming down, you know, with God's little weird finger coming down and saying, this is what the

other rollup or the other blockchain looks like right now.

And if you trust the authority, if I'm a smart contract on my chain and I trust the authority and I'm like, whatever, God's not gonna lie to me,

Then we have sort of a strengthening of this.

So maybe God has 3 hands now and 2 of them have to come down.

you know, which is sort of the, the ugly little brother of the chain coming in and saying, you know, good enough.

It's a, it's a representation of the chain.

It's not the chain itself, but it's a representation of the chain with pretty good trust assumptions where we can say, okay, I'm convinced that this is the state of the other chain.

Fault proofs are essentially 2 people going back and forth saying no you repeatedly until we figure out who's right and then

we have validity proofs and that's the math nerd coming in with such a convincing argument that you simply can't reject it.

This is how we communicate between blockchains.

This is how blockchain communication happens.

If I have a third party chain and it wants to communicate with me, it has to convince me what its state is.

Now what's the worst thing that can happen in this situation?

What's the worst thing that can happen when somebody is trying to communicate with me in this way?

Well, I would argue that the worst thing that can happen is that apps on our chain could be convinced of something invalid, right?

the thing that's happening on this other chain could break.

And it could convince me on my chain that something happened on your chain that didn't actually happen.

And I want to put this in caps, because I'm going to bring I'm going to come back to it later.

But this does not directly impact the other chain.

What has broken here is my view of the other chain.

The other chain is running independently, right?

It could be that the other chain has absolutely no clue that I'm even trying to read data from that other chain.

If my view of that if that other chain breaks, the other chain does not break.

I mean, my smart contracts might break because I might be making decisions based on bad data, but the other chain doesn't break.

All right, so let's get to withdrawals, right?

Because I've talked about all this stuff, and I've talked about a whole rollup system, but I haven't talked about this bridge stuff and the proof mechanisms yet.

When you think roll up, I want you to think about this.

that the that I was sort of lying to you and that these things are blockchains.

Well, I want to put these pieces back together and I want to show you something.

So here's you and let's say you want to send some funds from the parent chain into the child blockchain, into the L2, from the L1 into the L2.

Well, you use the mechanism that we talked about earlier to directly add inputs to the input array.

You send a transaction to the L1 blockchain.

This adds an input to the input array that tells the L2 kind of trustlessly that it can mint funds on the L2.

All right, so this is the same picture that we saw before.

And again, there's nothing in here about Prus, Optimistic or ZK.

So I light my money on fire on L2 and I tell the L1 that I burned it and the L1's like I have no clue.

The L1 has no clue what's happening on the L2.

This smart contract on L1 that is that is uh locking up these funds says prove it.

And so you gotta put on your your judge your judge wig or your uh your lawyer wig and you have to prove it.

Here's the smart contract on L1 that has the key to your safe.

Well, 1 way to prove it is you could use a proof of authority, and that's God's finger coming down.

Then there's a threshold system, and that's, and then there's like clients, and then there's fault proofs, and then there's validity proofs.

This is exactly like what we just did when we wanted to receive data on the roll-up.

Just like when we want to receive data, when we want to send data to the L1, we need to make a convincing argument to the L1 about what, and this applies to any chain, when we want to send data to any other chain, sending data is like receiving data but in reverse.

That should seem obvious to us, but in our mental models, it traditionally isn't, but it is obvious.

Withdrawals are just another chain receiving data from the L2.

Withdrawals, In this case, the standard thing is that withdrawals on the L1, is the L1 receiving data from the L2, just like how we talked about how the L2 can receive data from other chains.

And so when I talked about this, what's the worst thing that could happen?

It doesn't directly impact the other chain, right?

The worst thing that can happen is that the smart contract on L1 releases some funds that it shouldn't release, which is bad, But it doesn't directly impact the L2.

And this is a really, really, really important property to understand.

If the bridge breaks, the rollup does not break.

This is such an important thing to know about rollups.

I think so many people have this mental model that the bridge defines the roll-up.

But in reality, the bridge does not define the roll-up at all.

If the bridge breaks, that is obviously bad.

Assets on the rollup can become under collateralized.

But if the bridge breaks, if the bridge finalizes a state that is not what's in the rollup, That is a problem for the bridge.

The rollup is still going to continue operating as if nothing ever happened because just like I said in the slide many slides ago, the bridge or the rollup may not even know that the bridge exists.

And in many cases the rollup has absolutely no clue that the bridge exists.

So let me get to the second part of this talk, which is that ZK rollups aren't real.

Now, obviously, ZK rollups are real in the sense that people create these things and call them ZK rollups.

We have ZK sync, polygon, EVM, the wait is over, but I'm still waiting.

When I say ZK rollups aren't real, what I really mean to say is that the ZK part is not fundamental to the rollup.

In the way that we just described rollups, there is a rollup part, and then on these other chains, there is an implementation detail of a smart contract on a completely different system that has nothing to do with the rollup that either uses a zk or an optimistic or a light client or an authority proof or many different sort of things to establish a view into the rollup on a completely different system.

The ZK part is not fundamental to the rollup.

There is no such thing as ZK or optimistic rollups.

There are just rollups at the end of the day.

And then we create these view mechanisms on other systems, completely separate systems, and they have proof systems, and those things are ZK or optimistic.

But if you tie these things together, if you think that there's a thing called a ZK rollup or an optimistic rollup, and somehow ZK and optimistic rollups are fundamentally different, you're going to be at a disadvantage in the mental model for what a rollup is.

And the reality is that I think the optimistic crew gets this now, but why not the ZK crew?

And I think the answer is that ZK is really hard.

And people feel like they have to create the ZK proof, Because if you don't create a proof, you don't create a ZK proof, are you really a ZK rollup?

Right, that's sort of, are you really a ZK EVM if you don't have the proof?

They build this proof system and they spend all this time building this proof system and it's really, really hard.

And then they sort of cram the EVM inside of this proof system.

They shove it in and it's sort of, you know, it looks like this and it's kind of like, it doesn't want to be in this tight little space and parts are sticking out and it's not quite the EVM.

And then they pat it on the head and they say that it's just looking extra equivalent today.

What's the right way to build these systems?

The right way is to build the EVM in all its glory.

You know, this is weightlifting EVM, super EVM.

And what we want to do then is we want to build the box around it.

Instead of cramming the EVM into the proof system, we want to create a proof system around the EVM.

And this is what's really going to make it obvious that ZK rollups don't exist, or optimistic rollups don't exist.

And then we want to make a proof system around it.

I cut it a little bit short because We had some technical difficulties earlier, but thank you for coming to my TED Talk.

Join the collective, change the incentives, and you will change the world.

Come check out the vision of what Optimism and the Optimism Collective is trying to do, come check out the OP Stack Docs if you

want to build your very own blockchain, your very own layer 2 today.

And I just want to say, understand this property about roll-ups.

Understand that the proof system is not fundamental.

What you want to do is you want to build a really good roll-up and then you want to build a proof system on top of it and if you build a roll-up that way you can build a roll-up where it doesn't matter whether it's zk or optimistic you can slap a zk proof on it later You can slap an optimistic proof on it later.

You can slap 10 different proof mechanisms at the same time.

But if you think, if you tie the bridge to the rollup, you're thinking about these things wrong.

Change the incentives and you change the world.

And if you wanna fight me on Twitter, we can fight on Twitter.

We got everything and we'll make sure that once this goes edited out on YouTube, it's smooth and perfect.

I think it's a really good way to think about those primitives and just break them down into those hard components that actually matter.

And personally, what I got out of it was that optimism is the real blockchain.

But optimism is the only serious 1, that's correct.

Well, Emmett, thank you so much for joining us and we'll see you all on Discord hacking away on the OP stack.

See all ETHGlobal transcripts on Youtube

Scaling Ethereum Summit | How Rollups actually work - Kelvin Fichter

See all ETHGlobal transcripts on Youtube

Scaling Ethereum Summit | How Rollups *actually* work - Kelvin Fichter

Scaling Ethereum Summit | How Rollups actually work - Kelvin Fichter