Key Points Discussed

• Diego introduced Geth Classic: a new ETC client built as a minimal proof-of-work fork of upstream go-ethereum, pitched as core-geth’s maintainable successor.
• It ships an auto-generated documentation wiki that traces every change back to the exact upstream PRs and diffs.
• A one-way core-geth to Geth Classic database migration is being tested, and the same fork pattern could be reused by other proof-of-work chains.
• Client diversity was called critical to network stability, citing the Spurious Dragon / Shanghai incident as a real save.
• Governance: each client under its own org, with no anointed “correct client” — list the forks and let users decide.

Full AI Summary and Transcript ↓

Preamble

Hello, and Welcome!

This community call is an open voice chat discussion about Ethereum Classic. Everyone is welcome.

The call will be published on YouTube. We kindly ask that discussion stays focused on ideas rather than individuals. Let’s keep it classy.

Find past episodes, transcripts, subscribe to calendar, and more at https://cc.ethereumclassic.org.

New this episode: a fresh video format with chapter markers and cleaned-up captions. If you are watching on YouTube, it should look a lot nicer.

Introductions

Quick round of introductions for everyone on the call, and if there’s anything you want to talk about.

AI Summary

This call was a deep, one-on-one technical session between Istora and Diego on Geth Classic, a new Ethereum Classic client, followed by a wider discussion of client diversity and governance. The planned agenda topics (value accrual, futarchy, the Fifthening, side events) were not reached and roll forward to a future call.

Building Geth Classic from Upstream go-ethereum

The call opened on the work Diego has been doing to derive an ETC client from a modern upstream Ethereum client.

• Details
  • Diego: Geth Classic is not core-geth; it is a fresh fork of upstream go-ethereum with a deliberately small set of commits (around nine) layered on top of a chosen release
  • Diego: The commits re-add proof-of-work support and ETC specifics, the monetary policy and all the hard-fork activation blocks, with core-geth used as the battle-tested source of truth to avoid diverging from known-correct behaviour
  • Diego: The proof-of-work code that go-ethereum deleted after the Merge will not compile against the modern architecture, so it had to be revived and re-applied rather than copied verbatim
  • Diego: ETC-specific concepts are kept in separate sibling files, touching the minimum of upstream code, so each new go-ethereum release can be rebased by re-applying the same small commit set (the latest base was 1.17.4)
  • Diego: The aim is a maintainable, least-intrusive design that keeps the work auditable by an external participant
• Conclusion
  • Geth Classic is positioned as a next-generation, easier-to-maintain successor to core-geth, structured so it tracks upstream releases with minimal ongoing effort

The Auto-Generated Documentation Wiki

A large part of the session was a walkthrough of the documentation system Diego built alongside the client.

• Details
  • Diego: The wiki is generated deterministically from YAML descriptors tied to the codebase, so it cannot drift from the actual changes and removes human error from tracking what was modified
  • Diego: It organises the work as recipes (“where to look if you want X”) and shows, per change, what comes from upstream versus the revived proof-of-work code, with an origin column linking back to the exact PRs and diffs
  • Diego: As a worked example, removing then re-adding the eth/68 wire protocol traces back to the upstream PR (around 9 files modified, 5 new files added), with the reverted lines relocated into isolated files for maintainability
  • Diego: The generated view gives traceability across releases, for example comparing 1.17.3 to 1.17.4, and he has spent roughly three months on the client and the wiki
  • Istora: Noted the documentation is generated from the codebase itself, eliminating human error over which lines are included, and that the repo currently has a single star (his)
• Conclusion
  • The wiki doubles as an audit trail and an onboarding reference, and is valuable in its own right for anyone trying to implement ETC support in another client

Database Migration and Reuse by Other Chains

The discussion turned to operator migration and whether the approach generalises.

• Details
  • Diego: A core-geth to Geth Classic database migration is being tested and looks possible because the schemas are similar, but it is one-way (no downgrade) and experimental, so operators should back up first
  • Diego: The benefit is that existing core-geth operators could download Geth Classic and keep running on top of the data they already have
  • Diego: The upstream go-ethereum team does not maintain proof-of-work for other chains, but the fork pattern could be reused by other proof-of-work / EVM chains (he cited Binance’s go-ethereum fork as a project that lacks a scalable upgrade architecture)
  • Diego: For a different-language client such as a Rust reth port, the specific code does not transfer, but the general strategy (minimal commits, generated docs, disciplined upstream tracking) does; the right techniques depend on the language’s extension points
• Conclusion
  • Migration is plausible and low-friction in principle; the transferable asset is the methodology more than the code

Promoting Geth Classic and the Future of core-geth

Istora and Diego discussed where the new client goes next.

• Details
  • Diego: He wants to move Geth Classic into its own GitHub organization, promote it, and grow testing, ideally including miners
  • Diego: Over time core-geth could be sunset in favour of Geth Classic, citing faster updates, easier maintenance, and better performance
  • Diego: Nethermind remains an excellent, proven client with a small, isolated ETC footprint that is worth maintaining and keeping up to date
  • Diego: He would not force anyone to migrate; he would keep maintaining core-geth and let operators move when they see the value
  • Istora: Raised whether ETC should intentionally stop maintaining the older client to push migration, and both agreed that would be reckless while operators still depend on it
• Conclusion
  • The direction is to promote Geth Classic and let adoption happen organically, with core-geth maintained until migration is genuinely low-risk

