EPF6 Office Hours | Sina

Awesome. Very well. So yeah, welcome everyone. Welcome Cena. Thank you so much for joining us today.

Um so yeah, it's um week 17. We have another office hours with a special guest today. Uh joined by uh Cena from Gothereum. Over the years we had couple of uh get devs. We had Mario here uh Felix and Matt.

Uh but first time we are joined by Cena. So that's our uh uh get dev uh uh uh chosen for this cohort AMA. Thank you so much for being here and uh um of course it's u uh it's a couple more people now. Awesome. Um so uh thanks much for joining everyone before we get to the questions from the audience having some chat with Cena.

I would like to get some more some more context about you um some more about your background. So please tell us uh what brought you to Ethereum? How have you started in the core development working in EF working on the protocol?

Yeah, sure. Um, so first, uh, hey guys, it's a pleasure to be here. Thanks for inviting Mario. Uh, very nice to talk to you all uh, fellows. My story goes back a few years.

So just for context, I have been working at the EF on Ethereum for six, seven years now. Um been at Go Ethereum for a couple of years. Uh before that I've been working on EOSM and uh the first project that I worked was EthereumJS and that's actually how I got into working on Ethereum. um it was that so I was I guess um 2019 1819 I was doing my master's thesis and well I had a lot of time on my hands I didn't have any lectures anymore and uh it was around the bull market at that time and I started looking into this because I I had been hearing about crypto bitcoin for a a long time and I decided to just learn a bit more about it. Um first um I went a bit into some of the less valid projects uh less legitimate and then found my way to Ethereum.

Oh yeah, but on the way I was it's funny because I was I started working on what was later named Nano project. Um they were claiming that you know we have free transactions. I was like wow that sounds great. Uh who doesn't want free transaction? All these other blockchains they're paid.

You have to pay to use them. And I started using it and it was like always in the back of my mind but isn't it possible to doss the network with this and yeah at some point like I made some contribution and at some point um was asking them all these questions like okay what what's what about DOS? about they um they did a test net and said like yeah we will we will test this now and started spamming the network and of course the network went down and then I was like ah okay there's a reason why uh you have to pay for gas for transactions anyway so that that led me to Ethereum and like immediately I was shocked at how I don't know beautiful the protocol is I guess um it was very nice. It was clear from the get-go that people here really know their game. They they have a vision um and it's there's a lot of like technical richness here and a lot of interesting things to discover.

So I yeah started dabbling a bit. Uh and it's funny because you know it's been 7 years I like in my later years now I have all this experience and I like very rarely do I post something on ETH research and at the time I didn't know anything and I was just as a as a new person I just started posting on ETH research for some reason just anything that I was that I was finding out uh and like I don't know somehow it was I the community was very welcoming um And I I discovered at the time Gitcoin uh which was a project uh like it was a bit of a different iteration of Gitcoin. So they they assign assigned bounties to GitHub issues. So you could solve a ticket or issue and you would get paid for it. And me as a student who didn't have a lot of money, it was like obviously very excited by this.

Uh so I I did one for agnosis safe and one for Ethereumjs and um I mean so like the EthereumJS team they liked my work and they they invited me to to contribute um and so yeah this is this is basically how I joined and yeah I've had a bit of a journey through Ethereum and um uh through the EF but yeah Now I'm here.

Very well. Yeah. Thank you so much, Cena. Um, yeah, it's been um I mean it's uh it's been a quite a journey because a lot of things changed in the protocol and uh over the past couple of years. So the first time I met you like five years ago, you still been in the Basm team.

Uh so what I'm curious about is maybe more if you can elaborate on this like what was the like or how do you know the retrospective like how do you see these efforts uh before the epsilon happened before uh the focus on the the the vasm and uh what was like your u transformation to get like actually how did you get into me to to the team and what was it like to change from from that yeah

