Vipnode’s Economic Incentive Node Model Serves to Avoid Ethereum’s Past Network Clog

The Ethereum Foundation’s grant program, which funds the groundwork for ensuring deserving blockchain teams contribute to the growing decentralized ecosystem, has funded Vipnode, a subscription-based node model that aims to avoid a repeat of the network’s infamous jam of December 2017.

CryptoKitties And Network Clog

Andrey Petrov, an Ethereum developer and enthusiast, faced the infamous Ethereum network clog in December 2017, when the network became incredibly slow due to the launch of CryptoKitties, a cartoon-cat collectible game running on the blockchain.

Unlike his peers, who took to social and technical forums to undermine the network, Petrov dug to the bottom of the issue and sought to rectify the problems instead.

After the game’s launch in November 2017, an unprecedented influx of curious users led to the network jam, alongside skyrocketing transaction fees as seen in the chart:

Source: Etherscan

As per Petrov, the clog was caused due to users running an outdated version of the network’s full nodes, causing a major strain. To counteract this issue, the developer set out to propose a novel, economic incentive model, termed Vipnode, which allowed for the network’s full nodes to be able to run and support updated experimental light nodes.

Vipnode: An Ethereum Foundation Grant Recipient

According to Vipnode’s website, the model “is an economic incentive for running Ethereum full nodes. The goal is to allow the Ethereum network to remain decentralized by creating a financial marketplace for more people to run full nodes and serve native light clients.”

As part of the Vipnode model, the first version of Vipnode hosted a single full node controlled by a short “driver,” and monitored all smart contracts maintained by the model’s subscribers.

By paying for a VIP membership, the model prefers and whitelists VIP nodes, and gives them preference when a light node relays a request.

Soon after the first version, V2 of Vipnode was launched and is currently used, this system allows for a variety of different subscription models.

As per Petrov’s blog, pools for vipnode include:

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 Etherscan API).
Pools for Big Miners. When milliseconds matter, it can be valuable to guarantee direct access to some of the largest miners.

According to Petrov:

“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.”

The project is fully open-source, and developers can view the work on Vipnode’s GitHub page. Furthermore, a working prototype is available on its website.

Source: Vipnode

What are Full Nodes and Light Nodes?

To understand, here’s what the two nodes particularly do.

A full node contains a copy of the Ethereum blockchain in totality and records every transaction as it takes place. The node typically requires storage space of 120GB, and a RAM of 8GB to function.

Meanwhile, a Light node only stores crucial parts of the network, without storing the network in its entirety. As opposed to the full nodes, light nodes require only a few hundred MB in storage and can run on 128MB RAM. In short, light nodes were created with the objective of making it possible to run the network on a phone.

Light nodes do not process transactions on their own, instead of relaying data to a full node to confirm a transaction on their behalf. Therefore, light nodes are easy to set up and operate, limited only by finding an available full node.

However, at the same time as the CryptoKitties launch, an experimental Light Ethereum Subprotocol Upgrade was launched and quickly upgraded to by a lot of users. However, as the full nodes did not support the upgrade, the network ultimately suffered great strain.

The project’s GitHub was filled with complaints: