L2 - Optimistic and ZK Rollups | by Alok | BlocSoc Lecture Series

Transcript

so hello everyone uh today we are going to discuss about optimistic and zqs in the last lecture I think some discussed about what layer TOS are and why they are useful so today we'll be discussing the major two types the optimistic and Zs and how do they work so yeah firstly we will have to focus on some basic terminologies that are the most means whenever we are studying about the roller Technologies we need to know these terms so first is the bandwidth it's the cost of downloading and broadcasting the blockchain data then compute is the comp cost of running computations and the storage is the cost

of storing transaction data whatever data we are storing on the blockchain and these are the resource that a node needs and these based on these resources a node calculates whatever cost will be required to run for any blockchain be ethereum or any low than blockchain then there are two parameters which are useful in measuring the performance of a blockchain so first is the throughput I think some discussed that last in the last lecture so it's the number of transaction that system can process per second and second is the latency the time it takes for a transaction to be process so these are the two important terms for measuring

the performance current L ethereum processes block for around 12.5 second and it's uh 1 million gas per second so you can calculate the throughput and latency there yes so why do we need layout to mean we discussed in the last lecture that we have to scale the system but why do we need it so whenever we are creating a blockchain our main purpose is to decentralize it and the main things that we require in a decentralized system is that we should have little to low Trust on the system for whatever transactions we are

performing that should not require any trust and we should be okay with that the cost of running the system should be very low because if there are high cost then we have to trust the system because if there is a loss then who will be answerable so the cost of running the system should be low and the system should be highly scalable so scalable means that it should be able to operate for vast amount of users not just 10 or 15 transactions that are happening right now so now scalable how like scalability can be achieved in many in many uh things like uh many uh apps are scalable they are available to the users

worldwide there is Google Microsoft everyone is developing apps they are scalable but we want the scalability which is decentralized we don't want to give the power in hands of one organization so we want to achieve decentralized scalability and that means achieving scalability without meaningfully increasing the system's trust so uh the meaningfully increasing the system trust I'll discuss what it actually means and yeah decentralized scaling is like we don't want to increase the Trust on the system we don't want to increase the cost of running the system and yet how we want to scale the system now currently as I discussed the ethereum's latency is 12.5

second and its true putut is 1 million gas per second so what does 1 million gas gives you so basically right now for 1 million gas you can perform around 47 fund transfers from account a to b of e e and they there can be around 16 erc2 toen transfers in a 1 million gas so per second you can perform at most 40 to 50 transactions which is not we want we want to scale that so now how can we scale so there are like ID discuss we can use some Direct Solutions like we want to use an intermediary so using an

intermediary means like we'll take a third party it will process all the transactions and we will trust the third party that yes whatever transaction ctions are happening the third party is performing those transactions correctly and the trust will be the major feature for using the intermediary and second can be we can make the blocks bigger and more frequent like currently we are proposing a block in 12.5 seconds and the gas limitation is there for 12.5 million gas so the solution can be like increase the gas to around 50 million and increase the block size so that we can include as many as transactions as possible but are we able to solve the

problem like is it working because if we use an intermediary then we are increasing the trust and as I discussed before we don't want to increase the trust of the system secondly if we increase the block size so if we are increasing the block size we are taking in more transactions more data so the computation cost will be increasing significantly and if the computation increases then the cost of running the system is not remaining low so that is the another problem that we can't achieve so it is neither reducing the trust nor reducing the cost so these Solutions won't work so now we'll think like how can we

achieve this without increasing the trust and increasing the cost so let's discuss from the first principles like what happens in an ethereum transaction so in ethereum every there is a node and every node is storing the state of the blockchain a transaction happens the state of the blockchain changes every node calculates the state they reach on a consisten that yes the state changes accurate uh from all the nodes and the blockchain moves to a next St and during the execution means the transaction is run through the AVM we all know that all the transactions are run through the ethereum virtual machine and it's it the

transaction Alters the state of the evm we reach to a state t+ one which is agreed upon from all the nodes so in this way a transaction is pro processed in the ethereum blockchain so is it possible like the cost we are entering is because we are interacting with the ethereum's state so can we make a transaction without touching the state like just keeping the resources cost low without touching the state and yet performing transactions at a very high margin so yes the answer is yes we can do that so how are we going to do that yeah so the first solution is optimistic RS so what are optimistic rollups so

