Development Update — 3rd Feb, 2017
Happy weekend Rocket Poolers! After a hectic and successful 2017, it looks like 2018 will be no different. The last few months have been a whirlwind of activity and meetings, including but not limited too; a successful public crowdsale that finished with a bang and due to its proportional distribution design, all participants received tokens and almost a 55% refund of ether due to the sale receiving double its target. We also saw the surprise release of Casper onto testnet, the formation of several new business arrangements, visit to San Francisco with ConsenSys + Vitalik / Karl and finally the start of some additional full time members to Rocket Pool which will be announced soon.
Rocket Pool — Wait, what, who?
If you’re not familiar with Rocket Pool, here’s a quick run down before we get into the meat and potatoes of the latest development updates.
Rocket Pool is a next generation pool designed to work with Casper, the new consensus protocol that Ethereum will transition to in 2018. It was the first working implementation of a Proof of Stake pool and features several first to market features; such as load balancing across multiple cloud hosting providers using smart contracts, minipools, widow addresses and deposit tokens. Rocket Pool isn’t just a whitepaper, it’s actual code.
At the very essence of it, Rocket Pool will work to allow your everyday user and business, the ability to earn interest on their ether holdings over a fixed term, whether that be for just a few months or even up to a year.
Following up on the previous development update, more work has been done on the smart node service scripts. Rocket Pool isn’t only made of smart contracts, but also a network of nodes that can listen to the main smart contracts and receive instructions from those contracts. These scripts also allow the smart nodes to check in with the main contract on a regular basis to report on their server load which helps with load balancing users who stake with Rocket Pool + more.
These smart node scripts run as daemons (background processes) on an Ubuntu server running a full Ethereum node. The smart node services are designed to be client agnostic, so we can add even more redundancy to the network by not relying on just one node client. Be it a Parity node or Geth node, they can run along side the node client and listen for instructions from the main Rocket Pool smart contracts + allow an extra level of monitoring not seen on any Ethereum node to date.
One of the most important aspects of Rocket Pool will be node up time. Casper will punish validating nodes that are not online when they should be, this punishment is referred to as an “inactivity leak” which slowly drains the deposit of any validator at approximately twice the rate at which the validator would earn interest, although the exact formula is still being worked on.
Liveliness and Monitoring
Node client software can sometimes be unpredictable, from crashes to frequent updates, it’s important to make sure liveliness of the node is maintained, so if it does go down for any reason, it is quickly started again. The same applies for our smart node services.
To ensure any client or service that Rocket Pool relies on maintains a very high level of liveliness, both are managed using PM2, an advanced production process manager for Node.js. If either the client or services crash, they are restarted automatically and notifications of the crash are reported directly to Rocket Pool regardless if the services immediately resume operating correctly and that’s just the start…
Using Keymetrics we have designed custom monitoring probes that are run by our smart node processes. These probes allow a whole new level of monitoring on Ethereum nodes.
A smart probe allows us to monitor every smart node on the Rocket Pool network from a single dashboard, regardless of where that node is hosted. If it’s on AWS, Rackspace or a laptop in grannies basement, doesn’t matter.
At a glance we can see if each node is currently synced with the blockchain, what block the node is currently processing, the highest block that node can see, how many peers the node has, if that node is connected to the Ethereum network, the last checkin that node did with the Rocket Pool smart contracts, the time of that checkin and the nodes current sever load.
With our smart probes also comes active alerts. There’s many issues that can effect a node in various ways, from the common crashes to more irregular issues such as the node losing sync with the blockchain due to peers going offline or that node having network issues. With these active alerts, if a node even loses sync with the blockchain for just a tiny 15 seconds, an alert is sent to Rocket Pool for investigation. Similar alerts will be sent for nodes who have a small amount of peers, nodes using too much memory/cpu and a lot more.
The smart nodes haven’t been the only ones getting some love. Since the release of Casper onto testnet, we’ve been able to view in detail some of the methods needed to interact with Casper, which up until the release, had been changing periodically. The Rocket Pool smart contracts previously used a DummyCasper contract to simulate interaction with Casper, this is how people have been able to run our alpha.
The original DummyCasper contract though was missing several features that would be need for interacting with Casper on testnet, so in a major update, the DummyCasper contract was completely overhauled to bring it up to speed with the current Casper. Changes were also made across the board for our Minipool contracts which also interact with Casper, they now feature a much more accurate interaction system with Casper using direct calls to the Casper contract.
A new base contract has also been implemented across all main contracts in Rocket Pool. This contract introduces some common modifiers and storage access used for all contracts. Some of these new modifiers are access role modifiers which plug into another new contract introduced, the RocketRole contract. This contract and the new modifiers allow us to introduce ‘Role Based Access’ to our contracts, similar to user permissions seen in modern apps. Previously all our contracts used ‘Ownership’ permissions, which was basically a single role where only the account that deployed that contract was allowed to access certain ‘onlyOwner’ methods on it. This is great for smaller contracts, but with a network of contracts such as Rocket Pool, the new ‘Role Based Access’ system allows us to have a single ‘Owner’, ‘Admins’ and any other roles that need to be introduced. This results in a flexible permissions system rather than a single ‘one permission to rule them all’ style approach.
Rocket Pool will soon be expanding with new full time developers to help us get our beta happening in the near future on the Casper testnet. Still a lot of work to be done, but this should give us the extra boost we need to help get it there. We’ll also be looking at introducing some new part time roles soon, more info on that soon.
Slack or Discord
Since Rocket Pools inception, we’ve been using Slack for our main communication channel. While this has served it’s purpose, it’s also presented a few fundamental challenges in combating scammers that pop up, team management and channel management. For these reasons, we’ve opted to try out a new Discord chat room. Click that link to join and say G’day. We’ll be keeping the slack room open for a while, but at this stage it looks like we will transition to Discord over February.
RPL Token Exchanges
Now that the crowdsale has concluded, a common question for those that missed out, is where to acquire it. Currently RPL is listed on several decentralised exchanges and work is underway to get it listed on several other exchanges. More updates on these in the future.
Current exchanges that support RPL are: