Advaita Saha - Shrink Your Node The Small Footprint Nimbus Execution Client

Transcript

Hey hey hey hey hey hey hey hey everyone. Uh so I am Adita and I'm been working for one and a half years with Nimbus uh primarily on the execution client which uh which this presentation or today we're talking about and let's see let's see what we have achieved and from where are we exactly coming from [snorts] uh Nimbus as Nimbus it has always been at our ethos to create clients which we can run on any low powered devices or anyone doesn't need an extremely extensive hardware for it to run and we have been

quite a bit building on this but it's not really easy it's an definitely an engineering challenge that we are trying to achieve here so yeah uh this presentation is kind of going to be divided into three parts from the past, from where we are coming from and what we are currently offering and in the future what we plan to. Definitely the future is much more interesting but just bear with me for the past and the present.

Yeah. Uh so in 2019 we uh conceptualized like uh creating Nimbus and writing the execution on the consensus client. In 2020 it was the first release of the Nimbus consensus client. We were one of the first like been there from the genesis and it it's been some time uh on the consens execution client work but in 2025 September we launched our first alpha and it features uh low storage requirement lesser dependence on the B2B layer on def and it also comes with Nimus verified proxy which uh we're going to discuss later.

Then in October we also did uh release the proof of concept single binary which packs all three parts of a node which is the execution client the beacon node the validator client and it also packs something uh which is known as e sync from cl uh it doesn't need need to rely on the P2P network completely later like I'm going to elaborate on that later. So what we are offering today we have all the separate parts like Nimbus consensus client Nimbus verified web3 proxy like if you don't want to trust the RPC that you are using just use this one uh in in the between and you are

pretty safe. Now we have the Nimbus execution client and the Nimbus single binary. This presentation mostly would be on the uh later two Nimbus execution client and the single binary. So what as the execution client we are offering we are offering uh a very minimal set uh of requirements so that you can anyone can run our own and to emphasize on anyone like anyone maybe with a Raspberry Pi and uh NVME storage can just uh do it. We were just talking with Pybox and uh it seems like we can get it get it go going there. uh uh but yeah bad instrument at the left connect

venue we couldn't uh prepare the demo we are also providing different storage modes so that you don't need to bloat up your storage uh it comes with really low minimum storage requirement how we are doing that coming to that uh on the next slide and it also comes with a single binary package a lot of uh like you need to run an E a CL uh and the CL comes with a BN and a VC uh we just don't want like solo stakers to be doing that. Uh I'm a lazy person and I would be just happy to running a single binary and it takes care of everything.

So with the Nimbus execution client you can just run an execution uh node with 200 gigs of disk space uh which is just crazy. How we're doing this? It is just aggressive history expiry. uh but since uh as a full-fledged EL client we have to offer uh lot more we have the options of different types of uh storage that you want to select from. If you just want to keep the state and want to uh maybe use the RPC to fetch the balances of the accounts then just use the states. It's way but it's a custom setting. We don't ship with it. uh you just have to pass the flags to make it

run like that. The default mode would be the six months of blocks and receipts which gives us around 200 gigs including the uh state. So this would be pretty good to go with everyone like you can connect wallets to it. You can use it as a private RPC, you can uh connect it to the C uh CL and do pretty much everything. Then the next one which is like more the status quo postmerge blocks and receives plus state uh right now it's optional for us to uh store blocks the premerge.

So yeah and obviously you can run keep the full history or something which you offer is selective blocks or receipts maybe uh if you are using Nimbus E as the back end for uh wallet maybe you want to just keep the receipts not the blocks. So sure we also have that option. Yeah. Uh so why do we need a private RPC or why this lower storage requirement? anyone uh or any HNI with a meaningful uh wallet balance wouldn't like to trust Infura or any other publicly available RPC because yeah you can just get uh hacked, scammed or maybe your

