L3 - Executing Fraud Proofs | by Yash | BlocSoc Lecture Series

Transcript

uh okay guys so let's start with this lecture so today's lecture is going to be about fraud proofs so fraud proofs are a very important component of how optimistic rup works so if you have attended the last lecture where we uh had explained the different like what are basically layer tws and what are different type of layer TOS then optimistic rollups are a subass of that and a very important component of how they work uh are called for FR Group which which we are going to learn in this lecture so uh let's have a quick overview uh of what optimistic rups are so optimistic rollers basically assume

that the transactions that you're submitting on the rollup are valid uh so that way you don't have to reexecute every single transaction on ethereum when you submit a transaction uh every single validator is basically uh check if the transaction is correct or not and that incurs a lot of computational cost hence the high gas fees on L ons what Le to what optimistic rollup do is that you submit a transaction to the rollup and it just submits it submits the data of it on etherum and uh no one re-executes the transaction and hence you don't have to deal with all the extra competition that comes with it uh but then uh because of which there are the gas prices are very less but then how do you

uh how do you then ensure that the transaction you're submitting are actually correct so what happens is that you assume on optimistically that the transaction is correct but if the transaction is not correct then anyone who is observing the transaction can raise a challenge and submit what is called a fraud proof we're going to learn what what a fraud proof is what a fraud proof is but if a fraud proof is successful that means that the transaction submitted on the optimiz scrollup is indeed invalid then whoever had proposed the transaction will get slashed so now who is the proposer what do slashing means uh and how do you check if a transaction is valid or not we are going to learn of all of this in this lecture and rollers need to build a lot of infra infrastructure to make this

possible so in order to study all of this we're going to take a case study of optimism optimism is a layer to rollup which is uh as the name suggest is an optimistic rollup so this is what they have done they've created their own virtual machine and ovm uh the optimistic virtual machine they have created their own execution client called optimistic get and then they use something called State commitments and micr blocks to basically generate intermediate State commitments and uh whenever you submit a transaction it goes onto something called the canonical transaction chain and an intermediate state is generated on the state commitments chain and then you can use all of these components to generate fraud proofs and verify if a transaction

is correct or not so let's get into it so as I've uh shared this article before it's an article written by the CTO of Paradigm it basically goes uh goes over in very technical detail how optimism itself works and this lecture is going to be a rough overview of this article so if you after this lecture want to get a more deeper understanding of how everything works you can check this out and you can see that the article covers a lot of different stuff like how OBM exactly Works how optimism uh change the solidity compiler to make certain op codes available how they change the get but we are not going to go too much into deep into that we just going to focus on

on how fraud proofs work in optimism so in order to do that uh we'll have to first understand how transactions are sequenced and batch in layer tools we have an entire week of lectures coming up on sequences so we'll go into detail uh in those lectures but for this lecture let me just give you a preview of how that happens so whenever user submits a transaction it is received by an entity called a sequencer the sequencer basically batches the transactions and submits them onto uh something called a canonical transaction chain and it generates a State of the State of the State of each of these transactions and the users can they have a option to not use the

sequencer uh and submit it directly to the CTC but then but it comes after the delay so let's understand it deeply through the this diagram so as you can see there are a bunch of users here all of these users are submitted a transaction to the sequencer now as the sequencer receives the transactions it also uh it also basically orders them uh orders them based on how earlier transaction is received and when it reaches a particular batch uh a particular size it passes all of these transactions and it then submits it onto a CTC now as you can see in this diagram you might see that it is a blockchain uh but it is not a block chain in the traditional sense that there's a block and the block has a bunch of

transactions because optimism does not have those does not have blocks in that sense optimism has optimism do have blocks but they are sort of micro blocks because each transaction is a block in of itself now why is that that is because as you might know uh that the virtual machine of any blockchain is basically a straight uh State transition function now what does that mean it means that the blockchain has a state a state means that okay this account has this balance this contract has this storage variables which has these values that is basically the entire state of the blockchain when a bunch of transactions come like when a block comes which is a group of transactions these transactions basically change the

state of the blockchain and then after the block is basically added to the blockchain you have a new state of the blockchain so that's why the virtual machine which processes these block these transactions are called is basic Bally also called a state transition function so that is how normal that is how ethereum works but uh if we do the same thing for optimism there is a problem and the problem is that we have to eventually verify if a transaction is correct or not and if we do not have the intermediate states of after each and every transaction then let's say that a block has 1,000 transactions and uh the transaction the 999th transaction is false then you have to execute all of the transactions

before that to basically get to that transaction which is going to be a very inefficient way to prove if a transaction is valid or not so that's why what optimism does is it creates a block for each transaction that way we have a state for uh a state after each transaction so we know that okay if a transaction is invalid uh then we'll have an invalid State just after the transaction so that's for the sequencer thus it takes all of these transactions batches them up and it submits it onto the CTC and whatever state is generated after applying that transaction to the previous state that is being put on to a separate chain called the state commitments chain or

