Optimistic Virtual Machine: Full Ethereum Smart Contracts with Optimistic Rollup

ETHCC 3 · March 2020 · 41:17

Karl Floersch introduces the Optimistic Virtual Machine and its approach to running Ethereum smart contracts through optimistic rollup technology.

Speakers

Topics

From ETHCC 3, hosted by Ethereum France.

Transcript

do you hear yes do your ear can you hear me I hear you yes I hear you yeah yeah yeah I see that you've met oh it's you see if you remember I asked you and they've gotten to come to HCC and you're still made it thanks wait sorry sorry I didn't quite catch that last bit yeah I asked you to come to HCC in Osaka at DEFCON and I see that you made it so thanks thank you thank you I appreciate it okay you you can start a few I can start you say yep all right

well give me one moment oh I just realized I need to provide System Preferences I'm so sorry it's okay for my sharing screen I will be right back yes and we are good to do

the little screen if possible that's okay all right well welcome everyone it is currently three let me see 358 am so I empathize with anyone who is tired in the morning I unfortunately can't see who it was here however I will be able to see your questions and I would love to see that you are here because I don't want to necessarily just give a presentation where you know this could be a YouTube video so please if you go to slide Oh calm and you type in why 2 3 1 a great great code there you can ask

questions and so I will be I will be perfect hallelujah hello I saw anonymous hello so please say hi tell me how your day is and also just ask questions and stop me basically whenever wherever so let us begin today I'm gonna be talking about the optimistic virtual machine' optimistic roll up layer 2 and a lot of really really fun stuff and it I have an insane number of slides I in fact have something like 600 slides so I don't know if I'm gonna get through everything but nonetheless the dream right we have this dream of taking cryptography economics combining it and giving us all

super powers of the ability to you know use crypto economics to build these new incentive structures these new applications that we haven't seen before and it you know this this this dream has you know excited me for for many years and you know ever since I saw Def Con 0 videos on YouTube though it was it has been you know a real a real real thing to work for and of course unfortunately we're not quite there yet and we're not quite there yet for the most mundane reasons in the universe at least one some part of it right we have we have these transactions that have massively complicated information

you know in these and and we approve transfers with infinite coins and we you know I try to send these transactions and then speed up button I click this feet up button on meta mask over and over again and it still doesn't get faster it doesn't get fast enough so there's just like these fundamental pretty pretty mundane problems that kind of hold us back from a user experience perspective from you know the scalability the actual cost of all of these transactions the speed at which we confirm all of our transactions even things like who's paying the gas fees and stuff and you know I I don't want to be paying thirty cents unfortunately for

all of my transactions and so we we we actually you know the these problems we are so apparent the the potential is so clear but we still have you know a little bit of a ways to go great I got a bunch of people people saying hi well hello everyone great but anyway so we realized this this is I'm gonna kind of give a little bit of a story back maybe about a year ago not even not a year ago this summer a little bit like actually almost almost a year ago when we were kind of looking into this kind of conception of layer two so I you know I work on a lot of layer two stuff I was

working on aetherium two I was working on Casper and now focusing on building out you know aetherium scalability inside of layer two and so basically if we if we you know go back to probably a you know basically last summer we were thinking about and by we I mean optimism in particular you know Ben Jones and myself and a number of others you know Metallica et cetera and we're talking about these these you know optimistic future scones and so I'm not really gonna go into it but basically we realized that if you take the normal you know EVM state machine blockchain and you apply this optimistic layer on top of it then you're kind of you you can

actually what you can do is you can operate on optimistic states and so that means that off chain information so Alice sending a transaction to Bob off chain we can actually take that transaction and optimistically calculate future states of aetherium and essentially do computations on what aetherium will be it was this kind of like weird mindset shift that like really exemplified what it is to be you know lay and layer two and you know and this is something that actually held for four you know all of these different layer two protocols and so we kind of like we're looking into this and getting these like research epiphanies and realizing that optimistic states were based on off chain data and

non chain data and that all of this data is really really you know follows the same format and so these epiphanies kind of lead to a consolidation of all these you know layer two protocols even layer one protocols that we realized we're like really not so different right in there they were unifying frameworks and so this is this was kind of the beginnings of this like you know like a ridiculous optimistic meme but nonetheless you know we realized that if he really has B we we can really take use all of layer two to make aetherium better and so you know I when I whenever I have an excuse to put an aetherium logo on a bunch of hearts I do this so I

