DAPPCON 2025: Recent and Future Hardfolks: What Does this Mean for Validators and Users? - Philippe

Transcript

Hi. So, as has become a custom over the past years at Dapcon, I will be talking about Nosis chain and um well, hot forks and updates basically. Uh so, I always like to start a bit uh about talking about what Nosis chain actually is. Some of you still might not know. Um actually, by show of hands, who knows about nos chain here? Okay, that's a a decent amount of people, but still quick reminder. So, Nosis chain um basically is the same as Ethereum. So, it has a beacon chain, it has the same clients. Um it goes through the same hard forks and it's also all about decentralization.

It also has a few differences though. For example, it was based off on proof of authority um before the merge. Uh it uses GNO as um the staking token which is an EC20 token and it has faster block times and finality. It also has a few less blobs per block. Um so we have four execution layer clients which are mind, argon, gas and wrath. So Nethermind basically over the past year did a lot of bug fixes and performance improvements but they also developed uh this one file support which basically means that you can now export and import uh data so bodies receipts headers everything um from your node and then

reimp import it back. That's important because in well soon uh pre- mergers will actually get dropped entirely um from well nodes and then and does the peer-to-peer network. So you won't be able to sync a nodes from scratch basically without importing error files. Aragon um deployed it version 3 uh which comes with an built-in consensus layer um automatically. So you only have to run Aragon by itself without lighthouse or take or whatever. Uh which is great for RPC providers for example. Of course you cannot validate just with that and it also has statics query. So basically the same as u namines.

Um guess I announced actually last year here at tapcon is now stable. Uh it is basically well it has feature parity with um upstream guest and it also supports historical uh data for chain. So the premerge stuff and if you want to more information about guest I think Yum is actually giving a talk at studio a tomorrow at 240 if I'm not mistaken. Um and then today uh similarly as last year I can announce that we also have ref now um which is a new client. It's it doesn't support premerge headers or data at all. It doesn't support snapsync. So there are a few caveats uh but it is actually already at testing.

So you can run it as on your validator if you want to. Um quick word about uh kind diversity. It's extremely important because if um well a client has an issue your the basically the whole network it could go down. Uh and right now on noises chain almost or more than 80% actually of the validators are not mind. So that's not great if in case another mind has an issue. So please if you are validating on nosis chain and you're running mines consider running something else. So you have three options now you have um well as mentioned guest ref and aragon we did a lot of work to well get those clients please use them and save the network by

um having client diversity. So this is the hot fork timeline uh that we did in the past. So we started hard forking oh well we did the merge basically one year after Ethereum and since then we've become basically faster and faster until Denkun where we actually hard forked two days before Ethereum and now Petra which we did one week before Ethereum and then the next hard fork is supposed to be uh well it's going to be Fusaka potentially end of this year or at the beginning beginning of the next one. So what is Spectra? Uh this is a full list of EIPs. I'm not going to go through all of them because they are not really relevant I would say for users and validators but for validators specifically I want to talk

about two um so there's EIP702 which um allows basically owners of validators to withdraw and exit validators directly. Uh so in the past there were two keys so the withdrawal credentials which own the funds on chain and then a active key that is run by validators. So imagine someone here in the audience had like 100 GNO for example but didn't want or didn't know how to validate with them themselves. They could delegate it to me for example. I would run the notes for you but then I could hold your funds hostage because I'm the only one with the keys that can actually release that money. I would not be able to steal it or do anything with it, but I could basically

just hold it hostage, right? Which is very bad. With this EIP you can actually now as the owner of the funds withdraw and exit the validators whenever you want. So you are not dependent um on your node operator anymore. So that's a bit better for uh validators. Then EIP 7251 which I would say is by well the biggest one for pectra. Uh it aims to increase the maximum effective balance. What does this mean? uh basically until PEXRA if you had 100 GNO for example you would have to run 100 different validators different keys so maintain the keys and then test and sign with all of them which is um well it consumes a lot of hardware in terms of

