An economic incentive for running Ethereum full nodes
This is a story about vipnode, an Ethereum Foundation Grant recipient.
Full Node, Light Node: What’s the difference?
When you connect to the Ethereum network, you can use a full node or a light node (also known as a light client).
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?”
Two things happened in late-2017 which broke light nodes.
1. Cryptokitties
A massive influx of new users swarmed the Ethereum network, many of them relying on light nodes to trade their fancy cats and make sweet bank. We can see the usage skyrocket by observing the transaction fees go up:
2. Light Ethereum Subprotocol Upgrade
Around the same time, LES/2 was released — an upgrade of the protocol used for serving Light Nodes. The new protocol was still considered experimental and the server implementation was buggy. This meant that a lot of clients switched over to the new protocol, but many of the old full nodes were still running older code which did not support the upgrade.
The Result?
I was running some light nodes myself around that time. Normally, I’d fire up my light node and it would be up and running within a minute. Come December, everything broke. I’d leave my node up overnight and it would still fail to find a compatible full node with a free spot for it.
The Github Issues on the project were flooded with complaints, too:
We need more Full Nodes with Light Nodes slots!
Okay. How do we convince more full nodes to spend time and effort running potentially risky experimental code? An economic incentive is in order.
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 the Version 2 proposal, I outlined the design for vipnode pools. Any full node can join a vipnode pool and start earning proportional revenue from serving VIP subscribers.
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
The vipnode design can be extended for all kinds of server-client incentives. Imagine different kinds of pools that you can pay into with different kinds of guarantees:
- 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?
I’m starting to work on the pool implementation now. I’m aiming to have a beta in August 2018 and a more polished version in September.
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.
Translations of this article:
