Unwrapping Optimism with Ben and Mark

Transcript

[Music] welcome to xero 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 roll-ups what is unique about optimism the challenges of optimistic roll-ups partnerships and more but before we start in i want to say thank you to this

week's sponsor leased authority leased 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 loopering mina and filecoin this may they will actually be releasing a white paper on zcaps or zero knowledge access passes zcaps 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 private storage will launch right after the white paper is released

also this coming summer the moon math 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 authorities newsletter to stay in touch and be notified of the release of the zcaps white paper private storage and the moon math 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 so this week james and i are here with ben and mark

from optimism builders are the first optimistic roll-up live on ethereum welcome ben and mark thank you thanks anna for having us and hello james welcome back hi anna hi ben hi mark it's good to see you all again hey james likewise 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'm kind of i want to hear yeah what's new with you oh yeah yeah totally handshake um 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 um 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 of companies building on it yet and i was always ethereum curious and um i had met ben carl and jing and the optimism team at conferences and i kind of wanted to hop into the ethereum space and kind of 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 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 kind of your background and that project but when did you join optimism um i believe it was last july or so and what are you doing there what's your what's your gig i'm a developer and i'm working on um basically death we maintain a fork of geth that kind of runs as a sequencer or verifier and i'm also doing some devops work kind of our deployments and making sure that it's stable

running in the cloud cool how big is the dev team right now oh it's pretty small it's probably around um 10 or so people okay in a team that size you actually get to do a lot i guess you get to like wear many hats yes yes one of my favorite parts 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 yeah hi what's up val um i am a i'm a total uh etherean by heart um i discovered in like early 2017 this thing called ethereum and it basically seemed 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 the 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 just realized that there was a whole world of even more practical scaling opportunities that was layer two and that got me really excited because i knew that we could actually implement these things on ethereum today and that was super exciting that team that you just mentioned i understand optimism is kind of like an extension of the plasma

project or the plasma team is that the case was that kind of like the group that you're talking about originally in the in the foundation yeah for the most part um i think usually when we use plasma that's referring to like a class of layer two 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 and we did do a lot of 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 was smart contracts because that's what people are using and once we sort of started understand this data availability solution that is the roll-up

we started to realize hey there's a real thing here we could actually build this and so we we started optimism cool all right let's start talking about the optimistic roll-up we've had already on the show this month two projects from z like who created zk roll ups and i think we are like i think our audience is very well versed in the zk roll of space when it comes to optimistic roll up i have done i think one episode on it with john adler maybe six to eight months ago but yeah i think it's worth it to redefine optimistic roll up kind of what is it and maybe like for me i'm curious how is it specifically different from plasma or an evolution from that um i would love to talk about this okay

okay so i think i think one great framing that we've been able to evolve by now in the layer two scaling space which is super useful is basically this like two by two grid optimistic and zk you know on the left and the right and then roll up and plasma on the top or the bottom and sometimes that zk plasma is called volidium now that's a fancy new term that the 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 roll-up the difference is in a plasma

you commit a block route 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 opt-chain data providers that say that they will make the 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 roll up where you 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

like this is l1 nodes l1 nodes can retrieve this information that's right yep and very very very important point yeah absolutely l1 nodes so that sort of corresponds to where the data lives in each of these cases either you put it all into a censorship resistant form up front or you keep it off and wait for maybe there to be a dispute or you just trust someone is holding on to it off chain the two axes here are where does the data live on l1 or somewhere else and then how do you achieve confidence in the data is are you using validity proofs uh like a zero knowledge proof system or using fraud proofs which would make it an optimistic system exactly right that's exactly right james

yep 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 mouth flavor it's actually the succinctness that that is the important part right because that's the cygnus lets us spend much less gas to verify a big block of execution on on l1 i mean like 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 like bring them on chain in a very with a very small amount of data the question i have here is like lightning does something sort of similar this idea that you like

are able to do this batch of transactions off-chain so what is the big distinction between something like lightning and something like these roll-ups or plasma 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 right 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 sort of all of those solutions including state channels like the lightning network et cetera 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 sort of like 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 right on the other hand state channels require that the participant 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 roll-up 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

you can kind of think of it as another trade-off axis is uh 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 roll-ups we really really want these to have uh flexible participation we want people to be able to drop in and out over time and that means that they need to have a bunch more a succession of on-chain commitments to the state uh they need to have many more than two commitments on chain yeah what are the practical limitations

