DappCon 2023: Shared & Decentralized Sequencers as Part of the Modular Stack - Mathieu Chanson

Transcript

nice uh yeah welcome um cool that you made it to my talk um yeah I'm going to talk a bit uh about how I'm planning to not break all your depths in the future uh the focus is actually on the not in the title that I like handed over to theosis team or the yeah the conference team we forgot the not so the focus is really on the not we don't want to break stuff in the future and this talk is mostly about yeah how we're planning to achieve that um next topic uh in the printed out agenda or if you looked last week at the agenda you might have seen that the talk is about distributed sequencing um my colleague who wanted to do that talk originally yeah couldn't make it in the end so yeah I'm taking

over and I changed the topic to talk about yeah data migration uh I think it's also going to be interested so yeah please stay here um but yeah you have to wait for the distributed migr uh sequencers uh for some other conference um yes so now I already skipped a bit um yes short intro um I'm Paul I'm working as a developer uh for cabs in the blockchain team uh we're basically taking care of yeah a GU Fork that runs the the C blockchain and yes a short um intro into cell some people might know it some people might never have heard of it uh it's an evm

compatible chain uh basically and it was one of the first chains that was carbon neutral so we achieved that by implementing like a proof of stake system uh in the days when ethereum was still the proof of workchain and this proof of uh stake consensus uh is based on the ibft uh protocol so besides this lower energy usage that gives us some nice properties uh one of them is like one plug finality which is really beneficial for people um developing yeah applications on top of the cell blockchain um and also for users because they don't have to wait for confirmations uh and so on and yeah together with like uh a current uh block

period of 5 Seconds we think that's really yeah user friendly allows a lot of use cases that yeah have been hard to achieve on yeah obviously Bitcoin with its like block time from forever but even ethereum uh before we think that yeah allows some some new cool things to be built um another feature that I usually think isn't used uh enough and that makes onboarding a lot easier is uh that we have gas payments in erc20 tokens so you don't have this onboarding problem in as you have usually in ethereum where people just want to send a transaction for whatever stable coin that they own and they have to get ether and able to send transactions from their accounts but in or on the cell blockchain you can

just use uh like stable coins uh that we offer for example a yeah we have a stable coin for US dollars or euros and you can use those to also pay the gas price the transaction costs and yeah obviously you need a different transaction type to do that but yeah still it's only used in a roughly like 5% of all the transactions on the cell blockchain and I think it yeah it should be used more I think it's pretty cool um especially in the whole context of account abstraction that people are now talking uh in ethereum I think it has the same like a big bigger scope but it goes in the same direction we're going to yeah make onboarding easier and allow people to not have yeah those problems of needing uh to own ether in

order to send transactions um yes if you want to find out more uh you can look at the website is c.org easy to remember and like a little shame Shameless advertisement on Wednesday morning uh Renee the head of the C Foundation is going to have a talk um about unlocking web 3 growth in Africa um it's going to be less on the technical side more on the impact side but yeah there I think he's going to share a nice presentation uh if you're interested in that stuff uh please go over there so uh what are we going to uh look into during this presentation um first why do I as a developer working on the sell blockchain uh do have to care about

not breaking uh your applications and smart contracts um and to understand that better we going to do like a little Deep dive into yeah State handling how State working in the evm uh how do um events work and so on so we're going to dive a little in into the data structures of ethereum and after we understand that we can look a bit in to how can we migrate uh that state and in the end um going to have some questions I mean I've been more in the nitty critty details of the of the protocol layer uh in the recent time so I lost a bit of contact to yeah smart contracts and people building on the blockchain so I'm hoping to get some

insights uh how how applications look nowadays and try to get some yeah feedback from you what do you think is important uh what doesn't make so much sense and so on um yeah again um the cell blockchain historically has been um an L1 chain but yeah we want to align more with ethereum and this this has different reasons so one of the first reasons is we historically changed uh some yeah protocol things like the header structure in the blockchain we changed that which made uh RPC calls horrible because some tools could work with it