yeah I mean for me it was like from the beginning since I joined Ethereums I was like it wasn't was always on my radar And I found it so interesting and I um basically I had it from the get-go that uh when I talked to Hogar the team leader of DMJS I told him like I want to dedicate some of my time to Eism from the beginning and so this is this was the arrangement that we had and I started looking into it and at some point like then fully transitioned uh because like in EtheumJS there was a time when um basically it was There was a time when I was the only person working on it and I was like as a new person in this company I was feeling somewhat lonely. I felt like I needed mentors. I was doing like it was going great but I just felt like okay I want to work in a team and this is how like I started doing more and more on the on the eism side and um and I finally like fully transition to that and I mean the the the vision there was great um like EVM we all know has its quirks it's it's good like now we accepted it I guess uh But it was always that we can do better. We can like it can be faster. This was one of the selling points of ewism.

Um you can write from multiple languages. So you can write Ross and compile it to was this. This was a great selling point at the time and it's just such a standard right like you have was everywhere. You have it in the browser. There's great tooling for it.

There's great interpreters for it. Um but as we like kind of started doing more research into it, we found out that okay yes it has this advantages but actually you can make EVM quite fast. And this is when um when Pavle from Epsilon he wrote an EVM interpreter called EVM1 that turned out to be just as fast as was. Um and then it became a question like okay now if it's not much faster then is it still worth it to switch because you have all these existing applications that are written in EVM and in solidity um and it's very very hard somehow to transpile EVM to wasn't uh so it became this question and like the team then started looking into other things um like phase one and done from Casey like these were the projects like this was before the merge and this was the like ideas like okay what happens after the the merge are we going to have sharding are we going to have like identical shards are we going to have execution engines uh uh I believe execution extensions were called at the time and so we started working on a wasam extension like execution extension for for Ethereum so that in one of the shards you can have wasn't um but yeah like I was always um I always cared about users um and this was kind of lacking for me this feeling was not there that I'm like I'm having a direct impact uh on users like I can I can see it immediately so um this brought me then later on to GU and on that context Mario I so the today in the morning I had an idea uh that maybe I can share something with you guys I that I will prepare a presentation and uh this is not a presentation that I've done before uh so I had to do it from scratch um I had a few meetings today so it wasn't very successful I've made a couple of slides I'm happy to kind of start with that to give a structure. Um, and but you have to be warned because it's very raw and unfinished uh and and janky.

So, if you guys like I can I can share the the slides and

let's do it.

Yeah, seems like people are open to it. Like normally we never do this. This is just a chat. So, I mean, if you want to have a test audience,

stick with your but just

go for it. It's great.

It's it's something that's been on my mind these days a lot, this topic. And um so yeah, um it's helping me personally think through these things and so yeah, the topic that I want to share like let me first uh see how I can do this. Ah, okay. I have to allow sharing.

Can you guys see my screen?

Yes.

Yep.

Perfect. Okay.

Interesting.

Yeah.

Yeah. So, um, this is a bit this is a bit of a new topic for me. Um, but it's been something it's something that I've been thinking about a lot. It's been on my mind and it's basically seeing Ethereum clients uh from the lens of a product. We have all the uh all the software projects that we use they are somehow also products um and they have they are placed in an ecosystem with users and and competition etc.

Uh so I'm trying to in my head map this ecosystem um and think about things like okay features uh users the alternative clients and how they all tie together. Um and I know this is the Ethereum protocol fellowship. I'm aware of that and this might feel a bit adjacent to that. Um, but I actually think it's very important for you guys because you guys are starting in your career of doing Ethereum development. Uh, I've I've seen the projects that you're working on.

They they are very exciting. They are very deep technical stuff uh like implementing Fossil uh parallel execution um ZKVMs. All of these things are like very important things that we we are working on or you guys are working on. Um I think it's important that while we are implementing these things that we think that okay like these improvements that we're making they are not improvements for the protocol sake. Um in the end the protocol is used by people.

It's solving problems. Um I want to you to always keep this in the back of your head. Um what problem is it solving for who and and how? because we do have a history of sometimes shipping uh EIPs that don't gather a lot of usage and I'm thinking of some of the pre-ompiles for example but not necessarily um and it it does apply a lot to to these protocols for example something that has been discussed for a long time uh within Ethereum research community is the concept of stateless clients. And stateless clients are great.

