• Can I be slashed for being offline?

• Can I stop running my validator for a few days and then start it back up again?

• Can I withdraw my ETH at any time?

• How long will a withdrawal take?

• How are validators incentivized to stay active and honest?

• How does MEV Boost min-bid work?

• How long do pre-signed exit messages remain valid?

• How important are disk IOPS?

• How many validators can I run on my machine?

• How much ETH do I need to stake to become a validator?

• How should I deal with a compromised or stolen machine?

• I am overwhelmed and don't know where to start - what can I do?

• I proposed a block! What did I earn?

• Is the deposit/source address shown anywhere?

• Is there a penalty for missing a block proposal?

• Is there a penalty for missing an attestation?

• Is there any advantage to having more than 32 ETH at stake?

• Should I set a withdrawal address when setting up my solo staking validator?

• Taxes!! How can I stay on top of them?

• What exactly is a validator?

• What happens if I lose my validator keys?

• What happens if I lose my validator seed phrase / mnemonic?

• What if I want to stop staking?

• What is a node operator?

• What is a validator client?

• What is the deposit contract?

• What is the easiest way to Solo Home Staking?

• What is the time commitment for running a validator?

• What should I do if I am getting lots of client errors post Shanghai?

• When should I top up my validator’s balance?

• Where are some good places to view various staking metrics?

• Where should I set my withdraw address to?

• Why can't I see my withdrawn ETH?

• Why did my smart plug turn off my machine?

• Why do I need to have funds at stake?

• Why is all my RAM being used?

• Why the 32 ETH maximum?

Can I be slashed for being offline?

No. Realistically, the only condition that can cause a slashing event is if you run your validator's keys on two nodes at the same time (such as a failover / redundancy setup, where your backup node accidentally turns on while your main node is still running). Don't let this happen, and you won't get slashed. Slashing cannot occur from being offline for maintenance.

Can I stop running my validator for a few days and then start it back up again?

Yes, but with small penalties. See I'm worried about downtime.

Can I withdraw my ETH at any time?

If your validator proposes a block, then some of those rewards are immediately available to you in the form of priority fees and MEV (if you are using an MEV-Boost relay).

To withdraw your full validator amount (not just the skimmed amount) you will be able to withdraw your ETH by exiting your validator and waiting in the withdrawal queue. This process is different for each client, details for each can be found here: How to exit a validator.

Ethereum Foundation Withdrawals FAQ: https://notes.ethereum.org/@launchpad/withdrawals-faq

How long will a withdrawal take?

Validator withdrawals are processed in a round-robin fashion. Starting from validator 0 at the Capella upgrade, with each block, the consensus layer sweeps through the validator set in validator index order until it has found 16 withdrawals to include. The next block proposer will pick up where the previous proposer left off in the validator set and scan for 16 further withdrawals, and so on. If every validator were eligible for a withdrawal, and if the beacon chain is performing perfectly, then a full sweep of 980,000 validators would take 8.5 days ("sweep delay"). For more info, see Ben Edgington's eth2book. The queue and estimated withdrawal time can be seen on validatorqueue.com

Does my validator need to be online to withdraw my ETH?

No. You can generate your exit message and submit it using someone elses Beacon Chain client.

Beaconcha.in has built a resource exactly for this: https://beaconcha.in/tools/broadcast

How are validators incentivized to stay active and honest?

As a validator you are rewarded for proposing / attesting to blocks that are included in the chain. On the other hand, you can be penalized for being offline and behaving maliciously—for example attesting to invalid or contradicting blocks.

The key concept is the following:

• Rewards are given for actions that help the network reach consensus.

• Minor penalties are given for inadvertent actions (or inactions) that hinder consensus.

• And major penalties (or slashings) are given for malicious actions.

In other words, you maximize your rewards by providing the greatest benefit to the network as a whole.

How important are disk IOPS?

Disk IOPS are very important if you want your node to operate to its true potential.

Low disk IOPS can cause many different issues such as missed attestations, missed block proposals, failure to get in sync with the network as well as failure to keep up with the network if already in sync.

If you are using Ubuntu, IOPS can be measured using this software. Before running tests, make sure your node services are stopped otherwise it will interfere with the results.

How many validators can I run on my machine? Do I need multiple consensus or execution clients?

1) Quite a lot! A former Teku developer wrote an article in which they ran 5,000 validators on the one machine. There are a few other factors you will need to take into account, such as CPU, RAM and bandwidth considerations.

If you already have a validator client, a consensus client and an execution client, then it is as easy as importing the new keys into the validator client. It will pick up and start performing the validator duties for the new validator(s) right away.

2) No, you do not need multiple consensus clients running to run multiple validators. A single consensus client can run multiple validators.

How does MEV Boost min-bid work?

Beacon Nodes pick the highest reward (local or remote) if it is above the min-bid value.

If the highest reward (local or remote) is below the min-bid value then the local block will be selected.

There are circuit breakers in beacon nodes that select a local payload when certain network conditions are met such as there being many missed slots recently.

How long do pre-signed exit messages remain valid?

Pre-signed exit messages only remain valid for two hard forks. After that, you will need to generate new ones.

This comes from https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/beacon-chain.md#get_domain and specifically the line:

fork_version = state.fork.previous_version if epoch < state.fork.epoch else state.fork.current_version

An exit message signed at any epoch less than the last hard fork is lumped into a "previous version" bucket and given its fork version. That means that if your operation was signed two fork versions ago the verification function has the wrong fork version, hence the wrong domain, hence the wrong signing root, hence the wrong signature, hence it fails to verify.

How much ETH do I need to stake to become a validator?

Each key-pair associated with a validator requires locking 32 ETH to be activated, which represents your initial balance as well as your initial and maximum voting power for any validator.

How should I deal with a compromised or stolen machine?

The best thing to do is to exit your validator as soon as it is practical to do so. Even in the case of an encrypted machine that is physically stolen where you can safely assume the thief won't ever be able to gain access, it is simply not worth the thought or the risk of being slashed at some point in the future.

If your validator keys are ever compromised or you even suspect them of being compromised, exiting the validator and spinning up new ones are the best course of action you can take to protect yourself.

Once your ETH is secured, further investigations and actions can be taken to prevent or mitigate this from occurring again.

I am overwhelmed and don't know where to start - what can I do?

Staking on Ethereum gives you many options to participate. This can be overwhelming - no doubt. We all have been there!

Take it step by step. First learn about the options you have and choose what you are most comfortable with. There is no need to rush things and risk your precious sleep while doing so.

If you choose "Solo Home Staking" and want to run your own validator, decide between the different hardware options (f.e. Intel NUC) and follow a staking guide on testnet first. Search for Goerli Testnet Staking Guides. Take notes, find out what happens when you disconnect the power cable of your validator, how to update, etc. All in all - get confident with your node before staking on Ethereum Mainnet.

And - You don't have to face problems on your own.

Feel free to ask us any question and join our community on Discord.

I proposed a block! What did I earn?

Validators that participate in securing the beacon chain and execute "duties" get rewarded for this by new issuance of ETH. In addition, validators receive priority fees paid by users, and optionally MEV, Maximal Extractable Value.

You can view a validator's reward for proposed blocks by looking at the fee recipient address on etherscan.io↗ under Produced Blocks.

See a detailed explanation here: How does my validator earn ETH?

Is the deposit/source address shown anywhere?

Yes, the deposit/source address is shown on the validator. It’s not used for anything in the protocol though. The consensus layer actually has no record of which address a validator's deposit was made from but it is in the history of the execution layer as all transactions are.

The deposit/source address can be seen on beaconcha.in under Deposits -> Ethereum Deposits -> From Address.

Is there a penalty for missing a block proposal?

No. If you miss your block proposal, the slot that should have contained your block will be empty. Other than the lost rewards from missing the block proposal, there are no penalties or slashing that occurs from a missed block proposal.

Is there a penalty for missing an attestation?

Missing some attestations is completely normal and extremely low-cost. The penalty for missing an attestation is exactly the same as the reward for a successful one. So, with around 240 attestations per day per validator, missing one or two is still a successful attestation rate of over 99%!

Is there any advantage to having more than 32 ETH at stake?

No. There is no advantage to having more than 32 ETH staked.

Depositing more than 32 ETH to a single set of keys does not increase rewards potential, nor does accumulating rewards above 32 ETH, as each validator is limited to an effective balance of 32. This means that staking is done in 32 ETH increments, each with its own set of keys and balance.

Should I set a withdrawal address when setting up my solo staking validator?

Setting a withdrawal address when creating your validator keys is an important step when setting up your validator. Until a withdrawal address is set, you will not be able to claim your beacon chain rewards or withdraw your ETH.

The Staking Deposit CLI can set a withdrawal address during deposit JSON creation (an 0x01 address). If a user opts not to do this - usually simply by omission - then it sets the hash of the withdrawal pub key instead (an 0x00 address)

And that’s it. Once your validator uses v1 credentials the withdrawal address is fixed and can’t be changed. In the current design, skimming is automatic, and so are full withdrawals: Full withdrawal just happens after exit is completed.

A tool to export the withdrawal key will likely not be created, and it’d also not be very useful. You need the withdrawal key at most twice:

• Once to generate the signing key (only if no withdrawal address was set at that time).

• Once more to sign a message to set one.

In both cases the key can be generated inside the CLI tool, be used for its purpose, and then be discarded again without ever being written to disk.

Taxes!! How can I stay on top of them?

Calculating staking taxes can be both difficult and tiresome but it is an important thing to do. Luckily an amazing tool exists to simplify this process.

This will give you a rundown of the rewards your validators have accrued. Always double check with a local tax agent before filing to ensure they have been calculated in an appropriate manner for the jurisdiction that you are a tax resident of.

What exactly is a validator?

A validator is a virtual entity that lives on the Beacon Chain, represented by a balance, public key, and other properties, and participates in consensus of the Ethereum network.

What happens if I lose my validator keys?

If there's a catastrophic failure of your validator and you lose your validator keys, don't panic! These can be easily recovered as long as you still have your validator seed phrase / mnemonic. Simply follow the same steps you used when you first generated your validator keys, and install them on a new validator machine.

Be 100% certain that any previous machines will not come back online as this will lead to a slashing event.

What happens if I lose my validator seed phrase / mnemonic?

If you lose your seed phrase, the one used to generate the validator keys, then unfortunately your staked ETH is most likely unrecoverable.

However, if you had set a withdrawal address, then the validator keys are enough to sign a voluntary-exit, which causes a withdrawal to that address. There is also a special case if you have a pre-signed voluntary-exit message, but that's likely only used by staking services and only noted here for completeness.

What if I want to stop staking?

In the event that you can't recover your validator or you decide you want to stop staking, you have the option to exit your validator. Exiting a validator is a one way process. For details on how to exit your validator, check out our guide.

What is a node operator?

A node operator is the human being who makes sure the client software is running appropriately, maintaining hardware as needed.

What is a validator client?

A validator client is the software that acts on behalf of the validator by holding and using its private key to make attestations about the state of the chain. A single validator client can hold many key pairs, controlling many validators.

What is the deposit contract?

You can think of the deposit contract as a transfer of funds from an Ethereum account to a proof-of-stake validator account. It specifies who is staking, who is validating, how much is being staked, and who can withdraw the funds.

What is the easiest way to Solo Home Staking?

Setting up your own validator for "Solo Home Staking" is not difficult.

You can follow step-by-step staking guides, which don't take much time at all. See also time commitment.

There are pre-configured hardware options like Dappnode↗ or Avado↗ which can make things easier and eliminate the need to interact with the command line interface or Linux in general. You can also install the open-source Dappnode software ↗ on your own hardware to have a more intuitive staking experience.

What is the time commitment for running a validator?