SCC now the users do not have to use the sequencer uh on its own because the sequencer is a centralized entity so the sequencer can censor your own transactions like you can submit a transaction to the sequencer and can reject the transaction if you don't so if your transaction is let's say rejected you can directly put your transaction onto the CTC and that happens on the first first in first out basis so it's like a queue right but uh you but the transaction happens after a delay now why is that the transactions after happen after a delay because let's say the sequencer is batching a transaction and you send a transaction in between that so that transaction can Amper like it can have a negative an an

invalid State interacting with other trans action so the sequencer basically has a grace period like whenever a new Epoch is generated the sequencer gets to get some time to bash the transaction submitted on the CTC and after that anyone who wants to directly forcefully put a transaction into the CTC it can do so so that is basically an overview of how the sequencer an optimism works and how the block structure of optimism works so now that we are armed with that knowledge now let's uh look into how uh fraud proof exactly work so let's say that there is a CTC with T12 T8 and there's a state trans and there are a bunch of states for that uh and as you

can see that let's say the sequencer is a malicious sequencer and it submits a invalid state for let's say the fourth transaction so uh up until S3 the state is fine but after the fourth transaction is submitted the the sequencer submits a state which is let's say it gives itself 10,000 Bitcoins or 10,000 each and that is obviously an invalid State because it has to come from somewhere with a signature and that did not happen here so it's an invalid state so uh since it is an invalid state every transaction that comes after it the state that is changing uh all of the upcoming states are also invalid so now we have a problem on our hands here on the optimistic rollup and how do now

how do we Sol solve this problem we solve this problem by basically having everyone watch these transactions so the people who are looking at these transactions they can choose to uh run these uh run these transactions on the state themselves so like let's say you have S3 on S3 the transaction T4 came and uh now sequencer says that the S3 like T4 on S3 gives something S4 but we know that the S4 is invalid because the sequencer has generated in invalid state so if someone is watching this transaction they can independently execute T4 on S3 and get an S3 Prime and they can see

that okay I'm getting S3 Prime what is submitted on the secc is S3 is S4 sorry so that means that the sequencer has done something malicious so what this Challenger can do is now create a fraud proof submitted to optimism and since uh the fraud proof is going to succeed what happens is now optimism is going to prune all of the states that comes after S3 so now all of these states are pruned but the ctcs remain unchanged because the CTC basically has transactions right and these transactions come in signatures so the op optimistic chain is now going to re-execute all of these transactions on top of S3 to to basically create valid States so now let's see how this how the

Challenger can raise a for fraud proof so in order for a challenger to raise a fraud proof they have to basically specify two things they have to specify the State Route and then they have to specify the disputed transaction so in our previous case the Challenger is basically going to pass in S3 which is the correct State up just before the dispute and it's going to then the transaction T4 which has created a disputed State along with that the the Challenger also have to give the proof of inclusion or proof of inclusions and it is calling basically a contract called fraud verier which handles all of these transactions all of

this fraud proof uh management so what is a proof of inclusion so uh like whenever you create a state so a state has a bunch of a lot of data like let's say there are thousands of addresses so the balance of each and every address is basically part of the state what is the value of each and every variable all of these things are part of the state so you cannot have like if you have a block header you have to put the information of the state in the block header but you cannot put all of those information so what you do is that you create you feed all of this information into a Merkle tree and you submit the state root of that Merkle tree right so when you have to specify that okay I'm submitting a

particular State you'll also have to pass in a proof that okay this rout uh this state was part of the uh was part of the Merkle tree and you do that by basically passing in a Merkle route that says that okay this is included in the street uh so you have to do that with the transaction and with the preate root now when you pass this uh data to the fraud verifier the fraud verifier basically deploys two new contracts it deploys a contract called State transitioner and it deploys a contract called state state manager and these are going to be unique to the particular fraud proof that you're submitting now the state manager is basically a contract which has all of the data that is all of the context or background data

that you need in order to run the fraud group now what do I mean by that so like let's say that you uh submitted transaction T4 and the sequencer generated a malicious a malicious state for that now that happened on a particular time stamp and the fraud and the Challenger basically raised a fraud proof on a time stamp which is like 1 hour after that so if you want to reexecute the transaction on ethereum then the time stamp is going to be different different and hence the uh the actual state that is being generated might not be the state that you that should have been happened so uh there's a problem there so that's why when you're executing a fraud proof you cannot execute it straight of on