other tools couldn't so we now want to get closer to ethereum to basically make yeah developers lives easier make them allow them to use the tooling they want to use and so on um but additionally also becoming an L2 would allow us to uh use the added additional Economic Security that ethereum offers us so there's a way more tvl on ethereum that than on the cell blockchain currently so becoming an L2 would allow us to use that basically uh for our benefit and allow for different use cases than are currently possible um additionally um yeah becoming an L2 also might improve some of the bridging story

which is currently a bit rough around the edges and yeah basically there's lots of investment going into bridging around l2s and we hope we can use some of those um so on the right side you basically uh see one of our onchain governance uh proposals where we yeah ask the community um what they think about this we basically wrote a forum post about this idea to become an L2 and yeah actually it's seems like the community is quite excited about it uh but obviously there are some constraints and these are the following So currently transactions are quite cheap uh on C so this is a requirement and that actually

means that we have to go a bit different way than current l2s or optimistic uh rollups like optimism or arbitrum are doing so they're saving all the transaction data on chain on the ethereum Chain mostly As yeah call data at the moment uh but this is so pricey that we basically can't do it if we want to keep uh current transaction prices the next thing that's yeah as I already said really important for us is this one block finality and current rollups can't really do that so we have to change some fundamental assumptions there and we think we can get kind of like a two-stage Pro process so if you don't need the highest Economic Security you

can basically have this one uh one block finality but if you want the whole Economic Security of the L1 uh in in our case ethereum then you need to wait obviously a bit longer to get that benefit too and the last point and this is where the circle closes for this talk is basically we already have a chain we have lots of users we have a lot of onchain contracts that are deployed and we can't start from scratch so we have to uh find a way to migrate our state to this L2 um so before we look into the state uh itself um just some stats so you can get like a feeling about what we're talking

here um so ethereum at the end of August uh on a full node not an archive node was roughly like a terabyte of State uh an AR an archive node usually two to three times bigger so 2 to three terabytes and the cell blockchain is a bit smaller so end of August was like like nearly 200 gab of State um yeah 200 20 million blocks uh nearly 300 million transactions and I was a bit surprised by that number that there are like 722 million events emitted so that means that every transaction roughly uh emits three events which I found surprising um because I expected it to be less than one in average but

yeah uh nice to look into those numbers sometimes um yeah and usually I think ethereum Grows by a couple of like gigabytes uh per month the state cell obviously a bit less and again all these numbers are from Full noes so they already have some State pruned what that means we're going to talk about it in a in a bit but yeah now you have a feeling for for the stuff we're talking about here um so how is State actually stored uh I think the stuff that people think about is yeah like the account storage uh smart contract data and so on so this is the first thing and we're going to look EXA

look a bit into how this is implemented in the ethereum clients exactly but for users and like people interacting with the blockchain I think there's two other things namely like transactions people want to know what have I done historically what are the transaction I I sent in the past and yeah also yeah transaction receipts including all the events that uh yeah people or applications might use in in different in different ways so those three things uh are the things I want to focus on and now let's look um how this actually works and I hope it's big enough can you read it from the back yeah let me know otherwise I can I

can explain it a bit more um yeah but basically you see there's on the left side we have like the block structure with the header and yeah the block body and then on the right side we have some uh yeah some State and those State thingies that we're going to look into soon um they have the form of a tree so they are Merkur trees I guess most people know what the Merkur tree is um but yeah as a short reminder it's like an like a data structure that makes it really efficient to compare State and also yeah makes it possible to have efficient proofs of certain State and it works by yeah you have some data blobs that you want to put into this tree and basically it works by

hashing those uh data blops and the hash of this data creates the leaf nodes of the of the Merk tree and then if you go up the tree every node is basically the hash of all its children and you do this until you're at the root of the tree and that root is basically yeah it contains information about all the other trees and if some little data blob changes um down in the tree then the root changes as well so this is what we see here uh this whole tree is basically stored in the header um we are this the state rot of of the mercur tree uh yeah now we zoomed out a bit more

