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.

You can earn GitPOAPs by contributing directly to the EthStaker Knowledge Base (a contributor↗) and by asking a question that leads to content being created (a supporter↗).

To suggest changes or add new content please visit our EthStaker Github↗ or if you have any questions please join our Discord↗.

Please create a pull request for any changes you want to make and we'll review it as soon as possible.

• Documentation standardization notes

• Creating/Updating tables of contents

• Glossary and FAQ heading ordering

• Future support for multi-language

Documentation standardization notes

Please use these notes when writing for this knowledge base to maintain a standardized format.

• Use relative links ↗ to navigate between different files within this knowledge base.

  • [Other file link](other_file.md) → Other file link

• Use anchor links to headings within the same file.

  • [Anchor link](#heading-anchor) → Anchor link

• Combine relative links to other files with anchor links.

  • [Other file anchor link](other_file.md#heading-anchor) → Other file link

• Show when a link is referencing an external site by adding the ↗ icon at the end of the link.

  • [External site link ↗](https://example.com) → External site link ↗

• Create an image that's also a link.

  • [![image-text](https://some.site/your-image.jpg)](https://some.site/your-link.html)

Creating/Updating tables of contents

The tables of contents are created using a VSCode extension Markdown All in One ↗ using the command Create Table of Contents (in the VS Code Command Palette ↗) to insert a new table of contents. It should then automatically be updated when a file is saved.

Add the tag <!-- omit in toc --> to any headings you do not want to be included in the Table of Contents.

# HEADING <!-- omit in toc -->

Glossary and FAQ heading ordering

When adding items to the Glossary and FAQ it's important that they remain in alphabetical order so it's easier to navigate. As there is no native way to achieve this in Markdown, you can use this bash script to reorder the headings.

The file name alphabetical-ordering.sh has been added to the .gitignore file.

touch alphabetical-ordering.sh
chmod 700 alphabetical-ordering.sh

Edit the new file with your preferred text editor.

#!/bin/bash
# Reorder glossary and store just the reordered content in a temp file
perl -0777 -ne '
    (undef,@paragraphs) = split /^##(?=[^##])/m;
    print map {"##$_"} sort @paragraphs;
' staking-glossary.md > staking-glossary-temp-1.md

# Delete everything after the first --- in and store in a temp file
sed '/---/q' staking-glossary.md > staking-glossary-temp-2.md

# Combine the two files
cat staking-glossary-temp-2.md > staking-glossary.md
cat staking-glossary-temp-1.md >> staking-glossary.md

# Delete the temp files
rm staking-glossary-temp-1.md
rm staking-glossary-temp-2.md


# Reorder FAQ and store just the reordered content in a temp file
perl -0777 -ne '
    (undef,@paragraphs) = split /^##(?=[^##])/m;
    print map {"##$_"} sort @paragraphs;
' faq.md > faq-temp-1.md

# Delete everything after the first --- and store in a temp file
sed '/---/q' faq.md > faq-temp-2.md

# Combine the two files
cat faq-temp-2.md > faq.md
cat faq-temp-1.md >> faq.md

# Delete the temp files
rm faq-temp-1.md
rm faq-temp-2.md

Run the script.

./alphabetical-ordering.sh

This was a quick script, so if you have any improvements please update it here!

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 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 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 withdrawal 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 over 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 ↗

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 through your own node.

• 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 a validating nodes propose blocks.

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

Selamat datang ke pengetahuan asas EthStaker!

Tidak berat sebelah, koleksi sumber terbuka untuk informasi dan konsep mengenai Ethereum staking. Jikalau anda sedang mencari maklumat untuk memulakan staking di Ethereum atau hanya ingin belajar bagaimana rangkaian ini selamat menerusi Proof of Stake (PoS) validators, anda berada di tempat yang betul!

🔗 Pautan Berguna

• Staking glosari

• Staking FAQ

🚀 Bermula

• Apa itu Ethereum staking?

• Mengoperasikan node tanpa ETH

• Penjelasan proses Deposit

🚨 TOLONG!

• Validator aku offline! Apa boleh saya buat?

• Terlepas pengesahan! Apa boleh saya buat?

• Saya risau masa henti beroperasi 😔

• Saya risau pasal slashing 🔪

💰 Ganjaran

• Bagaimana validator peroleh ETH?

• Kekerapan Block proposal

💻 Hardware

• Keperluan Hardware

• Contoh Hardware

⛓️ Validator Clients

• Validator clients

• Execution clients

• Consensus clients

• Checkpoint selari

• Validator effectiveness

• MEV boost

Bolehkah saya menyumbang kepada Pengetahuan asas EthStaker?

Boleh! Ini adalah website dokumentasi secara live, bermakna kita perlukan pertolongan komuniti untuk mengekal dan kemas kini isi kandungannya. Sebarang sumbangan, daripada menulis seluruh bahagian, menterjemah, atau pembetulan sebarang ejaan amat dihargai.

Anda boleh peroleh GitPOAPs daripada menyumbang secara terus kepada Pengetahuan asas EthStaker (a contributor↗) dan secara bertanya soalan yang boleh menyebabkan kandungan baru ditambah (a supporter↗).

Untuk sebarang cadangan perubahan dan penambahan kandungan sila lawati EthStaker Github↗ atau mempunyai sebarang pertanyaan sila sertai Discord↗.

✏️ Melibatkan diri

• Bagaimana untuk menyumbang

Supported by a GitBook Community License ♥️

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?

Select this option

How do you want to generate your keys?

• Download CLI app

• Download Key Gen GUI app

• Build from source

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?

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

How are validators incentivized to stay active and honest?

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.

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.

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.

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!

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

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?

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

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

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?

What happens if I lose my validator keys?

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?

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?

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.

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 post Shanghai?

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 database corruption where a resync is required to get the node operating again.

Ensure that you are running a client version that is supported post network upgrade. The below versions should be the versions you are running at a minimum.

If you were running an older version post network upgrade, most likely your local database will need to be deleted and resynced as it has most likely corrupted. 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.

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?

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.

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.

Automated failover and backup systems may seem like a good idea, but they are much much more likely to cause a slashing event (e.g. double proposal) than a manual recovery process. Missing out on a few days of rewards may seem bad at the time, but getting slashed and potentially missing MONTHS of rewards is a lot worse!

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 ↗

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 with 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/

• (Pengesahan)

• (Blok)

• (Rantaian utama)

Archival node

• Archive nodes diperlukan jika anda ada pertanyaan seperti baki akaun di dalam sebuah blok.

• Data ini diwakili dalam unit terabytes (lebih daripada 20TB untuk Geth), menjadikan archive nodes kurang menarik bagi kebanyakan pengguna tetapi sangat berguna untuk service seperti meneroka blok, vendor dompet, dan analisa rantaian.

Syncing clients dalam apa-apa mode selain daripada archive akan mengakibatkan pruned blockchain data. Ini bermakna mode lain tiada arkib sejarah penuh tetapi full node boleh membinanya jikalau diminta.

Archive nodes tidak diperlukan untuk terlibat dengan pengesahan blok dan secara teori ia boleh membina semula daripada genesis.

Attestation (Pengesahan)

Salah satu komponen penting berkaitan dengan keberkesanan ialah undi chain head. Ini merupakan undi dibuat validator bahawanya percaya blok itu adalah blok semasa dan sahih di rantaian pada masa pengesahan dibuat. Struktur undi chain head mengandungi komponen yang berikut:

• Slot - Definasi dimana validator percaya chain head semasa ialah apa.

• Hash - Definasi apa validator percaya chain head semasa ialah apa.

Kombinasi yang unik ini tentukan satu titik pada rantaian. Dengan mengabungkan secukupnya undi chain head rangkaian Ethereum mencapai konsesi keadaan rantaian.

Attestation aggregator

Aggregation mengambil pelbagai attestations yang telah dipilih untuk mengundi dengan committee yang sama bagi chain head vote, dan undi muktamad, selepas itu mencantumkan mereka kepada single aggregate attestation.

Satu aggregate attestation berbeza dalam dua cara dengan satu simple attestation. Yang pertama, ia mempunyai pelbagai validators disenarai. Yang kedua, the signature is an aggregate signature made from the signatures of the matching simple attestations. Aggregate attestations adalah sangat efisien untuk disimpan, tetapi mengandungi tambahan komunikasi dan beban komputasi.

Jika setiap validator diwajibkan aggregate semua attestations ia akan menyebabkan rangkaian segera terlebih beban dengan komunikasi yang diperlukan untuk hantar setiap attestation kepada setiap validator. Perkara yang sama, jika aggregating adalah pilihan validators tidak akan bazirkan sumber untuk membuat demikian. Oleh itu, satu subset validators dipilih oleh rangkaian untuk menjalankan tugas aggregation duties. Ini memanfaatkan jikalau tugas dilakukan dengan baik, kerana aggregate attestations dengan validators yang banyak mempunyai lebih kebarangkalian disertakan dalam rantaian menyebabkan validator juga lebih kebarangkalian menerima ganjaran.

Validators yang menjalankan tugas aggregation process dipanggil aggregators.

Beacon chain

Senarai ini digunakan untuk:

• Tugaskan validators tugas mereka.

• Melaksanakan protokol level random number generation (RNG).

• Kemajuan beacon chain.

Block (Blok)

Block proposer

Block status

Proposed

Blok dicadangkan oleh validator.

Scheduled

Validators sedang menyalurkan data.

Missed/skipped

Pencadang tidak mencadangkan blok pada masa yang ditentukan, oleh itu blok missed/skipped.

Orphaned

Untuk memahami, mari kita tengok penerangan di bawah "1, 2, 3, ... ,9" mewakili slots.

1. Validator di slot 1 mencadangkan the block “a”.

2. Validator at slot 2 mencadangkan “b”.

3. Slot 4 dilangkau kerana tidak mencadangkan blok (e.g.: offline).

4. Di slot 5/6 a fork occurs: Validator(5) mencadangkan blok, tetapi validator(6) tidak menerima data tersebut (e.g.: the block didn’t reach them fast enough). Oleh itu Validator(6) mencadangkan bloknya decent informasi yang paling baru daripada validator(3).

Canonical chain (Rantaian utama)

Chain head

Checkpoints

Client

Committees

Consensus layer

Deposit contract

Effectiveness

Purata masa diperlukan untuk validator's attestations dimasukkan kepada rangkaian.

Epoch

Execution layer

Finalization

Untuk menentukan jikalau satu epoch telah dimuktamadkan, validators perlu bersetuju untuk dua epochs terbaru sekaligus berturut-turut, selepas itu semua Epochs sebelumnya boleh dikira sebagai muktamad.

Finality issues

Fork

Full node

Menyimpan dan mengekalkan data penuh rantaian blok pada 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.

Genesis block

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

Hard fork

Head vote

Inactivity leak

Inclusion distance

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

Justification

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.

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

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.

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%.

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

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

Signing

Slashable offenses

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

Attestation violation

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

Proposer violation

Slasher node

Slot

Solo staker

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

Source vote

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.

Suggested fee recipient

Sync committee

Target vote

Validator

Eligible for activation & Estimated activation

Unique index

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

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

Validator queue

• 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 will be the ONLY way to withdraw your ETH when the time comes and no one can help you recover your mnemonic if you lose it.

Withdrawal address

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 "" guide.

Inactivity Leak

• As soon as your validator is no longer participating in the network it will start 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?

Can I be slashed for being offline?

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

Conclusion

Geth is throwing errors and not syncing

• Resync Geth

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. attestations and proposing blocks).

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 Proof of Stake (PoS) 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 validator pool.

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 exit queue and activation queue again.

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 latests 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 late 2022, it is roughly one proposal every 2 months and sync committee participation every 2.5 years.

Is there really nothing I can do?!?

We like to joke that burning some Vitalik prayer candles ↗ may increase your chances. But no, seriously, it's random. There is nothing you can do to increase your chances at proposals, short of running more validators.

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.

• 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

• 16 GB of RAM (preferably DDR4)

• 2 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.

• 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.

• Your ETH will be locked into the Beacon Chain until at the earliest mid-2023, possibly later. It makes sense to buy some good hardware. This isn’t like mining with razor-thin margins, it will pay for itself quickly.

• 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 16 ETH 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. The Ethereum execution and consensus layer are approaching 1TB in size so 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. 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.

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

• NUC - Eridian

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.

Rewards provided on the Consensus are not currently liquid. They are locked on the chain until withdrawals have been implemented. Rewards provided on the Execution, however, 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 ↗

TODO

The importance of using a UPS

It is strongly recommended that you connect your node/validator to a UPS. Doing so will ensure that it does not abruptly switch off should there be a sudden loss of power.

There are many potential issues that an abrupt shutdown can cause, such as:

• Database corruption

  • This will require you to (depending on the severity of the corruption) delete the stored DB and resync it from scratch. Depending on the speed of your SSD, this could put you offline for a while.

• OS corruption

  • This will require an OS reinstallation. You will then need to reconfigure the machine, install an execution and consensus client, set up your validators, then get both clients in sync.

• Hardware failure

  • If your hard drive fails, you will need to source and install a new one, then complete the above steps (Install an OS and sync the clients).

If a power outage doesn't damage any physical components, you might still be unsafe. When power is restored you could experience a power surge that could overload and fry components, meaning more downtime while you investigate which components are damaged and then have them replaced.

Depending on the UPS model and the OS you are using, you can configure your UPS to gracefully shutdown the connected computer(s) once the battery level falls below a certain point. Incredibly powerful in protecting your data and computer.

My UPS (1600VA/960W) cost me roughly $200 USD and provides around an hour of power to all the connected devices. I have both my node and router connected, so in the event that there is a power outage, the node will still be online working away. I've had a few short power outages since becoming a validator so it has definitely come in handy!

Configuring auto start

If things switch off while you are sleeping or not at home, the below steps are very useful in having things start back up automatically.

Computer set to switch on automatically after loss of power

In your BIOS there will most likely be a power setting, in there you should be able to find an option to have your computer switch back on once power is restored.

If you cannot find the setting, you may need to check your motherboards user guide.

NOTE - To enter your BIOS, you will need to press a specific button after switching on the machine (and before the OS loads). The most common keys are "DEL", "F1", "F2", "F10".

This does vary between motherboards, and if you are unsure what yours is, check your POST information once the PC starts as it may show it on the screen. Or you can check your motherboards user guide. Or you can do what I do, which is to spread your hands out on the keyboard and press the before mentioned keys all at once and hope one of them works.

If running a VM, setting servers to start

If you are using a hypervisor to host your nodes/validators, then you should set the VM's to automatically switch on once the computer has booted. It also saves you from manually starting them up should you manually restart the host computer.

Using services and configuring auto start

It is common practice to configure your execution node, consensus node and consensus validators as services and set them to automatically start once the OS has booted. This can be done with systemd.

Somer Esat has written great guides and has a few examples that can be referenced, one of which can be found here. There are three examples in that guide are "geth.service", "lighthousebeacon.service" and "lighthousevalidator.service"

Doing the above three steps will help to minimise downtime.

Very loud fan on a NUC

If you are using a NUC, you may notice that the fan is quite loud and can be uncomfortable on the ears. This is due to a setting called turbo boost which is enabled by default.

To switch this option off, please go into your BIOS and find the option to toggle this to disabled.

Now, this isn't a best practice, so please don't take it as such. Instead, this should be viewed as a quality-of-life option if your NUC fan is very loud and is disturbing the peace.

A firewall is a security mechanism that monitors both incoming and outgoing network connections and can either accept or reject traffic based on a set of configurable rules. It is heavily recommended to have one configured to improve the security of your node/validator setup.

There are two kinds of firewalls:

Software firewalls

Software firewalls are run on the individual machine and protect it from other devices within the local network that it sits on.

It is recommended to have all traffic dropped by default and to set up individual rules allowing it where required, that way traffic can only enter the machine where it is explicitly allowed.

For example, if you run your execution node and consensus node on different machines, you can set up a firewall rule on your execution node to only allow traffic on port 8551 from the IP address of your consensus node.

If you are running Ubuntu Server, a firewall will already be installed by default under the ufw package, you will just have to configure it and enable it.

If you are running Geth and Prysm and have the software running on different machines, you could set the below config.

Execution (Assuming Geth with IP 192.168.1.50)

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.168.1.51 to any port 8551 proto tcp
sudo ufw allow 30303
sudo ufw enable

Consensus (Assuming Prysm with IP 192.168.1.51)

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 12000/udp
sudo ufw allow 13000/tcp
sudo ufw enable

Very secure! No traffic in or out unless it is strictly Ethereum related. A full list of external ports by execution and consensus client can be found here.

From here additional ports can be unblocked such as SSH, the consensus HTTP API (If you are also running your validator on another machine) or the execution RPC API (If you wish to interact with the Ethereum network using your own node).

Hardware firewalls

Hardware firewalls are run on dedicated devices (Usually your router) and can manage traffic both within networks and between networks.

One way to really fortify your setup is to configure a dedicated subnet on your router solely for your nodes/validators and have the firewall drop traffic from any other subnet from reaching this subnet (Also known as blocking all RFC 1918 traffic)

Should your regular everyday computer (Or any other device on your network) become compromised, the infiltrator won't even know about your nodes as they are sitting on another subnet that is completely blocked off.

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.

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 such as this one 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.

Extra reading: Exploring Eth2 – Why Open Ports Matter

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 🥳

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

2. Microprocessor

3. RAM memory

4. Hard Drive

5. Power supply

6. Cabinet

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

There are multiple consensus clients (previously known as 'Eth2' clients) to support the consensus upgrades. They are running the Beacon Chain and provide a consensus mechanism to .

Consensus clients all follow the same . 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.

Loadstar

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.

• Still in development and not fully reliable, background sync is slowed down and RPC responses might fail.

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 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.

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 ↗

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 ↗

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.

Execution clients 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.

Consensus clients 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.

Source ↗

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.

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.

curl -fsSL https://as-repository.openvpn.net/as-repo-public.gpg | gpg --dearmor > /etc/apt/trusted.gpg.d/as-repo-public.gpg

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

echo "deb http://as-repository.openvpn.net/as/debian jammy main">/etc/apt/sources.list.d/openvpn-as-repo.list

• This command will check all configured repositories for updates.

apt-get update

Step 4) Install OpenVPN access server.

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

apt-get install openvpn-as

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.

The Client UI is for your devices, you'll be able to download user profiles/certificates here. We will do that part later.

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

If you are one of the lucky ones that had to do step 5.4, then you may also need to add your Ethereum node/validator subnet to the user account too.

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.

These are the ports you set in step 5.1 and step 5.3 + port 943 (The default admin port). You can change the admin UI port if you wish, but as it doesn't have external access it is not really necessary.

sudo ufw allow 943
sudo ufw allow 9514 <Change to your "Multi-Daemon Mode" port>
sudo ufw allow 9515 <Change to your "Client Web Server" port>
sudo ufw enable
sudo ufw status numbered

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.

Open the client web UI - You can use either your public or private IP for this step. In my case, I navigated to https://192.168.3.111:9515

Once in, login using the user account you created in step 6. If successful, you will see the screen in the below step.

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.

Now check your IP address at > https://www.whatismyip.com/

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

Now check your IP address again at > https://www.whatismyip.com/

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.

So leaving the client UI exposed to the internet with MFA switched on (As per step 5.4) means the security is top notch.

This is a list of high quality staking guides that are recommended on :

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.

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 ↗

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 🥳

Even if you have a large SSD installed, there are cases where Ubuntu only reports 200GB of total available space, causing 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 🥳

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 hardware best practices page.

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. Lighthouse for example supports this natively.

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:

• I'm worried about downtime 😔

• I'm worried about slashing 🔪

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

• Steps (If the ancient folder exists)

• Steps (If the ancient folder does not exist)

File Locations

• Standard location of the chaindata folder.

  Copy

  /var/lib/goethereum/geth/chaindata/

• Standard location of the ancient folder.

  Copy

  /var/lib/goethereum/geth/chaindata/ancient

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.

   Copy

   sudo mv /var/lib/goethereum/geth/chaindata/ancient /var/lib/goethereum/geth/

3. Delete the chaindata directory and recreate it.

   Copy

   sudo rm -rf /var/lib/goethereum/geth/chaindata
   sudo mkdir /var/lib/goethereum/geth/chaindata

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

   Copy

   sudo mv /var/lib/goethereum/geth/ancient /var/lib/goethereum/geth/chaindata

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

   Copy

   sudo chown -R goeth:goeth /var/lib/goethereum/geth/chaindata
   sudo chmod 755 /var/lib/goethereum/geth/chaindata
   sudo chmod 755 /var/lib/goethereum/geth/chaindata/ancient

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.

   Copy

   sudo rm -rf /var/lib/goethereum/geth/chaindata
   sudo mkdir /var/lib/goethereum/geth/chaindata

3. Confirm the ownership and permissions for the chaindata directory are set to the Geth user.

   Copy

   sudo chown -R goeth:goeth /var/lib/goethereum/geth/chaindata
   sudo chmod 755 /var/lib/goethereum/geth/chaindata

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 Google Authenticator (opens new window)(or a compatible equivalent) on your phone if you don't already have it. For Android users, consider andOTP (opens new window)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:

sudo apt install -y libpam-google-authenticator

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

sudo nano /etc/pam.d/sshd

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:

# Standard Un*x authentication.
#@include common-auth

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

# Enable Google Authenticator
auth required pam_google_authenticator.so

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:

sudo nano /etc/ssh/sshd_config

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

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes

(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:

AuthenticationMethods publickey,keyboard-interactive

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:

google-authenticator

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

Do you want authentication tokens to be time-based: y

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:

Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
  29778030
  86888537
  50553659
  41403052
  82649596

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

Do you want me to update your "/<username>/.google_authenticator" file: y
Do you want to disallow multiple uses of the same authentication token: y
By default... < long story about time skew > ... Do you want to do so: n
Do you want to enable rate-limiting: y

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

sudo systemctl restart sshd

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.

Source ↗

The EthStaker Knowledge Base aims to be an unbiased, open-source collection of useful information and concepts related to Ethereum staking. To ensure a positive and productive environment for all contributors and users, we have established a code of conduct. By participating in the EthStaker Knowledge Base, you agree to abide by these guidelines.

1. Be Respectful and Inclusive:

Treat all participants with kindness, respect, and empathy, regardless of their background, experience, or perspectives. The EthStaker Knowledge Base welcomes individuals from all walks of life and seeks to foster an inclusive community that values diverse ideas and perspectives.

1. Maintain a Professional Tone:

Ensure that your contributions to the Knowledge Base are clear, concise, and professional. Avoid using offensive language, personal attacks, or engaging in any form of harassment. Constructive criticism is encouraged, but always provide it in a respectful and helpful manner.

1. Contribute Accurate and Unbiased Information:

Ensure that the information you contribute is accurate, up-to-date, and unbiased. Refrain from promoting specific projects, products, or services that could lead to conflicts of interest. Instead, provide objective comparisons and analyses that empower users to make informed decisions.

1. Acknowledge and Attribute Sources:

When using information, ideas, or concepts from other sources, provide proper attribution and credit. This not only maintains the integrity of the Knowledge Base but also recognizes and respects the work of others in the community.

1. Prioritize Collaboration and Open Communication:

The EthStaker Knowledge Base thrives on collaboration and open communication. Share your ideas, ask questions, and engage with other contributors in a constructive and transparent manner. By working together, we can create a comprehensive and valuable resource for the Ethereum staking community.

1. Protect User Privacy:

Respect the privacy of all users and contributors. Do not share personal information or contact details without explicit permission. Any communication related to the EthStaker Knowledge Base should occur through public channels, unless otherwise agreed upon by all parties involved.

1. Report and Address Issues:

If you encounter any issues or violations of this code of conduct, please report them to the EthStaker Knowledge Base moderators. We are committed to maintaining a safe and welcoming environment for all participants, and will take appropriate action to address any concerns or misconduct.

By adhering to this code of conduct, we can create a positive and productive environment that fosters collaboration, innovation, and the advancement of knowledge within the Ethereum staking community. Thank you for your commitment to maintaining the integrity and values of the EthStaker Knowledge Base.

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

Source ↗