Vulnerable Validator Architecture on Ethereum

A few days ago, Ethereum launched the “Ethereum Launchpad” which consists of an easy to understand user interface that guides you to the process of becoming an ETH 2 validator with only a few clicks
From the Ethereum foundation’s site:

“The idea behind the launchpad is to make the process of becoming an eth2 validator as easy as  possible, without compromising on security and education.
In contrast to using a third-party service, running your own validator comes with the responsibility of managing your own keys. This responsibility brings with it an inescapable tradeoff between ease-of-use, security, and education.”_

Ethereum community’s intention to increase decentralization is to have any computer become a validator and don’t rely on third-party services like Rocket Pool. So this has encouraged the sentiment in the community to try to accumulate 32 Ether to be able to stake in any setting even at a home setting or in your own regular browsing computer. There are numerous posts on Reddit and Tweets that suggest that is the plan for many Ether holders.

Operators of validators from other networks would probably dislike the idea of validating a p2p cryptocurrency network in your own home due to the heightened risk that it’d bring to your home connection and hardware, specially if you consider that ETH 2 validators are least staking 10k dollars (the dollar equivalent of the minimum amount of Ether needed to stake at current prices) in such an insecure manner.

The only inherent risk the Ethereum design has explained thoughtfully to its pool of prospective validators has been slashing. In older designs, the validator availability requirement was higher, but in the most recent designs, validators going offline is not a big violation of consensus, as long as a large number of validators don’t go offline at the same time. But there are other, more serious risks future Ethereum validators, who will take the launchpad option and will start validating using their own home hardware, should look take into consideration. As the Ethereum foundation said it:
"With respect to risk, we want you to understand what your slashing risks are, as well as the inherent risks involved with being an early adopter.”
Let’s dissect the untold risks involved with such an vulnerable design the Ethereum community is encouraging with launchpad and with home validation in the name of decentralization.


Using your home IP or any naked validator IP to connect directly to a p2p cryptocurrency network without sentry nodes increases the chance of being the target of distributed-denial-of-service attacks as well as other types of network attacks. In the grand scheme of things, it doesn’t make sense to attack just one target, but attacking a large number of home IPs could do some serious damage to the consensus as well as your validator season. An unlikely and hard to pull attack due to the number of available IPs on future Ethereum but it is still plausible. Hiding in numbers is the lesser blockchain equivalent of security through obscurity.


Exposing the validator’s IP to the internet, identifies the machine that is able to sign transactions and that could also contain keys. Which makes it a target for hackers probing for vulnerabilities in machines that are known to have cryptocurrenecy keys or are able to sign transactions for them. A measure to reduce the attack surface of probing and ddos attacks are the use of sentries. Sentries are full nodes that duplicate the information of the validator node, which help secure the actual validator hardware by not allowing it to connect directly to the p2p network. The recommendation for validators, as opposed to full nodes, is to use sentries to protect their identities, hardware and network against these attacks. In the case of an attack, sentries are the first ones to notice it so new sentries can be set up while the compromised sentry could be removed from the validator’s connections. None of this is explained on Ethereum’s lunchpad and surprisingly it’s not a serious recommendation either.


Using your personal machine for validation, opens the chance of malware and ransomware attacks. Usually, dedicated servers and VPSs are meant to be used through SSH to host a single applications, services or what have you. It’s less likely to download validator malware from your e-mail or browser and upload it to a dedicated server than it is if you validate on the same computer you use to browse the internet and receive e-mails.
Consequently, a shared USB drive or even the same modem could be used to compromise your validator computer even if you don’t use the same machine as the one you normally do to browse the internet.
Social Engineering Attacks can also enhance your validator as a target, if there was any bit of information correlating your identity with cryptocurrency, for instance, the recent Ledger leak.
then that can be used to target your leaked e-mail to receive malware that attacks machines that may or may not be running as validators at home. It’ll all depend on how persuasive the attacker can be.

In summary, Proof-Of-Service validation doesn’t come without risks, so if you’re considering running a validator from home, do more research on what other blockchain validators are doing because Ethereum will be subject to the same dangers of other PoS blockchains, so try to learn from their lessons.

Published by: Saxemberg on Aug. 1, 2020