Eth2 Staking: Infrastructure

Share this post
Share on facebook
Share on linkedin
Share on twitter
Share on telegram
Share on whatsapp
Share on email

In a few months, Ethereum 2.0, Phase 0, will be rolling out and introducing an entirely new concept for the future of the ethereum ecosystem: The beacon-chain.

 

The beacon-chain is a new blockchain that sits on-top of the ethereum mainnet chain, representing the ground work for Proof-of-Stake, sharding and the inevitable milestone of Phase 2, where all the pieces come together. We are currently In Phase 0, where the main POS chain allows for Ethereum staking and to earn rewards for securing the beacon-chain.

 

This new opportunity presents interesting economical benefits for validators accounts that stake on the beacon-chain. The new chain is efficient and optimized but also applies penalties to unstable validators or malicious actions. It even rewards whistleblowers, validators that catch malicious activity within the network.  

 

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.

Rudimentary Setup

On the ethereum mainnet, a special node is required to connect to the network, validate transactions and transmit new transactions. Running an eth 1 node is pretty straightforward:

 

Below is the code snippet to start you off.

As mentioned above, the beacon-chain is running on top of the eth 1 mainnet and new blocks include a reference to eth 1 block hashes.

Below is the basic docker command required to run a beacon-chain 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 eth 1 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. A good example can be found here.

Maximizing 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.5 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 which can be a max of 32 (always a whole number: 32,31,30..)
  • How fast the validator performs its duty. 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)


It’s important to note – a well performing validator should be maximizing its setup’s up time, executing on his duties promptly and ensuring synchronicity with the network.

Production Ready Staking nfrastructure

As with everything in development, the difference between development setup and a production  can be night and day.Here are a few key considerations:

Robustness

By robustness I refer to 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 orr 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 process to run is: 

  • Consistent backup (to spin up new nodes fast)
  • nsure networking and peering are optimal and continuously monitored with automated scenarios. 
  • un clusters of nodes to ensure greater stability.
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 the health of each node. Followed by taking down non-healthy nodes and spinning up new nodes online. 
  •  the nodes are peered between themselves to propagate new messages quickly.
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!

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 it.

This will not only help with improving the setup but also help with upgrading the actual nodes to the latest network specifications.

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, hand over fist

Remember, a validator can lose half of it’s 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

In order to break down cost in a way that truly makes sense, I worked with what I know for fact. The cost is based on some empirical tests we did on AWS, producing rough numbers which could be optimized.

 

  • eth 1 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, investor 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.

Who is Blox Staking?

We are the industry’s first non-custodial alternative for providing Ethereum staking services. Blox possesses formidable experience as master node builders. Our DevOps team are code-craftsmen with years of experience building nodes, databases, infrastructure and applications for consumers, businesses and enterprise grade customers. 

 

Never surrender ownership of your private keys and stake with reliable infra built to be secure and maximize your rewards. By leveraging our blockchain solutions, we expedite the process of becoming a validator, preparing your personal staking wallet and getting you to start staking.

Are you ready to start staking? Visit Blox today.

More to explore

All the Ways to Stake

Eth2 is fast approaching, and we are all getting ready to join in. But from running your own client software

Blox Staking Mid-Audit Update

In the sake of radical transparency, we’re sharing Least Authority’s initial report of our recent audit focused on the security