optimistic rollups improve the throughput and latency and how do they improve that they move the computation and data storage offchain so let's say there's there are two users Alis and Bob they are performing uh multiple transactions between each of them so Alis St to Bob then Bob sends 58 to Alis and they performed around 100 transactions between them now ultimately there will be some changes in the account balances of Alis and B what we are trying to propose is whatever 100 transactions that Alis and Bob used I means performed within both of them uh will be storing the final state of the

blockchain and that final state will be submitted to the layer one that is ethereum in our case so what we'll do like as we said we are moving the computation and data storage of so whatever computation happens happened between those 100 transactions when Alice sent some eat to Bob Bob received some eat he sent it back whatever computation happened whatever data storage was there we'll take it off chain and this is not happening on the ethereum blockchain because when we perform the transaction on the ethereum blockchain the state change will be there and cost will be inquired so we took all the transactions off chain we performed all the transactions and finally whatever the

account balance was we submitted the final State back to the ethereum lockchain now the cost incurred for 100 transactions is reduced to a single transaction cost whatever state change happened between Alis and Bob account we have submitted that to ethereum and we covered up the cost of around 100 transactions now how is this happening like how are we using those uh 100 transactions and uh yet not losing anything so this is done through sequences now sequences are responsible for storing and executing uh the User submitted uh submitted transactions locally so whatever transactions Alis and Bob performed they were submitted

locally to a sequencer sequencer ran all through all the transactions and changed the state of the ethereum which was initially to say State a 100 transactions were performed we raised a state B we submitted that state to the Elin blockchain and the L1 blockchain will verify whether the state is correct or not we'll descript that later and finally the 100 transactions are processed so in the diagram you can see huh so the diagram explains like how can we enter a uh Layer Two or a optimistic rer so I am a user I deposit 108 to a bridge contract now whenever you are entering a optimistic rollup or a z rollup there

are bridge contracts on the layer run blockchain so if you are say depositing 10 E from the ethereum blockchain to the arbitrum or optimism or stock whatever L2 blockchain so ultimately what you are doing is you are providing that fund to a Bridge contract which is stored on the L1 block so this bridge contract will lock the 10 this transaction will be added to the sequencer and the sequencer reads the transaction it relays the transaction to another Bridge contract which is on the L2 blockchain be it arbitrum optimism State any of them the similar the equivalent amount of funds

will be mained on the L2 and they will be transferred to the L2 address where whatever address you have on the l2s so any doubt till now anyone okay I think there is no okay let's move on so yeah we we have entered the rollup now we'll be using the rollup now in using the rollup what is mean what is means is like uh yeah let's discuss this

diagram so there's a badge transaction on L1 of the pre-state route something is there the postate route something is there Alis made some transaction to Bob Alis made some transaction to Charlie Bob made some transactions all those transaction happened we created a state Ro now as I discussed earlier the state route will change depending upon all the transactions that are happening so initially the straight route was say 0x 13457 after all the transactions the post State Route is 0x BC 892 F now this find the variable is changed to the new State Route like the new State Route is BC 892 now the new State Route will be

submitted to the rollup contract this rollup contract is on the El blockchain and the new State Route will be verified on the L1 blockchain and in this way all the transactions that happened between Alis Bob and Charlie they will be verified that yes they were correct the new state route that we have achieved is uh as per the transactions that have happened and in this way all the transactions that were performed of chain on arbitrum or optimism whatever they were they are being verified on the layer so yeah when we are submitting this batch one thing to keep in mind is that these transactions are very in a very compressed form this is meant to

reduce the storage cost that we are anchoring on the Elin blockchain so we are trying to reduce the storage as much as possible that we have to use on the ethereum lochain so yeah the note is there that encoding of all the data is passed as call data so yeah how is call data working like whenever there is a uh contract on ethereum there is a method or a function in a smart contract and the function takes some arguments now these arguments are stored in the call data and call data does not interact with the state of the blockchain but we are able to store that call data in

historical logs so in this way we are reducing the cost like we are not interacting with the state but still we are able to transfer that data to the blockchain and store that in the logs yeah this means that the published transaction data is not interpreted executed and no State access is made it's just stored in the historical logs of the blockchain means uh if you have studied about how events happen and how we are logging the events on the blockchain so we are making same use here like there will be some function called publish it will take some bytes of call data and its body is empty since its body is empty it is not interacting

with the scam yet we are able to pass the transaction data as a call data and the call data is being stored as historical logs in this way we have stored the data um in the form of logs and yet we have not performed any transition to the state so this are the uh cost effective things that happen and I have provide like this is the example of of a uh log that uh like there is a transaction batch appended event uh previous total element sorry batch index batch route batch size previous total elements extra data so these are all the uh arguments of the function and in this way we have