Why Client Diversity Matters

Istora asked Diego to make the case for multiple clients on the network.

• Details
  • Diego: A single majority client is a systemic risk, both for consensus bugs and for unspecified behaviours that exist only in one implementation
  • Diego: With miners spread across multiple clients, a bug in one client does not stop the chain, because the others keep the network moving
  • Istora: Cited the Spurious Dragon / Shanghai-era incident as a real precedent where only one client survived an issue and the network was saved because a minority ran different code
  • Istora: Argued developers should proactively reach out to node operators to run minority clients, which is in the operators’ own selfish interest (resilience) as well as the network’s health
  • Diego: More clients also reach more developer communities (including other language ecosystems), bringing different perspectives
• Conclusion
  • Client diversity is treated as essential to network stability, and a second well-maintained Go client materially improves ETC’s resilience

Organizations, Sunsetting, and User Choice

The call closed on governance and who should decide which client people run.

• Details
  • Diego: Each client should live under its own organization, the way Ethereum runs with Besu, Nethermind, and Geth each under their own orgs
  • Istora: Today ETC Labs Core maintains core-geth and it happens to be the client everyone uses, but no central body should anoint “the correct client”, because that removes a choice users should be making themselves
  • Diego: It is not a problem to have many clients, even forks of the same client; the user should decide which to use
  • Both: The aim is to list as many reasonable forks as possible and let users and miners decide, which both framed as the long-standing ETC approach worth preserving
• Conclusion
  • The shared position is maximal, transparent choice: surface the options, keep them under independent organizations, and let the community pick rather than having a maintainer pick for them

Action Items

• Diego: Move Geth Classic into its own GitHub organization and promote it for wider testing, including by miners
• Diego: Continue testing the core-geth to Geth Classic database migration and document the one-way, back-up-first caveats for operators
• Diego: Keep maintaining core-geth and the EIP-bundle branch for the next network upgrade, pending agreement on the shortlist
• Istora: Help promote the Geth Classic repo and its documentation wiki (currently one star)
• Community / node operators: Consider running a minority client for network resilience; developers to reach out to specific operators
• All: Next call is in two weeks; join the green room an hour early to beta-test Istora’s app, NourishMint, for on-chain rewards on ETC

Full Transcript

0:03Welcome and intros

0:03IstoraHello, and welcome to Ethereum Classic Community Call number 55. Today is Friday, June 26, 2026. Ethereum Classic Community Call is an open voice chat discussion about Ethereum Classic, and everyone's welcome. The call will be published on YouTube. We kindly ask that discussion stays focused on ideas rather than individuals, and let's keep it classy. You can find past episodes, transcripts, subscribe to the calendar, and more at cc.ethereumclassic.org. In this episode, if you're watching on YouTube, you should see a new video format, which we've been working on this week, to include the transcription and visualization instead of just a black screen in the last episodes. So I apologize for that, that was a Zoom… meeting… quirk, which we're now passing to a video transcoding pipeline, so hopefully you get a better experience if you're watching on YouTube from now on. We have us on the call today, Diego. How's it going, Diego? Good to see you again. 1:07DiegoYeah, hi, Sora. How are you? 1:10IstoraI'm doing good now, recovering from jet lag from the last call. It was good to see in Europe. 1:18DiegoYeah, yeah, good times. 1:20IstoraAnd now we're back with the latency once again. 1:25DiegoYeah. 1:27IstoraSo today, let's talk about, to kick things off with, the work that you've been doing on core-geth. Because I think this is super interesting, and it's a really useful approach. how to… basically derive an Ethereum Classic client from an upstream version of Ethereum. So maybe you can talk more about your approach and, how we could… Yeah, get more… useful information, not just for core-geth, but potentially other clients as well.

2:08Building an ETC client from upstream Geth

