Anna (00:00:05):
Welcome to Zero Knowledge. I'm your host, Anna Rose. In this podcast, we will be exploring the latest in zero knowledge research and the decentralized web, as well as new paradigms that promise to change the way we interact and transact online. This week, James and I chat with Ben Jones and Mark Tyneway from Optimism. We learn about the team, Optimistic Rollups, what is unique about Optimism, the challenges of Optimistic Rollups, partnerships and more. But before we start in, I want to say thank you to this week's sponsor Least Authority. Least Authority is a leader in the security of distributed systems. They provide security consulting services, develop open source products and contribute to the advancement of learning and research in the field. In addition to their security reviews of innovative projects, such as Loopring, Mina, and Filecoin. This May they will actually be releasing a white paper on ZKAPs or Zero Knowledge Access Passes. ZKAPs is an anonymous token-based authorization protocol that facilitates an online exchange of value, while disconnecting the necessary payment data from day-to-day usage service data of customers. PrivateStorage will launch right after the white paper's released. Also this coming summer, MoonMath Manual - a beginner's guide to zk-SNARKs, which introduces the theory and applications of zk-SNARKs from various angles will also be released. So sign up for Least Authority's newsletter to stay in touch and be notified of the release of the ZKAPs, white paper, PrivateStorage, and the MoonMath Manual, as well as continuous security audit reports, job openings, and more. Visit leastauthority.com/newsletter to join their mailing list. So thank you again, Least Authority. Now here is our interview with Optimism.

Anna (00:02:03):
So this week, James and I are here with Ben and Mark from Optimism, builders of the first Optimistic Rollup live on Ethereum. Welcome Ben and Mark.

Ben (00:02:13):
Thank you.

Mark (00:02:13):
Thanks, Anna, for having us.

Anna (00:02:15):
And hello, James. Welcome back.

James (00:02:17):
Hi Anna. Hi Ben. Hi Mark. It's good to see you all again.

Mark (00:02:20):
Hey James.

Ben (00:02:20):
Likewise.

Anna (00:02:23):
So Mark, I want to start with you. You've actually been on the show before. I think you were on the show last year, but for a totally different project. So you were working at the time on Handshake and I'm curious, what's been your journey since then. I want to hear what's new with you.

Mark (00:02:39):
Oh yeah. Handshake is a really interesting project. For people that don't know, Handshake is a decentralized DNS root zone and it's a fork of Bitcoin. So 10-minute block times, UTXO-based, but it has some kind of fun, extra goodies that let you basically purchase domain names on-chain in an auction system. And after working on Handshake for a while, the project is pretty decentralized. There wasn't really a good ecosystem of companies building on it yet. And I was always Ethereum-curious and I had met Ben, Carl and Jing and Optimism team at conferences, and I wanted to hop into the Ethereum space and learn what could be built over there. Just because building on Bitcoin, it takes months and months in what you can do in a single weekend on Ethereum.

Anna (00:03:40):
And actually, I guess if anyone wants to find out more about that work, that you mentioned, the Handshake work, I'll add the link to that in the show notes. And we did a whole episode about your background and that project, but when did you join Optimism?

Mark (00:03:54):
I believe it was last July or so.

Anna (00:03:57):
And what are you doing there? What's your gig?

Mark (00:04:00):
I'm a developer and I'm working on basically Geth. We maintain a fork of Geth that runs as a sequencer or a verifier. And I'm also doing some DevOps work, our deployments and making sure that it's stable running in the cloud.

Anna (00:04:15):
Cool. How big is the dev team right now?

Mark (00:04:18):
Oh, it's pretty small. It's probably around 10 or so people.

Anna (00:04:23):
Okay. In a team that size you actually get to do a lot, I guess, you get to wear many hats.

Mark (00:04:29):
Yes. One of my favorite parts.

Anna (00:04:32):
Now, Ben, I want to hear about you, what's your background and what led you to Optimism? And maybe what do you do there?

Ben (00:04:38):
Hi, what's up y'all? I'm a total Etherean by heart. I discovered in early 2017 this thing called Ethereum, and it basically seemd like: "Oh, this crazy libertarian edge case that I saw that was Bitcoin, which was really cool, actually has a lot more things that we can do with it now." So that was super exciting. My background in that time was math and physics, that's what I studied in school. And I quickly realized that all of the fruits were lower hanging in Ethereum by far, than they were in the physics and math world. And I just got hooked. That began a long journey. I started doing research at the Ethereum Foundation, working on Casper and with Vlad. And then I found Carl and Jing, and we realized that there was a whole world of even more practical scaling opportunities that was layer 2. And that got me really excited because I knew that we could actually implement these things on Ethereum today. And that was super exciting.

Anna (00:05:35):
That team that you just mentioned... I understand Optimism is like an extension of the Plasma project or the Plasma team. Is that the case? Was the group that you're talking about originally in the Foundation?

Ben (00:05:48):
Yeah, for the most part. I think usually when we use Plasma, that's referring to a class of layer 2 solutions and there's a lot of dope projects working on Plasma. So ---I can't at all claim to be,--- we can't claim that we were the Plasma team, but we were called Plasma group, we did do a lot of fun, exciting research in that area. And over time, what we realized is while academically infinite TPS was really cool, what was even cooler were smart contracts because that's what people are using. And once we started to understand the state availability solution, that is the rollup, we started to realize: "Hey, there's a real thing here. We could actually build this." And so we started Optimism.

Anna (00:06:27):
Cool. All right. Let's start talking about the Optimistic Rollup. We've had already on the show this month, two projects who created zk-Rollups, and I think our audience is very well-versed in the zk-Rollup space. When it comes to Optimistic Rollup, I have done, I think, one episode on it with John Adler, maybe six to eight months ago, but I think it's worth it to redefine Optimistic Rollup. What is it? And ---maybe like, for me,--- I'm curious, how is it specifically different from Plasma, or an evolution from that?

Ben (00:07:02):
Oh, I would love to talk about this. So I think one great framing that we've been able to evolve by now in the layer 2 scaling space, which is super useful, is basically this two-by-two grid, Optimistic and zk, you know, the left and the right, and then Rollup and Plasma on the top or the bottom. And sometimes that zk Plasma is called Validium now. That's a fancy new term that the Stark people have been working on. But effectively what these sections of the grid correspond to is where transaction data lives, how it is committed to and how the validity of the output of those transactions is acquired on L1. So for Plasma versus Rollup the difference is in a Plasma, you commit a block root that contains a bunch of transactions committed within it, but you don't actually take that transaction data and put it on-chain. Instead you have off-chain data providers that say that they will make their data available to you. And in the event that they do not, users have a way to challenge that that data was made available. And this basically must be answered by putting that particular sensor to data on-chain. So that's one side of things. The other side of things is a Rollup, where you've explicitly put all of the data on-chain and really you put it into the history. So it's not like sitting there in a smart contract that can be accessed by some other money Lego, but it is in the history in a way that nodes can retrieve it as they're downloading the chain.

