###### tags: `Gnosis` # A guide to choosing your clients and improving your setup as a solo staker At the beginning, every solo staker must decide which execution and consensus client to pick to become a validator. For newcomers, there is no obvious difference between all theses clients. One might only know that one needs to pick a consensus client and execution client. Fortunately, pretty much no matter what you choose the clients will work well. Nevertheless, there are some small differences between them which can make a your life as a staker easier or harder. I personally ran Teku, Lighthouse, Prysm and Nimbus on the consensus side and Geth, Nethermind, Besu and Erigon on the execution side. The following is a collection of my experiences as a solo staker on Ethereum mainnet and Gnosis chain. ## Software Stack I run my nodes using [Dappnode](https://dappnode.com/), [ethdocker](https://eth-docker.net/) and [Ethereum on ARM](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/). Dappnode and ethdocker cover the opposite ends of the usability vs customizability spectrum. Dappnode uses a graphical user interface, simplifying maintenance with auto-updates. If you want a special configuration though, it might take some time to get it right if it is even possible. Conversely, eth-docker is command line based. It is highly configurable and lets you spin up nodes in a few minutes. These two extremes perfectly cover all my needs in the last 3 years. Ethereum on ARM is obviously for ARM based minicomputers and a bit more involved to set up, but great once it runs. ## Consensus Client At the end of 2020 there were speed and efficiency comparisons done for all the consensus clients. Now, several years later these comparisons are not that relevant anymore, as all the consensus clients work well. There still are small differences between them though. **Teku**, is more resource hungry (RAM and CPU) than other clients, but it can run on slightly slower SSDs. Not sure how much slower, but it was enough to keep my validators up and attesting at near perfect efficiency when lighthouse missed a lot of attestations. After exchanging my ssd to a recommended one I switched back to lighthouse and CPU/RAM usage came back down. **Lighthouse** is my go-to consensus client, mostly because it is the one I have the most experience with. It is more efficient than teku, but not the champion in this regard. I never had any issues with it in the 3 years running it on Ethereum mainnet and almost 2 years on Gnosis chain. On older or more exotic CPU architectures Lighthouse cannot use the standard builds with optimized cryptography libraries and needs a so called [portable build](https://lighthouse-book.sigmaprime.io/installation-binaries.html#platforms). If you run into problems starting up Lighthouse it might be worth checking if this is the issue. **Nimbus** is hands down the most resource efficient and amazing consensus client. I run it on my fallback node as well as testnet node with 2500 holesky genesis validators. It just runs and does it quietly. I plan to switch over my mainnet consensus client to Nimbus in the coming months for client diversity reasons. In my impression, Nimbus is not as well parallelized as other clients. If your single core speed is low Nimbus might not be the best choice, but I do not think this should be an issue on modern CPUs. I only run **Prysm** on testnets, but it seems to be in the same category as Lighthouse: good resource efficiency and stability. Some users report that their prysm uses 500 GB of space on the SSD for Ethereum mainnet, after deleting the the data folder and checkpoint resync prysm it then went back down to a few GB, slowly growing. So it sounds like prysm might need some more hand-holding. I have never used **Lodestar** long enough to have an informed opinion about it. It seems to use more RAM than Lighthouse. Other users report a solid stability and high attestation efficiency, so it is definitely worth a try, especially to improve client diversity on Gnosis chain and Ethereum mainnet. Overall, all consensus clients are now rock solid and if you see some bottlenecks in your system it might be worth to switch clients to see if a different client uses less of the resources you lack and therefore improve attestation efficiency. One other thing to consider is client diversity. The higher the client diversity, the more resilient the underlying blockchain becomes. Current client diversity data for [Ethereum](https://clientdiversity.org/) mainnet and [Gnosis chain](https://d14n.gnosischain.com/) (currently under construction) may aid decision-making. ## Execution Client The selection here is a bit more limited. There are 4 clients: Besu, Nethermind, Erigon and Geth. On Gnosis chain there are only 2: Nethermind and Erigon. **Geth** is the oldest and most battle tested one. It is the most resource efficient one and works the most reliably as an RPC node, if one needs this. I had to resync it quite often after power outages. In my impression other clients are a bit more resilient in that respect, but as far as I remember Geth also improved in that regard. **Nethermind** is my go-to execution client it is pretty resource efficient and perfectly reliable for me. It has the fastest sync time. It fully syncs in less than 24 hours and even allows validator duties way before it is fully synced. **Besu** runs on my fallback node and did not have any hiccups in the last several months since I started running it. It is about as resource efficient as Nethermind, but takes longer to sync. **Erigon** is first and foremost an archival node. If you do not know what an archival node is, then don't use Erigon. It is surprisingly resource efficient and was the only execution client which was able to run from a HDD instead of requiring an SSD. I do not think that this is true anymore, but it still is pretty resource efficient. I run a gnosis erigon node on a small ARM minicomputer and it follows the chain without issues. In my experience Erigon needs more hand-holding than other clients and there is always the possibility that one has to resync the node after a major update. My personal tip: never run Erigon together with Nimbus, they do not seem to like each other. I had issues with this combination on Ethereum and Gnosis chain. To summarize Nethermind and Besu are great. Geth should only be chosen if one needs a extremely reliable RPC node, because the supermajority of geth on the Ethereum network definitely needs to change. ## Improve your attestation efficiency. If your attestation efficiency is lower than expected and switching clients did not improve them it makes sense to look further. Having an attestation efficiency below 95% for Ethereum mainnet (beaconcha.in) or below 92% on Gnosis chain (gnosischa.in) is what I consider something which can be improved. I normally am in the 99% range on Ethereum mainnet and 96-97% on Gnosis chain. These numbers obviously also depend on the overall network health and can sometimes be lower. There are several layers between signing an attestation until it is included on chain. Depending on your setup the bottleneck might be at any of these layers. Therefore, I only mention some more common issues here. Rule of thumb for me is the following: if it takes more than 2-3 days to sync Nethermind (Ethereum or Gnosis) then there is a bottleneck somewhere which could affect attestation efficiency. CPU power is normally not a bottleneck as long as a halfway decent CPU from the last 10 years is used. I ran/run nodes reliably even on ARM minicomputers. - **SSD speed**: make sure you use an NVME SSD and also do not take the cheapest one you find. A good guide can be found [here](https://gist.github.com/yorickdowne/f3a3e79a573bf35767cd002cc977b038). - Connect your node via **Ethernet cable**. Connecting through WiFi is asking for trouble. - **Bandwidth**: having less than 30 Mbit/s up/download speed might not be enough to run a node efficiently. An Ethereum node uses around 2-3 terrabyte of data per month, a gnosis node slightly more than that. Make sure that there are no data caps on your connection. I also registered my validators on https://beaconcha.in and https://gnosischa.in which sends me a notification and email as soon as my validators missed 2 attestations. This fast notification reduced my downtime on Gnosis chain massively and is probably the single best attestation efficiency improvement for me. [//]: # "### Advanced setup: disentangle consensus client and validator client Last year I started to disentangle the nodes from the validators themselves. The consensus client is not a monolithic piece of software. It actually is comprised of 2 pieces, the consensus client itself and the validator client. Normally they are run with one command and one does not care that these are separate functions. I currently run the validator clients on a separate machine using eth-docker. The validator clients need almost no resources and can run on a several year old machine. The great part is that Lighthouse and most other validator clients allow to connect to any other consensus client. Lighthouse even allows connecting to two nodes. I connect them to the main node and fallback node and they switch to the fallback as soon as the main node is not synced anymore. As far as I know, teku and nimbus support this functionality as well. I am not sure about Lodestar and Prysm This setup has the advantage that a fallback is always available without having to copy over validator keys to a new machine or manually changing any configuration. Now I can resync/reconfigure my nodes whenever I want without having to think about down time. The validator node can also be made more secure as it does not need access to the internet, it only needs to connect to the local nodes. The disadvantage is a more complex setup which gives rise to more possibilities for errors. In my experience this setup also slightly improved my attestation efficiency. Not by a lot, but I was surprised to even see a difference."
Last changed by  
 
