Recent and Future Hardfolks: What Does this Mean for Validators and Users?

Hi. So, as has become a custom over the past years at Dapkon, I will be talking about GnosisChain and, well, hot forks and updates, basically. So, I always like to start a bit by talking about what GnosisChain actually is. Some of you still might not know. Actually, by show So, GnosisChain basically is the same as Ethereum, so it has a beacon chain, it has the same clients, it goes through the same hot forks, and it's also all about decentralization.

It also has a few differences, though. For example, it was based on Proof of Authority before the merge. It uses GNO as the taking token, which is the ESC20 token, and it has block times and finality. It also has a few less blocks per block. So, we have executioner clients, which are Nethermind, Eragon, Guess, and REST.

So, Nethermind basically, over the past year, did a lot of bug fixes and performance improvements, but they also developed this R1 file support, which basically means that you can now export and import data, so bodies, receipts, headers, everything from your nodes, and then import it back. That's important because soon, pre-merges will actually get dropped entirely from nodes and just the P2P network, so you won't be able to sync your nodes from scratch, basically, without importing error files. Eragon deployed its version 3, which comes with a built-in consensus layer automatically, so you only have to run Eragon by itself without Lighthouse or Tick or whatever, which is great for RPC providers, for example. Of course, you cannot validate just with that. And it also has static query, so basically the same as Nethermind.

Guess, I announced actually last year here at WebCon, is now stable. It is basically—well, it has feature parity with upstream Guess, and it also supports historical data for another chain, so the pre-merge stuff. And if you want some more information about Guess, I think Guillaume is actually giving a talk at StudioA tomorrow at 2.40, if I'm not mistaken. And then today, similarly as last year, I can announce that we also have REST now, which is a new client.

It doesn't support pre-merge headers or data at all. It doesn't support stuff, so there are a few caveats, but it is actually already testing, so you can run it on your validator if you want to. Quick word about client diversity. It's extremely important because if, well, a client has an issue, basically the whole network could go down. And right now on GnosisChain, almost or more than 80% actually of the validators are Nethermind, so that's not great in case Nethermind has an issue.

So please, if you are validating on GnosisChain and you're running something else, so you have three options now. You have, well, as mentioned, Guess, REST, and Eragon. We did a lot of work to, well, get those clients, please use them, and save the network by having client diversity. So this is the hotfork timeline that we did in the past. So we started hotforking, 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 hotforked two days before Ethereum, and now Pektra, which we did one week before Ethereum.

And then the next hotfork is supposed to be, well, it's going to be Fusaka, potentially end of this year or at the beginning of the next one. So what is Pektra? 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. So there's EIP-7002, which allows basically owners of validators to withdraw and exit validators directly.

So in the past, there were two keys, so the withdrawal credentials, which own the funds on-chain, and then an 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, 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 on your node operator anymore. So that's a bit better for validators. Then EIP-7251, which I would say is, well, the biggest one for Pektra. It aims to increase the maximum effective balance. What does this mean?

Basically, until Pektra, 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 consumes a lot of hardware in terms of memory, networking, CPU, everything, basically. So it's not great, and it's also kind of difficult to manage all those keys and to keep them safe. Then there's an additional issue that if you had, for example, 1.99 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 inefficiencies. Of course, for us, it's not that important because 1 GNO, all things considered, is not worth that much, which is by design for us to train. But for Ethereum, if you had, let's say, 40 ETH, you would have to wait until you had 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 consolidate multiple validators into one.

So imagine you have 100 keys. You can now just consolidate them into two validators with 50 GNO each. So it's much more efficient, much easier to handle. And as a general, 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 better for everyone if you consolidate.

And you can also now take any amount between one and 64 GNO on one single validator, and you will actually get compounding interest or yield on any of those amounts. So if you have 1.99 GNO, you can put those on one single validator, and you will get compounding rewards. So how does that work in practice? Basically, you have two options.

Well, you can keep the old behavior, so stay as it was before. In this case, while 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 once every few days or not just a couple of weeks, I think, on Ethereum. Or you can upgrade to become compounding, so the new post-Petra way of doing things, basically. And you get all the benefits I just talked about.

And again, this is the recommended 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 each-taker deposit CLI, which I'm actually also happy to announce now that it works for NoSysChain. So we have the same tools now for Ethereum. It just makes things easier.

You don't have to run something different for NoSysChain and for Ethereum. 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 a smart contract. But I mean, honestly, just use the easy way. We have a tool available for you here on consolidate.

