> For the complete documentation index, see [llms.txt](https://docs.altiuslabs.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.altiuslabs.xyz/technical-overview/benchmark/benchmark-methodology.md).

# Benchmark Methodology

To ensure performance metrics are rigorous, reproducible, and representative of real-world network conditions, Altius utilizes a custom suite of utilities known as Altius Benchtools. This suite consists of two primary components: the **Transaction Generator** for workload synthesis and the **Profiler** for granular execution tracing.

#### Synthetic Workload Generation

Performance data is derived from synthetically generated block data that mimics specific network behaviors. The system utilizes the `transaction_generator` tool to create deterministic pre-states and transaction lists.

#### Defining Conflict Rates (c0, c20, c50)

A critical variable in these benchmarks is the Conflict Rate (`c`), which measures the frequency at which transactions compete for the same state, such as writing to the same storage slot or account balance.

* **Logic:** The generator accepts a `c` (conflict) flag. This percentage defines the probability of a transaction targeting a specific "hot" pool or account versus a random, non-overlapping address.
* **c0 (0% Conflict)**: Represents ideal parallelism where no two transactions touch the same state.
* **c20 (20% Conflict)**: Represents standard traffic, consisting of a mix of independent transfers and popular decentralized exchange interactions.
* **c50 (50% Conflict)**: Represents high contention, simulating volatility events or high-demand minting where half of the block interacts with a single contract.

#### Workload Types

Our generator supports two primary patterns used in benchmarks:

<table><thead><tr><th width="164.67578125">Workload Type</th><th width="396.21875">Description</th><th>Command Pattern</th></tr></thead><tbody><tr><td>Simple Transfers</td><td>Basic ETH/ERC20 transfers. Used to baseline raw throughput.</td><td><code>transfer -y o2m</code></td></tr><tr><td>Uniswap Simple</td><td>Complex DeFi swaps using original Uniswap V2 contracts. This tests the engine's ability to handle nested calls and storage updates.</td><td><code>uniswap -y simple</code></td></tr></tbody></table>

#### Reproduction Command

To reproduce the **Uniswap Simple (c0)** dataset used in our benchmarks:

```
# Generate 1,000 Uniswap transactions with 0% conflict (Ideal Parallelism)
./target/release/generate uniswap -y simple -t 1000 -c 0
```

To reproduce the **High Contention (c50)** scenario:

```
# Generate 1,000 Uniswap transactions with 50% targeting the "hot" pool
./target/release/generate uniswap -y simple -t 1000 -c 0.5
```

{% hint style="info" %}
**Note on Parallel-Friendly Contracts**: Our tools also support a ***Parallel Friendly*** (-y pf) mode, utilizing modified branchless Uniswap contracts. However, to ensure fair comparison against standard EVM implementations, the benchmarks in the results section utilize the standard simple pattern unless otherwise noted.
{% endhint %}

***

### Execution Profiling

To accurately measure **Time-to-Block** and **TPS**, we utilize the `profiler` tool. This embeds directly into the RPC server to capture multi-threaded execution traces without the overhead of external monitoring tools.

#### Metric Definitions

* **Execution Time:** Measured via `profiler::start("task_name")` and `profiler::end`, strictly capturing the compute time for transaction processing.
* **E2E Time (End-to-End):** Captures the full lifecycle, including:
  1. Transaction decoding
  2. State root calculation
  3. Database commit overhead
* **Client Latency:** The total round-trip time experienced by the client submitting the workload.

#### Output Verification

The profiler outputs a verified JSON trace containing exact timestamps for every thread worker, ensuring that ***Speedup*** metrics account for the overhead of thread synchronization and do not ignore setup costs.

JSON

```
{
  "details": [
    {
      "type": "transaction",
      "status": "success",
      "runtime": 31286, // Microseconds
      "tx": "125"
    }
  ]
} 
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.altiuslabs.xyz/technical-overview/benchmark/benchmark-methodology.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.