did it there anyway so now I'm just here and I can say questions although this part that's kind of just an intro so right we have this problem we clearly clearly clearly need you know scalability we need this instant transactions and we also have this layer to technology which is kind of fundamental and the barriers between all the layer twos are not so different so now I said that the barriers are not so different but let's actually go into the kind of different layer two be kind of meat-and-potatoes this is for someone who really wants to understand like okay what is the layer to space at

a high level what does it look like and so I'm gonna give you this is a lot of layer to you know goodies so let your to block chains all form the same kind of structure and I'm talking about you know roll-ups plasma state channels etc they all have this kind of they're all these state machines they have States the these states accept transactions that transitions it to another state which has another transaction which transitions into an ugly state and there's important properties that must hold for these layer two state machines first oh and by the way this of course is the excuse me head state and so these all of these layer to state machines

they have their state routes or you know state commitments information about the current state of this state machine is sent to layer one so layer one has an idea of what is going on in layer two and in particular the two guarantees that it really needs is it needs to know that one that this is the most recent valid state right so all of these state transitions are green meaning that these are you know valid state transitions and additionally it we need to know that the users who are interested in downloading the state will be able to download at the very minimum the head state of this layer to state machine so these are the

two these are two of the most important things that that these layer two state machines must provide and that is validity which is the you know the state transitions are palet and availability and that is the ability to download the actual head state and so our layer one needs to understand are like parent you know or layer one needs to understand the current state of the world in terms of what users can download and what is actually valid without having downloaded without having verified or your computed all of the you know layer to state transitions directly on layer and so it's this kind of resource constraint state machine because in fact

of course layer 1 itself can also be represented as the state machine and it's a kind of global view of the entire world and so you can actually have multiple of these state machines at different stages with different states and different transition rules and so you're committing all these to layer one and in fact you can even have you know nested state machines where you have one inside of another and in fact this is not you know this is actually not crazy it is you know you can think of it almost you could even think of it as a you know this is a shard and this is they you know plasma chain on top of that chart or maybe this is a roll of it and that's a plasmid chain on or a roll up in a roll up oh it's it's it's all

good and so if you don't understand roll ups I am assuming some knowledge of layer 2 but I'll do my best to define those terms so all of these use limited compute in memory on layer 1 and then as we go from this you know layer 1 state machine we actually get less and less compute and memory constrained and of course the the kind of trade-offs here we make are dependent on our layer 2 protocol and there's a number of different layer 2 protocols so for instance optimistic rollout that's the thing that I'm going to be talking about mostly ZK roll of plasma state channels etc these are all examples of these kind of layer 2 state machines and that's really like what we are talking about

when we're saying we're gonna scale blockchains we're gonna scale this trusted state machine well we're gonna scale it by making these sub state machines inside of it that we preserve properties of and so users can download the everyone sinks the the main chain whether that's you know eath one or the beacon chain and then users can download the head state of whatever the sub state machine that they actually kept about so they this is so the importance kind of scalability aspect here is that user a is only downloading this kind of layer one as well as the you know optimistic roll of chain or the shard or whatever that they actually are interested in but what are the differences between all

of these different layer two protocols right these that's the commonality but what are all of the differences great this is for you so I and yeah I just saw a question and so now I have to understand how to keep going without a even though I want to answer my questions I'm gonna answer a bunch of questions in an interest mode but anyway so comparison of layer two chains so we have this optimistic roll-up zk role of optimistic plasma ZK plasma state channels etc so first all of these must have a liveness mechanism so I talked about availability and validity but the

last component is liveness and soul agnes is just that all of these state rent be state machines they actually must be able to continue but this is kind of one of the this is one of the ones that is is shared across all of these layer two protocols they all have a kind of similar mechanism that can preserve liveness and the reason why you know liveness and validity and availability are kind of three good distinctions and I won't go into entirely but basically we need the guarantee that we can download a valid head state and we can also progress it and so what we can do is we can say ok let's use force transactions it's pretty pretty simple so we have a parent which is l1 we send a transaction on layer 1 and that forces a state-transition on