The majority of the time commitment for staking is the initial learning and setup. It will probably take a day or two of tinkering to get it all figured out (maybe more, and that's okay!). Once you get going you're looking at updating once a month or so (ten minutes) and responding to outages, which are rare.

What should I do if I am getting lots of client errors after a network upgrade?

The most common cause of this issue is when node operators have failed to upgrade their node software prior to the network upgrade taking place. This can cause the client software to follow a forked chain and require a resync to get the node operating again on the correct chain.

Ensure that you are running a client version that is supported post network upgrade. Please check the GitHub notes for respective the clients you are using to verify which version you should be running.

If you were running an older version post network upgrade, then most likely your local database will need to be deleted and resynced. This is more commonly true for execution clients than it is for consensus clients.

If you download the beaconchai.in app or sign up to an account you can configure email alerts when new client releases are published so you won't run into this issue.

Two other methods are to follow the projects on Github so you can be emailed when a new release is published, or to join the client team Discord servers where new software releases are announced.

When should I top up my validator’s balance?

The answer to this question very much depends on how much ETH you have at your disposal. You should certainly top up if your balance is close to 16 ETH. This is to ensure you don’t get exited out of the validator set (which automatically happens if your balance falls below 16 ETH). At the other end of the spectrum, if your balance is closer to 31 ETH, it’s probably not worth adding the extra ETH required to get back to 32.

Where are some good places to view various staking metrics?

There are many great resources out there to help you monitor your setup, a few are linked below.

All of these services will help you see things such as attestation performance, block proposals and total ETH accrued from staking.

Where should I set my withdraw address to?

It is critical that you set your validator withdraw address to an address that you have created yourself and have full control over.

This is typically defined as: A wallet address where you have the private keys and the ability to both send and receive transactions.

If you do not have the private key for the wallet (For example, an address on an exchange) then do not set that as your validator withdraw address as there is no guarantee that the 3rd party will give you your rewards or even exist in the near future to continue giving you your rewards.

Always remember: Not your keys, not your coins.

Advanced setups such as setting the withdraw address to a multisig is also supported but it is only recommended for advanced users.

Why can't I see my withdrawn ETH?

You may notice that your block proposals and ETH withdrawals are not appearing in your wallet transactions. Do not panic, this is both expected and normal. They will not appear there as both of these are not transactions.

If you enter in your wallet address into a website such as https://etherscan.io/ you will see a "Produced Blocks" tab and a "Withdraws" tab, further detailed information can be found here. Please note that these buttons will only appear if that wallet has had a block proposal occur or a validator withdrawal occur.

Whichever wallet you use will show your up to date ETH balance even if the transaction list is empty.

Why did my smart plug turn off my machine?

A not so frequently asked question but it has come up a few times! Some smart plugs only switch themselves back on after power failure when internet access has been restored.

However, in the case where your router or other critical network equipment are plugged into a smart plug with this "feature", they will not power back on unless the internet connection is restored, but the internet won't restore unless it has turned back on.

If you use a smart plug, it may be worthwhile to run a few tests to see if yours does this, otherwise you may find this out the hard way while attending Devcon on the other side of the world where it can only be fixed with manual action on-site...

Why do I need to have funds at stake?

As a validator, you'll need to have funds at stake so you can be penalized for behaving dishonestly. In other words, to keep you honest, your actions need to have financial consequences.

Why is all my RAM being used?

This question is commonly asked by Linux users - a detailed answer can be found here.

Why the 32 ETH maximum?

Each 32 ETH deposit activates one set of validator keys. These keys are used to sign off on the state of the network. The lower the ETH requirement, the more resulting signatures must be saved by the network. 32 ETH was chosen as a balance between enabling as many people as possible to stake without inhibiting decentralization by bloating the size of each block with signatures.

Limiting the maximum stake to 32 ETH per validator encourages decentralization of power as it prevents any single validator from having an excessively large vote on the state of the chain. It also limits the amount of ETH that can be exited from staking at any given time, as the number of validator that can exit in a given time period is limited. This helps protect the network against certain attacks.

Although a validator's vote is weighted by the amount it has at stake, each validators voting weight starts at, and is capped at 32. It is possible to drop below this with poor node performance, but it is not possible to raise above it. If you add more than 32 ETH for a single validator it will just get withdrawn back down to 32 ETH to your rewards address.

Once you have your validator machine setup running both an Execution Layer client and Consensus Layer client you are ready to start the deposit process.

Staking deposits are processed through the ethereum.org launchpad:

https://launchpad.ethereum.org/en/overview ↗

The following screenshots show the deposit process.

Choose execution client

Choose consensus client

Generate key pairs

What is your current operating system?

How do you want to generate your keys?

• Download CLI app

• Download Key Gen GUI app

• Build from source

Why run an Ethereum full node?

🍎 Contribute to the health of the Ethereum network.

• Check all transactions on the network are valid for yourself.

• Don't trust, verify.

📡 Broadcast your transactions .

• Remove reliance on 3rd parties and intermediaries such as Infura or Alchemy.

• Increase censorship resistance through decentralization.

Running a full node has very similar hardware requirements to running a validating node. The only difference is that validating nodes .

If you follow any of the and complete all the steps apart from the deposit process (which requires 32 ETH) then you will be running a full node!

Welcome to the EthStaker Knowledge base!

An unbiased, open-source collection of useful information and concepts about Ethereum staking. If you're looking to get started staking on Ethereum or simply to learn more about how the network is secured through validators, you've come to the right place!

🔗 Useful Links

🚀 Getting started

🚨 HELP!

💰 Rewards

💻 Hardware

🖧 Networking

⛓️ Validator Clients

🔑 Validator Keys

📕 Tutorials

🎛️ Scaled Node Operators

Can I contribute to the EthStaker knowledge base?

Yes! This is a living documentation site, meaning we need the community's help to maintain and update the content. Any contribution, from writing whole sections and translations to correcting spelling and grammar mistakes will be greatly appreciated.

Use this GitBook invite link to suggest edits and new content directly on GitBook:

✏️ Get Involved

Supported by a GitBook Community License ♥️

Slashing is a scary word. But what exactly is it, how can it happen and how worried should you be?

What is Slashing?

Slashing is a term used to describe the response of the Ethereum network to a validator acting against the rules of the network. Validators perform a number of duties (e.g. and ).

If someone wanted to attack the Ethereum network they could propose multiple blocks or attest to multiple conflicting blocks. To disincentivize attacks on the network, in a system, validators have something at stake, which is currently 32 ETH per validator. When a validator breaks the rules of the network, two things will happen:

1. The validator has some amount of ETH taken from that initial 32 ETH staked balance.

2. The validator is force exited and removed from the .

The amount of ETH taken as a penalty varies on the state of the network. If a small number of validators are slashed simultaneously, then a rough estimate of the slashing penalty is 1 or 2 ETH. In an incredibly rare Black Swan event, when a large portion of the network is simultaneously offline or breaking the rules (e.g. in a coordinated attack) then the slashing penalty can be up to and including 100% of the stake.

When your validator is force exited and the stake is withdrawn you are able to re-stake your remaining ETH (if you still have the 32 required), after going through both the and again.

Slashing Tracker

Staking is the act of depositing 32 ETH to activate validator software. As a validator you’ll be responsible for storing data, processing transactions, and adding new blocks to the blockchain. This will keep Ethereum secure for everyone and earn you new ETH in the process.

💰Earn rewards

Rewards are given for actions that help the network reach a consensus. You'll get rewards for running software that properly batches transactions into new blocks and checks the work of other validators because that's what keeps the chain running securely.

🔒 Better security

The network gets stronger against attacks as more ETH is staked, as it then requires more ETH to control a majority of the network. To become a threat, you would need to hold the majority of validators, which means you'd need to control the majority of ETH in the system–that's a lot!

🌿 More Sustainable

Stakers don't need energy-intensive computers to participate in a Proof of Stake (PoS) system - just a home computer or (in the future) a smartphone. This will make Ethereum better for the environment.

How to stake your ETH

🏡 Solo home staking

• Most impactful

• Full control

• Full rewards

• Trustless

Solo staking on Ethereum is the gold standard for staking. It provides full participation rewards, improves the decentralization of the network, and never requires trusting anyone else with your funds.

Those considering solo staking should have at least 32 ETH and a dedicated computer connected to the internet ~24/7. Some technical know-how is helpful, but easy-to-use tools now exist to help simplify this process.

☁️ Staking as a service

• Your 32 ETH

• Your validator keys

• Entrusted node operation

If you don't want or don't feel comfortable dealing with hardware but still want to stake your 32 ETH, staking-as-a-service options allow you to delegate the hard part while you earn native block rewards.

These options usually walk you through creating a set of validator credentials, uploading your signing keys to them, and depositing your 32 ETH. This allows the service to validate on your behalf.

This method of staking requires a certain level of trust in the provider. To limit counter-party risk, the keys to withdrawing your ETH are usually kept in your possession.

🪺 Pooled staking

• Stake any amount

• Earn rewards

• Keep it simple

• Popular

Several pooling solutions now exist to assist users who do not have or feel comfortable staking 32 ETH.

Many of these options include what is known as 'liquid staking' which involves an ERC-20 liquidity token that represents your staked ETH.

Liquid staking enables easy and anytime exiting and makes staking as simple as a token swap. This option also allows users to hold custody of their assets in their own Ethereum wallet.

Pooled staking is not native to the Ethereum network. Third parties are building these solutions, and they carry their own risks.

🏢 Centralized exchanges

• Least impactful

• Highest trust assumptions

Many centralized exchanges provide staking services if you are not yet comfortable holding ETH in your own wallet. They can be a fallback to allow you to earn some yield on your ETH holdings with minimal oversight or effort.

The trade-off here is that centralized providers consolidate large pools of ETH to run large numbers of validators. This can be dangerous for the network and its users as it creates a large centralized target and point of failure, making the network more vulnerable to attack or bugs.

If you don't feel comfortable holding your own keys, that's okay. These options are here for you. In the meantime, consider checking out the ethereum.org wallets page, where you can get started learning how to take true ownership of your funds. When you're ready, come back and level up your staking game by trying one of the self-custody pooled staking services offered.

As you may have noticed, there are many ways to participate in Ethereum staking. These paths target a wide range of users and ultimately are each unique and vary in terms of risks, rewards, and trust assumptions. Some are more decentralized, battle-tested, and/or risky than others. We provide some information on popular projects in the space but always do your own research before sending ETH anywhere.

Source ↗

You shouldn't worry about downtime, but understanding what happens when your validator is offline can help you to gain confidence as a solo home staker.

Example Scenario

• You start your solo staking home validator with 32 ETH.

• Everything is going well and after a few months, your validator balance is 32.5 ETH.

• Then... your validator goes offline! 🚨

  • If this happens for real, check out the "My validator is offline! What do I do?" guide.

Inactivity Leak

• As soon as your validator is no longer participating in the network it will start leaking ETH.

  • When you are offline, for each missed attestation the inactivity leak might be around -0.000011 ETH (the inactivity leak is slightly less than a successful attestation).

  • For a normal successful attestation, you might be rewarded with 0.000014 ETH.

• If you have a catastrophic failure and you are not able to get your validator back online for 5 days, then it will take about 5 days of being back online to get back to the same balance as when the failure occurred.

Missed Block Proposals

If you are offline, you will not be able to produce a block. But how often do block proposals occur for a single validator? Currently, on average, a validator will propose a block every 2-3 months.

So, in this example scenario, even if you are offline for 5 days, there's only a small chance you would miss a block proposal. But what happens if you miss a block proposal?

If you miss your block proposal, the slot that should have contained your block will be empty. Other than the lost rewards from missing the block proposal, there are no penalties or slashing that occurs from a missed block proposal.

Can I be slashed for being offline?

No. Realistically, the only condition that can cause a slashing event is if you run your validator's keys on two nodes at the same time (such as a failover / redundancy setup, where your backup node accidentally turns on while your main node is still running). Don't let this happen, and you won't get slashed. Slashing cannot occur from being offline for maintenance.

What if I can't recover my validator and/or I want to stop staking?

If you can't recover your validator or decide you want to stop staking, you have the option to exit your validator from the network. Exiting a validator is a one-way process. For details on how to exit your validator, check out our guide.

Conclusion

Being a solo validator is an important responsibility to ensure the long-term health of the Ethereum network. At EthStaker our goal is to help as many people as possible #stakefromhome ↗ and this information is provided to show that downtime and being offline is not something to be overly worried about.

It's random

How often a validator receives block proposals, and is selected to be part of a sync committee, is entirely random. As long as you do not see missed proposals, there is absolutely nothing you can do to increase the frequency.

True randomness can feel quite odd. A validator not getting a proposal for 9 months is perfectly normal. A validator getting two proposals in a week is entirely normal. Over a large enough set, this evens out, but for a handful of validators, randomness can indeed feel unsettling.

To see the latest's statistics on block proposal frequency take a look at Lucky Staker ↗.

The tool ethdo ↗ by attestant.io ↗ can be used to query the current average frequency of proposals and sync committees.

As of early 2024, it is roughly one proposal every 4 months and sync committee participation every 5 years.

Is there really nothing I can do?!?

No, it's random. There is nothing you can do to increase your chances at proposals, short of running more validators.

Don't panic!

Missing some attestations is completely normal and extremely low-cost. The penalty for missing an attestation is exactly the same as the reward for a successful one. So, with around 240 attestations per day per validator, missing one or two is still a successful attestation rate of over 99%!

Understanding missed attestations, low effectiveness and improving your setup

There are two causes of missing an attestation or having a low effectiveness with your validator. Some causes are under your control as a staker and some causes are outside of your control.

Even with a perfect setup, you might miss some attestations or incorrectly vote during an attestation lowering your effectiveness once in a while. Causes that are outside of your control are often related to network propagation or related to some of your peers being late in performing their own duties.

To go on a deep dive and learn everything about the attestation duty, timings, effectiveness and network propagation, check out these great articles.

• Understanding Attestation Misses ↗ by Adrian Sutton

• Exploring ETH2: Attestation Inclusion ↗ by Adrian Sutton

• Defining Attestation Effectiveness ↗ by Jim McDonald

As a staker, you cannot do much about the causes that are outside of your control. What you can do is work on elements of your setup that are under your control to maximize your rewards. Even if you have a setup that was performing well before the merge, it's possible that with the additional work being introduced, some overlooked part of your setup might be the cause of additional misses or lower effectiveness since the merge happened. That's why you should double check all these items.

1. Make sure your clients are up-to-date. Client updates often include optimizations and improvements that will help perform your duties on time.

2. Make sure your machine consistently has enough resources (CPU, RAM, disk, etc). Using a dedicated machine can help. If your clients are starved of any of these resources, it will likely be a cause for more misses and lower effectiveness.

3. Make sure your time is properly in sync. The beacon chain protocol is quite time sensitive. chrony is a good tool to improve your time sync. On Ubuntu or Debian derivatives, installing chrony is often as easy as sudo apt install chrony. On Windows, you can use these instructions ↗ to improve your time sync.

4. Make sure you have good internet latency, bandwidth and quality. For home validators, it's unrealistic to ask for a dedicated ISP or internet connection for your validator, but make sure your other network uses don't interfere too much with your validator. In case of doubt, see if you can get a better plan from your provider or check if there is an alternative provider in your area that can improve your internet.

5. Make sure you consistently have enough peers. Monitoring your clients peers count is not a bad idea if you have the technical ability.

6. Make sure you have properly configured open ports that permit incoming connections. Not only can this improve your setup networking health and your peers count, but it will also improve the Ethereum network health as a whole. To test if your ports are opened, you can use the StakeHouse open ports checker. Calling curl https://eth2-client-port-checker.vercel.app/api/checker?ports=30303,9000 should return a result that includes 30303 and 9000 in the open_ports field if those ports are opened from the Internet. 30303 is the default P2P port for Geth and 9000 is the default P2P port for many consensus clients. Adjust these values if you use custom ports or if you use clients which have different default ports. Consult your client documentation to find more about this.

Once you have those in place, there is little more you can do to help. There might be some marginal benefits in connecting with more peers at the cost of higher resources usage, especially bandwidth. Under normal circumstances, the default peers count from your clients should be good. Monitoring internet quality with tools like those from pingman ↗ can help pinpoint the cause of some of these missed attestations if they are network related, but it will likely still be out of your control.

Source ↗

Don't Panic!

The penalty for missing attestations is exactly the same as the reward for a successful one. Any downtime penalty will be recovered in the same amount of uptime.

Proposing a block is rare. Depending on the size of the validator pool, a single validator will on average only propose a block every few months. If you are unlucky enough to be offline at the time that your validator is asked to propose a block, that's also ok.

The Ethereum network is robust and designed to handle these situations. If you miss your block proposal, the slot that should have contained your block will be empty. Other than the lost rewards from missing the block proposal, there are no penalties or slashing that occurs from a missed block proposal.

If you have a large number of validators or want to minimize your downtime, consider running a second consensus and execution client pair and adding this endpoint to your already running validator client. This will ensure that if one of your client pairs goes down, your validator client will automatically fallback to the other one.

Doing this is a supported function by all validator client software as each client has slashing protections to ensure that you do not attest twice, so you will not get you slashed.

Do not however, configure a second validator service. By doing so your risk of slashing goes up massively. You should only ever have your validator keys in one place at any one time. Missing out on a few days of rewards may seem bad at the time, but getting slashed and bleeding ETH while you wait out the 5 week exit period post-slashing is a lot worse!

Having a second consensus-execution clients is great, but having a second validator client is not.

TODO

A full node is one that runs both an Execution Client and a Consensus Client.

Here is a simple breakdown of what is required to run a full Ethereum node:

• A stable Internet connection. The longer you stay online, the better your rewards. A spotty Internet connection will hurt your returns.

• At least 10Mbps of bandwidth both up and down. A full node usually takes around 8Mbps to 10Mbps up & down of network traffic, depending on your configuration. You'll also need to take into account other traffic happening on this network (downloads, video calls, streaming, gaming, etc).

• No data cap is imposed by your ISP. Running a full node will take a lot of data - as much as over 2 TB per month of on-chain data alone. This can be mitigated somewhat with a few settings tweaks to the ETH clients, but as a rule of thumb, don't run a full node if your Internet plan comes with a monthly data cap.

• Stable electricity. For the same reason as needing a stable Internet connection, you also want to have reliable power. This can be mitigated with a large UPS (backup battery) to deal with short blackouts.

• A computer with sufficient specs. This is pretty flexible because it really depends on what Execution and Consensus client you use, and what settings you configure them with. The computer can be a local machine, or it can be a Virtual Private Server (VPS) hosted in the cloud. Read below for some more information on those two options, and how to decide which is best for you.

The following are considered minimum requirements to run a full node:

• Linux or macOS Operating System

• Quad-core CPU (or dual-core hyperthreaded); both x64 and arm64 are supported

• 32 GB of RAM (preferably DDR4)

• 4 TB of free SSD Disk Space

  • A spinning platter hard drive is not fast enough to handle the constant random reads and writes that blockchain activity requires. You MUST use a solid-state drive. A list of tested SSD's can be found here.

Recommendations:

• The ideal setup, and best practice is to have a dedicated computer for staking. Try to limit additional processes running on your staking box. Especially if it is something that is connecting to the outside world. Every extra process and every file being downloaded is another opportunity for an exploit.

• Use Linux, it's easy! For the foreseeable future, Linux will receive better support from both the client teams and the community at large. If you choose Linux you will have access to more guides and more technical support from the community at large. Linux is lightweight, stable, secure, and it doesn't force you to restart for updates every other day.

• Use a minority client! It is both good for the health of Ethereum and good for the health of your money.

• A battery backup (UPS) is strongly recommended! Plug your modem and router into it also. Many ISPs have generators to support emergency services communications, meaning the internet continues to work during a power outage as long as your equipment is powered. Your ISP may be the same. Aside from blackouts, not having your computer shut down on every momentary power flicker is a nice quality-of-life improvement when staking from home.

• Everything here applies to both solo staking and being a minipool node operator with Rocket Pool ↗.

Hardware examples

Take a look at the hardware examples page for detailed explanations of real solo home staking setups.

Hardware options

• Raspberry Pi

• Old laptop/desktop

• New laptop

• New pre-built desktop

• Custom built desktop

• Intel NUC

• Server

• DAppNode

• Avado

• M1 Mac Mini

• Virtual Private Server

Raspberry Pi

Price: Lower cost.

Performance: Running an execution and consensus node on a Raspberry Pi is possible. Specifically, Nimbus which was designed to run on devices like a Raspberry Pi. Being able to run Ethereum nodes on low-powered hardware is great for decentralization and an honorable goal. However, running a validator is different. I maintain that the Pi’s lack of processing power and memory is a risk in some situations such as a period with no finalization. The reward of saving a few hundred dollars vs more powerful hardware does not even come close to outweighing the risk of extended downtime due to a lack of processing power or memory.

Power Usage: Approximately 8 watts.

Old laptop/desktop

Price: Lower cost.

CPU: For staking on Mainnet, a CPU that scores at least 6000 or better on Passmark is strongly recommended. For initial sync times, single-thread performance is better than having many cores.

Memory: Unless you go with an extremely bare-bones OS, 16GB is the minimum amount of RAM recommended for Mainnet.

Storage: An SSD is required. You do not need to worry about SATA vs NVMe, either will be fast enough. Buying one with a high terabytes written spec will help with longevity. A 2TB or bigger drive is recommended.

Caveats: Stability and uptime are essential to maximize your profits. If you are using an older desktop consider replacing the PSU and the fans. Buying a titanium or platinum-rated PSU will help save on the monthly power bill as well.

If you are planning on staking with an older laptop, consider that they have reduced capacity to deal with heat due to their form factor, and in rare cases, running while plugged in 24/7 can cause issues with the battery. If you do choose to stake with a laptop, try using one that far exceeds the CPU requirements as running a laptop at nearly full load 24/7 is not advisable. You will probably be fine, but generally speaking, laptops are not designed with that in mind.

New laptop

If you are buying brand new, there is not much value in paying the price premium for a portable form factor, screen, keyboard, and trackpad. Once you get your staking machine set up, you do not need any of these features. You can just remote into the staking machine from your normal computer. The low profile form factor will actually be a downside when taking thermal performance into account. Laptops typically do not include an ethernet port now, which means you will be relying on WiFi. WiFi is very reliable now, but you can't beat the simplicity and reliability of a cable.

New pre-built desktop

This is likely the simplest option and it will be easy to upgrade and service in the future**.**

Price: Medium price.

Power Usage: Probably around 30 watts.

Custom built desktop

This is essentially the same as using a prebuilt desktop. However, building your own gives you the option of choosing a case you like the look of, and buying higher-quality parts. For those of you who have never built a computer, it is easier than Lego because they only go together one way. Also, you won’t get any weird proprietary parts that will be difficult to replace should they ever fail. Unfortunately with prebuilt computers, concessions are sometimes made with components like the PSU to assuage the accountants and boost margins. Style points for adding a RAID card!

Intel NUC

Price: Medium price.

Power usage: 20-25ish watts.

NUCs are super cute, and their small form factor gives them a very high significant-other approval factor. Unfortunately that does come with a bit of a price premium and slightly less performance than the larger desktop option. However, these are minor drawbacks. This is probably the best option for most people.

Server

Price: Higher price.

Power Usage: It's bad. A modern server runs around 100 watts. If you get an older one, expect to be up around 150 watts.

Enterprise servers are jam packed with features, and are specifically designed to do exactly what a validator is trying to do. Run 24/7/365. They have redundant power supplies in case one breaks, they mostly have 2 CPUs, so in the unlikely event of one going bad, you can pop it out and restart with just one. They have built in RAID cards so you can have redundant storage. They have hot swappable drive trays, so if one of your drives goes bad, you don't even need to shut down. All of the components are high quality and built to last. You also get monitoring and maintenance tools that are not included in consumer gear like iDRAC and iLo. I would definitely caution that while servers are great for staking, you probably want to be the type of person who is willing to go into the weeds a bit and geek out. There is some research required to know what you are looking for before you go out and buy a server and there is a possibility you run into a weird technical issue that you will have to troubleshoot.

DAppNode

Price: Medium price

Performance: The DAppNodeXtreme is a good option if you are looking for a custom built OS with an easy UX. A DAppNode box is just a NUC pre-configured with their software. If you are confident enough to install an OS by yourself, you can save a bit of money by purchasing a normal NUC and installing DAppNode yourself. You can also install the DAppNode OS on any computer. If you don’t want to mess around with installing operating systems and want an easy UX, buying a DAppNode box is a convenient and simple way to get started.

Power Usage: 20-25ish watts.

Avado

Avado is an easy home-staking solution for people with limited technical knowledge or limited time. The Avado boxes are pre-configured computers with a user-friendly UI that allows you to use and manage the device from anywhere in the world.

Using an AVADO is convenient, secure and true to the spirit of decentralization.

M1 Mac Mini

Price: Medium price.

Performance: Definitely upgrade to 16GB of memory. The CPU will be more than fast enough with a 15,108 passmark score. Make sure you have a plan to get up to 2TB or more of storage, the internal memory and storage is integrated into the motherboard and requires soldering and advanced technical knowledge to upgrade.

Power Usage: Slightly less than the NUC, but not enough to make any real difference.

It's not possible to run Linux on the new ARM architecture this uses. It is more expensive that the NUC and also falls short on upgradeability, and ease of service, but for the Mac OS fans out there this is a great option that will work very well.

Virtual Private Server

Price: Anywhere from $20 - $50 per month.

Performance: You can buy as much as you can afford.

If you live somewhere that is prone to natural disaster or has an unstable power grid or internet connection but still want to solo stake, this is a good option. You can also consider using a DVT protocol.

If you do have stable power and internet, running your own hardware will be a cheaper/more profitable solution long term. You need to evaluate the pros/cons of this for your own situation. Remember that if one of the VPS providers goes down, it will mean all of the people using that VPS service to host will also go down, and the inactivity penalties will be much larger than if you have uncorrelated downtime yourself.

Staking rewards

Reward payments are automatically processed for active validator accounts with a maxed out effective balance of 32 ETH.

Any balance above 32 ETH earned through rewards does not actually contribute to principal, or increase the weight of this validator on the network, and is thus automatically withdrawn as a reward payment every few days. Aside from providing a withdrawal address one time, these rewards do not require any action from the validator operator. This is all initiated on the consensus layer, thus no gas (transaction fee) is required at any step.

Exiting staking entirely

Providing a withdrawal address is required before any funds can be transferred out of a validator account balance.

Users looking to exit staking entirely and withdraw their full balance back must also sign and broadcast a "voluntary exit" message with validator keys which will start the process of exiting from staking. This is done with your validator client and submitted to your beacon node, and does not require gas.

The process of a validator exiting from staking takes variable amounts of time, depending on how many others are exiting at the same time. Once complete, this account will no longer be responsible for performing validator network duties, is no longer eligible for rewards, and no longer has their ETH "at stake". At this time the account will be marked as fully “withdrawable”.

Once an account is flagged as "withdrawable", and withdrawal credentials have been provided, there is nothing more a user needs to do aside from wait. Accounts are automatically and continuously swept by block proposers for eligible exited funds, and your account balance will be transferred in full (also known as a "full withdrawal") during the next sweep.

How do withdrawal payments work?

Whether a given validator is eligible for a withdrawal or not is determined by the state of the validator account itself. No user input is needed at any given time to determine whether an account should have a withdrawal initiated or not—the entire process is done automatically by the consensus layer on a continuous loop.

Validator "sweeping"

When a validator is scheduled to propose the next block, it is required to build a withdrawal queue, of up to 16 eligible withdrawals. This is done by originally starting with validator index 0, determining if there is an eligible withdrawal for this account per the rules of the protocol, and adding it to the queue if there is. The validator set to propose the following block will pick up where the last one left off, progressing in order indefinitely.

Checking an account for withdrawals

While a proposer is sweeping through validators for possible withdrawals, each validator being checked is evaluated against a short series of questions to determine if a withdrawal should be triggered, and if so, how much ETH should be withdrawn.

1. Has a withdrawal address been provided? If no withdrawal address has been provided, the account is skipped and no withdrawal initiated.

2. Is the validator exited and withdrawable? If the validator has fully exited, and we have reached the epoch where their account is considered to be "withdrawable", then a full withdrawal will be processed. This will transfer the entire remaining balance to the withdrawal address.

3. Is the effective balance maxed out at 32? If the account has withdrawal credentials, is not fully exited, and has rewards above 32 waiting, a partial withdrawal will be processed which transfers only the rewards above 32 to the user's withdrawal address.

There are only two actions that are taken by validator operators during the course of a validator's life cycle that influence this flow directly:

• Provide withdrawal credentials to enable any form of withdrawal

• Exit from the network, which will trigger a full withdrawal

Gas free

This approach to staking withdrawals avoids requiring stakers to manually submit a transaction requesting a particular amount of ETH to be withdrawn. This also means there is no gas (transaction fee) required, and withdrawals also do not compete for existing execution layer block space.

How frequently will I get my staking rewards?

A maximum of 16 withdrawals can be processed in a single block. At that rate, 115,200 validator withdrawals can be processed per day (assuming no missed slots). As noted above, validators without eligible withdrawals will be skipped, decreasing the time to finish the sweep.

Expanding this calculation, we can estimate the time it will take to process a given number of withdrawals:

As you see this slows down as more validators are on the network. An increase in missed blocks could slow this down proportionally, but this will generally represent the slower side of possible outcomes.

Source: https://ethereum.org/en/staking/withdrawals/

Here is a list of example home-staking setups created by the EthStaker community:

• NUC - Eridian

• Custom Built Desktop - snoopmx

Validators that participate in securing the Beacon Chain and execute "duties" get rewarded for this by new issuance of ETH. In addition, validators receive priority fees paid by users, and optionally MEV. Validators are rewarded for executing those duties by new ETH issuance to the "validator balance". The current APY can be seen on the official launchpad ↗.

*Varies based on the total number of validators in the network. Estimate shown approximated for 435,000 active validators.

**These are subject to randomness; there can be "dry spells" multiple times longer than the average without being given one.

ETH on the Consensus layer is not liquid as it is being staked. Balances above 32 ETH will be automatically skimmed if a withdraw credential has been set, but to access the principal 32 ETH you will need to exit the validator.

Rewards provided on the Execution layer are liquid and can be accessed instantly.

Source ↗

Validator penalties

If the validator is offline and not executing its duties, it will be penalized at a rate slightly lower than the rewards for the same period of time.

Validators are penalized for small amounts of ETH if they are offline and fail to perform their assigned duties. This is called leaking. If a validator violates one of the core rules of the Beacon chain and appears to be attacking the network, it may get slashed. Slashing is a forceful exit of your validator without your permission, accompanied by a relatively large fine that removes some of your validator's ETH balance.

Realistically, the only condition that can cause a slashing is if you run your validator's keys on two nodes at the same time (such as a failover / redundancy setup, where your backup node accidentally turns on while your main node is still running). Don't let this happen, and you won't get slashed. Slashing cannot occur from being offline for maintenance.

Below is a table that shows the penalties that can happen to a validator:

*Varies based on the total number of validators in the network. Estimate shown approximated for 435,000 active validators.

Source ↗

• Archival node

• Attestation

• Attestation aggregator

• Beacon chain

• Block

• Block proposer

• Block status

  • Proposed

  • Scheduled

  • Missed/skipped

  • Orphaned

• Canonical chain

• Chain head

• Checkpoints

• Client

• Committees

• Consensus layer

• Deposit contract

• Effectiveness

• Epoch

• Execution layer

• Finalization

  • Finality issues

• Fork

• Full node

• Genesis block

• Hard fork

• Head vote

• Inactivity leak

• Inclusion distance

• Input data

• Justification

• Light clients

• MEV

• Mempool

• Node

• Operator

• Participation rate

• Peers

• Priority fees

• Private key

• Proof of stake (PoS)

• Public key

• Signing

• Slashable offenses

  • Attestation violation

  • Proposer violation

• Slasher node

• Slot

• Solo staker

• Source vote

• Staker

• Staking deposit CLI

• Suggested fee recipient

• Sync committee

• Target vote

• Validator

  • Eligible for activation & Estimated activation

  • Unique index

  • Current balance & Effective balance

• Validator lifecycle

  • 1. Deposited

  • 2. Pending

  • 3. Active validator

  • 4. Slashing validator

  • 5. Exiting validator

• Validator pool

• Validator queue

• Validator seed phrase / mnemonic

• Withdrawal address

Archival node

• Stores everything kept in a full node and builds an archive of historical states.

• Archive nodes are required if you want to query something like an account balance at a particular block.

• This data represents units of terabytes (more than 20TB for Geth), which makes archive nodes less attractive for most users but can be handy for services like block explorers, wallet vendors, and chain analytics.

Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical states but the full node is able to build them on demand.

Archive nodes aren't required to participate in block validation and can theoretically be built from scratch by simply replaying the blocks from genesis.

Source ↗

Attestation

Votes by validators which confirm the validity of a block. At designated times, each validator is responsible for publishing different attestations that formally declare a validator's current view of the chain, including the last finalized checkpoint and the current head of the chain.

Every active validator creates one attestation per epoch (~6.5 minutes), consisting of the following components:

An important component related to effectiveness is the chain head vote. This is a vote the validator makes about what it believes is the latest valid block in the chain at the time of attesting. The structure of a chain head vote consists of the following components:

• Slot - Defines where the validator believes the current chain head to be.

• Hash - Defines what the validator believes the current chain head to be to be.

The combination uniquely defines a point on the blockchain. By combining enough of these chain head votes the Ethereum network reaches consensus about the state of the chain.

Source (ethereum.org) ↗ Source (Attestant) ↗

Attestation aggregator

Although the data in each attestation is relatively small, it mounts up quickly with tens of thousands of validators. As this data will be stored forever on the blockchain, minimizing it is important, and this is done through a process known as attestation aggregation.

Aggregation takes multiple attestations that have all chosen to vote with the same committee, chain head vote, and finality vote, and merges them together into a single aggregate attestation.

An aggregate attestation differs in two ways from a simple attestation. First, there are multiple validators listed. Second, the signature is an aggregate signature made from the signatures of the matching simple attestations. Aggregate attestations are very efficient to store, but introduce additional communications and computational burdens.

If every validator was required to aggregate all attestations it would quickly overload the network with the number of communications required to pass every attestation to every validator. Equally, if aggregating were purely optional then validators will not bother to waste their own resources doing so. Instead, a subset of validators is chosen by the network to carry out aggregation duties1. It is in their interest to do a good job, as aggregate attestations with higher numbers of validators are more likely to be included in the blockchain so the validator is more likely to be rewarded.

Validators that carry out this aggregation process are known as aggregators.

Source ↗

Beacon chain

A major part of the work of the beacon chain is storing and managing the registry of validators – the set of participants are responsible for running the Ethereum Proof of Stake (PoS) system.

This registry is used to:

• Assigns validators their duties.

• Finalizes checkpoints.

• Perform a protocol level random number generation (RNG).

• Progress the beacon chain.

• Vote on the head of the chain for the fork choice.

Source ↗

Block

A block is a bundled unit of information that include an ordered list of transactions and consensus-related information. Blocks are proposed by Proof of Stake (PoS) validators, at which point they are shared across the entire peer-to-peer network, where they can easily be independently verified by all other nodes. Consensus rules govern what contents of a block are considered valid, and any invalid blocks are disregarded by the network. The ordering of these blocks and the transactions therein create a deterministic chain of events with the end representing the current state of the network.

Block proposer

A chosen validator by the Beacon Chain to propose the next block. There can only be one valid block per slot.

Block status

Proposed

The block was proposed by a validator.

Scheduled

Validators are currently submitting data.

Missed/skipped

The proposer didn’t propose the block within the given time frame, so the block was missed/skipped.

Orphaned

In order to understand this, let us look at the diagram below "1, 2, 3, ... ,9" represent the slots.

1. Validator at slot 1 proposes the block “a”.

2. Validator at slot 2 proposes “b”.

3. Slot 4 is being skipped because the validator didn’t propose a block (e.g.: offline).

4. At slot 5/6 a fork occurs: Validator(5) proposes a block, but validator(6) doesn’t receive this data (e.g.: the block didn’t reach them fast enough). Therefore Validator(6) proposes its block with the most recent information it sees from validator(3).

5. The fork choice rule ↗ is the key here - It decides which of the available chains is the canonical one.

Canonical chain

The canonical chain is the chain which is agreed to be the 'main' chain and not a fork.

Chain head

The latest block received by a validator. This does not necessarily mean it is the head of the canonical chain.

Checkpoints

The Beacon Chain has a tempo divided into slots (12 seconds) and epochs (32 slots). The first slot in each epoch is a checkpoint. When a supermajority of validators attests to the link between two checkpoints, they can be justified and then when another checkpoint is justified on top, they can be finalized.

Client

An implementation of Ethereum software that verifies transactions in a block. These can be consensus layer clients or execution layer clients. Each validator needs both an execution layer client and a consensus layer client.

Committees

A group of at least 128 validators is assigned to validate blocks in each slot. One of the validators in the committee is the aggregator, responsible for aggregating the signatures of all other validators in the committee that agree on an attestation. Not to be confused with sync committees.

Consensus layer

Ethereum's consensus layer is the network of consensus clients.

Deposit contract

The Deposit contract is the gateway to Ethereum Proof of Stake (PoS) and is managed through a smart contract on Ethereum. The smart contract accepts any transaction with a minimum amount of 1 ETH and valid input data. Ethereum beacon nodes listen to the deposit contract and use the input data to credit each validator.

More info on the deposit contract

Effectiveness

The average time it takes for a validator's attestations to be included in the chain.

Check out our page explaining validator effectiveness in more detail

Epoch

1 Epoch = 32 Slots Represents the number of 32 slots (12 seconds) and takes approximately 6.4 minutes. Epochs play an important role when it comes to the validator queue and finality.

Execution layer

Ethereum's execution layer is the network of execution clients.

Finalization

In Ethereum Proof of Stake (PoS) at least two third of the validators have to be honest, therefore if there are two competing epochs and one third of the validators decide to be malicious, they will receive a penalty. Honest validators will be rewarded.

In order to determine if an epoch has been finalized, validators have to agree on the latest two epochs in a row, then all previous Epochs can be considered as finalized.

Finality issues

If there are less than 66.6% of the total possible votes (the participation rate) in a specific epoch, the epoch cannot be justified. As mentioned in "Finalization", three justified epochs in a row are required to reach finality. As long as the chain cannot reach this state it has finality issues.

During finality issues, the validator entry queue will be halted and new validators will not be able to join the network, however, inactive validators with less than 16 ETH balance will be exited from the network. This leads to more stability in the network and a higher participation rate, allowing the chain to eventually finalize.

Fork

A change in protocol causing the creation of an alternative chain or a temporal divergence into two potential block paths. Also see hard fork

Full node

Stores and maintains the full blockchain data on disk. It serves blockchain data upon request and helps support the network by participating in block validation and by verifying all blocks and states. All states can be derived from a Full node.

Source ↗

Genesis block

The first block in a blockchain, used to initialize a particular network and its cryptocurrency.

Hard fork

A hard fork occurs when an update is being pushed to the Ethereum network and the new version of the software forks from the old version. Usually requires operators to update their validator software to stay on the correct side of the fork. Also see fork

Head vote

The validator has made a timely vote for the correct head block.

Inactivity leak

If the Beacon Chain has gone more than four epochs without finalizing, an emergency protocol called the "inactivity leak" is activated. The ultimate aim of the inactivity leak is to create the conditions required for the chain to recover finality. Finality requires a 2/3 majority of the total staked ether to agree on source and target checkpoints. If validators representing more than 1/3 of the total validators go offline or fail to submit correct attestations then it is not possible for a 2/3 supermajority to finalize checkpoints. The inactivity leak lets the stake belonging to the inactive validators gradually bleed away until they control less than 1/3 of the total stake, allowing the remaining active validators finalize the chain. However large the pool of inactive validators, the remaining active validators will eventually control >2/3 of the stake. The loss of stake is a strong incentive for inactive validators to reactivate as soon as possible!

Inclusion distance

The inclusion distance of a slot is the difference between the slot in which an attestation is made and the lowest slot number of the block in which the attestation is included. For example, an attestation made in slot s and included in the block at slot s + 1 has an inclusion distance of 1. If instead the attestation was included in the block at slot s + 5 the inclusion distance would be 5.

The value of an attestation to the Ethereum network is dependent on its inclusion distance, with a low inclusion distance being preferable. This is because the sooner the information is presented to the network, the more useful it is.

To reflect the relative value of an attestation, the reward given to a validator for attesting is scaled according to the inclusion distance. Specifically, the reward is multiplied by 1/d, where d is the inclusion distance.

Input data

The Input data, also called the deposit data, is a user generated, 842 long sequence of characters. It represents the validator public key and the withdrawal public key, which were signed with by the validator private key. The input data needs to be added to the transaction to the deposit contract in order to get identified by the beacon-chain.

More info about the deposit process

Justification

66.6% of the total validators need to attest in favour of a block's inclusion in the canonical chain. This condition upgrades the block to "justified". Justified blocks are unlikely to be reverted, but they can be under certain conditions.

When another block is justified on top of a justified block, it is upgraded to "finalized". Finalizing a block is a commitment to include the block in the canonical chain.

More info on justification ↗

Light clients

An Ethereum client that does not store a local copy of the blockchain, or validate blocks and transactions. It offers the functions of a wallet and can create and broadcast transactions.

MEV

MEV or "maximal extractable value", is a controversial topic. Node operators can extract MEV by accepting blocks built by "searchers", via a small side program called "mev-boost ↗" by Flashbots. In this case, the Consensus Layer client such as Nimbus, Teku, etc. will, when asked to procure a block to propose, get blocks from MEV relays via mev-boost and from the Execution Layer client such as Besu, Geth, etc. and then choose whichever block from the relay pays best. The local Execution Layer client will only build a block when no block is offered by the relay (e.g the relay is down) or the min-bid offered is lower than the locally set value. If a blinded block from a relay has already been signed, then a local block will not be built so double signing does not occur. For this reason, when a validator signs a block from the relay, it is trusting that the relay will submit that signed block to the network.

Rewards from MEV are paid to the same suggested fee recipient address as priority fees.

Source ↗

Mempool

When an Ethereum node receives a transaction, it is not instantly added to a block. The transaction is held in a waiting area or a buffer zone.

The transaction goes from a number of levels of verification such as it checks whether the output is greater than the input, whether the signature is valid or not, etc., and then only it is added to a block. The transaction is not added to a block if it fails any of these validations. The role of a mempool comes while a transaction is going through these checks. It is simply kept in this waiting area or a mempool. As soon as the transaction confirms, it is removed from the mempool and added to a block. Mempool is not a master reference shared universally by all nodes. There’s no “one” mempool. This means each node configures its own rules for the node’s mempool. In fact, a node can be the first to receive a transaction but it is possible that it might not have propagated the transaction to the rest of the network.

Source ↗

Node

Any instance of Ethereum client software that is connected to other computers also running Ethereum software, forming a network. A node doesn’t necessarily need a validator but a validator requires a node. Running a node by itself does not generate any revenue but does contribute to the robustness of the network.

Operator

A person who maintains a validator

Participation rate

The participation rate is the percentage of validators that are online and performing their duties.

If the validator set is 1,000 validators, and 250 validators are offline or rarely making proposals or attestations, then it could be estimated that the participation rate is 75%.

Source ↗

Peers

Other nodes running Ethereum clients that connect to each other over a peer-to-peer network. Communication between peers is how the Ethereum network remains decentralized as there is no single point of failure.

Priority fees

Almost all transaction on Ethereum set a priority fee ↗ to incentivize block proposers to include the transaction as a higher priority than others. The higher the fee relative to other transactions currently waiting in the mempool This fee is paid to the block proposer. All of the priority fees in a block are aggregated and paid in a single state change directly to the suggested fee recipient set by the block proposer. This address could be a hardware wallet, a software wallet, or even a multi-sig contract.

Private key

A secret number that allows Ethereum users to prove ownership of an account or contracts, by producing a digital signature.

Proof of stake (PoS)

A method by which a cryptocurrency blockchain protocol aims to achieve distributed consensus. PoS asks users to prove ownership of a certain amount of cryptocurrency (their "stake" in the network) in order to be able to participate in the validation of transactions.

Public key

A number, derived via a one-way function from a private key, which can be shared publicly and used by anyone to verify a digital signature made with the corresponding private key.

Signing

Demonstrating cryptographically that a message or transaction was approved by the holder of a specific private key).

