Looking back at Nethermind's core development journey over the years makes me incredibly proud of what the team has accomplished. The Resiliency Phase Before the Merge, there was effectively no alternative to Geth. It was by far the most stable and performant execution client, and execution client diversity barely existed. That concentration posted a major risk to Ethereum's resilience and one of its core properties: never going down. Today, Nethermind stands alongside Geth as one of the leading execution clients, with each accounting for roughly 30% of the network. The Ethereum Scaling Phase Once execution client diversity became a reality, the next major challenge was scaling Ethereum. Ethereum had been stuck at around a 30M gas limit for a long time. Nethermind led much of the performance engineering effort, demonstrating that Ethereum could safely operate at significantly higher throughput. Beyond setting an example, many of our optimisations and ideas were adopted by other client teams, helping raise performance across the whole Ethereum. Just as importantly, we helped establish a performance engineering culture within Ethereum core development, bringing a more data-driven approach to gas limits and gas pricing. That work was later adopted and expanded by the EF. Ethereum still has plenty of room to scale, but we're moving in the right direction. What's Next We’re now focused on the next set of challenges: 1. Executing on the Strawmap while leveraging AI as much as possible and exploring how AI agents can make Ethereum development increasingly autonomous. 2. Making Ethereum post-quantum resilient. It's part of the Strawmap, but it's important enough to deserve a separate point. 3. Accelerating institutional adoption of Ethereum. 4. Improving RPC layer - from hardening and design to making it verifiable.

🌟 @Nethermind has just passed the RPC compatibility tests! We’re happy to help if you’re considering Nethermind for RPC. Shortly after Fusaka, we’re planning a bigger release for RPC. Regarding the remaining three tests, we believe our responses are correct, and it seems the tests need to be adjusted.

Someone needs to finally say it: choosing Rust or any other language doesn’t make your software fast. @Nethermind is fast because we mastered engineering and built a strong team. People tend to overestimate the influence of your language choice and underestimate other factors such as architectures, algorithms & data structures, how familiar your team is with the given programming language, your priorities, and how your QA processes work (extremely important if your client gets high adoption; I prefer software that works rather than software that breaks fast, and this is always our number one priority). The fact that it works for us is because we hired super strong engineers and .NET legends into our team (plus QAs, leads, DevOps). Also, I think people underestimate C#. C# has amazing tooling that makes your team more productive and allows you to write highly performant code and control the GC, and the main limitation is how well engineers know things. And it works the same with Rust, there is no way of skipping solid engineering. If I built a new team from scratch, I might pick Rust or C#, or something else; again, it depends on many factors. There is still lots of space to keep improving Ethereum clients and blockchains on the design level. There is still not enough data gathered to describe EL performance fully. So about the labels of “the fastest client”: EL performance has many flavors and can’t be described with one metric (different RPC endpoints, syncing, archive, block building, and many more). If we would like to simplify EL performance to one metric, it would be how much throughput you can handle, and I am proud that Nethermind is crushing it, and if simplifying it to one metric, I can proudly say that Nethermind is the fastest client.