on transaction throughput in a plasma or roll-up compared to a state channel which you said can have you know you know essentially infinite transactions infinite throughput that's a great question so i think there's a bit of a spectrum here and it probably goes like somewhere from roll up to plasma to channel in terms of the participant said 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 platinum with that with still an unlimited participant set on the other hand with a rollup optimistic or otherwise you have to you do have to put those transactions into some you know 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 that limitation further got it so uh is the limiting factor there the amount of you know layer one chain space that your uh layer two system consumes that is the ultimate upper bound absolutely so where a state channel only touches the main chain

two times uh 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 exactly right and like is this the same for zk roll ups like this is just roll ups consistently across the board in fact the what you are doing with that data is you are rolling it up got it a ridiculous a ridiculous name but a great one i think it's a pretty good one i mean i don't know i does it come from fruit roll-ups is that like why people got excited about it or was there like 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 one difference between a zero knowledge

roll up and the optimistic roll-up that i think is worth uh talking about is just an optimistic roll-up will actually post the transactions themselves and all of the state transitions have to be executed whereas with a zero knowledge roll up they can include a zero knowledge proof and the state diff ah do you have does that sort of mean like you have to settle in a way in the optimistic one or am i missing am i missing exactly the the part here this is similar to one of the main differences between like uh bitcoin and ethereum is in bitcoin you have an implicit state and

explicit state transitions a transaction where in ethereum you have the opposite you have an explicit state the state tree and implicit state transitions you know whatever the contract execution does uh it sounds like what you're saying is that optimistic roll-ups have this you know and optimism has this implicit state transition where zk rollups have an explicit state transition yes cool this is going a little deeper into the distinction between optimistic and ck than i feel like i've done before so thank you we're playing taxonomist it's fun so optimism is the project that both of you are working on

but are you the only optimistic roll-up in town or are there others is this like a concept that is like from this org or is it something that's actually being replicated with different teams yeah there's definitely other projects out there working on optimistic roll-ups i know fuel is doing something interesting with a utxo based optimistic roll-up i'm kind of looking forward to whenever they come out with kind of their more complex scripting language that they've been talking about their uh prototypes are interesting are there any others maybe that we're not like because we did we did have uh fuel on but anyone else there's a there's a few others arbitram is definitely another another big one which are doing some

super cool interesting things um 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 cool i mean there's also i know that there's like zk operu which i think that's how you say it and that's like a combo zk optimistic has the optimism team like considered including zero knowledge proof somewhere in there in their construction even if it's not a zk roll up absolutely so zero knowledge for one for privacy is a great match for um for optimistic roll-ups 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 like super important one related to this in fact building a zk roll up does not give you privacy just because there's zk in there this is what i alluded to before in the simpler way you do the zk part for the speed the verification but you're not actually necessarily hiding what's going on got it the only one that does claim to do privacy right now is aztecs right that's right and they're actually the episode right before this one huh in some of the previous episodes i did on zk roll ups we did actually talk about the criticisms of optimistic roll up 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 yeah how you kind of treat these questions how you think about them so one of the big points is this distinction between the fraud proof and the ck reproof uh with fraud proofs as i've understood it there's almost like a dispute mechanism that would happen after the fact and that like since that takes so long the idea that you'd actually be able to like resolve a dispute in time to be able to kind of like adjust any sort of transaction it's too late that's kind of the the thinking that i feel has been like at least that's that's what i took away from it now i'm curious how you think about that or how you how you take that criticism 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 parameterized to be one week and basically the absence of a fraud proof will determine the validity of the transaction in its corresponding state route so if there is an absence what does that mean so if no fraud proof is submitted then the transaction can be considered finalized okay because anybody can make a fraud proof right yes uh so if nobody does that probably means there was no fraud

yes assuming that everyone can access the data and everyone can compute the state transitions so fraud proof is it's proof of fraud having been committed yes what does that even look like what is it fraud proof do you go like this is wrong for sure like what what is it you do indeed prove things very explicitly wrong it's a great question so in general like mark said the 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 okay instead you basically take the hash that came before you provide some merkle branches and you run the transaction against those branches but like where is this data even coming from is it two hashes that you're basically showing one that is like already proven and then the next one where are they ooh they they live on ethereum so like you you actually interestingly can roll you roll them up as well so 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 proof fraud you actually you know undo that hash and you provide a proof down to a very particular element that you disagree about but is that like hash the first hash and the second hash what's in between them is it like many transactions or is it like a single transaction it sounds like it's many like it's like almost like these these batches that have been written on chain it's definitely a challenging one and what you're getting at is the uh consistent overloading of the word transaction in the blockchain yeah so it depends what you mean right we call that data type of transaction in our