It's a great idea. Um it allows you to sync a node like so fast. Um you wouldn't need a lot of resources like storage. You can basically almost immediately sync up to the head of the chain and then follow the chain. But and I'm and I'm thinking of status here in a general concept like be it vertical but also a ZK verifying node that we'll have in future when we ship ZK on on Ethereum.

So in in the like kind of general concept great now you can sync the chain and follow the head. What can you do with this node? I I always had this question. Um yes this will be useful for some people like stakers but if I cannot do any kind of transaction simulation if I not process a transaction a new transaction that the user sends or any of these things then what exactly is it used for so like it makes us think what does this client this stateless client or this zk client need to do what kind of features that we have to build in in it. Uh so this is the like the thing like this like context is a background.

Now um like Ethereum itself the the protocol it has I think it's offering a few different products and I'm thinking of product in the very general sense. I'm not a technical uh product manager. I don't know that the like the terminology here but we are offering a few things like the first one is a block marketplace to end users. This is they can submit the transactions to send money for example. Um the second one is a blob marketplace to layer 2 mainly.

So we are allowing layer 2s to gain from the security of the main chain. um by submitting these proofs um and a summary of their uh state transition to to the ma to the main chain. But we have this deposit contract. I it's kind of funny to think of it as a product, but I think it is because it's a way for some people stakers to deposit their uh ET and get some yield. Um, so I think it's also kind of a product.

You have EVM. Um, like this is I think one of perhaps Ethereum's most successful products because it's been exported so wide and far. Um, EVM is a product to contract developers and apps. Like the guys who are writing these contracts, they care about EVM, its details, uh, what kind of upgrades are added and so on. like we need to basically keep them in mind when making any changes to the EVM uh and we need to kept keep their pain points in mind and and and improve it accordingly.

So, Ethereum has an asset with sound economics and for some people this is a product. Um, and in the end uh Ethereum clients they run the whole thing, the whole protocol and all of the above. Um but they are or this is my argument they are also a product for their users and um and but okay so what's a product I think that it's only a codebase or protocol implementation it's not only a codebase or protocol but it's a living system that serves users um solve problems competes in a market and must sustain itself over time and yeah so from here on I'm going to focus specifically on clients as products we don't like all these other things that I mentioned where I'm not get get into them I I work on a client team and this is the thing that I care about the most um so yeah let's get into this and by the way uh this is going to be a short one because yeah as I said I run out of time but if at any time you want to ask a question, please feel free to interrupt. And um yeah, so I think the the most important lens uh to look at a client from a product point of view is uh its users. And yeah, it made me think of the famous uh Steve Balmer meme, developers, developers, developers, only users, users, users.

I think it's the key like as you know also for dev connect this year. This is going to be the biggest focus like we care about users. Um same way with um clients we should care about your users like we're not only an implementation of the protocol um nim like Nimbus Gat never mind like these are all these are all products that people are using and depend on uh and so we should be mindful of that here I want to actually open up um and ask you Guys, who do you think are the users of clients and just let's collect the list? I want us to exhaust all the options, all all everything that you can think of when it comes to users of clients. Who could they be?

Any ideas?

Would institutional investors use clients to set up nodes?

Um, Mario, you want to say something?

I use client. I just want to use Ethereum, right? I mean, how how else do I use it without just looking into it, right?

Yeah. I mean, so yeah, like people who are working on on Ethereum, this one Ethereum investors, I I guess that they also use like run their own clients. Sometimes they they somehow indirectly either indirectly rely on a client um or directly run the node itself. Any other ideas? Sorry, what's up?

Uh wallet.

Wallets. Yes, wallets are also as far as I know like mostly indirectly users of a client. I have I have a list uh in the next page um and and we'll get to that. I I put wallet with a question mark because they are somehow the they are a user of the client. They're not directly usually running the client themselves.