memory networking CPU everything basically so it's not great and it's also um kind of well difficult to manage all those keys and to keep them safe um then there's an additional issue that if you had for example 1.9 GNO you would only be able to create one single validator and the 0.99 that remains are well not usable. So that's capital inefficient. Of course for chain is not that important because 1gn all things considered is not worth that much which is by design for no chain. Uh but for Ethereum if you at let's say 40 east you would have to wait until you're at 64 to actually be able to spin up a second validator which is a lot of money. So this EIP actually fixes both of these

issues. you can now um consolidate multiple validators into one. So imagine you have 100 keys. You can now just uh consolidate them into two validators with 50 GNO each. So it's much more efficient, much easier to handle. Um and as a general um I mean you should do it basically. It's way more efficient for the network even on the peer-to-peer network. So it's uh better for everyone if you consolidate. Um and you can also now stake any amount between one and 64 GO on one single valtor and you will actually get compounding interest or yield on uh any of those amounts. So if you have 1.99 GNO, you can put those on one single valtor and you will get

compounding rewards. So how does that work in practice? Basically you have two options. Um well you can keep the old behavior. So stay as it was before in this case. Well, you don't have compounding, you don't have consolidations, you run the same number of keys. I mean, basically nothing changes. You still get your partial rewards uh once every few days on uh and couple of weeks I think on Ethereum or you can upgrade to become compounding. So the new um post pectra way of doing the things basically uh and you get all the well benefits I just talked about and again this is the recommended uh choice because it's good not only for

you but also for the entire network. So how can you do this for new validators? You can use the eat staker deposit CLI which I'm actually also happy to announce now that works for Nos chain. So we have the same tools now for Ethereum. It just makes things easier. You don't have to run something different for NOS chain and for Ethereum. Uh so you just use the compounding flag or if you have current validators already and you want to consolidate them. Technically this would be done with smart contracts. But I mean honestly just use the easy way. We have a tool available for you uh here on consolidate.noschain.com.

It does have a few caveats. Um, namely it only works if your withdrawers are a safe wallet or uh with MetaMask because they are the only one to implement 7702 right now. I'm going to talk about that a bit later but it also works for Ethereum uh sepoleia and chi of course. So you can use this for all your validating needs. Uh this is what it would look like. So on the interface you would see for example here I have 505 validators that I want to consolidate and I'm choosing to end up with validators that have 32 GNO on each uh and this will result in having 16 validators in the end. So I will have way less keys to manage way

less peer-to-peer traffic way less signing and that testing. So it's way more efficient. Uh and on the second screen you see that um all those transactions normally I would have to do 505 are actually batched in only three transactions. So you only have to sign three transactions. Imagine you had um to sign those 505 transactions on your ledger for example that would take a lot of time. With EIP 7702 that is way easier. And actually talking about 7702 uh what it does basically is to allow you um to set an EOA on uh to set accounts codes on an EOA. So basically each address now becomes uh a smart wallet or you can make a smart wallet

out of it. So the pros of pros of course are that you can execute arbitrary codes on your EO. For example, you can do bash requests. So we all know this flow about uh well doing transaction um doing approve plus transfer for tokens uh into different transactions. That's not great. Now you can do this in one single transaction or for example you could send many different tokens to many different users in one single transaction. So that's great for user experience but it also has a few pros. Uh well the support is not great yet.

It's potentially dangerous and it's kind of gates kept by wallets, but that's kind of by design for your own security because um this actually well is dangerous in the sense that it makes it possible to lose all your assets, tokens, native tokens, everything, NFTTS in one single transaction. So you have to be very careful about what you do with this. Um so we just talked about Pectra and I want to talk a bit about how hard forks actually work, how we execute them. Um and of course there's a lot of preparation. So we have a lot of automated uh tools for this for testing for example hive tests estimatories to do automatic testing. And then you