layer 1 which then forces a stage transition on the kind of child chains so that's just you know to be complete there's the liveness mechanism for all of these that preserves the the liveness property of all of these layer twos but I'm not going to talk about that in too much detail because I'm gonna focus on the availability and validity mechanism which are the distinguishing features so first roll up roll ups have all the same availability mechanism all of the transactions are recorded in order on chain and this allows you as a full node to compute beheads state so what does that mean that means that as a user I am able to download from aetherium the genesis state

right whatever the first state is that this sub state machine was a you know started out in and all the transactions and I'll use that to compute locally you know off chain whatever on my computer the current head state and then I then I can create the e head State and these a validity mechanism so the the thing that distinguishes optimistic roll up and ZK roll up is the validity mechanism and so we need the ability to have aetherium know that this is not only the most valid like a valid available state but

we also need to make sure that it is a valid state uh-huh and so there are two ways to do this the first way is fraud proof so that is the kind of optimistic roll-up and so the way that we do this is we periodically commit to state routes all you know every state transition we're committing to that state route and if there's ever an invalid state route committed on chain then what we do is we expect one user to just say okay I will challenge that state route and I will prove unequivocally that this previous state and that transaction and this post date are and this this results in a different post eight and so with that I can

actually just delete this invalid post state and roll back to the most recent valid you know state route and so this is essentially we can use this fraud proof to say okay I'm just gonna prove that something went wrong and if the thing went wrong then we delete whatever the you know invalidity was and so this is how we can preserve our our our validity however it does come at a cost because it does impose a delay because you need to give users the ability to host these fraud furs now the second way is succinct proofs so zk rola or zero knowledge proof read this is snark starts etc and in this we can actually

just prove upfront that our transactions are valid so we have our our states or transactions and we just straight prove the state transitions we're able to do this succinctly so we can you know the the layer one knows precisely the moment that it is committed that everything is valid or the snark is you know there's some some bug in the stuff or the smart contract oh that is optimistic roll up n ck roll up the next come the next two are optimistic plasma and zk plasma so in plasma it has a different availability mechanism so it's still guarantees availability of the head state however what it does is it uses an availability challenge when the

head state is unavailable so essentially what you do is you say hey if there iam make the head state available and with that if Tyrion will play this you know what we you know is commonly called it like an exit game which will reveal what the head state is the most recent valid and available head state and it will you know reveal that to the user and allow the user to mutate that head state in whatever way it wants using a forced transaction which is essentially an exit and so this has an implication which is very interesting and that is that if the at B state were to eventually or - you know spontaneously become unavailable because the you know the operator went

offline or whatnot and still and committed a state route but didn't provide any witnesses then the head state might be unknown and this is a real problem because for instance if I'm you know if I'm running if I'm trying to interact with a smart contract and I don't know the current state of the smart contract I won't necessarily know what to do when you know there's a liquidation event or you know any other kind of problem that might occur and so this actually just changes the use cases for plasma because it makes it harder to build an application if your state can eventually can you know for one challenge period become unavailable it's still very useful but it's very useful

in certain use cases and so you know and and but the the use cases are also different for state channels they're very useful but it has a founded participant set state channels are basically like the most amazing but they have abounded participant set which makes them limited and so this is a kind of overall picture of all of these different layer twos and I'm gonna take a peek into all the the questions to see if there's anything I can answer so so for roll-ups when you say recorded transaction on chain are you talking of the l2 chain or the l1 chain both are possible but with different very

different trade-offs very interesting ok so what I mean really is I interestingly enough and if I'm talking about roll-up and I say it's recorded on chain I essentially mean that there exists some Oracle on chain that is saying this transaction is available for download and so realistically that means in like practical terms that means submitting it to like if there anyone putting it through call data making it available and then you know that it's you know been propagated by the etherium network so that's that's how you do it in a 3-1 in aetherium - you submit it to a char chain and the chard chain you know

there's some you get signatures saying that this is actually available and included in a block and so there are different ways to prove this but they all boil down to like an availability kind of certificate where you know that this is actually available for download yeah so that is that one and there I did get another question which is will I when will I be able to move my generics from or contract based apps to a layer to chain and that is very very soon and in fact you can already start messing around with the ovm which I'm going to talk about so anyway but I'll get to