nosyschain.com. It does have a few caveats. Namely, it only works if your withdrawal conventions are a safe wallet or 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, Sepolia, and you can use this for all your validating needs. 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. 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 not testing, so it's way more efficient. And on the second screen, you will see that 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 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, what it does basically is to allow you to set an account code on an EOA. So basically, each address now becomes a smart wallet, or you can make a smart wallet out of it. So the pros, of course, are that you can execute arbitrary codes on your EOA. For example, you can do batch requests.

So we all know this flow about doing approved plus transfer for tokens in two different directions. 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. Well, the support is not great yet. It's potentially dangerous, and it's kind of gate-kept by wallets. But that's kind of by design for your own security, because this actually, well, is dangerous in the sense that it makes it possible to lose all your assets, tokens, native tokens, everything NFTs, in one single transaction. So you have to be very careful about what you do with this.

So we just talked about Pektra, and I want to talk a bit about how it actually works, how we execute them. And of course, there's a lot of preparation. So we have a lot of automated tools for this, for testing. For example, HiveTest, EFTs, or Ethereum Sash Sash, I mean, a lot of repositories to do automatic testing. And then you have DevNet, which are spun up by the DevOps or Codef teams.

For example, for Ethereum, it's mainly Etana apps. And those generally start on the hard fork before, so the one that is not being developed. For example, DenQuent in this case. And then, for example, one day later, you do the hard fork transition to Pektra, so you can test that everything still works. And afterwards, you can of course test that all the features are still, well, functioning.

So usually there's between five and ten of those DevNets. For Fusaka, for example, the first two already were deployed. And, well, this allows teams to make sure that everything works together with all the clients. And, yeah. And the feature sets are always, well, usually different, because during the development period, of course, features get added, new features get added to the hard fork or get changed.

So DevNets usually have different configs and are used during development. And then we have testnets. Well, networks usually have a testnet 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 dev 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 Aave or Uniswap or NoSysPay or whatever the case may be. But it's also useful for the hard fork, because it's the last step, basically, before hard forking to mainnets. And then we can make sure that everything still works, because usually they are fairly close to, well, mainnets. So how did this go for Pektora? It didn't go very well.

The first two networks to hard fork were Cepolya and Torecki. Both failed in different ways. Cepolya was recovered very quickly, so that's all good. But Torecki took way longer, weeks, actually. And after that, Shiado, which is a NoSystem testnet, actually hard forked and was the first one to successfully hard fork from the get-go.

Although, to be fair, it would have had the same issue as Cepolya, so we kind of got saved by the US in this case. And then a third network that didn't exist before, Hoodie, was created, well, just so that we could make sure, basically, that the hard fork would go through on an actual testnet before going to mainnets. And this also delayed Ethereum mainnets, because rollout teams needed to have 30 days between the last testnet and mainnets to make sure that they have enough time to test everything. So, yeah, this was basically the hard fork timeline. So Holeskin, Cepolya forked first, and then Shiado one day after Cepolya.

Then Hoodie was created out of nothing, so it took a bit longer, and 20 days after Shiado, Hoodie hard forked. And then we have NoSystem chain, so mainnets on April 30, and Ethereum mainnets on May 7. So, what did this mean for developers? It was not great, because a lot of developers relied on Holeskin to, well, test their applications and test their variability. But their network was bound, so developers had to basically deploy to another network, so spin up the 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 NoSystem 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 Petra, one week of testing on a post-fork network. And you can basically, well, it is very cheap. As a matter of fact, if you have an interesting project to deploy, just hit me up, and we will pay for it, yes. So what did we learn from this?

Communication is always difficult. For example, Hoodie was just, well, messed up, because client teams basically didn't use the same configurations. And this really shouldn't happen anymore at this stage on a production network. So yeah, testing is, of course, always extremely important. And then there's some EIPs that don't necessarily generalize too well.

For example, the issue that Sepolia had is that one EIP basically assumed that there was only one event in the deposit contract, which was the case for Ethereum mainnet, but wasn't for Sepolia. And also isn't for Notch and Chain and Shiado. 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 worth it to do it from the get-go. And that's also the fix that was done later on to fix Sepolia and our networks as well. So yeah, just filtering the events could have saved a lot of time in this case.

So we have to be very careful about, yeah, generalizing EIPs basically. And as for Notch's, to make sure that EIPs we integrate actually fit, because our network diverges from Ethereum a bit. All right, so moving on to Fusaka, which is the next fork. This is a 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.

But if you want to learn more about scaling the layer 1, there's a talk from Tony Washtutter from DF tomorrow, Studio A at 2.15 if I'm not mistaken. So yeah, that's it for me. Thanks for listening. And if you have any questions, please go ahead.

Thank you, Philipp. Yes, we have a moment for questions here. Is there anyone in the crowd that has a question for Philipp?