have devets uh which are spun up by the devops or cordfs. For example, for ethereum it's mainly it apps um and those generally start on the hot fork before so the one that is not being developed for example then coin in this case and then for example one day later you um do the hot fork transition to pectra. Um so you can test that everything still works and afterwards you can of course test that all the features are still uh well functioning. So usually there's between five and 10 of those dev nets. For Fusaka for example the first two already were deployed. Um and well this allows teams to make sure that everything works

together with other clients. Um and yeah and the feature sets are always uh well usually different because during the development period of course features get added new IPs gets uh well added to the to the hard fork or get changed. So devets usually have different configs and are used during development and then we have test nets. Um well networks usually have a test net at least. They are usually free to use although it's a bit complicated on Ethereum from time to time but they are used for DB developers as well. So they can test on a chain without having to pay for it. They can do interoperability with it because they can for example interact with a or unis swap or noises pay or whatever the case

may be. But it's also useful for uh the hard fork because the um it's the last step basically before hard forking to mainet. Um and then we can make sure that everything still works because usually they are fairly close to well mainets. So um how did this go for pectra? It didn't go very well. Uh the first two networks to hard fork were sepia and hores. Um both failed in different ways. Seia was recovered fairly quickly. So that's all good. But Heski took way longer uh weeks actually. Um and uh yeah after that shadow which is an oyen test net actually hotforked and it was the

first one um to successfully hot fork from the get- go although to be fair it would have had the same issue as sepoleia so we kind of got saved uh by DF in this case and then a third network that didn't exist before hoodie was created um well just so that we could make sure basically that um the hot fork would go through on an actual test net before going to mainet. And this also uh delayed Ethereum mainet because rollup teams needed to have 30 days between um the last test net and mainet to make sure that they have enough time to test everything.

Um so yeah, this was basically the hot fork timeline. So Hleskin Sapoleia forked first and then shadow one day after Seapoleia. Then hoodie was uh created out of nothing. So it took a bit longer and 20 days after Shiato hoodie hot forked and then we have no sus chain so mainets on April 30 and der mainets on May 7. So what did this mean for developers? It was not great because a lot of developers relied on hlesi to um well test their applications and interoperability.

Um but the network was down so developers had to basically deploy to another network. So spin up the entire infrastructure again which took a lot of time and here I want to be a bit well it's going to be biased of course but I would recommend to deploy to no chain next time because it's a production grade network that is very cheap to use and that does hard fork before Ethereum. So you actually get for example here for one week of testing on a post fork network. Uh, and you can basically, well, it's very cheap. As a matter of fact, if you have an interesting project to deploy, just hit me up and we will pay for gas.

Um, so what did we learn from this? Communication is always uh difficult. For example, hoodie was just well messed up because uh client teams basically didn't use the same configurations. uh and this really shouldn't happen anymore at this uh stage on a production network. Uh so yeah, testing is of course always extremely important. Um and then there's some EIPs that don't don't necessarily generalize too well. For example, um the issue that Cipolia had is that one EIP um basically assumed that there was only one event in the deposit contract which was the case for it mainet but wasn't foria and also

isn't for nos chain and shadow. Um yeah so it's basically a sad error in the sense that filtering events is trivial and actually extremely cheap in terms of computation. So it was worthy to do it from the get- go and that's also the well the fix that was done later on to fix a polia and our networks as well. Uh so yeah just filtering the events could have saved uh a lot of time in this case. So we have to be very careful about yeah generalizing EIPs basically and as for nosis to make sure that EIPs we integrate actually fit um because our network diverges from Ethereum a bit.

All right, so moving on to Fusaka, which is the next fork. Um, this is the list of EIPs, but I'm actually not going to talk about any of them because I think they are not very relevant for users and validators. It's basically all about scaling. Um, but if you want to learn more about scaling 1, there's a talk uh from Tony Washer from DF tomorrow, studio A at uh 2:15 if I'm not mistaken. Um, so yeah, that's it for me. Thanks for listening and if you have any questions, please go ahead.

Thank you, Phillip. Yes, we have a moment for questions here. there's anyone in the crowd that has a question for Phillip.