Slashable offenses

If your validator commits a slashable offense it will be force exited from the validator pool and will have ETH deducted depending on the circumstances of the event. Typically, this will be 1-2 ETH but could be significantly more ↗.

This is not something to be overly worried about, there are simple steps you can take to make sure that you don't invoke a slashing event.

There are three ways a validator can be slashed, all of which amount to the dishonest proposal or attestation of blocks.

Attestation violation

• Double voting: Signing two different attestations in one epoch.

• Surround votes: Attesting to a block that "surrounds" another one (effectively changing history).

Proposer violation

• Double block proposal: Proposing and signing two different blocks for the same slot.

Slasher node

The slasher is its own entity but requires a beacon-node to receive attestations. To find malicious activity by validators, the slashers iterate through all received attestations until a slashable offense has been found. Found slashings are broadcasted to the network and the next block proposer adds the proof to the block. The block proposer receives a reward for slashing the malicious validator. However, the whistleblower (Slasher) does not receive a reward.

Slot

32 Slots = 1 Epoch A time period of 12 seconds in which a randomly chosen validator has time to propose a block. The total number of validators is split up in committees and one or more individual committees are responsible to attest to each slot. One validator from the committee will be chosen to be the aggregator, while the other 127 validators are attesting. After each Epoch, the validators are mixed and merged to new committees. Each slot may or may not have a block in it as a validatory could miss their proposal (e.g. they may be offline or submit their block too late). There is a minimum of 128 validators per committee.