system but that could actually contain several like user transactions which in ethereum we sometimes call a meta transaction although that that is perhaps a bit devoid of of meaning on its own so this is interesting so this this word transaction i've also this has come up before where like also transactions in a zk concept is different and like so transactions the way i've been using them the way i'm asking is actually like many transactions between different users like doing transfers within the optimistic roll-up like i'm imagining that you're able to do many of those and then that becomes like batched as a maybe it's mercallized and it's hashed all of those little transactions are individual leaves potentially is that

how it looks yep that's about right yep okay so then there's the hash and that hash gets written on chain like 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 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 route that was sent by the sequencer just mark you're using the word transaction again here like kind of unclearly now i'm not sure which one you're talking about so we just define these two types of transactions right there's the ones the users like sending funds between each other or maybe it's a smart contract doing something and then there's this other transaction maybe we just kind of stay there for a second

so 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 you know 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 you know 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 you know 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 one 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 yes if it's correct then there was no fraud uh if the layer one produces a different checkpoint 58 then there was fraud okay is it a contract happening on l1 that's actually rerunning something like is that is there almost like a verifier type setup yep and one of the things i think is really cool about optimism and arbitrary 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 so ben i want to go back to this question of like i want to bring the word transaction back because i still want to understand between let's use that term maybe checkpoints like are there many transactions within that those checkpoints like user transactions that that's what i mean like sending of funds or like contracts being doing something the the answer the answer is yes or maybe a more nuanced question is how many right and and in ethereum each transaction has this measure of how computationally expensive it is called gas right so sending money to someone not a lot of gas

doing you know 50 flash loan swap magic things is 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 interesting okay is the checkpointing actually happening on the roll-up side like i i think of these roll-ups as also like they're stand-alone blockchains there's like things being your blocks in a way or something being created a record being created also on them so are those checkpoints on the side of the roll-up or are those checkpoints

like i realize it's being verified on chain but like where 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 we're proposed if you see a disagreement between what you computed locally which you know is correct because you did it and it's your computer and that's different from what was proposed then you go into the you know 57 to 58 thing that that james was talking about let's then 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 there's conceptually like 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 like the pre-execution phase when we think about this 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 carroll and dave okay because these 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 oh wow on l1 this is on l1 okay okay exactly and so we have something called the ovm that enables this but this 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 right because you're sort of like you're running like a you know a little slice of l2 execution on l1 and evm is really not you know not really built for that so that's like a really that was a really fun you know problem to solve well but that's what you have to do right you make sure that all the data is

there you make sure that you have a way to deterministically run the transaction against that pre-state and so that's that's phase two you execute you know in in our example you subtract from alice's balance add to bob's balance you subtract from carol's balance add to dave's balance now that you have executed that transaction now 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 okay and you've proven

fraud so uh you have these kind of full nodes that are involved in the roll-up that are executing these blocks and looking for fraud and it sounds like ideally the layer one when it uh is validating a fraud proof does the exact same thing uh it goes from checkpoint to checkpoint and executes everything in between to make sure it's right uh is that is that in the correct neighborhood yeah absolutely is the expectation here that like that will never happen like are you trying to test the system to see if that even could happen like i just picture like since that mechanism is set up

is it set up purely to be like you can try but it won't work because there's a fraud thing that that's sort of the question i have like will people actually do this like will there be fraud i mean obviously you don't want fraud yeah ideally there's no fraud 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 because we're gonna catch you and that is encouraging people to stay in line yep it's the most important code that should never run exactly yeah exactly right it's like it's uh i think i called it in some presentation uh mad mutually assured dispution got it um this is a really interesting

one it this is a 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 like a common example of this is all of the people running a full node on ethereum that are not miners right 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 minor is for that right and so there's all sorts of these fascinating subjective reasons that people have for doing different things in the system i i think it's pretty likely that the you know mechanics of those of those incentives work out so that there's not 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 that actually speaks to this is sort of 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 this is interesting right and the answer is like because they want to know the state of the chain themselves right like there's lots of people that run their nodes and choose not out source that information because they want this notion of security