that ok so there's actually another kind of roll up but this to roll up uses a different availability mechanism and that is actually l1 but I won't talk about that here but it's just for completeness sake so wait a minute what are those issues again right we just like when when this very high level overall of layer two and it's kind of it's a little overwhelming probably and we're really trying to all we're trying to do is not just like figure out the kind of fundamental properties of the universe even though that's very interesting to me we're also just trying to speed up with area and so to do that we need to speed up the EVM we need to speed up our smart contracts

we need to get our you know we don't want to change the developer experience just because we're in layer two we want to move all of the amazing work that people have done on aetherium and put that into a more scalable environment without sacrificing things like security and the properties that we like about aetherium and so you know and so we want these these smart contracts and so the now the question is like okay if we want a theorem in layer two in a scalable setting how do we actually achieve that with all of our different possible layer twos well first state channels don't support an unbounded participant set this

changes the kind of smart contracts that you are able to write in a state channel because in you know for instance if I deploy you and the swap smart contract anyone in the world can interact with it so that doesn't quite give us the properties of ethereum so the next thing is zeros unfortunately zero knowledge proof technology's not advanced enough to support the EVM yet there is a lot of promising you know work being done on you know plunks and so that is you know it seems like VMs are coming soon and I'm very excited for that but it is not here yet and so I have waited too long for scaling in theory and so I'm too late you know I'm too impatient to wait for that so unfortunately that rules out zero knowledge ZK roll-ups DK plasma for

now so now we're left with optimistic roll-up an optimistic plasma right but remember we talked about these sudden liveness failures these sudden you know going offline and ever no one knows what the actual state is and so that makes plasma a little bit you know it doesn't really preserve the same smart contract properties that we know and love about aetherium is it that unfortunately eliminated optimistic plasma and so we were left with optimistic roll-up you know an optimistic roll-up is great it's you know it gets gets you you know 10 to 100 times the you know transactions per second on eighth one and then you know a hundred thousand times the transaction side you to you know who knows caveat

and these numbers don't make sense but they're not it's not as good as plasma which is like ridiculous but it is very nice and it gets you the properties that we're looking for and so hooray we you know we can do this so you know we talked about optimistic roll-up in in l2 and in particular we implemented a first version and so the the thing that you know of course you know Pig we you know buy and sell uni and the important thing was that the the user experience was actually kind of nice and the transaction confirmations were pretty fast so that is that is the overview and starting to bridge into you know optimistic roll up and the ovm I'm gonna

take a one more look at the questions to see if I have missed anything no I think we're looking good these slides are online and I will post them I haven't like to create a little link yet but I absolutely will so that was layer to block chains now optimistic roll-up overview so I'm I'll probably go relatively actually I'm curious in this in the in the questions here if folks how much of an in-depth you ask all of your optimistic roll-up questions and I will answer them I'm gonna go relatively quickly but hopefully it's it's a still still useful so we have our aetherium chain right and we have our roll-up contract and this is

the general form and this is honestly the general form of a lot of layer twos as we have kind of talked about and so we deploy our optimistic roll of chain contract to you know l1 and not identify as the genesis state of our optimistic roll of chain right now what we can do is we have you know we can have a bunch of agra gators these aggregators are you know they are bonded so that the fraud proofs has some you know there's something to lose you don't want to have an unbonded aggregator or someone submitting a state route because then you know you you you don't have something to penalize you you need you need to penalize people for submitting

the wrong thing when you use fraud occurs unfortunately it's kind of annoying anyway so what we do is we first started the chain by you know submitting this roll of contract and adding these aggregators now we're going to quote enter of the chain so we'll send some deposits to that smart contract and what that will actually do is that will do a forced transaction which changes the state of the optimistic role of change it's kind of like sending a message into a you know virtual blockchain that lives inside of atheria and so that will change our you know eath to optimistic eath next what we will do is we will send some transactions so we just send a transaction to the aggregator or the sequencer there's way too many names