um and yeah we can see there's like those three parts that we talked about the first one is about the the accounts storage then we have like some storage for the transactions and some storage for the uh for the receipts and yeah let's look first at the account storage it's called World State here um but yeah it's the most fundamental thing with that the state that the evm can access and yeah exactly let let's look a bit in how it works so in the block header there's the root of the the world State try and this basically me means that this is like the hash version of a lot

of uh data blobs and these blobs are uh account States so in ethereum today there are two kind of accounts there is like externally own owned accounts this is basically the stuff that you can control with your private key on your computer or on your Ledger and there are contract uh accounts and yeah again this is like the model how it is currently working there's talk about how to change it um with like the whole account abstraction um thingy um yeah but for now it works like this so we have these accounts and externally owned accounts they basically only fill the nons and the balance

fields and every time you send a transaction the the nons is increased and yeah the balance is just like all the The Ether uh that you that you might own for like contract accounts this like codes is also set to the hash of the smart contract bite code that is actually stored for this account and the important thing here is that like the nons and the balance are mutable Fields so those can change in which which each like uh State transition in the blockchain but uh the code hash is actually an immutable field and this is the reason why smart contracts can't be changed so one once this is deployed uh even if you have a buck in your smart contract contract you

need to redeploy it but you can't change the hash and therefore you can't change the the bite code of a smart contract so a smart contract also might uh have some data that it stores and again in this account State we only have to store the root of like another Merkle tree which uh stores the account storage and yeah how this storage exactly works it's a bit like uh too deep for this talk but yeah you can imagine it's like some yeah key value pairs uh with some data in a special way that makes the cont contract be able to access all this stuff um yeah the next part that we

talked about is uh the transactions so the transactions are actually a part of the body so uh light clients don't need all the transaction data they actually only uh sync the headers um but we're going to come to this they also store the root of this transaction trees so we can imagine this like the body includes like a bunch of transactions and this is the full transaction data and they get put into a Merkle tree and the root of this Merkle tree is stored in the header so light clients can verify data when they get data from Full nodes um the transactions itself the underlying data is yeah is transaction blobs and yeah as you may know there's like old school transactions like the

all trans actions that yeah one probably doesn't want to use anymore but they're still supported uh and then there's like yeah more modern like iip 1559 type transactions uh yeah it's not really important but yeah they all get yeah hashed put into this uh into this Merk tree and stored in this transactions route in the in the block header um the same happens for the receipts um they I have a quick question so is the code of smart cont itself stored somewhere on chain or in the state or not uh actually not it's stored in the database and just the hash of it is stored so you can you can verify that it's right but uh you might have to

request it okay um yeah so for the receipt it's it's the same uh in order for light clients to work there's the root of the receipts tree get stored in the header so the light client might not know what the receipts are for a certain block uh but when they request the data from a full node they can actually check that the data is correct which yeah it's kind of cool that they thought about it in the beginning of ethereum to yeah make it like client friendly um there's another cool thing uh to know about receipt so um events that are emitted by the blockchain they are stored in the receipts so often we want to do some filtering on like a big interval of blocks and this is you can imagine it's

like a a sequential scan on a database so we have to go through every block and filter out all the events that are matching and if we would actually have to go down in this in this tree and like check every every little event then it would become like horribly inefficient it already is inefficient to do thisle quential scan and there's better solutions to do that um but there's a little optimization that people put into ethereum and this is basically we add like a bloom filter in the header and this combines all the indexed event Fields um get basically put in a bloom filter um some people might have heard about it it's a probabilistic data structure

and basically you can have false positives uh but you can't have false negatives so that means if if you see in this Bloom filter you can check is this is something matching the signature and if you get a receiving yes then that means probably there's something included that matches that signature but if you get a no this is not included then you know for sure so basically that makes the the sequential scan a bit faster by going through each block looking at that thing if it matches then we have to go through the whole receipts list to check in detail if not then we can just skip to the next block so now we looked at um yeah how

