What happened to Vipnode?

TL;DR: Development is suspended due to several blockers. Will re-evaluate once light clients are officially supported.

In 2017, I was trying to run the Go-Ethereum light client for development purposes, but my client was unable to find full nodes to connect with for hours at a time. Why were so few people running full nodes configured to serve light clients?

Vipnode is an open source project I launched in 2018 with the goal of creating an economic incentive to run full nodes serve support light clients.

I've written several blog posts throughout the project's lifetime with various updates:

An economic incentive for running Ethereum full nodes (May 2018)
Vipnode: Progress Update (June 2018)
Vipnode: Progress Update #2 (Sept 2018)
Vipnode: Progress Update #3 (Nov 2018)
Vipnode 2.0 Released (Feb 2019)
How Infura Uses Vipnode to Manage Ethereum Nodes (Dec 2019)

The project was funded by an Ethereum Foundation grant, and later by Infura and ConsenSys.

Blockers

By the time the last stable release was published (June 2020), several blockers from further development had become clear:

To this day (January 2022), light clients are still not officially supported or enabled by default. In 2018, different clients were experimenting with different light client protocols--Geth and Parity each had their own incompatible versions, and neither were enabled by default. Today, iteration continues on light client protocols with a robust but lengthy roadmap. In principle, the merge to the Proof of Stake beaconchain should make light clients easier to implement with fewer sacrifices, so perhaps soon we'll have more viable light clients sooner than later--certainly before sharding is completed.
Many-to-many micro-payments were too expensive to implement: The economic model of vipnode required many full nodes to interface with many light clients, and light clients were to send tiny balances per time period to all of the full nodes who service them. In practice, even in 2018 the transaction fees were way too high for this kind of thing (10-20 gwei at $300 ETHUSD). Today the gas fees are x100 higher (100-200 gwei at $3000 ETHUSD), but we have much more impressive rollup technology than we did in 2018, so we're on the right track. We also have much more interesting DeFi mechanisms that could be used to amortize value distribution without N^2 transactions. I suspect we're very close to having a fee-affordable economic model here, another x10 improvement from rollups should cinch it (these happen more frequently than you'd think!).
Nobody wants to pay for something that is otherwise free. We have many high-quality endpoint providers like Infura and Alchemy, and all modern wallets subsidize their own providers, too. There is some debate about the consequences that this has on decentralization.

Utility

High-level, Vipnode is a sidecar daemon that lives along your node or client and gives it instructions. It was built to connect full nodes with light clients through a coordinator, and track the usage between them which could ultimately be converted into payments.

Turns out that this kind of command-and-control sidecar is extremely useful for managing network topologies of node deployments. When I worked at Infura, we deployed Vipnode along every Infura node, and the Vipnode daemon coordinated which node should be peered with which other node. We had a complex topology of various kinds of nodes: Full nodes, archival nodes; internal nodes, external nodes, backup nodes, nodes optimized for different kinds of workloads, etc. I published a blog post that talks about how we did that.

In my original An economic incentive for running Ethereum full nodes (May 2018) blog post, I speculated about several other potential usecases for what Vipnode could do:

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.

One of my regrets is not pursuing the last one, which would later become known as MEV! Thankfully the Flashbots team and several others have done a great job at it.

Another use-case I would add to that list is managing, monitoring, and multiplexing Ethereum staking nodes. Péter has already started building the Minority client in this vein.

Moving forward

Work on Vipnode is currently suspended, but not completely abandoned. There's a lot of great code in there that I'm proud of. Perhaps once light clients are closer to being a norm, I'll dust the project off again! Or perhaps another more interesting use case will come up again.

In either case, I hope the permissively licensed open source code has found some use in other unexpected projects too!

shazow / shazow.net