Reth (short for Rust Ethereum, pronunciation) is a new Ethereum full-node implementation focused on being user-friendly, modular, fast, and efficient.

And ECC gave me a 250-euro student ticket to come to attend.

And I was the beginning of it all so big.

Thank you to the organizers Last year I presented foundry foundry is a Developer tool that many people in this room maybe use, maybe not use.

Today I'm here to talk about Reth, a new Rust Ethereum node that we've been building at Paradigm for the last...

Over here in the screen before I get into any exciting slides you're seeing a few things.

Etherscan on the left and a node running on the right.

On the top, TMAX panel, you see a Lighthouse node.

On the bottom left panel, you're seeing a Lighthouse node.

On the top 1, you're seeing a Ref Archive node sinking at the tip.

On the bottom right, the ticker that's going up is not some countdown.

It is the block number going up And on the left, we're seeing ether scan.

So let's start refreshing ether scan And see what happens 1 Rest girl goes eventually to 2 and so on so we're trying the tip.

Wanted to give this as a sign that we're gonna talk about real engineering, live in production, that we put a lot of hard work into.

Paradigm is Building a new Rust Ethereum node.

REST is built to be modular, contributor friendly, and of course, blazing fast.

It's built in the Rust programming language, which is a language that empowers developers to build fast, efficient, and reliable code.

I don't consider myself a great programmer, but when I discovered Rust, my life changed.

You will find some links there, our chat rooms, my Twitter, find me after for stickers, et cetera.

And the person that stole it from the cafe we will find them I Don't know what the right pronunciation is we make decisions by Not consensus necessarily, but by or combine committee we have different opinions.

We won't hold anyone to any accountability here In this talk we're going to talk about why?

And I hope that this is going to be informative talk and 1 that will hopefully pave the new wave of Ethereum infrastructure.

First and foremost, we are all Ethereum developers.

And what is happening is that the world is changing.

The world is evolving, and so is Ethereum.

Here we are seeing Vitalik Buterin's very

a theorem The theorem roadmap involves more and more and more and more Complex and simple

yet time is finite and things are happening and we don't have infinite resources.

Because the Ethereum protocol is built in a way that if 66%

of the validator set, which is now running an execution node, suffers from a critical bug or yet worse is compromised, the network will finalize a bad checkpoint and that is catastrophic.

So it is critical for the theorem networks health that there is no node that has over

66% There was a very noble work by a prison where they

literally Encouraged people to run competitive nodes.

That was beautiful The goal of wrath is not to overtake geth or anything else Peter's team is the team that brought us all here is the team that gave us jobs, you know So Peter's team deserves all the support it can get.

We'll be happy with number 2, number 3, whatever.

We want to provide a new wave of Ethereum infrastructure.

great code base with great abstractions in the middle, and everything plugging onto it.

A lot of people maintain get forks, some better, some Frankenstein, some you don't want to see them ever again in your life.

We want to get to a world where instead of having endless forks, we have some, perhaps, because it's going to be hard to agree, of course, on 1 thing, but some varying implementations with clear abstractions, clear interfaces, clear tests, clear benchmarks on every 1 of these components that can be mixed and matched to build new EVM-centric infrastructure.

The thing that bothers me actually the most, though, is

that people think that this is hard and that this is something special that only talented people do.

However, This has been a system that has been developed for a long time.

And as the protocol has been evolving, like, we cannot always do the best engineering from the beginning and we cannot always figure out the best abstractions.

We have deadlines to meet and, you know, And we have families to meet.

And not everyone can be over the node 24-7 to make sure that the person like me, like 5 years later, will be complaining.

Yet we want to see, can we do better than this?

Performance is something that I deeply care about.

Archive nodes are a critical piece of infrastructure for the ecosystem.

And most importantly, they allow everything to work.

Every piece of historical infrastructure, indexers, Etherscan, anything, anything you can imagine, literally, that has some notion of historical data needs an archive node.

Archive nodes do not need to be expensive and slow to sync.

Archive nodes are a piece of technology that is critical for the future of the industry.

Secondly, the rollup-centric roadmap demands more performance on the edges.

Current nodes can support more performance, because contrary to what 1 might say, it's not the CPU or the whatever that is bottlenecking you.

And the state growth is the big enemy here However, 1 could say but let's try to do better in this vertical also

And I will not talk about the third and the

It's kind of obvious why these are useful Comes that question then So that is all the motivation so far.

Let's talk a bit about the principle around how we approach the problem.

We thought we went to the drawing board and we said What do we build?

I don't know anything about nodes I didn't know anything about know anything about nodes until we started.

So we're like, okay, let's give it a fresh look

very easy to consume, a thing that can become the backbone of the new wave of Ethereum infrastructure.

Again, Ethereum has given me everything, and I want to give back to it.

And this is hopefully 1 small contribution.

So to the meat of the conversation, REST is an Apache MIT licensed Ethereum execution layer written in Rust.

It is driven by the open source team that shipped Foundry

and is going to be shipping a lot of many great things.

We have some people from the team in the audience, Roman, maybe Alexei as well.

And I want to spend a minute to talk about our culture.

It's inclusive, mentoring, and fully async.

Even though we have a core team of very, very, very strong engineers, the most talented engineers I've ever worked with, we have no ego.

We talk to everyone in the community and we mentor them hand to hand.

There was 1 guy that said, day 1, journey of learning Rust.

And we jokingly said on day 3, Red Contributor by day 10, and he was a contributor by day 8 or 9.

The async first component is something that

I learned from working at Paradigm on the investing side, which was something about having very, very low tolerance for noise.

