Ethereum 2.0 Staking Veteran Driver's Guide: Three Tips to Avoid Staking

Editor's Note: This article comes fromBabbitt Information (ID: bitcoin8btc)Editor's Note: This article comes from

Babbitt Information (ID: bitcoin8btc)

Babbitt Information (ID: bitcoin8btc)

, Author: Raul Jordan, translation: free and easy, published with permission.

This article discusses the slashing mechanism in the Ethereum 2.0 network. For Staking participants (especially those who participate in person), you need to understand what situations will lead to slashing and how to avoid being slashed. Most of the information presented in this document is client choice agnostic, meaning it will apply to all users regardless of whether they choose to run Prysm, Lighthouse, Teku, Nimbus or another Ethereum 2.0 client.

The original author is Raul Jordan, co-founder of Prysmatic Labs.

*IMPORTANT DISCLAIMER*

Prysmatic Labs is not responsible for the loss of users' funds regardless of the cause, including client bugs or documentation errors, this exclusion of liability extends to the slashing process. While every Ethereum 2.0 client does its best to ensure that the codebase is secure, as with any other development project, there will always be the possibility of errors. Participating in Ethereum 2.0 is a risky activity, and it is important that participants research and understand the risks and responsibilities they will bear.

What is slashing?

Slashing occurs when a validator exhibits behavior that is competitive with the Ethereum network. Slashing is not necessarily due to malicious intent, it can also be due to misconfiguration. The actions of verifiers may cause confusion in the system or destroy its integrity. Therefore, these verifiers who cause harm to the network will be penalized for their pledged ETH, which is irreversible.

Not to confuse slashing with inactivity penalties, the goal of slashing is to disincentivize those who seek to harm the Ethereum 2.0 network, and in turn reward those who maintain, manage, and operate the Ethereum 2.0 network as planned. The main purpose of slashing is to mitigate attacks performed on the Ethereum 2.0 network, such as creating conflicting forks of validators on different checkpointed views of history.

Validators that follow the protocol correctly will never issue slashable votes in normal operation, and validators will not be slashed for being offline.

How Slashing Works

1. The act of slashing destroys the staked funds of validators who harm the Ethereum network, forcing them to leave the network and strengthening the security of the blockchain by promoting good actors.

2. Although slashing is a form of punishment, it is still possible for even a normal user to be slashed if their validator is incorrectly configured. Therefore, it is critical to know how to properly set up and manage authenticator clients and operating systems, and users should avoid attempting to use advanced instructions without understanding their full capabilities.

3. Validators propose two conflicting blocks in the same slot with different roots (essentially hashes of internal data). If such actions were not punished, it would be easy for validators to create unnecessary forks, or cause confusion. Note: Simply proposing the same block twice will not be slashed;

Validators attest to two conflicting blocks in the same slot. This is known as double voting and also means that validators may try to create conflicting forks of the chain. Note: Simply voting twice for the same block will not be slashed;https://github.com/protolambda/eth2-surround

Votes cast by validators "surround" or are "surrounded" by previous votes, which means validators attempt to vote against history, in which case they are slashed;

image description

Ethereum 2.0 surround vote, from1、2What happens after being forfeited?

While there are multiple mechanisms to prevent slashing, it is critical that each validator key pair is only used by one validator. This sounds easy, but when multiple validators are configured, it's easy to restore a validator by mistake and duplicate a validator that was already running. Always verify that the correct validator key is being used/restored/set when making changes.