Anna (00:08:29):
Like this is L1 nodes, L1 nodes can retrieve this information.

Ben (00:08:33):
That's right. Very important point. Yeah, absolutely L1 nodes. So that corresponds to where the data lives in each of these cases, either you put it all into a sensitive resistant form upfront, or you keep it off and wait for maybe there to be a dispute or you just trust someone is holding onto it off-chain.

James (00:08:51):
The two axes here, where does the data live? On L1 or somewhere else? And then how do you achieve confidence in the data? Are you using validity proofs, like a zero knowledge proof system or are you using fraud proofs, which would make it an Optimistic system?

Ben (00:09:09):
Exactly. That's exactly right, James. And of course the zero knowledge proof... Interestingly, the real property that gives us the scaling is not the zero knowledge element of these SNARKs or STARKs or choose your Moon Math flavor. It's actually the succinctness that is the important part. Because that succinctness lets us spend much less gas to verify a big block of execution on L1.

Anna (00:09:33):
I mean for the uninitiated, I've always understood it a little bit like there is this batch of tons of transactions happening off-chain, and then there's this mechanism to bring them on chain with a very small amount of data. The question I have here is Lightning does something similar, this idea that you are able to do this batch of transactions off-chain. So what is the big distinction between something like Lightning and something like these rollups or Plasma?

Ben (00:10:02):
They're definitely both super similar. You're totally right, Anna, that there's a lot of underlying components that are the same basic idea. One of them is that we want to use the blockchain more efficiently. So we use it as an adjudication layer instead of as an execution layer. That's basically the Optimistic side of that access that I was talking about, all of those solutions, including state channels, like the Lightning Network, etc., all use that sort of framing. You don't go to court to cash a check, you go to court when the check bounces. So that's one aspect. The designs that you choose beyond that core framing basically give you different properties in your system. So you might have a system, for instance, like the Lightning Network, where payments can happen entirely off-chain and almost infinitely. Like you can imagine sending a Satoshi back and forth between two servers at a million Satoshis per second, and it's not very meaningful, but you could claim you have this incredible TPS number. On the other hand state channels require that the participants set be known in advance. So to add someone to a state channel, to get them participating in this network, for them to receive money or send money, they have to make an on-chain transaction, whereas in a Plasma or a rollup, that's not necessarily the case. So it comes with some other trade-offs, namely not quite as off-chain, not quite as theoretically infinite throughput, but you get some nicer properties.

James (00:11:18):
You can kind of think of it as another trade-off access is a state channels and payment channels have to be fixed participant. But what they get is this nice property where there is a setup and an ending. So there's only ever two things that go on chain, whereas with plasmas and with rollups, we really, really want these to have a flexible participation. We want people to be able to drop in and out over time. And that means that they need to have a succession of on-chain commitments to the state. They need to have many more than two commitments on-chain. What are the practical limitations on transaction throughput in a plasma or rollup compared to a state channel, which you said can have essentially infinite transactions, infinite throughput.

Ben (00:12:13):
That's a great question. So I think there's a bit of a spectrum here and it probably goes like somewhere from rollup to plasma to channel, in terms of the participants set that you can get. So, one thing you can do in Plasma for example, is you can post absolutely massive blocks because the only thing you put on-chain is a hash of the block. That block actually could be bigger than any one user could validate. And they could actually validate subsets of the blocks that is the transactions that pertain to them and follow the chain. So you can get a lot, a lot of throughput out of Plasma with that, with still an unlimited participant set. On the other hand, with a rollup, Optimistic or otherwise, you do have to put those transactions into some availability mechanism, which is the L1. And so because of that, you are somewhat limited. And this is why we need things like Eth2 to expand that limitation further.

Anna (00:13:06):
Got it.

James (00:13:06):
So is the limiting factor there the amount of layer 1 chain space that your layer 2 system consumes?

Ben (00:13:17):
That is the ultimate upper bound. Absolutely.

James (00:13:19):
So where a state channel only touches the main chain two times and a plasma only puts the tiny hash of this block onto the main chain, a rollup has to put much more data on there?

Ben (00:13:33):
Exactly right.

Anna (00:13:34):
And is this the same for zkRollups? Like, this is just rollups consistently across the board.

Ben (00:13:41):
In fact, what you were doing with that data is you are rolling it up. A ridiculous name, but a great one.

Anna (00:13:48):
I think it's a pretty good one. I mean, I don't know. Does it come from Fruit Roll-ups? Is that why people got excited about it, or was there some technical background to this name? I thought it was Fruit Roll-ups, I don't know. That's what it struck in my mind.

Mark (00:14:03):
One difference between a zero knowledge Rollup and an Optimistic Rollup, that I think is worth talking about, is just in Optimistic Rollup we'll actually post the transactions themselves and all of the state transitions have to be executed. Whereas with a zero knowledge Rollup, they can include a zero knowledge proof. And the state diff.

Anna (00:14:29):
Does that mean you have to settle in a way, in the Optimistic one? Or am I missing exactly the part here?

Mark (00:14:37):
This is similar to one of the main differences between Bitcoin and Ethereum, as in Bitcoin you have an implicit state and explicit state transaction, where in Ethereum, you have the opposite, you have an explicit state, the state tree and implicit state transitions, whatever the contract execution does. It sounds like what you're saying is that Optimistic Rollups have, Optimism has this implicit state transition, where zkRollups have an explicit state transition.

Anna (00:15:17):
Cool. This is going a little deeper into the distinction between Optimistic and zk, then I feel like I've done before. So thank you.

Mark (00:15:25):
We're playing taxonomist, it's fun.

Anna (00:15:28):
So Optimism is the project that both of you are working on, but are you the only Optimistic Rollup in town or are there others? Is this a concept that is from this org? Or is it something that's actually being replicated with different teams?

Mark (00:15:42):
Yeah, there's definitely other projects out there working on Optimistic Rollups. I know Fuel is doing something interesting with a UTXO-based Optimistic Rollup. I'm looking forward to whenever they come out with their more complex scripting language that they've been talking about.

James (00:16:01):
Their prototypes are interesting.

Anna (00:16:03):
Are there any others?---- Maybe that were not--- Cause we did have Fuel on, but anyone else?

Ben (00:16:09):
There's a few others. Arbitrum is definitely another big one, which are doing some super cool, interesting things. The Hubble project is another very underrated one, that I will recommend you all go on to github and check out if you so desire.

Anna (00:16:21):
Cool. I mean, I know that there's Zkopru, which I think that's how you say it. And that's like a combo zk-optimistic. Has the Optimism team considered including zero knowledge proofs somewhere in their construction, even if it's not a zkRollup?

