Run Your Own Ethereum Node in One Command: The BuidlGuidl Client - BuidlGuidl's Builder Bootcamp

Transcript

Well, hello. Uh, I'm Spencer from Bill  Bidd. Uh I'm I'm going to be talking about something a little bit different  and uh it's a project we've been working on called the Bidd client which is a  super easy way to run your own node at home with one simple command. And fair  warning I'm scheduled for an hour but uh I have a feeling we're going to be getting  an early lunch. So don't hold that against me. So some basics on nodes. Why nodes? Why do we  care? Uh I essentially nodes are what's forming the backbone of the Ethereum system. That's  what allows us to do all this cool new tech.

Allows us to travel to all these places, call  it work. Um but essentially what a node is is it's a computer running a pair of specialized  software packages which are called execution and consensus clients. We'll get into that a  little bit more about that real soon here. Uh, and nodes are great because each contains  a full verified copy of the chain. So, it's trustless. You have it right with you. You  don't need to take anyone else's word for it. Uh, nodes are responsible for doing the computing.  Essentially, they're executing transactions and powering smart contract logic. And nodes  are also responsible for coordinating between themselves to ensure that the we have a good  chain integrity and that no one is in control.

So real basics about execution clients. These  are the programs that are essentially handling computation for the chain. Uh they're the ones  doing the the transactions and smart contracts. They're responsible for putting together  new blocks and applying state transitions. And this is the this is the software that's  basically managing Ethereum state the the balances, contracts, storage, logs, all sorts of  other cool stuff in the chain. And and for and for developers, uh they're the way that you can  interact with the chain. So you get that with a through a remote procedural call endpoint. And so  there's there's many execution clients out there.

uh some of them more popular ones including  GE, Nethermind, Ref, Basu and Aragon. And then the other half of the the paired software  package is called the consensus client. And this these clients are more they're more  responsible for handling the coordination um coordination both to the execution client  because the consensus client is communicating with the execution client to tell about blocks  state transit and train state transitions and then consensus clients are also communicating to other  nodes consensus clients to ensure that the that everyone is following ong the same chain. Um, and  optionally you can set up your consensus client if

you have, you know, 32 ETH laying around. This  is uh this is the way that you can uh stake 32 ETH and and earn rewards for performing validator  duties, which are basically creating block block proposals when your turns up and attesting  to other other validators block proposals. But for the nodes we're talking about here, uh I  guess you call that a validator client. Uh nodes that I'm interested in are are nonvalidating  clients. We'll get into that a little bit. They're great though because requires no pile  of ETH and you you still get you still get the benefit of of being a good ETH citizen and  contributing to the chain, contributing to to the integrity and also get your your own RPC endpoint  which is uh what a lot of us are interested in

and some of the the common consensus clients out  there Prism, Teu, Lighthouse, Nimbus and Grandine Uh so this brings us to the Bidd client which is  not the best name uh because technically this is not a not a client. It's not that fancy. Um it's  really a a Node.js project. It's a wrapper script for running a pair of clients and it makes  it a lot easier to install, configure, run, and monitor your own validating node. There's a a  small screenshot of the of this uh dashboard view you get when you're running your build go client  and uh I'll pull it up in a second here. But yeah, as far as installing, it's uh kind of took  inspiration from homebrew and it installs

with a oneline command which looks at your  dependencies, installs those that you need, pulls down the clients, spins everything up.  And one of the one of the kind of sticky points of setting up your own node is the startup  configurations for these nodes can be a little complex. Guides are a little bit over the place.  So when you're doing it for yourself, you sort of get into get into this thing where you're almost  guessing and checking. H looks like it's working, it's not. Go back, reync. Um so the build go  client comes with uh preconfigured um startup options for the for the consensus and execution  clients. Uh just a a few command line flags you

can put in for some common things you'd want to  change. But since it's since it's basically a wrapper that's running these two clients, uh it's  easy to get into the projects yourself and you can make any change to the options for the clients  that you'd want. Get as weird as you want. Um so somewhere I'll show you what the uh the client  actually looks like. Point out a few things. This is not synced on my computer, but we'll get  an idea what you're looking at. Um, so that's uh pretty nerdy built with blessed config  library and and the main things you're getting

are both logs of the clients as they're  running. There's pretty handy status box up here which will tell you if it's syncing, if  there's an error, if what the current block is, if if you turn your node off. It's got a it's  got a catch back up to the chain. It'll it'll show you that info. Um your number of peers  and some stats on on how your system's doing. So, I've already kind of been through this, but  uh benefits of running your own node. Yeah, you're

