I am 1 of the co-developers that I'm building RET.

It is modular, contributor-friendly, and basically fast implementation of the Ethereum protocol.

What I want to talk about is basically these 4 things.

A little bit of the history, why the new client is important thing, what are we missing currently in the present state?

I'll be focused a little bit on the modules, basically what RET is composed of, while they're important for us, while that modularity is important for the new clients.

I'll give a little bit of developer insights to just show what basically path that we took, what decisions that we made, and I think talk about a little bit of the current state of the client.

Diversity in Ethereum ecosystem is very important.

In essence, it allows you more security, it decentralises network, it allows basically if there is some potential problem in the 1 client, other client should take over and just move the network forward.

But the present state is the get is the majority client that everybody uses.

So if the get has some of the potential consensus bug or something like that, it will break the network, network will stop, and all the client will just report the problem.

They couldn't, they don't have any weight to move Ethereum forward.

Other things that other clients bring is innovation, it's a little bit experimentation.

It provides users and developers new weight to use Ethereum.

A little bit history, 2022 is the year that I started working on Ethereum.

In this time, we had to get as even more major Ethereum client and the second biggest 1 was Parity Ethereum.

Parity Ethereum at that time basically moved away from Ethereum space and just open sourced their client and renamed it to OpenEthereum.

Here we see fork of the get, named TurboGet, there is Nethermine, Parity renamed to OpenEthereum.

London hard fork, around that time, OpenEthereum was deprecated.

It was basically the client that was not well maintained and it basically time got over it.

And at that time we decided to deprecate it to not implement merge, basically Parise hard fork.

We see Aragon that was renamed for the turbo get fork of the get and see Bessu and then the mine taking traction.

2022 people started noticing and basically focusing more on diversity.

And as it was 1 of the major points of the merge, as the merge was 1 waiting, because when you switch consensus, you cannot go back.

In that sense, diversity was a little bit more focused.

And present, Nethermine, Aragon, and Besu are the major clients, Gett is still the major client.

Now we come to the last year, September 2022, Paradigm started building their own client.

Idea is to have like very modular, very well-made documented client that we hope to, we'll improve the ecosystem and development experience.

Basically modularity is 1 of the major points of us, because we want to be able, if needed, to just rewrite components if they don't perform well enough, or to be able for community users, anybody, just to use components, add their modification and use it with the rest of the system.

Cleanup structure, standalone Rust libraries basically allow that hackability of the code and allow for client to be used in different ways.

You want to be flexible and in configuration to support both the archive node and the full node.

You're currently supporting only archive node, but we will add full node support.

And most importantly, it's MIT Apache license, so anybody can use it.

I'll focus a little bit on components, what's inside the client.

Database is most important aspect of any Ethereum client, because how you write the database, how you read the database matters a lot in terms of how fast you are thinking, how fast you are doing things.

And the database layout is the most impactful thing in the Ethereum client.

For the plain state, we are using the Dragon flat key value database.

We'll probably shrink in the future a little bit.

There is some idea that we want to implement.

We are still a work in progress, and currently we are very satisfied it's under 2 terabytes.

Optimization of data, basically, optimization of memory footprint is very important as any byte matters.

For example, 2-bit intersection, if you save cache of the section, it's additional 50 gigabytes, 64, and still the optimization depends on how you read and write data.

First module that can be important is provider.

Because every terminal and RET including has simple database, fetching data and fetching data in proper order is very hard.

You need to know layout of the database, you need to know encoding that's used, you need to know basically where the data is.

Provider is the 1 library that's going to wrap that.

It will give you high level abstraction on the low level database access.

Basically, it will allow you to fetch 1 block where the block is split into multiple tables.

Other than that, it will allow you to have access to the history state without worrying how the state is indexed.

1 good thing is that we can have multiple readers.

And basically, you can run your client, and client will push data, write data to the database.

Then you can have another process that's going to just read.