transaction is altered on the way and you are shown something different. Yeah, I would want anyone to trust that. just run the Nimbus CL and it comes you can run the Nimbus CL and the Nimbus light line. Light line just takes no space at all and uh you can just connect the wallet to the Nimbus CL. You should be good to go with 200 gigs of space. Anyone pretty much uh with a meaningful wallet balance would be happy to spend $300 for this. And you can just also do it on a Pi box, Raspberry Pi, and uh get it done. So yeah that's kind of uh running Nimber Nimbus on low powered devices

and then comes the single binary so we always wanted uh Ethereum should be a very simple experience shouldn't be too much complicated um we tried to work on this for quite some time and now finally we have the single binary and it actually opens up a lot of options for us to explore. Uh we are going to come to that one by one but let's first explore how it looks and how the interfaces of the single binary.

Yeah. Uh so this is like a uh screenshot of uh the Nimbus single binary running on hoodie and you can see it starts up both the EL and the CL and it is uh uh communicating properly syncing it doesn't need any kind of external uh setup it's just as simple as you just pass network data you are good to go like live a happy life so uh are we restricted to only running Nimbus uh CL and E together? Not really. If you want to run it as a single binary, you can do it like pass the network data, it should run. If you want to only run the

execution client, be happy. We also have that option. Nimbus beacon node comes with the CL and the VC together. So you can also select that. And this is the interface that we are trying to expand on and also include later the light line uh in this interface so that [snorts] uh people don't need to check for different releases. It's just one thing you just download. You have all the options available. If you want as a node operator want to run separately feel free to do so.

Yeah. So what does the single binary opens the doorway to? It's it's like uh uh like as Nimbus we come under if and one of the projects initially uh was like the status application and we wanted a private RPC node behind our application as we don't want to trust any external guys or uh it it needs to be independent for to be truly decentralized. So yeah you can spawn an Ethereum client to any other application which maybe needs it.

Second, have a private RPC in your local machine. Don't depend on anyone. I don't like to trust anyone. And reduce dependency on the P2P sync like the def P2P layer. Uh how are we doing that is like when it is a single binary, we have complete control over the database. The CL has also the history. So if we want to sync the EL from the CL database, it is quite possible in inside the single binary. we just import blocks from the CL DB and process it. So what's the future? The future that we want to move forward to is like a more harmonious approach towards Ethereum clients is like a

shared database between the EL and the CL. Uh right now if the E is storing six months of history and the CL is storing six months of history, it's just redundant. We don't want to waste storage space like that. So with the complete uh shared database, we want to keep a separate history database inside the single binary which will be used both by the CL and the EL and no redundancy at all. It can also use the ERA 1 and ERA files to sync. So if this question comes up like what we are not storing history for that long u it might be

a problem but no you have the era one era files and also the nimbus execution client can sync from both era 1 and files which is like a very nice feature. Uh history network is also another solution that we have been aggressively exploring. uh it's it's uh not there yet but yeah we are fully exploring all the options of reducing storage and relying on a separate history network. So yeah, pretty much this is like how the shared block database would be communicating with the EL and the CL and the goal would be to reduce a little bit

dependency on the DEF P2P and make the whole overall package a lot more stable. Yeah. So are anyone any one of you guys running Nimbus? If not, just try it out. uh it's it's you don't have to spend a lot on the storage. Uh the performance is good and we are always there to help you. So yeah, if is anyone running Nimbus CL should try out the single binary and the execution client. Uh it's an alpha the execution client. So uh that's the disclaimer but yeah moving uh planning for the beta release in the first quarter of 2026 and open to all of

your suggestions and uh whatever your feedback are always there to fix uh any issues or include new features. Yeah, thank you and uh please join the Nimbus community uh for any suggestions. [applause] Excellent. We do have about five minutes for questions here. Are there any questions? >> So, forgive me if I'm not um not familiar with Nimbus. How does it handle MUV?

>> Uh as in like >> external is that an external running the program? >> Yeah. Yeah. uh like what what exactly uh do you want to understand from the handling me point like from the single binary package or >> the single is it so we have to run MUV on a separate >> no no the single binary as of now don't uh support that >> doesn't support it okay >> yeah but if you're running the single binary as a separate one like execution and CL you obviously can't integrate it >> okay >> let me just ask a follow-up question on that so if we use the binary. We can't add a sidecar like me [clears throat] boost or mev commit.