2:08DiegoYeah, absolutely. So… yes. Well, I wouldn't say it's exactly core-geth. I mean, what I… what I'd done was, like, starting… like, a new fork from go-ethereum, and trying to take all the experience gathered from core-geth into this new… like, client, or the new fork of go-ethereum. So… My main goal there was to create what could be, like, the next generation version of core-geth. With the same… Goals, but, with a different approach on how we could tackle maintainability for the future. So, my idea there was to… To, initially, like, fork. go-ethereum since, one of their releases, and then add like, a limited amount of… of commits on top of that release. To add support for, well, proof-of-work, and particularly for Ethereum Classic. So the idea with that approach will be to… to be able to apply that limited set of commits on top of every new release. The idea of those commits was to keep those as separate as possible from the upstream. So, like, touching the minimum parts. necessary to extend… go-ethereum functionality. So, the goal with that is that, with, like, future applications of these commits, the conflict should be minimal or quite simple to… to solve. Because, basically, the idea will be to just… to put the… the if statements necessary to enable, like, the proof-of-work behavior, or adding certain particular parts on the database, and, like, trying to keep it, like, at the… at the minimum. Like, to be the least intrusive as possible from the upstream code. So, that was my main goal there. And also, I… what I… what I use as a base for… for what I wanted to… this to be was, like, in part, trying to… Bring back to life all those pull requests. from go-ethereum that removed the proof-of-work. Flat, yeah, code. And also, using core-geth as, like, the source of truth, because nowadays, core-geth, we know it works, and it's battle-tested, and I didn't want to diverge from any of those. I mean, I didn't want to diverge from the original… code for… for proof-of-work in go-ethereum, but I didn't want to diverge so much from core-geth either. So… what I did was, as I told. So, I started from one of the releases, I started to bring back to life the code for proof-of-work, I also added the particularities of Ethereum Classic, like, for example, with the monetary policy, and of course, all the activation blocks and all that. So I took that from core-geth, of course. And I was able to come up with, I think, like, 9 commits? which, part of them, like, re-add the proof-of-work parts, there's some other that will add all the things that are particular for Ethereum Classic, like the configuration itself of the hard forks. adding some testing, and… and all that. So… That will be one part of it. But also, I wanted to be sure that what I did will be a… will be simple to… audit from an external participant. So, what I did for that was to create, like, a wiki page, or some sort of documentation that would allow anyone to check what I did there, so… The idea there is that you could see, like, some sort of three-way commit merge. So, you will see… Like, the final code? What comes from the upstream, and what comes from… from the original… like, the original code for proof-of-work. Because… as you can imagine, the code that exactly existed at the time that it was deleted from the repo, will not compile anymore because, I mean, there have been many changes on the architecture and, like, different stuff from the upstream. So I had to take that removed code and adapted to… to the new… to the new architecture of the modern go-ethereum. So, the idea with that wiki page that I think you could link it into the show notes, is to… to have something, like, it's readable for anyone that could have some understanding on… on go-ethereum, or maybe, like, just any client experience. I think it's quite simple to follow. It's like, basically it's all these… idea that I had for… for… For how this should work, and… And yeah, and expose it into… into a wiki page. And quite recently, I put it into a test, because I think 3 days ago, there was a new release of go-ethereum. And I was able to basically apply these very same principles. to this new release. So I took what I had for the version 1.17.3, I… I applied. Those permits on top of the new one, which is 117.4. And I will not say those apply directly, but the conflicts were so minimal and really simple to fix. And that really allowed me to… to keep track of the actual changes… changes between both versions, so I think… I think this… This new approach is… it seems to be working quite well. Yeah, some… well, that's… that's the overall story behind Geth Classic, or whatever name we came up with in the future. Something else that I've been working on, besides like. tweaking the wiki page and all this, and making this, like, more… palatable for… for an external user, is that I also… I'm trying to make Geth Classic compatible with core-geth databases. So the idea will be that any user that has been using core-geth could simply download this Geth Classic version, and… And start running this new version on top of what you already had. for core-geth. So, that will allow, in the future, if we decide to, I don't know, to… promote… going from Classic to, I don't know, some other level or something, like, it will be more production-ready. The migration should be quite simple and straightforward. So, yeah, I don't know. I hope I'm being clear? 10:16IstoraYeah, no, that's great, and I think this… this approach is… really beneficial for a number of reasons. Like, obviously, having the ability to quickly update to new versions of go-ethereum is gonna be making it so that things like security patches are more quickly applied, because they don't need to be translated into this older format. If I understand correctly. And on top of that, like, having this… playbook approach. Is something that could potentially be used for other clients as well. So, especially with agentic approaches, you could potentially use this as a kind of, like, recipe for how to convert any existing Ethereum client into an ETC client. Is that reasonable to infer? 11:17DiegoYes, I think that… Yeah, that could be applied. Honestly, if we are thinking about new clients, I'm not sure if… I will… maintain another fork for another client. I think that we can do this for… for go-ethereum because of the history behind go-ethereum, and because, I don't know, many people that might be used to something around go-ethereum, or, I don't know, they feel comfortable and secure using that environment, and that's okay. But for other clients, thankfully, Nethermind is way, way friendlier for… I think plugins or any other plugin system is the way to go. So this approach I took could be applied for… new forks. I think it might be a lot of work. Yeah. For just another plan. But yeah, it's up to the maintainer. If they want to do it, up to them. They can use it, and I could help anyone to run the same thing. But, particularly for Ethereum Classic, I think, yeah, it might be a bit too much. But yeah, it's up to the person that might take care of it. 12:45IstoraAt the very least, it's an extremely useful reference for people that are trying to implement ETC, because they can see exactly how it differs. And not just from a git diff, but with detailed rationale. So, should we jump into one of these categories that you've got with code changes, and… let's step through exactly what people that are looking at this wiki would be able to understand from these pages.

13:19The auto-generated documentation wiki

13:19DiegoYes, well, it's basically… so, my idea was to… to organize this wiki page in… in the very same way an auditor could want to tackle. An analysis, for this new repository. So, in the first page, you will find, like, some sort of recipes, so it's where to look if you want to, I don't know, understand how the fork was structured. So, there is a page for the fork architecture, which is basically… so my idea was to… to keep… Old it, dim… The code that was brought back to life. into separate Files, because the idea with those files will be that there should not be conflicts in the future, because those files will not be part of the upstream anymore. So, you will find, like, a lot of underscore, O, go, or you may find some, like, underscore etc.go, or some other for the mess artificial finality. Because I also try to keep that. Even if it's disabled, I think that there are people that still feel comfortable. with the existence of mess within the code, even if it is disabled, so I try to keep it into… into this new version. But also, I try to… to keep it, like, separated as… as… The rest of the integration. So, that's the main idea. So, you will find, like, sibling files. with POW or ETC concepts, and, like, minimal integrations within the upstream code with if statements and… and that. I see. So… So, yeah, you will find, like, the fork… the fork, architecture, which is… which is basically what I… I already described. Also, you will find here all the sources I used for all this, code that was brought back to life, so I have the reference to every PR that basically removed the proof-of-work code from go-ethereum, so you can also use as a basis for, I don't know, anything you can… you can dig in, because, I mean, within those pull requests, there's a lot of history, and there are a lot of questions, and there are a lot of decisions that have been made. for those removals, and I think that's part of… of a history that is important to keep. So… anyone is interested into checking this, I mean, there's also references into this wiki, so I think there are, like.

