ZKPodcast: Diving into Arbitrum’s Optimistic Rollup

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 today james and i chat with stephen goldfeder and ed felton from arbitrom we dig deeper into the topic of optimistic rollups we learn about the history of the project and what makes it unique in the ecosystem but before we start in i want to tell you about the zk jobs board

a few weeks ago i held something called a zk jobs fair which was an awesome way for job seekers to connect with the best teams working on zk topics we did this on a gather.town hangout it was very social it was very fun now as part of the job fair i also put together the zk jobs board which is a list of all these available jobs in the zero knowledge space there are jobs in software development specifically in rust as well as applied cryptography and research jobs there are also a couple community and biz dev positions now i've added the link in the show notes you should be sure to check it out if you're currently looking for a new opportunity and also keep your eyes open for the next zk jobs fair it'd be super

cool to see you there i also want to take the time to thank this week's sponsor ave ave is an open source decentralized non-custodial liquidity protocol on ethereum with ave users can participate as depositors meaning they provide liquidity to earn a passive income they can also act as borrowers to borrow in an over-collateralized way or an collateralized way think one block liquidity flash loans given that we are currently doing a series of l2 focused episodes it makes sense to mention that ave has also deployed a new market on polygon sidechain this lets users pay much lower gas fees

assets can be transferred from ethereum with the polygon bridge and put to use on ave's polygon markets to learn about it check out the blog posts that i've added in the show notes and also visit the project at ave.com so thank you again ave for supporting the podcast now here is our interview with ed and steven so today james and i are chatting with stephen goldfeder and ed felton from arbitram welcome to the show guys thanks for having us thanks uh thanks for having us and hi james hi anna it's good to be here again so this is like i think this is the fourth episode in a series of episodes that we

seem to be doing on roll-ups over the last little while kind of an accidental series totally i mean i think about a month ago i did something called the like mapping the l2 landscape as an event as a zk session since then um i feel like this topic has become extremely relevant for the show so yeah i think with today's episode we're going to be looking at arbitram which is another roll up i guess it falls into and correct me if i'm wrong here but like more in the optimistic roll-up side of things that's correct but before we start in on all this i actually am really excited to have the two of you on the show it's the first time we meet and i would love to hear how kind of what your path to arbitrarium is

sure i guess i'll go first um since uh i was there at the very beginning of proto arbitram it goes back to actually the 2014 at that time i was teaching a course at princeton or i was helping teach a course at princeton about blockchain cryptocurrency technology and one of the topics we covered was smart contracts so it seemed pretty clear to a bunch of us that scaling was going to be a big issue for smart contracts and so we started thinking about what we could do about it um and long story short in the fall of 2014 a group of students in this princeton course did a joint course project building

a a very early version of arbitrage it was called arbitrary you can go on youtube actually and watch their course presentation and it's obviously student work but you can see really the germ of the ideas from the product there wow so that happened and a bit more research on the topic and then in 2015 in in spring of 2015 i got invited to go off and work on the white house staff and so i worked for president obama for almost two years which was when obviously arbitration was not so much on my mind during that time we had other things to worry about but in january of 2017 when the presidential transition happened i came back to princeton and one day uh these two graduate students stephen goldfeder and harry

kaladner came into my office and um at this point i think i'll pass the baton to stephen to tell the rest of the story yeah so i guess i can back up a little bit i was like eagerly waiting for ed to come back from the white house because in the interim uh scaling well we thought scaling had become a problem of course what we actually saw was a blip compared to what we see today but it was very clear to me that scaling solutions were necessary and had had early foresight here so harry and i basically ambushed at his office and said hey that our virgin thing that you were working on i think it's time to pick that up and for that we worked on arbitram for about two years or so a year and a half to two years in an academic context we published a paper in

arbitrary and it became clear to us uh basically then before the paper was even like fully published that there was commercial potential here and we decided to spin out arbitration as a company i don't think any of us realize that moving forward we'd all be in this full time and absolutely loving it three years later but uh there's really nothing else that i'd rather be working on now and you know that's sort of the beginning but it's been a really long and really amazing journey in the company so far and i think the best is yet to come cool that is a really long time for a product to exist uh how similar is arbitrarium today to you know what you started on three years ago and to what the student work from uh 2014 was yeah let me compare it to the student work um

the piece that really comes through from that very first version is the way that the system resolves disputes between parties about what is the correct execution of a chain the basic idea of resolving disputes through this recursive bisection method that we use uh that goes back to the very first version of arbitron but i think almost everything else about how it works um has been built since then you know if you go back to 2014 this is before ethereum had really launched yeah um and so we didn't think of it at that time as an ethereum scaling project because there wasn't really an ethereum to scale and so one of the big one of the ways in which it's changed is the way that we've

adapted some of the basic ideas um to work with ethereum and i think we found partly that it's a really good fit to the problems and affordances that ethereum has and partly we've made it fit through the various research and engineering work we've done in between so that's a big piece of it moving into what's today called a roll-up model is i think one of the changes over time we've had different ideas of what the role of validators are and how all that works um you know we could go deep on that if anyone is interested and this is actually another part of our journey um in the early days of our company we would talk to people about what we were doing and they said okay is it state channels or is it plasma and we would have to say uh no it's

something else but there wasn't really a word at that time for the thing that arbitrarium is it was only later that this term roll up came along and we recognized hey this actually is a pretty good description of what we do um or at least a you know a big part of what we do and so the category that we're in is a category we were in before it was a category but do you i mean i said this just before that you're sort of in the optimistic roll-up category as well like the idea of using i'm assuming you're using fraud proofs it was that already part of the idea back in 2015 yeah yeah the idea was that was optimistic in the sense that somebody would make a claim about what the correct execution of the chain was