these like three things uh work uh yeah data structure wise in ethereum and now I already mentioned that we have like that there's a difference between full nodes and archive nodes um the important uh thing here is that usually people aren't interested in whatever Old State so as we see here uh at like a certain Block in in the blockchain's history there's always a link to the state rout at at that point and in theory you you could carry that but often when you just want to estimate the gas price of a transaction or look at the state of a certain contract you're

only interested at the current state of the blockchain not in the state like one year ago so in order to optimize that we can basically yeah look which parts of the state try aren't uh Linked In the state tree anymore and just remove them and yeah as I already told you this usually removes the uh like reduces the state by uh yeah by a factor like 2 to three um yeah for transactions we actually can't remove them um yeah we might need them again uh to to yeah look at them look at the history and Reeds also they

might be removable but at least in in G they aren't uh so in theory they could be reproduced by either querying them or like re-executing the transactions but I guess also the the amount of storage you could save is not really worth it like removing them so most of the of the state pruning actually happens in this like World St World State try that's as they as they call it here so uh sure because you were also can only accesss

never know they canun transaction and receipts valid No Ex exactly like it's more like if you want to qu them and I think that's the main reason it's not really worth it at the moment to prune them but for the tra State transition to check that you just only need the current the current block the current state try and then you can check the state transition for the next block so I just didn't understand why then the receipts and transactions

I I think I think it's not really technical reason I think it's more convenience reasons that first people might want to querry that stuff like transactions okay what are my transactions in the past and it would be inconvenient and probably not really worth it compare compared to the state pruning of the the state try to remove those and the same with events that at least yeah when I was doing stuff like it was common to okay give me the events for the last year of uh of token or whatever so in theory you could remove it but it would probably make it even more complicated to people to understand oh what's a full node or it's like a it's a full note that also has pruned events so I really can only use it to yeah estimate transactions or look

at the current state of things does it make sense okay but then like it makes a difference what kind of potentially break the SM contracts like removing trans cont exactly cont usies on events yes yes so as we saw like in the in the header we we always have this uh transactions rout So in theory if we remove them we could ask another full node please give me this data but then it would become like more centralized and it's like a lot more pressure again on archive noes and so on so I guess this is some kind of trade-offs where

people actually decide okay this like storage savings are so small and it might be so convenient for people to have that data that they don't actually remove it at the moment maybe it comes when the blockchain grows another five years that people say actually now we can save a couple of gigabytes by removing that stuff and we remove it for everything that's older than two years or something like that good um yeah so now coming back to like this L2 to L1 to L2 um transition that I'm working on and where we basically want to bring over our current state um how can we in theory do that um I see two ways the first one is

just do what every ethereum client or cell client does we start at the Genesis block uh We sync the whole chain go basically through every straight transition check that they match uh what we see from the data we get from all the other nodes and yeah do that for a while I on ethereum it takes like yeah at least a couple of days or weeks even nowadays and yeah get to the tip of the of the chain and then we yeah continue whatever we want to do uh the other option that I'm working on is like doing something that's I found like people call Regenesis so we basically do some kind of a snapshot of the of the blockchain and remove all the history and but move the state try into this new

um into this new genesis block um but first like let's look a bit at the trade-offs um so when we would want to sync this chain that also means that we need to support all the historical versions or quirks of the protocol so in ethereum it's a yeah I'm not actually sure how old it is now but yeah we need to support all um all the like object formats how the header looked like and so on we have to confirm to all like the evm behavior how did certain yeah bite codes behave uh we have to implement all of the hard Forks

that happened in between even though we only want the chain to work in in the current uh now and here and we also have to support that for the unforeseeable feature so the the client is only getting more and more complex and yeah to give you a feeling of that of course I selected this uh because it shows that quite well this is how like an evm inter prer is uh created in the guest code base at the moment so you see there's like for all the hard Fork that happened in in the past and are about to happen there's basically different instruction sets and and all over the g code base there are those little if statements if this hard Focus enabled then do this if not uh do that and yeah you can imagine how how that