Initial sync with the pipeline with NVMe SSD hard disk is under 2 days.

Pipeline is basically used for initial sync.

It's optimized to handle that multi-block execution and multi-block preparation of the execution and localization after that.

It's 1 of the idea that is pioneered by Aragon.

It's, yeah, we have in our database, we are just saving the canonical chain that allows you a little bit of flexibility where we know that the data and blocks that are inside the main in the database are the canonicalized block.

Site, penny, block, we have different model that handles that.

Pipeline, for example, stages that are inside the pipeline are the header body that are specialized for the fetching of the blocks, headers, basically data that's needed from outside, from the P2P network.

There is some sender recovery, total difficulty that they need to realize preparation for the execution.

Execution that executes, creates receipts, everything around that.

And there is a few stages that do merkelization and history indexing.

There is some places that we want to improve.

1 of the things that we could introduce as ETL is to read the right data a little bit differently.

But either way, we are very fast even without it.

Longest time for execution is, of course, execution.

It's basically a list of traits that abstract away components.

Basically we implement the trait, specify the trait, and somebody is going to implement it.

That allows you very, like, abstract modularity between the libraries.

So you can just implement your own trait and just be sure that you comply with the rest of the system.

P2P is 1 of the things that does discovery, management of notes, timeouts and sending, receiving requests from the P2P network.

It's 1 of the things that every client obstructed in some way because it's very easy to obstruct it's It allows you to handle peer management in 1 place and don't think about it Downloader is wrapper around P2P it's glue between the rest of the system and P2P module that allows you to download headers, blocks, and full header blocks and bodies, whatever you need.

In the future, maybe we switch downloader to not fetch P2P, but the idea is to fetch from some server or something like that.

It is memory structure that stores validate blocks that are received from the Kostasus layer.

It's needed as a separate entity that allows us to have multi-site blocks that can potentially be received.

And it does reorganization on the R canonical chain that's database.

Merkle tree is of course calculated to check everything.

Why this is possible, why it was not possible with proof of work is for proofs take, as we have consensus, we have finality.

Finality allows us to have a limited amount of blocks that we can reorg.

Basic engine is the starting point of the RET.

Engine is the 1 that handles Engine API, that is consensus layer blocks that we receive, and fork choice update that we receive.

It switches between history sync that is in the pipeline and the live sync that is in the tree.

It's basic synchronization point of the node, and it basically requests, if needed, payload building, basically creating new block.

Other module, the second pool is expected.

It's like, it's very complex thing, but most of the devs just expect to work as like, it needs to be DDoS protected, it needs to have like Ordering of the transactions by base fee, priority fee, it needs to have buffer for the non-gaps, everything around that sounds simple, but it was not.

RAM is the EVM, basically that I built 2 years ago.

It is tested, it passes all the theorem test, it is used in Foundry.

This is an APC, Basically standard APC that you expect everywhere.

This looks that's very rough component flow.

Pipeline basically takes blocks from the downloader and fetches from P2P, but the blockchain tree and pipeline touches provider to send right data or your gift needed.

Even with EVM already done, it was very hard to figure out how to do it.

We had a few ideas that was not, when we started implementing it, when we started basically doing it, we figured out that they're not good enough and we needed to switch our path.

There are a few dead ends that we approached and basically reverted back.

We initially started with the pipeline and just wanted to be like pipeline to be the main component that does everything.

Very soon we figure out that we overboarding 1 component of our system and we needed to build multiple ones.

We wanted to basically use pipeline for the finalization and like the using and like integrating pending side blocks, everything around it.

But figure out the 3 and separate components are basically a better option.

We wanted to pipeline to be the main entry of the RET.

Basically, the pipeline starts everything and figure out what needs to be done.

But we move that logic inside the engine.

Even that was very hard to do, that initial sync and everything like that.

We tried to use all the build Merkle tree implementation, but there was a problem having optimized way to merkleize full state and 1 point of time.

