I expect the new Raspberry Pi 4 (4GB RAM option, external SSD) to handle an Eth2 validator node without breaking a sweat. That's $100 of hardware running at 10 Watts to support a 32 ETH node (currently ~$10K stake).
— Justin Ðrake (@drakefjustin) June 24, 2019
The first thing to realise when running your own validator is that you can help secure the network without worrying too much about uptime.
Assuming the network is generally healthy (which means consistently operating with > 2/3 online and finalising new blocks), validators that are online > 50% of the time will see their stake increase over time.
To quote from the EF's Validated series:
This means that validators need not go to extreme lengths with backup clients or redundant internet connections as the repercussions of being offline are not so severe.
The protocol has anti-correlation incentives built into it that penalise correlated failures.
These include proportional slashings -- where the percentage of ETH destroyed depends on the number of validators that have been slashed recently -- and inactivity leaks -- where validators start being heavily penalised for being offline if more than 1/3 of validators are offline and the chain is not finalising.
Proportional slashings mean that a staking provider stands to lose a lot more ETH than an individual running their own validator if they experience a bug or a hack that causes the validators under their control to fail collectively.
In addition, the largest whales and providers also run the risk of entering into inactivity leaks and losing significant amounts of ETH (if their infrastructure goes down at once).
Even if providers are careful about both geographical and client software decentralisation, discorrelating themselves from all possible hacks (due to either social engineering, an external actor breaking in, or someone internal going rogue) is extremely tough.
As an eth2 validator, there are two keys you need to look after -- a signing key and a withdrawal key.
While your funds can't be moved without the withdrawal key, the signing key is needed to initiate a withdrawal (this is expected to change for Phase 1).
If you choose to use a staking provider, you will have to hand over control of the signing key (it's difficult for a provider to offer a service that protects against slashing if there exist multiple copies of the signing key).
This means your ability to exit, if they go offline, or you're unhappy with the service you're receiving, depends on them.
Although it is possible to do the key exchange in a way that obligates your staking provider to provide you with a signed exit before you submit your deposit, there is a risk that this message is invalidated by a fork. This brings with it the added responsibility of keeping track of the validity of that message, and possibly multiple messages (which is not great from a user experience point-of-view).
Running your own validator is not as scary or expensive as you may think. You should be able to run a validator on an old phone or raspberry Pi ($100) by the time eth2 launches.
At a slightly higher price point, solutions like DappNode already offer reliable staking hardware that works out of the box, with an easy to read dashboard to help you keep track of your funds and performance.
A hundred nodes controlled by the same entity might as well be one.
-- Barnabe Monnot
In the long-term, ethereum adds more value and provides more resilience, the more its consensus layer remains decentralised.
Satoshi's original vision was one-cpu one vote, but with today’s PoW systems we’re a long way from this ideal. As it stands, the vast majority of mining resources is concentrated in a small number of mining pools in which individuals join forces to reduce the variance of their payments.
We chose to move away from a proof-of-work model towards a proof-of-stake model in part to try and address this problem.
By choosing to run your own validator, you help turn this ideal into a reality, reinforcing ethereum’s ability to remain uncorruptible and uncensorable going forward.
Thanks to Danny Ryan, Barnabé Monnot, Carl Beekhuizen, Joseph Schweitzer, and Mamy Ratsimbazafy for reading drafts of this.