But uh maybe with your idea previous idea with stateless uh maybe um like on small smaller device maybe uh it will be good for normal users like not investors and something like that. And and this is a good question like can it can we have the stateless client in such a way that it's embeddible in the in the wallet and I think with the current idea it's not sufficient. I'm happy to discuss this more because um a stateless client does not have the it's not doesn't keep the whole state and wallets need the state. They need to know the balance of the user. They need to know its history of transactions.

So um what has the done like the user done in the last 5 years? Uh what are the all the token transfers um they've done and things like this in in the current form of status client. I think this is not possible. So we have to make changes to them. So to allow uh wallets to run an embedded stateless client.

Uh I heard about execution witnesses. So I would like to to hear your opinion after after your slide about that.

Yeah. Um I mean execution witnesses. So they what they give you is basically um the state that you need to run one block but it can be that let's say I've I have a wallet uh I haven't used in five years and I want to transact with it now. um how do I see the history like how do I know what's the balance of this account if my node has never like in the execution witness I can only see like since the node started syncing so let's say I sync my node now uh and start receiving the this execution witnesses it doesn't touch my account because it wasn't used in the last blocks

but will you be able to prove the balance in a recent block. So you kind of know the the actual balance.

Yeah, exactly. So you would need to receive a proof from someone and who made that someone. So will you have to ask for a provider um to to give you this proof? Yes, probably. Like right now it sounds like um I will need to like the node is able to verify a proof

because it knows the correct state route. So this is important.

It knows the correct state route and it will be able to verify a proof. The question is that is it efficient enough because let's yes for if I only want to know a transfer then um I can get a proof for my balance and then I know I have enough balance to do the transfer. But if I want to do a unis swap transaction then it involves so many contracts and storage accesses like just downloading all of these proofs individually. Um yeah it's it's a different story especially because you don't know in advance uh all of the things that you will need. you need to start the transaction uh processing and you will know first like okay now I need the storage to be able to go further in the EVM execution you have to request that and then they will give you some data and then you're like okay now I need this account so you have to request another one it's you cannot do batch retrieval even and because of this it's really not that efficient but I think it's currently the the only option actually.

Thank you.

Um yeah, any other users?

I think uh like RPCs and builders providers or

Yes. Yes. Actually builders is a good point. I didn't include it in my list. So something that I can add now.

Um, yeah, RPC providers like Infuro Alchemy,

layer twos.

Yeah, layer 2 is a is a funny one. I also have it in my list um as um as a not so straightforward case. Let we I will get into it on the next slide. Okay, if there's no other um I'm going to show you here my list and I have two categories. The more straightforward kind of users, the less straightforward kind of users.

The first one is cipher punk end users. And this I'm also including Mario in this list because he just wants to run his own node for interacting with Ethereum. For him it's important. Um then we have stapler funny like nobody actually mentioned st but they big uh big you um use case category alchemy and fura are like RPC providers these guys are running nodes in scale they have so many different kinds of nodes they have different clients uh from GU nethermind different combinations and many of them then you have um ether scan dune the graph uh they are the if I want to put a category name into them it's the data indexers they will extract all the visible blockchain data from the clients um make their own database from it and then serve users with a either UI or a query language um in yeah so Another one is um MEF hunters or MEF searchers as mostly people call them. Um these guys also run usually themselves run clients and they they try to find opportunities.

They they try to test simulations uh using the client themselves. There is um exchanges. So this goes somewhat to the enterprise investor uh that somebody mentioned uh like exchanges I believe run their own clients uh to be sure and because they have to do a lot of operations like moving funds around and so on and also knowing the the the head of the chain the the finalization points and and if I was running an exchange I would not trust a RPC provider rather I would run my own node. Now the less straightforward kind of users and the first one I have is layer twos and the reason why I mention this like bit less straightforward is that yes they are using the clients in a direct way in which they post their blobs um and like you use it in the sense of a normal user by submitting transactions right so it's a it's a normal transaction that has a blog that updates their main contract, but they are also in a way users of the clients because they are forking the L1 client usually, not always. And so we have things like opra um we have arbitum nitro uh well actually nitro is not exactly like a fork of of existing clients.

