Rust x Ethereum Day 2023 at The Foundry SF

Georgios Konstantopoulos presents on "Reth"

The talk we're calling it Rust Retinascence.

we can, and let's see where we are going to land today.

Here you see that we have some stickers on the back.

We have a Zora chain NFT that people are free to mint.

It's an open edition which closes on Sunday.

And we also have a Farcaster channel and it's been actually had an interaction with someone today where they were like, hi, I know you from Warpcast.

a half hours, we're slightly behind, but we have the whole day ahead.

We're going to do a few talks from very high context people from our teams that have built a lot of our open source software.

So if you want something fancier, DoorDash is your friend.

And then we're going to do an hour of lightning talks.

We're going to have a community showcase of 5 minutes each from each attendee without Q&A in the interest of time Where people will go over what they've built and then we can all sit and chat until the end of day We will take the chairs out.

We'll put tables and it could be a hybrid of like a hacking, socializing situation.

This is an untested format, so we'll see how it goes, but overall, get the right people in the room and things happen.

So, the takeaway, like what am I going to sell you today, right, what am I going to convince you of, is that we want you to be building on Rust and Ethereum, and we also want you to be using REST.

From this talk, from the other talks they will tell you other things.

we want to use in production but we don't have enough people but it seems like small groups of people are achieving great things with it, so clearly there is something there.

And on REST, using that Rust foundation, we seem to build something also exciting, which we also think has great potential for the future of the ecosystem.

So, maybe just to go back a little bit, in 2021, it was about a year in, in a library called the EthersRS, where we started to dare to dream, where we said, OK, we have EthersRS.

It's a good library for interacting with things, what more can we build?

was, if you build everything to be very modular, very well tested, and very well documented, then we could hopefully get to the state where the cost of deploying a new application, a new system, a new startup even would go way down.

And we thought, okay, what is going to be our foundation?

Although these days he looks more like this.

and foremost, which is an underrated thing for production use, is batteries included.

You download Rust, you get the compiler, you get a very annoying teacher, which is the compiler end, the linter, you get a test framework out of the box, you get so many things, and the most important thing, actually, for production use, is a mature ecosystem of libraries.

We have asynchronous APIs, we have databases, we have

networking implementations, everything, again, built with the lens of Rust of being like this high-performance thing.

So there is this meme that, oh, Rust is hard, blah, blah, blah.

But like every tool, there is a learning curve.

And there is a productivity frontier that you get once you're past that learning curve.

production in this room knows that very well.

If not, I think it's worth talking about and getting over that initial hump.

Rust has a culture of documentation and inclusivity.

Note how we haven't talked about performance yet explicitly.

The documentation is very important for onboarding people.

The inclusivity is also very important for making sure that we

Everything can be simplified with the right abstractions, the right test, the right documentation.

And that's how we have approached our software.

That's how most people in the Rust community also approach their software, which is very different, let's say, to C or C++ community, where being able to write hyper-optimized assembly that nobody can read is considered elite.

You get the obvious things that everybody has heard about.

Efficiency means I can do them with little resources.

And that is where the Rust language employed modern programming language techniques, mainly the Boto checker, to give you a language that has very efficient memory allocation, and very strict types, and very eliminating a large class of vulnerabilities, while also giving you very high performance.

It's cross-platform, which means that you can go to Linux, you can go to Windows, to ARM, to whatever you want.

And you can also go to the browser, which we'll hear some slide about from Tom and Wagner later.

The big con is that you need to learn a new thing and learning a new thing has a perceived cost

and that is a very fair critique but you know like take some risk and maybe you will be rewarded.

For Rust and Ethereum the motivation is very simple.

is a high-performance language and Ethereum is mission-critical infrastructure which demands safety and performance, we're going to use aerospace software for it.

in Rust and Ethereum there's this big ecosystem of MEV, smart contact developers, indexers, RPC providers, a lot of things that custody big numbers and these big numbers 1 they need to remain big because for the sake of our industry

Or if there is any performance issues, we'll have trouble saturating demand.

So to the previous slide, Rust is a perfect fit, almost, for this kind of problem.

So what have we done so far to ameliorate this concern?

So I have put together a small timeline of what has been shipped so far, just to paint a picture or to put things into perspective.

I joined Paradigm, Ether's RS, which later became Alloy.

there were a bunch of other Rust ecosystem libraries from

Parity, because Parity was developing Parity Ethereum later on, called OpenEthereum.

But there was a lot of legacy code in this codebases.

This was 2017, 2018 Rust, before AsyncAwait.

So it was a very, very, very different world.

And we wanted to take a fresh perspective at it So after ethers we built foundry then We found which foundry is for testing.

Then we found Dragon Rakita who wrote Revm, which unlocked the whole simulations game.

Then we're like, okay, where else should we put Revm?

Basically, the thesis was, if we have a very fast operating system,

lot of issues with, and tech debt with our software that was built from 2020 did.

So we did a rewrite of that and also achieved more performance.

And most of the software on the left side, on the pre-Pardem raster, are semi-deprecated at this point.

And Storm later today will also talk to you about Cryo, which is our approach to data.

So you can see how there's sort of a full stack infrastructure approach here.

And it's unclear what's going to happen next.

It's possible that we want to move up to higher abstractions, whether it is like application layer infrastructure, like a shared sequencer, or anything else.

So after a 10-minute intro, we'll get to the topic.

So Reth is a new Ethereum execution layer.

It is Apache MIT licensed, which means that it's free for anyone to use, fork, do whatever you want with it.