Ben (00:16:39):
Absolutely. So zero knowledge for privacy is a great match for Optimistic Rollups because the evaluation of these zero knowledge proofs, of these SNARKs can end up being quite gas-intensive. So if you make the execution of that SNARK verification be Optimistic, then you can further lower your costs, which is pretty cool. Obviously privacy is another super important one related to this. In fact, building a zkRollup does not give you privacy just because there's zk in there. This is what I alluded to before. In a simpler way, you do the zk part for the speed, the verification, but you're not necessarily hiding what's going on.

Anna (00:17:19):
Got it.

James (00:17:19):
The only one that does claim to do privacy right now is Aztec, right?

Ben (00:17:24):
That's right.

Anna (00:17:24):
And they're actually the episode right before this one. In some of the previous episodes I did on zkRollups, we did actually talk about the criticisms of Optimistic Rollup and I thought maybe we could go through some of those with you, because I'm very curious to hear from you as the Optimism team, how you treat these questions, how you think about them. So one of the big points is this distinction between the fraud proof and the zk proof. With fraud proofs, as I've understood it, there's almost like a dispute mechanism that would happen after the fact. And since that takes so long, the idea that you'd actually be able to resolve the dispute, in time to be able to adjust any sort of transaction, it's too late. That's the thinking that I feel has been, at least that's what I took away from it. Now I'm curious how you think about that or how you take that criticism?

Mark (00:18:21):
Yeah, totally. So basically, just to frame the problem, when the L2 system submits transactions and corresponding state routes to L1, and then there's this fraud proof window, which we've parametrized to be one week, and the absence of a fraud proof will determine the validity of the transaction and its corresponding state route.

Anna (00:18:45):
So if there is an absence, what does that mean?

Mark (00:18:48):
If no fraud proof is submitted, then the transaction can be considered finalized.

James (00:18:52):
Because anybody can make a fraud proof, right?

Mark (00:18:57):
Yes.

James (00:18:57):
So if nobody does, that probably means there was no fraud.

Mark (00:19:02):
Yes. Assuming that everyone can access the data and everyone can compute the state transitions.

Anna (00:19:09):
So fraud proof, it's proof of fraud having been committed. What does that even look like? What is fraud proof? Do you go like, "This is wrong for sure". Like what is it?

Ben (00:19:20):
You do indeed prove things very explicitly wrong. That's a great question. So in general, like Mark said, the general pattern that you see is a transaction is posted and then a proposal, as to what that transaction did, is posted. And then the next transaction is posted and then the next proposal is posted and so on and so forth. And the core trick is to go from the latest valid proposal and prove that if you executed the transaction against that valid proposal, the next proposal would be invalid. So what this means is that you can evaluate this fraud without just naively executing all transactions in the history, leading up to that point. Instead you basically take the hash that came before, you provide some Merkel branches and you run the transaction against those branches.

Anna (00:20:10):
But where is this data even coming from? Is it two hashes that you're basically showing one that is already proven? And then the next one, where are they?

Ben (00:20:20):
Oh, they live on Ethereum. So you actually, interestingly you roll them up as well. So actually what happens when you post these transactions and you post these proposals is that you can post them in a batch. Those are hashed into a single value and that value is stored on-chain. And so when it comes time to prove fraud, you actually undo that hash and you provide a proof done to a very particular element that you disagree about.

Anna (00:20:46):
But--- is that hash---, the first hash and the second hash, what's in between them? Is it many transactions or is it a single transaction? It sounds like it's many, it's almost like these batches that have been written on-chain.

Ben (00:20:58):
It's definitely a challenging one. And what you're getting at is the consistent overloading of the word transaction in the blockchain. So it depends on what you mean. We call that data type of transaction in our system, but that could actually contain several user transactions, which in Ethereum we sometimes call "meta transaction". Although that is perhaps a bit devoid of meaning on its own.

Anna (00:21:22):
This is interesting. So this word "transaction",--- I've also,--- this has come up before, where also transactions in a zk concept is different. And so transactions, the way I've been using them, the way I'm asking is actually like many transactions between different users, doing transfers within the Optimistic Rollup. I'm imagining that you're able to do many of those. And then that becomes batched, maybe it's merkelized and it's hashed. All of those little transactions are individual leaves potentially? Is that how it looks?

Ben (00:21:53):
Yep. That's about right.

Anna (00:21:54):
Okay. So then there's the hash and that hash gets written on-chain. User transactions is quite high or could be quite high, as many Merkle leaves as you can include. But you're saying that a transaction for you is also just that moving of the hash on-chain.

Mark (00:22:10):
So that single hash that commits to the entire batch gets stored on L1. And then to run a fraud proof, what happens is you can basically prove inclusion of the transaction, and then you can prove inclusion of all of the storage slots that were touched by that transaction's execution. And you basically will deploy all of the contracts onto L1 and you'll fill in all the storage slots that were touched on L1 and then execute the transaction. And then you'll take the corresponding state group from the L1 execution and compare that against the proposed state root that was sent by the sequencer.

Anna (00:22:58):
Mark, you're using the word "transaction" again here kind of unclearly. Now I'm not sure which one you're talking about. So we just defined these two types of transactions, right? There's the ones, the users sending funds between each other, or maybe it's a smart contract doing something. And then there's this other transaction. Maybe we just stay there for a second?

James (00:23:16):
It sounds like from the top layer we have on-chain, the Optimism state route, which says the whole current state of this Optimistic system. And then we want to have a block, an Optimism block, that takes that state route and produces a new one. And we would like to be able to prove that that block is correct and unfortunately that's really expensive. So instead we use the nice Optimistic proof, which is saying, "Okay, if there's no fraud shown, it's correct." And in order to enable people to produce fraud proofs, to show that there was fraud in this block, we're going to take that block and we're going to break it down into a set of checkpoints, so you might have a hundred checkpoints in this block. And the person creating the fraud proof is going to choose two of these that are next to each other and say that the fraud happened between checkpoint 57 and checkpoint 58. And so what the layer 1 does is it looks at the block, it says, "Okay, here's all of the code that was executed between checkpoint 57 and 58. I can learn the state at checkpoint 57 by having people upload it for me. And then I can run the code and see if it produced checkpoint 58 correctly." If it's correct, then there was no fraud. If the layer 1 produces a different checkpoint 58, then there was fraud.

Anna (00:24:51):
Okay. Is it a contract happening on L1 that's actually re-running something? Is there almost like a verifier type setup?

James (00:25:00):
Yep. And one of the things I think is really cool about Optimism and Arbitrum and some of these is that the verifier is running the EVM or is running the OVM or things that are extremely close to the EVM and can run Solidity contracts.

Anna (00:25:17):
So, Ben, I want to go back to this question, I want to bring the word "transaction" back because I still want to understand. Let's use that term, maybe "checkpoints". Are there many transactions within those checkpoints? User transactions, that's what I mean, like sending of funds or contracts doing something.