increases complexity for testing uh yeah from my experience like the stuff only gets worse and you can't really remove all stuff ever because you need to support the sync process and that means you you need to run all of these uh code paths eventually um another negative point is like what I already said uh the syncing process like scales linear with the block height so the longer the chain gets uh the longer it takes for the first thing making it like yeah increasing increasingly yes sorry question iiz I don't understand so we have blockchain with its own State we have ethereum and

now you're talking about sying ethereum from ethereum Genesis in am I right uh not really so now I'm talking about the general like if we would something to do in ethereum then we would need to support all this all these different I just my okay if you're MRA L2 becomes an L2 why do you care about All State uh I'm just taking as example I could have also shown in like some code snippet of cell it it looks the same just that some of the hard Forks are called differently but what I'm basically wanted to say if you want to support Zing like any any chain you need to support all the hard forks and all the code that was ever all the protocols that were ever executed

during the life of that chain would be exactly so from yeah I think 2017 or 2018 yeah I'm not sure I shouldn't can you just not take the the current C State and just basically declare it at Genesis of C L2 that okay this is the initial state by definition that's where we're coming next um yeah so yeah good point we we're getting there and yeah so the syncing takes more and more time so ideally for people coming into the ecosystem it gets more and more like oh you start this note and then 3 weeks later you might be synced or something happened in between and you have to start from scratch so uh it gets

more more and more hard and people are more and more using uh yeah centralized uh providers to do that kind of stuff inste instead of running their own noes so what we are thinking about is yeah basically what you already said we we want to do like a new genesis block but put the state we already have in there somehow so of course it's it's not that easy and and yeah one of the big trade-offs would be that we lose all the historic transactions and all the historical events um they would be still carable we could keep the old nodes running before that event and carry that stuff but yeah it would be a bit harder

for developers to yeah they would have to do something to to carry that stuff um so quick intro uh how like a chain is created at the moment um again at the example of like the G client so on the right side you see like one of this Genesis configs this is basically the file with which you can create a new chain you see at the top there's this config thingy uh where you can enable or disable certain hard Forks uh this is yeah kind of an old example because it only includes the really barebone stuff then there's a lot of stuff which you don't really uh need to care about and then here this aloc uh field is uh quite interesting because

that goes basically directly into the state ride that we looked at before um so this is the way in a Genesis um config to set the state of certain accounts in the state try so here we see for this address like C2 D7 uh this is basically this is going to be like an externally account and here we just say under this account please create like a like a BAL or initialize it with a balance and that also sets the nons of this account so once this chain is started then the person that owns the private key for this account will have like a balance preset in this blockchain at the Genesis block um the second account here uh this

is going to be like a smart contract account so we basically say okay it's not going to need a balance but we also set like some decode which will put this like evm bite code uh into that account or hash it like store it somewhere and put the hash in this account State and then we also set some storage for that account so if we would then uh create a blockchain based on this config uh which is like something like G init genesis. Json uh we would create uh a new block uh probably number zero and yeah if you would start it and not create new blocks on top of that you would have like at least this one smart contract and this

one account in the blockchain um now first obvious thing uh to think is easy we can basically go through the whole uh state that we have these like 190 gigabytes and just put them into this Json file right like for every account that we have we just write like a line in this uh in in this config Pro without MH so we could just say okay we we get rid of all the old blocks and just go through through every account in this in this giant tree which is like 190 gab yeah and probably I mean this is like a bit more efficiently stored so if

we store it in Json it's probably going to be like 500 gabyt I'm not sure and then we would need to import that I I guess everything was would break when we tried to do that so this is kind of the first idea but we can do like it better we can actually go at database level and yeah hop over this this export import process on the way um yeah so I'm mostly working uh yeah on the on the GU for for this so in in guest the the data is actually stored in a in a key value database uh that is like underlying the whole blockchain and so what we do there we open this database and we're looking for the latest Block in this database