It's a one from scratch. But yeah, OP Wrath, OP GU, um, and Bore from Polygon, it's also fork of GU and, um, Gnosis, uh, Nethermind, and they, they are all basically, yeah, forking, um, the the main clients, the like L1 clients, and they can be conceived of as users in some ways because they are consuming this product uh the code at least we have private networks as so it's related to layer 2 but yeah private networks this one is I put the skull emoji here because at least in get and I know in some other clients it's a dead use case we do not support private networks anymore directly in and I mean like protocols like click because click was a proof of authority uh protocol. So it allowed you to define a set of people who are authorized to make blocks. This is not supported anymore. We drop support like get is a posos only uh client and poss by definition is open.

So it's permissionless. it's not private. Um, then we have projects that are using the client code as a library. So, a bit of a difference there to how layer 2 use it, they just import our code and use it to run. So for example, if someone wants to do EVM execution but they don't want to do it as part of the client or using it called RPC then they can import the revm from RAT and process a call using EVM.

um wallets we have with a question mark. We already talked about this and this last one I don't know I just had this thought like GitHub contributors because for us it's such an issue now we have people on our GitHub who are literally like they only try to contribute somehow which is super nice but it can be anything like sometimes not very meaningful PRs so that um I think their only goal is to form commits and and earn air drops but Yeah, they are also somehow we have to deal with them. These they are also people that we have to deal with on a daily basis. And I and I kind of mention it now because it's a bit of a challenge for us. Um with AI, it's now super easy to spin up new PRs.

Um so yeah, much easier to write the code than to review it. Uh this is actually one of the biggest bottlenecks in G is the review capacity. Like writing code is much more easier than than reviewing it. Not not everyone can do that. So yeah, I I hope that yeah, we can add builders to this list.

Um I hope that that kind of paints a picture of uh of clients and who uses them. And and as you can see, it's like a rich tapestry, many different kinds um with different needs. And so then the next question is what are these people's needs? Like what do they care about? Um and so I think that for the first kind cyer punk end users, they care about self-sity.

So they they want to run their own thing uh to be able to sure that nobody is changing anything. You know that when you use the RPC provider like Alchemy, the result is not uh verifiable. They can when you do a ETH call, they can just they return you an answer like five and then you just have to take their word for it. Um but I definitely know users who run their own clients just to know that it's correct. Um for for these people I assume that efficiency is also important because as an end user if I want to run a client then I I often don't have a big machine to uh to do this on or I would not want to spend a fortune to be able to run my own node.

Before it was possible to run Ethereum on your laptop. I've done this in fact. But nowadays, yeah, it's a bit more tricky. Um, for stakers, the most important thing is that they don't want to lose their stake. So, it's very important that uh the client imple is implemented correctly.

It's it follows the protocol um and that it's secure. So the key cannot be linked somehow. When it comes to providers, they care about performance because they are running so many nodes. The heavier the node is, the higher their cost. So they they're trying to they these guys are low margin um operators.

So shaving anything from performance then it gives them a bigger margin. The other thing important thing is spec compliance. This something that providers often complain about because um some clients implements this RPC method a bit differently to this other client and they have to deal with this because they have to return the same thing to the user in the end. um data indexers they as I said before so they run the client and to be able to extract everything they need from it in terms of data and then put it on a database somewhere um so they need yeah the the speed of extraction they need methods that allow them to do this as fast as possible and they need features that support it. So they need detailed like traceabilities.

They they want to know exactly what have done this transaction, which upgrades were executed. Uh for MAF hunters, it's simulation features and mele connectivity. Um they want to know as soon as a transaction appears in the me pool. So they often ask questions like yeah, how can I increase the capacity of my mele? how can I be connected to more peers so that they receive the transaction pending transactions faster?

And then they they need features that allow them to analyze um this transaction quickly and then see if they can find the opportunity in it and they need it to be fast. So this is what they need for exchanges. It's stability and security. Basically, they need something that doesn't change and secure as possible. It just needed to work.