Ben (00:25:36):
The answer is yes. Or maybe a more nuanced question is "how many"? And in Ethereum each transaction has this measure of how computationally expensive it is, called "gas". So sending money to someone, not a lot of gas. Doing 50 flash loan swap magic things, it's going to be a lot of gas. And what you want to do is make sure that the amount of gas from one checkpoint to the next is bounded. And so yes, there can be multiple transactions. And in fact, the frequency with which you checkpoint can come out of the amount of gas that's been spent.

Anna (00:26:15):
Wow. Interesting. Okay. Is the checkpointing actually happening on the Rollup side? I think of these rollups as also like they're standalone blockchains, there's things being blocks in a way or something being created, a record being created also on them. So are those checkpoints on the side of the Rollup or are those checkpoints...I realize it's been verified on-chain, but where..?

Ben (00:26:37):
That's a great question. They're like the link in some sense, because they live on both. What you do as a verifier is you download those transactions, you compute locally what you think those checkpoints should be. Then you watch the chain and compare those checkpoints to what were proposed. If you see a disagreement between what you computed locally, which you know is correct, cause you did it and it's your computer and that's different from what was proposed, then you go into the 57 to 58 thing that James was talking about.

Anna (00:27:09):
Let's than walk through what the node operator does exactly. So this hypothetical person or computer has found this problem, this discrepancy, what happens? What is the process?

Ben (00:27:21):
There's conceptually three phases. There's basically a part where you upload all relevant L2 state that was involved in between the checkpoint that was correct and the checkpoint that was wrong. And that we call the pre-execution phase, when we think about this, conceptually. So for example, let's say the checkpoint had a transaction from Alice to Bob, it had another transaction from Carol to Dave. Before you can execute the fraud proof, you have to go to the checkpoint that was correct and put on chain the balance of Alice, Bob, Carol, and Dave, because this is the requisite information to be able to execute the transaction. So that's conceptually one thing that you do, the next thing that you do is you actually execute the transaction. So you give the transaction data and you run it on chain.

Anna (00:28:11):
Oh, wow. On L1?

Ben (00:28:13):
Exactly. And so we have something called the OVM that enables this, but this ends up being one of the hardest problems is how do you create a system of transaction execution that you can run on L1, if need be. Cause you're running like a little slice of L2 execution on L1. And the EVM is not really built for that. So that was a really fun problem to solve. But that's what you have to do, you make sure that all the data's there, you make sure that you have a way to deterministically run the transaction against that pre-state. And so that's phase two, you execute, in our example, you subtract from Alice's balance, add to Bob's balance. You subtract from Carlos balance, add to Dave's balance. Now that you have executed that transaction, what you do is you take all of the updated values and you use them to calculate what the next checkpoint should be because, given the old checkpoint and all updated values from the old checkpoint, you can derive what the new checkpoint should be. And once you've done that, you have a single hash for the checkpoint and you prove that it's not equal to what was proposed and you've proven fraud.

James (00:29:26):
So you have these full nodes that are involved in the Rollup, that are executing these blocks and looking for fraud. And it sounds like ideally the layer 1, when it is validating a fraud proof does the exact same thing. It goes from checkpoint to checkpoint and executes everything in between to make sure it's right. Is that in the correct neighborhood?

Ben (00:29:52):
Yeah, absolutely.

Anna (00:29:55):
Is the expectation here like, "That will never happen"? Are you trying to test the system to see if that even could happen? I just picture, since that mechanism is set up, is it set up purely to be like, "You can try, but it won't work. Cause there's a fraud thing."? That's the question I have, will people actually do this? Will there be fraud? I mean, obviously you don't want fraud.

Mark (00:30:17):
Yeah. Ideally there's no fraud.

Anna (00:30:19):
So it's like you've created a very elaborate trap and you've been like, "Look at the trap, you better not do it cause we're going to catch you." And that is encouraging people to stay in line.

Mark (00:30:30):
Yep. It's the most important code that should never run.

Ben (00:30:36):
Exactly right. I think I called it in some presentation "MAD, mutually assured dispution". This is a really interesting one. This is very common question that you bring up, Anna, and it's such a fascinating one. It almost always comes back around to some topic of incentive systems in blockchains and when they do or don't apply. A common example of this is all of the people running a full node on Ethereum, that are not miners, they're running very complex infrastructure and doing an incredible service to the community, but they're also not getting rewarded in the same way that a miner is for that. And so there's all sorts of these fascinating, subjective reasons that people have for doing different things in the system. I think it's pretty likely that the mechanics of those incentives work out so that there's naught fraud being proven. On the other hand, you should make proving fraud profitable. So that in the event that there is fraud, it's pretty much a no-brainer for the people that see the fraud to go ahead and publish that.

Anna (00:31:43):
---That actually speaks to--- This is where my question's coming from, because you're expecting people to perform this role, I guess, of checking or looking for fraud or seeking fraud. And they will likely never find it. And so why are they doing it at all? And I guess this is interesting.

Ben (00:32:01):
And the answer is, because they want to know the state of the chain themselves. There's lots of people that run their nodes and choose not to outsource that information because they want this notion of security. And so this applies in a rollup, too.

Anna (00:32:16):
Is this like, so you're a dApp, --- that relies on your,--- you have your own node and you're running a node and you maybe interact with, you move something with Optimism. ---This is what I'm trying---. I'm trying to picture a use case for somebody running this node, who doesn't get paid ever because they never find fraud. And they are doing some core infrastructure stuff. Where is their benefit? For them it's like, they want to work on both, they want to go between the chains, and so they run the node and somewhere in there they could find fraud, but they probably will never. But they have some other business case that lives on top of that, so they don't care about incentives?

Ben (00:32:56):
Exactly right. So your block explorers are always going to be running these nodes. There's something that we might touch on later, there's notion of fast exits purchasing yet to be withdrawn funds. Those people want to run a node. Crazy nerds like me and Mark run Ethereum nodes, et cetera, et cetera.

Anna (00:33:16):
Another point of criticism that was, I think it was Alex from Matter who brought it up, was this M of N honest validator assumption, this idea that you would need... ---I don't know if that's exactly.--- Do you know this expression? Does this mean anything to you?

Ben (00:33:30):
Yes. Well, in a layer 1 consensus you have an N of M honesty assumption, where that's usually like two thirds or half. Like James said earlier, anyone should be able to prove fraud. So the interesting thing in a rollup is actually that you have a 1 of N honesty assumption. It only takes one honest person to prove fraud to secure the chain.

Anna (00:33:49):
Interesting.

James (00:33:49):
You still can't escape the M of N honesty assumption of the underlying chain though. So you're layering another assumption on top of that.

