Inside Paradigm’s plan to make Ethereum more resilient

Crypto venture firm Paradigm made one of its most notable contributions to the Ethereum network yesterday, launching the alpha version of an open-source node implementation called Reth v0.1.0.

Reth, developed in the Rust programming language and released under an Apache/MIT License, forms part of the backbone of Paradigm’s commitment to actively influencing the crypto sphere by creating client software centered around performance. The project took nine months of coding, a devoted team of eight core developers and 90 contributors.

It aims to reduce latency between the node and the network while maintaining uptime at all times. However, the main objective of Reth goes beyond the technical as it seeks to make Ethereum’s blockchain more approachable for developers by enhancing node performance.

Although client diversity isn’t a pressing concern for Ethereum, it’s crucial for the network’s users to rely on diverse client projects that offer fully functional node software and well-connected to the network. This is where Reth comes into play.

“We believe that by using Reth as a node, we can actively contribute to enhancing Ethereum’s client diversity, thereby improving the stability and decentralization of the protocol,” George Konstantopoulos, CTO of Paradigm and developer behind Reth, told The Block.

Reth: Performance-centric Ethereum client software

Ethereum node clients can be divided into two categories: those designed for Ethereum’s execution layer, which handles transaction settlement, and those meant for the consensus layer, responsible for achieving network consensus. Notably, Paradigm has joined a growing list of companies developing such software for Ethereum, contributing to an already crowded client software market.

Existing popular execution clients include Geth, Nethermind, Besu, and Erigon, while consensus clients comprise Lighthouse, Lodestar, Nimbus, Prysm, and Teku. Nevertheless, the Ethereum ecosystem always stands to gain from an influx of a new client project, especially one backed by an influential venture fund like Paradigm, renowned for its substantial technical and financial prowess.

Reth’s primary role will be as an execution client, enabling users to utilize it for block building and maximal value extraction as necessary. Moreover, it can support Ethereum consensus nodes as well. 

Reth has already demonstrated impressive performance metrics. The team said that Reth can endure heavy traffic and sync quickly. It was able to sync with the Ethereum blockchain from its genesis to block number 17.4 million within 50 hours. This, Paradigm, claims, is the the fastest sync speed among all client projects.

Despite these significant advancements, Reth is still in its alpha phase, with the team working towards improving the software’s stability and resilience. 

The Block caught up with Paradigm’s Georgios Konstantopoulos to discuss Reth’s role in the Ethereum ecosystem, the challenges faced in building Reth out, and what the industry should expect to come next. Here’s the full Q&A:

What is your vision for Reth’s role in the Ethereum ecosystem in the next 5 years? Do you aim to overtake existing clients or remain a niche alternative option?

We believe that by using Reth as a node, we can actively contribute to enhancing Ethereum’s client diversity, thereby improving the stability and decentralization of the protocol. Furthermore, Reth’s role as an SDK ensures that it provides a user-friendly and accessible tool for developing EVM-centric infrastructure, such as indexers, block builders, and more.

We do not have a zero sum mindset, and we hope that Reth offers an alternative option for people who are after high performance and a great node experience.

What has been the most surprising challenge you’ve faced so far in developing Reth? What have you learned from it?

The biggest challenges have been:

1. Learning all the edge cases that exist as part of Ethereum’s history and correctly implementing them.
2. Optimizing every component of the node in the presence of such edge cases.

Our biggest learning from this was unsurprisingly: Mature testing and benchmarking practices are table stakes for any high performance / complex system developer’s toolkit. We put a lot of emphasis on that early on, and that allowed us to iterate very fast on new features, while covering edge cases and optimizing components without fear of breakages or regressions.

How extensively has Reth been tested under adverse conditions like high transaction volumes, network splits, or denial of service attacks? What concerns do you have about its resilience?

Want to caveat this response by saying that Reth is in “alpha” phase, and we’re still heavily testing and improving its stability.

We apply a defense-in-depth approach towards security to gain confidence around resilience:

• We operate nodes ourselves and carefully monitor them, their logs, metrics, alerts etc.
• We run the Hive testing suite nightly on Github Actions, which tests for reorgs and other consensus-related edge cases.
• We developed Flood for stress testing Reth under high RPC volumes that look like DoS attacks.

We are generally happy with how the node behaves today, although there’s still more edge cases to be uncovered. We feel confident about the correctness of the historical sync, and any resilience concerns would be about edge cases we haven’t observed yet at the tip of the chain, e.g. during a reorg that is not captured in the Hive testing suite. Testing never ends and is a process which we take very seriously for the long run.

At what point will you consider Reth to be “production-ready” and what steps do you need to take to reach that level of maturity? How can the community help accelerate progress?

Production-readiness is a really high bar, which we aspire to meet in the future. We asked node operators what that bar is for them, and these are the most important metrics they shared for production readiness:

• Reth’s uptime without crashes. For staking, that is near 100% uptime, as otherwise you could get slashed by the protocol.
• Ability to survive harsh environments without database corruption e.g. SIGKILLs, power outages or node/machine restarts.
• Can the node stay synced and follow the tip quickly, even under heavy load (whereas, anecdotally, other nodes start falling behind sometimes, and that’s a problem for your reliability).

All of these are metrics which we’re actively tracking in all our running nodes. The bottleneck to production readiness is going to be time, more eyes on the code, and more node operators running the node. Our ask from the community would be to be extremely open and direct with their feedback. We take every feedback loop very seriously and would love for people to run nodes and share their experience with us.

If you had to pick one part of the Ethereum roadmap to focus Reth’s efforts on, what would it be and why? What might Reth do differently in that area?

Ethereum’s roadmap is long and ambitious! I think it’s hard to pick one item from that list given its longtermism. I think EIP-4844 and Cancun are the most important thing for us to get right due to the implications on rollup scalability. I don’t think we’ll implement things differently in any way, but the process for implementing will be more collaborative with the rest of the core devs, compared to us so far catching up to a known target.

What is your view on client diversity for Ethereum? Do we have enough independent implementations of the protocol currently? What can be improved?

Client diversity is critical for a resilient network like Ethereum. If a single client dominates with a market share of 66% or more, there is a significant risk of disrupting the chain and causing monetary loss for node operators. This is because if that client has a bug and forks to its own chain, it can finalize the fork, making it difficult for validators to return to the real chain without being penalized. 

Anyone is free to start a new implementation of the Ethereum protocol, in any language of their choice, like we did. The main pain point of client diversity is that testing across all client implementations becomes harder. We should invest further in cross-node integration testing infrastructure, like the Ethereum Foundation does by maintaining Hive.

Where do you see the biggest opportunities for performance or functionality improvements over existing Ethereum clients? What is Reth’s “unfair advantage”

Firstly, we were fortunate enough to learn from all the lessons of client development over the past years, which let us avoid many mistakes. Secondly, we decided to build Reth as a brand-new modern codebase written in production Rust that is well documented, tested, and modularized, which allows for high performance with fast development speed, with little technical debt.

Still, we see many areas with room for improvement. We’d like to support OP Stack as part of the upstream node implementation, and further refactor the codebase to be easier to consume. Finally, we’re also excited about further performance optimizations, especially around reading and writing to disk, and the database size.

We invite every developer to join us in this process of extending and optimizing the node!

© 2023 The Block Crypto, Inc. All Rights Reserved. This article is provided for informational purposes only. It is not offered or intended to be used as legal, tax, investment, financial, or other advice.