provided all the data to the uh L1 blockchain in the form of the arguments like batch rout this is the batch rout then batch size previous Ro elements and whatever extra data okay now in this way we use the optimistic rollups now exiting the rers so how are we able to exit an optimistic rer so initially we were uh able to provide uh means we submitted say 10 e to the bridging contract and that contract that fund was locked now Alis wants to withdraw those funds and she wants it back on the eum men now how will she get

that so firstly she'll need a Merle proof uh that Merle proof will be proving that yes uh uh she has submitted some amount of e or whatever uh currency to the uh Layer Two then the means uh for generating that proof she'll be requiring the data for and that transaction data is meant to be provided by the sequencer so it is the duty of the sequencer of every layer to blockchain to provide the data to the users so that they can generate a Merkle proof and give them the guarantee that yes

they have submitted some funds to the bridging contract and if there is a malicious sequencer we'll discuss how we are accommodating that thing now yeah here there are just trust uh assumptions on the sequencer that yes sequencer will provide the data to the users now how the trust situation is being solved like we want minimum trust as much as low trust as possible so the optimistic rollup Sol solve this problem by requiring sequencer to post full transaction data on the main execution layer and if they'll not post the data on the main execution layer so there is uh something called um means they have

to put some amount there which will be slashed so in this way we uh means maintain the sequences that they have to submit the data to the main layer yeah okay so now how are we able to this uh how are we able to get confirm that just all the transactions that are happening are currect like the transactions between LS and Bob that happen say they both both are acting mly and they want to provide a false state to the main el1 L el1 change so how are we mitigating that so there is something called fraud proofs uh we have a

complete lecture uh next uh next lecture is completely on frauds I'll discuss in uh just a gist like what happens here so it is a cryptographic proof uh and it demonstrat that yes some FR took place there was uh some uh a transaction which was not up to the mark it was altering the state in a way that we were not expecting so there are some uh entities called verifiers the verifiers uh because they have uh available all the data all the transaction data they run through all the transaction data and uh generate a a verified State themselves and match that state with the state

which has been submitted by the sequenc now if those state will match the state is correct but if the verifier finds a state which is not up to the mark to the sequencer State the verifier can generate a um issue that the state proposed by the sequencer is not correct and in this way we are providing a fraud Pro so if this spoted discrepancy they can submit the proof and uh in the fraud fraud proof there are two important terms that we need to remember Fidelity Bond size and dispute period ruce so Fidelity Bond size what it means like in a proof of stake what happens is a user provides

some funds at stake that and providing after providing that state he assures us that he'll be performing all the things honestly so here whenever a verifier is raising a issue the verifier will provide some fidelity want in terms of any tokens whatever have been decided by the layer to rollup so the verifier will raise some Fidelity Bond and after that he'll raise the issue so if the issue is not up to the mark means if the issue is false then the whatever Fidelity B the verifier rais that will be slashed and if the issue is correct in the same way the

sequencer will be uh slashed of some of the Fidelity Bond and that will be distributed among the verifi so this is Fidelity Bond the size can be determined depending upon various rups and second is the dispute period duration so what is dispute period means uh whenever the layer two is submitting the transactions onto the layer one there is a period which is provided to all the verifiers within this period they can uh run all the transactions which are within the L2 block and create their own State and this state should match with the sequential State So within the dispute

period they have to complete all the state changes and means they have to produce their own State and match that state with the sequen state so dispute period duration can also be controlled by rools depending upon what they want like for arbitrum it's around 6.4 days so the uh there is a duration of 6.4 days after which all the transactions that happened on arbitrum are considered valid and they are submitted to the layer so these are the two parameters that are important when dealing with frauds yeah so here is a Delma like we discussed that whatever transactions

that happen on layer to we want all those transactions to be correct so what whatever state the sequencer produces we want that to be correct so this means step one if the system incentive work as inter means whatever we have planned all the things are going as per the plan so in this case nobody is cheating so if nobody is cheating in the system then there is no point in running the verifier because if someone is running a verifier he raises a issue but there is no problem in the system so the verifier will lose his funds as we discussed the Fidelity want s so there's no point in running the verifier but if nobody is

running a verifier then there is an opportunity for a sequencer to propose a false streate because there is no verifier the sequencer has the ability to propose a false State and no one will counter that state but if the sequencers CHS then the system will no longer function as in so okay let's let all this like how are we able to solve this yeah so we have concluded that there is no point in running a verifier because we are getting no incentive out of it means if we are running a verifier and the system is running as ined we'll be receiving no rewards then what's the

