1. Overview

This report covers a comparison between v13.0.2 using go LevelDB and VersionDB + MemIAVL. The results of the analysis show that even though MemIAVL offers a performance boost for state-sync and fast-sync processes, it takes a toll on the resources required for the node. Additionally, the block processing time is higher, which enhances the chances of missing blocks in validator nodes.

2. Methodology

2.1 Multi-Node Setup

To perform the analysis, the multi-node setup present on the evmos/testing repo was used. The setup comprises 5 validator nodes running the same binary, named from node0 to node4, a grafana server, a cAdvisor node, and a transaction bot (evmos/bots) that sends transactions to node4. All validator nodes use the same binary and configuration. This setup was configured to achieve a consistent amount of transactions per block. Additionally, the bot performs only one transaction type. In this way, it is easier to compare the node’s performance with each of the corresponding configurations. For the tests, this setup was run for 10 minutes, with the transaction bot submitting transactions continuously.

The testing scenarios covered with this setup were:

2.2 Mainnet Node

Additionally to the multi-node setup tests, a mainnet node with MemIAVL and VersionDB was synced using state-sync. For this, a GCP e2-highmem-8 VM was used.

Machine specs used are:

The state-sync process was successful and took approximately 2 hours. However, the latest snapshot found by the process was five days old. It took about a day to catch up to the current block height. Once the node fully synced with the chain, CPU, RAM, and disk values were obtained for comparison against a node that uses goLevelDB.

3. Results & Observations

Multi-Node Setup

Scenario 1

Transactions per block

The number of transactions included on the blocks is the same in both cases. As a consequence, the block gas and the block size are equal.

go LevelDB

memIAVL + versionDB