16:08Worked example: reverting the eth/68 removal

16:08IstoraCould we jump into one of those? 16:09Diego10. Yes, absolutely. So, I don't know if you're… Seeing this, but basically it's in the upstream porches. Yep. So, they are, like. 10 so far, that I've been, like, looking at, the… well, one of the latest ones, I think it's for, kind of, sample the removal, of… eth/68. If I recall correctly… Exactly. 16:40IstoraIf I go to… 16:42DiegoYeah. So, yeah, like, for example, this is, I would say, quite recently, quite recent, But, yeah, for example, I mean, you will see, if you open, it's the PR33835. Yeah. Let me check if this is exactly the one I'm referring to. I have to read it real quick. No, this is not the one that… Number two. Yeah, no, I'm sorry, the one removing 68 was 33511. So, basically, you will see in that pull request all the rationale about removing it, why they did this, and… Yeah, I think this particular one was a really clean one. Because they just removed a few… A few files, which are the support for this. This protocol version, but it was quite simple to… to bring it back to life into, like, new files. So… what else? So we have the… 17:57IstoraIn this context, you would be… you're basically just reverting this PR. 18:05DiegoYes, that will be the… that will be, like, the first step. So, once you revert that PR, nothing will compile, probably, because everything has changed… have changed, with the new architecture. So, the next step will be, how could we… how… how could we… make it compile and work with the current architecture of, go-ethereum. That was, like, the main problem and the main challenge of, like. like, seaming… I mean, tied it all, again, together. So… yes. And also, exactly, it's not exactly… A revert. Because the revert will have touched the files in Upstream, and my idea was to… that I wanted that code to be part of new files. But, what I did with this wiki was to… define… So… what I did was to, as you said, I mean, it was some sort of a revert, but not exactly a Git revert operation. So, it was taking the same lines within that pull request, and put it into some other files. And link it in… in… within the, the upstream using if statements. So… So yes, what I did in this way was to reference the lines… from this PR that were, like, quote, reverted, unquote, But… like, pointing to the actual destination within Geth Classic. So, in that way, you will get the best from both worlds. I mean, you will see exactly the diff coming from the PR, but you will see it in the context that it's, like, more suitable for maintainability for the future, in the context of Geth Classic. So that's the… the whole… Yeah, way to tackle all this, all this equation. 20:18IstoraSo this, this purge, this Purge eth/68, can then be traced through to the eth protocol. subsystem. And there, you have this origin column that refers back to the exact PR that you're… Exactly. reverting. And then you have this view that you can look at the exact source code change. The diff. 20:43DiegoAnd actually, if we concentrate into this one. As an example, there is a page for ETH protocol, And you will see there. Like, if you open that page, it… it says, on the top, the eth/68 wire protocol, message type, blah blah blah, and you have a table on top of it, and it says what was revived from… from the upstream. So there were 20… 26 files. So, I had to modify 9 files from the upstream, and I had to add, Like, 5 new… new files for taking care of this. And down below, you will see the list of all the… all the files and… and methods that were… Had to be modified, or… yeah, to… to make it all work. And you will see there the diff count. So, for example, there are, like, a lot of, like, adding one line and removing one line, that's probably a change into… It changed into some signature or so, so… yes, I mean, you will see all there. So it's all there. So yeah, that's a lot of information, and it's… I mean… It's not that simple to process, but it's something that a human could do, and that's the important thing, I think. The important thing, I think, because, I mean, we can do many of those things for using agents, but the idea is that someone could be able to check everything that the agent made, so… so yeah, I think that's the simplest way to… To put this. So you can keep track of every change here. You will see… What's the origin of every… Function on all that, and every… all of that is traceable on the… on these pages. So, yeah, I think it's good material. I've been using it, basically, for… for checking that everything is what I wanted it to be. Not only by using the tests and all that, but checking the code itself. 23:01IstoraAnd the other aspect of this is that the wiki page is generated deterministically, and links to… 23:12DiegoYes. 23:13Istorathe changes that you've made in the codebase itself. So it's like a… it's a documentation-generated. 23:19DiegoYes, yes, exactly. Yes, it's auto-generated by using descriptors that are in YAML files, but the structure of those YAML files is basically, okay, you will have, like, this file, and this method within that file will map into this other file coming from, I don't know, this PR that removed that particular behavior. So, in those descriptors, you will have all the information, and there is a post-processor of those descriptors, and that will come up with this wiki page. Yes. 24:01IstoraAnd that is kind of eliminating any human error potential in terms of which lines are included? 24:10DiegoYes. Yes, completely. Yes, and also it's good for having… It will allow you to have traceability, between releases. Because you will be able to compare also what have changed from, like, the release 17.3 to the 17.4. So having those descriptions is also helpful for that. So, yes, it's, yeah, yeah, I think it's, yeah, I'm pretty happy with this. I'm… Yes, this has been evolving. I mean, initially, I used this only for the proof-of-work part of all this work. But then I realized that it will be important for having… having the same, like, mechanisms for the rest of the code, and I think at this moment, I think pretty much. I think most of the code is covered by one of the pages, so yeah, I think it's, yeah, it's a good thing. It's a lot of information, but I think it's something that, like, an auditor or anyone interested into this could… With enough time and dedication, could understand. And hopefully find something that's not good, and… fill out some pull requests, yeah, pull requests, or at least an issue, and I could take a look at it. 25:38IstoraI see. Cool. And, like, how long have you been working on this in the background? 25:44DiegoOof, for… I will say, at least. I don't know, 3 months, probably? Yeah. Yeah, I think it's around that time. Quite recently, the biggest change, I think, I made for the… for this version was, this… some sort of migration from… core-geth into the new database system, so I wanted it to be transparent. But yeah, I don't want to… 26:22IstoraSorry, please go ahead. I cut you off there. 26:24DiegoNo, no, I was only going to say that, yeah, besides that, I also reworked all this wiki quite recently. So yeah.

