L4 - Layer 2 Transaction Lifecycle | by Yash | BlocSoc Lecture Series

Transcript

all right so hello everyone uh today's lecture is going to be about leer to transaction life cycle basically I want to talk about what happens when you submit a transaction onto a layer two and how is it finalized on ethereum so let's get into it uh so when a transaction is submitted onto the blockchain you might have noticed that you have to wait some time for it to be executed right so like when you consider a transaction to be executed like you know that okay it's not going to revert after this that point is called finality so like the time it took for you to reach that point is called finality basically so in this

lecture we're going to explore the following topics uh basically what does the word finality mean on ethereum and then how does a transaction life cycle look like for both optimistic gups and zups right so let's first look into finality so as you might know that ethereum works on a proof of stake consensus mechanism and it uses something called a practical bintin fall tolerance algorithm to basically vote upon what transaction is correct and what transaction is not correct so what happens is that there are a bunch of validators which have provided stake into the network and then whenever and uh then one of these validators is

chosen to propose a block they have a bunch of transactions in something called a menol they basically whenever you submit a transaction the transaction is being received by a full node right uh like you might know what the full node is because like whenever you're using a Dap the DAP is using a uh like a it's using a service with a service by Alchemy or infura so those are basically full so you're basically using a centralized connection to a full node or you can use a decentralized connection to a full node either way whenever you submit a transaction it goes to a network and it is gossiped inside the network until it reaches the validator that is supposed to propose a block so

they have a list of all the transactions that need to be included in the block they create a block and then they propose it uh to the network now all the other validators they have to look at these transactions reexecute them and basically confirm that okay all of these transactions are indeed valid for example like let's say Alice sends 10 e to Bob so for that transaction to be valid Alice must have 10 e and Alice must provide a digital signature approving that yes I do want to do this so like no one uh apart from Alice can submit this transaction on her behalf you have to provide a digital signature these type of things must be validated by valid datas so they basically vote on

the Block that okay all the transactions are correct and if the vote passes the block is included so let's look at two terms that ethereum has created one is called a slot a slot is basically a 12 second time period so every 12 seconds one slot passes and then there is something called an Epoch an Epoch is basically a collection of 32 slots so one EO is one eoch is basically 6.4 minutes long so why do we need to know this uh it is to basically understand what finality means so like whenever an ebo starts all of the validators that are part of the ethereum consensus they are shuffled into 32 committees right and each slot so like there are 32 slots

in an Epoch each slot is assigned one of these committees so committee is basically just a random group of ethereum validators and for each of these slots one of the validators is at random chosen as the block producer sir okay so they are the ones who get to decide who gets to create and propose what a block should be so in each slot there could be only one block uh but there could be no blocks as well but generally there are uh there is one block per slot right so the block producer for that slot will publish a slot uh will publish the block and then everyone who is part of that committee that committee gets to vote on whether the block is valid or not and if 2/3 of

the committee 66% a super majority of that committee approves that okay this block is indeed valid all the transactions are valid then that block is well it's good to go it is called like okay this block is ATT estated right so during the 32 epochs each committee basically votes on the Block proposed and each validator gets to vote once and each transaction is voted upon once and when the ends the validators are reshuffled and the Committees are created once again and this uh process happens indefinitely so when you submit a transaction it goes into a slot it is picked up by a block producer it is

included in a block and then when it is included in the block every 66% of the P of the validators in that committee must approve that your transaction is valid and then uh when that Epoch ends that is when your transaction is called it is uh vaguely finalized so let's look at three terms of finality right so the first term is called unfinalized unfinalized basically means that okay the block producer has produced the block for your slot it has been included in the block but the attestations has not come yet okay now the attestations do not come right after the block is proposed okay when whenever the slot ends or close to

ending the block producer will propose a block and then the ATT status will reexecute it that takes some amount of time that is not theoretically possible to do in 12 seconds right and because it's not just that you have to reexecute the block after re-executing you also have to vote by voting your what you're doing is the validator it is approving that okay the block is correct so they have to send a signature they have to sign that okay I'm approving that this transaction is correct and all of these transactions must then all of the signatures sorry they must be aggregated in order to create a One Singular signature that can be either that can be checked if it's if it if it is approving or denying right now why is that because

