In a few months, Ethereum 2.0, Phase 0, will be rolling out an entirely new concept for the future of the Ethereum ecosystem: the Beacon Chain.
The Beacon Chain is a new blockchain based on Proof of Stake (PoS) consensus and which will eventually become the main Ethereum chain once all Phases of the transition are complete. Phase 0 is first up, where the main PoS chain will allow for ETH staking to earn rewards for securing the network.
This new opportunity presents interesting economical benefits for stakers, known as validators in Eth2. The new chain allows just about anyone to participate but also applies penalties for unstable performance or malicious actions.
I’d like to share my exploration of a rudimentary setup for running staking infrastructure. My objective is to highlight the challenges of maximizing rewards and minimizing penalties for a DIY setup in Eth2.
How to Run an Eth2 Validator
Rudimentary Setup
On the Ethereum mainnet, a special node is required to connect to the network, validate transactions and transmit new transactions. Below is the code snippet to start off:
The Beacon Chain is running on top of the Eth1 mainnet and new blocks include a reference to Eth1 block hashes.
Below is the basic docker command required to run a Beacon Chain node:
*https://docs.prylabs.network/docs/install/lin/docker/
Technical breakdown of the basic docker command to run a Beacon node
Before we continue, let’s break down the operations more clearly:- This will pull the latest docker image for Prysm’s Beacon Chain. (Be careful as the latest image doesn’t mean the latest stable version)
- We specify a local data folder, which is crucial if you want the data to persist independently from the docker container. (For updates and so on)
- We’ve opened several ports for communication. =
- Port 4000 is the RPC port
Port 13000 is used by libP2P - Port 12000 is used by discv5
The snippet below is a basic setup which you can find in Prysm’s documentation. A real world setup might require a few more bells and whistles like networking, RPC and Eth1 configurations.
We’ve now extended our run command to include some critical configurations:
- A restart will always make docker restart automatically if your node crashes, which could be dangerous or redundant if the node is corrupted.
- For P2-max-peers, it’s important to guarantee your node is well connected to the network which will accelerate syncing and reduce chances to fall behind.
- grpc-gateway-port opens up the nodes RPC to work over http. (ind out more here)
- The two last flags are to set up a dedicated eth 1 node for the beacon-chain. Prysm comes with a default config for this so you won’t need to run one. Bur, I believe that for production setup, you shouldn’t count on it and may be better off running your own node.
- A more automated deployment could use docker compose.
Maximizing ETH rewards, minimizing penalties
Understanding how the reward mechanism for validators functions will be a subject for a different blog post, but here are some pointers to help us map the important factors:
There is a key constant in the Beacon Chain world called epochs, a 6.4 minute stretch of time which contains 32 blocks. Epochs are important as validators are assigned duties they need to perform during those epochs. A validator’s duty can be to attest (sign) a proposed block or propose a block for which he gets rewarded.
The reward itself can change over time and from validator to validator, depending on the following factors:
- Overall ETH at stake. The more ETH at stake the lower the base reward becomes.
- The validator’s effective balance
- How fast the validator performs its duties. There is an incentive to submit your signed duties quickly.
From the above we understand that the history of a validator really reflects its future rewards. A validator that fails to meet his responsibilities can be penalized, meaning his balance will decrease. A malicious validator could get slashed, meaning a big chunk of his stake will disappear and he will be banned from the network.
If a non-active validator loses enough ETH from their effective balance, they can be removed from the active validator list.
To put it plainly, a validator can lose 16 ETH and be thrown away from the active validator list in just 18 days! (See Eth 2.0 spec)
Production Ready Eth2 Staking Infrastructure
Robust Eth2 Staking Infrastructure
Robustness
How susceptible the setup is to crashes, data corruption, disconnections and other factors. In the world of blockchain nodes, many things can influence how well and stable a setup works. However, from time to time, a node’s database may get corrupted, which can lose its peers or just crash all together.
In such scenarios the speed with which issues must be automatically solved is crucial. The longer the infrastructure is down (regardless of reason) the more penalties a validator can incur.
To mitigate these occurrences, the recommended processes to run are:
- Consistent backups (to spin up new nodes fast).
- Ensure networking and peering are optimal and continuously monitored with automated scenarios.
- Clusters of nodes to ensure stability.
Consistent Eth2 Staking Infrastructure
Consistency
By employing redundancy and clustering in your setup, a consistency issue may take place. It will manifest itself in non-discrete data states and responses. A simple example is asking for the latest block via 2 concurrent requests and getting 2 different answers.This is a crucial aspect for any validator as it can influence its ability to execute its duties correctly. To mitigate these issues:
- A health protocol needs to be implemented inside the clusters to continuously monitor each node. Followed by taking down non-healthy nodes and spinning up new nodes online.
- The nodes must be peered between themselves to propagate new messages quickly.
Available Eth2 Staking Infrastructure
Availability
While running a cluster of nodes we should also consider their availability and load balancing the requests between the nodes. A happy node is a node running while under-stressed!
How to Deploy Your Eth2 Staking Setup
Deployment
Last and definitely not least, as this setup becomes more complicated, it’s important to have an efficient deployment pipeline with automation built in. This will not only help with improving the setup but will also help with upgrading the actual nodes to the latest network specifications.
Security is Key for Eth2 Staking
An overkill? Not really!
Although this may seem like an overkill for running a few validators, I believe it’s not even close.
A single validator of 32 ETH at today’s prices is around $7K USD. The last thing we want is to run it on a half-baked setup, never certain if it will crash and start losing money.
Remember, a validator can lose half of its stake (16 ETH) by not being online for ~18 days. Unless you want to make it your day job, make sure you have a robust infrastructure!
Cost of Solo Eth2 Staking
Cost
The cost is based on some empirical tests I did on AWS, producing rough numbers which could in theory be optimized.
- Eth1 node
- Requirements: 100GB storage, 4 GB RAM (AWS t2.medium)
- Monthly cost: ~$50-$60
- Run at least 2 in a cluster for stability
- Beacon Chain node
- Requirements: 40GB storage, 4 GB RAM (AWS t2.medium)
- Monthly cost: ~$40-$50
- Run at least 2 in a cluster for stability
- Devops + Development Setup
- This component will demand most of the resources during setup. Every business or operation will need to analyze their specific development requirements to produce a reasonable result.
The monthly cost for a stable and robust setup is pretty high, even if excluding the devops and dev work. As most validators will consider staking as a passive income stream the recommended solution is to use a trustless staking service to mitigate the complexity and cost.