and so this applies in a roll-up too is this assuming like so you're a dap that relies on you you have your own node and you're running a node and you maybe interact with like you move something with optimism this is what i'm trying to picture like a use case for somebody running this node who doesn't get paid ever because they never find fraud and they are kind of like doing some but like some core infrastructure stuff like what where is their benefit for them it's like they want to work on both they want to like 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 they don't care about

incentives exactly right exactly right so your block explorers are always going to be running these notes right there's you know something that we might touch on later this notion of fast exits sort of purchasing yet yet to be withdrawn funds those people want to run a node crazy nerds like me and mark run ethereum notes you know et cetera et cetera 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 i don't know if that's exactly do you know this expression does this mean anything to you yes well in a layer one consensus you have an an m of n 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 roll-up is actually that you have a one-of-n honesty assumption it only takes one honest person to prove fraud to secure the chain interesting you you still can't escape the m of n uh honesty assumption of the underlying chain though so you're layering another assumption on top of that that is true it is um like the weakest link um because you basically inherit the l1 security because um even if a miner let's say that miners are trying to censor the fraud proof and um 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 is still kind of it comes back to like the 51 um that's uh really interesting because it sounds like you know if you have this coalition of minors on the layer one what happens to optimistic roll-ups is that they have this um they have a improper state transition potentially is that right that would definitely be the outcome in the event of a 51 attack and for a zk roll up the outcome of a 51 attack is that it has you know a liveness failure that the miners decide that that uh roll-up stops running for as long as their coalition lasts

so the interesting thing about an optimistic roll-up being censored is that i 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 proof being sent from users and it's also racy if multiple users are trying to submit fraud proofs at the same time it kind of will result in a priority gas auction and only one of them will go through and it will result in you know wasted gas and a reversion so i do think

that the optimal strategy is for miners to censor users sending fraud proofs and just include them themselves 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 you know realize it and socially coordinate some fix ethereum has uh you know in the past and i think in the future will continue to show a willingness to socially coordinate to fix issues like this 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 um so we 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 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 i have to understand is that this 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 you know hours i agree with you james we're definitely gonna have an

incredibly agile you know ethereum for at least a little bit longer but i'm not optimistic on the order of hours so it's definitely it's definitely very important i think to design with that in mind i think i've had uh 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 that's a 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 to make censorship harder

you know with basically fancier execution models on l1 so maybe if we get to the point where we're commit revealing or doing some you know threshold encryption stuff maybe then it's going to get harder and we can we can say other things yeah maybe in 2026 or 2027 well by then the the zk roll up evms will be about to be out ooh i feel like there's some snaps happening in there um 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 roll-ups i've talked about this with actually all of the roll-up projects that i've had on centric roadmap is that is that what you're calling it

centric the roll-up centric road map the the roll-up centric road map indeed do you almost see eth2 if eth2 comes out then the roll-up model actually is less valuable or are you like no it will for sure stay on okay tell me why tell me your tell me what you're thinking in in eth2 at least from my understanding of eth2 there's there's really no execution model defined for user transactions what eth2 provides is a large throughput of consensus over data that's exactly what our roll-up needs to scale is it needs data that is available and agreed upon you're saying that since

the eth2 team has backed off from plans for uh execution on the shards you know it kind of looks like the shards are ideally suited for what a roll-up needs a roll-up needs state availability the shards provide tons of it a roll-up doesn't need very much um execution and you know in any like happy path and so it is okay to have just one you know evm shard managing a roll up that uses all of the other uh 60-something shards exactly and there's actually an ethereum scaling hackathon coming up that um there's a project called rainism and anybody that's interested in

contributing the stretch goal is to try to get optimism running on the e2 sharded test net by the end of the hackathon what was the name of the project sorry can you just say that could share a link it was something that proto put together and um yeah we can maybe we could put it in like the show notes or something so you'd have to do kind of a prototype merge and then uh do a roll up from there yup exactly one question i have here is like so so far we've been talking a lot about like the optimistic roll-up construction but like where's optimism unique in that like is is what we've described like the week-long fraud-proof window the the way that these the oru communicates with the base chain