you're being a good citizen. You're improving the  chain resilience through sharing data with other clients. uh you get your you get your RPC endpoint  and there's there's many distributed RPC services that are out there uh including infura alchemy but  it's kind of cool to run your own node because you have direct access to the chain and I really don't  think those I really don't think those services are going to be doing anything nefarious but you  get your own trustless independent verification of the chain and direct access and if you're  making a lot of making a lot of requests.

Sometimes sometimes those those charges can  really can add up. And with your own known, you know, you're not worrying about a per request  fee or running into annoying rate limits. And it's got a few charts here showing it's fast. uh where  the the leftmost entry on the x-axis is uh is a BG client that I was running on my home network.  So just going through my router and ran a couple of different uh methods through just to show that  yeah when you got a local node it's it's quicker.

So some basic requirements for running the build  client. Uh it's it's built for Linux or Mac OS and for nodes uh they're not too CPU intensive.  So luckily pretty much any modern processor with made within the last few years with at least  four threads is going to get you by. uh some extra extra CPU power is uh helpful for syncing.  It might help you sync a little bit. It can get a little get a little spicy there, but after your  notes sunk up, it's uh it's it's no issue there.

Uh on the RAM, you want at least 32 gigs. Uh  we've had we did we did some testing with 16 and it worked for a while and then we'd get random  crashes. So, and RAM's chief. So, just get 32. The drive selection is a little bit more tricky  because these clients are doing a lot of read reads and writes. So, you really want you want to  be a little more picky on that. Um, you're going to want an MVME SSD with at least two terabytes.  Uh, talk a little bit more about that later. And you you'll want to make sure the drive  includes a DRAM cache which helps with speed uh quite a bit. And there's another kind of tricky  thing is there are different there are different

architecture levels per for different drives which  is basically saying there's there's different ways they're set up to that have to deal with the  the amount more or less the amount of data being stored on each in each flash uh chip. And so it  goes from quad level cell, you're you're storing four levels on on each uh on each location  and then you go down to triple multi is two, single one. And the quad level cell architectures  are going to be the most budget friendly. You'll see a lot of those out there, but uh you want to  stay away from those. uh the uh they're not so quick on reader writes and they tend to degrade  a lot faster and as you get down triple multi-

single the lower you get on the levels the more  expensive. So multi or single level architectures are probably going to be enterprise and kind of  out of reach. So the sweet spot's going to be a a triple. And and as far as your network, you're  going to want to make sure that your your data is not being metered because a sync node will use  more than 100 gig gigs a day and they're going to use more than that when they're syncing. And  so yeah, the drive selection is very critical and it can be confusing. Uh but we got some  links to third party to some thirdparty stuff on our client.biddgill.com biddgill.com and  there's this SSD selection guide which is a GitHub gist of of a number of users who have  reported how different drives work in nodes.

So that's a great way that's a great place to  go. I mean I've got burned before like reading reading specs online for some cheaper drives and  it uh turns out they lied and they didn't work. So, a a setup that's been pretty well tested for  us and we have a number of these going is we're using the used to be Intel. I think I think Intel  stopped making these, but we're using Asus Nux uh the 13 Pro version which are a little older.  I think they might be on 15 or so now. But yeah, we're using Knuck 13 Pros with with i5 processors.  So, nothing nothing too too spicy. Uh running

Abuntu on there. Uh just just kind of we've got 32  gigs of uh kind of run-of-the-mill laptop memory, which is working well. And a drive a drive they  kind of settle on is the the Acer Predator GM7000, which I was going to put prices up here, but  they're fluctuating so much and they're different for different regions of the world, but it's not  super expensive. Uh should say though that that that uh Predator drive there's there's one that  comes with a little kind of graphine heat sink sticker which fits perfectly in these nooks and  one that comes with a real like a beefy heat sink and I very much doubt that it's going to fit  in these tiny computers. So get the non-heats

version. And speaking of thermal management, these  these little computers come in uh little like a tall version, short version. I go again with a  tall version. They they do better with thermals. So I mentioned before that uh you  want at least a two terabyte drive. These clients do use quite a bit of space and the  developers thought thought about that and they have a they have a potential they have a potential  way to to save on drive space for syncs. And so I got some really basic cartoons here that are  supposed to be showing the chain where the the

genesis is on the right, the most recent blocks  on the left. And developers have have given you the option of doing what they call an archive sync  which uh you ba like very basically break down the chain into two main components. You could call  it call one component the state which is kind of the the big database which holds balances nonses  contract storage by code all sorts of other stuff and that's the that's the most storage intensive  part and then the the other half you could break it down to call it the history which is more like  block headers transactions receipts logs so on so if you got a big old you could do an archive sync  and these f these hold the entire state entire