Um, yeah, I have I have uh also some things for the less straightforward kind of users. Um, so we have um I can think of something. So for I can maybe try to give more examples so that it's not so dry. um wallets they need API features something that we were discussing with wallets for example recently is that um when they when they see like when you're using an app uh and you try to do the transaction then if you've noticed then they try to simulate it and then show you what's going to happen like they can show you that you will transfer so much ether you will transfer this token like all of the consequences of your transaction they try to show it in the wallet UI which is super useful for the user of course but it's kind of tricky to do this actually um using the current API so uh we worked on something called it simulate which is it's like eth call but on steroids it's um it lets you simulate create whole blocks and allow you to customize it a lot more. So, we asked MetaMask, do you guys can you guys benefit from this?

Um and they were like yes we definitely need this but it doesn't solve one of the issues which is gas estimation because not only they need to simulate those transactions but they also need to be able to estimate how much each of these uh takes in gas and for that they are using these super complicated um API methods like tracing methods and they run it so many times like it's when they showed me the code it is horrible um because they don't have a good way to kind of fulfill this need. So they need API features. Um for one uh projects using client code as library they need a stable API. They usually don't want the API to change a lot. Uh they need backwards compatibility and layer 2 they like one of the things they need they need access to the teams specifically when it comes to security issues.

So we have amazing list um where some of these layer tools are signed up and when we when we see a a security issue that can affect them then we try to inform them. So for them this is a need. Um another one is they need often rollup specific features. So these are features that doesn't really benefit Ethereum users uh but they need it and it's a big question right now for um for like layer 1 clients how to handle these kind of requests because yeah it's it will be code that we ourselves will not be using um so it's a bit more tricky I know this was a bit dense um I want to give you has a chance to ask if there's any questions while I drink a bit of a a sip of water. Okay, folks.

The AMA part is finally here. Please ask if you have any thoughts. And

okay, thank you. H I think the presentation is great. H yes in this one I think that all the users h wants some well all the user follow the same some of there are features that are common to all the user like efficiency performance and stability for example

and the other for the one you mentioned for the cyber cipher banks uh for for Sure they want self sovereignity ster security. So I think that you could say that everybody wants efficiency, security and performance and on top of that each of these one type of user wants some some other yes um 100% agree I to I try to bring the differentiating factor because I want to paint this picture that there are different users and they care about different things. But of course, if the client sync time is reduced, then everybody can benefit from it.

If you can sync in one hour instead of one day, then um yeah, what's not to like about that?

Yeah. But for example, in the sters side, I I think that all the stakers want to sync the fastest in less than a day.

I mean, I don't know about that. Um why why would you need to sync because you sync once and then you

well if you don't have redundancy and you your node goes down maybe you you have to be fast.

Yeah I mean uh I yes I am running a validator and I rarely have to touch it. Yeah,

luckily. Yeah,

it can happen that on a on um occasion like for I might need to if something goes wrong then of course sync time will matter a lot

because I might have to reync a note. Uh but it this happens very rarely for me. So I would say that as a staker what I care most about is that I don't lose my funds. it's not slash and um you can say like performance maybe because it goes to the attestation rate so I want to have a high testration rate um and so it means that it needs to have a good performance as well

yeah hi uh I had a question like this is the same like I had asked you on Twitter so like uh with the state growth that's occurring And let's say when we scale to let's say 400 million blocks or like we increase the block limit like eat get logs or like something like eat get proofs get stuck. So like what do you think would be the solution to that because like we are working on that like we will we are trying to get a dev with three clients up for 7745 but like how what do you think would be the good answer to state growth and also providing ETH get proofs for let's say a very high gas limit blocks

I mean this this is the golden question if you can answer this then um I think that state growth you rightly mentioned mentioned that state growth is a big issue. Um get proof is a big issue. I think that the some of them are under investigated or let's say now um there is a big effort the state effort to kind of find the bottlenecks and what happens when the state is quite large and larger. Um I don't I don't have answers to that. I think that I just know that um it's very important.

