Optimism 🛠 Deploy to Optimism in 0.5 Seconds or your Money Back

[Music] [Applause] cool oh okay we good all right we're good we're good all right um this is uh deployed optimism 0.5 seconds of your money back um the first like five minutes of this talk are going to be me talking about how to deploy in the second 40 minutes of this talk are going to be talking about optimism in general trying to answer like architectural questions about uh what's going on under the hood so this should be pretty quick because it's very very easy so if you were working on optimism maybe about a year ago you would have known that uh optimism used to be really annoying to to deploy to because we had this custom compiler it was a total nightmare uh and it made people really annoyed so we got rid of it and i'll talk a little bit about how we got rid of it but for now the reality is it's really really easy to deploy so anything that runs on ethereum should run on optimism one to one the gas is all the same the contracts are the same runs the same byte code you can use solidity viper whatever you want works really really well and we spent a lot of time trying to make that happen um so deploying with remix it's very very simple first you got to add your network the optimism network to your to your wallet so i made this website called chain id dot link and you just do you go to this link chain id dot link question mark network equals optimism and hit connect oh and of course i probably have signed oh no no there we go oh it's because i'm already connected so whatever i'll sign up to something there we go okay right boom connect to my uh to optimism uh and i'm connected to i guess this should be this should be optimism whatever cool all right so you you know you do this with whatever wallet you have connect connect optimism and then you know go to go to remix and uh write your contract and i have a simple contract here that doesn't do anything it doesn't matter this is simple but it can be as complex as you want you know save it connect metamask to whoops to your injected web3 provider and that's it just deploy and um this is what is this this is on main net so there you go deploying on mainnet that's it that's easy it's the same thing it's really simple just like deploying onto ethereum except it's faster and cheaper um okay go back to this uh doing it so with remix pretty straightforward uh hard hat also very straightforward same general concept just add optimism to your network config and deploy um i do have a very brief example of this straightforward look at me this is my network config that's that's all i dated i just added an optimism network and then i can deploy my contracts so i have my adder same thing as before i have my deploy function same thing as before and deploy if it'll ever deploy there we go that was easy okay that's it it's the same thing it's like that's i this is why this talk is really boring it's just it's just showing you how to deploy a contract um same thing with truffle literally just the same thing you just add options of your network config i can maybe i can share the slides later if you want to link to this but very straightforward same thing with brownie except you don't even need to add it to the network config because it's in there already um and that's it that's literally all it is this is not a very interesting talk so i will talk about uh the more interesting side of things which is how optimism uh can actually be this easy to use which is as a result of this concept of evm equivalence which is sort of a stronger form of evm compatibility where this trick is you know the evm is a very delicate beast and every time you change the evm a little bit you you know you can say that you're compatible because you're compatible with all the rpc endpoints but if you change the behavior of the evm all of a sudden you get into sort of a weird uh weird state where you get developers who are relying on some very small feature of the evm and um and you've told them that you're evm compatible but then this one feature of the evm doesn't actually work so are you really evm compatible i would say no but because so many people have said on evm compatible that we've come up with this new idea of evm equivalence where you're essentially just running an evm that is like a production evm that's being used to run the ethereum mainnet so it's the same exact virtual machine and you can actually like take this evm and really run like a mainnet node with it in this case we're using gethsevm to do this so we literally our client runs geth okay so um yeah so let's let's sort of describe at a high level why is this okay let's describe it a high level um how this whole system even functions because it's quite interesting you have your layer one oops there you go you have your layer one and your layer one is pretty you know what that looks like it's a block chain right and then what we have is these two components we have this thing called an op the op node the op node and it pulls transaction data from layer one sort of just like pulls in layer one blocks and from these layer one blocks it deterministically generates a list of layer two blocks and then it takes these layer two blocks and it executes them like right at this point you just have like a block chain on layer two and it's fully derived from layer one so just like a pure function on layer one blocks that generates layer two blocks and then you need to execute those blocks so executing the blocks just happens in geth we take geth and geth has this very beautiful api called the engine api which is sort of a new thing for the merge um but what it allows us to do is to treat geth like a like a thing that can be driven there's the you know in after after the merge you'll no l no longer have this the the execution and the consensus parts of ethereum are being split into two pieces so you have the part that executes blocks and you have the part that figures out what those blocks should be and we sort of realized oh well we can actually apply the same exact idea to layer two why not you get the blocks from layer one that's the consensus and you do the execution and this can this execution client so in this case the block execution literally just happens in geth which gives you this like perfect evm equivalence because you're not doing any sort of like weird translation into a different virtual machine you're just running geth so everything just works how you would expect it to okay first of all before we do that does anyone have questions i don't want to like i guess it's a workshop it's kind of like a lecture um all right well if people have questions just stop me we could do the whole microphone thing um let me move this up okay okay so um this is there we go okay so what um part of the safety of like of an optimistic roll-up is sort of the ability to prove oh let's let's go a little a little back essentially if people aren't familiar with the idea of an optimistic roll-up you're publishing transaction data you take transaction data from users you sort of bundle it together and you publish it to layer one and then you what you're also doing is you're executing these blocks and you're generating the results right you're um when you execute a block you get a resulting state route that says this is what the state of the system is you get a bunch of sort of information about the state of the system and we we execute a bunch of blocks and then after a certain number of blocks we take that sort of the state root of that block and some other information about it and we publish it to layer one and the idea is that if we publish this data to layer one then contracts on layer one can actually start to make decisions about what's going on with on layer two and you can use like merkle proofs to basically prove something about the state of layer two given one of these sort of checkpoints and it allows you to do so deposits into a rollup are very very easy it's just a transaction on layer one and this allows you to do withdrawals from a rollup because you can you can do a proof that says i can prove that you let's say you burned this amount of money on layer two i can prove that to you because i have a merkle proof but i can only do that if i have something to do a merkle proof against and that's what these checkpoints are so we do these regular checkpoints that get published to layer one and this gives something that contracts on layer one can execute a proof against so that they can make decisions about what happened on layer two and this gives you deposits and withdrawals so but the question is how do you actually guarantee that this thing that is being published to layer one this this state route or this output that's being published to layer one is actually correct because it could just be anything i mean the whole point of the optimistic rollup is that it's not you are not performing the the execution of transactions on layer one so ethereum has no clue if the execution result is correct you're kind of just telling it this is what the result was but it doesn't have any proof of this so what we want to do is we we have a program that we're running and we want to prove that that program is ran correctly right we want to take this now i'm getting these sort of mathematical stuff but it doesn't really matter that much we have a program and we want to prove that the program ran correctly that's you know that allows us to say based on the transaction inputs that we've published to layer one the output the state route that we publish to layer one is absolutely correct and it can't be wrong so how do you do this proof well whatever you have a program what does our program look like our program it takes l1 blocks it generates l2 blocks then it executes those l2 blocks and then it takes that that finds that final state root from the last l2 block it's a very simple program um and then you know more generally what is a program because it's important um we have a machine architecture it can be whatever we want it can be like x86 or it can be something even simpler it could be the evm and then we define operations within that architecture so essentially we have op codes right so the evm has a bunch of op codes x86 has hop codes blah blah blah it's a series of operations right um and this is universal like this is sort of what a program fundamentally is and what we're really trying to prove is something about a a series of execution steps inside of this machine architecture right it could be the evm we're trying to prove this opcode happened then this opcode happened then this alpha could happen and i actually executed those opcodes correctly so we have this series of steps the evm is fully deterministic right so given a starting state and the ebm everyone gets the same result this is why this entire blockchain thing even works and um and we want to prove that we ran let's say the evm correctly so we sort of want to prove this the the the correctness of this trace of you just think about the list of execution steps that's what i mean when i say a trace just the list of things that happened except on ethereum we don't want to re-execute every single step because if we wanted to re-execute every single step we'd be wasting a huge amount of gas and it'd be really really expensive because the whole point of the optimistic roll-up is to sort of not have to do all this this work and you really don't want this proof process to re to be executing an entire ethereum transaction because it's really hard and really expensive so yeah so the question is you know how do you do something like this with the evm because it's a very complicated program the answer is well either you go and you build an evm interpreter in the evm which is a huge amount of effort and it's not worth it or you can just do something much uh much cleverer where you can take the um you take our your program and you compile it into a much simpler machine so our program here is geth which is sort of like a wrap slight wrapper around the evm and then we have these little other parts that i talked about trade you know figuring out the l2 blocks and figuring out the final state route you kind of think that of that whole thing as your program and what you're going to do is you're going to compile it so you're going to compile it into a simpler architecture right i mean you know you you can compile geth right this is a thing that people do so you you take your program you compile it into a simple machine architecture and if we want to get an execution trace out of this we run our program you know it's a compiled binary we run that with some input and and we run an emulator and at every step we sort of record what the state of the machine was so we take you know what is the state of the of this virtual machine at step zero okay the memory is this the program counter is this the stack looks like this you take that you take a snapshot of it and you do that process for every single execution step so you can't general you can't really execute this whole thing on ethereum a single transaction generates a massive execution trace so you could i guess do this proof by just just executing every single step on ethereum and seeing what the result was it should give you a result it's a machine a virtual machine you can run it on ethereum just like you can run pretty much anything else on ethereum so you can run every single execution step on ethereum but it would take forever and it would be really really really expensive so you don't want to do this you instead introduce this idea of bisection games and this is sort of what truebit truebit really pioneered years ago and getting into some more annoying matthew terms but you don't need to know about it the idea of the bisection game is that if you think about your program as a series of execution steps then uh and you say that the starting step step zero is based on a known state we all agree on step zero but we disagree and as we agree on step zero because we must have if sort of if you think about it from the optimistic roll-up standpoint let's say that each one of the things corresponds to a block if i'm challenging block n and i and i it's because i disagree with the result that was published for that block but doing that is sort of an implicit statement that i agree with the result of block n minus 1 because if i didn't agree with the result of block n minus 1 i would have challenged n minus 1 instead so you can follow this logic backwards and backwards and backwards and the idea is that you you are you should be incentivized to always challenge the first thing that you disagree with because if you you should just challenge the earliest thing because if you wipe whatever the point is you're going to challenge the earliest thing and so we agree on the starting state because the starting state is the output state of the previous block which we agree on so we agree on the starting state but we obviously disagree on the sort of the ending state of running this virtual machine and we have to figure out which one of us is right and if you if you sort of think about it if we agree on the starting state but we disagree on the ending state then at some point in the middle there must be some step where we agree on the previous step but we disagree on the next one that's just sort of you know i could prove it but it's it's sort of intuitive at some point you you got to a point where you disagree so you want to find out how can you find this first execution step where you disagree because if you can just get down to executing a single execution step that's very very cheap and you can do that on ethereum no problem so you want to figure out how you and your sort of your adversary can you know the person who published this result this this output this claim about the state of lair 2 how you two can sort of play a game and figure out where this first disagreement is and the process we do is we generate our execution traces and we generate a snapshot of this of this machine state at every single execution step and then we turn that trace sort of we hash that that snapshot and then we generate a merkle tree out of it so if you think about the machine starts here and then the machine goes into into its next state and remember this is all deterministic right the machine just operates on a state and it produces some output state so you go from step one to step two to step three at each point you're taking a snapshot and you're hashing it and then you generate this big merkle tree out of this this array of machine states and so then you want to try to find you and your your sort of like i said your adversary are trying to find the first step that you conflict on and so what you do is you look at you you start making your way down the merkle tree and you look at each root and you say do i just do i agree with this root this intermediate node of the merkle tree or not at this point let's say we've gone down the merkle tree we say okay we disagree on both sides remember this is in order of the execution so this means we disagree on the second half of execution and we disagree on the first half of execution somewhere in the first half so we always want to find the earliest steps so we're going to start thinking about the the first half of the execution and let's say okay we agree we sort of go down here and we agree on the first two steps right we agree on this root but we disagree on this root and so if we ground this root that means we agree on these two execution steps we agree here we agree here because we both have the same thing in our little merkle trees that we're comparing but we disagree here so now the question is do we disagree here because this is different or do we disagree here because this is different because they're both part of this this intermediate node and then maybe you know as an example you say okay we disagree because this is different but we actually agree on the contents of this so by doing this game we just go back and forth and we compare our trees and we try to find the first node in the merkle tree where uh where the hash is different and that first note in the merkle tree where the hash is different represents or the first leaf node in the merkle tree represents the first execution step where you agreed on the previous step but you disagreed on the next one so what we're going to try to do is we're going to try to execute this step because you're saying that the result of this step was x and i'm saying the result of this step was y and we're going to figure out which one of this is right and we're going to do that by executing this machine step on on ethereum so how do we do this it's pretty interesting we literally just built a machine interpreter in solidity so there's a we picked we deliberately picked a very simple uh simple virtual machine called or just simple machine architecture called mips and it's about 400 lines of actual solidity code so you can actually see like a like a vm interpreter on chain for for very little code which is really cool so just to reiterate the full full challenge process in a nutshell someone publishes a proposed version of the l2 state this takes the form of a hash then somebody else comes in and challenges that state and then the proposer and the challenger play this game where they go back and forth and try to find the first step where they disagree and so you find that step so one of them now executes that machine step on chain literally just like a virtual machine instruction on chain and this is you know it's just a program like a machine architecture is just a program itself that takes instructions and generates some output so you execute it then ethereum knows who's correct because they've ethereum's the one doing the execution so it knows who wins and if the challenger wins then the state proposal is invalidated so this means that somebody else has to come in and say actually this was the correct result of executing that block on layer two or whatever it is and then oh well whatever so optimistic roll-ups are a solved problem i think this is actually very true they're complicated but not really in a lot of ways they're very sort of you know that architecture that we were describing is actually very very straightforward and the actual the changes that we made to geth are like less than 400 lines of code total um and i could have gone on for way way longer but i won't so let's we can go to questions if people have any questions about optimism how it works any of these little there's sort of a lot of jargon in here but whatever i mean yes me have a little an extra mic okay yeah thank you for the talk server um my beginner question i would say would be like what's the benefit for me to deploy to optimism versus ethereum mainnet yeah sure yeah so um the primary benefit is just that you're gonna get essentially the same exact experience as on mainnet except it's gonna be way way way cheaper and and we could do this by kind of separating the execution like mainnet you have thousands and thousands of nodes that are executing all these things optimism it's just the people who care about optimism there's just like a lot less people on the network so it's just cheaper in general um but yeah so it's cheaper we've added some interesting stuff to make it also faster which is sort of these interesting things you can do when you when you are a layer two you can introduce this idea of a sort of sequencer which is a block producer and the block producer can give you really really really fast pretty reliable confirmations and so you get sort of a much snappier experience you get to see what your transaction did within like a second or two instead of waiting 15 seconds and you know when constructed correctly these things basically give you the same security guarantees as ethereum with basically one added security assumption which is that there's a single honest participant watching the chain and willing to perform the challenge process if necessary so you get basically all the benefits of ethereum with a with a single honest party assumption you're not trusting like a majority of some set of validators just like one person on the network is incentivized properly to do this and um yeah and it's cheaper and faster so and you also pay with ease and gas yeah you also pay in east with gas so you can yeah thank you of course other questions sure let's uh we'll pass the um i i think we read up somewhere online that one of the sort of subtle differences between deploying on ethereum mainnet and deploy on optimism is that the it says something about being careful about using uh block times for timings in your contract could you maybe just allude to where that comes from why the block time is not consistent in optimism sure yeah so um this basically comes from this like this block producer that we call the sequencer and it's just that you can't make um the the assumptions around the sort of the the what's the word um like the fidelity of the timestamp are a little weaker than on ethereum and it's it's because the the sequencer has a little bit of room um you have to give them a little bit of room in when they can create their blocks and so this technically the sequencer within certain bounds can manipulate the timestamp it always has to be going up and it always has to be basically within a certain amount a certain window of the current like actual ethereum time um but there's leeway for them to to go like a minute into the future or something like that right so so you can't you can trust it for for many things if you're just trying to keep time over the course of let's say days or even hours sort of longer periods of time where that like minute or two minute fidelity doesn't really matter that much but if you expect time to work within very very tight periods of time you sort of have to trust that the sequencer isn't going to try to use that to explicitly mess with your contracts it's just something you need to be careful with if that makes sense yeah okay how does optimism compare to zika volups in terms of like security assumptions and also like speed like now and also in the future i guess um this is a good question the i mean at the moment optimistic roll-ups are like functional i'll say um they're way more reliable i mean maybe except for like stark net which is still still in in alpha um i guess one of the main selling points at the moment is that they're they're very functional uh do you have you know you have different assumptions about this the safety but like really it all boils down to whether you want to whether you want to make a like the one honest party assumption or whether you want no assumption at all and the one real downside long term of the optimistic role is just that you have this basically you need to give people enough time to be able to actually challenge these state proposals and so you need a window of time that we call the challenge period where somebody can come in and challenge something um this both of these things i mean the realistic thing is that optimistic roll-ups are still a thousand times easier to build and so there's there's sort of like the other side of the security argument which is like how secure is it if there's like two people in the world that can really audit it at what point is it you know the more complexity you introduce into your system the more you're opening yourself up to bugs it's just sort of like security ends up being the spectrum and we actually think in a lot of ways optimistic roll-ups end up being more secure at least now um in the long term like i don't know very long term for me five plus years you might see zk roll ups well i i actually think that the the way to build these systems correctly in the future is to do a um to do an optimistic roll-up and then when these state results are published these checkpoints are published immediately start generating a zk proof between the last two checkpoints that have been published and so so in the worst case you get this optimistic roll up if no one's publishing these these validity proofs it's an optimistic roll-up but when people are publishing the validity proofs you can actually you know the validity proofs you you don't even need to think about waiting the seven day period as soon as that validity proof is up you're able to withdraw so now it just becomes a problem of optimizing your um prover so you can get very very fast proving times and um and you can just publish these validity proofs very quickly and so you cut down on your on your withdrawal time to be just the length of the the proving time so i i think realistically that the future is probably going to be like a hybrid optimistic zk thing and luckily optimism isn't designed in a way so you can slap this on the current system and it doesn't you don't have to change anything so i just think it's like overly complicated as my answer for zk yeah cool other questions comments concerns opinions i think we got like 15 more minutes or people are tired we can just just go to bed all right i think we're just gonna call it we can just do uh questions afterwards if people have them cool [Applause] this is [Music] [Applause] [Music] you