Solo staker

An operator who runs a validator on the Ethereum network without a protocol between their validator and the Beaconchain

Source vote

The validator has made a timely vote for the correct source checkpoint.

Staker

Someone who has deposited ETH into a validator to secure the network. This can be someone who runs a validator (an operator) or someone who deposited their ETH into a pool, where someone else is the operator of the validator.

Staking deposit CLI

A command-line tool used to generate validator keys and deposit data files.

• https://github.com/ethereum/staking-deposit-cli

Suggested fee recipient

The fee recipient is an Ethereum address nominated by a Beacon Chain validator to receive tips from user transactions and MEV.

Sync committee

A sync committee is a randomly selected group of validators that refresh every ~27 hours. Their purpose is to add their signatures to valid block headers. Sync committees allow light clients to keep track of the head of the blockchain without needing to access the entire validator set. Occurs every 2 years on average, however, there can be "dry spells" multiple times longer than the average without being given one. So if your validator is selected... congratulations! 🥳

Target vote

The validator has made a timely vote for the correct target checkpoint.

Validator

A node in a Proof of Stake (Pos) system responsible for storing data, processing transactions, and adding new blocks to the blockchain. To activate validator software, you need to be able to stake 32 ETH. A validator's job is to propose blocks and sign attestations. It has to be online for at least 50% of the time in order to have positive returns. A validator is run by an operator (a human), on hardware (a computer) and is paired with a node (many thousand validators can run on one node).

