Bitroot Performance Benchmarks

Draft. Figures below come from one internal stress test. Hardware, node count, software version and transaction type are still to be added, so the page stays unindexed until they are.

This page states how Bitroot measures throughput, under which conditions, and how the numbers can be reproduced. The design target and the measured result are reported separately. Every measured figure names the run it comes from.

1. Targets and measurements

The measured throughput is below the design target. The target describes what the architecture is built to reach. The measurement describes what one run produced.

2. Definitions

TPS here is the chain-side rate: the number of transactions that landed in blocks divided by the time from the first to the last landed transaction. It is not the rate at which the load generator sent transactions. For the general vocabulary see Performance metrics glossary.

TODO(engineering): state whether consensus and network overhead are included, and how failed transactions would be counted. In this run none failed.

3. Test environment

The load tool also reports a blocks setting of 300 and a chunk size of 0 KB. TODO(engineering): explain what these two mean before they are published as conditions.

4. Workload and results

TODO(engineering): state the transaction type. The report lists the recipient as "default" and does not say whether the run used native transfers, token transfers or contract calls. Transfer-only numbers are an upper bound for real applications, so this must be stated next to the result. See also Hotspots in parallel EVM workloads for how conflicts change throughput.

Raw output

The load tool's report, unedited:

==================================================
🔥 Stress Test Report
==================================================
Total Planned:       30000000
Successfully Sent:   30000000
Duplicate Sent:      0 (already known, not counted above)
Failed to Send:      0
Landed Transactions: 30000000
Success Rate:        100.00%
Retry Attempts:      0
Signing Time:        79499764 ms (all sign_batch_txs)
Total Pause Time:    79499764 ms (incl. recharge & signing)
--------------------------------------------------
Send Duration:       805.19s
Total Duration:      805.19s (incl. waiting)
Average RPS:         46425.94 req/s (send speed)
Average TPS:         46425.94 tx/s (inclusion speed)
--------------------------------------------------
Run Mode:            mempool
Nonce Mode:          local
Signer Count:        500
Blocks:              300
Chunk Size:          0 KB
Tip Wei:             5000000000
Mempool TXs:         100000
To:                  default
Real Chain TPS:      36430.68 tx/s (first to last landed)
==================================================

The tool prints two throughput lines. "Real Chain TPS" (36,430.68 tx/s, first to last landed transaction) is the chain-side figure used on this page. "Average RPS" and "Average TPS" (46,425.94) are not used: they do not match 30,000,000 transactions over 805.19 s, which is about 37,257 tx/s.

TODO(engineering): explain how the tool computes "Average TPS", and what the "Signing Time" and "Total Pause Time" lines (79,499,764 ms each) measure, so a reader can reconcile the report.

5. Reproduce the results

TODO(engineering): link the stress-test tool, the exact commit, the command line and configuration, and the raw output.

6. Known limits

• One run is not sustained production load. It shows what the network did for roughly 13 minutes under this setup.
• The load is a single workload. Throughput under high contention, for example many transactions touching the same contract, is not covered.
• The result applies to the environment above once it is filled in, and to no other.

7. Independent verification

TODO(product): link any third-party measurement or audit report with the organization, scope and date. If none exists yet, say so here.

8. Changelog