We had a lot of memory problems there, so we built our own.

And the biggest insight is basically speed depends on the data, how you access data, how you write data.

It matters a lot if you are just adding data to the table.

You know how block numbers that you receive and just push it.

There is bigger, there is even difference if you are writing randomly and if you are writing a lot of data that is pre-sorted.

Even that can get you like big improvement in the speed.

1 of the things that we started is the section level granularity.

Granularity in the sense that archive node could access history state on the section level.

We initially thought, hey, this is a good idea.

It will slightly increase the database, but it will have better performance.

But after a few research and talk, basically, we had to build that so that the database was not that small.

And we figured out that for the history access, users mostly use providers, everybody that uses that, uses block level indexing, and they even like optimize for the multi-block logs or state accesses.

So we revert that, basically build block level granularity, hashing our database a little bit.

This, On the main, the section was, we have our encoding that compresses a little bit of data, but is encoding.

Smart way how you basically remove zeros.

But for some fields in the section, we introduced a standardized compression.

And it was like 200, 300 gigabyte smaller for the section and around 200, 300 for receipts.

We was very surprised that was this much.

Basically, starting with this sentence, just leaving this sentence was like a big thing.

For the 7, 8 months, we build that client from scratch and we are thinking minute.

Even that is enormous job, enormous success.

Project feels good in the sense that we figure out what module, how they're connecting, we figure out how it's going to work.

There is some bug that we need to squash, but in the way the structure of the project feels very good.

Still, it's not even alpha, to be honest.

We are going to break database a few times.

We are working currently in stabilizing some things, cleaning up some code that we know that can be better.

Either way, it sinks, it is working with consensus layer, everything around that, but so you know database going to break.

We want to consolidate that library that I talk about, to add a little bit more documentation, just to make it a little bit easier for the guys that just want to use some components, just to use it.

And that's a very powerful thing that we can do.

We are open for the feedback, contribution.

I think People don't notice, but working on open source project, I worked from OpenEthereum in 2020 to now, feedback is important.

That's how the community is built, That's how you figure out your next path.

You figure out what's important for the people that use your software.

You can figure out what's the next step for the project.

Other than that, bug reporting and just reporting problems.

It's 1 of the major things how you stabilize the software.

We are around 100 contributors, community is very important.

The basic, The guys that built the foundry and foundry became something special in Ethereum ecosystem are now building RET, and you can expect the same thing that you can find in foundry to find rat.

So the same community feedback, same community outreach, and everything around that.

Hi, so for the initial state sync, is it like Aragon where it downloads the state via BitTorrent?

We are still figuring out how to do that snap-seeking state downloading around that.

Our first intention was like, let's archive sync from the beginning to the end.

After that, we will figure out what's our next step.

We want to consolidate what we are currently having and then talk about, is it going to be BitTorrent?

Maybe is it possible to do it like snapsync that does that get and nethermine does it?

Maybe there is some different ways we can do it, but either way it's now open question But this something that we are probably going in some way to implement in the future.

Yeah, so I quite liked that breath was doing a transaction level state.

Now for replays, it makes life a lot easier.

Is it irrevocable now that you're moving to block level state?

Basically, it was harder to support both of them.

And we figure out, you can still execute total section in the block to get to the state of destruction, but for the history access, the main important thing is like the block level.

You are basically iterating over logs of multiple blocks, you're iterating over the blocks of multiple section, but either way, there will be ability to have like, give me traces of that section.

It will be a little bit longer because you need to execute past section.

But either way, we have fast EVM, we have the state, you can expect performance as the founder has it.

You said you wrote the code from scratch, but didn't you reuse a lot of code from Sputnik VM and Akula?

1 minute drama that unfortunately it happened, but at that point of time, we had like 20% of the code.

It was, I'm not sure, basically, but it seems Twitter just come to the train and just, I'm not sure what happened.