The very non-obvious thing about Ref is that we see it as an SDK for EVM infrastructure.

It means that not only is it a node, it's a platform that you can build things.

And it reduces the cost of shipping something that people would think was hard to a few days or weeks.

And we will hear from people today talking about it.

We're going to hear about OP-Ref, we're going to hear about MEV-Ref, we're going to hear about ZK, EVM using Ref-Revum, etc.

There seems to be something going on here.

Here I have 2 IPs hosted on the same box, by the way, so we're running an archive and

a full node on the same machine for something like 500 or 600 bucks a month, which is pretty cheap for what you're running on it.

So if people want to hit that endpoint, feel free.

Contributors are excited and we're still barely scratching the surface.

And this is a slide that is 2 months old at this point,

and we didn't do new benchmarks, but the rough trend remains the same.

Reth outperforms other nodes from 2.5x to, I lost count, like 15, to sync.

And on database size, it also outperforms things that we thought were already on the efficiency frontier.

And based on our most recent findings, it seems like we can do even better than that.

On the RPC performance, which is the read loads that many people are interested about, for example, if you're an RPC provider, if you're an indexer, or anything else.

Reth also provides sustained throughput up to 16, 000 requests per second,

which is a lot of queries, a high success rate, and most notably, in many cases, 1 or 2 orders of magnitude, better latency.

will get a response basically instantly, whereas other times, other nodes will go through long code paths for no obvious reason.

So we're quite excited by that, and big kudos to the team for achieving this big feat.

We're gonna have an alpha 8 release soon.

end of year, it will be hopefully production ready.

So here we have Raul, who will also speak to us later today about his other

adventures besides risking 32 ETH in alpha software.

So yeah, Raul, 1 day he came to us, and he's like, hey guys, I'm running this node, it's working great.

I'm like, testnet, No, he was on mainnet, but, you know, again, no warranty.

If you lose your money, it's your money, not, yeah.

A quick case study, again, we'll hear about that later.

a set of patches on ref, similar to OP-Geth, which is a set of patches on geth, to enable usage of Reth in layer 2s, specifically in Optimism.

Now what's special about what happened here is that we had a chat in mid-July with some people from Coinbase, Roberto, who we have here, and some people from OP, which we also have here.

And basically, we're like, this can't be that hard.

And what happened, we set up a chat room, and We did a weekly call, 30 minutes a week, some effort from our team.

But what was very impressive was how these people, like Roberta I think didn't know Rust even when the project started.

These people figured out how everything works, mostly on their own, and as

of yesterday, we're almost at the tip of girly base in 1 month,

when others would think that this would take you

know, like until December, January, February, you know, roadmap level things.

Whereas this is a good example of how people are able

to understand how a not simple code base works, get into it and modify it

in non-trivial ways while being safe or hopefully not introducing new things.

Matter of fact, we found a bug in OBJF as of last night due to this.

Personally, I'm most excited about the wave of experimentation this can enable.

So it's not just that, hey, we have some existing use cases that will make better.

And many times, your imagination is bound By the tools that you have available to you and when that is unlocked you start thinking bigger So what we

can do I do not know novel node architecture is particularly interesting to me and

in general the introduction of more Low-level cryptography primitives on a theorem you can do this today by the way you can do red thick walls get whatever and you can use Reth And I'll go over some examples.

1 is direct DB access, which means this will get

a bit more technical, but people should be able to follow.

It is insane that we're querying nodes over JSON RPC.

an SQLite file, you don't spin up a REST API to talk to it, you talk to the damn file.

So what we're going to see is that by having a good abstraction for querying the database directly, you can get a lot of efficiencies

And we will also see a perennial problem that exists in all node operators, which is, hey, I have a node, I want to add some functionality on it, I click fork on Go Ethereum, I add a bunch of spaghetti code, and then when get releases a new release, you end up rebasing for a week or a day.

So instead, it would be nice if you can extend the node

and get a CLI and everything all good without having to fork it.

Because that way, we have some canonical implementation we can all agree on, we don't waste time rebasing, and we have a unified ecosystem in the end.

So I don't know if this is visible from behind.

Basically, Just to walk you through this snippet, you import 4 things.

You define your main and the result type doesn't matter.

And you do a few very obvious things, right?

You open the database, you query, you get a handle to the latest state to the database, and then you query the database.

You say, I want to ask this address and this storage slot, what happened?

Or if you want to query the historical state of the database, given just a file, all I'm giving it here is a path to a .mdbx file, and that's it.

And this shows a very simple example of how I can either query the latest state of Ethereum or any historical state, which is really powerful.

You see this is like, what, like 24 lines total?

And you already know how you can iterate through any table.

You see I am importing state provider, an account reader.

And then you can imagine easily how you extend this to simulate, pass it to EVM, build block, make 1, anyway.

In practice, we saw REST indexer, which may be not visible over here, basically a guy that is

the VP at Aave who didn't know much Rust, imported the library,

and in a weekend or a week, had a POC Reth indexer that walks the entire logs table, skips non-relevant logs based on

the Bloom filters, ABI decodes them, puts them into Postgres, and outperforms the hosted solutions by 75x.

So if you can build things that outcompete hosted things with open source code in days, that says something about how the infrastructure landscape will evolve in the next year.

For CLI extensions, I'm showing you here the trait that we have implemented that basically says if you implement any of these methods, your node will get overridden functionality.

We have 2 methods, 1 called extend RPC modules, another called spawn payload builder service.

See all Paradigm transcripts on Youtube

Rust x Ethereum Day - Reth