Why Dedicated Nodes makes more sense for heavy indexing workflows
Aug 22, 2023
Current State of Blockchain Node Infra
Currently there are mainly 3 node services out there:
1. Public nodes: where the node URL is shared with all public. E.g. nodes on chainlist.com
2. Elastic nodes: where the nodes are shared among multiple users. E.g. Quicknode
3. Dedicated nodes: where one node is exclusively served for one user.
Typically, a well-constructed decentralized application (dapp) should avoid using a public node, both for reasons of reliability and performance. At present, we observe that elastic nodes have become the default choice for most dapps, while dedicated nodes are reserved for specialized applications. However, we anticipate a shift in this trend. As the industry increasingly embraces L2 and L3 scaling solutions and faster blockchain networks, we expect more dapps to begin relying on nodes that provide greater computing power at a lower cost. Although dedicated nodes are currently underutilized, we believe they will soon become the standard, particularly for workflows that require heavy indexing.
Cost Comparison for Elastic vs. Dedicated
Let’s consider a workflow where a dapp is looking to index all the NFT transfers on Arbitrum and BSC. This is a heavy indexing workflow (indexing to tx level) on two relatively fast chains.
- Arbitrum: 0.3s per block, 1 tx per block
- BSC: 3s per block, 200 tx per block
Indexing steps:
1. Index the block by making eth_getBlockByHash('latest') call to get the latest block responses
2. For each transactions from the block, make eth_getTransactionReceipts calls to get transaction details then fetch the event logs
3. Look up the event logs to parse the NFT transfers
Number of calls for Arbitrum
- 0.3s per block ⇒ 8640000 getBlock call per month
- 1 tx per block ⇒ 8640000 getTx call per month
Number of calls for BSC
- 3s per block ⇒ 864000 getBlock call per month
- 200 tx per block ⇒ 172800000 getTx call per month
| Quicknode (Business) | Triangle | |
|---|---|---|
| Arbitrum | ||
| cost for block call | 8640000 * 2 = 17280000 credits | N/A |
| cost for tx call | 8640000 * 2 = 17280000 credits | N/A |
| BSC | ||
| cost for block call | 864000 * 2 = 1728000 credits | N/A |
| cost for tx call | 172800000 * 2 = 345600000 credits | N/A |
| Total cost per month | 381888000 credits => 120M (baseline) + 260M (overage) => $299 + $10 * 260 ~= $2900 | Arbitrum: $200 ($100 if on-premise) BSC: $500 ($400 if on-premise) => $700 |
Notice the huge difference between elastic and dedicated nodes for multi-chain heavy workflows! The elastic node's pricing is simply not scalable for fast chains with many calls. This example only covers 2 chains, imagine if you have 5+ fast chains!
Performance Comparison for Elastic vs. Dedicated
Here we conduct load testing using flood on triangle's dedicated node and quicknode's node. We sent requests at 300 rps.
Notice that there's a very insignificant difference between the performance of the 3. Triangle's node performs identically compared to the best elastic nodes out there.
Pros & Cons for Elastic vs. Dedicated
| Elastic | Dedicated | |
|---|---|---|
| Reliability | High - Well-tested infra to support large scale of users | Medium to High - Very provider dependent, the performance varies for different providers |
| Scalability | Low - Often rate limited | Medium to High - Rate limit is dependent on the spec of the node |
| Cost-Effectiveness | High (low workflow) Low (heavy workflow) | Medium (low workflow) High (heavy workflow) |
| Accessibility | High - Just an API key is necessary | Medium to High - Often need to wait for the node to be sync’d, no node is available right away |
| Observability | High - Most of the elastic node providers have monitoring/metrics dashboards for their users | Low - Many dedicated node solutions don’t provide a monitoring dashboard High (Triangle) - At Triangle we built a dedicated monitoring service with our proxy to provide similar or even better monitoring experience as elastic node providers |
Where can I get dedicated nodes?
Acquiring dedicated nodes in the present day is not as seamless as obtaining elastic nodes. With elastic nodes, users can simply register for an account and immediately gain access to an API key for the shared node. In contrast, acquiring dedicated nodes often requires users to navigate the entire sales process, involving conversations with the sales team and a waiting period of several days for the nodes to be ready. Only then can they test and decide whether to proceed.
At Triangle, we believe that this process should be largely automated through the streamlining of the deployment pipeline. We are working on constructing a dashboard that empowers every developer to deploy a dedicated node of their choice. This platform will allow them to effortlessly test and build with their chosen node, enhancing efficiency and ease of use.