like all of this like is there a distinction between the optimism construction and some of these other optimistic roll-ups that you can hint at or share so definitely a lot of the concepts that we've been going over are pretty applicable to a lot of different roll-up designs right we've been speaking in very generic terms we didn't get to go over my favorite roll-up design which is a roll-up that computes the fibonacci sequence but that's for another day anyway a lot of the concepts we've been talking about apply 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 domain ethereum client things like our compiler which is how you you create a smart contract that can run in l2 is a very small fork of the ethereum solidity compiler and i think this is super important for the ecosystem as a whole like building layer two 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 got it just as importantly we can build things on layer 2 that are too risky to try on layer one but if we can prove them out on layer

two then they can be adopted in layer one and that's something that i'm super excited for there's this whole family of quote eth one point 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 to instead throw that into l2 test it out validate it that works and then move on you're talking about like client software when you said that i thought oh maybe he's talking about dapps that need cheap gas prices to try out but actually what you're talking about is actually like client software like the the forks like the potential integrations into the base protocol that's exactly right yeah so things these are things like state rent

account abstraction stateless execution these are all fun buzzwords that you might hear in the eth one point x community and that's what i'm talking about yeah nice i want to ask you a little bit about this software and like does optimism have a validator community like is there validators like there are on some of the other roll up or like coordinators some sort of role we talked about the node operator running basically like the full node including the optimistic node being able to do the fraud proofs is that the validator like i'm curious about that role 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 is kind of 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 that's interesting so this is but like that node operator then like going back to the l1 fraud proof creator node operator would they be running like an ethereum node doing the verification side of

things and then also run a verifying node in a way a separate blockchain yes that is true okay yeah so um doing the verification for a roll up is strictly a super set of the verification for just the l1 chain itself which implies that it's always more expensive than running an ethereum node yes that is the problem with scaling and is the 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 sort of yes that's correct i was really talking about though

the underlying software there which applies both to this verifier role that was mark was talking about as well as the sequencer role like the blocks i see it's both right in the same way that uh in the same way that both minors and block explorers run the same core software you you would have to run the same software on both sides right because everyone has to agree but it's absolutely in that software package that i was talking about yeah okay so let's talk a little bit more about these sequencers mark i know you you did a talk at a recent event that i did called mapping the l2 landscape and we 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 yeah totally so um 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 um the sequencer can kind of choose the ordering of these transactions when it when it executes them you know the sequencer is like also responsible for

taking those transactions and batching them up and sending them to l1 right so designing a fair kind of sequencer is really important you want to kind of think about the ways that the sequencer is able to extract mev from the system and kind of create a mechanism to prevent them from extracting mev in bad ways this adds so much more complexity than like muv on the optimistic side that's that's wild are you then following like are you working with the mev flashbots folks are you like coordinating with them to like keep that kind of in your build yeah i mean um i've definitely been chatting with them

kind of picking their brains seeing if they have any good ideas and kind of 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 like the existing power structures and just like magnify them because it seems like technology has the tendency of doing that definitely all the amazing folks behind flashbots and flash boys and all this incredible research and now execution have definitely been like with us in the community as we've been building something that's been very fascinating for us to watch at optimism is we put out this like sequencing like mev auction post like over a year ago now and since

then the like mev has been a bit of the talk of the town it's been like become more and more prominent and miners are actually starting to extract it much more readily it's almost like they they pointed out what the problem was in the dark forest and now all of the monsters have turned towards and been like oh ha ha thank you for letting us know we can do this exactly exactly and i think one thing uh i just think it's worth highlighting that as you 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 your transactions are broadcast uh 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 meb 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 uh sort of like magic moon math world where it's much much harder to like 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 to react is where is the value in block production when you don't know necessarily all the other users transactions in a block i we suspect that there still is a lot of value there cool so there's currently a lot of conversation among d5 projects who are looking to move either fully or partially onto l2 like 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 kind 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 like how you can kind of imagine even those those defy protocols working across the the different l2s oh that is that is a great question that is 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 roll-ups over plasma was the ability to do smart contracts and one of the incredibly alluring things about smart contracts is the ability to have these incredible money legos right this is like your composability as it's as it's normally called what you are 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 roll-ups that could but it could also apply to you know between a roll-up 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 like 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 roll-ups 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 i i think from our perspective i think that's one of the things that's gotten us a lot of success is we have you know partnerships with you know folks like synthetics who's been an amazing early client and soon we'll be you know having chain link and uniswap and maker and blah blah blah so i think that's that's one important component of this as a researcher though i do also love the cross roll up part of this question right 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 roll up and another there's going to be a delay fundamentally right like the fact that these are two separate things basically has a requirement that you have some delay and if you're if you're