Mark (00:34:01):
That is true. It is the weakest link, because you basically inherit the L1 security because even if a miner, let's say that miners are trying to censor the fraud proof, and a single miner defects and decides to include the fraud proof, then that block could just be reorged out by a majority. So you are right. It comes back to like the 51%.

James (00:34:28):
That's really interesting, because it sounds like if you have this coalition of miners on the layer 1, what happens to Optimistic Rollups is that they have this improper state transition potentially. Is that right?

Ben (00:34:46):
That'll definitely be the outcome in the event of a 51% attack.

James (00:34:49):
And for a zkRollup the outcome of a 51% attack is that it has a liveness failure, that the miners decide that that rollup stops running for as long as their coalition lasts.

Mark (00:35:02):
So the interesting thing about an Optimistic Rollup being censored is that, I do agree that miners will censor fraud proofs being sent to the contract because the miners actually will just include the fraud proofs themselves. They have no incentive to accept the fraud proofs being sent from users. And it's also racy, if multiple users are trying to submit fraud proofs at the same time, it will result in a priority gas auction. And only one of them will go through and it will result in wasted gas on a reversion. So I do think that the optimal strategy is for miners to censor users sending fraud proofs and just include them themselves.

James (00:35:51):
Unless the miner is the one that committed fraud. The outcome I feel like is more likely, than miners censoring this fraud proof for seven days, is that the first time anyone tries to censor the fraud proof, people realize it and socially coordinate some fix. Ethereum has in the past and I think in the future will continue to show a willingness to socially coordinate to fix issues like this.

Ben (00:36:19):
Absolutely agreed. That's definitely our philosophy here too. And I think a very important note here on this point is this is something that makes parameterization really important. So we've had a lot of people a bit aghast by our one week fraud proof window. People always say, "Oh, my goodness, a week to confirm the fraud proof transaction. That's crazy. Even I with not very good usage of gas price can get my transaction confirmed within a day." And what they have to understand is that this length of time isn't there for the normal case of Ethereum operation. It's for the case when Ethereum starts having censorship, to give the Ethereum community time to be able to socially coordinate. Because if you have that window beyond the order of hours, I agree with you, James, we're definitely going to have an incredibly agile Ethereum for at least a little bit longer, but I'm not optimistic on the order of hours. So it's definitely very important, I think, to design with that in mind.

James (00:37:19):
I think I've had John Adler tell me before that, this social coordination is a critical part of the rollup security model. That it's not just a nice feature, that it is the fallback, is that the Optimistic period is long enough to give time for social coordination in the worst case scenario.

Ben (00:37:40):
That's a pretty interesting take. I think I would tend to agree with it, as Ethereum stands now. Hopefully we can improve our L1's to make censorship harder, with basically fancier execution models on L1. So maybe if we get to the point where we commit revealing or doing some threshold encryption stuff, maybe then it's going to get harder. And we can say other things.

James (00:38:01):
Yeah. Maybe in 2026 or 2027.

Ben (00:38:05):
Well, by then the zkRollup EVMs will be about to be out.

Anna (00:38:08):
Ooh, I feel like there's some snaps happening in there. This actually does bring up another topic that I wanted to dig into with you guys, which is the Eth2 landscape, what it would look like with rollups. I've talked about this with actually all of the rollup projects that I've been on so far.

James (00:38:28):
The centric roadmap...

Anna (00:38:28):
Is that what you're calling it? Centric?

James (00:38:31):
The rollup-centric roadmap.

Anna (00:38:32):
The rollup-centric roadmap. Indeed. Do you almost see Eth2, if Eth2 comes out, then the rollup model actually is less valuable? Or are you like, "No, it will for sure stay on." Tell me why. Tell me your thinking.

Mark (00:38:47):
In Eth2, at least from my understanding of Eth2, there's really no execution model defined for user transactions. What Eth2 provides is a large throughput of a consensus over data. That's exactly what our rollup needs to scale, it needs data that is available and agreed upon.

James (00:39:13):
You're saying that since the Eth2 team has backed off from plans for execution on the shards, it looks like the shards are ideally suited for what a rollup needs. A rollup needs data availability, the shards provide tons of it. A rollup doesn't need very much execution in any happy path. And so it is okay to have just one EVM shard, managing a rollup that uses all of the other 60 something shards.

Mark (00:39:46):
Exactly. And there's actually an Ethereum scaling hackathon coming up that. There's a project called Rayonism and anybody that's interested in contributing, the stretch goal is to try to get Optimism running on the Eth2 sharded testnet by the end of the hackathon.

Anna (00:40:05):
What was the name of the project? Sorry, can you just say that again?

Mark (00:40:08):
Rayonism. I can share a link. It is something that proto put together and maybe we can put it in a link at the show notes or something.

James (00:40:17):
So you'd have to do kind of a prototype merge and then do a rollup from there?

Mark (00:40:22):
Exactly.

Anna (00:40:24):
One question I have here is, so far we've been talking a lot about the Optimistic Rollup construction, but where's Optimism unique in that? What we've described like the week-long fraud proof window, the way that the ORU communicates with the base chain, all of this. Is there a distinction between the Optimism construction and some of these other Optimistic Rollups that you can hint at or share?

Ben (00:40:50):
Definitely a lot of the concepts that we've been going over are pretty applicable to a lot of different rollup designs. We've been speaking in very generic terms. We didn't get to go over my favorite rollup design, which is a rollup that computes the Fibonacci sequence, but that's for another day. Anyway, a lot of the concepts we've been talking about applied to a lot of things. Now, different projects have different parameterization and maybe different choices within that. I think one of the things that stands out with Optimism is one of our central goals is to stay with Ethereum as much as possible. So what that means is that the software that we maintain is all forks of other Ethereum software. So our node software is a fork of go-ethereum, the main Ethereum client, since our compiler, which is how you create a smart contract that can run on L2 is a very small fork of the Ethereum Solidity compiler. And I think this is super important for the ecosystem as a whole. Building layer 2 is hard enough without reinventing all entire other parts of the stack. And it also means that we can be better together. So it means that as we improve L1, we will improve L2 because they use the same code. Just as importantly, we can build things on layer 2 that are too risky to try on layer 1, but if we can prove them out on layer 2, then they can be adopted in layer 1. And that's something that I'm super excited for. There's this whole family of "Eth 1.X" that has all these incredible designs and ideas. And it's hard for the Ethereum community to coordinate around how to test these things out, whether to put them in the fork. It's going to be really cool to be able instead throw that into L2, test it out, validate that it works and then move on.

Anna (00:42:28):
You're talking about client software. When you said that, I thought, "Oh, maybe he's talking about dApps that need cheap gas prices to try out." But what you're talking about is actually like client software, like the forks, like the potential integrations into the base protocol.

Ben (00:42:44):
That's exactly right. So these are things like state rent, account abstractions, stateless execution, these are all fun buzzwords that you might hear in the Eth 1.X community. And that's what I'm talking about.

Anna (00:42:58):
Nice. I want to ask you a little bit about the software and does Optimism have a validator community? Is there validators, like there are on some of the other rollup or like coordinators, some sort of role. We talked about the node operator running basically the full node, including the Optimistic node, being able to do the fraud proofs. Is that the validator? I'm curious about that role.

Mark (00:43:20):
Yeah. So there's no validators in the system. There's what could be called a validator or verifier. The role of a verifier is to listen to L1. And it listens to all the transactions that are posted by the sequencer. And the sequencer, you can think of the sequencers, the right node, like the writer, it writes and extends the blockchain. It maintains the liveliness of the system. And users can send transactions directly to the sequencer, or they can send transactions through a special L1 contract, that the sequencer listens to and it pulls in those transactions and executes them.

Anna (00:44:02):
That's interesting. So that node operator then going back to the L1 fraud proof creator node operator, would they be running an Ethereum node, doing the verification side of things and then also run a verifying node, as, in a way, a separate blockchain?

Mark (00:44:18):
Yes, that is true. So doing the verification for a rollup is strictly a superset of the verification for just the L1 chain itself.

James (00:44:28):
Which implies that it's always more expensive than running an Ethereum node.

Mark (00:44:33):
Yes. That is the problem with scaling.

Anna (00:44:38):
And is the verifying client software, is that, Ben, what you were talking about? Like that's where you would test out new things? Because it's a fork of Geth, but it can do more and you can add to it?

Ben (00:44:50):
Yes, that's correct. I was really talking about the underlying software there, which applies both to this verifier role that Mark was talking about, as well as the sequencer role. In the same way that both miners and block explorers run the same core software, you would have to run the same software on both sides, cause everyone has to agree. But it's absolutely in that software package that I was talking about.

Anna (00:45:15):
Okay. So let's talk a little bit more about these sequencers. Mark, I know you did a talk at a recent event that I did, called "Mapping the L2 landscape", and you went deep on sequencers, but maybe you can share a little bit more even in this episode about what they are and how they work and maybe how people can think about them?

Mark (00:45:34):
Yeah, totally. So I think an interesting mental model that helps reason about sequencers is the sequencer is really, like I said before, it's the kind of node that's responsible for maintaining the liveliness of the system. And it's really the L1 contracts that the sequencer interacts with. You can think of those L1 contracts like the service level agreement with the sequencer. So when you are sending transactions to the sequencer, the sequencer can choose the ordering of these transactions, when it executes them. The sequencer is also responsible for taking those transactions and batching them up and sending them to L1. So designing a fair kind of sequencer is really important. You want to think about the ways that the sequencer is able to extract MEV from the system and create a mechanism to prevent them from extracting MEV in bad ways.

Anna (00:46:39):
This adds so much more complexity then. Like MEV on the Optimistic side, that's wild. Are you then following, are you working with the MEV Flashbots folks? Are you coordinating with them to keep that in your build?

Mark (00:46:54):
Yeah, I mean, I've definitely been chatting with them, picking their brains, seeing if they have any good ideas and how to design these mechanisms, because really we want to design something that is fair. We don't really want to create something that mirrors too closely the existing power structures and just magnify them. Because it seems like technology has a tendency of doing that.

Ben (00:47:20):
Definitely all the amazing folks behind Flashbots and Flash Boys and all this incredible research and now execution, it have definitely been with us in the community, as we've been building. Something that's been very fascinating for us to watch in Optimism is we put out this sequencing, MEV auction post over a year ago now. And since then the MEV has been a bit of the talk of the town. It's become more and more prominent and miners are actually starting to extract it much more readily.

Anna (00:47:50):
It's almost like they pointed out what the problem was in the dark forest. And now all of the monsters have turned towards and be like, "Oh, ha ha! Thank you for letting us know we can do this."

Ben (00:48:01):
Exactly. And I think one thing, I just think it's worth highlighting that as we design these sequencing mechanisms, this does not mean that the service level agreement, as Mark was saying, that you have with the sequencer should be that all of your transactions are broadcast in plain text, and the sequencer should be trying to extract as much value as it possibly can from those transactions. So we still do need to do things that limit the amount of MEV that can be extracted. There's responsibility of application developers to do that at the application level. And there's also responsibility at the infrastructure level to try to tackle that in more general ways. But even in a crazy sort of magic Moon Math world, where it's much, much harder to front run, the right access to the state is still fundamentally valuable, because even if you don't know what other transactions there are, because they're encrypted or obfuscated or whatever, there is still value in being able to put your transaction first, because there might be external things, outside of the system, that you can use to be profitable. I think one of the most fascinating things we're going to see with MEV, and I think we're going to see more experimentation with this more quickly on L2 than L1 is able to react, is where is the value in block production, when you don't know necessarily all the other users transactions in a block? We suspect that there still is a lot of value there.

Anna (00:49:26):
Cool. So there's currently a lot of conversation among DeFi projects who are looking to move either fully or partially onto L2. They're exploring this, there's a lot of grants going out, there's a lot of partnerships being announced. And I feel like there's a little bit of a battle for certain projects to join certain rollups. And I know with Optimism you've been relatively successful, as far as I know, in terms of commitments. But can you talk a little bit about that and how you can imagine even those DeFi protocols working across the different L2s?

Ben (00:49:59):
Oh, that is a great question. That is a big question, I love it. So a few things. So one starting note is that one of the things that drew us to Optimistic Rollups over Plasma was the ability to do smart contracts. And one of the incredibly aluring things about smart contracts is the ability to have these incredible money Legos. This is your composability, as it's normally called. What you were alluding to is the fact that composability is especially hard across, we call these "domains" internally, I think "chains" is the right word, across different rollups, but it could also apply to between a rollup and a state channel or between one L1 and another L1. Here at Optimism one of the things that we've been doing is designing for composability and interoperability. As a first-class citizen. We are much more focused on having one really good composable rollup before we start to examine the various challenges that come into breaking out different rollups horizontally. We have lots of fun thinking here, and there's lots of external community work being done as well on this front. But that's one of our focuses is be really good for money Legos to be all in the shared Optimistic Ethereum chain. From our perspective, I think that's one of the things that's gotten us a lot of successes. We have partnerships with folks like Synthetix who has been an amazing early client, and soon we'll be having Chainlink and Uniswap and Maker and blah, blah, blah. So I think that's one important component of this. As a researcher though, I do also love the cross-rollup part of this question. That's a super, super fun one. So you can do a variety of things here, but the thing to keep in mind is that when you are talking between one rollup and another, there's going to be a delay, fundamentally. Like the fact that these are two separate things basically has a requirement that you have some delay. And if you're a programmer, you can even think of this as an asynchronous, even like imagining async-await for blockchains. This is basically what we need. What is not very well developed in the crypto technology stack right now is what are the correct patterns for talking between rollups and chains in general? What do applications need to tell each other? The most common thing that they tell each other is a deposit and a withdrawal. But there are other things too. Maybe you want to tell the Uniswap V3 price to all of the other rollup chains. Because that's going to be your best price oracle, et cetera, et cetera. We're doing our best to give developers as much time as possible to figure out this really hard experience problems by having one really good chain to start. But there's going to be some incredibly interesting things that come up across rollups, as time goes on.