and in this latest block or in the latest the header of the latest block we can uh get the root of the of the state tree and store that because this is the important part that that we want to keep we want to put that into our new genesis file and then we can actually go through the database and there's going to be like these like 20 million blocks that I talked about in our database and we can just remove them so we just delete all the history have to be a bit careful that we don't delete too much data but actually the blocks and the headers we we are not interested in them anymore so we remove that stuff and then create by code a new block uh whatever it's going to look like we can set it up as we like and importantly

we put this yeah the root of the state try in there so by then we have a new um Genesis block uh that references the state um that we that we had in the chain before just that we removed all the history and removed like 20 million blocks um now important uh to make clear is that everyone could do that so everyone who has like a like a cell Noe and is doing this migration which is probably set at a certain point of time can check this process so it's like a tool that you can run which going to be enabled at a certain point in time and everyone can verify that the new genesis block that we're like putting online wherever uh is actually correct

and decide to not follow the chain if we yeah try to build whatever Back Door in there or yeah change account State however we like so this is verifiable everyone can run it uh and so so nobody needs to trust us um but now we're running into a different problem um so now everyone who is running a cell node can actually do this but how do new people like that just want to think with the network after this reg Genesis event actually sync it so the problem is now you can't go through the chain and apply all the transactions and actually get to the end state but you need to somehow uh sync those like uh 190 gigabytes of data

which is not included in the uh in the chain or it is included but it's not really available um so something that uh optimism is working on for their super chain is basically that we extend the Genesis uh definition a bit and this is like all the the common stuff that's already in there but we're basically extending by extended by saying we also can give it a state hash so we basically say we put a reference to that state tree in uh that we want to have and the clients will accept it saying okay this is the the state I want to I want to have in the end and for now I just accept that I I have a Genesis block and

I have a reference to to that hash but I have to find out what the underlaying data of this like giant Merk tree actually is and yeah and then we can already use like existing in protocols so there's the like the eth protocol which actually notes use in this P2P network of ethereum to exchange blocks and headers and so on and even better the snap protocol uh which is especially optimized to sync uh state in ethereum because it does like bigger chunks so you have like less round trips and it's yeah in general a bit more efficient in doing that so um yeah the procedure there would someone wants to the procedure would be someone wants to uh sync this chain he

downloads this Genesis file which includes the state that everyone else can verify by using our migration Tool uh the client loads that sees like oh I'm actually missing some state for to verify the state hash and then starts the snap protocol to actually ask other full noes in the network please give me this data and slowly rebuilds uh this stay try um yeah obviously this whole process is not without outside so as I already said um we're going to lose all the um transaction and evade data uh which is not nice but yeah you can still get it yeah you can still run the notes from

before this Regenesis event uh which is not ideal but it's still there I mean it's not lost and yeah it's just maybe a bit more inconvenient to access it and building a seamless solution to access this might might actually not uh worth it I'm not really sure but if you imagine like some E Event filter query that goes over this Regenesis event you would need to split it if you want to provide a seamless interface you need to split it you need to send both requests to the old nodes and the new nodes you need to wait for their uh results uh combine them again and send them back to the user which yeah it complicates stuff to really make it work for for every

possible case is probably really hard and I'm not sure if it's worth it so that's something I'm yeah I want to discuss with you um a bit later or actually now because yeah so my feeling is that uh for transaction I think this is like totally fine but my questions for people working more on top of the blockchain is do you still rely on events nowadays or is everyone using yeah other like indexing Solutions yeah the graph comes to mind uh is that something that that you're working with would losing events from the chain history be something where you say like okay no way this will never work nobody

will ever keep using that um maybe yeah is anybody working in in that kind of field and has an opinion on that us index actually to be very honest it's just I'm trusting the and it seems to be very good so I don't care about the events on now but it's sometimes convenient on on the client side to just pass for recent transactions and events all of something this is only really true for for something you put on it TR so if if you interact with the smart contract you have to read the ls see what happened right now