and then there's a time period where people can dispute that if they want to dispute it and if there is a dispute then there's this dispute resolution protocol so all of that existed in the 2014 version okay but was it was it all built with the concept of like bitcoin as the core i think our line back then was we're chain agnostic and that's what was in our academic paper was you have some layer one chain that has some basic capabilities and you can build a powerful layer or two on top of that really it solidified to us that we were building on ethereum back when we started when we initially formed the company and that's when you know you know in an academic paper you could say oh it's chain agnostic and that's like a good thing when you're building a company and uh you have to actually know

what you're building on and it became clear to us that uh building on ethereum was the right thing to do uh this actually was the most popular model for investors back in the day this was like 2017 2018 people just want you to launch your own blockchain and get your own coin but it was clear to us uh back then that if this could be made to work on ethereum uh we should make it work on ethereum and and that's sort of the approach that we took and uh and the rest is uh history from that point so you just mentioned the company that you formed which is i it's off chain labs correct that's that's a company so i actually kind of wanted to understand that so like going back to that story you were saying it like 2017 you're deciding okay we're gonna actually

run with this you found a company like who who was that company and and what was the kind of origin story there yeah so at first at first it was just it was the three founders it was myself and harry kaladner and stephen so we were the three main authors of the academic paper we had written the vast majority or i think maybe all of the code underlying the academic paper and so it was just the three of us that spun out into a company and at first it was just you know three people and a piece of paper saying that we're a corporation and that was sort of the beginning of the journey we we did a first fundraising round in early 2019 we started hiring employees and got an office

and you know started actually producing taking the academic code which we had licensed from princeton and then uh turning it into something that was going to work as a product wow you were raising in 2019 that's a that was a tricky time i remember yes back then basically people didn't really believe that scaling would be the issue that we that it is now this quickly i remember one of our investors says you know what you're saying is build it and they will come you know do we really need this is ethereum uh really going to ever reach its capacity or or is it going to reach it anytime soon another another uh pushback we got was hey you know there are so many other problems that will come first like ux uh you know etc finding good use cases

and you know scalability is more down the road so i i think that you know uh it was a particularly hard time for the market to to raise that but i think for scaling solutions also people didn't really believe believe that it would become that important that quickly but uh you know we didn't have too much trouble trouble raising but uh you know we definitely did need to convince people of our story as opposed to today where people are uh saying hey why is this not built yet why is it not our main net yet we need this like yesterday okay so we've kind of determined that arbitrary falls into the optimistic roll-up category but like when you were doing this there was no optimistic roll-up category really like you didn't call it that did you or like actually sort of random question

here but like who coined that phrase i actually don't know that so it came in two pieces i think as i understand it um first the idea of roll up which i you know today means something about uh recording data on the l1 chain to allow people to replay the history of the chain if they want to um and then optimistic as a descriptor on that came came later um we didn't or originate either of those terms but we you know we adopted them because it was clear that they you know were describing the thing that we were already doing uh if i remember correctly uh you know roll ups came out of barry whitehead's work

on um you know zk roll ups or you know the early thing that eventually became the foundation of zk roll ups and optimistic was coined by i want to say vitalik and then popularized by um dean eigenman's post on optimistic systems no way dean made that famous uh who's the the first one that i remember writing a big blog post about what is optimistic and then uh you know after that they came together to be optimistic roll up which was a description of systems like arbitrum that were already in progress a few weeks ago we did have optimism on the show

and there obviously you can see like they kind of took that name and now it's kind of part of their brand i keep unfortunately messing that up and being like optimistic when i mean optimism and optimism when i mean optimistic um but i i i want to understand you know how how does what you've built how is it different from what they're building if you're both in this kind of sub-category of roll-ups which we're calling optimistic yeah it's a great question the first thing i'll understand on on the name yeah i think they definitely uh were using the term optimistic roll-up before we were so that's sort of now come to describe a category of scaling solutions we also have uh some others like fuel labs um also sort of uh re-categorizing pro projects into this category yeah i don't

add do you want new sure let me talk about what the difference is um there's a bunch of ways to come at this we can talk about a lot of the detailed differences but one way that i think is useful to think about it is that we start with the idea of resolving disputes that is dealing with claims of fraud by an interactive protocol so you have two people alice and bob who disagree about what's the correct outcome of a particular um of a particular set of inputs to it to the chain um and how do you resolve that dispute we use an approach that's based on interactive proving so um that is um alice and bob sort of go back and forth there's a kind of game

between those two parties that's refereed by an l1 ethereum contract and our system is designed around the idea that that is the best and most efficient way to not only to resolve disputes but actually it allows the most efficient execution even in the case without a dispute at bottom one of the big differences between optimism's product and our product is the way that the disputes are resolved and many aspects of the overall design of arbitram follow from that decision to use interactive proofing and we can you know we could dig into that a lot more why interactive proving is better we think and then you know what does that mean for the design sure i want to take one step back into

the kind of fraud proof concept because it was this i mean it was in that interview that i realized like okay so when you're like this fraud proof it's not that you're constantly sending fraud proofs in fact you should never like it's almost it will be very rare that such a proof is actually created and i guess the reason i didn't get that right away is i'm always thinking from the zk proof like context and the zk roll up where you're you're often sending proofs here this is if there is a dispute a fraud proof is submitted and then that fraud proof must be kind of figured out yes if everyone agrees if literally everyone agrees what the result is there's no need for a proof yeah right