>> Not not as of now. >> Not as of now. >> But yeah, in future for sure. >> Okay. Excellent. Couple questions over here on this side. Let me get the gentleman in the front row first and then off to you. Question. >> Uh will it run on Raspberry Pi? >> What will it run on Raspberry Pi computer? >> Yes. Yes, it should. Yes. >> Same line of question. curious about CPU uh benches comparing single binary between running the two execution layer consensus layer. >> Yes. So we we don't have the metrics of uh like CPU performance for single binary because we just uh did it before dev connect but yeah for E and the uh CL is obviously it's available uh maybe come to the Nimbus booth we'll happy to

share and discuss. Yeah, >> this is a question from uh YouTube from toio. He's asking any plans to support quick. >> Yes, it's uh again it's dependent on uh the whole Ethereum. It's not that we are supporting it but yeah uh we are very happy to integrate it and we're looking forward. >> Thank you. >> Lots of questions still coming in here. >> Thank you. Uh so if I'm understanding correctly uh with the sixmonth expiry uh you because that's not part of the the full node specification it would be technically called like a light client.

Uh how does that compare to other light clients like Helios or I'm not very familiar with the space. Uh um yeah I'm not very much famili familiar with uh exactly like what under the hood Helios does but uh uh I'm not sure if it's a full frag execution client which stores the complete state and it can uh validate blocks and everything but uh >> oh yeah that that it maybe doesn't execute the full state transition. Yeah, maybe.

>> Okay, >> just quickly, someone someone asked whether you can run it on a Raspberry Pi. Have you have you guys run this on a Raspberry Pi on mainet? >> Uh the not the single binary yet, but the execution client. Yes. >> Okay. Thanks. >> Uh quick question. You mentioned the CL sync thing. So, uh you can sync the EL using the CL. So doesn't that still require the EL state to sort of bootstrap adding the execution payloads or how exactly are you doing it just with the blocks if you're checkpoint syncing it?

>> Oh yeah, if it's checkpoint synced we we can't because the whole history is not >> so you have to sync from genesis in order to be able to do that. >> Yes, but for what we are planning to do is like we are not uh completely relying on the CL for that sync. It's like for the short distance when the EL might be falling out of sync for maybe some other reasons or it is trying to catch up with the CL because of maybe some non-finality happened in the network. It can just use the CL's database. You don't need to uh connect to uh peers and uh completely depend on that. >> Okay. Excellent.

>> Excellent. Let me know if we have uh any other questions in the room. I I did have two since I'm not seeing any hands up here. I guess um one of those is just maybe retrospectively if you if you look back right I get the history of Ethereum between uh proof of stake and proof of work and the execution clients and now there's what three or four different types of clients depending five how you want to count right execution consensus validator uh you got some sidecars of the mev boost or mev commit you've got your slasher if you want to run that um I mean if you were to look back as a core dev here would you would you have designed it that way modularized or would you have created a single binary a single execution? I mean looking back I I would obviously do a single binary but

uh since Ethereum is eternally evolving I think this was bound to happen like we are changing specs we are trying to improve we are trying to adopt every new stop uh that is making us future proof uh doing that the separation is kind of was bound to happen and it is kind of better in the development process but that doesn't mean that we shouldn't have a single binary option which makes the life of solo stickers easier. >> Absolutely. And then let me ask you one second followup on that last statement which is you mentioned that you're in alpha ready to go to beta. Are are you just recommending that on the test nets or on mainet or just as a node but not a validating node like what are you

recommending? >> Yeah, you can run it as a node but not uh as a validator because it's alpha. Uh you can use it for its RPC. You can uh use it on test net full-fledgedly. So yeah, feel free to do so. >> Okay. Any last questions for it? All right. Well, please give a big round of applause here for [applause]