How Infura Uses Vipnode to Manage Ethereum Nodes
At Infura, we use Vipnode to control the peers of groups of nodes, where each group has a different role. We’ll explore several recent additions to Vipnode that make this possible. First, a little background about what Vipnode is and how it works.
At Infura, we use Vipnode to control the peers of groups of nodes, where each group has a different role. We’ll explore several recent additions to Vipnode that make this possible. First, a little background about what Vipnode is and how it works.
Vipnode is an open source project designed for matchmaking Ethereum nodes with relevant peers. For example, if we have a geth light client, we can use a vipnode pool to find available geth full nodes who will serve our light client.
Pools and Agents
Vipnode can run in two modes: As a pool, or as an agent. The pool acts as a coordinator server that match-makes connected agents. The agent takes control of a local Ethereum node and connects to a pool to get further instructions about which peers the Ethereum node should connect with.
If we’re simply looking to peer our node with other nodes on the official demo vipnode pool, we can run:
vipnode agent wss://pool.vipnode.org/
The agent will connect to the demo pool at pool.vipnode.org, request compatible peers to AllowList the Ethereum node’s NodeID, then connect to the AllowListed peers. This works even if the peers’ normal limits are reached, because AllowListing bypasses the node’s limits.
At Infura, we take the same idea, but implement it a little differently.
Managing Infrastructure
By running our own private Vipnode pool, we can ensure that our Ethereum nodes are all peered with each other. By running a separate pool for different kinds of nodes, we can carefully control our internal network topology of our Ethereum nodes.
Some recent features we added to Vipnode to make this use case more powerful:
vipnode agent --min-peers=3
Control the number of pool-aware peers the Ethereum node maintains. If the number of node peers that are members of the pool drops below this number, the agent will request more AllowListed peers from the pool. We can use a high number here to always request more peers to make sure all of our nodes are cross-connected with each other.
vipnode agent --strict-peers
When we run an Ethereum node by default, it’s going to find other random peers to connect with. Strict peers is useful when we want to disable discovery and keep the peer set to be exactly what the pool tells our node to use. Additionally, if a node’s advertised routing information changes (such as the IP address or port), strict peers will force the Ethereum node to reconnect to it with the latest address.
vipnode agent --enode.host=”10.1.2.3"
A fresh Ethereum node will use the built-in peer discovery mechanism by default. In that process, the node will find its’ own public IP address and use that to advertise connections to peers.
That’s great for normal nodes, but if we’re running many nodes within a single network cluster then we may want them to peer with each other over our internal network. There are many benefits: Better security isolation, lower latency, no bandwidth costs.
We can use the --enode= flag to override the entire advertised enode:// connection string, or just override the host component with --enode.host= with our internally-routed IP address.
Network Topologies
With these three new features, we can create complex arrangements of peer networks. We could have a set of nodes that are fully connected with each other. We could make a set of nodes that is fully isolated in a private network. We can reduce our bandwidth usage by making sure our nodes are connected to each other using the private network routing.
At its core, Vipnode is a tool for controlling which peers we connect with. Originally this power was used to integrate with a public paywall mechanic, but now it’s also useful for managing clusters of nodes. Keep an eye out for more interesting use cases!
Subscribe to the Vipnode newsletter for release updates.