Demystifying L2 Transactions by Chris Buckland | Devcon Bogotá

foreign [Music] so welcome to the workshop it's going to be quite Hands-On uh if you so I was wondering how many people have laptops and they're kind of ready to follow on yeah okay so maybe I'll do it live as well and if you want to follow along that'd be great and do it yourself that'll be that'll be good um so the topic of the talk is to look into what an L2 transaction is in the context of arbitrim so there are a range of different l2s um but the one we'll use today is arbitrim and L2 transactions will differ between those but some of the concepts will be um passed between them so yeah so there's some differences some similarities uh we'll go into some of those um and I'll first give a bit of an introduction about what a roll-up is and that's what I mean by L2 in this in this context and then we'll go into uh the workshop itself foreign Okay so at a very high level a roll-up is a side chain it's another blockchain but it's connected to some sort of base chain by a validating bridge and if you want to read more about this there's a paper by Paddy you've sat in the back of a room over there um so you can get more information there and this is a kind of rough overview of how it works so you've got one blockchain at the top which is the roll-up you've got the main blockchain at the bottom which in this case would be ethereum and they're both progressing via State transitions new blocks are being made um there's a bridge contract on the base chain on ethereum and periodically an operator will take the state of the rollup of the roll-up chain and they'll paste it into that bridge contract that once it's in that bridge contract it can be checked so in an optimistic roll-up case there's a fraud proofs that are used for checking that state and in the case of a ZK roll-up it's just a ZK proof but the other crucial thing is that green blob that I've put inside the the bridge contract and that's data that's associated with the state transition so you on the on the roll up you need us like a minimum amount of data to be able to recompute the state transitions that are occurring on the on the roll-up so in the case of optimistic Roll-Ups that's going to be the transaction data itself and yeah it just continues in the same way and this would be the case where some data was put Unchained the fraud proof is checked and is found to be invalid um yeah so this is a kind of rough life cycle of a L2 transaction so a user would create a transaction they'd submit it to a sequencer who would then be collecting these transactions into a batch when the sequencer has got enough transactions they'll compress this batch using some standard compression algorithm in arbitrim's case this is broadly and then they submit the batch to ethereum so that's this green blob is that batch there yeah and another kind of difference between L1 and L2 transactions is gas so as I've mentioned L1 turns like L2 transactions need to be submitted at some point to the L1 and someone's got to pay for that So eventually that's going to be the user and that that cost is associated with the call data that is required that is consumed by the transaction on L1 and is priced at the price of L1 gas then there's L2 gas which is basically the same as L1 gas the same gas that you know on ethereum but it's at the price of L2 right so this is just the execution of the transaction that's occurring on L2 so you pay first to put the transaction on L1 and then to put and then to execute it on L2 so there's these two different costs and we'll kind of go into that in this Workshop yeah so this is the URL so if you go to this GitHub repo and you can start following down the the set of instructions so there's a set of prerequisites that um include tools like Foundry JQ um and broadly itself um and you can start following the steps yourself or you can watch me do it as I go yeah okay yeah so I've included some useful links at the top there's some rpcs there to connect to both arbitrum and to ethereum and just some other stuff some general information if you want to read more about like L1 L2 gas and some of the ways in which arbitrim works that are relevant to this talk yeah so these are the prerequisites um it's just there so you can clone this repo itself we've got curl for making some requests Foundry for using cast cast is a kind of tool for helping you format um ABI style uh functions for calling calling the Json RPC JQ just for formatting some Json and broadly which is the compression algorithm that's used in artichoke yeah so there's there's a quick setup stage I've already done this um I'll paste this in yeah I'll just check those there okay so the first step is to we're going to send the transaction on um L2 so I've already sent a transaction which you can use if you want um in your example or feel free to like use your own like metamask connect to arbitrum and send them like a transaction on mainnet at the moment they're reasonably cheap I think so it should cost you only a few cents to do that if you want to but this transaction hash if we look at it on on Arbor scan this is a usdc transfer basically so this is just transferring some tokens and that's the this is what we'll look into today um yeah so I'll set that environment variable and also feel free to like if you've got any questions at any stages as I'm walking through this just stop me put your hand up we don't have to get through all of this today so just you know let's talk about it and if you've got questions you know just put your hand up at any time yeah so first we'll kind of grab a transaction receipt for that and there's two interesting things in this transaction receipt that you might not be used to when uh looking at L2 compared with L1 transactions so this is this L1 block number which is uh the block number that the L2 sees of L1 so it's a kind of like LDL one is it's reading the state from the L1 occasionally and one of those bits of state is the L1 block number you can access this as part of the arbitrary VM and then the other thing is this gas that it used val1 and that's what we're going to look into so this is the amount of gas that was spent uh to send this traction transaction and get it recorded on L1 yeah so we're going to store that in a variable oh yeah okay foreign and I'll just Echo that out so you can see like roughly what it is so it's like 236 000 gas so that seems like a lot when you think about just what it's doing is storing just a bit of data on the L1 but the reason why it seems like a lot is because this is in units of L2 gas so this is this has been scaled for what it would be if it was on L2 and that's just to make the accounting a little bit easier inside the inside of arbitrum so this amount we need to find out what the ratio between the L2 gas and the L1 gas was at the time this transaction was sent to then try and really figure out how much L1 gas was used and from there we can start to figure out as well like how many bytes of data it might have consumed so store some of these variables as well foreign okay yeah so as I mentioned we need to find out this ratio of L2 to L1 gas so the the roll-up is is estimating at any one at any point in time what it thinks the L1 gas price is and it's a little bit more complicated than just reading the L1 base V because there's a time lag between when the sequencer processes a transaction and when it submits it onto the L1 so it does some kind of estimating and it moves moves its price up and down depending on how accurate it's been in the past um to try and make sure that it keeps even um and so there's this uh L1 get L1 base fee function which is what was really used by the um the arbitrine virtual machine to well by arbitrim sorry to to figure out what what L1 gas prices it should charge yeah and there's a bit more docs here if you're interested in reading about like exactly how that works yeah um and maybe we should go a bit more into that because I realize we're running quite quickly on time because I guess I thought everybody would be following along and there'd be lots of problems but I'm a skilled pro at this so it's going quite quickly um yeah so one interesting thing that happens with that with that estimation is that um you because because the sequencer is having to try and figure out what the price will be when it submits to L2 um it's kind of a it ends up wanting to overcharge to not get out of pocket itself so arbitrim has a slightly different mechanism there where um the sequencer is rewarded later for exactly how much they spent and there's a kind of a pool that sits on L2 and the ball starts quite full and then the difference between what it was uh awarded and what it estimated in the first place is then reduced from the pool or added to the pool if they're overcharged and then this is you this difference between what the pool Target should be and what it actually is is taken as a factor into the future estimate of what the L1 gas price should be um so the sequencer never ends up out of pocket they always get exactly what they paid um but there is some mild fluctuation between what users pay now and what users pay in the future so some users now might receive slightly less than what they like get a slightly better gas price than what they expected some might get a slightly worse one but overall it's quite quite close to the average quite close to what you should be getting so we'll call that pre-compile at um at the Block Heights so that for this we need an archive node and we're going to call the the pre-compile at the block height when this transaction was sent on L2 and then we'll see what the estimate was at that time yeah absolutely yeah so so you you want to know what the what the estimate was at the time that the transaction was sent so you need to know what the state of the the node was at that time and for that you need an archive node a full node wouldn't be able to do this yeah say again exactly yeah I think I think full nodes do keep some recent uh historical States I can't remember exactly how but probably not a week's worth um yeah so you so to do this kind of thing that we're doing now you would need an archive node but this isn't something that you might normally want to do this is just kind of like let's go look at some of the analytics it's not part of like you don't need it to for to send transactions or things like that and there are ways to get estimates for what these values are before you send your transaction as well so you know what you're going to spend you don't have to wait and inspect it afterwards if you want to yeah I think there was someone uh-huh yeah okay thanks yeah foreign it's not it's not a snapshot it's just well yeah okay you you need you need to know what the state was at that time because this is stored in State this L1 base fee estimate so at a different block height the L1 based vs will be different and we want to know what it was when this transaction was sent yeah uh this yeah so this the sequencer has to pay some costs to put this data on chain and it wants to get refunded for that um so this is this estimate is is in the system it's under like you might say it's under consensus of the of the al2 and the sequencer is forced to use this value uh in its estimate yeah well the the currencies are the same so the the but it's both if is the unit of accounts yeah on both of them yeah but the gas prices are different and they're moving and this is just a wave to try and estimate that movement of gas on L1 foreign okay so let's make make a score yeah so this was an estimate of the base fee at the time the L1 base V estimate which is about eight way it looks like so that's what it thinks it was at the time and we'll store that in a variable foreign so as I mentioned we want to work out this ratio so that we can scale the L1 gas used in from L2 gas units into L1 gas units so that it starts to make sense to us again so we also need to know what the L2 base fee was at that time and this we can do by just fetching the block at that height and looking at the base fee in it yeah which is 0.1 Gray so arbitrum has like a minimum um L2 gas price which is 0.1 gray um if if congestion happens then it will go above that but generally it just sits here if it's not if it's not um being used heavily at the time okay so we'll store that as well and now that we have these two ratios we I mean these two um these two uh gas prices we can use them to calculate the ratio so have I stored this already yeah that was about oops so there's the actual amount of L1 gas that we used at the time so which is a bit more what we kind of expected and if we divide why did we expect that no a bit more like not more than uh it's it's like what we expected yeah uh yes yeah it's a really great question so we do compression over a full batch rather than individual transactions which does leave you with this problem right how do I know what um my transaction how many bytes it will use in the compressed batch rather than in in in the other amounts so what we do is we it's it's very hard to figure that out and do it fairly because it also depends on ordering and things like this so what we what we do is we compress your individual transaction when we give you an estimate for it and so if your individual transaction is more compressible you'll get a better you'll get a better estimate for it and you'll you'll be charged less but that still isn't quite the perfect scenario but that's the kind of like halfway house that we've arrived at yeah foreign okay and so each unit of each byte of data on L1 consumes around uh consumes 16 gas if it's a non-zero byte so as an estimate we can say that this consumed around like 180 bytes of data so we can then actually go and take a look and see if that's kind of what it did consume so to do that we'll rlp encode the transaction which it's got I've got an error in my script there I think um this aabcc doesn't look right again yeah I was doing a bit of debugging yeah so this script what it does is a high level at a high level it's just it it requests uh transaction receipts uh takes the bits out of it which are important for RL for for an actual transaction uh rlp encodes it and just spits out the result with the zero two prefix which is Type 2 transaction so if we do that again oh I'm not sure why that's oh yeah thanks there we go thanks for geisha okay and if we count those bytes let me see it's about the same yeah yeah so we spoke before about uh yep so again that's all right I can't quite here yep so ROP is just the format of the transaction that ethereum accepts and then we'll include rlp encoded transactions into a big batch and the batch will then be compressed with a compression algorithm so rlp is in compression it's just it's just serialization is there a way uh you don't need to you uh yeah because what you what you so what runs under the state transition is the full decompression so when what you're when you run the Ford fraud proof you're bisecting on the parts of the state transition so if the decompression is within that state transition then yeah you'll be able to decompress you don't you don't need an implementation of the decompression on L1 you need it on L2 and you need to included in the state transition yeah foreign yeah so let's try and explore the batch there's a function on another one of the pre-compiles that you can find in arbitrum to find the batch uh containing a specific block which is this one so we store the block number earlier and we'll use that to look up the batch these pre-compiles by the way are they're kind of like the way in which arbitrim customizes itself compared to ethereum so it needs to do some special things like this um and they've been added as recompiles so they can be found at like different addresses um that you can find at the top of the files foreign a little bit longer wait a minute oh yeah there it is so 974 was the batch number I don't know why I printed some rubbish but oh yeah it's because I copied the there we go um yeah it takes a little bit longer that one because we're doing oh no no it's not the longer one okay this one might be a bit longer so given the batch number we need to find the transaction that submitted it and we need to look at the call data that was in that transaction because that would be the batch um so we need to find uh the transaction and we do this just by looking up uh the logs that emitted this specific batch number um yeah so this is the transaction ID so if we go to etherscan foreign transaction ID this is the batch itself and if we scroll down and look at oh oops so it calls this function add sequencer L2 batch from origin and if we look at the original this is all the batch data so it's a large amount of data being submitted in one go yeah yeah we can even look at this function in the code so this is the contracts which is called the sequencer inbox and it's where this sequencer submits these batches um and this is the batch data itself so we're going to try and grab that data and decode it and the way that um the way that variable size um arguments in in uh in yeah in the evm are encoded is at the end and we've been there as a placeholder for them inserted at this point so we'll find this data at the end of the of the arguments list um and given these all fixed size arguments um we can know the exact position in them in that uh in that input which is uh well first we'll download it actually yeah yeah which is 458 is the is the position and we'll put it into a file so if we open so this is the raw batch data that we downloaded raw is compressed exactly yeah so so yeah this is pulled straight out of the call data and this is what the sequencer inputted so it's compressed yes exactly exactly great question and we'll explore that in step five yeah um yeah so if we open the file we can see that it begins with this zero zero at the start and this is not part of the compression this is just a a type of the data so there are some different instantiations of arbitrim one is called arbitrum one another is called arbitrum Nova and they handle data in different ways so arbitrim1 does this compression it stores all the data on ethereum Nova doesn't it stores its data with an external party that external those external parties sign that they've received it and they put that signature along with like our commitment to that data on chain and this zero zero here just tells us that the type of this data is roll-up data it's arbitrine one data so we want to remove that before we do the compression I do the decompression sorry so we we take those off and put it into another file and then we just remove those those front two zeros and then this is the uh the commands to decompress the badge so first I'm going to convert it from hex into binary then I'm going to use broadly decompression and then I'm going to convert it back into hex and put it in a file um yeah and it outputs this uh warning because there's some zero bytes at the end which aren't actually relevant to the the compression but get added because of 30 like 256 byte words okay so if we look at that this is the actual batch data and we can look at the size differences now between the the compressed and the decompressed make that a bit bigger so we've got this one which is the uh uh wait what was it which one compressed which is a 198 bytes and then we've got the decompressed one which is 715 so you can see the difference in the ratio there and the the effectiveness of the compression yeah yes exactly yeah you you the if the shared structure between different transactions then they're going to be included into this compression and improve it yeah um this is a bit of a um the compression isn't actually this good because this if we look at this batch data it can it includes a lot of zeros and zeros um are charged at a different um amount in in gas in the evm they charge the four by I think four bytes uh four four gas per byte rather than 16 for non non-zero bytes and the compressed batch will be almost no zeros in it they'll be it'll be much more like a tenth of the more zeros right rather than oh a 16 sorry yeah [Music] um yeah so it's it's not quite as good as it's showing here but it's still quite good you can work it out by like doing some more complex analysis but we won't do that here okay uh yes we've compared those and then the last thing to do is that our transaction should be in that uncompressed batch so we'll go and try and find that so if we Echo the the rlp I think I had it in raw Maybe let's see where I have it oh foreign so this is our transaction if we go into the batch and there it is so along with a load of other transactions foreign yeah and that's basically it for the workshop so if you've got any more questions yeah yeah you can you can do that yourself as a developer so that on arbitrum there's a registry where you can register address against an index and then you can substitute them an option will know that you've done that and it will then um switch them back out when it comes to execute and in that way the sequencer will charge you less for your gas yeah yeah because when when you're compressing um the addresses in in a batch then it does a lot of that for you anyway like so it the two yeah it's one one was like a a legacy system where we would do that we would allow users to do this themselves and now like the whole holistic batch way achieves a better result do you have the second question yeah can everybody hear the questions by the way or should I repeat them yeah sorry yeah no there's not so like optimism Muse said lib I think and we went for broadly the reason was is because we did some analysis of different compression algorithms and we found that probably performed best um and I guess they did a similar sort of thing and chose settler for their own reasons um yeah I don't know I don't know how important it is to standardize this specific part of the Roll-Ups because it's it's something that users shouldn't really be interacting with generally um and I think that's the most important part to standardize um but yeah it would be interesting to to see why they chose those that as well yeah uh sorry I didn't repeat the question here I asked if there would be uh if there's any efforts to standardize this compression algorithm across different altitudes yeah registry compression yes yeah so there's an address registry that you can use you you register and address against an index and then that will be used when upon execution you substitute your indexes into your transaction and then there will be de-substituted from the registry upon execution to reduce the amount of call data that even goes into the batch itself here um it should be foreign opportunity so we used to have it in our docs we've just recently revamped them and I'm struggling to find it but we did used to have it there do you know where it might be tricky short friend address for industry so we've got our address table here which is the yeah so this is like a bit of documentation but I'm sure we had some more documentation about actually how to use this contract in pre-compartmently okay maybe we can do this afterwards as well yeah yeah yeah so the the compression the broadly compression was part of nitro exactly yeah it was one of the major parts that produced the cost previously we didn't compress I don't yeah yeah um yeah so the question was uh why the hard-coded minimum base fee um I think that's partly just to avoid like us um getting loads of State load early on for very cheap price um given that we may expect users to come on board onto the platform and the gas price not to always sit there it would be good to not the future not to be burned by that kind of Legacy Behavior yeah yeah yeah so the question was the execution occurs on Layer Two so what's happening on layer one what are we putting there yeah you just store the data such that there's an there's enough data there so that anyone who's observing ethereum can recompute the same train State transitions that are occurring on L2 and that's important so that anybody can can take part in a fraud proof um uh game yeah uh yeah yeah we have two ways of doing it so that I'll open up that contract again uh the question was um uh in the in the contract do you need to emit all of the data that the batch data in an event or can it just be in the call data of the transaction uh yeah so there's that we have two functions for that one is uh submitting it from origin and in this case we know that the that it's being sent from the transaction origin and therefore we know that the call data is going to look like this so if we know that then the L2 can reliably grab data out of the call data if the sequencer is you know going via some other contracts or it's not coming from the transaction origin then we emit the full uh batch data in an event so in production this so this is here if if it were needed but in production it's way more expensive so it's never used where do we not need what sorry yeah so to clarify on what we're doing here we're emitting a sequence number and what the L2 node will do is it will say okay I've got a new sequence number I'll go look up the the transaction related to that sequence number I'll look inside the call data I'll find the batch basically the same process if we as we've just done and all of that all doing all of that is part of that state transition function so it's all yeah yeah um yeah um yes execution happens online too yeah Penn State is online too as well yes sorry I missed a bit you said it was foreign no so the question is does the execution also take place on layer one as as well as on Layer Two and no it doesn't we just put enough data such that anyone who's reading the ethereum can then go away and recompute themselves what would have happened and take part in this fraudproof game because reclaim a lot of blocks correct exactly yeah yeah you need so so yeah to if you want to know what the state of the L2 chain is you need to replay the history of the chain in the same way that you would replay the history of L1 to figure out what the state of L1 is um yeah so the question is is can I find out States about a specific address without recomputing the full State on L2 and the answer is no so the state only exists on L2 and that's only where you can make questions about the state uh yeah I believe yeah so the question is can you sort of game the system uh take advantage of this of this minor fluctuations in L2 gas price to try and achieve a better price for yourself and the answer is yes yeah you can uh yeah foreign yeah so I think that's that the question that comes down to a little bit around your security assumptions um so in order for the state to in order for you to be confident of ethereum States uh you want a wide range of people to run full nodes such that if an invalid State transition occurs a large number of people can get together and form consensus that that was an invalid State transition that should be a rejected fork and we shouldn't ignore it but with uh roll up this there's a slightly different um safety assumption which is that if any single one person uh notices that there's an invalid State transition then that one person can enforce that the state transition is is corrected so it's you don't need a large number of people necessarily you it's a kind of one of many one of n security assumption rather than like an N of M and so this means that maybe you can afford to have less people actually running the L2 nodes yeah and and so have maybe slightly more beefy machines yeah yes yeah yeah we can go into it yeah sure so the question is is like how how in practice do fraud proofs work okay yeah so two parties take place in uh a fraudproof game to figure out which of them has chosen the correct state and then one of them wins which is what you what you're asking about and at that point that state is that the losing state is rejected more people can challenge The Winning State if they want to but the losing state is rejected whoever chose to uh take part to defend that side of the state will lose some stake because you have to put at stake to defend a state um and the if no one if no one comes to challenge The Winning State then that will be accepted as the correct State and you'll go on from there no the L2 doesn't deal so if you're running an L2 node you've got your if you think about a fork occurring on ethereum you've got some people that choose different rules for their node that doesn't mean that you need to stop running your node with the what you see is the correct rules and the same kind of happens on L2 I can run my node and I can see which of those two is going is going to win the challenge because only one of them is correct and I know which one of them is correct so I can continue to accept transactions validate them and we can continue to process them in that time what you can't do during that period is withdraw funds from the system so withdrawals are paused whilst this fraud proof game is taking place because ethereum itself doesn't know which of those two states is going to be correct so the funds stay in the system while it's happening but we can still progress the state as an as an external viewer yeah foreign [Music] yeah so the question is it's like if two two states are in violation of each other is people defending either side um what is the what are we actually challenging where what's the state transition that we're challenging is it the pre is it from the previous state to the current state or is it further back and the answer is it's just the previous assertion yeah foreign proofs take place in the solidity contract uh and yes they do but the way they the way they work is that there is a bisection game that the two parties play we don't want to execute the full State transition again so instead we try to decide which part of the state transition we disagree on so we take the state transition we bisect it into many parts we allow the other person to choose which part they disagree with and which part they agree with and so you always you have you're reducing the size of the state transition always keeping a point that you both agree on and always keeping a point that you both disagree on and making that smaller and smaller and smaller until you get down to a single uh opcode and then you execute that single op code up um is the question that's within a single state transition they disagree about multiple things or is it that there are multiple people disagreeing about one okay so if there's two two parties but they disagree about multiple things then I'll just be the first disagreement that matters because that's all you need to to slash the person out of the system and remove their their uh state from system yeah uh yes um so I think your question I think is what happens if someone includes an an invalid transaction in in the batch or yeah so so the optimum virtual machine will know what to do if someone gives in an invalid transaction it will ignore it basically so you can then choose to run a different arbitrary virtual machine that would do something weird with that and then we would end up at different states and we would like challenge each other over over the result of that but just including an invalid transaction in the batch isn't enough to like confuse uh an honest validator that something weird has happened or that they've got the wrong state or anything like that there are rules about what to do for every bite that you see in that batch yeah I think sorry there's one at the back first sorry how long do we have left uh these are great questions though for a long time so the question is oh sorry we did yeah so the the question is um given that uh during a a fraudproof game withdrawals are paused isn't there an attack you can do on the system to delay and cause problems for everyone else by just creating a challenge and what is the cost of that of creating that challenge um and the answer is dependent upon how high the stake is set um so that's yeah if if you have a very high amount of stake then it becomes very costly for you to cause this delay the the amount of status stake is set by the system so for in order for you to take part in a challenge you need to put up a certain amount of stake yeah so at the moment the validator list is whitelisted so it's not open to the public so so whatever amount value in there is is not really meaningful but we're working quite hard on trying to make that open and when it is open I can say that it will be quite expensive yeah uh yes now I challenge it I will become well with this challenge now this one chain malicious I could prove that I was correct so there's a separate so the question is is what if the sequencer is malicious tries to cause an invalid State transition is that a yes right and what happens when someone challenges so there's there's a separation in the system between uh sequencing transactions and generate executing those transactions to create a state to update state so the sequencer has no power over what state will be update what the state will be based on what it puts there the node software does so if the sequencer puts rubbish there the node software like um honest node software will recognize it as rubbish if the sequencer puts valid stuff there then they will process it as valid stuff but the sequencer is all it's doing is putting data onto the chain they don't enforce in any way what the state should be that's a result of that data those are the validator nodes that decide that yeah so given just some data that arrives people run any validator nodes need to decide what the result of that data would be yeah so that kind of answered the question right now yeah yeah and the nodes will know what to do when they see that so there'll be strict rules about everything that the the batch contains yeah exactly so the question is is like what can this what powers does the sequencer have in the system and the sequencer can choose ordering of of things inside that batch um but they can't manipulate what the output of those transactions will be yeah so you don't you don't trust them in any way for the security of the system the sequencer is necessary for lightness lightness of the system to get transactions moving Fred's like waving his hand over there like um yeah so at the moment there aren't right so the moment we trust the sequencer to pave well if they don't then we won't be able to use the system properly the funds will still be safe that are in there and there's a secondary backup system which normal users can use so you don't have to go by the sequencer if you don't want to be you don't get the benefits of compression but you can send your transaction yourself or you can find another someone willing to compress stuff for you and put it into uh into the system for you but they they want fundamentally the sequencer is the one who chooses the ordering and you won't be able to do that um we have like a a weight a time period where if the sequencer is not actually doing its job at all if it's not updating things or it's not including these what we call delayed messages which are user sent messages via the L1 then after a time period you can force those through regardless of the sequencer so that's the kind of backstop if you need to exit the system and the sequencer is not allowing you to send transactions yeah but it's not really the validators that are involved in that it's more the users who say okay I don't like the system anymore it's not working for me and I want to just force my way out of it yeah uh yes so that comes back to uh your your um your node software right so if you if you can see that this state is correct then if oh sorry yeah yeah so the the question was it's like what how does finality work in the system given that after a fraud proof a certain state will be rejected um so the answer is if you were following that invalid State then you will basically see a reorg probably quite a deep free-org um but if you were running on a software you won't see and you won't see any problems basically you won't see any difference there'll be no uh change yeah but you can but that does bring into the question what the finality of a transaction is in in there and as you as you pointed out you could get the steep reorg so it depends whether you're running software it depends like whether you're running node software or not you might want to wait just until that week period is off all challenges are over and then just be like okay now it's definitely fine yeah um yeah any more questions uh the question is is there an easy API that I can use to see if there are if the challenges are complete and the answer is that you can look in the smart contracts so you the smart contracts are created and destroyed when challenges exist um so you can see in in the smart contracts all the challenges that are taking place at any one time yes yes it will if you um on if you think that if you if your node software has a bug in it or you've done something malicious with your node software then you'll be following what will know will not be the canonical chain eventually and so you'll see results that will not never happen or or may happen in a different way the transactions will still be replayed so you all the transactions are on L1 so anyone who wants to run on a software can know what the final state will be but if if you're running some it's sort of like uh mutated software or something like that then yeah you you'd after one week's time you may find that all of the state that you thought existed didn't and you're actually on this other China the question is like like what the question is what happens to me when that challenge ends and and I realized that I was following the the wrong chain is that the question yeah the challenge ends no one decides to dispute this state transition basically everyone in the world is agreeing on this state transition at this point if they didn't and they would start challenging it okay um I've got to wrap up now but thanks very much for the great questions and uh yeah