Aragon basically deprecated a lot of things at that point of time.

They removed Polygon, they removed Binance, and they deprecated the client.

And I'm not sure, But it seems that the main developer just wanted to deduce drama.

Basically, that's how the Ergon Turbo gets started.

1 quick question about the, I mean, I also talk with the LaserMinds teams and their developers.

And they told me that, well, I guess it's so popular because more like EF, I mean, Ethereum Foundation is more likely to support them.

So will this case also be a situation for your projects?

I mean, will EF, I mean, they provide limited help for another man, but I mean for this 1 as interesting or they will also provide limited help.

Basically this undertaking is mostly driven by paradigm.

I'm not sure about future Maybe that basically I talk with the Ethereum Foundation.

The guys from Ethereum Foundation are testing the client as a lot of providers.

Basically I was the guy that was on OpenEthereum.

The paradigm is normally the space and they're basically building open source clients.


Speaker 0: Hello, nice. Hello, everybody. My name is Ryan Rakita. I am 1 of the co-developers that I'm building RET. It is modular, contributor-friendly, and basically fast implementation of the Ethereum protocol.

Execution layer, basically. What I want to talk about is basically these 4 things. A little bit of the history, why the new client is important thing, what are we missing currently in the present state? I'll be focused a little bit on the modules, basically what RET is composed of, while they're important for us, while that modularity is important for the new clients. I'll give a little bit of developer insights to just show what basically path that we took, what decisions that we made, and I think talk about a little bit of the current state of the client.

Recent history. Let's start for the present. Diversity in Ethereum ecosystem is very important. In essence, it allows you more security, it decentralises network, it allows basically if there is some potential problem in the 1 client, other client should take over and just move the network forward. But the present state is the get is the majority client that everybody uses.

So if the get has some of the potential consensus bug or something like that, it will break the network, network will stop, and all the client will just report the problem. They couldn't, they don't have any weight to move Ethereum forward. Other things that other clients bring is innovation, it's a little bit experimentation. It provides users and developers new weight to use Ethereum. A little bit history, 2022 is the year that I started working on Ethereum.

In this time, we had to get as even more major Ethereum client and the second biggest 1 was Parity Ethereum. Parity Ethereum at that time basically moved away from Ethereum space and just open sourced their client and renamed it to OpenEthereum. 2021, it's a brilliant hard fork. Here we see fork of the get, named TurboGet, there is Nethermine, Parity renamed to OpenEthereum. London hard fork, around that time, OpenEthereum was deprecated.

It was basically the client that was not well maintained and it basically time got over it. And at that time we decided to deprecate it to not implement merge, basically Parise hard fork. We see Aragon that was renamed for the turbo get fork of the get and see Bessu and then the mine taking traction. Paris was important 1. 2022 people started noticing and basically focusing more on diversity.

And as it was 1 of the major points of the merge, as the merge was 1 waiting, because when you switch consensus, you cannot go back. In that sense, diversity was a little bit more focused. And present, Nethermine, Aragon, and Besu are the major clients, Gett is still the major client. Now we come to the last year, September 2022, Paradigm started building their own client. It's building the Rust.

It uses some ideas from the Aragon. Idea is to have like very modular, very well-made documented client that we hope to, we'll improve the ecosystem and development experience. It's built for us last. Basically modularity is 1 of the major points of us, because we want to be able, if needed, to just rewrite components if they don't perform well enough, or to be able for community users, anybody, just to use components, add their modification and use it with the rest of the system. Cleanup structure, standalone Rust libraries basically allow that hackability of the code and allow for client to be used in different ways.

You want to be flexible and in configuration to support both the archive node and the full node. You're currently supporting only archive node, but we will add full node support. And most importantly, it's MIT Apache license, so anybody can use it. It's like open. I'll focus a little bit on components, what's inside the client.