1. You can find it here (

2. If a validator is slashed, a number of things can happen:source）；

3. Slashed validators are forced to withdraw from the beacon chain within 36 days;

4. Slashed validators face three types of penalties (

5. source

Penalties start at each epoch until the validator leaves the exit queue;here。

In the interim between the reporting message being included in a block and the exit of the slashed validator, a special penalty will be imposed proportional to how many other validators were slashed during this period. Applicable maximum up to all valid balances of the relevant slashed object.

This means that if a validator is slashed, it will be penalized immediately and will continue to be penalized for about 36 days until it can exit, and within 18-36 days there will be a one-time penalty, The slashed amount is also affected by the number of validators slashed during the same epoch (that is, to determine whether this is a coordinated attack or a separate attack). For more detailed instructions, please visit

here

Finally, it's worth noting that a slashed validator cannot re-enter the validator set. If the verifier wants to continue to verify, it needs to make a new pledge and generate a new key, and the penalty is irreversible!

In general, being slashed will result in your staked ETH getting less and less, with significant losses along the way. After 36 days, you can exit the beacon chain, and you can withdraw all remaining ETH, and you will lose a large portion of your ETH during this 36-day period.

Common user errors that lead to slashing

Although the slashing scenario mentioned above seems impossible for ordinary users, incorrect configuration may cause honest validators to be slashed too! Here are some scenarios where this might happen:

1. The same authentication key is running on two servers at the same time, one of which may be used as a failover in case the first server fails.

Note: This is the easiest way to get slashed, and you may find yourself in a slashed situation if your failover system falsely reports that the first node is down.

Please don't run verify keys in two places at the same time!

2. You migrated the key to another computer or another Ethereum 2.0 client without migrating your confiscated protection history;

Explanation: Another node of yours may have an incorrectly synchronized clock, which could cause you to be slashed, which can be easily circumvented if you migrate the slash protection history.

3. You deleted or lost the slash protection history in the validator client;

Explanation: Losing the slash protection history can cause issues like your clock being messed up to produce blocks or votes that would be slashed.

4. Validate using a containerized environment without a persistent volume (PV)

5. A protocol bug that could lead to slashing errors (this is unlikely, but it would be the worst case)hereKnowing how to set up, configure, upgrade and troubleshoot any installed software is critical when choosing a validator. existherehere

(ethereumprice.org) A good resource to better understand the risks of participating in Ethereum 2.0 staking can be found at

here

There is another resource that explains how to detect slashing conditions.

Who is carrying out the forfeiture?

Slasher

Slasher refers to a separate piece of software whose main purpose is to detect slashable events. You can think of slashers (Slashers) as the "police" of the Ethereum 2.0 network. Due to the additional data and processing required to detect malicious messages, these slashers are usually run independently of beacon nodes. To detect slashable messages, the slasher records the proof and proposal history of every validator on the network, and cross-references that history with broadcast content to find slashable messages, such as double blocks or surrounding votes.

What the network needs is an honest slasher client to monitor the network, as any slashes found will be propagated throughout the network to be included in a block as quickly as possible.

Whistleblower Reward

To incentivize slash detection, validators will receive a "whistleblower reward", which is a reward on the beacon chain for submitting blocks with any valid slash. These rewards are given to those validators who participate in the slash, and are usually rewarded around 0.1 ETH per validator.

While incentive detection is valuable, if you discover slashing in Prysm, simply running a slasher client will not earn you whistleblower rewards. By default, any slashes discovered are broadcast to the network to be included in blocks as quickly as possible, so usually rewards are sent to proposers immediately after a slash is detected, rather than to validators running the slasher.

Running a slasher doesn't mean it's profitable. Forfeitures are rare, and rewards for whistleblowers are set low. In essence, operating a slasher is an altruistic act, and again, only an honest, functioning slasher needs to be activated in the network to catch violations. Fortunately, this is a low barrier to entry, and we envision that a significant number of users and entities will run slashers to secure the network.

confiscated vaccinations

We have good news for you, forfeiting is preventable! There are many best practices to ensure we don't get slashed, but it's important to understand them.

1. Local confiscation protection database

One method of slashing protection implemented by multiple clients is a local signature history database. This feature is enabled by default in Prysm's validator client. This database ensures that validators do not sign messages that are considered slashable messages based on their own history. More simply, a validator considers the database as its only source of truth when deciding whether a message should be signed. This approach ensures that a single validator does not perform duplicate actions.

Note that local slashing protection does not prevent running multiple validator instances with the same validator key.

The database only tracks signing events for validators in that local instance. This also means that if a user changes their validator to a different client (for example, migrating from Lighthouse to Nimbus), or moves to a new hardware setup (installation on a new linux machine, migration to a hosted solution), then The signature history database must also be migrated. This will ensure that a history of past operations is preserved on any new client.

2. Remote slashing protection

Another alternative implementation to prevent slashing is to use a slasher. The slasher records all proofs and blocks it receives, which validators cite before agreeing to sign messages. This approach is a stronger form of slashing protection than a local signature history database, but like a database, it does not protect against running multiple instances of the same validator.

Another implementation to prevent slashing is to use the slasher itself as a middleware between beacon nodes and validator clients. Before a validator client submits a block or proof, it first asks the slasher whether it is slashable.

If the check passes, the data will pass through the beacon node. This is the most advanced form of slash protection, because ideally the slasher knows about everything that happens in the network and records the history of blocks and proofs for each validator. But one thing to note is that in Prysm, remote slashing protection is not yet optimized, as our slasher is still a heavy resource hog. Given the high resource consumption of our slasher, this may cause your validators to miss proofs or blocks. Remote slashing protection is designed to operate as an additional layer on top of local slashing protection. For security reasons, users cannot disable local slashing protection in Prysm.

3. Migrate your confiscation protection history

From time to time, you may wish to switch staking machines, or you may wish to migrate to a different Ethereum 2.0 client that suits you. In any event, you should always carry your forfeiture protection record with you.EthereumForfeiture Protection Standard: EIP-3076EIP-3076There is currently an official standard for migrating

1. Ethereum

2. 2.0 slash-protected history between clients, it's called

. The standard proposes to represent a validator's slash protection history in a JSON file. This file contains:

Information about the chain’s initial state of the verification history (used to distinguish testnet from mainnet);

All signed blocks and signature proof information about the user's running validator public key;

By exporting this file, and importing it when migrating to another computer or Ethereum 2.0 client, you will gain a lot of benefits and be able to avoid the simple slashing condition of not storing this local history.

Import existing authentication keys into Prysm

As of press time, in v1.0.1 of Prysm, Prysm does not allow users to import EIP-3076 slash protection JSON files into validator clients. This is the top priority of the Prysm team, which may be implemented in the next version after the Ethereum 2.0 mainnet goes live.

1. Export your slash protection history from Prysm

2. As of press time, in v1.0.1 of Prysm, Prysm does not allow users to export slash protection history to EIP-3076 slash protection JSON files, again, the Prysm team is working hard to achieve this goal.

3. If you are sure you want to migrate machines, we recommend that you wait until Prysm supports exporting slash protection history. If you really can't wait, here are some important things to keep in mind:

4. Shut down your beacon node and validator on machine 1, make sure it is not running as a system process. You can check with your operating system's process monitor tool or a command-line tool such as top or htop and check to see if the name "prysm", "validator" or "beacon" is included.

5. Note your wallet directory location. If you started Prysm with the defaults, you can see its path at the top of the "Authenticator Account List" output, which varies by operating system.

6. Take the entire catalog and migrate it to your next computer.