Anna (00:52:40):
You just mentioned these consistent patterns or almost standards of how these L2s or rollups should be communicating. Is there any work on that in the community? Is there any organization trying to push for this?

Ben (00:52:54):
There's this organization called Optimism, that's been doing a little work. Anna, you don't know this, but you're describing my past few days. Definitely, this is important. One of the things that we're pushing hard to standardize now is the deposit withdrawal interface, which, like I said, is the most common form of communication between chains, especially layered chains like rollups, is you deposit your money in from L1, you withdraw it out from L2 back to L1. And so defining how assets are moved between these chains is definitely a super important thing. More generally, there's like the question of communication and there's different components here. One problem is that you have, if you want to do it with zkRollups, then maybe you can't use all of the EVM goodies that Solidity gives you in terms of data types and things like this. But another one is that you can see some things are asynchronous calls. So you're basically only sending info one way. It's not like in Uniswap where you can do your flash loan and then do your thing with the flash loan and then return the money. Flash loans can't work the same way on L2 across chains, because loaning the money in one direction is going to take some time and then sending it back is going to take some time. But the whole point of a flash loan is it either happens in a flash or it doesn't. So it's a very challenging problem, very fascinating.

Anna (00:54:15):
It sounds like there would be no way to do a flash loan, cause there's multiple transaction jumps you'd have to do. It wouldn't be able to fit into the space it needs.

Ben (00:54:27):
You definitely can't do the exact same thing, but you can do some things. So for example, you can deposit into another rollup, but instead of depositing to your own address, you can deposit to an address on the other chain that will flash loan your money for a period of time and then automatically withdraw it back to you. So this doesn't give you quite the same thing as a flash loan, because there's capital lockup and it's a little different, but it does give you some semblance. So it's our suspicion that those sorts of design patterns, as cross-rollups stuff becomes more prevalent, is going to really, really evolve and be super fascinating.

Anna (00:55:04):
Interesting. Let's talk a little bit about bridges, because I mean, this is what you were talking about with some of these standardizations or some of these patterns that we we'd like to see, but I want to ask you, James, also your thoughts on this, because you're the bridge master, is that what they call you? King of bridges?

James (00:55:23):
No. But developing standard models for these sorts of things is what I work on all day.

Anna (00:55:32):
Is the bridge thinking bridging from L2s to other L2s or is it also bridging from L2s to potentially other chains that have EVM compatibility? Is this included in this thinking? Or is it really just between the two L2s right now?

James (00:55:49):
Well, you know, as I think you and Ben pointed out, there's not an organization standardizing these things, there are dozens of bridges and bridge communication systems being built in parallel. Most of them are only thinking about one-to-one relationships, the connection between Optimism and Ethereum, or the connection between xDai and BSC. There's basically no unified model for thes, there's no shared patterns. There's collisions in the address space all over the place with no way to distinguish which chain-given address is on. And then there's people like me and Ben working on different, but probably extremely similar standards for how domains talk to each other. So I think it's mostly just a mess right now and it's going to take a lot of time and a lot of people losing some of their money, in order to sort things out.

Anna (00:56:52):
There's no group, there's no bridge alliance. By the way, I find that those two words together funny. But is there any meta group that's trying to work on this problem?

James (00:57:02):
You know, I think most of the people building bridges right now are just trying to bring farmers over to their chain, there's not a long-term strategy for most of these.

Anna (00:57:11):
That's a bit of a shame.

James (00:57:13):
The exceptions are going to be the rollup projects and me of course, I'm really cool. The rollup projects are really the main people that are putting work into getting a single good working bridge model. And you see this from Arbitrum and Optimism have extremely similar designs and you see it on the zk side, too, all those work differently.

Anna (00:57:40):
Yeah. There was an announcement and there's a proposal for the Maker-Optimism bridge. I'm curious what that actually means? Is that a bridge from the dApp to an L2? Is that different from these other kinds of bridges?

Ben (00:57:58):
It's definitely a little different. I think we've encountered the second most overloaded term than transaction in the blockchain space, which is bridge. We did specifically call our token deposits and withdrawals a "gateway" just to add to the confusion, but at least not have something else be called the bridge.

James (00:58:17):
Oh, gateway is a bad word to use because it overloads with communication systems.

Ben (00:58:22):
That's true. Yeah. I thought I was depositing into my Windows 98 machine, in fact.

Anna (00:58:30):
Okay. This is so good, because I've actually been careful not to use the word "bridge" between the L1 and the L2. So this is where you're talking about the gateway. Okay. So tell me about the the overloaded term "bridges". I feel you.

Ben (00:58:44):
Cool. So in the context of the Maker thing that you're referring to... Well, we're actually getting --- at is one of the what we think,--- and is quickly evolving to be a very important primitive in cross-chain systems, which is basically doing things in advance on one chain, because you know that something is going to happen due to what happened on another chain, but has not happened yet because of the slowness of the communication from one chain to another. So the simplest example of this and what the Maker bridge is talking about is for withdrawals. So remember that we have to wait one week and if there's no fraud proof at the end of the week, that's considered a state update. What this means is that if you want to update the state to say, "I am withdrawing my money back to L1", once that transaction has been proposed, you must wait one week until it is credited to you on L1.

Anna (00:59:40):
Oh, I didn't realize that from your one week thing. I'm actually sorry, this is a total miss on my part. We're right at the end of the episode. And I'm only like, "Oh, so when you, you deposit money into the contract, you put it into the Optimistic Rollup, you hang out in there for a while and when you pull it out, you have to wait a week before you get it."

Ben (00:59:59):
Right. And when we say we put it in, what we mean is we lock it up in a smart contract on L1 that says, "I am deposited funds. I will not be released unless I see a valid withdrawal." And the only way for it to know about a valid withdrawal is if it sees one that had the fraud proof window expired with no fraud proofs.

Anna (01:00:20):
Okay. And that's a week. Got it.