Eligible for activation & Estimated activation

Refers to pending validators. The deposit has been recognized by the Beacon Chain at the timestamp of “Eligible for activation”. If there is a queue of pending validators ↗, an estimated timestamp for activation is calculated.

Unique index

Every validator receives a unique index based on when they are added from the validator queue.

Current balance & Effective balance

The current balance is the amount of ETH held by the validator as of now. The effective Balance represents a value calculated by the current balance. It is used to determine the size of a reward or penalty a validator receives. The effective balance can never be higher than 32 ETH.

In order to increase the effective balance, the validator requires “effective balance + 1.25 ETH”. In other words, if the effective balance is 20 ETH, a current balance of 21.25 ETH is required in order to have an effective balance of 21 ETH. The effective balance will adjust once it drops by 0.25 below the threshold as seen in the examples above.

Here are examples of how the effective balance changes:

• If the Current balance is 32.00 ETH – the Effective balance is 32.00 ETH.

• If the Current balance dropped from 22 ETH to 21.76 ETH – Effective balance will be 22.00 ETH.

• If the Current balance increases to 22.25 and the effective balance is 21 ETH, the effective balance will increase to 22 ETH.

Validator lifecycle

1. Deposited

32 ETH has been deposited to the ETH1 deposit-contract and this state will be kept for around 7 hours. This offers security in case the Ethereum chain gets attacked.

2. Pending

Waiting for activation on the Beacon Chain.

Before validators enter the validator queue, they need to be voted in by other active validators. This occurs every 4 hours.

3. Active validator

Currently attesting and proposing blocks.

The validator will stay active until:

• Its balance drops below 16 ETH (ejected).

• Voluntary exit.

• It gets slashed.

4. Slashing validator

The Validator has been malicious and will be slashed and kicked out of the system.

A Penalty is a negative reward (e.g. for going offline). A Slashing is a large penalty (≥ 1/32 of balance at stake) and a forceful exit ... . - Justin Drake

5. Exiting validator

• Ejected: The validator balance fell below a threshold and was kicked out by the network.

• Exited: Voluntary exit, the withdrawal key holder has the ability to withdraw the current balance of the corresponding validator balance.

Validator pool

The number of currently active validators securing the Ethereum network. The current validator pool can be seen here ↗.

Validator queue

The validator queue is a first-in-first-out queue for activating and exiting validators on the Beacon Chain.

• Until 327680 active validators in the network, 4 validators can be activated per epoch. For every (4 * 16384) = 65536 active validators, the validator activation rate goes up by one.

• 5 validators per epoch requires 327680 active validators, allowing 1125 validators per day.

• 6 validators per epoch requires 393216 active validators, allowing 1350 validators per day.

• 7 validators per epoch requires 458752 active validators, allowing 1575 validators per day.

• 8 validators per epoch requires 524288 active validators, allowing 1800 validators per day.

• 9 validators per epoch requires 589824 active validators, allowing 2025 validators per day.

• 10 validators per epoch requires 655360 active validators, allowing 2200 validators per day.

• Amount of activations scales with the amount of active validators and the limit is the active validator set divided by 64.

Exiting validators works in the same way, with the amount of validators that can exit the Beacon Chain per day rate limited to preserve the stability of the network.

Validator seed phrase / mnemonic

The Seed Phrase or Mnemonic is a set of words (usually 12, 18 or 24 words long) used to generate your validator keys. Your mnemonic is the backup for your validator keys and is the ONLY way to withdraw your ETH, and no one can help you recover your mnemonic if you lose it.

Withdrawal address

An address that can be optionally set when creating a validator key that will be used to withdraw staked ETH. If this address is not set at the time of key creation it can be set at the time of withdrawal instead. For more information about setting the withdrawal address on key creation, see our FAQ answer.

This is a simple NUC that I set up for my home staking validator. It was very easy to build - around 10 minutes to unpack everything, slot in the RAM and SSD, and turn it on.

I decided on the larger form factor for the NUC (there's a normal and a slim version) to avoid any problems with restricted airflow and overheating. I'm also not constrained on space so I didn't mind having a slightly larger form factor on my shelf.

2TB SSD is the right amount for me as I won't need to upgrade it within the next 1-2 years and possibly by that time there may be improvements made in the protocol and/or clients that allow for smaller states, needing less storage.

You don't need 64GB of RAM but I wanted to have extra in case I needed it in the future, but 16GB would have been fine.

Total cost: £1165 (October 2022)

The machine only needed three parts:

• Intel NUC 11 Pro NUC11TNHi7 Tiger Canyon Home & Business Mini PC Mini Desktop 11th Gen Intel® Core™ i7-1165G7 Processor Upto 4.7 GHz Turbo,4 Cores,8 Threads,12 MB L3 Cache(Without RAM&SSD)↗

• Samsung 970 EVO Plus 2 TB PCIe NVMe M.2 (2280) Internal Solid State Drive (SSD) (MZ-V7S2T0), Black↗

• Corsair Vengeance SODIMM 64GB (2x32GB) DDR4 2666MHz CL18 Memory for Laptop/Notebooks (Intel 6th Generation Intel Core i5 and i7 Processor Support) Black↗

To open the NUC, simply unscrew the four retaining screws, and detach the ribbon cable.

The ribbon cable has a small plastic retainer that can be unclipped by hand.

With the ribbon cable removed, the NUC will look like this:

The first component to insert is the SSD. There is a retaining screw that needs to be removed before the SSD is inserted (1).

The SSD is placed in the slot that says "NVMe ONLY" (2). It can only fit one way because of the little notch, so there's nothing to worry about.

Replace the SSD retaining screw (1).

The SSD in place should look like this:

Insert the RAM into the slots. Again, they can only fit one way because of the little notch.

The finished setup should look like this:

Replace the NUC base plate and secure the four retaining screws... and that's it!

All you need to do now is plug in the power cable and press the power button to turn it on 🥳

To install the validator software, check out the Linux installation guide.

This is a Custom-built-desktop that I put together for stake solo validator. I decided on high-quality components at a good price so that they will not be obsolete quickly.

There are 6 main things to keep in mind:

1. Motherboard External site link ↗

2. Microprocessor External site link ↗

3. RAM memory External site link ↗

4. Hard Drive External site link ↗

5. Power supply External site link ↗

6. Cabinet External site link ↗

I decided on a mini ITX motherboard Z690l which is a small form factor, the card is modern to house Intel 12th generation microprocessors that will last me for many years of hard work.

An Intel Corei5-12400 microprocessor with integrated graphics, the ratio with or without integrated graphics is very little difference in cost, plus you save on buying a graphics card.

A 16GB DDR5 RAM with RGB looks great for your build, in addition to the 6000 MHz it reaches.

A hard drive SSD 2TB PCI Express 3.0 NV1 M.2 NVMe.

The power supply EVGA Supernova 750 GM is very important for the assembly, I decided on an EVGA for the mini ITX that does not make noise, that is modular, you save on cables that you do not need and the fan is only activated when it is needed. With the SFX shape that is smaller.

Finally, Cabinet Cooler Master NR200P SFF - Mini-ITX, removable and with great access to modify the hardware components, including fans.

It is certainly a wise decision to build your own node. They are quality components without a doubt, you can save more by buying other motherboards or another type of RAM.

1. $280 USD - Motherboard Z690I AORUS ULTRA LITE LGA 1700/ Intel Z690/ Mini-ITX/ DDR5/ Dual M.2/ PCIe 3.0/ USB 3.2 Gen2X2 Type-C/2.5 GbE LAN

2. $225 USD - Microprocessor Intel Procesador Core i5-12400 - S-1700-2.50GHz - 6-Core - 18MB Smart Cache (12va. Generación - Alder Lake)

3. $125 USD - RAM memory 16GB DDR5 XPG ECC CL40 XMP 6000 MHz RGB

4. $145 USD - Hard Drive SSD 2TB PCI Express 3.0 NV1 M.2 NVMe

5. $115 USD - Power supply EVGA Supernova 750 GM, 80 Plus Gold 750W, Fully Modular, Eco Mode with FDB Fan, SFX Form Factor

6. $125 USD - Cabinet Cooler Master NR200P SFF - Mini-ITX

TOTAL: $1015 USD (September 2022)

Greetings #StakeFromHome #Mexico

Ethereum is a peer-to-peer network with thousands of nodes that must be able to communicate with one another using standardized protocols. The "networking layer" is the stack of protocols that allow those nodes to find each other and exchange information. This includes "gossiping" information (one-to-many communication) over the network as well as swapping requests and responses between specific nodes (one-to-one communication). Each node must adhere to specific networking rules to ensure they are sending and receiving the correct information.

There are two parts to the client software (execution clients and consensus clients), each with its own distinct networking stack. As well as communicating with other Ethereum nodes, the execution and consensus clients have to communicate with each other. This page gives an introductory explanation of the protocols that enable this communication.

gossip transactions over the execution-layer peer-to-peer network. This requires encrypted communication between authenticated peers. When a validator is selected to propose a block, transactions from the node's local transaction pool will be passed to consensus clients via a local RPC connection, which will be packaged into Beacon blocks.

will then gossip Beacon blocks across their p2p network. This requires two separate p2p networks: one connecting execution clients for transaction gossip and one connecting consensus clients for block gossip.

If you're ever out and about and away from home for long periods of time, then this tutorial is for you!

Question - Why should I set up a VPN server? It is easier to simply forward ports and connect in.

Answer - A VPN server introduces another layer of security. To connect to your node via SSH, you first have to connect to your VPN and then SSH into your node. This introduces another barrier and makes intrusions much more difficult.

Requirements

• You will need a public static IP address or a DNS for your home network.

• This tutorial assumes you have Ubuntu Server 22.04 LTS installed and running. If not, no stress! You can follow the below link for a tutorial on how to do that.

Recommendations

• For security purposes, I recommend you set up the VPN server on a separate machine that is not your staking machine. This can even be a VM.

With all of that out of the way - Let's dive right into it!

Step 1 ) Run commands to ensure your machine is up to date.