and so and as you say in the common case no proof is necessary right because someone makes a claim which is correct and everyone else looks at it says uh-huh that's correct and on you go so this is one of the ways that optimistic systems can be more efficient is you don't have to pay the cost of proving yeah unless there's actually a dispute unless something goes wrong unless something goes wrong one way or another yeah yeah but normally things don't go wrong right and people are disincentive from trying to cheat there's a very interesting thing here to connect your this question back to the other point of how we compare um you know our core differences in the in the technology is really around fraud proofs and it's a bit

ironic that you mentioned froctures don't really come up in practice like we expect them the incentives of the system will work that properties shouldn't come up and we really don't expect to see these but ironically the fraud-proof technology impacts the happy case as well so uh you know for for example our transaction costs are quite low and it's because of the way we do fraud proofs other systems uh have issues with large transactions which consider a transaction that goes over the ethereum gas limit or a contract deployment that goes that's larger than allowed on ethereum we can do these but systems that require that rely on fraud proofs that that uh re-execute code have trouble with these because again even if fraud proofs don't come up you always have to have

the ability to do a fraud proof so if your fraud proof mechanism requires you to re-execute code and rerun your transactions on chain then even in the happy case where there is no fraud proof you still are bound by the limits of of the ethereum chain and that's something which we break out about so it's super interesting that like you know our core technical differences from other optimistic roll-ups are in the way we do fraud proofs but it actually impacts the healthy system even when there are no fraud proofs which is i think you know an interesting and not super uh appreciated point yeah so i mean one way of looking at this is you rarely have to do a fraud proof but you always have to be ready to do one got it uh so you've used the word interactive to describe your fraud

proofs a few times should we say that optimism's fraud proofs are non-interactive and that's one of the core distinctions um i i think it's probably more accurate to say that they are one-round interactive proofs so someone posts a claim about a roll-up block which is like a claim about what correct execution is and there's one round of interaction that someone says assuming it's wrong they make a claim that it's wrong and then the system in one sort of that one round game is able to resolve it um whereas we use a multi-round interactive protocol and okay on the other on the other hand the zk zk roll up system would use a non-interactive because they you just post the proof every time right away so it's a much more of a spectrum than a

binary here is we have the zk on one end as non-interactive and then optimism as one round of interaction and then arbitrarium can do potentially many rounds multiple rounds yeah as many as necessary um it's a small factor times the log of the number of steps of computation yeah uh you said uh recursive earlier which gave me a hint as to how it works yeah so let me dig into that a little bit more so imagine that alice has made a claim about a billion steps of computation and bob disagrees with it right so what will happen is bob first of all says he disagrees with that bob will make a counter claim here's what he thinks the result which should be after a billion steps and then bob will divide his counter

claim into a hundred smaller claims each of them being uh 10 million steps that sort of um in sequence um line up to be equivalent to his whole billion step claim right and so now bob has made a hundred of these 10 million step claims and alice will pick one of those to disagree with ellis has to pick one to disagree with and so now what you've done is in one round of this game of bob's move you've reduced the scope of the dispute from a billion steps to dispute about uh 10 million steps of computation um so a factor of 100 at each round um you reduce it so after whatever the log base 100 of a billion is which is i guess

four and a half rounds um you now have a dispute about one step of computation um and now that finally gets decided on the l1 chain on the merits right that is whoever is making that one step claim has to offer a proof that like hey this is an ad instruction here's a proof that it's an ad instruction here's a proof of what it is that we're adding and therefore here's what the result should be so that one step proof is super simple but you get there from a billion steps or whatever 100 billion down to one through this recursive division right the idea is that you know you and i are running the same computation with the same inputs we should agree exactly on what happened at every step

right yes so where optimism the solution would be to have the l1 run all one billion steps in arbitram there's this negotiation between you and i where we narrow down to exactly where we disagree and then the chain resolves just that one step where we disagree exactly right and and the thing that you can prove is that the person who's right can always win the game as long as you know there's no censorship on the chain and the other kind of standard fraud proof assumptions yes right you have to assume that people can get um a transaction on the chain within a not outrageous length of time so it's about a week in optimism i think

is what they're thinking and that's what we're thinking as well that you have about a week of grace period to deal with denial of service attacks if there is a dispute so in this you know example with a billion steps of computation and we need to do four or five rounds back and forth is that one week per round or one week for all rounds it's one week total we sometimes talk about it as a chess clock model that is um each player gets a clock that starts with a week and when it when it's your turn to move your clock is ticking and if your week runs out then you lose the challenge and so that means that you have a week this is a week in addition to the time that it's expected to actually take you in the absence of denial of service

right so you have a week of extra cushion to deal with denial of service or crashes or whatever might happen during the entire course of the game gotcha interesting and so uh this core difference is why you were talking earlier about uh arbitrarium being able to handle much larger contracts and much larger computation is because where you know a one-round fraud proof would have to run all billion steps at the same time arbitrarum can break it down into a bunch of discrete little um you know sub-rounds or bunch of discrete rounds but only if necessary right so this is one of the key points if you're if you're operating with this re-execution model you have to post a state route

on the l1 chain basically every for every transaction or you know within for every ethereum gas limit whereas with arbitrary you don't need to do that so that you can checkpoint the state route to chain say only every five or ten minutes um and because if there's a dispute going the difference between 13 seconds and five minutes is just a couple rounds of dispute and with this chest clock model it doesn't slow down the um the resolution of the dispute by more than a trivial amount right and i guess the other part of that is uh if i have committed fraud and i am absolutely sure i'm going to lose this

