In this article we will take a deep dive into private Ethereum nodes, how they work and why they give you a competitive advantage. Special thanks to moon1185#8426 and trippyfish#0805 for this piece👇
Nodes are the gateway to the Ethereum network. On a cryptocurrency blockchain a node’s primary job is to confirm the legality of each block. Most nodes on the Ethereum network are JSON-RPC. JSON-RPC nodes are widely used in the crypto space as they are specifically provisioned to interact with the blockchain (they can read and write data), and are used alongside a wallet or dApp. So how exactly do they work?
After a transaction is sent to the blockchain, it will be submitted to a node. The node does a series of preflight checks to ensure the request is valid before it then enters a pending state. Miners are notified of these pending transactions and can include it when solving the next block. There are different types of nodes running on different software and hardware. Some examples include mining nodes, light nodes and archive nodes.
Transactions are mined once the miner has verified its legitimacy and recorded it on the global ledger. To go through this process, nodes are crucial in determining how a miner will receive and verify a transaction. However, miners will not work with individual transactions, but rather a set of transactions referred to as a “block”. The integrity of each individual transaction is maintained through an extensive verification process which results in blocks’ immutable nature. Before learning more about nodes, it is important to understand the flow of a transaction.
Transaction in a Blockchain Flow
- 1.When you sign a transaction on Metamask, the signed request is immediately sent to an RPC node. Metamask uses Infura by default but gives you the option to add custom RPC endpoints.
- 2.The node receives the request and immediately does some preflight checks to ensure your request is valid.
- 3.After the transaction is validated, your transaction is put into a pending pool–also known as the “local mempool”.
- 4.The RPC node broadcasts its local mempool to other nodes spreading your pending transaction to the entire Ethereum network.
- 5.At some point, a mining node will collate hundreds of transactions together into a potential block in a way that maximizes the fees collected while ensuring the block stays within the gas limit.
- 6.The mining node validates the transactions on the potential block and proceeds to execute all the transactions and update its local copy of the blockchain. The mining node will also produce a “certificate of legitimacy” proving the work done for solving the block.
- 7.The mining node proceeds to broadcast the completed block along with the certificate for other RPC nodes (such as the one you used) to hear about it, validate it and update their individual copies of the blockchain.
Armed with some basic understanding of how transactions work, you can quickly see how complex the blockchain can be. Your RPC node can be a bottleneck and could severely impact your ability to interact with the blockchain. This is why using a node specifically designed for NFTs provides immense value when trading
While the blockchain is immutable, the Ethereum mempool (i.e. an amalgamation of all pending transactions across all nodes) is not. Each node can only store so much information–this is due to computing, memory and storage limits. When a node gets overwhelmed it begins to prioritize competitive transactions over uncompetitive ones. This is where the mempool comes in. The database holding these pending transactions is an aggregate of each node's mempool. From the mempool, miners will then verify the most favorable transactions first (think higher priority fees, check out our articleNFT Sniping Gas Explained). This results in the inevitable cannibalization of transactions between node users. While this is unfavorable for the individual user, it’s also become the accepted norm. One common justification is–everyone’s in the same boat. But are they really?
Currently there are 3 major node providers in the Ethereum space. We have Infura, Alchemy and QuickNode. These services are built to handle scale and can support tens of thousands of users on their infrastructure. Moreover, proprietary technology is rife; each provider is constantly innovating to solve low-level computing problems whilst ensuring data correctness and real-time sync with the blockchain. Many offer free services, however, the advanced functionality and resources (which are needed to gain an edge) are gated behind a monthly fee. With these advanced subscriptions, the more you consume the more you end up paying. Yet despite this, due to the nature of their architecture being “shared”, rate-limitations and local mempool cannibalization are still a common sight. Last but not least, node authentication is done via the node URL itself. As a paying customer it’s in your best interest to keep this URL a secret to avoid anyone else from using the node on your dime!
Recently, there have been new node options available for investors on Ethereum. Private nodes sold in the form of “NFT utility”. With the known disadvantages that come with the above-mentioned options, a private node aims to solve them. No rate-limits and private or dedicated hardware tuned for performance over scale. But why is this important? It is all due to exclusivity, which is the last ingredient to making all of this perform well. At NFT Sensei we value this privatisation of “node authentication via NFT ownership”. If you can estimate for a maximum number of users, you can plan for resource usage in an economical and efficient manner. Given the vast number of providers and the variations between their offerings, we decided to take an in-depth look into their technologies. This helped us better understand how these nodes have been set up, so we decided to outline some notable private node providers for you too:
A utility based NFT project with HyperNode being their highlight. JustCube’s HyperNode uses a server located in AWS Virginia. Apache 2.4.53 is used as a proxy to authenticate users and forward requests to a node. Using this approach there is always the chance you can receive a prolonged response time, as request are sent to one server and then redirected to another.
A utility based NFT project with GigaNode being the highlight. GigaNode currently uses a one node setup located in AWS Virginia. Running NginX proxy and apache utils to handle requests and authentication.
Yakuza has a similar issue to JustCubes, as having a single-node setup with a poorly configured NginX Proxy can lead to multiple timeouts and can be easily saturated on high traffic mints. By using htpasswd (apache-utils simple password authentication) to handle authentication they also have the issue that anyone with the username and password can easily connect to the node. This can be viewed by looking at their RPC Url format: https://poseidon:[email protected]/
Zapnode currently uses a cname record to point their domain and subsequent subdomains to quicknode instances. This makes Zapnode a commercial node with shared infrastructure and without the possibility to authenticate request.This can be viewed in the below table with information on its IP address and DNS name.
Moonbears is a utility-based project with TrippyNode being the flagship. TrippyNode is a distributed, highly-available node. Carefully crafted with ample resource redundancy for each holder and configured to run behind an NginX proxy that is tuned for high-throughput.
TrippyNode is currently running a cluster of network load-balanced nodes in North Virginia, a single node in Germany and another in Singapore. These are all serviced using AWS Global Accelerator under the domain “moonbears.trippynode.xyz”.
The node client itself is a modified implementation of GETH (Ethereum’s official node client), custom NFT authentication is directly baked into the node with holder snapshots taken on a periodic basis.
CNCR = Concurrent Requests
After looking at these results, we knew which private node provider we wanted to partner with. So we are super excited with our partnership with TrippyNodes. We have worked together to create SenseiNode, which is a custom solution on top of TrippyNodes. This provides extremely fast performance as this node is truly private (among Sensei Holders), widely geographically distributed, and specifically made for multi-wallet botting and sniping.
One huge problem with NFT gated nodes is that they are incompatible with burner wallets. You cannot send transactions from wallets without the authorised NFT. SenseiNode overcomes this with a custom solution that lets you register burner wallets with the node. This is achieved via high performance caching and lookups to validate addresses. The result is a node that allows for safer and smarter botting - something never seen before in the NFT space.
To test the methodology and performance of different nodes for yourself, the following libraries can be used. Click on the drop-down handles to follow the coding instructions:
Ethspam is a compiled binary written in golang which generates an infinite stream of realistic read-only Ethereum JSONRPC queries.Per second, ethspam generates around 500,000 lines, or 120 megabytes of data, on a modern portable laptop.
eth_call, eth_getTransactionReceipt, eth_getBalance, eth_getBlockByNumber, eth_getTransactionCount, eth_blockNumber, eth_getTransactionByHash, eth_getLogs, eth_getCode
While these queries are exactly what we want to send to our nodes for testing, we need to consider the fact that the nodes will respond with an error when making eth_getBalance calls using an address that isn’t on the allowlist. The GetBalance query is the only read call that is gated by these private nodes.
In order to build this fork, simple follow these commands:
When calling ethspam, all you need to do is:
$GOPATH/ethspam -f trippynode.json
Your json file should include a array of wallets you wish to use for testing
Versus takes a stream of requests and runs them against multiple endpoints simultaneously, comparing the output and timing.
In order to install versus:
tar -xzvf versus_1.0_linux_amd64.tar.gz
rm -rf versus_1.0_linux_amd64.tar.gz
sudo mv versus /usr/local/bin
For each test we run a similar command where we only modify the json file with the array of wallets, concurrency, stop-after and node url.
5 request concurrency / 250 requests
$GOPATH/ethspam -f placeholder.json | versus —-timeout=5s —-stop-after=2500 —-concurrency=25 "http://anynodeurl.com"
25 request concurrency / 2500 requests
$GOPATH/ethspam -f placeholder.json | versus —-timeout=5s —-stop-after=2500 —-concurrency=25 "http://anynodeurl.com"
50 request concurrency / 5000 requests
$GOPATH/ethspam -f placeholder.json | versus —-timeout=5s —-stop-after=5000 —-concurrency=50 "http://anynodeurl.com"
100 request concurrency / 10000 requests
$GOPATH/ethspam -f placeholder.json | versus —-timeout=5s —-stop-after=7500 —-concurrency=50 "http://anynodeurl.com"
The node you use to purchase NFTs directly affects your transaction's performance, so being aware of your node is important when trading. When deciding what node to use, it is important to look at the team behind the private node. A team that can properly scale their infrastructure and can deliver on their roadmap will provide the most long term edge over other traders. When looking for a node a few things should be taken into consideration: Is the node infrastructure designed with high availability and redundancy? Will it have a good response time despite my physical location? And is the team behind the node capable and will they continue to improve? Asking the right questions