An economic incentive for running Ethereum full nodes

Andrey Petrov
May 8, 2018 · 5 min read

This is a story about vipnode, an Ethereum Foundation Grant recipient.

Full Node, Light Node: What’s the difference?

A full node has a copy of the entire state of the Ethereum blockchain and executes every transaction that gets mined — this requires upwards of 120GB of storage and 8GB+ of memory (some actual stats). It can take several hours for a full node to join the network and become fully synchronized. If you wanted to run a full node in the cloud, it would cost around $20/mo.

A light node has only the minimal amount of state to make sense of things while talking to full nodes. We’re talking just a few hundred megabytes of storage and 128–512MB of memory. The goal of a light node is to be small enough to run on a phone or embedded device.

Any time a light node wants to query the blockchain or send a transaction, it must ask a full node to do it on its behalf. In effect, a light node is a mooch. But that’s okay.

A light node can join the network and start using it almost instantly, assuming it can find a full node with a light node slot available for it.

“Why won’t my Light Node connect to the network?”

1. Cryptokitties

Image for post
Image for post
https://etherscan.io/chart/transactionfee

2. Light Ethereum Subprotocol Upgrade

The Result?

The Github Issues on the project were flooded with complaints, too:

Image for post
Image for post
https://github.com/ethereum/go-ethereum/issues?q=syncmode+light+peers

We need more Full Nodes with Light Nodes slots!

Image for post
Image for post
https://vipnode.shazow.net/

The first version of vipnode was very simple: I hosted a single full node controlled by a short “driver” which monitored the smart contract for new subscribers. When someone paid for a VIP membership, the VIP’s public key (the enode ID) was whitelisted by my vipnode server. That means even if my server was full, it would still allow the VIP to bypass the server’s limits.

After chatting with the very-encouraging Robbie Bent and Jon Choi (thank you again), I was convinced to submit a grant proposal to the Ethereum Foundation to build out a more complete version of vipnode.

Pools for vipnode

In order to be able to track how much share each node deserves, we must rely on a few features of how Ethereum clients are designed:

  • A client can specify an ethstats server which will receive handy analytics about the client like information about peers it’s connected to. The vipstats server will use this information to receive client-side claims about which vipnode it’s connecting to.
  • A server can be controlled through an RPC API. A companion vipnode process will use the API to manage whitelisted peers (Parity already supports this, Geth is pending the merging of my PR). When a new VIP registers, all members of the pool will be instructed to whitelist the new enode ID. When a VIP connects, the node will send a claim to the vipstats server.
  • When the vipstats server corroborates the claims from the client and server, it will allocate a proportional fee of the pool’s revenue to that server. The structure of this fee is still up in the air. Perhaps per amount of time, or a flat rate, or something else. Each pool can decide their own structure.
  • If one side is inconsistent, then the vipnode will refuse to count it and the server will disconnect a client which fails to corroborate the claim without some timeout.
  • The vipstats server will also act as a custom bootnode that VIPs can use to direct their clients to connect to the correct set of full nodes.

Extending Incentives

  • Pools for managed clusters (like an Infura pool — a Decentralized Infura).
  • Pools for risky experimental features (like when LES/2 first launched).
  • Pools for non-standard extended API support (with inverted indices supporting complex queries like the the Etherscan API).
  • Pools for Big Miners. When milliseconds matter, it can be valuable to guarantee direct access to some of the largest miners.

We can use the vipnode pool design as a measure of marketplace demand. Anyone can start a pool and put initial client funds in it to encourage people to start running full nodes to take the other side of it.

Where are we now?

Everything is open source under the MIT license. You can follow along at: https://github.com/vipnode

Newsletter is here:
https://tinyletter.com/vipnode

If you’d like to try the working v1 prototype, it’s here:
https://vipnode.org/

Special thanks to the Ethereum Foundation for supporting this research and development. I continue to be impressed with the ambition, generosity, and effectiveness of this community, and I’m honoured to be a part of it.

Update: Follow progress and announcements here.


Vipnode

Building an economic incentive for Ethereum full nodes.

Thanks to Rob Bent and Tracy Osborn

Andrey Petrov

Written by

A doodler and computerer. I like open source, room-scale virtual reality, and p2p systems. YC alum and Xoogler. Cat person. ➲ https://shazow.net/

Vipnode

Vipnode

Building an economic incentive for Ethereum full nodes.

Andrey Petrov

Written by

A doodler and computerer. I like open source, room-scale virtual reality, and p2p systems. YC alum and Xoogler. Cat person. ➲ https://shazow.net/

Vipnode

Vipnode

Building an economic incentive for Ethereum full nodes.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store