26:35Database migration and reuse by other chains

26:35IstoraCool. I was gonna ask how the database migration is… going? Like, what's the status of that? And what are the challenges? And do you think it's feasible to… Have some kind of upgrade mechanism for people that are currently using. core-geth to switch to Geth Classic. As it may be known. 26:59DiegoYes. Yes, yes, it is possible. I… yes, I mean, I'm testing it right now, but I think it's possible. Both schemas are quite similar. The thing is that it will be irreversible. So, once you start going with your Classic on top of your former core-geth database. you will be able to continue using Geth Classic, but you cannot go back. So, because, I mean, it will change part of the internal, structure, like, because basically, the… the current. schema for… of… of go-ethereum have changed. So… Yeah, it's, like, you're upgrading to a new version, and it's not… it's not simple to downgrade it. to a previous one. So, basically, that's why… this works this way. But, yeah, it's… 28:04IstoraCould you maybe do, like, a… could you maybe do, like, a snapshot or a backup of the old… structure of the database? Yeah. And then… 28:13DiegoFallback or something. Yeah, yeah, I mean, that's part of the administration, if they want to be on the safe side, yes, it's something that is… Yes, it's a good recommendation. I mean, just keep it backed up, just… shall be caused before. And… yes, and then try this. It's quite new, it's quite experimental. This new feature is something that I'm working on. Maybe thinking in the future, I mean, in some future where this, as I said, I mean… This may turn into something, like, really production-ready, and people are happy with this, the way we are doing things with this new version. It should be, like, an easier way for users to move to another compatible client… Updated version of the same client. 29:09IstoraInteresting. And… the… I'm just trying to think out loud here, but what you've got is essentially a vector of changes from the upstream version. Would it be possible to somehow package those changes in a standalone way, where you just apply them again. I mean, that's essentially what a fork is, but could it be somehow turned into a plugin of some sort that makes it easy to apply? 29:41DiegoNo, no, I don't think so, because… I mean, the go-ethereum team never… care about. Other chains, or anything like that, so they… they didn't care about putting, like, the proper extension points, so that's why… it's not that simple. I mean, hopefully that will be incredible, but, yes, it's not the main goal of the go-ethereum team, so… They will only be focused on… on Ethereum, so… yes, so that's what we have to deal with. So that's why I wanted to keep it, like, as small as possible. I think nowadays, we are in a better shape for doing this than in the past, probably, because in the past, there were… there was a lot more code that was part of the upstream, there would be, like, many more conflicts. Now that the code is basically removed from the upstream, if we add it into our own fork, of course, I mean, there will not be changes to those codes anymore, because they don't have it, so… It's much, much simpler nowadays to keep up with a new fork like this one. So, yeah, you're… you're in on doing this work. 31:03IstoraThere may be… like many other EVM chains that are trying to use Geth. So, like, they face the same challenges as ETC, I assume. So maybe there's… 31:17DiegoYeah. 31:17IstoraThis kind of approach is useful to other chains as well. 31:22DiegoYes, that would be awesome. And basically, one of my goals with this was to keep the ETC and the proof-of-work changes, kind of trying to keep it separate. So, I mean, ideally, any other proof-of-work chain could take this very same work and add their own, like. forks, definitions. So it should not be that much more work than… than what I did. So they could fork this fork, and just add their own. yeah, upgrades, for example, if they wanted. That should be quite simple. to do. So yes, it's, hopefully it might be a pattern that someone else could follow. I don't know, like, for example, I think the Binance chain, they also work on top of a go-ethereum… Go with your fork. But, yeah, I don't know what type of architecture they follow. I think they have, like, a really old version of go-ethereum, and… Yes, basically they were facing the same challenges that the current core-geth faces. So, probably, yeah, they haven't… they don't have, like, a really scalable architecture for upgrades, most likely. 32:51IstoraI see. And would you, let's say there's someone… trying to… essentially create an Ethereum Classic fork of one of the other clients. Let's say RETH, for example, the Rust. client. And they wanted to make… Retz… RETSE. Could they use this in some way to help them? And could you maybe give some… direction as to what the best approach that might be for… other clients. other codebases. 33:27DiegoYeah. Well, it probably will depend… well, it depends, I think, on the language and the capabilities that every framework will provide for extensions. So… maybe, I don't know, too much about Rust, but they may have, like, better extension points, or something, it might be simpler, because, like, for example, you don't have inheritance in Go. So, that makes things a bit more difficult to extend if you are… if you have not planned your code for extension since the beginning, for example. And I think that maybe in some other languages, like Rust, that might be simpler. So… I think, I mean, overall, I think the… The idea of creating a fork with, like, thinking on reducing the conflicts for the future is, like, a good… Criteria to take any time that you are making a fork of, like, a big client, or probably any other software. They have it in mind that you are a fork. And that you want to keep track of upstream all the time. think about every change that you make into the upstream code will be a potential conflict in the future. So I think that's something that will be really important for any new fork, probably for anything, but particularly for clients. So, in that sense, yes, all this experience is something that can be exported to some other clients. But, particularly the techniques I use for… for Geth Classic, I'm not quite sure, I don't think so. I mean, besides some, like, general, I don't know, strategy pattern, or many other, like, different patterns that could help you at an architectural level. for the language itself, I mean, every language could provide… could give you, like, different benefits for… for adding this sort of extensions, so… Yeah. 35:39IstoraRight, right. So it's not, like, literal… Code changes, it's more just the general approach. 35:47DiegoYeah, I think so. 35:50IstoraCool. Yeah, I think this documentation site would be great to promote a bit more, have more eyes on it. It's currently got zero stars. It's now got one star, I should say. 36:06DiegoYeah. 36:08IstoraSo… 36:08DiegoOkay, cool. 36:10IstoraI'm the first person to star this repository, and hopefully others will… star as well. How do you see this project, however it is named in the future, being part of the overall client landscape in ETC? Does it live alongside core-geth? Will it eventually replace it? And… Do you think that… there's a need for two Go clients. At all. Or should be. Like, yeah, refocus on having one. 36:47DiegoYeah, the first thing I would want to do with this is to promote it into its own organization, because right now it's under my user, my own user. it would be better to have it in, like, in a more mutual place. But, I mean, so far, it's, yeah, it's there, and… Having something public, it's… it's better to not have anything, so… So yes, probably in the not-so-distant future, this should go into its own organization. But besides that. with regard to core-geth, I think it will be positive if we can start using this client more, and… Yes, and eventually thinking about replacing core-geth with something like this. I think it's… yeah, it's… it is better for the future of the client landscape. If it were me, my preferred client is still, the Nethermind Plagin. Because, I mean, it's, well, Nethermind is awesome, it has been proved, like, it's, like, it's a great, great platform, not only for development, but also for running. All the optimizations that they made for making it run, like, extremely… in an extremely efficient way are awesome. So, that's great, and also the footprint for Ethereum Classic, it's, like, really small and isolated, and it's its own plugin, and it works perfectly. But, that being said, I still understand that people may want to run… I mean, mostly, like, people are running… I mean, there are a lot of, probably system administration that they have their own scripts, and many things that are based on the existence of something compatible with go-ethereum, and I will understand. So, I think in… for those people, I think the existence of Geth Classic, it's… it's good and important. And I wanna… that's why I think it's important to maintain it, and to keep it up to date with the upstream. So in a, yeah, not-so-probably distant future, if we can get all together and be all convinced that this is a good path forward. Hopefully, more people will test this. And at some point, probably miners who will start like, moving part of their operations into this new client, and start testing it aside from core-geth. And eventually, yes, I mean, we could sunset core-geth and start using this one. That would be great. Very, very great. 39:39IstoraYeah, and it's… like, the primary benefit is… Faster updates, I guess, easier to maintain. And… 39:49DiegoYes, and also the performance is better, I could say. I mean, that's something… that's also something that came from upgrading the… yeah, the overall architecture and all the optimization categories the team made, but, yes, it's… Yes, the memory consumption is lower, and yes, there are a lot of… Of optimization, that makes sense to also, yeah, for… yeah, for upgrading. 40:21IstoraCool. Well, yeah, it's amazing to have more options, and this does seem like, like, a really good option for the future, especially if people want to continue with Geth, or that world. It will be interesting how… the network… ETC as a whole. Evolves over time, and ideally in a way that multiple clients are used, like, with the diversity push. Such that, I mean, maybe you could say a word, actually, as to why and how important it is to have this diversity, because right now, we're not super diverse. And… The benefits that are provided by having multiple clients, especially in terms of like, going through hard forks if they're necessary. To ensure the stability of the network.