like a programmer you couldn't even think of this as like an asynchronous you know like even like imagine an async await for blockchains this is basically what we need what is not very well developed uh in the crypto technology stack right now is what are the correct patterns for talking between roll-ups and chains in general what do applications need to tell each other right like the most common thing that they tell each other is a deposit and a withdrawal right but there are other things too maybe you want to accord you know tell the uniswap v3 price to all of the other roll-up chains right because that's going to be your best price oracle et cetera et cetera we're doing our best to like give developers as much time as possible to figure out those 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 yeah you just mentioned this sort of like consistent patterns or like almost standards of how these l2s or rollups should be communicating is there any work on that in the community is there any sort of organization trying to push for this uh there's this organization called optimism that's been doing a little work anna you don't know this but you're like describing my my past few days oh um definitely definitely this is important one of the things that we're pushing uh 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

roll-ups is you deposit your money in from l1 you withdraw it out from l2 back to l1 right 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 right one problem is that you have if you want to do with zk robs then maybe you can't use all of the evm goodies that you know solidity gives you for in terms of data types and things like this but another one is that they you can see these are asynchronous calls so you're basically only sending info one way it's not like in uniswap where you can like do your flash loan and then do your thing with the flash loan and then return the money flashlights don't 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 like it either happens in a flash or it doesn't right so it's very very challenging problems very fascinating there's no way it sounds like there would be no way to do a flash loan if you have because there's multiple transaction jumps you'd have to do right like it wouldn't be right exactly able to fit into the space it needs you definitely can't do the exact same thing but you can do something 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 like capital lock up and it's a little different but it does give you some semblance right so it's our suspicion that those sorts of design patterns as cross roll-ups stuff becomes more prevalent is going to really really evolve and be super fascinating 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 would like to see but and i want to kind of ask you james to also your thoughts on this because you're the bridge master is that what they call you

no king of bridges but no uh developing standard models for these sorts of things is what i work on all day yeah is the bridge thinking bridging from l2s to other l2s or is it also bridging from l2s to potentially like other chains that have evm compatibility is this included in this thinking is that or is it really just between the two l2s right now well uh you know as i think you and ben kind of pointed out there's not an organization standardizing these things uh there are dozens of bridges and bridge you know communication systems being built in parallel most of them are only thinking about you

know one-to-one relationships the connection between optimism and ethereum or the connection between uh xdi and bsc there's basically no unified model for these there's no shared patterns there's collisions in the address space all over the place with no way to distinguish which chain a given address is on and then you know there's people like me and ben working on different uh but probably extremely similar standards for how domains talk to each other so i 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

um in order to sort things out there's no group that there's no bridge alliance by the way i find that those two words together funny but is there is there any meta group that's trying to work on this problem you know i think most of the people building bridges right now are just trying to uh bring farmers over to their chain um there's not a long-term strategy for most of these that's a bit of a shame uh the exceptions are going to be you know the roll-up projects and uh you know me of course i'm really cool [Laughter] the roll-up projects are really the main people that are putting work into getting a single good working bridge model

um and you see this from you know arbitrarium and optimism have extremely similar designs and you know you see it on the zk side too all those those work differently yeah there's sort of an announcement or there's a proposal for the maker optimism bridge i'm curious what that actually means is that a bridge from the like a dap to an l2 is that different from the these other kinds of bridges it's definitely a little different i think we have 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 got it oh gateway is a bad word to use because it overloads with uh communication systems that's true if that's true yeah yeah i thought i was depositing into my windows 98 machine in fact [Laughter] okay but that this is so good because i 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 bridge the overloaded term bridges i i feel you cool so in the context of the maker thing that you're referring to what we're actually getting at is one of the what we think and is quickly evolving to be 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 okay so the simplest example of this and what the sort of maker bridge is talking about is for withdrawals so remember that we we have to wait one week and if there's no fraud proof at the end of the week that's considered you know a state update right 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 i actually oh i didn't realize that from your one week thing i actually sorry and this is a total miss on my part and we're right at the end of the episode and i'm only like oh so we when you you deposit money into the contract you put it into the optimistic roll up you hang out in there for a while when you pull it out you have to wait a week before you get it right and and when we say we put it in right 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 had the fraud proof