game after 10 rounds uh i probably won't even play the game at all uh so we don't have to have the layer one spend money and gasp running this 10 round game that i know i'm going to lose that's true but also even if you do play the game out the l1's job is really easy it's a time keeper number one and number two it makes sure that the players moves are are sort of valid on their face so bob is supposed to issue a hundred intermediate um state routes and did bob issue 100 things that look like state routes or not right whether the state routes are correct or bear any resemblance to reality the referee doesn't need to know because that's all going to come out as they

play this interactive game and so the referee just needs to make sure that each player moves on time and that the move is syntactically valid does it contain 100 state routes did the person really identify one of those hundred steps um you know literally is it an integer between 0 and 99 the sort of segment identifier that gets passed so it's very simple checking at each round interesting i'm i'm left with like two questions from here that maybe you can help me understand so we we keep kind of mentioning this one week duration so going back to that idea fraud proofs they exist in the case that somebody does something inappropriate but like you have this week-long

time frame i guess that's been predetermined when you think of a transaction actually kind of going from the l1 to arbitram doing something like things are basically happening over an arbitrary and then you're trying to kind of bring it back to l1 does it then sit for a week on on route back to l1 when you're trying to kind of show that this thing has happened guaranteed that it's happened roll it like roll it up and and write it do you have to wait before you can access it so there's an important distinction here between finality and what we call confirmation so finality is when do you know the result what you what the result of your transaction will be at what point in time does every honest

party who's watching know exactly what the result of your transaction has to be and then there's confirmation which is that at what point in time does the ethereum chain record the fact that that happened does that make sense yeah yeah okay so and it might be helpful to walk through kind of the life cycle of a transit of an arbitrary transaction sure let's do so some user wants to do an overturned transaction what they're going to do first is arrange for that transaction to get put into the chains inbox so the chain has an inbox which is managed by an l1 contract and it's first in first out and basically that is supplies the inputs to the chain's execution and so what the chain does is it reads

its inbox one transaction or message at a time and it processes each one and that processing is fully deterministic so once your transaction is in the inbox now you can figure out exactly what its result is going to be and everyone else everyone else who's paying attention can also figure that out because the result of your transaction is a deterministic result of what's in your transaction and what's ahead of it in the inbox so when you talk about this execution though is that execution only on arbitrarium or is that execution still on this l1 like where are the execution on arbitrage okay so we've already moved off of l1 where we're in l2 yeah so as soon as you put your transaction into the arbitrary chains inbox

now its result is inevitable okay um and everyone can know what it is so as soon as the arrival of your message in the inbox has finality on ethereum then your transaction has finality on arbitrage and everyone knows what its result will be the only entity that doesn't know the result what the result of that transaction will be is the ethereum chain right so the whole point of the of an l2 chain is that you don't want to make ethereum do all the work of executing or checking out all the transactions right yes and so we don't right so all observers who are watching they can execute along with what the chain is doing based on the contents of the inbox that are fully

known to everybody figure out what the result of your transaction will be and go on from there um but it takes a week for the ethereum chain to ratify or confirm that inevitable result when we talk about kind of going over to arbitrarium it's not that it's like a ledger owned by like sitting on one person's computer where things are happening like that in itself has a decentralized block produ production kind of system yes so it's like it moves from the l1 to the l2 which has its own i guess security in it yes and then it's that extra the extra security is generated by getting that confirmation one week later

actually is that how you think of security there because i always think of like the l1 is supposed to provide the security in a way so the white yeah we think of the l1 as providing confirmation as confirming or ratifying the result right in normal case the history of your transaction will be you put it into the chain's inbox um and once that has finality that putting into the inbox transaction is finality on ethereum now your transaction has finality right its result is known and is known to you and knowable by everyone right then at some point some party will propose a rollup block that includes the execution of your transaction and whatever results it produces whatever changes it makes to the state of the arbitrary chain

there's a state route that's posted that summarizes all of that and then any actions like withdrawals of funds back to l1 are also part of that roll-up block so that roll-up block gets posted if it's correct everyone knows that it will eventually be accepted if it's incorrect everyone knows it will eventually be rejected so in the normal case someone posts a correct rollup block that includes your transaction and then a week later in the normal case no one has disputed that and the ethereum chain confirms it and then uh now ethereum knows that that's the result of your transaction okay everyone else knew before that but it takes a week for ethereum to find out so say you're me i'm running an ethereum

node uh and then i want to participate in arbitrom so i also run an arbitrary full node alongside it right if you want to yes right so it's just like ethereum you can run a full node or not uh and so my arbitrary full node can learn very quickly whether an arbitrary block is valid right because it's running the whole arbitrary chain it's syncing everything sure yeah but then it takes ethereum a week to catch up to what my node knew all along that's right that's right okay yeah your node everyone's node knows it knows the score it's just that ethereum is slow to find out okay and so uh you know the idea of that week is that it gives a chance for my node to tell ethereum

that uh you know something's fishy here yes right if you think that that roll-up block that was proposed is wrong you can dispute it um you have to say what you think is correct and then you have to stake and um then um you and whoever proposed that block will be put into a challenge with your stakes at stake um and eventually one of you will lose and their the wrong block will eventually get rejected and the correct one will eventually get confirmed interesting but the outcome of that challenge is known to everyone else uh you know as soon as it happens everyone knows who's in the right in that challenge okay the security property of the rock is that you can ensure that whatever you

