Is your EVM node good enough?

Wuzhong Zhu

June 9, 2022

A while ago, I built a tool called the EVM speed tester. It was built for one of the most fundamental questions in the blockchain space—how fast a node can spot transactions in the mempool of EVM chains.

Speed tester is a pure front-end web application; what it does is uncomplicated:

A set of nodes listen to the network mempool to spot the same transaction identified by its hash and to retrieve it.
The node with the shortest time between the transaction initiation and the moment it can retrieve it from the mempool wins the race.
To make it fair, they take turns in sending the transactions.

However, this tool can be expanded—and we’ve received great feedback to do so. There are many other important aspects of a node—other than just transaction spotting. People spend a lot of time and money to find the right tool, but not everybody understands right away that it is equally important to find the right node. Hence, here is another tool to help.

Node performance insider

Node performance insider is an analysis tool for EVM nodes. It is lightweight, plug-and-play-ready, and hassle-free. It provides basic information and common metrics for a node: for example, chain ID and network latency; the tool also measures some other less common metrics, for example, total gas value in the transaction pool. Before starting, there are a few things you should know.

Use a WebSocket endpoint if possible.
By default, the tool stops monitoring in 20 seconds. This can be changed in the source code.
Depending on the node, a huge number of requests will be generated during testing, the faster the node is.
Usually, around 200 requests are sent every second to the node but it can go higher than that. Generally speaking, the number of requests = number of transactions received + 1000/network latency (ms). If the network latency is as low as 10ms, it generates 100 requests more than a slow network.
If any metric does not show, this is normal.
Some node providers do not expose some namespaces like txpool. Some node providers limit the request rate from users. All of that will result in an incomplete report. Detailed explanation and system requirements are included in the latter part of this article.

If everything goes well, you should see something like this:

Should you find it difficult to understand this report, please keep on reading. In the following section, I will explain what is peer count, network latency, transaction volume, and the tx pool value, as well as why they are important to users.

What happens after a blockchain transaction is sent

Firstly, let us see how the transaction works on EVM:

When a transaction is initiated from a client—for example, your laptop—it is first sent to the EVM node to which the client is connected. Then a special series of interactions happens among the connected nodes, aka the blockchain network.

A blockchain is all about “transactions”, “nodes”, and “blocks”. There are two types of nodes for EVM networks: regular nodes and miner nodes.

When a transaction reaches an EVM node, it is immediately broadcast out to the network. The transaction gets propagated to and stored in other nodes until it is “mined”. The “container” a node keeps the unfinalized transactions in is called txpool. Txpool is very important for a miner node.

Miner nodes are no different from others except they have the ability to create “blocks”.

For proof-of-work blockchains like Ethereum and Bitcoin, the miners compete with each other by constantly solving difficult hash questions. Once a miner wins the competition, it is then granted the right to “mine” a block.

A block contains transactions. Only after a transaction enters a block, it is considered finalized. Each transaction contains “gas”. Gas is the fee paid to the miner as a reward. The transactions in txpool with high gas always get picked up first. After a new block is created, the miner notifies the network about the news.

Other nodes in the network eventually receive the new block and merge it into their local blockchain, with the highest block number on the tail. And that completes the full cycle of a transaction on EVM.

Choose the right type of node

What makes a node good or bad, really depends on its use case. For DApps, network performance is probably a very important part of the user experience.

Imagine a user who wants to sell an asset ASAP but the network is so congested, that the requests keep getting bounced back and delayed. Devastating. By the way, check out how to get yourself a fault-tolerant setup as an end user.

For miners, one of the important factors is the volume of transactions they receive and the gas fee in these transactions. Hypothetically, more transactions means a higher probability of getting a good transaction with a higher gas fee, hence more profit. Network latency is probably the least important metric for miners.

Algo traders need the best of both worlds. A low latency network allows the trading endpoint receives and send information quickly. High transaction volume and timely block updates speed up the trading strategies optimization.

About the performance insider configuration

Not all providers give full access to the nodes. If you are using a free endpoint, it is likely that you can’t see all of the metrics because some namespaces are closed or the request rate limit.

By the way, the Chainstack free RPC endpoint doesn’t set request limits.

Chainstack dedicated node gives you full access to all namespaces necessary for this tool.

Use Chainstack.

Anyway, to summarise, the following namespace is needed for each part.

How to improve performance

Reducing network latency

Most requests, for example, sending transactions and getting account balances, do not require node-to-node communication. All information needed is stored locally on the node. Network latency can be reduced by improving Internet speed and bandwidth. However, the most important factor may be geographical location. Below is a test conducted against the same node from different sides of the world. You can see the huge difference in network latency.

For DApp developers, it is important to find a host that is closer to the users. If the users are from around the world, hosting nodes in multiple regions could be an effective solution compared to upgrading network infrastructure.

Improve transaction quality

In general, the more transactions a node receives, the better; the higher the gas fee, the better; the higher the transaction value, the better. But all of these are not configurable by default. They depend on the network condition and the neighbours, aka peers.

If a user wants high transaction volume, they probably want to deploy the node close to a node the DEX is running.
If a user wants a speedy transaction, they probably want to deploy the node close to a strong miner.

Geographical location can be another factor too.

For example, a node in the US and a node in Japan may behave completely differently in the daytime and night-time. A node in the US EST may receive a lot of transactions in the daytime but very little at night, but the situation is the other way round in Japan.

You can use this tool to visualize the node performance at different times and regions, and find out the best node to match your need.

Conclusion

If you have any questions, feel free to ping me on Twitter. I am also consolidating information for different node providers. If you can, please send a screenshot of your report and the following information to me on Twitter/Telegram/Discord, at your convenience. I will consolidate the information and share it in the next blog when I have enough.