We have a lot of different like we hear it from different places because we always thought that it's something for the future but what I can tell you guys that it's not for the future. It's here already. We have to deal with it because um we sat down with people from Bass and with people from Arbitum recently and um they are having big issues because their network like they have such a high gas limit and such high demand. So the sizes of their nodes has exploded. Um I recently saw that ref had to so as you know like ref archive runs around two terabytes on mainet and they had a limit on their database size for 8 terabytes and bass already broke that.

So like rest had to remove this limit of 8 terabytes because yeah like the base and worldcoin um nodes they were already hitting that and so it's at least four times bigger than mainet um and we we also saw this with um with guest nodes. So yeah basically these guys were telling us that the the GU archive node on base is more than 40 terabytes. Um, and this is from a few months ago. I'm sure that it's above 50 now. Um, maybe a bit more.

And when you have sizes like that, first it's operation issue. So it's like how the hell do you run at such a node and with a replication even um and then second is that it does a lot to the node performance like they um they they were reporting that node has slowed down it's like sometimes it has these jumps in response time um and they need to run archive nodes because they need the proofs Um so it's it's big. So I can I can tell you that from the guest side how we're thinking about it is that for now we uh we also implemented the alternative archive mode. So we call it the pathbased archive mode which is very lightweight. It's around two terabytes and it can serve historical state but not historical proof.

Um but we know that a lot of people really need the proofs get proof. So we are working on a feature that allows you to customize how long you keep the proofs for. So you can say that I need the proofs for the last month and customize your note so that it can keep the proofs for the last month. And with this approach we think that um yeah it will become much easier to run these nodes to run around the archive nodes. Um it will require much less storage and also it will help with the performance because uh how path based archive works is that you don't keep everything in the key value database.

So like as you know get has running on level DB or patch of level DB called pebble DB. Um and this database uh when it grows in size then it becomes also slower because the underlying database uses a tri like a tree to to index the keys. Um so we what we do is basically in the pathbased archive mode we put um the historical state and proof on a flat file and it means that it can scale much better without losing performance. So yeah it's this is something that we're working on right now like we um and we plan to test it soon in the next two three months. Um yeah the how to solve state growth some variant of state expiry I think uh how it will look like I don't know

yes

uh you mentioned that there is a better solution for the large uh data set uh the a better solution of the database for the large data that is that part clear?

Yeah. So, uh what I was saying that is that in G you have two databases. One is the key value database. Um this is keeping all of the states. Um and we have the freezer database.

It's the freezer database is just a list of files and it's very efficient. So it has 01 access read and write. It's because it's append only. You just append to a file and then there's an index that you can directly look up where to go to. Uh so it's very fast and we developed this for history.

So basically for blocks, receipts, transactions, data like this. But it turns out that we can also use it for state history. So if you put if you format previous states in terms of um append only structure so per block state diff if you format it like this then you can use the freezer format and it has 01 access so it's it's faster. Uh but I I do want to mention here something. Um because there has been recently like for the longest time there was no big improvements in terms of the database.

Now some teams are looking at this and there was a while ago there was a call about it. Um was it a month ago or so? But basically what what happens is that yeah trying to find um so I forgot this company's name but anyway they developed something called QMDB it's um efficient database um well it's more of a database I think it's like a state try plus database so it's really an alternative to the Merkel Patricia tree But um but if we do it then it's like access to to the state will be much faster and you can also do historical proofs. So it's a nice structure but for that you need to change the it's a consensus change right so you need to change the the try format and I think it's a much harder change but what I'm excited about is that now like some teams started looking into implementing uh new databases um like key value databases and this includes uh something called try DB from base team um let me see if I can find Yes, here I can post it in the chat. So, basically did work.

Um, I don't know why I can see it in the chat. Anyhow, it's like GitHub base/try DB