see on your node that any honest player themselves can ensure the correctness so if you're running your node and you know the state that's exactly the guarantee of the roll-up but you can guarantee that ethereum will publish that people will confirm that because either uh it's going to be published and accepted or if someone tries to challenge you know that you can successfully defend it and so uh the security guarantee is that ethereum will catch up to what everybody else knows is correct you know as long as there's no censorship and there's one honest person like me out there willing to submit the proof and everything so we do assume that there is one honest person who is or just one greedy person who wants to take the stakes from liars right even just a person who

um who is challenging wrong um roll-up blocks for profit will ensure correctness yeah and you know i i think to be clear is that's a assumption of any optimistic system yes yeah what's essentially the the assumption of of roll-ups is that you get a guarantee of correctness on some assumption an optimistic assumption you have to assume that there is someone who's willing to stand up for the correctness of your transaction or the correctness of the chain at all and for zk rollups you have to assume that the cryptography works yes um there's also questions about censorships one of the things that i like about optimistic systems is anyone literally anyone in the world can play the role of the one party who

forces correct execution right you don't have to rely on someone who has special equipment or special know-how or secret software or anything right all of the information you need is on the l1 chain because it's a rollup and the computational load of actually ensuring correctness is reasonable for an ordinary computer oh that's nice i want to understand like this idea of one individual can submit a fraud proof but like what does that actually look like it's not somebody sitting there like sees something with their eyes and pressing no right like this is all built into the rules already essentially yeah so in practice people will run validator software right so validator software is

if you want to get right down to it you know it's a piece of software that watches the chain and it creates disputes and engages in this interactive challenge protocol when needed and we offchain labs produce open source software that will do that and so anybody can download that build it yourself or just download our docker image or you can write your own according to the published protocol right so anybody can do that and there's open source software that lets you do it so in practice what you do is you start a validator on your computer or on an amazon instance or something and then you just like go about your regular life i guess should we make a distinction here when you use the term validator i mean we have i have a validator it's called ck validator but on these

proof-of-stake l1 networks i've heard a lot of different words for the actor that lives between l1 and l2 and is that what you're referring to here when you say validator yeah so we we think of the nodes the arbitrary nodes is basically falling into two categories they're the ones that are validators who are who are paying attention to the correctness of the protocol making sure that roll-up blocks are correct and so on um and they're mostly most of the time a validator is just watching and checking right most of the time everything's okay and so nobody even knows you're running a validator if you don't tell them then there are full nodes which are more like ethereum nodes meaning that they're following along and

many of these nodes will accept rpcs from clients and um can provide node services using the same api that ethereum nodes export got it but these validators are not building they're not creating the block there's no like actually this is a question like is there a block in there blockchain in there okay so who who makes the blocks so any validator can make a block okay so anybody can make a block you're essentially proposing a block if you like you can think of it like the ethereum chain in the sense that anyone can make a block we don't have a proof of work that you need to do instead um you're subject to fraud proof instead you have to stake and you're subject to

uh to it to a fraud okay so so it is proof of stake in a way it is proof of stake but you don't call it that this is where it becomes so intertwined the difference is i think that with sort of classic proof of stake you have this scheme where people make blocks and there's a kind of consensus that develops among the people who have stakes down whereas in our protocol and in most other roll-ups it's not a consensus protocol it's a correctness protocol that is if you are correct and everyone else in the world is lined up against you you will still win because at the end of the day this dispute resolution protocol is determining who is actually wrong about what the chain will do

and so if you're right you can always win um in this game that's a difference between either proof-of-work or proof-of-stake type consensus algorithm traditionally proof of stake is like a voting model and the idea is if you accumulate enough stake you can like overpower and make bathrooms happen in the system there's no such attack attack vector here right all you need is one stake and you can guarantee honesty and if someone else has like way more stake than me and they can they still can't uh force a bad action a bad result into the system is the validator actually like the bad actor as well like if there was to be a bad actor would it be a validator actually submitting something incorrect yes the validator who post the the update would post a bad update and

then another validator were challenged and you get this interactive challenge between two validators that would play out yeah and then at the end of the challenge the bad validator is going to lose the challenge and they will lose their stake and some of that state goes to the good validator who challenge them and some gets burned for incentive reasons we were talking earlier about you know this being a correctness protocol not a consensus protocol and that validators unlike in proof of stake cannot vote for you know incorrect things am i right in believing that you get that nice property because you're relying on the layer one host blockchain to provide you you know a consensus protocol and everything else you need that's exactly correct there's no magic

yeah there's no magic bullet here it's we're we're using ethereum's consensus we need a consensus mechanism but the property is if ethereum's consensus works then one honest validator can afford correctness this is an extension to existing like consensus protocols it improves them it makes them better and more scalable yeah yeah exactly and that's why it's really a layer two by definition the layer two it's the true layer two because it doesn't have its own consensus it relies under the layer of consensus and then the validator uh property is for ensuring the correctness of the layer two and that's why it's and that's why it's so nice because you can get the decentralization and security of the layer one and then you have these validators that are really again minimally trusted in a typical proof-of-stake uh

or a different consensus system you have to worry about who are the validators how many are there can they again can they overpower and over-team and form a cartel here you don't have that property all you need to know is that there is one honest validator that's going to do the right thing and again that together with ethereum's consensus is the recipe for correctness so as long as ethereum is working and there's one honest validator out there arbitrary is going to work right yeah as long as that's the case you will get correct execution of the arbitrary chain besides this the fraud proof there's something else being written to l1 what is that actually like what is the true like not not the proof of fraud but like the transaction going back yeah so let me tell you sort of what's in a roll-up