haurog
309

Read more

Automatic refilling of my on-chain bank account

I use a smart contract to claim, swap and forward my Gnosis chain validator rewards directly onto my Gnosis Pay account. With this I get a weekly top up into my account which I can directly spend with the card, as soon as I receive it.

1/3/2024
Rocket Pool Censoring Relay Status and Developments

Written by haurog, improved with suggestion by austonst (March 2023) Background Since the merge, the burden of block proposals falls on the shoulder of validators. They make a decision how much they want to interfere with block production. In other words, a node operator chooses what kind of block production methods are ethical in their view. MEV relays generally give a higher reward than local block production. Almost 90% of blocks are relayed through an MEV relay, and choosing a relay influences what kind of transactions end up on chain and how they are ordered. Some relays censor certain transactions, whereas other relays allow any transactions in blocks they produce. The focus is mostly on OFAC compliant transactions, which, to the best of my knowledge, only concerns Tornado Cash transactions. In the last few days (end of February beginning of March 2023) there have only been about a dozens tornado cash transactions per day which had been delayed more than 3 blocks. Ultrasound money mentions about 1200 OFAC transactions per week and a third of them being censored (subject to delay). Censorship therefore affects a small portion of all transactions on the Ethereum main chain only. Shortly after the merge, Flashbots was the biggest relay, many of the newer non OFAC compliant relays had to prove themselves first in production. Flashbots also promised the highest rewards at the beginning. This is why at the beginning if MEV Boost was enabled it was mainly Flashbots which was used. Now, there is a multitude of different relays for a user to choose from. It also needs to be mentioned that, to the best of my knowledge there is no clear law that node operators have to censor certain transaction in any of the large jurisdictions. Nevertheless, some node operators want to be on the save side and choose an OFAC compliant relay.

3/13/2023
All Flight Emission Estimators Are Wrong, But Some Are Useful

All models are wrong but some are useful. George Box All flight emission estimators have to simplify the complexity of the real world in order to estimate a carbon footprint incurred by air travel. Some make more assumptions, some less. In this post, we discuss how these assumptions influence the usability, accuracy and perceived precision of some readily available flight emission estimators. disCarbon Our flight emission estimator has an offset function which allows users to compensate their flight emission immediately and directly on-chain. This has the advantage that it is transparent, verifiable and taps into the first liquid and, therefore, efficient market for carbon credits. The emission estimation implemented is based on the model by myclimate. myclimate myclimate is one of most well-established flight emission estimators and is integrated in many airline websites. The model itself is explained in very high detail and is accessible on the myclimate website. The actual model used by the interactive estimator on their website is slightly different than the one documented which leads to small deviations on long range flights. We assume that this is due to unpublished changes in their calculation parameters. In a master thesis from 2009 it has been deemed to be the best emissions calculator from a wide range of European carbon compensation retail providers, see page 86 in the linked report (only available in German).

8/10/2022
Read more from haurog
Published on HackMD