Vipnode: Progress Update

Overall: On track for end of August, despite a couple dead ends.

Engagement

Last month, I published ‘An economic incentive for running Ethereum full nodes’ where I announced the vipnode grant funding, design, and goals.

The article did well, after receiving some attention from /r/ethereum and even earned a Chinese translation on EthFans. Pretty cool.

The newsletter is up to 60 subscribers, and the old single vipnode has 20 paying customers (which was the cap in the smart contract — oops — raised to 100 now), raking in a modest 0.1691338 ETH (about $96 USD at time of transacting).

Partnerships & Upstream Updates

• Ethereum Foundation grant paperwork was submitted last month, but the grant has not been disbursed yet.
• Infura has been very supportive since we met during EDCON. They’ve already donated some server resources, and we’re in talks about additional collaboration/sponsorship. Our long-term goals are very aligned, and we hope to reach a design and implementation that works for everyone!
• WallETH expressed interest in integrating vipnode into the mobile client. We’re looking for more third-party wallets which use the Light Node protocol to collaborate on the integration design.
• go-ethereum PR for addTrustedPeer/removeTrustedPeer is pending.
• Tracy Osborn is starting to help with design and frontend work.

Migrated Website and Repos

• https://vipnode.shazow.net → https://vipnode.org/
• https://github.com/shazow/vipnode → https://github.com/vipnode

Design Changes

The original design used ethstats to verify peering on both ends, and a custom bootnode to route clients to the next available vipnode. Due to inherent limitations, these are being replaced with a simple JSON RPC 2.0 API that third-party wallets will need to implement to participate. Details follow.

Custom Ethstats Collector

I completed an implementation of the ethstats/netstats collection protocol: https://github.com/vipnode/ethstats

As far as I can tell, this is the only alternative implementation to the original NodeJS implementation. If you’ve been looking to build a custom ethstats collector, this is for you!

Unfortunately, in the process of reversing the protocol, I discovered that it will be insufficient for what vipnode needs. There is some discussion in the README, but the main incompatibility are:

• Stats messages are not authenticated. This means that as long as a client is authorized to publish, it can pretend to be any node and send false stats for it.
• Stats do not include the list of peers. I misread the original code, thinking it did. Instead, it just includes the peer count. We need the list of peers to validate participation on both ends.
• There are fewer client implementations than I suspected. It seems geth is the only client that ships with a built-in implementation. Parity does not. If clients are going to need to implement something anyways, then we may as well build our own simpler API.

Lessons learned here will inform our design moving forward.

Custom Boot Node

I started implementing a custom boot node that was going to be used to route clients to the next available vipnode, but discovered that this won’t work.

It took some significant effort to figure out how discovery on the Ethereum network is supposed to work vs how it actually works.

Turns out the default client behaviour is not compatible with being forced to use specific nodes via a boot node. Instead, the client will continue to accumulate additional potential nodes by traversing the network, then choose a subset to connect with at ~random. This is unfortunate but not a blocker.

Since we’re already committing to having third party wallets implement a small vipnode API, then we’re going to add one more call there to acquire the set of vipnodes that are ready to accept connections instead of doing it automagically through a fancy bootnode like originally imagined.

What else?

I took some time to measure the minimum required resources for running a full node (big thanks to Infura for donating a server!):

There is a lot of FUD going around about how much the Ethereum blockchain is growing and the associated resources. Hopefully this sets a more realistic baseline for people.

Some notes:

• While the bandwidth received is already far lower than storage used, it is still exacerbated by the fact that 50 peers were connected. The minimum bandwidth required will be less than this. I plan to run another test with just 1 peer.
• Parity’s database compacting should perform even better.
• The latest optimizations in geth (1.8.11) should improve these numbers substantially.

I’ll try to do more tests like this in the future and possibly build out more streamlined measurement infrastructure as part of the vipnode project.