block which is probably the key the key thing right so a roll-up block has first of all a reference to the previous roll-up block saying you know here's the last block before me that i that i say is correct then so starting at the end point of that block the role of block says we can execute a certain number of steps of computation and that if we do that we'll consume a certain number of messages from the inbox that after doing that the state root of the chain will have a certain hash and that along the way in the course of doing those things a certain set of outputs will be produced and there's a sort of hash that summarizes all the outputs that are produced

so that is the claim it's starting at a certain point you can execute a certain amount of computation that it takes the state root of the system to a certain value and then it produces an outputs that have a certain hash so that's relatively small so uh phrasing that in kind of more uh layer 1e terms is the rollup block is the previous state a bunch of transactions and the assertion that if you execute all these transactions on the previous state it'll produce a new state and these uh messages sort of we logic logically it includes that information but it doesn't actually physically include it like the individual transactions are not actually part of the rollup block they don't need to be uh they're they're in the inbox because

they're in the inbox right the inbox provides and this is another thing that is i think non-intuitive for people who are new to this that you have this inbox contract which runs on l1 which does two things first of all it establishes an order on all of the transactions that are submitted to the chain and then it also records in their call data um it records their data in the form of l1 call data so that it's accessible to everyone and then separately you have the roll-up protocol which given the contents of the inbox ensures the correct execution that is the update of the state of the chain and then whatever outputs it produces one higher level point that uh

again i'm not sure i'll just say it quickly and i can speak this if it's interesting uh for a question but sometimes people get uh think that we're sort of scaling ethereum transactions directly right you have some contracts on ethereum and then the roll-up comes in and gives you extra superpower there there actually was a scaling project that did this and this was basically true bit back in the day when the idea there was you're running your ethereum contract you you get to sign that super intensive you call out to truebit it gives you a result and everything stays on ethereum the way to think about arbitrary really all the modern rollups these aren't like interacting with the transactions they're actually on ethereum they're basically uh present themselves as other chains and they have their own ecosystem and their own their own sort of transaction

history and state that's built on top and secured by ethereum and so it's not that you know there's no like one-to-one um you know relationship between every transaction is affecting something on ethereum rather the roll-up has an ecosystem it's a chain that lives on ethereum that is secured by ethereum that has a trustless bridge back to and from ethereum but um that's sort of the level of interaction really is the bridge and information going back and forth but it's not like every transaction on ethereum can just call out into the roll-up and get some extra superpower super scaling energy or whatever um just as a quick aside i am interested in how you guys would characterize the difference between your uh recursive fraud proof system and true bit i i know truebit is basically defunct these days so it doesn't matter that much sure um

i'd say a few things um one is that in our basic model the execution is stateful whereas truebit is stateless okay that they are proving the result of a computation that has an input and an output and no state and so this is what you know what steven was talking about before where you have like a sub procedure inside of your ethereum transaction and you can execute that sub procedure on tribute whereas because our system is stateful and because it is capable of emulating ethereum you can do 15 minutes of ethereum transactions in a sort of single rollup block if you want it and so that's the statefulness is an important thing the other thing is we've made

some very significant improvements in the bisection protocol so that you need many fewer rounds what we were talking about back in 2014 is similar to the kind of bisection that truebit uses and we've since made a bunch of improvements that increase the sort of degree of division in the bisection from a factor of two for every two rounds to a factor of 100 for every one round so a big difference and especially when you compound that over all of the uh over multiple rounds i want to ask so i mean the things that are kind of off the table for an optimistic roll up or probably a zk roll are things like flash loans like what you said it's not one transaction that could like

go through kind of go off and come back within one block it's like it's it's gonna go off it's gonna live off and then come back after a while i would say that your flashlights are in play flashlights that they go back and forth from ethereum wouldn't be in play but like again we're we expect there to be a fully flourishing ecosystem of d5 protocols you know on the role of itself on arbitrary so i think everything you have in ethereum you'll see it there but yeah definitely we don't have synchronous composability so you wouldn't have flash loans that go jump back and forth you know between the role okay and on the arbitrary chain like is there will you say there's an entire ecosystem is there like gas and all of those elements is that is that the case for all the

roll-ups i actually never asked that question there kind of has to be right because if resources are free then they're going to get overused now i want to bring up something stephen you mentioned earlier which was this idea of re-execution this is i actually i think a while back i said i have two questions and one was the one week and now this is actually the second question um so so yeah it's this idea of we i mean at least i i feel like i understand what we've we've talked mostly about like optimistic roll-ups in general but you mentioned that like the re-execution aspect that is actually used more for like the fraud proof actually has a has something like it differentiates you somehow

and i i don't exactly understand where that fits into this yeah so i think that we were discussing that was we were asked about the comparison between us and uh optimism and how we do our fraud so uh so what is a fraud proof right so the key idea of a rollup of course is you take the execution off chain and you prove to your theory of what happens and the way the fraud proof works is optimistically the validator posts what happens without proof and then a challenge window opens whereby anyone can prove fraud and that's what's called a fraud proof and so what are these fraud proofs these magical things look like so the simplest way to do a fraud proof and this is what optimism does is re-execution where you point to a transaction and say hey that transaction is fraud fraudulent and you re-run the that