return yeah exactly so that was as soon as you would execute something on the the chain after this event it would work as before right it would just be stuff that's before I don't this is not not true for all the applications it's just for the yeah my feeling is the same I mean I I spend so much time like finding finding problems in like event thinking code and all the things that could go wrong uh but yeah maybe people have different opinions um a different question that would be interesting uh who is actually running their own blockchain nodes uh are people all using uh yeah centralized providers

to actually run blockchain nodes and I'm not going to tell anyone or is anyone like running their own nodes I know it's a big hassle okay yeah I mean it's awesome but I feel like a lot of people don't don't want to do that because I have like horrible experiences like data getting corrupted and okay the backups take forever and yeah my feeling is like I don't want to touch that stuff which is horrible but yeah cool um then yeah I'm yeah finished with the stuff I wanted to tell you um if there's any questions would be happy to answer otherwise yeah

I'm around to mingle later what's the current state of immigration have you already achieved that or you currently consider um So currently I'm at the state where I actually generated the new block I have imported it in another block and I'm currently working on this getting this snap syn to work so I would say halfways and yeah we're currently at the state like where we're done discussing okay will people actually accept that when they lose all their events do we actually have to do something yeah more complicated I mean then we could think about stuff like rewriting history uh if we want to get rid of all the other

stuff at the historic uh things that are lying around but yeah I hope that that we can find an argument that this is actually working good enough for people to accept it to yeah avoid adding spending more time on this yes understand correctly guess and everybody valid we kind of start oh sorry yes so I will repeat then from the start so um

just on this migration that you were talking about if you can comment on um how can you do this in a decentralized way because if I understand correctly um you're going to reach consensus about the snapshot height calculate the state rout with your tool and then validators will start you know creating blocks on the L2 immediately if I understand correctly and then validate a posterior that the state rout that was like written in the Regenesis block is actually correct and uh then my question maybe is how long does it take for your Tool uh to actually calculate the state rout and uh would it make sense to rather have um validators of the L1 one each independently calculate the Regenesis block and then move on to the L2 once there is consensus on that uh

yeah a great question so like the first thing you you realized which is yeah important to actually do this migration we need to stop the chain which is yeah not something that yeah I should have maybe said that but yeah actually we need to stop we maybe yeah we ask for an hard Fork at this block then actually all the nodes stop creating new blocks everyone needs to run this migration tool might be faster or slow for people depending on on their machine and then we need to start it somehow somehow synchronized again so this is all like really much uh in discussion so maybe an easier way is to start with a centralized sequencer in the beginning say hey for this process we do it then we start it again and then we afterwards

we have a second hard Fork where we bring back decentralized sequencing something like that uh but this is something which is a bit like further on the road map for now I try to get this working with the centralized uh sequencer which would basically allow me to get rid of that whole problem it would be okay one node does it then the sequencer starts again and everyone else can verify if the block the sequencer uses as the new genesis block is actually correct thanks and maybe just to if there are no other questions to continue on that in principle do you really have to stop the chain I mean I guess once you fix the block at which you want to do the snapshot uh the underlying chain could the Legacy chain if you want could continue forging and not enough validators I guess According to some

sure that's that's always the option right that people say like oh I don't want to do this I disagree with becoming an L2 I just continue the chain um that's possible but if you would continue and you want to follow on the L2 then everything that's every block that's created after the fork date would be lost so all the transactions that you sent on the old chain which is discontinued would need to be reapplied to the other chain right but then just to conclude my last question which is actually where I wanted to get it I was always curious in this situ ation you have a proof of stake system right mhm so you have some sort of not in a stake problem but actually between you know the L2 and the Legacy chain in the sense that if I'm validator um why should I

stop forging on the Legacy chain why can't I continue it forever and ever as a fork if you want like AO classic yeah I mean you could do that I mean I hope that people agree that there's enough benefits with actually getting this like additional security from becoming an L2 like the additional benefits of being closer to the ethereum foundation having easier bridging that this convinces the validators to to join that but this is actually a task we have to do to convince them but you could do both right if it's proof of work you can't because you have to split your resources but yeah okay cool any more questions nice then thanks for [Applause]

attending