history for the whole chain. So you're going to  end up with a large database. But the advantage is that some some methods that you're going to hit  the RPC with are dependent upon having the state. So all your RPC methods are going to work all the  way back through the chain. And if you want to try to save some space, which a lot of node runners  do, you can use what's called a prune sync, which basically you're you're keeping the full  history of the chain, but you're pruning the state after some number of blocks. And a little  confusing, prune syncs have different names depending on the execution client. Like some call  it a full sync, some call it snap. Uh it's not

really full because you don't have the whole whole  state, but whatever. Uh this way you get a smaller database if you're going to go with the brun sync.  Um but you're limited to certain RPC methods than if you're going back further if you're going back  further in time than you have this state for. And just to illustrate a little bit um  client database sizes that for the clients that we're using mid November 2025 uh a ref  pruned sync is going to cost you about 1.2 2 terabytes and that'll give you state for back  back to 10,064 blocks from the most current and on ref that pruned that that sync that sync point  is userdefined. So you can you can change that if

you'd like. Uh on the GU side a pruned prune sync  is going to cost you 1.4 terabytes. Um and on GU the peroon syncs the state is more limited. It's  available for the last 128 blocks. And then if you uh you're going with the big boys uh  a RE archive sync is going to be about 2.6 terabytes and a GU archive is is much  larger. I've seen different numbers. Um so I settled I said about 15. It's up there. I  haven't tried it myself so I cannot confirm.

So yeah, th those execution clients uh are  taking up quite a bit of disc space for sure. On the consensus client side, we're looking  at 100 to 200 gigabytes. So not nearly as bad. So I mentioned kind of showed a list of of the  clients earlier and it mentioned that there's a number to choose from and and that's very that's a  very good thing because client diversity is super important. We really don't want a majority of  clients to be using or a majority of nodes using the same clients because that creates a bottleneck  where a a problem in one client could compromise the chain. So there's a big push to get to get  more clients out there and get more nodes running at greater diversity. And kind of illustrate  where we're at, uh I pulled these charts from

client diversity.org or and uh figuring out  what what nodes are running what clients is not super straightforward. It's uh they even say  here not not 100% accurate. Um and even on the execution side they're they're saying they have  74% confirmed clients and they're kind of assuming the rest are death. But the way the client break  client breaks the client diversity breaks down right now is get the big player g and nethermind  are the big players on the execution side. Techu is dominating on cons consensus side which uh with  prism and lighthouse coming in second and third.

And right now the build go client is set up by  default to run ref on the execution side. And you have the secondary option of running it with GE,  which is the majority client, but it it's tried and true. It's the OG. And on the consensus side,  you have a choice between Prism and Lighthouse. Uh some of the basic BG client startup options. Um  flags to choose your your two clients. By default, the BG client will do a a prune sync, but if you  want to use an archive, slap that in there. Um, you have the option to set your your pure  discovery ports for both clients, which is

important. You want those to be accessible  to other nodes so that they can they can benefit benefit from that data, especially during  their syncs. You have an option to to change the directory. It's usually within the build client  directory itself. But if you want to run it on a secondary drive or something and do that and  handily there's an update flag which which is great because clients are constantly being updated  for improvements and forks. So if you have a build go client all you got to do is pull it pull from  the git repo and hit it with that update and it'll uninstall your old clients, install some new  ones. And then there is this owner flag. And this is for a little kind of like a a little mini  decentralized RPC service that's running based on

our build guild nodes. And we're using we're using  the the RPC from the these distributed nodes to power scaffold ETH apps. And anyone's anyone's  welcome to opt in to to help us out with with powering scaffold ETH. All you got to do is set a  set an owner flag and good to go. And in return, uh, people opted into the RPC, we'll get a an  ERC20 called build guild bread. It's, uh, you know, not worth anything, but it's kind of a super  super complex point system. U, but that option is there. Um, yeah. And as I plan, as I promised,  I'm way under time. So, take any questions,

how compatible. Well, first uh thanks for  the talk. How compatible is the build guild client with other technologies like OAL  or SSB? Uh I missed I missed the other technologies you said. Sorry. SSB and OLE for  DVT distributed validator technologies. Oh, uh I'm I'm not familiar with that.  I don't have a good answer for that, but I'll figure it out. Yeah,  thank you. Yeah, sorry. Anyone else?

No. Well, questions. I I think that's it. Get some lunch.