also coordinator people say it is it is absolutely a mess operator but nonetheless you send it to someone who is creating these blocks block producer and what that does is that of course updates their balances in the state and then what we do is we calculate a new state route based on their updated balances and we commit to both the transaction and the new state route and we do this for every single transaction and we just we can call these transitions and so then we'll bundle a bunch of transitions into a block will commit that block and we will create a we will actually create a Merkel tree or a you know concise commitment to all of the transitions this is a little bit

tricky but you know we we normally what we'll do is we'll have a constant sized state storage for each one of these blocks so we're submitting a bunch of transitions it's getting murk alized into a you know single state route and then we are not a single state route sorry oh my goodness a bunch of transitions merkel eyes into a single block route and then we are storing that block route but any lots of gas savings comes from the fact of course that we're doing this this this you know constant size safe storage because we're because we're creating this kind of virtual chain but the most gas savings are because we're not doing this computation directly on you know aetherium and that gives the scale as I said you know you know you can implement

a not so optimized optimistic role to get 5x transactions per second but you know 10 to 100 on each one is a pretty pretty reasonable estimate so we can do this and we continue to watch the etherium chain and we see and apply all of the transactions that have been submitted to aetherium in these kind of virtual blocks to our local clients and so we're kind of syncing this chain and remember it's availability and validity that we are trying to to preserve and so on this chain we might have you know swap end users can actually interact with you know swap and this is the kind of thing that we did for our demo and once again we're committing these state routes we're submitting these

transactions and we're committing all of these different transitions and building up a chain and so we you know update our balances of according and now what's gonna happen what's gonna happen we've got an evil aggregator someone who is ready to commit fraud remember they're bonded so don't worry don't worry we'll will punish them soon and they will take our normal transaction and replace the recipient with themselves very bad and they will then calculate a new state route with the result of that transaction sent to themselves right this is an invalid state transition this is an invalid transaction right now an

invalid state route is really the most precise and correct way to say so all of the users are going to see and apply that transaction locally to their nodes they will all notice that something went wrong and then well they will submit a fraud proof and so we challenged these invalid blocks and so we have our invalid transition we have our our previous state and we have a bunch of other information like all the storage slots that we are that this transaction is affecting and so will what we're doing is we're essentially creating a little virtual environment for running this particular transaction this particular state

transition and we will go through this kind of long process of challenging invalid blocks notably this this the particulars of this you know kind of proof of invalidity are not that important right in this in this case we are simply proving all of the we are proving everything is the full pre state we're applying the transaction and checking the post route it's the simplest by far as you know invalidity proof but there are many so just as a caveat so valid at first we verify that the trippi's transactions were actually included in the chain once we have done that then we verify that the storage

slots were included and so we provide these merkel route these merkel branches for all of the different story slots and we're and we're set and then we apply being valid transaction and remember that invalid transactions touching all of the storage slots that we prove and we say oh as we're applying it we noticed that the signature is invalid and so oh what are we going to do the blocks invalid and we can simply remove the invalid block and then d remove or burn the aggregators the in the malicious aggregators bond and so we have deleted that horrible horrible block got rid of that bad aggregator and continued on great success and so this

is this is okay we just put a blockchain on the blockchain very exciting so i'm going to take a look at all of the questions because folks may have a bunch so what about cost who great question hi what about costs who pays to commit to layer one that's a great question and this actually depends on a lot of kind of configurations how you build your chain probably the easiest way to do this is users will pay the aggregator and then the aggregator will pay layer 1 gas fees so it's kind of like these relayer

markets kind of like these you know gas station network kind of situations where you have an entity that is paying layer 1 fees on your behalf and collecting fees inside of that you know some some other system and so the system that they cook that these optimistic roll-up you know aggregator / the sequencer is collecting fees in that is the actual blockchain themselves so they we can you know implement for instance account abstraction and all of these kind of meta transaction libraries to pay the fees for for layer 2 and let's see but having sending to missions that yes

I hear you great great great great ok so the big my goodness time flies when it's 3:30 a.m. so um the big the big problem with this was that the unipeg transition evaluator was very very much hard-coded and so we have we instead of you know card coding some particular you know solidity contract that's for evaluating this transition we created a general-purpose transition evaluator the ovm and so what this would we what we did was we wanted we needed the ability to verify any state transition in a way that is easy to audit and is compatible

