Why a Tile Architecture¶

Docs-site note (2026-06-25): A "why we chose it" page — the core-pinning tradeoff only; the layout details and numbers live in the Performance overview.

The decision¶

A validator runs many jobs at once: ingest packets, verify signatures, replay blocks, vote, and persist the ledger to disk. On a shared thread pool these jobs compete for the same cores, and the scheduler is free to preempt the one job that must never stall — the consensus path (replay → vote) — to run background I/O. A late vote can mean missed credits or, in the worst case, delinquency.

Firedancer solves this with a tile architecture: each stage of the pipeline is a dedicated OS thread ("tile") pinned to its own CPU core, communicating over message-passing rings, so no stage can preempt another. Vexor adopts the same principle — isolate the consensus path from I/O by pinning hot stages to dedicated cores — and applies it selectively to the stages that matter most.

An important scoping note, stated up front: Vexor is a conventionally-threaded validator (Agave/Sig lineage) that applies tile-style core-pinning to the consensus-critical path. It is not a full Firedancer-style tile-per-stage rewrite. The rationale below is the "why"; the implementation is PARTIAL and described honestly as such.

The problem with a shared thread pool¶

Property	Shared thread pool	Tile-style pinning (chosen)
Core assignment	Scheduler decides; threads migrate between cores	Hot stages pinned to fixed, dedicated cores
Consensus vs background	Background I/O (persist, compaction-equivalent) can preempt replay/vote	Background work runs on separate cores — it cannot preempt voting
Cache / NUMA behavior	Thread migration thrashes per-core caches	Pinned threads keep warm caches; pinning is NUMA/CCX-aware
Tail latency	Jittery — depends on what else the scheduler ran	Predictable — the consensus core does consensus, nothing else

The cost of a shared pool is tail latency on the one path that has a deadline. When the persist thread, sigverify, and replay all land on the same core under load, voting can be delayed by work that has no business preempting it. Pinning removes that interference by construction rather than by hoping the scheduler does the right thing.

What Vexor actually does¶

Vexor applies the tile principle where it pays off and leaves the rest conventionally threaded:

Parallel transaction execution on dedicated worker cores (DONE, live). The WavePool wave-barrier executor runs its workers on dedicated cores chosen to sit off the hot pipeline (away from the cold CCX that hosts non-consensus consumers, and off the main process mask). This is deployed and bank-exact.
Core-mask carve-outs. The main process is launched with a CPU mask that excludes the wave-worker cores, so general floater threads cannot contend with the pinned executor. The pinning is NUMA/CCX-aware — workers are placed on a CCX off the hot pipeline, never on the cold CCX reserved for background/RPC work.
Persist off the consensus path. The VexLedger persist path (fsync) is kept off the hot consensus cores so ledger writes never preempt replay or voting. A dedicated ledger tile (a cold core plus a message-passing ring, the Firedancer-style move) is specified and PLANNED to formalize this further.
Generic core pinning is opt-in. A general dynamic pinner exists but is DORMANT by default — the consensus-critical pinning above is the deployed, proven part; whole-validator tile placement is not on by default.

The concrete core numbers, the full stage-to-core map, and the measured effect are owned by the Performance overview.

Why we adopted the tile principle¶

The consensus path gets a deadline guarantee by construction. Pinning replay/vote-adjacent work to dedicated cores and pushing I/O elsewhere means background work cannot steal the cycles voting needs — no reliance on scheduler fairness.
Predictable tail latency. A pinned core does one job, so its latency doesn't depend on whatever else the scheduler happened to co-schedule. That predictability is what protects vote timing under load.
Cache and NUMA locality. Pinned threads keep their caches warm and stay on the right NUMA/CCX domain, avoiding the cross-core/cross-domain memory traffic that thread migration causes.
It is the proven model. Firedancer demonstrated that dedicated-core tiles are how you get deterministic performance out of a validator; Vexor adopts the principle on the path where it matters most without committing to a full ground-up tile rewrite.

Honest caveats¶

PARTIAL, not a full tile architecture. Vexor applies tile-style pinning selectively to the consensus-critical path; it is not a Firedancer-style tile-per-stage rewrite of the whole validator. The dedicated ledger tile is PLANNED (specified, not yet built), and the generic dynamic pinner is dormant by default.
Needs enough cores. The benefit assumes the host has cores to dedicate. On a small or oversubscribed machine, pinning fewer stages buys less, and on a tight core budget the carve-outs may not be worth it.
CCX/NUMA layout is hardware-specific. The placement that works on the deployment hardware (which CCX is "cold," which cores host the wave pool) is tuned to that topology; the principle is portable, the exact core numbers are not. Specific core assignments are deployment configuration, not a fixed contract.