41:21Why client diversity matters

41:21DiegoYes, well, yeah, as you say, I mean, I think it's crucial for the stability of the network, one of the… the decisions that were made early in the Ethereum days is that we will be having, like, multiple clients, and that we will have, like, really good specifications, and the clients will be an expression of that specification, and the problem by having a single majority client is that you are in risk of turning the code into a specification, because if you have a single client and you have a bug into the consensus of that client. Any other client for the future will have to implement that patch, and that will… that might have been something that will have come out from the… I mean, not existing in the specifications, so that's one of the… I mean. One of the main… problems of having a single client, single majority client. That's something that actually happened to Bitcoin. They had some behaviors that were only present in the client and not specified anywhere. And those things are quite delicate. And… so that's on the… on the, on the more, like, the protocol, or… or the bureaucratic side. on the side of the network health itself, I think it's also important… well, basically because of the same thing. I mean, if you have, like. more clients, you will have… Miners mining into different… clients, and you will… have, like, a… Let's say, like, the majority will be… So the idea will be, like. bundling it into a single client will not change the whole blockchain, basically. If you have, like, let's say, a third of the hashing power, into, like, 3 different clients. There will be no problem if one of the clients have a bug, for example, because the other two that will be a majority will still keep leading the blockchain forward? So, I think in that sense, it's also really important. Right, right. Yes, and also for chasing bugs, and yeah. 43:50Istorajust to put this into, like, a real-world example, this happened before with Spurious Dragon, right? With the. Shanghai fix, where it was only one of the clients that was able to survive, and the network survived as a whole, because one of the clients did not have this denial-of-service bug. So… Right now, with ETC existing with one client, if there is that kind of denial of service bug, the whole network goes down. But if a… even… even a minority of nodes are running a different client that don't have the same bug, then the network survives. So it's really important. 44:26DiegoYes. 44:26IstoraThere's at least a significant minority running Yeah. Another node. 44:33DiegoYes, yes, you're right. I was only thinking about consensus bugs, but yes, in this case, it was crucial to have another one, yes, keeping running the… yeah, the blockchain. 44:44IstoraYeah, and I think we can, like, from the developer's side, I think it's important we… We try to make it clear to people that are operating nodes that it's in their interest as well. Like, there is a bit of a kind of, There's a game theory problem in terms of free-rider problem, I guess, where if you're the only person running a different node, then you're taking on additional risk. But if a certain majority run it, then that risk is reduced. So it's like, how do we reach that equilibrium point where enough people are running a different client? And that might be a case of, like, getting in touch with specific… node operators that are running a large number of nodes, potentially ETCMC, or mining pools, such that they are… Understanding the importance of having this diversity, and… Yeah. If they're intentionally running 2 or 3 versions of the node, then they can actually increase the security of their own infrastructure. For selfish reasons, not just to make the network as a whole more healthy, but because it's actually in their own interest. 46:01DiegoYeah. Yeah, absolutely. Yes, I think it's, yeah, it's, it's really good, and also, even if in the case that there will be a new majority client. I think it's better to have more options. For… yeah, for anyone, for developers. And also, this will allow us to… Reach, like, more developers for different environments, we now have, like, for people from… coming from the .NET world, from people coming from the Go world. Also for the Java world, so I think it's important to have, like, different voices, different opinions, Yeah, the more the better, I think, for developers, so…