transaction on chain so they have a before checkpoint and an end checkpoint and you rerun you say hey does this transaction match up with the end checkpoint and that's how you prove fraud what we do is different and this is what ed was talking about we do this back and forth and we can we instead of re-executing you know you're say five million gas transaction we actually just do an interactive process and we when you end up having to execute on chain is not the entire transaction but much much smaller like one step of the transaction so that's all fraud proof so you might say okay this is all irrelevant doesn't it matter yeah that's the thing is to me like it was kind of in the context of the fraud proof but like does that have any impact on how the system's built without a fraud proof like that that

idea that we talked about like the inbox and the fact that you're writing back to chain yes so so so it does have few things are um that come into play here number one are uh this is something i mentioned earlier as well the idea is if you're pointing to transactions to re-execute them then you basically need to have frequent checkpoints you know every challengeable unit has to have a checkpoint before and a checkpoint after and what this means is in systems like optimism you have a checkpoint for every transaction and a checkpoint is roughly a 32 byte state route 32 byte hash and they need these frequent checkpoints because you need to basically point to something and that runs between two checkpoints we don't need these checkpoints that's one point and another is this idea of we can do transactions they use much much much more gas than is

allowed an ethereum block we can do contract deployments that completely break out of ethereum's contract size limit now how can we do that and the answer is because we don't need to ever run our transactions on chain if your fraud proof model is re-execution then you can't have a transaction that uses more gas than is allowable in ethereum block because it's not challengeable someone can't say hey that's wrong and you say okay let's run it oh we can't run you can't because there's too much gas on on now one right or the contract deployment is too large we can't do that contract because it's too much gas but we can do those things because our model doesn't require us to re-execute and rerun full transactions on chains you can do a transaction in arbitrary that uses much much more gas than than an ethereum block and that's okay

because the fraud proof will not say hey run that unchained and you'll be like oh sorry i can't it will get it down to the core unit of dispute and that's going to always be small and something that you can run on chains so it's ironic again none of the fraud proofs won't come up but they really really really do uh yeah basically what you're saying here is like your fraud proof won't break ethereum like you will be able to run more on your chain and yet you've been able to make sure that if if ever you need to run a fraud proof it will still fit within the confines of the l1s exactly the mechanism won't come up but in order for the system to work the mechanism needs to be there and therefore you can't do something that it's not challengeable even though no one's going

to challenge it when it is challengeable but it's a very like weird thing where again the fraud boost won't come up but if you don't have the ability to do fraud proofs then that's a big problem yeah right and the key thing is right you have to be able to do the fraud proof and you have to have enough data recorded on the l1 chain so that the scope of the fraud proof is defined right so this is this thing that you always need to be ready to do a fraud proof even if you very rarely have to do it and the cost of being ready to do one kind of fraud proof versus a different kind of fraud proof can be fairly different okay so we've talked about kind of we we've mentioned a few of the other optimistic roll-ups we have mentioned the zk roll ups i want

to talk a little bit about the cost of all of these systems and how you kind of fare like what what does it cost to use an arbitrarium style optimistic roll-up versus others sure i mean we've worked really hard to shave down the cost um at this point in time given the ethereum gas costs and the price and the price right right now given the situation with ethereum fees uh for all of these systems the biggest cost is from the l1 footprint of your transaction um and that is the cost to record your call data on the l1 chain something that you have to do if it's going to be a rollup and then whatever additional l1 cost is

necessary for bookkeeping and dealing with fraud and so on and we've worked both in the architecture of our system and also in our specific engineering to minimize those things so to give you an idea um on our test net that's currently up um people can actually go and run their transactions and then look in our block explorer and see what the l1 cost was but we're running around something like 2000 l1 gas per transaction for a transaction that has a small on small call data and um we think we can get that down further by adopting bls signatures once that is fully supported but that number is really competitive in terms of where other systems are so we're really happy with that and there's a bunch of things we've done to

make that possible some of them are things anyone can do like aggressively compressing the transaction header data some of them are things that not everyone can do like not posting a state route for every transaction because our protocol allows us to not do that so l1 footprint is you know is the biggest component of cost that's really where we're focused um in terms of cost reduction this is sort of a more generic question but optimistic versus ck does does zk tend to be more expensive or optimistic the answer i think is it depends um call data needs to be recorded on the l1 that is pretty much a constant and then the question is how much bookkeeping is required and how much cost is there per

roll-up block or per um whatever the equivalent is in a zk system and another thing to be said here is the overhead of zk i think is is much much larger than the overhead of a per batch level of the overhead of arbor trim or other optimistic roll-ups so in order to advertise the overhead you need uh significantly larger batches and a zk system than you would in in our the way that that sort of batch size um affects users is that you have some entity that is submitting batches of transactions to the system and it's got to wait until it has a full batch before it can do that and for the user that means latency and so if you have a system that needs to accumulate a million transactions in a batch before it can submit a batch

because a batch is super expensive per batch right um then you're gonna have a longer latency than a system where you can have a batch of 30 to 50 transactions and still operate very efficiently and that's kind of the neighborhood that we're in that's why i guess you said amortized over because like on a per transaction optimistic might still be more expensive but you can do more of them i guess but you you win on time and time is really important for users right how quickly can they get to the point where you as a user know what the result of your transaction will be right people are already unhappy with how long that takes on ethereum and you certainly don't want to make that worse and there's a whole other conversation about how to make it better um but that's something that goes more to our