Please login to the machine and authenticate as superuser using the below command

sudo -i

Now execute the below command to ensure the OS and packages are up to date. Please upgrade any that aren't.

apt-get update && apt-get upgrade

Step 2 ) Install OpenVPN dependencies.

Please execute the below command.

apt-get install ca-certificates wget net-tools gnupg

Step 3) Import OpenVPN GPG key and add the official repository.

Execute the below three commands

• This command will load the OpenVPN public GPG key.

• This command will add the OpenVPN access server repository to your machine.

• This command will check all configured repositories for updates.

Step 4) Install OpenVPN access server.

Now the fun begins! To install, execute the below command

Hooray, you've just installed OpenVPN access server! Pay attention to this part of the debug, it contains valuable information.

The Admin UI is for making changes to the server config and adding users.

Step 5) Configuring the server for remote access.

Browse to your Admin UI URL. You'll receive a certificate warning, you can safely ignore this and continue. Once completed, you'll see the below UI.

Please login, read and accept the EULA and we are ready to go!

We need to make a few network changes, for this please navigate to Configuration > Network Settings

Step 5.1) - Changing the VPN traffic port

Please find the "Multi-Daemon Mode" section, and edit both ports away from the default ports. This is for security purposes. These ports can be the same number. I picked 9514, but this is an example only, I recommend choosing your own ports.

Step 5.2) - Adding in your public IP

Please don't navigate away from the "Network Settings" page for now. But you will need to open the below URL in a new tab.

Copy your IP address from this website and paste it in the "Hostname or IP Address" field located at the top of the "Network Settings" page. This will already be populated with your private IP address, you must overwrite it with your public one.

Step 5.3) Configure the admin UI and client UI to run on different ports.

This step is optional but for security purposes I heavily recommend it.

We are going to configure the admin UI and the client UI to run on different ports because we only need to publicly access the client UI.

On the same page "Network Settings", please scroll down to the bottom and find "Client Web Server" and toggle the "Use a different IP address or port" setting.

Now we can change which port we want the client web server to run on, you can make this any port of your choosing. I chose 9515.

From here, please click "Save Settings" and then "Update Running Server"

Once the running server has been updated, you may need to refresh your browser and log back into the admin UI.

Step 5.4) Enforce MFA on all user accounts

This step is also optional, but for security purposes I also heavily recommend it.

We are going to require that all user accounts setup and use 2FA so in the worst case scenario where someone did get your otherwise guess your user credentials, they won't be able to gain access.

Please navigate to Authentication > Settings

Please find the "TOTP Multi-Factor Authentication" setting and toggle it

Once the setting has been changed, you must again click "Save Settings" down the bottom and then "Update running server" as shown in the bottom of the last example (Step 5.3).

Step 5.5) Advanced users only - Adding a static route

If you are an advanced user - You may have setup your OpenVPN server on a different subnet than your Ethereum nodes/validators.

If that is the case, you will need to browse to "Configuration > VPN Settings" and add in a static route for your validator network.

If they are not on separate subnets, please continue onto step 6.

Step 6) Adding user accounts.

Step 6.1) - Create a new user and set a password

Please navigate to "User management" > "User Permissions".

From here, you can add a new user. Please type out a username and tick the "Allow Auto-login" box, then select the "More Settings" box.

You can now set a password for the account in the new options that appear when you click "More Settings".

Once done, please "Save Settings" and "Update Running Server" again.

Step 6.2) Advanced users only - Allow access to another network

Step 7) Unblock local ports.

If you are using a local firewall (which you should be), you may need to unblock the local ports depending on how you have it configured.

Almost there!

Step 8) Port forwarding.

For this step you will need to login to your router and forward ports to the machine running OpenVPN access server. The exact workflow is router dependent, so please search online for instructions and include your router make and model in the search.

You will need to forward two ports, both TCP/UDP.

• The port(s) you entered for "Multi-Daemon Mode" (I used 9514)

• The port you entered for "Client Web Server" (I used 9515)

Once completed, please browse to the below website and enter in your ports to check if they are forwarded correctly.

Step 9) - Configure a device for VPN access.

If you've made it this far, then congrats! You will be pleased to know that all the hard stuff is out of the way.

Please complete this step on the device you want to set up remote access.

NOTE: If you enabled MFA as per step 5.4, then after logging in you will be prompted to setup a 2FA credential. You can use something like Google Authenticator or Authy. I heavily recommend enabling this as the extra security is definitely worth it.

Step 9.1 ) - Install OpenVPN client

Please select the OS you are using.

From here you can select a client for your device.

• If on Windows or Mac, it will automatically download the OpenVPN client software and guide you through the rest of the process.

• If on Linux, Android or iOS, it will take you to an external page with further instructions.

Step 9.2) Download the client user profile

Please download the "autologin profile".

Once done, you will have to import the profile into the OpenVPN software. The software itself (Windows or Mac) or external pages (Linux, Android or iOS) will show you how to do this.

Step 10) - Connect to the VPN

Lucky you, I saved the easiest step for last.

• If using a laptop or desktop, please connect to another network such as a mobile hotspot.

• If using a phone, please disconnect from your WiFi and ensure you are connected to your telco's internet.

Go back to the OpenVPN software and hit connect and you'll be connected in just a matter of seconds.

If the connection was successful, you will see it now matches your home IP as you are now connected to your home internet connection. From here you can securely SSH into your Ethereum nodes/validators.

If you can connect to your home network but are unable to SSH into your servers, you may need to tweak the firewall on your Ethereum node to accept incoming SSH connections from the IP address of your OpenVPN server.

FAQ

Can I connect to this VPN while also using a different VPN provider?

No. At least not easily. To get this to work you will need to write your own IP tables.

Does the client UI need to be exposed to the internet?

No. If you can access the server within your local network and download and setup your user profile, then you won't need to access the client UI externally.

However if you aren't within your local network and you need to redownload a user profile (For example if you are travelling and your phone/laptop dies and you get a new one) then you won't be able to login to the portal and download a new user profile.

To protect your server from brute-force SSH connection attempts, you can install fail2ban.

This program will monitor incoming connections and block IP addresses that try to log in with faulty credentials repeatedly.

You can change the maxretry setting, which is the number of attempts it will allow before locking the offending address out.

Save the file and restart the service.

Congratulations! You've successfully improved the security of your node 🥳

It is very important that you forward ports to both your Ethereum execution and consensus clients, this ensures you are able to peer with other nodes efficiently.

Your execution and consensus client will still run without port forwarding, but you may notice it will take a very long time to find peers, and you may struggle to connect with a meaningful number of them too. So it is in your best interest (and heavily recommended) to have them forwarded.

Below are a list of the default ports that the software(s) are set to listen on.

If your node is running and the port(s) have been forwarded, you can use an online tool to check whether the ports are forwarded correctly.

For more information on how to actually forward the ports, it is best to search for instructions via google, make sure to include your router make and model as the specific steps taken to forward ports will vary depending on your router.

Static IP's

It is also recommended to configure your node with a static IP. This can be hardcoded on the machine itself or set as a reservation on your DHCP server (which is usually your router).

If your node gets a dynamic IP address assigned to it, there is always the chance that your machine may get assigned a different IP address and your port forwarding will no longer work as they will be pointing to the old IP.

If you would like to log into your home network remotely, such as while on vacation or on a business trip, the most common route is to use a Virtual Private Network server. This will allow you to connect to your node via SSH and view your monitoring dashboards from anywhere in the world, all without exposing your SSH port to the internet.

Many node operators use as their VPN server of choice for this. Tailscale is an open-source P2P VPN tunnel and hosted endpoint discovery service. It takes care of authentication, publication, and the NAT traversal required to establish an end-to-end encrypted path between your machine and your node without sending any sensitive traffic to a centralized server. It is a very powerful tool.

We will briefly cover a basic configuration of it, but feel free to for more details.

Setting Tailscale Up

First, create a free . Tailscale requires the use of an SSO identity provider such as Google, GitHub, Okta, Microsoft, etc. For details, visit .

It is recommended that you enable 2FA (Two Factor Authentication) on whichever identity provider you choose for added security.

Next, follow to install Tailscale on your client - the machine you want to connect to your network with. For example, this could be a laptop or your phone. Note that it is not your validator node!

Once completed you should see your computer as 'connected' on the .

Now, install Tailscale on your node:

Finally, authenticate and connect your machine to your Tailscale network on your node:

You’re connected! You can find your Tailscale IPv4 address by running:

You should now be able to exit the SSH session to your node on your client, and SSH into your node again through Tailscale using ssh <user>@<node-name> -p <ssh-port>.

Updating UFW

Run these commands on the node machine.

Allow access to all incoming ssh connections over Tailscale.

You may also remove access to the SSH port to completely lock down your node. Note that you will not be able to log in from the local network as Tailscale will become the only way to log in. Only run the following command if you are okay with this.

Once you’ve set up firewall rules to restrict all non-Tailscale connections, restart UFW and SSH:

Now, confirm that everything is working as expected. exit from one of your current SSH sessions (but remember to keep the second one open as a backup). Next, connect to the node machine via SSH using the Tailscale IP address or hostname: ssh <user>@<node-name> -p <ssh-port>

If it works, you did everything right and can now safely log into your home network while abroad!

Validator effectiveness can be thought of as how useful an attestation is to the network, considering both block production and inclusion distance.

Attestation Inclusion Process

How are attestations included on the Ethereum network? The process is roughly as follows:

This is a simplified view of attesting, but can be a useful starting point.

1. Every attesting validator generates an attestation with the data it has available about the state of the chain.

2. The attestation is propagated around the Ethereum network to relevant aggregators.

3. Every relevant aggregator that receives the attestation aggregates it with other attestations that have the same claims.

4. The aggregated attestation is propagated around the Ethereum network to all nodes.

5. Any validator that is proposing a block and has yet to see the aggregated attestation on the chain adds the aggregated attestation to the block.

Whenever an attestation has an inclusion distance greater than 1 it is important to understand why. There are a number of possible reasons:

Attestation Generation Delay

A validator may have problems that result in delayed attestation generation. For example, it may have out-of-date information regarding the state of the chain, or the validator may be underpowered and take a significant amount of time to generate and sign the attestation. Regardless of the reason, a delayed attestation has a potential knock-on effect for the rest of the steps in the process.

Attestation Propagation Delay

Once an attestation has been generated by a validator it needs to propagate across the network to the aggregators. The nature of this process means that early propagation is critical to ensure that it is received by an aggregator in time for integration into the aggregated attestation before broadcasting. Validators should attempt to ensure they are connected to enough varied peers to ensure fast propagation to aggregators.

Aggregate Generation Delay

An aggregator can delay the attestation aggregation process. Most commonly this is because the node is already overloaded by generating attestations, but the speed of the aggregation algorithm can also cause significant delays when there is a large number of validators that need to be aggregated.

Aggregate Propagation Delay

Similar to attestation propagation delay, the aggregation attestation needs to make its way around the network and can suffer the same delays.

Block Production Failure

For an attestation to become part of the chain it needs to be included in a block. However, block production is not guaranteed. A block may not be produced because a validator is offline, or is out of sync with the rest of the network and so produces a block with invalid data that is rejected by the chain. Without a block there is no way to include the attestation in the chain at that slot, resulting in a higher than optimal inclusion distance.

Block production failure has a second impact, which is that it increases the total number of attestations that are eligible for inclusion in the next block that is produced. If there are more attestations available than can fit in a block the producer is likely to include the attestations that return the highest reward, which will be those with the lowest inclusion distance. This can result in attestations that miss their optimal block also missing subsequent blocks due to being less and less attractive to include.

The fact that block production is out of the validator’s control (except for those the validator itself produces) requires the definition of the term earliest inclusion slot, where the earliest inclusion slot is the first slot greater than the attestation slot in which a valid block is produced. This takes in to account the fact that attestations cannot be included in blocks that do not exist, and is no reflection on the effectiveness of the validator.

Malicious Activity

It is possible for a malicious actor to refuse to include any given attestations in their aggregates, or to refuse to include attestations in their blocks. The former is mitigated by having multiple aggregators for each attestation group, and the latter by the cost of excluding an aggregated attestation. Ultimately, however, if the cost of excluding an attestation from a block is compensated for monetarily, or is considered to have a higher value politically, there is nothing an attesting validator can do to force inclusion by a block-producing validator.

