Chicago Ethereum Meetup | Optimistic rollup with Optimism | 2020 Apr

all right hello everybody and thanks for coming I'm will work at a company called doesn't have heard of us more likely you've heard of optimist to grow up or the optimistic virtual machine that we're associated with as well and luckily enough or kind of unlucky due to the pandemic that's going on but it's pretty awesome that more or less everybody from my team is also here so great to see them and everybody else who's not in Chicago that decided to join so yeah today as was kind of you know outlined in the invitation we're gonna go over layer two in general at a high level and then talk through optimistic roll up a little bit and then the ovm and like the differentiator within optimism for the optimistic gorilla and then kind of the current state of optimism what have we done already what are you currently doing what are we planning on doing in the future and then a quick little demo of some of the stuff that we talked about today and like Paul said feel free to interrupt at any point if what your any questions or comments you have are relevant to the slide in question or the idea in question if it can wait till the end that's better but if it pertains to the slide then yeah let's talk about it then cool so let's get into it although you know we have about an hour maybe a little less than an hour and we're gonna work a demo in here as well so we're probably not going to get like into really deep dive stuff or like a bunch of really complex theory or anything like that so if people have questions about that and want to hang around after and talk through it happy to do that alright so first things first why layer two right before we're talking about like what it is and what it you know our approach to it and everything like what's the idea behind it you know one of the main motivators obviously everybody knows but right on main net we have lower tens of transactions per second whereas if we can make it so that thousands of computers around the world aren't doing the exact same thing in order to progress the state and we can do a lot more same thing with speed if that's the case as well if it's not so massively distributed then we can accomplish one unit of execution a lot quicker right and then as was mentioned earlier fees are a large motivator as well you don't want to be going broke and be having slow execution and then user experience as well it's something that doesn't really get mentioned as much when it comes to layer two but it's really important as well if we're talking about better throughput and better speed and potentially lower or or you know as close to zero fees as possible the user experience has a good potential to be much better than layer one as well so what is layer two oh and you might recognize these slides if you saw Carl's presentation at HCC I've taken a lot of them and use them directly or repurpose them for this talk so yeah like what is layer two right it's basically a state machine you have your collective state that's agreed upon and then there's some transition that occurs and that moves you straight along to the next thing and then another transition moves your stay along to the the next valid state right and so the most current state is called the head stick here and the way layer 2 works is you know we we want to get this better throughput in this better speed in these lower fees and layer 2 but we are also the reason it's called layer 2 is because there is a layer 1 and that is aetherium and we want to fully inherit all of the security that aetherium has to offer right so every now and again we're going to take this state and we're going to you know make it as small as possible and we're going to submit it to layer 1 so as to get some of those benefits in the form of state commitment so then users can look at the head state and see that it's on layer 1 and you know see that get that security guarantee as well so it you know I suppose it's important to mention layer two is often talked about in the abstract but you know there's potential for many different types of layer twos or many different implementations of even the same layer to solution so you might be tracking a lot of different depending on you know what you're doing you might actually be paying attention to many different head states at once and then yeah like this is all composable right so there could be also I suppose layer 3 and layer 4 and all the way down but the whole idea is that layer 1 as we talked about before as many of you have experienced as limited compute memory and layer 2 a lot less limited right we can we can do a lot more a lot faster and leverage some of the some of the guarantees of layer 1 right and then yeah as we keep going down like in theory yeah maybe there's even less limited compute I think Karl and his talk talked about you know layer 1 the way that we talk about it now is cerium and then layer 2 would be you know any of the layer 2 protocols like for instance optimistic roll-up or plasma or state channels or anything like that but in the future layer 1 could be like the beacon chain and layer 2 could be shards and then layer 3 might be rolla so really quick comparison of layer 2 chainz and more importantly than comparison of the chains in question is more so like the mechanisms and the reasons behind them so you know has we talked about before one of the things that's really important for layer 2 chains is availability like everybody in the world should be able to see what the head state is right what is the current state of my stuff in layer 2 frightened so like there are some differences between Optimus to grow up in plasma and state channels as to how that availability works and then there's also veloute right we need to guarantee since we're not dealing with the unanimous consensus of layer 1 on every single transaction we need to figure out like how are we going to guarantee the validity how are we going to leverage that there one security to security so when it comes to roll it our availability mechanism is pretty easy pretty simple we're taking all of the different transactions that occur on layer 2 and we are rolling them up I'll roll up and then we are posting it to the layer 1 chain right so the way that we make sure that our head state is available in the way that we make sure that all of the transactions that occurred that led to our head state are available is by posting them on layer 1 and then everybody can see from a theory immed the state and see that you know what the state of their wallet is and now the Liddy mechanism is we're going to post that State on occasion to layer 1 as we said and we have fraud proofs so if we look at that state and like we said all the different transactions that into that state are also present so we are able to do you know our validity checks ourselves we're able to run all those from the previous state run all of the different transitions see if we end up with the same resulting state now if we don't were able to submit a challenge to the layer 1 chain and say hey like we started here we applied these transactions we didn't get the same thing so something's something's wrong right so we're able to submit a challenge and then you know prune the invalid state from layer 1 right and I suppose we can go over a few of the differences here for the you know other approaches right so Zeke a role similar to optimistic rollick except that be you know ability mechanism is you know assistant Zeke a proof right so that whole challenge thing is not required for easy Kerala and then plasma it's the same you know kind of the opposite the same validity mechanism for plasma except for the availability mechanism is slightly different right instead of submitting all the transactions to the chain it's incumbent on you to keep track of all the transactions that are associated with the state that you care about so it's much harder than optimistic relat and then state channels you unanimous consent for everything and you know there's a boundary participant set so state channels are a little bit different than everything else they're really appealing but also not really like you know globally useful for everybody and able to use as a single protocol for everybody well it's moved for okay so walk through and this might get into the weeds a little bit I'll try to like you know breeze through it but if you have any questions along the way please you know let me know so starting the chain right as we said before like we fully inherit the security from layer one and the way that we do that is by hosting our contracts on layer one and basically we are defining the rules by which we're going to play in layer two on layer one and and that defines all be you know challenges and validity proofs no getting like that so we define our optimistic Rolo chain by deploying our contracts they're sweet we have a chain now we also have aggregators who are going to be the ones who are actually advancing this layer to state and posting these commitments onto player one and what is important is for them to post a bond so that if they misbehave if we do challenge them that they have something to lose there's a disincentive for them to lie or misbehave and I guess it's important important to point out that there can be many different aggregators at any given time they're only be one but there they are redundant for right now we're just going to assume that there's one so entering the chain how do you do that so if I want to enter the Jane I'm gonna send the transaction to the layer one deposit contract and say hey I have this money I want to use this money to you know join this layer 2 protocol and abide by its rules right so then that goes through it gets mind on chain and all of a sudden my eath turns into optimistic Heath right so great now sending transactions so remember yeah transactions are not going to occur on chain they're going to be processed by the aggregator and then they will eventually make their way on chain in the form of their state but not processed right so say I want to send 145 youth to Bob send it to the aggregator the I greater does the processing yeah the Ducks 1.5 youth for me adds a table comes up with the state that represents that and keeps track of all these different states of the layer to chain that is advancing roles those up submits in the chain they get mine and that's how the state of Kansas so submitting a block right we have this bra little contract submitting a block is just if we view all of the state of all of the layer two of the layer two environment as Leafs in a Merkle tree then we just create a miracle route from that and that is our block that is our role of block so we have 32 bytes per role a block of state right so that is part of the you know the appeal here we can do many different transactions that represent a lot of different state transitions and the state representation on chain is just 30 to 30 degrees so lots of gassing as well so let's see yeah when the state ultimately gets posted on chain like we said we can see that and everybody can observe it right so now interacting this mark smart contracts after all are just accounts as well so you can represent you know this as an account as long as the aggregator knows the logic of a smart contract we're able to represent its state that's simply like another account so how transactions work is you send a transaction to the aggregator saying that you want to invoke a specific function of a contract and the code is Kara because it knows the contract logic it knows how that should work and same sort of thing instead of updating a you know an external um account you're updating for contract route submit it to the chain and again everybody can see you know the updated state so now let's say that the aggregator wants to act maliciously right so I say I want to send xx to Bob and Yaga said well you know it really not instead of Bob getting that if I got that one right so they include that and they create a roller block and they submit that route to the chain right so now just like all the other ones that route is on chain but now we see it and we're able to say ok we have all of the data that went into this and we know the previous state we're able to apply these transitions and see that like I said that you know my sign transaction said to send 1/8 to Bob and instead it went somewhere else because you know the route is not the same and what's important and I can see that Bob can see that and figure I can see that either scan anybody running a full node can see that so instead of me having to watch the chain and and make sure that my own transactions are actually you know that somebody is protecting them what's nice is all we need is one honest validator to make sure that our transactions are safe right and given enough use and especially people who are you know using layer two with a fair amount of value they are going to run validators and there should be a safe assumption and we'll get into it later but you are you're rewarded if you you know prove fraud so yeah let's get into that now actually so challenging invalid blocks what what goes into that right we saw that we have an invalid transition because we know that like off chain we were not able to compute the same State on chain given the same inputs right so now we know that it's wrong but we need to prove to layer one that it's wrong right so how do we do that well we need to since there's a lot of different state that has transition off chain and since the only thing the chain actually knows about is the state group we need to from just the state route and the data that we have off chain that has been submitted as call data we need to piece together proof that we can prove to this contract that is incorrect right so we'll need an inclusion proof of the previous chant or we'll need the previous transition and the state of the preview the inclusion proof over the state of the previous transition right so like when I went to send 1/8 to Bob I had 7 and 1/2 Keith and I know that I have that because I can prove it from all the different transactions on chain and more importantly from the previous transition route I have an inclusion proof that I can generate that says I have senator happy right so let's go through verify transaction inclusion so we have yeah this is the previous state you're able to create a merkel route or a Merkel proof that shows that the the previous transit transition exists is right before the one I'm challenging and is valid and then we're the one that I'm challenging comes right after it that's something that's easily checkable by the contract so that's easy to proof now storage inclusion so we have like I said these merkel proofs of the key starting state of the employed trend transition so i have to piece together a merkel proof this as I have sudden have eath to start and this empty slot here has exists as well or does not exist I should say and then we actually applied the invalid transition so in this case it's fairly easy because you know the signature is invalid they they changed you know like it's not my signature I did not sign something saying that it's going to be aggregator but in practice if the if the signature was valid but instead the route was different than we would be able to to find that out as well right we send to the chain the proofs required to you know like the inclusion proof of the previous state as well as the transition the chain itself then does that actually does the computation and it sees that it's not valid right so now the the what we have just talked about is that's that's how it would ultimately check the resulting state in this case we already succeeded because the signature is invalid but yeah now if the Challenger succeeds right we move the block in question the invalid block and this is the part that I was talking about where if one honest validator exists where we're safe this is why there will probably be one honest alligator is because we burn most of the deposits to the aggregator or I should say much of the deposits that the aggregator has posted but we reward whoever challenged part of that bond so you are definitely in sized to challenge invalid transitions cool so yep so yeah then this aggregator dies goes away and as we said anybody who posts a bone can become an aggregator right so they post upon somebody else you know is selected to fill the void and they're able to build on that chain with the invalid State removed sweet so I have to thank Carl for this one but yeah we just sort of put a block chain on the block chain right so I think I'll pause here really quick and see like if there's any questions we kind of went through a fair bit here but hopefully the idea is pretty simple we run all the stuff we actually computed off chain the only time we actually run it on chain is when we're proving that somebody misbehaved and that's where the bulk of our speed-up comes cool one question something I've been a little bit fuzzy on in the past and I think you touched on it but I think it'd be helpful if you expanded on in just a little bit or clarified maybe so on on chain in the actual like layer one state you're posting the the merkel root of the rollup state is that accurate the two like as part of the Challenger thing as just just as any like yeah not part of the challenges yeah that is that is how the role of chain progresses right is these the Merkel route of the state of the l2 chain is posted and kind of a blended to so what I think I want what I'm when I'm have been fuzzy on is how I wear and I think you mentioned it but I may have forgotten but where exactly does the the kind of the expanded state of the roll-up chain exist where can either scan or whoever fine oh yeah that's that's pretty important and it wasn't like explicitly mentioned in the slides but that is added as call data for each one of the blocks emissions so the state that is actually stored as state within a theory is you know the the Merkel group however we post as call data all of the different transactions that made that state what it is that the transition the state from the previous Merkel route but notably it is not actually processed by layer one so we are still using layer one for storage although not storage the way that we store everything else on the chain this is called ADA which has gotten massively cheap recently I think it's what sixteen gas per byte so yeah that's very helpful thank you yep no one more quick question in the chat Marto said what's the incentive of the aggregators they get some eath maybe I missed that yeah so that wasn't it either but um yeah the aggregator will like we said that the promise of layer two is lower fees but there still will be fees and the aggregator will still be rewarded it's due to economies of scale they can charge much less for each individual unit of work and you know still make a decent profit well you know making stuff cheap for you cool so now getting on to implementation so the first that we wanted to do was yeah okay we understand optimistic role and we want to implement a simple proof-of-concept get in users hands see you know if there's a bear there right so back when we were the plasma group we for Def Con last year I worked together with unis coop and created something called unipeg dot exchange many of you might have used it but in essence we we built out up to mr. guerrilla we've built custom contract code for Eunice WAP as well in layer two and built out all this stuff that we just went through and except for the deposit and withdrawal because it's all fake money for you know big exchange but we built that out and had a little trading competition at Def Con and people were able to see what it would be like to use optimistic roll up and see what you know what that user experience would be like so you know this was just a screen screenshot of you know a specific trade but you know we're looking at you know less than half a mil s than half a second to get compromised instead of you know much much longer on layer one cool great we're done right or I should say when when are we gonna have more so all of our stuff is open source so you can go in and see you know as I said we did create a custom contract code and that makes asset because that means that like for every single contract they're just gonna come on later - we're gonna need to write new code and that for a scaling company is not very scalable right so we need to be able to do better than instead of ya scaling by writing new contract code for every single thing so that brings us to the who Vienna and and what we did not so just to highlight a couple of the problems bleh or - yeah it's it's hard to audit right if we're you know one all of the different layer to code needs to be audited but then if we're writing new contract code that needs to you know act and complete parity with layer one that's really hard on right also every incompatibility with existing existing developer tooling is terrible right because then you as a developer need to figure out am i developing for layer 1 or layer 2 and what you know what do I need to change in order to adjust to the environment I'm working with right and then yeah like like we said it's a huge burden for existing l1 contracts if if they have to write new code if they have to you know maintain two different ways of going about things that's gonna be trouble right so think what we set out to do is we want an EVM that can execute optimistically off chain and also execute on chain so you can write the code once and use it in both places right that would lower your audit risk that would make your auto spend just one time in order to validate contracts that will work in both layer one and layer two right and then ideally it should be compatible with the existing developer tooling and simple to implement not it and yeah efficient to evaluate state transitions on chain right like we needed to not take forever run out of gas right so yeah this gets out the the motivation like you yeah if instead you know swap in custom code if we could just you know have a general purpose solution for this that would be ideal so that gets us to you you know OPM so what our goal with the OPM is is if we notice in layer two that there's an invalid state transition that we can you know run that exact same thing on layer one exactly so the OPM is an EVM implementation which can be run off chain and then executed on chain so that's exactly we were talking about for frog groups in the on chain OPM the evaluation is done inside of a containerized environment so you know before when we said we put a blockchain inside the blockchain here it's starting to get very very much more like that right so we we wrote basically EVM inside of a smart contract and we'll show you the components of that but the three are there's a transpiler so well yeah there's a transpiler a safety checker and an execution manager so translation is the the reason that we need to transpile in the end the reason so if we're going to put a block sure if we're going to put an EVM inside of the EVM and more importantly if we're going to be able to take layer two state transitions and evaluate them on layer one we need to account for the fact that they're gonna have different states right the layer one state and layer two state are going to be different there's going to be contact it's missing so basically what we need is we need all of this to be like a static function that we're able to call in and we're able to provide it inputs and have the exact same logic and get the outputs of unity right so in order to do that we need to make sure that none of the code that we're that we're using can modify state outside of the state that we're allowing it to modify so that's where translation so we have the execution manager that we're talking about is literally a smart contract through which all execution flows so that is our execution context so anytime you're going to make a call any time that you're going to ask for environment context or anything like that you're actually going to interact with the execution manager so that's where translation comes in so let's say that this is your contract code you're you're pushing you're adding your you're storing well the moment you go to do an S store right you are going to modify state that will ultimately affect the context of the layer in which you're working so we need to transpile that right we need to somehow make your contract code static so what we end up doing is taking that s store and instead of you writing storage to the chain you are instead calling a contract and having that contract deal with it right so this this is what allows us to in a static fashion challenge any fraud proofs right because now we've taken imagine on layer one we're trying to challenge something generically that modifies State this is is how we end up doing so we're going to transpile that and just on the note like I'm sorry I didn't hear was that uh what did you say yeah there's a little bit of feedback no no I think it was sorry okay I meant that the audio wasn't very clear if you if you can try again or if you want to type that question I can relay it in a second but for now you can produce go ahead we'll cool so I guess something to note is that yeah so we are like like we said we're writing any VM within a smart contract so that is not going to be as efficient this this virtual environment is not going to be as efficient as the EVM itself so there's a bit of a gas overhead but there's zero overhead for State independent code so for instance if you're adding or multiplying or anything like that that's not stuff that we need to step in front of like you know writing the state or calling an external contract or something like that so did that question come through or should I keep going I haven't seen it yet all right cool so the other thing that we need to do there so our transpiler is is what we use to take contracts that you have written for layer 1 and transpile them such that they'll work in layer 2 and layer 1 right though the work in the obeah and so the transpiler will get rid of or more importantly like trans pile op codes that are unsafe and the result of that should be safe but we still need to implement a safety check ourselves on chain just to make sure that any contract code that we're going to deploy in the OPM is safe it doesn't use any of these unsafe op codes it instead calls the execution manager to do all of it so we wrote a safety checker as well and then there's also our execution manager so as we said our execution manager is in static context in which all of this actually takes place so when you deploy a contract you call the execution manager with that contract the execution vendor will actually deploy that contract and it will keep track of the address that you think that contracts at and the address that it knows it and it's local state right that way you can use one address to interact with this contract whether you're on Laird one or and layer two right likewise if you're talking about timestamp you don't ask an EVM per timestamp because you the timestamp of your transaction that is going on in layer two is going to be different than the timestamp in layer one when when a fraud proof happens right so instead you ask the execution manager for a time step and then what we're able to do like during a fraud proof is we actually provide the time stone so then when you ask the execution manager okay like what is the time of this this transaction instead of asking the EVM and having a mess map were able to make sure that it's likewise in that message center right so you know your your address message founder or really like any of you know any of the context that is specific to the chain that you're dealing with whether it's layer 1 or layer 2 so yeah like this when we're talking about that store like this is actually do you walk-ins you're unmuted I'm not sure if you're trying to talk all right moving on so we said like S store is unsafe because you're you're going to set storage and we need to make sure that all of those storage calls are gonna go through our execution member right like when when we submit a fraud proof we don't actually want to change storage han-shan right we want to execute that storage change through an execution manager that keeps track of like you know how is the state been modified in the course of this estrade that I'm proving right so like the SOR here this is the exit execution manager code every time that you your smart contract are going to store some value you're actually going to call the execution manager and it is going to save your storage on its own associated with your own contract right so it keeps track of all of the different state of the entire l2 chain within the execution so that is the same as you know all of these different up codes right if you're like by storing if you're loading or if you're creating a new contract or calling another contract right you're calling contract on layer 1 that is probably gonna have a different address than on layer 2 so the execution manager needs to step in the middle of that and do that mapping for you right same with you know any very good fall so yeah like Weston therapy I'm on so you see with like create and create to you somehow presumably have to like also safety check the new thing that's created right like that seems jerky exactly yeah well yes it actually is very tricky then then can certainly attest to that if he's if he's still on you wrote a lot of that but so that was the reason that there's that the three different things that we said we're the transpiler which does that transportation for us but then the safety checker and then the execution manager so the execution manager anytime that it's actually going to deploy a contract it needs to know that that contract code is safe right and then any contract code that it you know will recursively create will also be safe so yeah there's there's a fair amount of complexity there and so yeah like the execution manager is are basically is our layer two it is a contract that that completely you know runs the EVM in our context and then also you know on chain during frog cruise so yeah there was a lot there do we have any other questions before we move on cool also I think this was Jing who created this nice little image here so current state of optimism we got one theoretical question all right I may have the cards for this but let's see you actually might have might have mentioned it really briefly at the very beginning but could and execution manager like a separate one be on the roll of chain and then have like an another roll up that is being executed on the role of Jean um that's a good question a theoretically like yeah like we should be able to have you know lay or three and layer for and everything but so our execution manager will be deployed in a non trans filed fashion right it will be the only thing that is actually running EVM code whereas anything else that's deployed will will be deployed through our execution manager so it would be it would be harder for the execution manager to do anything that's made of two layer two now that said yeah it could run everything through you know just like our execution vendor liens on the EVM your layer three execution manager could lean on the layer two execution manager to them you know have it be Turtles all the way down another quick question do you have any back-of-the-envelope numbers on how much of a storage hog this contract would be if it were being used heavily on layer one and also like what the cost would be to keep it running yeah so the nice part about layer one is that I shouldn't have too much storage at all right like we at the point of fraud proofs we'll need to make sure that the contracts that are called in the fraud proof transaction in question are actually deployed on layer one but they don't necessarily need to prior to that as well as you know all of the layer one fraud group should be static like it should not modify state other than potentially potentially reverting some of the state route that was committed as part of that block that is fraudulent right so yeah like the overhead on layer one should be very small now be yeah like like we said we're running the EVM in a virtual environment on layer one so each one of these fraud groups will be fairly beefy depending on the transaction that takes place so there might be a large gas fee to prove fraud but that will definitely be you know more than compensated for by the reward that you stand again and as much gas being used for the regular state transitions when you update with the latest merkel route or now so they're just the 32 by you know state route as well as like sixteen gas per you know bite of call data so that that depending on how large your your role up blocks are you know that kind of dictates the gas there awesome thanks so yeah current state of optimism is as we talked about we implemented a simple proof of concept with you know swap and then you know from that we gain some user feedback as well as just like the understanding that this doesn't scale well as we want to do you know we luckily that was really successful and a lot of people were like yes we want this right now and it became immediately apparent that we you know there's only so many of us and then we didn't want to write more code per contract that gets deployed so that led right into the creation of our general-purpose OPM and then something that hasn't really been done yet or tested on our side is you know this generic l1 to l2 entrance and exit we wrote some of that code before for plasma as well as a little bit for although it didn't actually get used for the unit big demo but there's a couple of different updates that need to be made to it in order to get it to work with our current things so there's just a little bit we got to do there and then eventually we'll launch a public test net and maintenance and it sort of goes without saying but we're planning on validating with users the whole way through so we kind of validated with users during DEFCON last year and that is kind of what motivated some of the changes in this generic OPM we are currently you know working with a couple of different contracts on layer one that need scaling to use the OPM for you know to get some of that feedback to test it in in a real environment and get some that feedback as well and we're gonna you know obviously do that throughout the process so as part of that you know anybody here who is interested in you know looking taking a look around or you know kicking the tires on some of this stuff please go to our github you know for car repo take your contracts and transpile them and run your unit test and see if they work let us know if there's any bugs so that is the end of you know like the presentations we have like a short demo I won't show of some contracts that we transpile also I said it before but say it again big thanks to Carl almost all of these slides are his so I'm just repurposing them before we get demo let me know if there's any issues nothing in the discord at the moment but anyone else can feel free to unmute themselves - cool see alright so we can get into demo stuff oh forget that's here so you might recall our you might recall the quadratic funding contracts that Paul and others created for our Chicago area meet oh right there's you know but let's see so we get into contract project here we have you know a couple are different right now let's go back we had a couple of different eligible projects that you could vote for and ultimately yeah that would be sort of like get coin in quadratic funding we're like the less that you contribute the more they're the more individual contributions the more your contribution would be worth and so we have a couple of different contracts there and what I thought would be useful is to take our stuff that we've developed this this OPM stuff in the translation and showing you how like what the developer experience might look like right so I forked that repository and we have a couple of different contracts that I wanted to see like could we transfer all these contracts there because all in them are good developers we there are unit tests which is is great so what I wanted to see is like what is the minimum amount of time that it will take for us to transpile these contracts and see that they work on the OPM right so I went into the project and first thing I imported our transpiler and our full node that contains the OPM and you know which has the execution manager and you know safety checker and everything and I had to make a couple of changes in smart contract or not to the smart contract notably I did not have to make any changes in smart contract but I had to make a couple of changes to the unit just mostly just importing dependencies here as well as the only material change was to swap out the provider that we're using right like now we're not actually gonna use you know like a l1 EVM we're gonna use our ovm right so swapped out the provider and what you see as all these other changes is just the fact that our provider the creation of it is async so all the stuff that was done in this base level described I pulled it in here after the provider is is created those are set off of the provider stuff and then the other material change is just closing our provider at the end of each or at the end of all tests and then the same thing for our other set of unit tests the actual quadratic funding you know just right so our material change is creating the MOC provider and then closing the OPM the other changes I had to make that I didn't really mention because it won't affect many different projects like anybody using waffle or truffle is that with builder they they allow you to specify your version of this ol C compiler but for us to transpile we need you to be able to specify the path to the transfer to be the sole C compiler so our trans Fowler the way that it hooks into regular dev tools is by overriding the sole C version we just pass it a path to our Tran filer so as you can see this is just generic waffle config and the only update that you would normally have to make if you're using waffle is to come in here and instead of using whatever sole c version you're using use our transpiler and then like like I said before make the update to use our provider and that's that so then just to make sure I'm not just smooth talking let me share this so now you should be able to see my terminal I created this OPM branch that like I said pulls in our libraries and wires up the tests to actually use our stuff so when we run the build this is slightly different than what it would normally do and that it's not using builder to compile instead this is running through Sol see-through waffle that will then use our transpiler so it generates the you know the output JSON and the exact same formats and everything it's fully compatible and then let's see we're able to run our tests and see that they all pass so now what's important here well I said see that they all pass before they actually done but what's important here is yeah we're abiding by you know what three is standard we're abiding by all the different developer protocols that you normally would so that you can interact with our layer two RPC server the same way that you would interact with any other node so that really lowers the burden of dealing with you know like if I'm developing for layer one then I have to use this set of tools when developing for later to I've used this set of tools and I have my debug level a little bit high so you're seeing somewhat like the printouts from inside of our know that gets fun but yeah so that's like the only thing that was required and most importantly like there's no change to your contracts no audits that you need to do or anything like that you just need to come in and swap out the provider and change the compiler so I think that's it any other questions a quick question so I'm not totally sure where where is the machine that it's running against like where was the configuration for setting that up yeah so the configuration for setting that up was just so like where is the machine that it's running against when you're using waffle or when you're using ganache when you're using truffle it's just a built-in local chain that gets spun up oh no that's the exact same thing here we just we have our full note that when you that's part of this create mock provider that's why it's async is like it's actually spinning up a node and deploying our execution manager and having that web 3 front-end that you hit in order to interact with it so you and then like the most important part here is that you don't have to change any of your code of your interaction so you deploy contract your you know actual interaction like your transfer or anything like that you are speaking the exact same language that you would to an l1 smart contract to interact with our l2 node and our l2 node is taking that and changing it to communicate with our execution manager and you are getting the exact same results as seen by your unit test functioning okay that that makes sense Thanks and then follow-up question there how what's the test net story look like for optimism contracts what do you mean by story like if you had a contract that you would have deployed to Rob's 10 is there already like the optimism executors contract on Rob's 10 and then you just deploy it pointing at that no no will so just like you know for test nets we'll need you know we'll actually need to run our own aggregators to actually create an l2 chain for our test nuts and we will have a public test net that's launching in a little bit here but yeah like you would then interact with that and there will be like on rob stone or on thundering be will be the like actual l1 deposit contracts and the fraud proof contracts and everything everything like that clear the yeah like the roll up chain contract we would still be submitting our roll up blocks to clear one so the mock is this is this is kind of deploy it just locally launching like ganache or whatever like a local like a local l1 and then kind of with your contracts deployed on it exactly so yeah like right here we say create my provider yeah ends up ganache deploys our execution manager and yeah cool any other questions or do you want to get to the casual part of the amido yeah I've got one more question so for for that that contract you just transpiled no no changes to the actual contract code itself which is cool are there any instances where there would have to be even slight differences between the l1 version versus the OB Embree yes yeah so there are three categories of op codes and Ben and Carl can speak to this a little bit better but um one of them is like add multiply stuff that is just like static and doesn't you know deal with state at all and those we just we don't even trans file but then there's other ones that do modify state or ask for context you know like calls or like times things like that that we need to transpile so instead of you making this call to an address that may or may not exist on layer 2 instead you tell the execution managers before and they'll look up the proper address and make sure that it saves everything but then yeah there is a third category that it should be extremely rare of you know op codes that are fully unsupported I can't remember the exact ones off the top of my head right now better Carl do you remember like which ones are currently supported the big ones that are different are like time stamp block number those are really the big ones there's like a weird thing all but that's like you know neither here nor there but the this is more like a differences probably in the way that they will be implement or implemented and so that's you know a question of do we want to you know gave this exact same API and you know implicitly there are differences in how they function or like change the API to like signify that there are those differences so the feature wise they should be should be simple any other questions if not going to close this out by switching to speak or no sorry gallery view and if I weren't can do kind of a virtual round of applause for will that be cool some think okay thanks well