point of running a verifi so the solution here is like if someone has some uh Bitcoin or someone is holding some eat or someone is holding say any token which has some utility we're not discussing about mean funds so if someone is holding any token which has some utility the token has some price and any person the user whatever means uh whoever is holding that token they don't want to lose the value of that token like if some uh means if something happens in say arbitrum or optimism the price of that token will

fall drastically the market will significantly decre so the incentive here is anyone anyone of the person can will be running a verifier because they want to hold their token means uh the value of the token should remain there like uh say I am running a D5 firm and it is solely based on with now my uh def5 firm is having some tokens and if something happens on arbitrum the loss will be mine I have launched the defy form on arbitrum and a sequencer proposed a wrong State the the loss will be of the firm that I am

running so out of uh storing I me the uh means out of uh proposing that yeah have to hold value of the tokens I'll be running a verifier because I don't want my firm to go down and thus in order to maintain that value I'll be running as a verifier so in most of the layer tools what happens is like um any firm that have launched their product on uh any of the l2s they'll run verifier they'll run a verifier because they want that the token value should not collapse so this is how we are solving the Delma because

the verifier directly is not getting any incentive but when they have launch their own firm or their own product then the incentive is there because they don't want to lose the value of their own product I guess that is clear okay so we'll take a break and then we discuss about the Zs so yeah now I'll discuss what ZK rups are so they are similar to optimistic rups in one way that as we were batching up all the transactions in the um L2 and then submitting them back to layer one

but the difference here is like there we were optimistically believing that all the transactions are correct and then there was a dispute period where any verifier can come and raise a issue but the difference here is like uh that there is a proof generated for the all for all the transactions that happen and the proof will be verified by a L1 L1 contract and in this way we are not optimistically believing that yes all the transactions are correct but we are using a tool cryptographic tool to verify that yes all the transactions are cover and at the same time we are saving the cost because we are not providing

all the transaction data to the ethereum blockchain so this is the this is another thing like we are no longer include uh increasing the trust we are minimizing the cost and yet again we are able to solve the issue of scalability so yeah they are similar to optimistic rups they combine a large number of layer to transactions that were executed off CH submit them as one transaction on here we are using validity proes instead of the Sal proes and these validity proes instantly prove if transactions are valid or not and then one thing that is problematic is like uh whatever optimistic rups are there they are

directly AVM compatible because all the transactions that are happening are basically same that are happening on the E but for the ZK RS we have to de a AVM which is compatible to the ZK circuits and that is something to take care of and many blockchains are working on it but still it takes some resource and some tools to develop e which is compatible to the zero circuits uh yeah stet and ZK are some of them same as ZK RPS stock uses CYO as the language they are not ZK

AV compar and ZK I there and yeah how ZK RS work so as we discussed earlier there are multiple transactions we bundle them up we create a batch of transactions now all the transactions are B good and there will be a contract will be generating a validity proof that proof from the layer to will be subed to the layer one and the layer one on the layer one there is a verifier contract the verifier contract will take the proof and there will be some public inputs using the proof and the public inputs it

will verify that yes all the transactions are correct the final state that we have reached is the state that should be there and once the all the transactions are verified they are submitted on the El blockchain and yeah process concludes so interaction between L1 and L2 what happens like some say there's a batch one there are multiple hundreds and thousands of transaction we are badged together the proof is generated and some public inputs are provided the public inputs include pre-state route postate route the proof is already there these all inputs are provided to the layer one the verifier contract will

take the inputs will take the proof verify that yes the final states are correct and then the transactions will be included in the Block in layer huh so what are the dependencies on layer one like how is the ZK R up dependent on the layer ofaction so first is the transaction finality like we discussed before the transaction will be considered final only when the ver fire contract on the layer one blockchain is giving us a thumbs up that yes all the transactions are correct the final state is correct so the transaction finality is dependent upon the layer one then the

data available availability so as we discussed earlier like we were providing the uh data all the transaction data as called data to a function in the same way all the uh call data is provided to the L1 uh blockchain in the form of call data and say anyone wants to uh Roll Roll Another uh ZK means he wants to generate his own state of the ZK roller so he'll take the data from the etherum blockchain whatever was submitted as the quor and spin up his own rollup and verify that yes all the states are accurately managed and sensorship resistance is basically using

the security of E blockchain means all the state changes that are happening and that's why we want the zq rollups to be e compatible because then it's very easy for all the transactions to be more censorship resistance yeah then how the validity proofs work so as we discussed there is a validity proof that has to be provided to the verifier contract on the L1 block so how will the validity proof work so a ZK proof is generated what what are the things that the ZK proof includes first it includes the Mer tree route of all the