Calculating Attestation Effectiveness

Attestation effectiveness can be thought of as how useful an attestation is to the network, considering both block production and inclusion distance. It is formally defined as:

(earliest inclusion slot - attestation slot) / (actual inclusion slot - attestation slot)

Effectiveness is represented as a percentage value. An attestation that fails to be included with the maximum inclusion distance of 32 is considered to have an effectiveness of 0. Here are some example effectiveness calculations:

Aggregate Attestation Effectiveness

Attestation effectiveness for a single attestation is interesting but not very useful by itself. Aggregating effectiveness over multiple attestations, both over time and multiple validators, gives a better view of the overall effectiveness of a group of validators. Aggregate effectiveness can be calculated as a simple average of individual attestation effectiveness, for example a 7-day trailing average across all validators in a given group.

Source ↗

MEV Boost Information and Guides

• Beaconcha.in Relays ↗

• CoinCashew MEV-boost guide ↗

• Flashbots docs ↗

• Flashbots GitHub ↗

• Inclusion Watch ↗

• mevboost.org ↗ - Tracker with real-time stats for MEV-Boost relays and block builders.

• mevboost.pics ↗

• MEV-Explore ↗ - Dashboard and live transaction explorer for MEV transactions.

• MEV Panda ↗

• MEV relay list ↗

• MEV Watch ↗

• Rated Network ↗

• Relay Monitor ↗

• Relay Scan ↗

• Tornado Warnings ↗

• Transparency dashboard ↗

• Uptime Monitor ↗

Checkpoint sync, also known as weak subjectivity sync, creates a superior user experience for syncing Beacon Node. It's based on assumptions of weak subjectivity↗ which enables syncing Beacon Chain from a recent weak subjectivity checkpoint instead of genesis. Checkpoint sync makes the initial sync time significantly faster with similar trust assumptions as syncing from genesis.

In practice, this means your node connects to a remote service to download recent finalized states and continues verifying data from that point. The third-party providing the data needs to be trusted to provide the correct information about the finalized state and should be picked carefully.

Validate against a known trusted source

You must verify the slot and state_root against a known trusted source. This can be a friend, someone from the community that you know or any other source that you trust. There is a maintained list of publicly hosted checkpoint sync endpoints here↗, but it is recommended to use your own trusted source first if possible.

You will need to know the IP & Port of your beacon node.

Obtaining slot and state root

Option A:

1. Check your consensus client logs

2. Find the slot number.

3. Find the state_root value.

Option B:

1. Open http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized in your browser.

2. Find the slot number.

3. Find the state_root value.

Option C:

1. Install curl and jq.

2. In a new terminal window run:

   Copy

   curl -s http://YOUR_NODE_IP:YOUR_NODE_PORT/eth/v1/beacon/headers/finalized | jq .'data.header.message'

If the slot and state_root from your validator matches the slot and state_root from (multiple) other sources, then it's a match, congratulations 🎉. If it's not a match you should start from scratch by wiping your beacon node and starting from the top.

Technical notes on checkpoint sync ↗

Weak Subjectivity ↗

This is a list of high quality staking guides that are recommended on ethereum.org ↗:

• CoinCashew's Ethereum 2.0 Guide - Linux (CLI) ↗

• Somer Esat - Linux (CLI) ↗

• Rocket Pool Node Operators - Linux, macOS (CLI) ↗

It's critically important for the health and long term sustainability of Ethereum that there is a diverse and balanced client ecosystem. Multiple, independently developed and maintained clients exist because client diversity makes the network more resilient to attacks and bugs. Multiple clients is a strength unique to Ethereum - other blockchains rely on the infallibility of a single client. However, it is not enough simply to have multiple, clients available, they have to be adopted by the community and the total active nodes distributed relatively evenly across them.

Please consider running a minority client to support Ethereum.

More information on client diversity can be found on ethereum.org ↗

Even if you have a large SSD installed, you may only have (Ubuntu Server) 200GB of total available space depending on whether or not you have a LVM configured for your disk.

This can cause the system to run out of disk space when syncing.

The error message is similar to:

Fatal: Failed to register the Ethereum service: write /var/lib/goethereum/geth/chaindata/383234.ldb: no space left on device

To address this issue, assuming you have an SSD that is larger than 200GB, expand the space allocation for the LVM by following these steps:

sudo lvdisplay # Check your logical volume size

sudo lvm # Attach the lvm console
lvextend -l +100%FREE /dev/ubuntu-vg/ubuntu-lv
lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv
exit

sudo resize2fs /dev/ubuntu-vg/ubuntu-lv
df -h # Check results

Congratulations! You're now using all available disk space on your staking machine 🥳

Automatic security updates are helpful when you are not able to access your machine but want critical security updates to be applied automatically.

sudo apt-get update -y
sudo apt-get install -y unattended-upgrades update-notifier-common

sudo vim /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since all services should auto-start on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

sudo systemctl enable unattended-upgrades
sudo systemctl restart unattended-upgrades

Update system packages again.

sudo apt-get update -y
sudo apt-get upgrade -y
sudo apt-get dist-upgrade -y

Restart the machine.

sudo shutdown -r now

Congratulations! You've successfully enabled unattended-upgrades on your staking machine 🥳

Lighthouse Slashing Protection

The Lighthouse validator client includes a mechanism to protect its validators against accidental slashing, known as the slashing protection database. This database records every block and attestation signed by validators, and the validator client uses this information to avoid signing any slashable messages.

Lighthouse Slashing Protection Documentation ↗

The Ethereum community maintains multiple open-source execution clients (previously known as 'Eth1 clients', or just 'Ethereum clients'), developed by different teams using different programming languages. This makes the network stronger and more diverse. The ideal goal is to achieve diversity without any client dominating to reduce any single points of failure.

Geth

Go Ethereum (Geth for short) is one of the original implementations of the Ethereum protocol. Currently, it is the most widespread client with the biggest user base and variety of tooling for users and developers. It is written in Go, fully open source and licensed under the GNU LGPL v3.

Besu

Hyperledger Besu is an enterprise-grade Ethereum client for public and permissioned networks. It runs all of the Ethereum Mainnet features, from tracing to GraphQL, has extensive monitoring and is supported by ConsenSys, both in open community channels and through commercial SLAs for enterprises. It is written in Java and is Apache 2.0 licensed.

Besu's extensive documentation will guide you through all details on its features and setups.

Nethermind

Nethermind is an Ethereum implementation created with the C# .NET tech stack, licensed with LGPL-3.0, running on all major platforms including ARM. It offers great performance with:

• An optimized virtual machine.

• State access.

• Networking and rich features like Prometheus/Grafana dashboards, seq enterprise logging support, JSON RPC tracing, and analytics plugins.

Erigon

Erigon, formerly known as Turbo‐Geth, started as a fork of Go Ethereum oriented toward speed and disk‐space efficiency. Erigon is a completely re-architected implementation of Ethereum, currently written in Go but with implementations in other languages under development. Erigon's goal is to provide a faster, more modular, and more optimized implementation of Ethereum. It can perform a full archive node sync using around 2TB of disk space, in under 3 days.

Consensus clients run the Beacon Chain and provide a proof-of-stake (PoS) consensus mechanism to execution clients.

Consensus clients all follow the same specification ↗. If a client doesn't follow this spec it won't be able to come to consensus with the rest of the network.

Lighthouse

Lighthouse is a consensus client implementation written in Rust under the Apache-2.0 license. It is maintained by Sigma Prime and has been stable and production-ready since Beacon Chain genesis. It is relied upon by various enterprises, staking pools and individuals. It aims to be secure, performant and interoperable in a wide range of environments, from desktop PCs to sophisticated automated deployments.

Lodestar

Lodestar is a production-ready consensus client implementation written in Typescript under the LGPL-3.0 license. It is maintained by ChainSafe Systems and is the newest of the consensus clients for solo-stakers, developers and researchers. Lodestar consists of a beacon node and validator client powered by JavaScript implementations of Ethereum protocols. Lodestar aims to improve Ethereum usability with light clients, expand accessibility to a larger group of developers and further contribute to ecosystem diversity.

Nimbus

Nimbus is a consensus client implementation written in Nim under the Apache-2.0 license. It is a production-ready client in use by solo-stakers and staking pools. Nimbus is designed for resource efficiency, making it easy to run on resource-restricted devices and enterprise infrastructure with equal ease, without compromising stability or reward performance. A lighter resource footprint means the client has a greater margin of safety when the network is under stress.

Implemented by Trinity. Works like fast sync but also downloads the data needed to execute latest blocks, which allows you to query the chain within the first few minutes from starting.

• Syncs state first and enables you to query RPC in a few minutes.

Prysm

Prysm is a full-featured, open source consensus client written in Go under the GPL-3.0 license. It features an optional webapp UI and prioritizes user experience, documentation, and configurability for both stake-at-home and institutional users.

Teku

Teku is one of the original Beacon Chain genesis clients. Alongside the usual goals (security, robustness, stability, usability, performance), Teku specifically aims to comply fully with all the various consensus client standards.

Teku offers very flexible deployment options. The beacon node and validator client can be run together as a single process, which is extremely convenient for solo stakers, or nodes can be run separately for sophisticated staking operations. In addition, Teku is fully interoperable with Web3Signer↗ for signing key security and slashing protection.

Teku is written in Java and is Apache 2.0 licensed. It is developed by the Protocols team at ConsenSys that is also responsible for Besu and Web3Signer.

These tools can be used as an alternative to the Staking Deposit CLI ↗ to help with key generation.

Source ↗

Connecting remotely to a staking machine, whether it's hosted by a cloud provider (AWS, etc.) or running in your home is most often achieved using SSH (Secure Shell).

SSH is a command line tool that allows direct access to a remote machine. This tutorial will cover:

1. Installing SSH on your staking machine

2. Connecting to your staking machine using SSH

3. Using Mosh to improve your remote connection experience

4. Using Blink for iOS for mobile connections

5. Generating SSH keys

6. Changing the default SSH Port

This tutorial won't cover the networking setup required to get a static IP, hostname and/or VPN as those are covered in other tutorials.