window expire with no fraud proofs okay and that's a week and that's and that's a week yeah we think that that should be parametrized in 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 like subjective finality right your verifier generates the checkpoint and you know that you're good but the point is that we have there's no way for the l1 chain to magically know if we're good so the l1 chain always has to wait yeah 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 it the hundred percent when it arrives and i'll give that you know i'll give them that one percent fee right and you're kind of like 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 we've since realized that that's overloaded and thank god we're not contributing to the nft hype now um but but that's sort of what's going on there's a lot of designs there i can tie back to the maker maker one in particular but i can pause for questions too

no this is this is interesting so this is the idea that like you would basically pay a small fee to get your money out quicker right like from a user's perspective you're like i don't have to wait the week exactly right is there a fee when you're using the optimistic roll-up as well like is there a fee going in and then there'd be another fee coming out you definitely have to have fees on any blockchain system pretty much that has a bounded amount of computation because you have to make sure that people don't spam the chain for free so you do have you do have fees if you crunch the numbers on one week lockup versus like the interest rates that we're seeing elsewhere it seems pretty likely that those fees will be quite low to get your to get your money in and out

okay one other interesting note i don't see talked about as much in the fast exits world but i think is 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 there 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 like virtually moving in and out of the rollout but in practice they're just trading assets with people who want to do the other action in an l1 smart contract basically like within there yeah yeah let's kind of walk through what the maker optimism bridge would actually look like though so this is like a very specific proposal where you would i guess you'd deposit like maker where you know you mint die basically i'm kind of curious like how would this work would you deposit on the l1 and mint die in the optimistic roll-up is that kind of what what it would look like or first of all the maker team is amazing and they've been doing some awesome work major shouts out i do not want to speak

um to their roadmap unduly so i can share i can share what what i think is going on i want a caveat with subject to change but i can have a good sense we talk with them so i have a good sense of what the what the proposal is in its current form basically the the core realization is that a withdrawal in progress could make an extremely good collateral for an mkr on layer one because it's very clear if you know the state of the state of the roll-up that what this asset is and what it's going to be worth and because of the sort of you know 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 dye 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 die so that is to my understanding the current 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 interesting 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 you know opting every die holder into this security system and making the stability of die 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 uh 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 it just it does have significant security impacts and you know new trust assumptions for the maker

system that's definitely a good point james you are you're a great you're a great grounding force in these sorts of discussions so i definitely agree um i do think that the design that they're choosing though is is actually i think pretty reasonable and pragmatic like a few notes one one note is that if the assumption of the roll up is non-censorship by minors that's actually something like there's already a lot of things on maker that break if the miners can censor right already so so hopefully that's not like that that's not like so oracle for example oh right yeah sure um so there are definitely i think in general what we're gonna see is crazier and crazier uh trust like models and assumptions being being

pushed as we enter this sort of multi-chain universe that is like very rapidly expanding in front of us um i really personally like the trade-offs that maker makes i think they're i think they're very very interesting 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 i think they definitely think they would be best suited to answer those and they might be a little upset if i answered too much for them fair enough so anything else maybe on the roadmap that you want to share with our listeners before we wrap up yeah totally so right now we are on mainnet with synthetics and it's kind of a kind of closed early mainnet launch

there is a kind of contract white list where if you want to deploy arbitrary contracts you need to kind of be added to this white list 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 synthetics to enable synthetics exchange and this is going to be really interesting because synthetics 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 in 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 on they announce that they're planning on launching v3 on optimism later this year yeah i mean that's going to be pretty wild do you feel ready yeah oh yeah definitely our knees are weak and our palms are sweaty but we are feeling ready i think we all i think do think we already made that joke once before there's synthetics on your chain already yeah codes code spaghetti um i want to show one other i want to show one last uh

short term upcoming milestone which is the youth global scaling ethereum hackathon that is coming up um we are we are going full steam ahead and gonna have some prizes and other awesome stuff so check check that out for more details we're thinking of this as like the staging ground for our next batch of like whitelisted deployments to mainnet so that's gonna be super exciting we're gonna have lots of fun stuff to keep everyone busy and sir i'm sure to keep us busy so that's very exciting cool all right well i wanna say thank you ben mark for coming on the show to chat with me and james about all things optimistic and optimism thanks for having us absolutely thank you guys it was a pleasure

cool i want to say a big thank you to andre the podcast producer and henrik the podcast editor and to our listeners thanks for [Music] listening