"Optimism: Keeping Ethereum Half-Full" - Kelvin Fichter

next up we have Kelvin from the optimism team and he's going to be talking about how optimism is going to help scale ethereum uh we've seen a handful of talks on scaling today and this is going to be another fantastic one in the series so uh Kelvin is here with us on on this chat so I'll let him uh introduce himself and kick off with his presentation so welcome Kelvin all right hello hello um super excited to be do this uh my name is Kelvin I work for optimism and I do a lot of random stuff working on this extremely cool project so I'm very excited to be able to talk to you about this it's kind of gonna be a fun presentation it's not going to be too uh not going to be too heavy not going to be too light so I hope that everyone gets something out of this and let's talk about the the very cool things that are happening in the scaling space right right now all right so I need to share my screen let's get that going all righty and there we go I believe we're good to go good to go all right optimism keeping ethereum half full all right if I can here we go all right so kind of the first thing that we need to understand is why EX exactly we are even talking about this right now so in a nutshell right this is how ethereum Works um right you kind of tell ethereum what you want to do uh you know whatever whatever these people are saying and uh you know ethereum is like this little family business ethereum it here's your little transaction and then it uh you know processes your your transaction and gives you a result right this is the basic flow of ethereum and you know this is kind of a way to look at how this execution really works I sort of a very simplified version of this execution and the important thing here you don't really have to understand much about this uh this diagram right now but the key things are what a theum really does is it's storing your transaction data and results and it's also doing the actual transaction execution and that means running smart contract code um and the thing is that that data storage is pretty cheap like hard drives are pretty cheap but execution on ethereum is quite expensive and a majority of the cost on ethereum right now comes from the fact that that we have all of these new smart contracts that are quite complicated and transactions burn gas like crazy so you know this is sort of an updated uh an updated picture of ethereum today and uh we kind of just shout loudly and hope for the best uh you know we've got we've got this person with very long legs and one arm saying we Unis swap we've got a large uh baby screaming for more yams we have this uh we have this gold medalist with gold legs and Lambos for feet asking us if we've ever heard of Bitcoin and this is sort of what happens to ethereum uh in the face of that so you see this is ethereum is completely swamped and everyone's really sad because there's there's so many transactions to process so how do we solve this dilemma well there is sort of a clear idea which is uh child labor child chain labor in this case specifically we don't condum child labor but you can see we go to the Next Generation we get we offload some of our our work to the uh other people that we have sitting around in this case offloading that work means doing the computation somewhere else on optimism so here is the optimistic execution model and again all you really have to understand in this slide is the transaction data still gets sored on ethereum but we stick the transaction on ethereum and then we read it and we say okay what does this transaction want to do and then we kind of run it in sort of another version of ethereum this layer two version of ethereum and that's where the execution happens and then we publish the result back onto ethereum and because this execution is not happening on ethereum anymore and we don't have to have all of the ethereum nodes doing this execution right so we do the computation outside then the fee for this transaction is just going to go way way down because we don't we don't have thousands and thousands of nodes executing these contracts um and instead we just do it on L to so right this is our uh you know you've got all the kids doing all the work the child chain doing all the work here and the fundamental problem that arises here sort of the this this looks very very simple in theory but the fundamental problem is this Advent of fraud right so what what exactly is fraud well we have these contracts that are storing the transaction data and then Layer Two gets the transaction and executes the transaction um executes the transaction and then we get this result that gets published on ethereum but ethereum didn't actually run this transaction so how could we how does ethereum know about what happen ethereum doesn't know whether the result that was published is actually valid and so you know on Layer Two you can pretty much the people who are publishing these results can pretty much claim anything any possible result result and uh layer one has no clue they kind of just have to accept it ethereum kind of just has to accept this result because it hasn't done this work for itself so in this case uhh everything is now candy so what what are the solutions to this General problem well you basically have two options here you either have moon maath or not Moon maath which which is just making ethereum do the transaction again so fundamentally what you are trying to achieve in one of these two solutions is make ethereum know what the correct result was and so moon maath is essentially proving to etherum that your result is correct and the not Moon maath way of doing it is making ethereum just run the transaction again um and these each have their various trade-offs but I'm going to take a look at the Moon math route first and then we'll talk about sort of the path that we've taken in tackling this problem so you know option number one moon maath right you get uh you get this kid to do it and I didn't need to even Photoshop the glasses on this kid so you just know that uh that they know what they're doing and this essentially what you're trying to say is this result cannot possibly be invalid so you provide a transaction result to ethereum and you give some proof that it can't possibly be invalid and obviously you want ethereum says prove it and you provide this sort of complex uh mathematical structure that convinces you on layer one that this result was correct the tradeoff space with this sort of approach is that it's quite confusing to a lot of people it's it's quite difficult to understand uh it's not necessarily developer friendly and it also limits you in sort of the design space of how you can build your applications you typically cannot just build a solidity smart contract and deploy it to a system like this because these these proof models sort of need to be uh sorry you need to build your applications in a way that you can then go and prove that the the the result of executing your application was X or Y whatever uh and often times you have to adapt your application to the proof system rather than the proof system just working for for any arbitrary application and especially today I I think that this space will definitely grow in in the future but right now it's sort of quite early and quite difficult to use so what is option two well let's just briefly bring back up our our old diagram here we uh have this you know this suff on ethereum that I called the rollup contracts and that's that's what we want to take a look at so what actually are these rollup contracts because I kind of lied it's not this simple right essentially there are three contracts that or three sort of main areas of these contracts and the first two of these the sort of canonical transaction chain and the state commitment chain are are pretty straightforward so the canonical transaction chain is just where the transactions go when people people put them on ethereum right so sort of kind of think of like your your your M pool or something like that where this is an append on the log you put transactions in there they stay there forever they can't be deleted or anything and this is what the layer two nodes then read from in order to know in the ordering to execute transactions on Layer Two then the state commitment chain also pretty straightforward is is also an append Only log except that so this is where the the transaction results go after you've executed after the layer two UNS have executed the transaction the transaction results get posted to this state commitment Cham and this is sort of readon or sorry uh yeah read only a pen Only log but there is a case in which this log can be this uh this state commitment chain can be deleted and that is as a result of something in this fraud verification contract and that's exactly what we want we want it we want a system where somehow we can say you cheated and therefore the result that was published is not invalid or sorry it's not valid anymore and we need to delete it and somebody else can publish a different correct result instead so you know this is the this is the general flow I say I think you cheated right and I say to the Contra oh whoops I I messed these slides up uh this one this this should say they didn't cheat whoops my animations are quite rush today but point being if the fraud verification contracts recognize that you did not cheat it won't do anything it won't touch the state commitment chain but if the fraud verification contract say okay wait a minute the result that we found by when we executed this trend transaction again on layer one was different than the result that was posted uh or or supposedly executed on Layer Two so that result was fraudulent we need to go in and we need to remove that result from the sort of list the can not not canonical because we can delete it but this list of of results and then we have a timeout window that says You must prove that something is fraudulent within a certain amount of time from when the result was published and we assume that if you don't try to go through this fraud process after that amount of time then you you just figured it was it was uh valid and not fraudulent and we just after that it can no longer be deleted so this is great because this is why we kind of call it an optimistic system in in the in the ideal case that people are just sort of motivated by profit or whatever they won't try to cheat or and if they do try to cheat then we can challenge them but if they don't try to cheat we don't have to bother challenging them right because it's it's only necessary in the case that there is actually fraud so as long when people are submitting valid transaction results it's much much cheaper because none of these transactions actually have to be executed on ethereum itself so now the really fundamental question is how do you make this work this is all sort of straightforward in theory getting ethereum to just do it for you but but how do we actually do that and the uh the meme answer is is this or this which is basically that we go over the whole transaction together on layer one through sorry whoops messed up that that slide whatever okay yes the fundamental problem with any of these sort of systems essentially can be described like this there's a smart contract and it has or it makes decisions based on something like the current ethereum time and ethereum says you know it's this the current time stamp of the current block is this and time stamps are just one example but there are a lot of things where there's the result of these sorts of op codes stuff like time stamp is going to be fundamentally different between layer one and Layer Two so the current time on layer one or the current time on ethereum is going to be different from the current time on Layer Two And if we execute this transaction in a different block on layer one the current time will be different so all of a sudden this transaction is no longer deterministic and and we can't just if we run this transaction on layer one odds are it will come up with a different result than what we got on Layer Two but not because we did anything wrong just because the current you know that uses an OP code a stateful op code and sorry because it uses a stateful op code and this this adds a sense of non-determinism and so we need to fix this right essentially we need to figure out what are the things that contracts can access that are dangerous to us and the answer is storage contract storage other contracts and information about ethereum like the block number and if if they are able to arbitrarily access this information then they could interact with a contract that doesn't exist on layer one when we're doing the verification step or so doesn't exist on Layer Two when we're doing the verification step on layer one and that would cause this non-deterministic Behavior so what are the codes that we don't really care about the safe op codes that we don't have to worry about you know basically the pure op codes so add subtract push pop you know the stack op codes M load s store these things don't have anything to do with modifying the state and but what are the tricky op codes so we have sort of the ethereum state op codes like timestamp and number SL load and s store for for accessing contract storage call create and and all of their various different forms so all of these all of these op codes give us issues and if we just allowed contracts to arbitrarily use these op codes we could essentially never guarantee a deterministic execution of the the L2 transaction on L1 when we're verifying it so how do we block them well we need to block them because we can't allow people to use them so we have this thing called the safety Checker and the safety Checker is literally a smart contract that static ly analyzes contract B code and it says oh I see that you include an SL load I'm not going to allow you to deploy this contract this contract is not allowed to exist on Layer Two because you use one of these ban op codes but you know if you're a a if you're a good contract and you decide not to use any of these Bann op codes then you're totally fine you can deploy on Layer Two because that means that we go back and execute it on layer one there's no chance that you will use one of these sort of op codes that give us a headache um but obviously these op codes you know especially things like slad s store and call are are extremely useful and we can't live without them so we how do we actually get around this problem how do we make sure that people still have access to these op codes even if we need to ban them and it the answer is that we get around it by taking all these op codes and we replace them we replace them with our own sort of custom op codes and these are implemented as calls to a special contract called the execution manager that sort of handles all of the logic for these op codes and it ensures that that these op codes will always behave deterministically based on sort of some setup phase when you create the initial or when you want to run this fraud verification step and in order to sort of translate from solidity code to this these special op codes these calls to the special contract that handle these op codes for you we have a a custom compiler a custom version of of the solidity compiler that will instead of allowing you to use these op codes just immediately translate them into calls so this is the general flow of the execution manager um here if we just had the execution manager with no context uh and a contract wanted to know you know what's what the current time is well if the execution manager hasn't been set up properly then then it doesn't know what time it is and then all of a sudden it doesn't not have any clue of what to do so really what we need is the two-step thing where we have these two contracts called the execution manager and the state manager and the way this works is that the the users populate the state manager with what the state was on Layer Two before this transaction that they wanted that they want to sort of verify on layer one and they say this is exactly what the state was you know these are what the contracts are it's not all of the state it's only the state that's relevant to this particular transaction and you load that into this thing called the state manager and then when you actually execute this transaction during this fraud verification process um when these contracts for for instance ask for what the current time stamp is the the execution manager will then go into the state manager and say okay hey what what time is it right now and it will access that state and return it back to the other contract so that's sort of the the nice ideal case of a very simple interaction but let's say that this a contract we're trying to interact with uh a contract that has not been set up on layer one so a contract that uh the the user who is trying to prove fraud is has has not sort of initialized setup made it ready to be used during this fraud verification process then what would happen is that this in order to to actually let's say do a call to this other contract the contract would send request this call from the execution manager execution manager would ask the state manager do you do I know about this account has this account been set up does does this contract have the ability to access this other account and uh in this case if the answer is no then all of a sudden everything has to immediately stop and this is really important because everything has to immediately stop so that the contract cannot make decisions about the presence or absence of information during this fraud verification process because on Layer Two all of this state is always available so if it can somehow recognize that oh hold up some of this state is not available to me it can make decisions based on whether it's running on Layer Two or layer one so we have a lot of of very interesting very interesting problems to sort of face here where the the execution manager has to figure out how to immediately halt the entire execution but it can't just revert because that op code is a call and if it reverts then that revert can be caught by the contract that called it so what we end up having to do is make sure that the contract that called it also reverts if the execution manager reverts in this way so there's this really fascinating aspect of having to sort of hijack reverts and figure out how do we carry all these things up because we can't allow uh we can't allow execution to continue and this is all sort of reflected in our in our contracts right now but it's an extremely interesting problem it's it's somewhat non-trivial and all these sort of things that you would think are are quite easy running evm code on ethereum are actually quite difficult when you're trying to prevent access to to state that contract should not have access to of course you know everything errors that all right last little technical bit because we'll do this the the one important thing that we all will need is be able to send information between layer one and Layer Two so that we can for instance you know transfer erc20 is from ethereum onto you know this this optimistic role system so doing that from a layer one to a layer two is quite easy you kind of just tell ethereum what you want to say ethereum puts it in the layer 2 Chain as a transaction and it's just there and you can access it on Layer Two that direction is quite simple it's basically just sending a layer two transaction um the other direction is a little more difficult the other direction you say something you have a message that you want to say layer to like you know transfer some number of e20s or just High whatever it is and you sort of acknowledge that you put that in the chain on Layer Two but you don't what what gets posted to layer one is not the full state of Layer Two because then what's sort of what's the point uh you post sort of you post the state root of Layer Two on layer one so someone actually needs to come in and say okay there is a message on Layer Two and I can prove to you that this message exists on Layer Two so please relay it to a contract on layer one and so you say okay I believe that there's this message ethereum tells you to prove it you give a Merkel tree proof that this message was actually included on the layer two chain it says okay is is that you know is that have we waited long enough that it's we're sure that it's not fraudulent and then as long as that proof checks out we send that message off to a contract on layer layer one and everyone's happy and to finish this off other really cool stuff we can do custom op codes we did uh we have a native account abstraction so eoa account or externally owned accounts don't exist anymore we can do any eips that we want whenever we want and we have lots of plans to do that we have geohot commits and it is extremely cool just trust me look at the repo and you will be very excited so what is the status well the contracts are being audited right now um you can see the latest contracts in the contracts we2 repo we have a test net up and running and we're doing a lot of testing we are hitting those Integrations because we got to make sure that everything works beautifully and we're hiring so if you are you know a compassionate person who loves public goods and you know how to use Ms paint for presentations then please come talk to us because we are absolutely hiring and absolutely looking to do more cool stuff with cool people great well Kevin thank you so much for that amazing uh talk and the lovely visual um there's a lot of people for the hackathon that are working on integrating L to Solutions so we'll be sure to recommend them uh to try out optimism um and give you feedback directly um we are at time but uh what I will do is I'll just kind of ask a couple of smaller questions that uh maybe you can just clarify for the audience and if more questions come up on our chat um and if you have time you can just uh join the uh the live. online.org uh page to answer them and chat directly so you kind of talked about how the execution manager works and and the op codes that are at least detected and prevented in some capacity um it's like a two so two branches to that scenario the first one being uh what actually is impossible if you are trying to deploy to uh to ovm uh in terms of like what you can do on mainnet but you can't do on um on ovm and then the second one being just kind of as developers think more about supporting layer twos and in optimism um what's kind of like a blocker for them or what should they think about differently or what what do they have to do very differently than what they're used to U that they should keep in mind as they consider optimism yeah cool good questions um well pretty much anything you can do on layer one you can do on optimism as well I can't off the top of my head think of anything you can't do um you can write your contracts in solidity you can basically take the contracts you have right now just use our custom compiler and deploy it as is um and you can actually do more because we have these sort of custom op codes and things like that that we can always add quite easily much much more easily than we could on on layer one so we're going to do a lot of experimentation with potential eips that we want to try to implement potential new OP codes so in a lot of ways it's sort of an expansion on what's possible on layer one and the the sort of biggest shift from from an application design standpoint since you can just run the same solidity code uh that doesn't really change the biggest shift sort of comes in the in the message passing where you if you want to have applications where part of it runs on ethereum and part of it runs on this uh optimistic rollup system they need to talk to one another and we have contracts that sort of abstract that for you and let you really easily do that but you kind of need to understand what's happening to to some extent that there's there's a delay here between the it doesn't immediately go to the contracts on layer one or Layer Two and you have to wait a little bit before those transactions go through but really other than that you can kind of treat it just like you would treat your contracts on ethereum awesome uh that sounds like a pretty good good sell because you can just directly support scalability in your project so um excited for uh the test net to get a lot more usage and and Bucks uh cleared out and then so that it can become a reality and uh want to thank you again Calvin for doing this awesome talk and uh we'll we'll see