ethereum you have to execute it on a sand sandbox environment an environment which has all of the background context and all the background data that uh that was there originally when the transaction was run on the optimistic chain so all of this data is stored the state manager so now uh yeah so optimism basically creates a Sandbox environment that guarantees that the execution of the smart contract is going to be deterministic between L1 and L2 sorry there's a typ on the slides uh and as I said that optimism basically had to create their own infrastructure to make this happen so they cannot use the evm uh on its own because uh if you call let's say the

time stamp on the evm it's going to return the be is going to return the default time stamp which is at that time you do not want that so you need to alter some of the evm op Cod so that the fraud proofs can run and for that the optimism basically created an ovm and uh they basically whenever you run a smart contract on ovm it checks that all of the op codes are basically optimizing ovm safe or not right and uh so there is another contract called the execution manager this contract is responsible for for executing the fraud proof on ethereum and uh it basically inputs all of the ovm off codes and it runs them on ethereum to check if the fraud proof was

correct or not and uh the uh optimism also modified get to make it obum friendly so get is basically a execution client for ethereum it is the most popular execution CL for ethereum it was written in go uh and developed by the ethereum team so uh get normally takes messages and it sends it to whatever the message says like whoever you have to send it to but optim but optimism changed it so that whatever message you submit to optimism it has to go to the sequen as entry point and uh optimism also created the sandbox environment inside of get uh so that uh whenever a fraud proof is generated the

execution manager gets to run the uh run the transaction instead of the actual chain and whatever the messages original data was like uh the two the address it was sent to the address it is coming from all of these are passed in as arguments because like whenever you settle a lar to transaction on lar f it uh the the transaction is being the data of the transaction is being sent to ethereum through call data so like call data has all of the arguments uh when you when you send a transaction on L2 to L1 this is a this is a topic that is related to something called Data availability and we might have a lecture on that as well so I'll not go too deep into that now

ovm maintains an order list of all the transactions and as as I said that uh each transaction is a block but then if you know that ethereum have eum in a block has a block gas limit so you cannot have more than a certain amount of blocks on ethereum so we also need to have some sort of rate limiting factor on optimism as well so what optimism has created for that is called an Epoch so an Epoch is basically an interval of time and optimism has defined that okay a particular EPO can only have a particular amount of gas consumed in that so if you have submitted a transaction in an eoch which has exhausted gas it basically returns that your transaction is too early and you

can resend it after after the next Epoch starts so now let's come back to the fraud proof so as you said that the pre-state is loaded into the sandbox environment the pre-state is basically S3 and it is loaded into the environment and the Challenger apply triggers a function called the apply transaction which invokes the Run function on the execution manager the execution manager as I said was responsible for executing this transaction in the sandbox environment and uh basically what execution manager returns is S4 prime okay S4 prime is the actual correct state that should have been generated and now what optimism does is basically

it checks that if there is a mismatch between the state that the execution manager has uh returned to us and the state that the uh sequencer had submitted on the state commitment St and if there is a m uh and if there is a mismatch between the states then uh uh yeah so as I said that there is an the finalized fraud verification function is called which actually check if there is a mismatch between the state roots and if there is a state root mismatch that means that okay the fraud proof is successful the state that was submitted by the sequencer on transaction four was indeed invalid and then all the states after that must be

pred and re-executed to obtain the correct States now uh you might have a few questions as to like uh what if someone spams fraud proofs and what if some what if the sequencer itself pans a lot of States so that in the hopes that okay at least one of the state is not uh not checked so that an invalid state is fast so in order to mitigate all of this uh basically optimism runs on a proof of stake Network a proof of stake mechanism so the sequencer or any other party any basically any party can submit transactions can submit the state on the state commitment chain but in order to

do so so they have to first put some amount as a stake right so this avoids spamming first of all because not everyone can do it and then once someone has put a stake on it if they submit an invalid State then their stake will be slash what that means is that let's say you deposit some money and you're submitting uh States onto the SEC and you have submitted an invalid state to get some reward now a fraud proof have been generated for your invalid State and is successful if it's successful then the money that you have deposited to the optimism contract it will be taken away from you so that is basically an incentive for you not to provide invalid

stage is that uh I think that's clear to everyone and then you might ask that okay what incentive do do people have to check if the transaction is correct or not right so what happens uh when the stake is slashed is that a percentage of the stake is burned away and the remaining per and the remaining part of the St it gets redistributed uh to the to the entities that were uh that basically raised the challenge and provided the data for for fraud proofs so this incentivizes everyone to check each transaction because if you let's say if you're checking a transaction with optimism and you find an invalid State then if you submit a fraud proof and you know it's

going to verify then you'll get then you going to receive a reward so you'll have an incentive to do that and that basically that is basically how fraud proof work and that is basically how optimistic rollups also work so are there any questions so far okay so if there are not any questions then uh that is it for this lecture and uh yeah that was it for the lecture

thank you