you cannot individually verify every single signature because that takes a lot of time so in order to solve that problem ethereum created something called BLS aggregation which is a uh it is a piece of cryptography that allows multiple signatures to be aggregated now that also requires time but it allows ethereum to aggregate ions of signature at once which basically allows you to have more than 500 like 900,000 validators as of now which was not possible before this scheme was introduced so uh so that's why when the epoch ends so so that's why when the slot is uh when the slot ends you don't uh have a finalized block yet you just

have a block which has your transaction included in it now the next state is called some is something called an unfinalized block but it is considered safe someone's mic is on can you mute it please thank you uh so the next date is called unfinalized but it is safe why because this is when the E first Epoch has ended so when the first Epoch has ended that means that uh all of the validators in the committee committee have ATT estated that the block is validated and the signatures have been aggreg aggregated and it is verified that okay this block is indeed valid fine but uh and there is very little

chance of reorganization that okay after an entire set of ethereum validators have confirmed that your block is good then it's a there is a very low possibility that there is something wrong with the block so you can consider it safe but it is not yet considered finalized it is considered finalized after another set of attestations is done so basically after two EPO your block is considered finalized so one Epoch is 6.4 minutes two EPO is roughly 13 minutes so after 13 minutes your transaction is considered finalized why do we wait for two EPO well because uh in the first Epoch every validator gets to vote once on your transaction right and when the validators are voting again

in the second Depo they're voting on transactions that are basically doing a state change on top of the state change that your transaction has donees done so they are also implicitly validating that okay your state change was valid that's why the next state change is valid so that's why we consider two EPO to fully at aate and finalize a block transaction so that is what finality means on ethereum so now let's look at what a transaction life cycle looks for layer tws let's start with optimis optimistic rup first so if you have ATT the last lecture you might have gotten an overview of how what a sequencer is and how sequencer

work works so basically user submits the transaction to the sequencer right uh and the sequencer then batches these transactions and sends them to the layer one now you can also forcefully include a transaction into the sequencer uh but that takes some delay on arbitrum that delay is for example 24 hours but generally you you might not need to do so now why would you trust a sequencer to include your transaction uh we'll have a full week of lectures on sequencer so I'll not go too deep into this but the worst thing a sequencer can do is either censor your transaction like to not include it at all because of which you might want to use the layer one approach or the

sequencer might reorder your transaction so that uh they can get MV m is something that uh that is basically bad for you we'll have another lecture on it so we can dive deeper but for now you just consider okay m is bad M happens when block producers or sequencers reorder your transaction on the M Pool and uh another thing that the sequencer can do is not include your transaction at all or do it after a delay to uh avoid that you can forcefully include your transactions on L that is a feature that is available on optimistic rup so let's assume that that does not happen the sequencer does batch a transaction and sends them and it sells s them to lv1 using call data so an ethereum

transaction you basically have a bunch of message message that variance that you can either you can send a transaction to someone so two is a field the the amount of value you're sending that is a field and the data you're sending along with the transaction that is a field so this data part is where all of the information of these transactions is being batched and sent into and sequencer does this every to five minutes uh and in the last lecture we basically went over what fraud proofs were so fraud proof is basically when you believe that the sequencer has generated a malicious proof a malicious State and you want to challenge that so uh one thing I did not mention was that

this fraud proof does not have an infinite like timeline okay you can only submit a frad proof one week after the transaction was bashed and sent to ethereum after after that you cannot send a FR which means that after a week of time you can sa safely agree that okay uh you can safely agree that uh the transaction is indeed finalized however optimistic rollups would like you to believe that the finality is is occurring in 3 to five minutes itself now why is that that is because uh you basically have to consider that the fraud proof is sound you have to believe that the for fraud proof is working and

no one in the right mind would submit an invalid transaction because there is a very clear cryptographic way to prove that your transaction is invalid and it will lead you to lose a lot of funds which is undesirable for you so why would you do that right so that is why you can consider when your transaction is submitted to the layer one in 3 to 5 minutes you can consider that to be the finality on top of the ethereum finality itself so 5 minutes plus uh 13 minutes you can assume that on optimal up you get a finality in less than 20 minutes or you get a finality in one week depending upon what you believe because there could be there could be smart contract bucks attached to the verifier contracts

it is in theory possible if you if you want to consider finality if you want to uh basically attach those risk into your calculations you might assume that finality happens after one week or you might assume that finality happens under 20 minutes depending upon your risk factor so this is a brief diagram which I have also explained last lecture that users basically submit the transaction to the sequencer they bash them into basically batch and then they submit it onto a canonical transaction chain which is on uh the layer one and a corresponding stat chain this this is basically created to help fraud proofs and uh as I