and um it's a key value database that's kind of uh switchable from level DB and it as far as I know I I haven't looked into details of it but it uh batches uh some leaves together and stores them in such a way that then access is more efficient because in the end when you look at it like uh The leaves in the Ethereum try they are very small. So like for each account is I think around uh 60 or maybe 80 80 bytes. Um and each storage leaf is 32 bytes. So they are super small. Um and if you if you manage to batch a few of them together then it becomes um you can you can have better locality caching.

So a few relevant things together uh it seems like they are getting basically some speed up. So like what I'm excited to see is uh like some experimentation done on these kind of new database formats and we're start starting to see some

Yeah. Thanks We are we are at the full hour here. So we should be slowly wrapping up but I want to give you guys a chance to maybe ask more questions or sign up for you to finish.

I I it's okay. I can uh I can I don't have a lot more anyway. It's like not a lot. I think this is as far as I go.

Um yeah. Sorry guys. This was a bit raw this presentation. Um, but I'm really glad that I could share it with you. Um, but yeah, I mean I'm I'm here if you have some question for maybe another five minutes or so, but then I'd have to leave.

What is uh what are your intentions for this presentation? Are you intending to show it to guests, show it to the EF, present it generally on ACD? What what's the intention here?

Uh, I think it was just a way for me to jot down these thoughts. Uh it also ties together with um something that I've been involved in uh recently which is the ETH client summit. So um my intention is to or our intention is to bring together uh different Ethereum clients uh like the the client developers and and their users together. And I think that this is a forum that has not happened before. And I think it's quite important like because right now you might not believe it but the the most common communication channel between client developers and their users is the GitHub issues and GitHub PRs which is really I think low bandwidth.

Um so yeah we hope to have everybody in the same room around Devcon connect uh in the dev connect week and yeah because of this I've been thinking a lot like okay who are the users of clients what are the needs um and what we want to surface is basically their pain points like what are the issues they're facing and I have a lot of examples right now just from conversation that I've been having with these users as I've been inviting them um which is I think very insightful for me because the a lot of these issues these guys are having I like we didn't know about them. Um so yeah, I'm hoping that at some point I can maybe um add some of their pain points to this presentation later on and then um share it somewhere. Yeah, that's really cool. Um, thanks, Cena. Yeah.

Um, folks, do you have any any thoughts? Any let's uh use some extra space for maybe more questions um about the presentation or get or or anything? Uh Lee,

uh I remember you also mentioned Pebble DB. I'm wondering what's that?

Oh, Pebble DB is it's a key value database that is embedded. Uh so it's written in Golang. Uh we can use it as a library. This is the good thing about it. So if you think about other um possible databases like key value databases um like I don't know radius or something they are external they have their own process um pebbled is something that is embedded in like it's a library you can use um and you just need to point it to a directory and then it will keep its files and data um and yeah the interface it has is like just get put get key put key and value uh very simple so it doesn't have a query language in this sense and it's what actually most of the clients are using a database like this it's just that some are using level DB some are using MD XBX um and different implementations basically but

yeah Great. Thanks a lot.

Yeah, I guess something else I could mention is like Pebble DB was developed by the team by by the team behind uh Cockroach DB. So that's the parent uh company and they developed Pebble DB uh to use it internally and then they they're also sharing it as open source so that we can also benefit from it. Yeah, thank you. Um, lot of database back ends there. Uh, the clients folks, do you have anything else that wasn't clear or you want to ask Cena before we wrap up?

Um I'm I'm sure you will have a chance to meet Cena in Bueras.

Yes. Also available on Telegram, Discord if you want to shoot a message. Happy to take questions. Um anything around G or generally your clients. All right.

[Music] [Applause] Cool. Okay, I guess we can we can wrap it up here. So, yeah, thank you so much Cena. It was unexpected presentation, but it was great. Yeah,

I know that the fellows good to meet you and uh I'll learn something new. Um definitely very interesting point of view. We can

we can chat about that more more later and well in Argentina. Looking forward to that.

Yep. I love that.

Awesome. So, yeah, thank you so much for everyone and um I'm looking forward to uh continue this later. Um have a great day.

Thanks a lot.

Thanks for your time, guys. away.