Popular Science: The Risks of Running an Autonomous Validator Infrastructure
Editor's Note: This article comes fromEthereum enthusiasts (ID: ethfans)Editor's Note: This article comes from
Ethereum enthusiasts (ID: ethfans)https://blog.ethereum.org/）。
Ethereum enthusiasts (ID: ethfans)
, Author: Saxemberg, Translator & Proofreader: Min Min & A Jian, reproduced by Odaily with authorization.
A few days ago, Ethereum released "Launchpad", which includes a simple and easy-to-understand user guidance interface, and it only takes a few clicks to become an ETH 2.0 validator (
The Ethereum Foundation's website mentions:
“The purpose of Launchpad is to make the process of becoming an ETH 2.0 validator as easy as possible without compromising security or sacrificing user education.
Rather than using a third-party service, running your own validator node requires you to manage your own private keys. This makes it difficult for us to have the best of all worlds in terms of ease of use, security, and user awareness. "
The original intention of the Ethereum community is to improve decentralization, so that any computer can run a validator node without relying on third-party services such as Rocket Pool. Therefore, this encourages community members to actively try to pledge 32 ETH to become a validator through all available devices, including home computers. On Reddit and Twitter, many ETH holders have posted about their intentions.
So far, the only well-articulated risk inherent in Ethereum's consensus mechanism design from a validator perspective is slashing. Older designs had higher requirements for validator availability, but in the latest design, a single validator going offline is not a serious consensus violation as long as not many validators go offline at the same time. However, there are other, more serious risks that should be considered by future Ethereum validators who opt for Launchpad and run their nodes from home equipment. As the Ethereum Foundation puts it:
“In terms of risk, we want you to understand the risk of slashing and the associated risks of being an early adopter.”
secondary title
DDoS attack
secondary title
Probe and compromise servers
If the verifier's IP is exposed on the Internet, it is possible to identify the device that is able to sign the transaction and holds the key. Attackers probe these devices for vulnerabilities and launch attacks. Using sentinel nodes is one way to reduce your DDoS attack surface. The sentinel node is a full node that replicates the information of the verifier node, which can prevent the real verifier node from directly connecting to the peer-to-peer network, thereby protecting its hardware equipment. Unlike full nodes, we recommend that validators use sentinel nodes to protect their identities, hardware, and network from attacks. Once someone launches an attack, the sentry node will be the first to notice, so we can disconnect the attacked sentry node from the verifier node and create a new sentry node. None of this is mentioned in Ethereum's Launchpad. Surprisingly, there is no strong official recommendation for validators to use sentinel nodes.
secondary title
Malware and Ransomware
If you run a validator node on a personal device, the chances of being attacked by malware and ransomware increase. Typically things like applications or services can be hosted on dedicated servers and VPS (Virtual Private Servers) via SSH. If you run a validator node on the same computer you use to browse the web and receive emails, you may be downloading malware from emails or browsers. Using a dedicated server reduces this possibility.