with all of the developer tooling that we have today as well as you know it preserves the account model and solidity contracts in everything that we're that we're looking that we you know know and love about of hearing so we wanted if the EVM that could execute optimistically and was compatible with you know all the developer tool and so we are you know instead of having a state-transition that's hard coded for you Eunice WAP we have a state transition for the EVM and so we can take our layer two chains and we prove it invalid inside of this UVM and the reason why a with the uma is because it's like Oh EVM essentially for now right this is an optimistic EVM in

particularly that we implement it and so there's there are two types of virtualization container virtualization and machine virtualization the the ovm is a kind of virtual environment or a container virtualization and that means that we're actually creating a separate namespace inside of the EVM which has the nice benefit of running all of the actual op codes directly inside of the EVM so we're not actually like we're not we're not a re-implementing to add up code or anything like that we are instead just running bare metal EDM and so we can actually do pretty efficient frog bursts and so on the other hand there's machine virtualization where you actually implement a full IBM inside of

the EDM and that can be you know basically it's just more work and it's it's you know easier to potentially you know there's there's a bunch of complexity there and so you essentially have the EVM and inside of the EVM you have a no VM virtual environment and inside have you know you can have multiple of these Obion virtual environments or you can you know nest them arbitrarily however you might like so there are three components to this there's a transpiler a safety checker and an execution manager so the transpiler the way that this works is we take our EVM byte code which has you know an S store in it and we can we transpile it into a new into a cross contract call and so the cross contract

call will do exactly what the S store does but it does it inside of this virtual environment and of course you know we're adding a bunch of code here but this is a slave this is a you know a non optimized version of what we are what we are trying to do of course but this is actually you know as it turns out it's actually not that much more expensive because a normal S store is about 20 and gasps this ovm s story that is virtualized with this virtualized storage it's about 24,000 guests and so that's a 24 percent gasp overhead and it is in fact a zero percent gas overhead for independent state independent op codes so like add or multiply and whatnot and so we can take our transpiled contract send it through a safety checker that verifies that all of

the the different opcodes are actually safe there has been no there have been no problems and then we add it to our you know code that is our our execution manager and our execution manager actually holds all of the state and does all of the kind of the storage between holds all the storage for all of our smart contracts and so for example what we have is we literally have a function called ovm s store which takes out the this assembly is just a it could have been a bi encoded but it's not and so it literally takes the storage slot the storage value and it's store and it stores it literally there's like there's no difference and so we do this for it's

very nice to have you know very little work there and so we do this for a bunch of different opt outs right all of the stateful op codes like create create to call static call we're just simply you know you know shimming those particular op codes and so our execution manager is kind of doing this fun little thing holding all these smart contracts and so we're able to actually kind of fulfill this dream of having a kind of general-purpose layer two state machine and so that gives us the ability to build Optimus roam and optimize the plasma of course we care about Optimus to roll up and that's what we are actually building and we want to build the rest someday and so that with that III I wish that I could talk about all

of the public goods but the most important thing is that we can actually use layer to to extract MeV from miners and in particular solve the public goods funding problem but we still need to figure out how to distribute those public goods so someday hopefully somebody can help to distribute these you know help figure out how to distribute these public goods it's like you coin grants Mollick Dow etc but we will we will we'll see so all of these things if your iam y'all y'all I wish I could say hi to everybody here and I you know I'll all of these slides and let me take a quick look at the questions I'm sure I'm out of time in half a second but nonetheless that is that is that so how can I be

sure that my l2 transaction this is a question Oh are we are am I totally out of time I'll do one question how can we be sure that my l2 transaction will end up in an l2 block in later and later aetherium great questions so essentially there are different mechanisms the where you can allow the the person who you send your transaction to will send a signed promise saying I will include this transaction and in fact this is what the state will look like and so you're able to get this kind of guarantee that either my transaction will go through within some period of time or I can you know sacrifice their bond just in the same way that the people's bonds are sacrificed if they post in invalid state route and so we

are now at the point where we can build a general-purpose optimistic roll-up that preserves the etherium developer tooling without you know too much work so it's very exciting and we're you know well let's talk reach out thank you very much [Applause]