While SSH on its own is a great tool, there are some limitations that can be frustrating when connecting over a poor internet connection. For example, if the internet drops even for a second (if you're in a moving car or train) or you change WiFi networks, the SSH connection will be closed.

Installing SSH on your staking machine

When you installed Linux on your staking machine the installation options should have asked if you would like to install SSH during the setup process.

To check if SSH is installed on your staking machine run the command:

ssh -V

If SSH is installed you should see a response showing the installed version:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022

If you get an error or don't see the version output then it's likely that the SSH server is not installed. When you want to install any new packages to your Linux system it's best practice to make sure that your current packages are up to date for security purposes:

sudo apt-get update

Then install openssh-server:

sudo apt-get install -y openssh-server

If you are using UFW as your firewall and have restricted incoming and outgoing connections then you will need to add the SSH port to allow remote connections (replacing <SSH_PORT> with the configured SSH port - the default port is 22):

sudo ufw allow in <SSH_PORT> comment 'Allow SSH in'

Connecting to your staking machine using SSH

Once you have confirmed SSH is installed on your staking machine, you can connect from a different machine using the command:

ssh <USERNAME>@<IP_ADDRESS>

For example: ssh eridian@186:204:70:208

This command attempts to connect with your user's username at the specific IP address (or Host Name) of your staking machine.

You may get a prompt saying something like "You haven't connected to this machine before, do you want to trust it?" to which you should submit Yes as the response.

At this point, if everything is configured correctly, you should be prompted to input your password. This is the password you use to log in with your staking machine user.

If you are using a different port for your SSH connection then you can specify the port when connecting using:

ssh -p <PORT> <USERNAME>@<IP_ADDRESS>

Using Mosh to improve your remote connection experience

Benefits of using Mosh:

• If you have an intermittent internet connection (e.g. a mobile connection or you're in a moving vehicle) a standard SSH connection will fail whenever the connection is lost. The connection must then be manually re-established, which can be annoying if it happens often and you are using additional security steps such as 2FA. Mosh allows connections to be dropped and automatically re-established when the internet signal reconnects.

• Mosh uses a predictive interface for typing commands into the console. Standard SSH only shows the typed command once it has returned from the remote server. If you have a slow connection, this can be perceived as a laggy/slow interface. Mosh displays the text as you type commands, giving a much nicer user experience.

Limitations of using Mosh:

• A limitation you will notice when using Mosh is that you can't scroll back up the terminal history. This is due to the way Mosh only renders the current screen, which has some performance advantages but can be frustrating if you miss something and can't scroll back to see it.

The Mosh package should be installed on both sides of the connection. That means both your staking machine and the machine you want to connect from (e.g. your everyday computer) will need Mosh↗ installed.

Install Mosh on your staking machine:

sudo apt-get install -y mosh

If you are using UFW, allowing Mosh ports through the firewall:

sudo ufw allow in 60000:60020/udp comment 'Allow Mosh in'

Mosh uses the same connection method as SSH, so once it is installed and the ports have been allowed it should be as simple as connecting with the command:

sudo mosh <USERNAME>@<IP_ADDRESS>

If you have changed the default SSH port you can specific the port used by Mosh using the command:

sudo mosh --ssh="ssh -p <MODIFIED_SSH_PORT>" <USERNAME>@<IP_ADDRESS>

Using Blink Shell for iOS for mobile connections

The Blink Shell↗ mobile app for iOS allows you to connect to your staking machine using both SSH and Mosh.

On your device (iPhone or iPad) open the Blink Shell app and type:

config

Keys & Certificates can be added if you are using an SSH key for your connections:

Hosts can be configured so you have an alias command e.g. ssh validator that you can use with preconfigured settings

iCloud sync can be turned off if you don't want your SSH keys and passwords to be stored in iCLoud.

Auto Lock is a useful feature to add additional security to your portable device.

And that's it! You can now connect to your home staking validator remotely from your iOS device 🗺️

Generating SSH keys

For additional security, SSH keys can be used alongside or instead of your username/password authentication when connecting to your staking machine.

Follow the instructions here to generate SSH keys: https://linuxconfig.org/how-to-generate-and-manage-ssh-keys-on-linux

Changing the default SSH Port

The default port configured is 22 for SSH connections. If you want to change the default port for any reason (e.g. due to port forwarding on your router or the port being used by another service) follow these steps:

1. Open the /etc/ssh/sshd_config file and locate the line:

   Copy

   #Port 22

2. Uncomment that line (by removing the leading # character) and change the value with an appropriate port number (for example, 22000):

   Copy

   Port 22000

3. Save the change.

4. Restart the SSH server:

   Copy

   systemctl restart sshd

5. To confirm the port has been updated correctly run:

   Copy

   sudo netstat -tulpn | grep ssh

6. The result should show the new port number:

   Copy

   tcp        0      0 0.0.0.0:22000           0.0.0.0:*               LISTEN      1282/sshd: /usr/
   sbi 
   tcp6       0      0 :::22000                :::*                    LISTEN      1282/sshd: /usr/
   sbi 

To install Linux on a physical machine here are the steps to follow:

1. Download a Linux distribution image onto your everyday computer.

2. Flash a USB with the distribution image.

3. Boot your staking machine from the USB.

4. Select the right options for your installation.

Download a Linux distribution image

There are lots of Linux distributions available. If you are an experienced Linux user then you will already know which distribution you want to use based on your skills and ability. However, if you are a new Linux user or just want to keep things simple, then the recommended Linux distribution is Ubuntu Linux.

There are two types of distribution that you can choose:

• Desktop: https://ubuntu.com/download/desktop↗

• Server: https://ubuntu.com/download/server↗

Desktop comes with a graphical interface that is similar to Windows or macOS desktops. For staking machines, the desktop version isn't ideal as it comes with additional overhead that isn't required, but it can be easier for new users who feel more comfortable with a graphical interface.

Server is a command line only interface. This can feel intimidating at first, but when following solo staking guides you will simply be copying and pasting commands, so it's not too difficult. You can remotely connect to your staking machine securely using protocols like SSH, but the easiest way to get started is to directly connect a keyboard and monitor. SSH can always be used later.

Flash a USB with the distribution image

There are lots of tools available to flash USB drives with disk images. One that is open source and works across multiple platforms is https://www.balena.io/etcher↗. Simply select the Linux distribution image you downloaded previously, select the USB, then Flash!

Boot your staking machine from the USB

This step should be as easy as inserting the USB that you flashed with the disk image in the previous step and then turning on your staking machine. In some cases, you may need to force the machine to boot from the USB rather than any currently installed OS. This can be done by editing the BIOS boot order and allowing booting from USB. Google is the best place to find information about booting from a USB if you do encounter any problems at this stage.

Select the right options for your installation

Once you have booted from a USB you will be presented with an installation menu. Use the arrow keys (up and down) to move the selection and use the return key (enter) to select the option.

After selecting Try or Install Ubuntu Server you will see a screen like this. You don't need to do anything at this point, the system is just starting up.

Once the system has started you will be presented with the installation wizard. The first step is to select the language.

Select the keyboard layout.

Select the installation type you want to use. For this, select Ubuntu Server.

Select a network. If your staking machine uses an ethernet cable for a direct network connection (recommended) then this option should already be populated. If using WiFi, select those details.

Select a proxy if required. If you are using a standard home network and don't know what this option means, don't worry, just leave it blank.

Select where you want to download the updates for the operating system from. This location can be selected based on your geographic location so that the downloads are faster. But it's easier to just select the default option that's pre-populated.

Select the storage configuration. As your staking machine is most likely a dedicated machine selecting Use an entire disk is the best option. Don't worry about encryption as you want your machine to be able to automatically restart, and encrypted disks make that process much more complex.

You'll be shown a summary screen of the storage configuration. Linux by default may not use the entire available disk space. In the screenshot above the local storage size is shown as 1.171 Terabytes, but the confirmation screen below only shows 100GB being used.

To use all the available disk space, use the arrow keys to highlight the ubuntu-lv row and hit the return/enter key to select Edit. Enter the Max value shown next to Size in the input field, then save the update.

After confirming the storage settings you will be presented with an additional confirmation screen to make sure that you're ready to completely format and wipe any existing data on the storage disk. That's what we want, so select Continue.

Setting up the user profile is important as it's how you will access the machine, both directly and remotely. Select a name for your user and the name for your server that will appear on your local network. Your username is used to login to the machine and the password protects your user account.

At this point it's a good idea to set up the SSH server so you don't have to install it manually later. If you never intend to SSH into your staking machine and only connect to it directly with a keyboard and monitor then you don't need this option. For information on SSH connections see the tutorial Connect with SSH.

This screen might be displayed asking you to select or deselect popular snaps. Don't worry about this page, it might even be empty for you. Simply move on to the next screen.

At this point, the installation will begin using all the configuration settings you've provided. This can take a few minutes (10 or more) depending on your hardware and configuration. You don't need to do anything, just wait until it completes. At the end of the installation process, you will need to reboot your machine. Select Reboot Now and it will ask you to remove the installation device (the USB you used during the installation).

Once the system reboots you'll see startup information similar to the output below. Wait until that completes and you'll be shown a login screen.

This is the login screen for your validator machine. The name of this machine is eridian-validator.

Enter the username you created during the installation. You will then be prompted for your password. As you type your password nothing will be shown on the command line (so it will look like it's not working!) but don't worry, this is for security and the typing is working.

And... you're in!

Congratulations! You've successfully installed Ubuntu Linux server on your staking machine 🥳

At this point, you are now "on the command line" and can start to work through many of the solo staking guides.

A common reason for Geth to fail can be an unexpected shutdown of a validator machine. Geth uses RAM for temporary memory and during a graceful shutdown some important information will be written to disk. However, during an unexpected shutdown, there isn't time to write to disk (e.g. due to a sudden loss of power) so important data is lost. This loss of data leads to a corruption of the chaindata folder, requiring a resync.

File Locations

• Standard location of the chaindata folder.

• Standard location of the ancient folder.

Steps (If the ancient folder exists)

Good news! The required resync can be made much faster than a full resync simply by keeping the ancient folder. The ancient folder contains files that are not corrupted during an unexpected shutdown.

1. Stop Geth.

2. Move the ancient folder.

3. Delete the chaindata directory and recreate it.

4. Move the ancient folder back to the now empty chaindata directory.

5. Change the ownership of the chaindata directory to the Geth user.

6. Start Geth.

Congratulations! You've successfully started a Geth resync 🥳

Steps (If the ancient folder does not exist)

If the ancient folder does not exist, that's not a problem. It just means you will need to resync Geth from scratch, which will take a bit longer.

1. Stop Geth.

2. Delete the chaindata directory and recreate it.
3. Confirm the ownership and permissions for the chaindata directory are set to the Geth user.
4. Start Geth.

Congratulations! You've successfully started a Geth resync 🥳

Two-factor authentication involves requiring a second security measure in addition to your password or SSH key, usually on a separate device from your primary one.

For example, you may be familiar with logging into a website such as a crypto exchange using both a password and a Google Authenticator code (or an SMS code). This two-step process is an example of two-factor authentication.

SSH can also be configured to require a Google Authenticator code, which means that an attacker that somehow compromised your SSH key and its passphrase would still need the device with the authenticator app on it (presumably your phone). This adds an extra layer of security to your system.

Start by installing (or a compatible equivalent) on your phone if you don't already have it. For Android users, consider which is an open-source alternative that supports password locking and convenient backups.

Next, install the Google Authenticator module on your node with this command:

Now tell the PAM (pluggable authentication modules) to use this module. First, open the config file:

Find @include common-auth (it should be at the top) and comment it out by adding a # in front of it, so it looks like this:

Next, add these lines to the top of the file:

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that PAM knows to use Google Authenticator, the next step is to tell sshd to use PAM. Open the sshd config file:

Now change the line KbdInteractiveAuthentication no to KbdInteractiveAuthentication yes so it looks like this:

(Older versions of SSH call this option ChallengeResponseAuthentication instead of KbdInteractiveAuthentication.)

Add the following line to the bottom of the file, which indicates to sshd that it needs both an SSH key and the Google Authenticator code:

Every option added to AuthenticationMethods will be required when you log in. So you can choose e.g. 2FA and password, or a combination of all three methods.

• publickey (SSH key)

• password publickey (password)

• keyboard-interactive (2FA verification code)

Then save and exit the file with Ctrl+O, Enter, and Ctrl+X.

Now that sshd is set up, we need to create our 2FA codes. In your terminal, run:

First, it will ask you about time-based tokens. Say y to this question:

You will now see a big QR code on your screen; scan it with your Google Authenticator app to add it. You will also see your secret and a few backup codes looking like this:

Finally, it will ask you for some more parameters; the recommended defaults are as follows:

Once you're done, restart sshd so it grabs the new settings:

When you try to SSH into your server with your SSH keys, you should now also be asked for a 2FA verification code, but not for a password.

With that out of the way, let's get into it. There are a few things that you can do to minimize your potential downtime.

There will always be situations where you will have downtime, it is inevitable when running a validator so please don't chase a perfect attestation record. There are however some things you can do to minimize downtime.

The below ideas may or may not be feasible depending on how many validators you are running. Please weigh up the pros and cons yourself and decide if it is appropriate for you to do in your circumstances.

Connecting your node and router to a UPS

This will ensure abrupt shutdowns don't occur potentially saving your hardware from breaking, or your DB/OS from corrupting saving you a resync/reinstall. More information can be found about this on the

Running multiple Consensus-Execution client pairs.

Either on the same machine but on a different SSD or an entirely separate machine and running different consensus/execution client software. A separate machine is more important if you are running a sizeable number of validators, otherwise, it may be overkill.

It is perfectly safe to run multiple nodes for redundancy, just not multiple validators.

The benefit of doing this is you won't have any downtime should one of the client pairs go offline, or corrupt, or if the SSD where it is sitting breaks and it requires manual maintenance to bring back online. You'll be able to fix the broken node in your own time while the validator will happily use the other configured beacon node and continue performing its duties.

You can even take it a step further and have your validator client on a separate SSD (For example, with your OS) and have it point to your beacon nodes, both of which would also be on separate SSDs, with less points of failure all around.

Having spare hardware ready to go.

It can be useful to have a spare SSD ready to be swapped out in case of hardware failure. You will be able to immediately start the process to recover your nodes/validators and when that is done you can then buy a replacement drive at your own leisure.

If you travel around a lot, you could even have it plugged into your machine on standby ready to go meaning your node could be recovered remotely, unless of course, the drive that fails is your OS drive.

There will be times when you are offline and are missing attestations, do not stress or panic when this happens and focus on getting yourself back online. If for example, you are offline for 4 hours, it will take 4 hours of being online to be back where you started in terms of validator balance.

For more information about downtime see our helper posts:

Exiting a validator requires a signed message to be sent from your validator client. The withdrawal process is different for each client. These links are for each specific client:

This page will show you how to configure your execution client to serve HTTP RPC requests.

This will allow you to interact directly with the Ethereum network using your own node. No need to use a 3rd party service like Infura anymore!

1) Configure your execution client

You will need to add the following flags to your execution client.

2) Configure your wallet

The below example will show you how to use your RPC endpoint with Metamask as it is one of the most commonly used wallets.

2.1) Open Metamask, click the menu icon at the top right, and select "Add Network"

2.2) Scroll down the bottom and select "Add a network manually"

2.3) Fill in your node details

The specific details will vary depending on your local setup. As I am running Geth on the same machine as my Metamask installation, so I am using 127.0.0.1 as the IP address.

If your RPC is unavailable or otherwise inaccessible, it may show an error when you enter the Chain ID and won't allow you to save the network.

2.4) Look out for the confirmation message

2.5) Swap to your new network if Metamask hasn't done so already

Success! Now you can use Metamask as you normally would with the added benefit of accessing the Ethereum network through your own node 🥳

When migrating validator keys, take your time, do not rush!

There are many scenarios where you need to move the validator keys from one machine to another, here are some examples:

• ⬆️ Upgrading hardware.

• 🔧 Recovering from a hardware failure.

• ☁️ Migrating from a cloud hosting service to a home staking machine.

In any of these cases, the procedure should be the same. The most important thing to remember is that the penalty for being offline is very low, so do not optimize for minimum downtime. A slashing event caused by incorrect key migration will incur a penalty equivalent to MONTHS of simply being offline.

🚨 Do not rush 🚨

Definitions

Source: Where the keys are coming from. Target: Where the keys are being migrated to.

Steps

1. Stop the validator client on the source machine.

2. Stop the validator client on the target machine.

3. Wait a MINIMUM of 2 finalized before continuing.

4. Copy the validator keys to the target machine either through intermediate storage (e.g. a USB) or directly from source to target machine (e.g. scp, rsync, etc.). If the validator keys have been lost due to a hardware failure, .

5. Delete the keys from the source machine. This ensures that even if the source machine restarts unexpectedly, the validator signing keys won't exist so cannot be used by the validator client.

6. If available, export any from the source machine and import on the target machine.

7. Turn off the source machine and be 100% sure it cannot be restarted.

8. Start the validator client on the target machine.

9. Import the validator keys.

10. Check the validator client logs to confirm everything is working correctly.

Congratulations! You've successfully migrated your validator keys between two machines 🥳