46:52Organizations, sunsetting, and user choice

46:52IstoraIt seems like an increasingly pertinent question, given that core-geth is kind of becoming… I mean, it's the main client, but it's something that might not be the main client for a long time, and, like, in the next few years, now might be a good opportunity to… encourage everyone to switch to a new client, and give them the opportunity to decide which client that is, and also encourage them to pick different clients. So… if… if… It… yeah, we… I don't know if… 47:26DiegoIt will take time. 47:28IstoraYeah, yeah, it's a long process, but, like, is it… should we intentionally not maintain the old version of core-geth, and instead just have this one option for a Geth client, and also encourage the other options? Or should we… you know, maintain that big… because people are… Node operators are likely just gonna go with the easy path, and if that just means updating core-geth. As they have done. with their scripts and what have you, then that's probably just what they're gonna do. But maybe it's better for the network as a whole to force them to do some kind of upgrade. 48:10DiegoWell, I will not… I wouldn't want to force anyone to do anything, but, before doing something like that, we should be, like, really, really, sure that, this is, like, a really good replacement. The only way for doing that is by testing it, like, like, a lot. So, before doing something like that, I mean… I will keep maintaining core-geth, as much as we need it. Hopefully, the community will realize that I go with Ethereum Classic, it's a better option. And at some point, I don't know, it's… time will tell. I mean, yeah, it's hard to say what will be the future. Hopefully. There will be operators that will see the value in this, and this will be, like, a more easy decision to… to make. If we make this, like, simple enough. I don't know, maybe… like, I think providing this… like, migration path, that it's not bumpy. I think it's, something positive, something that might encourage people to try these new clients, because it will… it will essentially feel the same, but… also with a lot of benefits from the, like, the new architecture and the new things that the new versions of go-ethereum bring. So, I don't… I don't know if it's that important, the name. That they're running, but they're… they might be happy just being able to use the same… database that they had before, and if everything works the same, I think there will not be many people complaining about it. But what I don't think it will be… I don't know, I'm still debating on this. One option will be to just like, use the core-geth name for this new client, but I think that maybe that's not fair, because that might be forcing people to do something that they may not want to do. So maybe I think it's better to keep this as a separate name, like, this is a kind of a… I will say it's a new client, but it's not, it's just an upgraded version of the same base that core-geth was based on. And the idea will be to, okay. You sh… you should take the… you should make the decision. If you want to move into these new clients, that… that essentially should be… should feel the same. So, I think, yeah, I think probably that's the best way to move forward, but I'm open to, I don't know, to opinions into that, from you or from anyone. But he's interested in… in this. 51:22IstoraYeah, no, I… I was… Kind of just thinking out loud previously, but it does… Yeah, in order to test these clients properly, you kind of have to be running them alongside core-geth for a long time. And that means, like, you can't just instantly switch everything, so you kind of have to… Like, gradually move things forward with, like, a. 51:46Diegofabricate. 51:47Istoranotice, potentially, if you are going to stop with the… the core-geth? But that will take a long time, and yeah. Reckless to just stop supporting and force everyone to upgrade. 52:01DiegoYeah. Yes, eventually. 52:02IstoraHow many? 52:03Diegoeventually… eventually something that might happen is in the… in some distant future, there might be some hard fork that will not be implemented into core-geth, that might force people to use one of the newer clients. But, yes, that's… that might be, like, the… end of life for any client, if you are not implementing the hard fork rules, the new hard fork rules. But, I don't think that's something that will… that will happen in the nearby future. 52:35IstoraI see. 52:36Diegothis for core-geth. 52:37IstoraAnd the… the previously discussed, EIP bundle. That's… within scope for the next version of core-geth, I imagine. 52:49DiegoYes, I really have a branch with that implementation. But yeah, it cannot be, like, settled yet. Yeah, I don't think it makes too much sense to release it. But once we have an agreement on that, yes, I mean, I have a version there that it's… yeah, we can put into testing and to… yeah. Running DevNets and all the things that we used to do for new network upgrades. 53:19IstoraYep. And I guess, like, this is a… we're coming up to the hour, so this will be kind of like a wrapping up piece, but the… this is also in the context of some recent pull requests on the website that's… basically… like, I think it's really important that we are delicate and thoughtful about… The naming of which organizations Clients belong to. And having the separation of developers, and… Organization maintainers is kind of essential in terms of balancing power and ensuring decentralization of the software stack itself. And… Like, personally, I believe that every different client should be under an organization controlled by the… Maintainer of that. client. And currently, ETC Labs core-geth just happens to be the main client that everyone's using, so that's… Where it's… Placed at the moment. But yes, in the future, like, each client should probably be under an organization. 54:32DiegoYeah, yeah. 54:33IstoraThat's… 54:35DiegoYeah, and that's how Ethereum works, basically. Besu, they have their own. Nethermind, they have their own, so there is not a huge problem there. Actually, they were trying to get rid of, go-ethereum from the slash Ethereum, Organization for many years. They didn't do it for political reasons, as… as I understand. But yes, the… The path is to… to make every client into its own organization. And… and there is not… it's not a big problem to have many clients, even forks of the same clients. I mean, it's up to the users to decide which client they want to use. And if they trust, or they have been trusting the ATC Labs Core organization for a long time. That's great, and if someone is able to convince the users to use their… some other organization, that's fine too. I mean, it's up to the users to decide on which one to put their trust. Something… It will be… I mean, I don't know, like, it's fair to probably not use the same name, because it might be confusing, but, in the end, it's, Yeah, it's something that's out of our control, it's just, like, well-behavior, but. 56:03IstoraYeah. 56:03DiegoYeah. It's. 56:05IstoraAt the end of the day, we want users to be able to make informed decisions. And… 56:10Diegoscope. 56:12IstoraForce them to make choices when they need to make choices, and try not to make decisions for them. When it's in their interest to not do that, and… like, putting stuff under the official Ethereum Classic. Quote-unquote official, there's nothing official in ETC. organization. Really just, kind of, removes that choice from people that they really should be making themselves. Like, we're saying, like, this is the correct client, and to me, that's completely antithetical to the ethos of the project, so… for… for many reasons, that one being the main one, I don't think that the core clients should be under the Ethereum Classic org. 56:57DiegoYeah, yeah, yeah, I agree, and I made the same point into that discussion. But, yeah, for me, I think, the best… the best place for core-geth is what it already is, and if anyone else wants to create a… a fork, I would appreciate to use another name. but under their own organization. And then, I don't know, I mean, the user's cool. Decide which client to use, and that's… that's fine. 57:29IstoraYeah, yeah, in an ideal… 57:31DiegoThe game, and part… 57:32IstoraYeah. 57:34DiegoYeah. 57:35IstoraDude, go ahead. 57:36DiegoNo, no, I was going to say that, I mean, it's part of the game, and it's part of collaboration, and it's, yeah, part of the open source world. It has happened many times in different softwares, so it will not be a big deal. 57:51IstoraTotally, totally. And then, I think we should have… we should list as many forks as reasonable in… on the website, but present them neutrally, and… 58:01DiegoGo. 58:03IstoraLet the public decide. Let the users decide. 58:06DiegoAbsolutely. 58:07IstoraThat's… that's basically… The approach that I think has always been the case, so why change it? 58:12DiegoYeah, I agree. 58:16IstoraOkay, well, we're bang on one hour, so thank you, Diego, very much for joining. It's been an awesome call, and deeply technical, and I hope the listeners enjoyed. I certainly did. And, Yeah, we're going to have the next Ethereum Classic Community Call in 2 weeks' time. Same time, same place. If you're listening, there may be opportunities to join the green room and earn… a… a proof of contribution. Basically, I'm about to launch an app called NourishMint that will be ready by the next call. And if you join the green room in the next call, you can help me beta test this app, and potentially earn some… rewards on-chain on ETC. So, if you're interested in joining that, you can join in two weeks, one hour before the call. And, until then… Unless there's anything else to add, Diego? 59:18DiegoNo. No, no. 59:20IstoraOkay, well, see you next week. See you in two weeks' time. And, till next week… till next time, stay classy. 59:29DiegoOkay, thank you so much. 59:32IstoraThanks, Diego, take care. Bye-bye. 59:34DiegoBye, bye.