Ben (01:00:21):
And that's a week. We think that that should be parameterized at a week. So of course the notable thing here is during that week, there's no question to any of the other participants in the ecosystem as to whether or not that is your withdrawal. People know immediately, basically. We call this "subjective finality". Your verifier generates the checkpoint and you know, that you're good. But the point is that there's no way for the L1 chain to magically know if we're good. So the L1 chain always has to wait. So what this gets at is to, what we call sometimes, it's called "fast exits fast withdrawals", there's a lot of different terms. But basically the idea is instead of withdrawing your money to yourself, what if instead, you will draw your money to a contract that says, "Hey, if someone paid 99% of this withdrawal to me immediately, they can get the hundred percent when it arrives and I'll give them that 1% fee". And you're kind of selling your withdrawal in advance. In fact, in Plasma, in early versions of this, we actually realized that that could be represented as an NFT. We've since realized that that's overloaded. And thank God, we're not contributing to the NFT hype now. But that's sort of what's going on. There's a lot of designs there, I can tie it back to the Maker one in particular, but I can pause for questions too.

Anna (01:01:41):
No, this is interesting. So this is the idea that you'd basically pay a small fee to get your money out quicker. From a user's perspective, you're like, "I don't have to wait the week".

Ben (01:01:51):
Exactly right.

Anna (01:01:52):
Is there a fee when you're using the Optimistic Rollup as well? Is there a fee going in and then there'd be another fee coming out?

Ben (01:01:59):
You definitely have to have fees on any blockchain system pretty much that has abundant amount of computation, because you have to make sure that people don't spam the chain for free. So you do have fees. If you crunch the numbers on one week lockup versus the interest rates that we're seeing elsewhere, it seems pretty likely that those fees will be quite low to get your money in and out. One other interesting note, I don't see it talked about as much in the fast exits world, but I think it's a very interesting point, is that we often think about markets for exits for these withdrawals because they take so long. And we think of some liquidity provider that are serving that role. One interesting thing that I think we may see in the future, as the infrastructure gets more built out, is there's actually a very natural coincidence of wants between people withdrawing and people depositing. So you can actually imagine a rollup where the same volume of people are depositing as are exiting. And instead of any actual deposits or exits occurring, those two parties will simply trade their L1 and L2 assets for each other repeatedly. So you might even have this world where people are virtually moving in and out of the rollup, but in practice they're just trading assets with people who want to do the other action.

Anna (01:03:17):
In an L1 smart contract, basically.

Ben (01:03:19):
Exactly right.

Anna (01:03:21):
Let's walk through what the Maker-Optimism bridge would actually look like though. So this is a very specific proposal where you would, I guess, you'd deposit — Maker where you mint DAI, basically — I'm curious, how would this work. Would you deposit on the L1 and mint DAI in the Optimistic Rollup? Is that what it would look like?

Ben (01:03:42):
First of all, the Maker team is amazing and they've been doing some awesome work, major shoutout. I do not want to speak to their roadmap unduly, so I can share what I think is going on, I want a caveat with subject to change, but I have a good sense when talking with them. So I have a good sense of what the proposal is in its current form. Basically the core realization is that a withdrawal in progress could make an extremely good collateral for MKR on layer 1. Because it's very clear if you know the state of the rollup, what this asset is and what it's going to be worth. And because of the longer-term nature of Maker liquidations and things like that, that week is actually a lot more reasonable of a requirement within that framing. And Maker also has an Oracle that is used to basically update the price of DAI, for example, and other components. And so, very interestingly, what we can do without building much additional trust assumption into the system is have that oracle be an oracle for upcoming withdrawals and basically credit them and use those to mint DAI. So that is, to my understanding, the current proposal is you still do it on layer 1, but you use a collateral that is a layer 2 asset that is in the process of being withdrawn.

Anna (01:05:02):
Interesting.

James (01:05:02):
I do want to push back on the idea that this is not very much of an additional trust assumption, because it is a really interesting idea, but it has the side effect of opting every DAI holder into this security system and to making the stability of DAI now dependent on proper function of the Optimism contracts and withdrawals. And it has an additional side effect, which is that it expands the power of the Maker Oracle, where previously the Oracle affects all vaults and all users equally, now it will affect users individually at its discretion. So it is a really interesting system, just it does have significant security impacts and new trust assumptions for the Maker system.

Ben (01:05:53):
That's definitely a good point, James, you're a great grounding force in these sorts of discussions. So I definitely agree. I do think that the design that they're choosing though is actually I think pretty reasonable and pragmatic. A few notes. One note is that if the assumption of the rollup is non-censorship by miners, there's already a lot of things on Maker that break, if the miners can censor already. So there are definitely, I think in general, what we're going to see is crazier and crazier trust models and assumptions being pushed, as we enter this sort of multi-chain universe that is very rapidly expanding in front of us. I personally like the trade-offs that Maker makes, I think they're very, very interesting.

Anna (01:06:46):
Cool. So it sounds a little bit like... This is also maybe questions for the Maker team for us to chat with them, because it's their proposal.

Ben (01:06:53):
I think they definitely would be best suited to answer those. And they might be a little upset if I answered too much for them.

Anna (01:07:01):
Fair enough. So anything else maybe on the roadmap that you want to share with our listeners before we wrap up?

Mark (01:07:08):
Yeah, totally. So right now we are on mainnet with Synthetix and it's a closed early mainnet launch. There is a contract whitelist, where if you want to deploy arbitrary contracts, you need to be added to this whitelist. And as we are iterating on the system and making it more stable, we're planning on adding more projects. And we have an upcoming release planned with Synthetix to enable Synthetix exchange. And this seems to be really interesting because Synthetix exchange is really, really expensive on L1. And on L2 it becomes way cheaper, because L2, you're really just charged for the size of the transactions and bytes because you don't need to pay all the gas for all the execution. And then over the next few months we're hoping to have a really rock-solid and stable system, and hopefully we can get Uniswap. They announced that they're planning on launching V3 on Optimism later this year.

Anna (01:08:20):
Yeah. I mean, that's going to be pretty wild. Do you feel ready?

Mark (01:08:24):
Oh yeah, definitely.

Ben (01:08:26):
Our knees are weakened, our palms are sweaty, but we are definitely ready. I do think we already made that joke once before.

James (01:08:34):
Those Synthetix on your chain already.

Ben (01:08:38):
Yeah. Code "spaghetti." I want to show one other, I want to show one last short-term upcoming milestone, which is the ETH Global, scaling Ethereum hackathon that is coming up. We are going full steam ahead and going to have some prizes and other awesome stuff. So check that out for more details. We're thinking of this as like the staging ground for our next batch of whitelisted deployments to mainnet. So that's going to be super exciting. We're going to have lots of fun stuff to keep everyone busy and, I'm sure, to keep us busy. So that's very exciting.

Anna (01:09:12):
Cool. All right. Well, I want to say thank you, Ben, Mark, for coming on the show to chat with me and James about all things Optimistic and Optimism.

Mark (01:09:23):
Thanks for having us.

Ben (01:09:25):
Absolutely. Thank you, guys. It was a pleasure.

Anna (01:09:29):
Cool. I want to say a big thank you to Andrey, the podcast producer, and Henrik, the podcast editor. And to our listeners, thanks for listening.