said that if the sequencer is sensoring your transaction you can forcefully submit the submit your transaction directly on L1 but that happens after a delay of 24 hours and that happens with a first in first out algorithm so it's like a q so now let's look at the exact terms that optimism uses optimism has basically three states it's an uh either your transaction is unsafe either it is safe or is it finalized an unsafe transaction is when you have submitted it to the sequencer it is being processed but is not get settled on L1 batch so this means that this is a time where the sequencer can act maliciously it can not include your

transaction but generally it does include so you so that's why whenever you do a transaction on layer one you might see that it is instantly confirmed right so this is that is what happening right now when you submit a transaction on Layer Two and you see that okay it is confirmed on metamask what is actually happening is that that transaction is being accepted by the sequencer and then after a few minutes it will be bashed and submitted on layer one uh this type of finality is called Soft confirmation uh it is a term that is given by arbitrum the next thing that can happen to is that the transaction is actually settled onto the layer one but this is before the finality on layer one itself so there is a chance that there might be reorganizations but similar to

fraud proofs you can assume that okay because ethereum itself is a proof of stake mechanism if there is any reorganized that means that someone's St will get slashed and they would not have an incentive to do so so that will probably not happen so if safe transaction as a name suggest is pretty much safe because it is submitted on L one and if you really want to be risk prone you can wait for the finalized transaction which wait which which wait Waits another 13 minutes for the ethereum transaction itself to be finalized this is what is called as hard confirmation by Arbiter yeah that is basically a rough overview of how transactions work on optimism so now let's cover the ZK part quickly so the same thing happens

roughly that the user Serv the transaction and the sequencer the sequencer batches the transactions but instead of optimistically assuming that the transaction is correct it sends it to something called a prover now this prover basically generates a ZK proof that the transaction is indeed valid if you know if you do not have a great idea of what a ZK proof is uh assume that there is a piece of it's a there is a function that function takes in two variables X and W and it outputs a variable called Y in our case X is basically called public inputs W is called a witness which is which are basically private inputs and Y is called and Y is called the output right so a

function is basically you take some input you do some computation on it and you do an output a ZK proof is a proof that this computation did indeed happen and if you give X to this particular function it will output y but you do not have to uh tell them what w is which which makes it private which makes it the zero knowledge of zero knowledge proof that you don't need to have the knowledge of your private inputs but still you can gen generate a proof which verifies that you have done this competition correctly however that part is not necessary for ZK rovs why ZK ROV use ZK proofs is that gen is that comp Computing that function Computing that

state transition function that okay you're inputting some transactions you're inputting the current state and then you're applying the state transition function such that you receive the post State like the state after the transaction has applied this computation it is a fair bit of computation it takes work and generating a ZK proof of that would take a lot more work but then verifying that that competition was done correctly takes a lot less work than actually Computing it so imagine that on ethereum you're doing a transaction now you have to verify that that transaction is correct all of the validators in the committee must reexecute a transaction right so that is some work but if you just want to verify

but like if I execute that transaction independently on a single server and then I generate a proof the proof will be expensive but it will it will happen only on a single server and then I provide the proof on ethereum ethereum what ethereum is do is doing is it's verifying that transaction so verification is so cheap that uh it is so cheap that when all of the people in the committee is re-executing the verification part it is very it is much less competition power than executing the original proof right so that is where ZK proofs come in handy in rle of transactions so you submit a transaction on the sequencer it Bates and sends it to the approver the approver generates

ZK proofs for all of these transactions and when it has generated the ZK proof it provides that proof onto L1 and L1 basically verifies it and uh yeah that is a transaction life cycle of Z here's a diagram that explains it uh similar to optimistic rollups the sequencer can still do M and it can still drop your transactions so to provide to prevent censorship you can forcefully include transactions in Zs as well uh and then yeah you submit the transaction to the approver it generates approv and it is verified on layer one so here are the terms that are used by

Zing for finality pending basically means that uh it is part of the me pool but it is not yet included in a block by the sequencer so sequencer as you know is responsible for batching these transactions and creating a block pending would mean that it is part of the mempool mempool is uh as I've mentioned previously that each validator like when you submit a transaction to the network the transaction is gossiped around right is gossiped around and every node gets a copy of the transaction so every validator node basically maintains a list of these transactions these list of transactions that it is listening from the network is called a mempool so if that particular