Database footprint, I wrote here. Database is most important aspect of any Ethereum client, because how you write the database, how you read the database matters a lot in terms of how fast you are thinking, how fast you are doing things. And the database layout is the most impactful thing in the Ethereum client. For the plain state, we are using the Dragon flat key value database. Our archive node is under 2 terabytes.

We are very pleased with that. We'll probably shrink in the future a little bit. There is some idea that we want to implement. We are still a work in progress, and currently we are very satisfied it's under 2 terabytes. Optimization of data, basically, optimization of memory footprint is very important as any byte matters.

For example, 2-bit intersection, if you save cache of the section, it's additional 50 gigabytes, 64, and still the optimization depends on how you read and write data. First module that can be important is provider. Because every terminal and RET including has simple database, fetching data and fetching data in proper order is very hard. You need to know layout of the database, you need to know encoding that's used, you need to know basically where the data is. Provider is the 1 library that's going to wrap that.

It will give you high level abstraction on the low level database access. Basically, it will allow you to fetch 1 block where the block is split into multiple tables. It's just 1 library call. Other than that, it will allow you to have access to the history state without worrying how the state is indexed. 1 good thing is that we can have multiple readers.

And basically, you can run your client, and client will push data, write data to the database. Then you can have another process that's going to just read. And that allows new flexibility. Initial sync with the pipeline with NVMe SSD hard disk is under 2 days. Pipeline is basically used for initial sync.

It's optimized to handle that multi-block execution and multi-block preparation of the execution and localization after that. It's 1 of the idea that is pioneered by Aragon. It's, yeah, we have in our database, we are just saving the canonical chain that allows you a little bit of flexibility where we know that the data and blocks that are inside the main in the database are the canonicalized block. And we just reorg if needed. Pipeline is optimized for the ranges.

Site, penny, block, we have different model that handles that. Pipeline, for example, stages that are inside the pipeline are the header body that are specialized for the fetching of the blocks, headers, basically data that's needed from outside, from the P2P network. There is some sender recovery, total difficulty that they need to realize preparation for the execution. Execution that executes, creates receipts, everything around that. And there is a few stages that do merkelization and history indexing.

And after that, there is the section ID. There is some places that we want to improve. 1 of the things that we could introduce as ETL is to read the right data a little bit differently. But either way, we are very fast even without it. Longest time for execution is, of course, execution.

Interface is 1 of the core libraries. It's basically a list of traits that abstract away components. Basically we implement the trait, specify the trait, and somebody is going to implement it. That allows you very, like, abstract modularity between the libraries. So you can just implement your own trait and just be sure that you comply with the rest of the system.

P2P, downloader module. P2P is 1 of the things that does discovery, management of notes, timeouts and sending, receiving requests from the P2P network. It's 1 of the things that every client obstructed in some way because it's very easy to obstruct it's It allows you to handle peer management in 1 place and don't think about it Downloader is wrapper around P2P it's glue between the rest of the system and P2P module that allows you to download headers, blocks, and full header blocks and bodies, whatever you need. In the future, maybe we switch downloader to not fetch P2P, but the idea is to fetch from some server or something like that. That would be very interesting.

Blockchain tree. It is memory structure that stores validate blocks that are received from the Kostasus layer. It's needed as a separate entity that allows us to have multi-site blocks that can potentially be received. And it does reorganization on the R canonical chain that's database. Merkle tree is of course calculated to check everything.

Why this is possible, why it was not possible with proof of work is for proofs take, as we have consensus, we have finality. Finality allows us to have a limited amount of blocks that we can reorg. In the practice, that is just 1 block. But in the theory, it can be 642 epochs. Engine is the thing that drives the RET.

Basic engine is the starting point of the RET. Engine is the 1 that handles Engine API, that is consensus layer blocks that we receive, and fork choice update that we receive. It switches between history sync that is in the pipeline and the live sync that is in the tree. It's basic synchronization point of the node, and it basically requests, if needed, payload building, basically creating new block. Other module, the second pool is expected.