transactions in the batch say there are 100 transactions will generate a Merle tree and the Merle tree rout will be included in the proof the Merkle proofs for transactions to prove inclusion in the batch like if a transaction is included or not in the batch so we'll be requiring Merle proofs for that so that mer proof is included and Merkle proof for each sender receiver pair in transactions and a set of intermediate State Roots intermediate State roots are helpful in generating public inputs and since we want to give as less information as possible we are talking about zero knowledge of course so we

create some intermediate State routs and these are helpful in generating the public input which are helpful in verifying the uh transactions so now how this proof is generated so there are many techniques like ZK STS and ZK SARS there will be a complete lecture on how these techniques work how we generate the proofs I'm just explaining that whatever is included in the proof and stars and snars will be discussing later uh now what happens after the proof is generated the L2 operator the Z rollup operator submits the validity proof to the verifier contract on Al public inputs are also submitted the

verifier contract takes the public inputs take approves and verifies all the transactions yeah so what is the benefit from these RS so I included the screenshots it includes all the optimistic and Z rops so you can see that for sending e the ethereum main net takes .82 ASP but stocket takes 01 optimism takes 01 arbit takes 01 so these are the significant cost reductions that were that we are getting and from all the technology that we are using we have come to a

conclusion that no trust assumptions are being included and uh one more thing like whenever a rollup is started and actually it has three stages so there is a l2b framework proposed by V and it includes three stages stage Z stage one stage two in the stage zero all the operators are manually run in the stage one they The Operators are all the contracts running and in the stage two like if there is a optimistic ruler so in the stage two whoever is the verifier there can be n numbers of verifier anyone can come and verify the state of the optimistic roller so let me give an

example like if there is arum so currently arbitrum one and arbitrum Nova they are in stage one so in stage one whoever are the verifiers they are a selected group of P that we have to keep Trust on what is the problem that no uh means anyone cannot verify the transactions the problem is like they have a dispute period of 7 days so if arbitrum allows any of the uh means any of any user to verify the disputes so what will happen is a delay attack will take place like say I am a very uh I am a random person I go to the uh

dispute period I raise a issue I know the issue is not current but the dispute will be lenden then then I will raise the issue again so the dispute period will be extended again so from 6.4 days to 12.8 days to and number of days so this is a problem that happens and that's why currently we have to trust a certain number of verifiers that have been selected by the arbitrum in the stage two what will happen is they will be able to allow any of the user to come and verify this stage uh uh so and verify the transactions so in the stage two it is called no wheels rollup and no wheels rollup means that it is

completely decentralized so yeah that was some extra information so yeah currently most of the rollups are in the stage one level and they are trans transitioning to stage and yeah these are the benefits like the gas ke reductions are significant and the swap tokens also it takes $4.1 on it the means Zs it is significantly low yeah one more thing you can notice here is like in the star net it's 01 but in Z is SN light it's 04 met is in 0916 this is because it depends upon the

proof that all the blockchains are generating like we discussed about stars and St so the slight different in difference in the cost is because of the proofs um it depends upon the computation of different uh methods so that is why you are seeing a significant difference in the price though it is very small but yet there is a difference and yeah this is the difference between optimistic and Zs I have explained all of them so optimistic uses Pro Group CK uses vality groups optimistic requires a one we delay because of the dispute period and ZK we

can withdraw F immediately because valid data comption it publishes full transaction data and it does not public full transaction data it is just giving up some public inputs and in ZK rollups one more thing that happens is like they are uh saving the transaction dat uh saving the uh storage cost by reducing the public addresses to uh bits like for a 20 byte address they are using a 6 byte index and they are indexing all the addresses so for two address the initial cost would be of 405 but what they do is they index the address through a 6 byte

uh slot and in this way for every two addresses they are saving 28 byes so in this way compression of Z rups takes place and the rollup cost means these are the difference cost like for ZK rollups they pay high overhead cost because of the computation the verifying gos optimistic rer trust resumption doesn't require a trusted setup it requires Z require a trusted setup like the cryptography has to be trusted that is the cryptograph the liveness requires requirement like the verifier should be there for optimistic rollups but in SEC LS we don't need someone because the verification is taking place through the

verifier contract security properties yeah these are some basic things uh okay then I guess these are the differences and this should be enough for you to understand what actually optimistic and Z CH we have upcoming lectures to explain all the details is in much more depth but yeah this was the intro to Optimist any doubts