Skip to content

How It Works

SSMT sits beside an execution client and computes state roots for it. The client executes a block, streams the resulting state changes to SSMT over an IPC transport, and SSMT returns the new state root.

flowchart LR
    Reth["Execution client<br/>Reth-based"] <-->|"state changes / root (IPC)"| Server["ssmt-server"]
    Server --> Orch["Orchestrator"]
    Orch --> Pool["Worker pool<br/>nibble-partitioned threads (≤16)"]
    Pool --> Cache["In-memory cache"]
    Cache -->|miss| MDBX[("MDBX store")]

Parallelism: nibble-partitioned worker threads

Trie work is partitioned by the first nibble (4 bits) of each key and routed to a pool of worker threads (between 1 and 16). Each worker owns its partition and walks its portion of the trie independently; the per-partition sub-roots are then aggregated into the final root. A "shard" in SSMT is therefore a worker thread within one process — not a server or a network node.

Memory hierarchy and persistence

Each worker reads through an in-memory cache hierarchy in front of an on-disk MDBX store: hot nodes are served from memory, and only cache misses hit the database. Per-block state changes are applied to MDBX as durable deltas.

Transports and modes

  • Transport — the engine and client communicate over IPC. A Unix domain socket is the supported path today; other transports exist in the codebase but are not yet wired into the server.
  • Modes — the server can run live (receive blocks from a client in real time), capture (record incoming blocks for later use), and replay (re-run captured blocks without a live client), which is how much of the correctness and performance validation is done.

Performance

SSMT includes a benchmarking harness that times its parallel root computation against sequential baselines on the same data, validating every result against the client's recorded state root so a wrong run fails loudly. Reported speedups depend heavily on the workload (for example, storage-heavy blocks behave differently from account-heavy ones), so figures should come from your own runs rather than a single headline number.

Note

SSMT is evolving quickly; treat published internals and benchmark figures as subject to change.