It's like, it's very complex thing, but most of the devs just expect to work as like, it needs to be DDoS protected, it needs to have like Ordering of the transactions by base fee, priority fee, it needs to have buffer for the non-gaps, everything around that sounds simple, but it was not. RAM is the EVM, basically that I built 2 years ago. It is tested, it passes all the theorem test, it is used in Foundry. This is an APC, Basically standard APC that you expect everywhere. And we have metrics and Prometheus.

This looks that's very rough component flow. This looks something like this. Engine is at the top. It drives 3 pipeline and building. Pipeline basically takes blocks from the downloader and fetches from P2P, but the blockchain tree and pipeline touches provider to send right data or your gift needed.

Development insights. Even with EVM already done, it was very hard to figure out how to do it. We had a few ideas that was not, when we started implementing it, when we started basically doing it, we figured out that they're not good enough and we needed to switch our path. There are a few dead ends that we approached and basically reverted back. We initially started with the pipeline and just wanted to be like pipeline to be the main component that does everything.

Very soon we figure out that we overboarding 1 component of our system and we needed to build multiple ones. We wanted to basically use pipeline for the finalization and like the using and like integrating pending side blocks, everything around it. But figure out the 3 and separate components are basically a better option. We wanted to pipeline to be the main entry of the RET. Basically, the pipeline starts everything and figure out what needs to be done.

But we move that logic inside the engine. So the engine drives everything. Pipeline is there for the initial sync. It's optimized only for 1 thing. Even that was very hard to do, that initial sync and everything like that.

We tried to use all the build Merkle tree implementation, but there was a problem having optimized way to merkleize full state and 1 point of time. We had a lot of memory problems there, so we built our own. And the biggest insight is basically speed depends on the data, how you access data, how you write data. It matters a lot if you are just adding data to the table. You know the order.

You know how block numbers that you receive and just push it. There is bigger, there is even difference if you are writing randomly and if you are writing a lot of data that is pre-sorted. Even that can get you like big improvement in the speed. 1 of the things that we started is the section level granularity. Granularity in the sense that archive node could access history state on the section level.

We initially thought, hey, this is a good idea. It will slightly increase the database, but it will have better performance. But after a few research and talk, basically, we had to build that so that the database was not that small. It became a little bit bigger. And we figured out that for the history access, users mostly use providers, everybody that uses that, uses block level indexing, and they even like optimize for the multi-block logs or state accesses.

So we revert that, basically build block level granularity, hashing our database a little bit. Compression data was fun 1. This, On the main, the section was, we have our encoding that compresses a little bit of data, but is encoding. Smart way how you basically remove zeros. But for some fields in the section, we introduced a standardized compression.

You can look at that PR. And it was like 200, 300 gigabyte smaller for the section and around 200, 300 for receipts. We was very surprised that was this much. Current status, we are sinking minute. Basically, starting with this sentence, just leaving this sentence was like a big thing.

For the 7, 8 months, we build that client from scratch and we are thinking minute. Even that is enormous job, enormous success. Project feels good in the sense that we figure out what module, how they're connecting, we figure out how it's going to work. There is some bug that we need to squash, but in the way the structure of the project feels very good. Still, it's not even alpha, to be honest.

It's pre-alpha, even before that. We are going to break database a few times. We know it. We are working currently in stabilizing some things, cleaning up some code that we know that can be better. Either way, it sinks, it is working with consensus layer, everything around that, but so you know database going to break.

In Broadstrokes, we are there. We want to consolidate that library that I talk about, to add a little bit more documentation, just to make it a little bit easier for the guys that just want to use some components, just to use it. And that's a very powerful thing that we can do. We are open for the feedback, contribution. I think People don't notice, but working on open source project, I worked from OpenEthereum in 2020 to now, feedback is important.

