Hello Rocket Poolers! In this month’s update, we’ll be focusing on node operators; those all-important people in the Rocket Pool network who want to run their own node, stake their own ETH, and earn a better staking return overall than they would staking solo. As part of this focus, we’ll be covering some design details of our smart node software package that these operators will run and how it aims to improve upgradability, scalability and monitoring(ility) for all node operators of any experience level. All willing node operators will get a chance to try this out in our upcoming public beta release using more fake ETH than you can shake a node at.
But before we dive right in, want to know a bit more about Rocket Pool and its founder David, but don’t want to spend 10 mins digging through google? Well Token Talks with Zach DeWitt has you covered. In his podcast, Zach covers the best emerging projects in crypto through unbiased and exclusive interviews with blockchain technology founders. In this talk, he uses his silky- smooth radio voice to talk to David about Rocket Pool and our plans for the staking future of Ethereum. Be sure to give it a listen.
Rocket Pool — Wait, what, who?
If you’re not familiar with Rocket Pool, here’s a quick run-down before we get into the details of the development update.
Rocket Pool is a next-generation Ethereum proof of stake (PoS) infrastructure service, designed to be highly decentralised, distributed and compatible with Casper 2.0, the new consensus protocol that Ethereum will transition to in late 2019.
We offer any user, business, corporation, pool, wallet provider, exchange, hedge fund — just about any service — the ability to provide their users with the option to earn interest on their ether holdings for a fixed term without worrying about maintaining an extensive staking infrastructure, just plug and play.
Rocket Pool has a long history in Ethereum and work on it originally began in late 2016 after the Mauve paper was released by Vitalik Buterin. This provided an early functional spec for Ethereum’s new consensus protocol called Casper which would allow users to earn interest on a deposit of Ether. Since then, Rocket Pool has grown and evolved into a next-generation staking network, aiming to allow businesses and their users to earn interest on their ether and to empower users who wish to stake on their own node by providing them with additional income on top of interest awarded by Casper.
Smart Node Operators
To begin, let’s recap what is to be a smart node operator in Rocket Pool during Ethereum 2.0. Users who wish to stake their own ETH in Rocket Pool, but not run a node, will need node operators to do their staking for them. These users may be customers of a business, exchange or any other service which has registered a group in the Rocket Pool network and been on-boarded through it. Or they might be just regular users who do not have the time, skills or minimum amount of ETH required to run a node themselves.
So, what are the benefits to being a node operator then? Why not just stake your ETH without running a node? If you run a node in the Rocket Pool network, you:
- Only need 16 ETH minimum as opposed to 32 ETH solo staking outside of Rocket Pool. The other 16 ETH required to begin staking comes from users who don’t run a node.
- Earn additional rewards in the way of a network-determined fee charged to users who have ETH assigned to your node for staking. Every node operator in the network can vote for how much they think this fee should be and the network forms a consensus around a middle ground value. We don’t control how much node operators make from users, it’s up to them as they’re the ones providing the network with resources.
- Get to stake your own ETH completely fee free. You’re the backbone of the network and we respect that.
- Have complete control of your own node. Many node operators don’t want to trust another entity with staking their ETH, so these users will be right at home in Rocket Pool and get extra rewards for it.
- Can stake as much ETH on your own node as you’re comfortable with. Outside of Rocket Pool you’re limited to 32 ETH per node, inside Rocket Pool as a node operator you can stake in multiples of 16 ETH. Have 128 ETH and want to stake it all on a single node, rather than 4 separate nodes and save some cash? No problem.
- Can utilise our smart node software stack which is detailed below. This can be installed with a single command to get your node up and running easily. You can select which ETH1 client you’d like to use (Geth/Parity) and which ETH2 beacon chain client you’d like to use (Prysm, Lighthouse, Nimbus etc). Our smart node software will offer a CLI (GUI to follow later for home users) to help interact with the Rocket Pool network, make deposits, monitor minipools (our validators) and more. The software handles all interactions with Casper and more, making staking on your own node a pleasurable experience.
Our next beta, which will be announced soon, will give eager node operators all these options to try out!
Smart Node Software
Our smart node software aims to make staking as a node operator in Rocket Pool an easy and flexible process, with some really cool scaling and monitoring options provided out of the box. Our aim is to give casual node operators the tools to run and manage their node easily, and at the same time allow power users to create some truly mind-boggling redundancy, scaling and monitoring for their staking nodes.
To install the smart node software, only a single terminal command will need to be run. This will install your ETH1 and ETH2 clients of choice and configure your node to get up and running. After installation, a Rocket Pool CLI will be available for your node. This will allow it to register with the network, deposit ETH/RPL and begin receiving ETH from regular users who are not running a node. For home users who wish to run a node on their own computer, this CLI package will become bundled with a GUI to make things easier. Only the CLI will be available during our upcoming betas, with the GUI coming at a later date.
With staking in ETH2 requiring both ETH1 and ETH2 clients, it can be a little daunting to know exactly what’s going on in your server. Out of the box, we’ll be providing users with some command line monitoring to help them view CPU, Memory & Network usage of their node. All users will also have the option to follow live logs of their ETH1 & ETH2 clients and our own minipools that are running on it.
Shown above, we’re also working on some highly customised monitoring for our nodes with a graphical interface that will be available for all users who wish to enable it. This will be part of our second beta later in the year.
The software stack that runs the smart node is built using docker containers. There are many benefits to using containers, but one of the biggest is portability — we can create an environment where each process in the stack runs the same no matter which server or laptop they are running on.
Above, you can see the design of our default smart node software stack from the ground up. Node operators will be able to choose their ETH1 and ETH2 client upon install.
In the “Validators” segment above, you can see that this node has made 3 x 16 ETH deposits on their node, which has created 3 minipool containers (our type of validator). Each of these validators contains 16 ETH from the node operator and 16 ETH which has been matched from users who are not running a node and have simply deposited it to the Rocket Pool network for assignment to node operator.
A node operator can create as many validators as they want on a single node, but keep in mind that the more validators are on a node, the more resources are required for that node, mostly in the way of CPU.
Since a node can have many validators on it, all communication from these validators to the ETH1 and ETH2 clients is sent through Traefik, a reverse proxy / load balancer. What this creates is an extremely flexible setup that can add scaling and load balancing abilities to your node — we’ll go over just some of these possible setups below.
This is where things get really fun. Rocket Pool’s smart node software stack is built to allow advanced scaling / load balancing options out of the box. To show exactly what’s possible, we’ll cover some of these configurations for each experience level, from your standard user to your advanced power user.
Experience Level: Casual User
Our standard smart node stack is what’s available out of the box for all users upon install. It is exactly as seen in “The Stack” diagram above. It allows each user to select which ETH1 client they’d like to run (Geth/Parity) and which ETH2 Beacon chain client (Prysm, Lighthouse etc). These clients are automatically restarted should they crash, as is every part of our smart node stack. This is the stack that we’d estimate 90% of users will use.
Experience Level: Experienced User
If you’re experienced with running Ethereum nodes, you’ll know they aren’t always super reliable. Although we provide monitoring and auto-restarts for crashed clients, you might want a bit more control and redundancy for your validators to ensure they can always perform their duties. For these users, they can scale their ETH1 and ETH2 clients by launching more instances of them. The user simply runs “rocketpool scale pow=3” on their terminal — this instantly creates 3 ETH1 clients on the node; all communication from your validators to your ETH1 clients is now load balanced across them. If one of these clients crashes, all traffic is balanced across the remaining two until the crashed client is automatically restarted. This user can also do the same for the beacon chain clients, so all communications from validators to ETH1 and ETH2 chains is load balanced with some redundancy. Neat!
Experience Level: Weekend Devop
On your weekends, you love playing around with servers, you have experience running some nodes in the past and know your way around a docker compose file. You decide that not only would you like to run one or more clients in a load balanced manner as described above, but you want to run different ETH1 and ETH2 clients alongside each other — just in case there’s a bug in one, you’ll have others to pick up the slack.
In this scenario, you configure your node to run both Geth and Parity ETH1 clients alongside each other, with requests to them from your validators being load balanced between each other. That’s cool and all, but you want to favour the client that’s performing the best, not simply send requests to each one in a standard round robin fashion. So, you enable “Dynamic Round Robin” as the load balancing option in the docker compose file for ETH1 clients. This means that if Geth is processing requests quicker than Parity (or vice versa), the Geth client will process the majority of the validator requests to the ETH1 chain. You end up with:
- 2 x ETH1 Clients (1 x Geth 1.8, 1x Parity).
- 1 x Beacon Clients ( 1 x Prysm)
- All load balanced using Dynamic Round Robin to ensure the best performing clients get the most requests.
That’s pretty sweet, but not nearly enough craziness.
Experience Level: Professional Devop
You have a regular paycheck doing things exactly like described above, and this is just another day on the job for you. You decide you want more: “Hey, if fancy pants Infura can do it, so can I!”. You pick the best server you have and get to work.
You configure each ETH1 and ETH2 service to use 3 clients of each in their respective group. You also make sure each group has different clients in it. So you end up with:
- 3 x ETH1 Clients (1 x Geth 1.8, 1x Geth 1.9 and 1 x Parity).
- 3 x Beacon Clients ( 1 x Prysm, 1 x Lighthouse and 1 x PegaSys)
- All load balanced using Dynamic Round Robin to ensure the best performing clients get the most requests.
That seems like a great setup and your beefy server is handling it just fine. But that thought lingers in the back of your head: “there must be more ways to ensure all validators are always communicating to their chains!” And there are. You open up our stack’s docker compose file, head to the Traefik section and add some health checks in there. Now each client is pinged internally every 2 seconds, and if they don’t respond in a fast enough manner, they’re automatically taken out of the load balancing setup. You can now rest easy, dear server warrior.
Experience Level: Lord of the Devops (and partially insane)
You scoff at the above node operator’s setup. They are but a grain of sand in your beach of experience. You have servers that IBM would be envious of, and more disposable cash than several small sovereign nations combined.
You create the following node setup:
- 12 x ETH1 Clients ( 4x Geth 1.8, 4x Geth 1.9, 4x Parity)
- 12 x Beacon Clients ( 3x Prysm, 3x Lighthouse, 3x PegaSys, 3x Nimbus)
- You deposit 4,800 ETH on your node which creates 300 minipool validators, all of which communicate via load balanced methods to the above clients.
- Health checks running every second for each client with automatic rules for dropping clients should they not respond in the desired manner or time.
- Dynamic Round Robin load balancing ditched for your Weighted Round Robin load balancing. You already know which specific clients perform better, so you give them a higher weight, resulting in that particular client performing more of the work for your setup.
- Fire department added to speed dial for your server farm.
The above examples are all currently possible with our smart node software stack which budding node operators will be able to try out in our upcoming beta that will be announced soon.
Our second beta down the road will look at extending this further using Docker Swarm and Kubernetes for spreading out our smart node stack across multiple servers. Stay tuned!
Questions or just say hello!
Well this turned out a bit longer than expected, 10 points to you for making it this far! If you have questions or want to know a bit more about us, why not swing by for a chat and say G’day! You can view our website or have a chat with us in our chat room that anyone can join. If chat rooms aren’t your thing, we’re also on Twitter!