roadmap than to the our current test net cool speaking of that's actually the next question and a question i want to touch on i know we're getting close to the end of this episode so let's hear about this road map you mentioned a test net where is this project at yeah so we've been on testnet actually since october and that's a test net that's fully open and permissionless anyone can launch on deploy contracts and we've seen a ton of usage on our test now we're actually currently on the fourth iteration of our test net but it's been running since october and a few weeks ago we put out what we call the main net release candidate version of our test net so this is more or less the code that will run on mainnet and uh running on testnet getting some more mileage of testing

there but again this is our full protocol like the fraud proofs uh mechanisms are up and running on the test now we have real validators running we have some other people running validators as well we have the permissions deployment and lots of people uh playing with our with our test net currently and the scaling ethereum hackathon is going on and people are people are building on on our test then we're seeing a nice amount of usage there yeah so where do we go from here is and the answer is mainnet of course um and the do you have a timeline in mind or um so we haven't announced uh a formal timeline yet but i what i'll say is i think it's gonna be a lot sooner than people expect we are basically um from a technical perspective near just about there and we're we're coordinating some some

details and and we'll we'll have a lot more to say about this in the next one to two weeks but i think we're we're probably a lot closer than people than people realize cool um i know that a lot of the lt there's sort of a race between the l2s to to find new d5 projects to work with or or other kind of daps you know more popular projects that are like working on top of the l1 how is that going for you like is this do you feel that kind of race that that competition and and what are you seeing like from your side so so one thing to be said about the way we're approaching our launch and this is actually something that's different from a lot of other players in the space we don't have a white list model we're not uh onboarding uh one project at a

time when we open the floodgates and let projects in it's everyone everyone's on the same footing and we think that's really the values of the open and permissionless you know ecosystem that's what we're doing here that you know it should be open to everyone and we're not going to be picking winners so yeah we have a really really strong coalition of projects that are launching with us uh some of them are announced um like mcdex and dodo exchange and some of them are not yet announced but we'll be announcing in the next few weeks and also we have a really really strong uh coalition of infrastructure projects already announced chain link but a bunch of other uh node providers and and different infrastructure projects are going to be coming along uh with us to to on to and as well so i actually think i'm

really really comfortable with the coalition that we have now again much of it is not yet public but will be potentially by the time this has aired uh will be public cool is there anything missing before maynet release is there anything you still need to build or you feel like there's some projects that will make using the system even easier okay yeah so so the way we're doing our main launch i should say and this is not something we've spoken about publicly yet but i'm happy to to say here where uh we're initially going to launch on mainnet and it's going to be mainly open to developers not in a whitelist or restricted model but the idea is it'll be open to the developers to set up shop first so we'll have infrastructure providers setting up a bunch of the products for example that are launching on us are going to be

using chain link so chain link needs to be up and running we don't want to be in a situation where we hey say hey everyone we're on mainnet five minutes after we deployed our contracts and made it but there's nothing running so there will be a time where again it's open to everyone but it will really be focused at developers there'll be a few weeks period and you know important in these period projects coming on or again you know the infrastructure projects that we're working with and also um projects that really make the user experience better so so one category of projects here are fast bridges we spoke earlier about that optimistic roll-ups have a delay period that delay withdrawals for roughly one week but they're you know that's really only on the protocol level the protocol level bridge has this one-week delay period but there

are some really really great solutions coming on board like connext hop protocol seller sea bridge uh that are basically bridging uh this gap and providing fast liquidity exits to users so um i don't i don't have an exact date on when those will go live but that's an important piece of infrastructure in the system as well got it that was actually a question was like how would that week-long thing be mitigated and it sounds like you have a plan in place and that will be kind of like happening somewhat in tandem with with you going live yeah and the design of the system makes this possible because um although it takes a week for the l1 ethereum chain to recognize your withdrawal is happening your withdrawal has finality which

everyone else can verify right away and that means that somebody who is thinking of loaning you that withdrawal money right away can have certainty that that withdrawal is going to happen and so a liquidity provider can can cover that one week delay for you at zero risk and this also enables a competitive market for those liquidity providers um and so we think that there will be a robust market in people who are facilitating instant withdrawals from the network so if i'm a liquidity provider here i have ether on ethereum you have ether on arbitrum you're going to send me that ether from arbitrom

to l1 and i'm going to send you ether on l1 immediately and i get urethra after a week is that right more or less yeah there's a small fee involved and there's different ways there's different technologies for doing this some are more state channel like some are cross chain atomic swaps some involve selling the uh the sort of withdrawal ticket it gets created at l1 um on l1 there's different ways of doing it but that's the fundamental idea yeah you're trading an l1 asset for an l2 asset and paying a small fee to the provider i am an atomic swap minimalist so i probably won't be using that one yeah you can use the technology of your choice

that's the beauty of this you know i understand y'all are on uh test net right now is this something that you know i could go home after this call and uh download like a docker client or anything and participate in the test net yes absolutely so uh there are a few ways to participate in the test net one the easiest way to participate in the tesla actually doesn't require you to download anything i just uh point your tooling at an arbitrary node deploy contracts interactive apps if you actually want to want to run a validator on the test net there is a docker image that's packaged it up that will allow you to do that as well so uh plenty of ways to participate in the test net for developers i want to deploy for users that want to use live apps we have a

a forklift unit swap live in the test that users can just play around with and also for uh sort of power users that want to run validators with james i assume might be might be you i have been known to run full nodes once in a while on that note i want to say a big thank you to ed and steven for coming on the show and sharing all of this info about arbitrarium with all of us thank you so much for having us this is really a blast thanks and thanks james for co-hosting this one oh it's great and i want to say a big thank you to the podcast producer andre the podcast editor henrik and to our listeners thanks for listening