The synchronous communication is like a mutex on your calendar.

While everything should be flowing like a channel, like an async stream.

So our culture is like heavily built on async written communication, very clearly communicated, low ego, close every feedback loop.

And that is what truly enables us to build great software.

I showed at the beginning of the presentation.

a big box, feel free to hammer it right now, open an issue if it breaks.

We share our code, we're not afraid to share experimental code, we invite people to test our experimental code, foundry infamously was on nightly's, still is, and we screwed up the v1 release we'll talk about that another time we have a grafana board here which has all the Prometheus metrics exported by the rest node that you're seeing above it and the current tag is alpha 4.

We're going to talk about the new releases in the future.

So 8 people stood up a new node in 8 or 9 months.

We have 100 plus open source contributors of various size.

But what we want to do is that we want to create the next

Not application, not smart counter devs, core devs, people that will make the Ethereum ecosystem anti-fragile and real for the long run.

The node has a very attractive performance characteristic, which I'll talk about in a second.

Here I have a link to a tracking issue that my colleague Matt Sides created which is a checklist of all the RPCs supported.

And has support for both GIFs, debug tracing, rewritten from scratch

in Rust, including the JavaScript tracer, which some people love, some people hate, I hear, and the parity trace module, following the spec, well, no spec, but following the initial implementation as much as we could, actually.

And the last bullet I'll talk about in a second.

The first 8 devs in this picture are named Matt Seitz, Roman Krasiuk, Oliver Norberg, Dan Klein, Dragan Arkita, Alexey Shekirin, and our unknown Joshi.

They're the best Rust team I've ever worked with, and a Big shout out to them for dealing with me on a day-to-day basis.

People are starting to get hired out of our codebases.

People come into our chat rooms and they snoop competitors hired out of our chat rooms.

We have a first look on the best ones, hopefully.

There's no point in creating any conflict.

And the upper numbers are a bit easier to measure.

The lower numbers, there's like some nuance, and I don't want to be too strongly opinionated.

The numbers, what you see up is the block 17.4 million.

It doesn't scale that much, like in a month.

Ref achieves best-in-class syncing speed.

We tested on latitude, on bare metal servers, on Samsung Evo devices with very, very high IOPs.

That's the bottleneck when you're sending a node.

So we chose to use the best hardware to get the best output.

For less good hardware, the gap might be less big.

But we're going to work on keeping it to be as good as it is now.

The database size, I think, honestly, the difference with the ErgonDB doesn't really matter if you like it that much, it matters to be on the order of magnitude, 2 to 4, 4 to 8, 8 to 16, and so on.

Yet at Nethermind, they have the tri-structure built in to the database, which means that they incur significant overheads for historical nodes.

Caveating that this comes at trade-offs for like how well you can operate at the tip.

We're trying to do both TBD if we'll be able to do both.

The initial goal for us was to build an archive node and we're talking about archive nodes today.

On the slides below, there's 3 things, and I

will explain how these charts were generated because we take a scientific feedback loop driven approach to all our charts.

You see a throughput chart, which means that input, output, 1 request in, 1 request out.

you keep hammering the node and it keeps responding successfully.

For the people that we'll ask later, the spikes, we don't know yet what they are.

Obviously, latency should be going up as you're increasing the load.

We're still investigating how to make the charts better.

Any data analysts or data scientists or somebody that's very experienced in load testing, please reach out.

This is made possible by a tool called Flood that my colleague Storm built for Reth.

We were like, we need to get numbers for this.

So flood is a tool for load testing nodes at the J curve inflection point when latency and throughput start to come into contrast with each other.

And that's the only place where you need to measure.

The only thing that we need that we know how to do it, like this open source project is measured, measured, measured.

Anybody that doesn't test at the J curve inflection point of the thing is giving you false numbers.

And that's why I'm trying to also get to hear that, like, we didn't invent any new algorithm, we didn't do anything crazy, we had good abstractions, and we just applied good software engineering principles from scratch.

Profiling and benchmarking, the feedback loop.

It really opened everyone's eyes to what can happen and to the flat DB design, which we have deviated at this point, but still a big part of it has overlap and they're the best people that could create this.

It's built on Reven, which is a library that our colleague built, which is also the AVM that powers Foundry and I think all of MEV infrastructure or anyone that's serious about it today and the Rust programming language.

I'm realizing I have 7 minutes, so I'm not going to go through all of these.

But Swiss cheese model of security, you go through everything, You apply everything that you can.

If you thought solidity auditing was like something, do this.

The action item from this group, this audience, is help us make the node great.

If it is the case, we're going to do better.

and we have no way to find out more about it.

We work with Latitude, who will be creating a one-click deploy solution, and we also give discounts to people to run on bare metal.

Literally, if you start seeing a node on Latitude right now, call me in 50 hours and we have a node and we can talk about it.

Cross-platform priority, very, very important.

And the hardware, the only thing that matters is the

disk Less cores on the CPU because we're doing a single threaded process, which is the AVM Not fundamental I will talk about in a second memory usage 16 gigabytes.

We've talked about the node, but we've said it's modular.

We're building EVM-centric infra, and we're creating great abstractions for it.

And not just that, this is like the entire crate.

Every crate is carefully designed, careful interfaces, careful tests, careful benchmarks for everything.

And I will do a community showcase just to show how powerful this is and I'm not like selling you anything.

So why are we extracting data over JSON RPC when we have a database available to us locally when performance is important?

See all [EthCC] Livestream 4 transcripts on Youtube

Georgios Konstantopoulos Konstantopoulos - Reth: A new Rust Ethereum Client