That's how the community is built, That's how you figure out your next path. You figure out what's important for the people that use your software. You can figure out what's the next step for the project. So it's very important. Other than that, bug reporting and just reporting problems.

It's 1 of the major things how you stabilize the software. We are around 100 contributors, community is very important. The basic, The guys that built the foundry and foundry became something special in Ethereum ecosystem are now building RET, and you can expect the same thing that you can find in foundry to find rat. So the same community feedback, same community outreach, and everything around that. The team already knows how to build it.

I think that's it. Thank you for listening. Questions? Questions? Hi, so for the initial state sync, is it like Aragon where it downloads the state via BitTorrent?

Not exactly. We are still figuring out how to do that snap-seeking state downloading around that. Our first intention was like, let's archive sync from the beginning to the end. After that, we will figure out what's our next step. We want to consolidate what we are currently having and then talk about, is it going to be BitTorrent?

Maybe is it possible to do it like snapsync that does that get and nethermine does it? Maybe there is some different ways we can do it, but either way it's now open question But this something that we are probably going in some way to implement in the future. OK, thank you. We have questions here.

Speaker 1: Yeah, so I quite liked that breath was doing a transaction level state. Now for replays, it makes life a lot easier. Is it irrevocable now that you're moving to block level state?

Speaker 0: Yeah, we removed that part. Basically, it was harder to support both of them. And we figure out, you can still execute total section in the block to get to the state of destruction, but for the history access, the main important thing is like the block level. You are basically iterating over logs of multiple blocks, you're iterating over the blocks of multiple section, but either way, there will be ability to have like, give me traces of that section. It will be a little bit longer because you need to execute past section.

But either way, we have fast EVM, we have the state, you can expect performance as the founder has it. Basically, founder does it in some way. Yeah. Question there? All right.

We're left. Depending on.

Speaker 2: Is it working? Yeah.

Speaker 0: Yep.

Speaker 2: Yeah. Thanks for the talk. You said you wrote the code from scratch, but didn't you reuse a lot of code from Sputnik VM and Akula?

Speaker 0: Not exactly. EVM I built 2 years ago. This is not a new component. There was drama, right, that's fun. 1 minute drama that unfortunately it happened, but at that point of time, we had like 20% of the code.

It was, I'm not sure, basically, but it seems Twitter just come to the train and just, I'm not sure what happened. Aragon basically deprecated a lot of things at that point of time. They removed Polygon, they removed Binance, and they deprecated the client. And I'm not sure, But it seems that the main developer just wanted to deduce drama.

Speaker 2: So there's no code?

Speaker 0: Sorry?

Speaker 2: There is some code, or?

Speaker 0: We use MDBX, wrap around it. And I think we use LLP. That's very small part of the code. We are not forking Aquila. Basically, that's how the Ergon Turbo gets started.

We build it from scratch. And It was like, what else to say?

Speaker 2: Thank you.

Speaker 3: 1 quick question about the, I mean, I also talk with the LaserMinds teams and their developers. And they told me that, well, I guess it's so popular because more like EF, I mean, Ethereum Foundation is more likely to support them. So will this case also be a situation for your projects? I mean, will EF, I mean, they provide limited help for another man, but I mean for this 1 as interesting or they will also provide limited help. Yeah

Speaker 0: Basically this undertaking is mostly driven by paradigm. I'm not sure about future Maybe that basically I talk with the Ethereum Foundation. The guys from Ethereum Foundation are testing the client as a lot of providers. We did contact with them. Basically I was the guy that was on OpenEthereum.

The paradigm is normally the space and they're basically building open source clients. You cannot be more

Speaker 2: open

Speaker 0: source

Speaker 3: than

Speaker 0: MIT and Apache. I think that's it. Thank you very much. Thank you. Thank you.

See all ETH Belgrade transcripts on Youtube

Reth: Rust Ethereum client - Dragan Rakita | Paradigm