validator is chosen as the block producer it uses its own mol to create a block so that's why uh it is important for all the validators to include transactions because the me pool of each validator must be roughly the same yeah pending means that it is part of the M Pool but not yet included in the block included would mean that the sequencer has received the has received your transaction it has bashed the transaction it has created a block and it has sent it to the appr now before submitting the blocks zking particularly uh sends the state that it changes so like when a block of transactions when you apply it to the previous state uh it will change the state and create the new

current state of the blockchain zync is sending this current state on L1 it is doing that because let's say that you do a transaction where you where Alice is sending 10 e to Bob right so Bob's balance is increased by 10 now there is another transaction in the same batch where Bob is sending T to char so now Charlie's transaction has increased 10 each but Bob has decreased 10 so now it is the same as the initial transaction so if you do it separately you have to do two State changes for the first transaction and two State changes for the second transaction or total of four but if you bash them and send them on ethereum then Bob's transactions are basically canceling out and you only have to do two State changes so that

saves a lot of money so like if you're doing any transaction where the state is not change like even if the state is changed like let's say the Bob is not sending Bob is not sending 10 eat he's only sending five eat right but still uh you don't have to update Bob's balance twice you only have to update it once so even in this scenario you only have to do three state changes instead of four right so that's why batching transaction is cheaper that's why Zing Ops for this where they send a state change of the bach to L one and verified is the state when the proof gener where the prover is generating all the proofs and it is committing it on L1 and then the proofs are being verified on L1 oh yeah by the

way if I didn't mention it if you submit an invalid transaction to the prover then it cannot generate a ZK proof by that I'm not seeing that the prover is not going to do it because it's good it is mathematically impossible to generate a fraudulent ZK proof you can only generate correct ZK proofs and you can only verify if the ZK proof is the true or not right so the prover is not going to submit invalid transactions and uh a similar story happens on stocket where uh the terminology is slightly different instead of pending you have received where the mempool has received the transaction it sends it to the sequencer

and uh then the sequencer batches the transaction and sends it to the Prov this part is called accepted on L2 and when the prover generates a pro and verifies on ethereum that is called accepted on L1 uh So speaking of timelines uh this received part or the pending part with the sequencer has received the transaction this happens instantly and when you use a when you use a ZK rollup on metamask and you see that okay your transaction was uh your transaction was confirmed instantly this is what's happening you're assuming that the sequencer is not uh dropping a transaction and you're you're basically getting a stoft commitment and that is what what is being shown to you it's almost

instant uh the Prov takes around a few hours four to five hours maybe might be different from for from rollup to rollup but takes a couple of hours to generate the proofs and send it to Lin and then the normal finality guarantee for lin happens and uh so yeah instead of wasting the time of the prover what the sequencer and the mull do before the transaction is being sent is that they verify and valid if the transaction is correct or not now that is not require now you are actually trusting the central Authority that okay the me pool is part of the node the node is executing then it is having its own computational U computation charges the

central the sequencer itself is a centralized body you're also assuming that the sequencer if the sequencer is validating or not it's going to is going to ball down to whether they want to decrease the load of the pr or not but when it reaches the prover the cannot generate a malicious proof so uh so you can be so if even if a invalid transaction by any case passes the meol and the sequencer it will be blocked at approval however it is also under the security guarantee that the prover itself does not have any bugs so the prover might have any implementation level bugs that someone has messed up in the code or there could be fundamental

mathematical bugs that the cryptography that is used to gener approv that itself is broken that is very very very unlikely because there is a lot of research done on it so far so finding a bug in a cryptographic library is almost impossible finding a bug in a ZK circuit slightly more possible but these uh that's that is the reason why these rollups are taking so long to develop optimism recently released their permission permissionless fraud proof mechanism recently like last week why is that because creating these mechanisms safely and ensuring task and you need very skilled

people working on these problems for a very long time to ensure that there are no bugs and there are no security issues with these contracts and that is how the entire ecosystem is basically ensuring that you can submit your transaction and you can get a soft confirmation in gently ly and when you're when you get a hard confirmation you really really get a hard confirmation that you know for a fact that it is mathematically proven that the transaction will not be reverted and your transaction is indeed included in the canonical blockchain so yeah that that was it for the lecture uh do anyone have any doubts