What Exactly Is Firedancer the Highly Anticipated Feature on Breakpoint

CoinWorld.com reports:
How does the Solana validator client Firedancer perform? How does it work?
Author: Karen, Foresight News
At last week’s Solana Breakpoint conference, the atmosphere was lively, with a succession of ecosystem product releases and a variety of colorful peripheral activities. The highlight of this feast was the official launch of the early version of the Solana validator client Firedancer on the mainnet, which received special attention as a milestone achievement, signaling a qualitative leap in performance for the Solana network and mitigating the risk of network downtime due to the crash of a single client on Solana.
The development of Firedancer can be traced back to 2021 to 2022. As the second validator client developed by Jump Trading Group (the original client Agave was developed by Anza), its design aims to eliminate single point of failure vulnerabilities and enhance the overall stability and robustness of the network. Unlike the original Rust-based validator, Firedancer is written in C language and does not include Rust code. This choice significantly reduces the impact of potential vulnerabilities on the entire network and adds another solid line of defense to Solana’s security.
How does Firedancer perform?
According to Kevin Bowers, Chief Scientist at Jump Crypto, during his demonstration at the Solana Breakpoint conference, Firedancer demonstrated the ability to process over 1 million transactions per second, far exceeding Solana’s current theoretical limit of tens of thousands of TPS. Kevin Bowers also metaphorically described this achievement as widening a “country road” into an “interstate highway,” indicating a dual optimization of network cost and capacity.
Jump Trading’s core engineer, Liam Heeger, shared the progress of Firedancer on the testnet, stating that the client has successfully produced over 20,000 blocks and achieved a 1% staking ratio.
Another engineer, Aryaman Jain, further revealed the performance of Firedancer under specific conditions. In a 10-validator environment, its TPS can reach millions, with over 1.2 billion computational units processed per second, demonstrating a blockspace capacity of 3.5 Gbps and a VM execution efficiency of 500,000 TPS.
How does Firedancer work?
Firedancer is built around three main components: a high-performance computing stack and network stack, runtime, and consensus mechanism. The key to its ability to improve Solana network performance to 1 million TPS (the current protocol-level limit restricts performance to around 81,000 TPS) lies in its innovative architectural design and data flow optimization.
The validator adopts a concurrency model, executing diverse tasks with a small number of threads, each focusing on specific tasks such as network packet processing, transaction verification, and block packaging. This design maximizes resource utilization and significantly improves transaction processing speed.
Specifically, each thread performs one of the 11 different tasks. Some tasks only require one thread to complete them, while others require multiple threads to parallelize the same work. Additionally, each thread runs on a CPU core and owns that core: it never sleeps or allows the operating system to use it for other purposes.
Firedancer also introduces an architecture called “tiles,” where each tile represents a task, the thread running it, and the CPU core allocated to it. This combination enables flexible and efficient performance tuning. For example, net and quic tiles can each handle >1 million TPS, while verify and bank tiles focus on transaction verification and block execution. Although their processing speed is relatively slower, it is sufficient to meet the demands of high-concurrency scenarios.
The official Firedancer documentation lists 11 types of tiles:
net: sends and receives network packets from network devices (each tile can handle >1 million TPS);
quic: receives transactions from clients and manages and implements the QUIC protocol for connection management and packet processing (each tile can handle >1 million TPS);
verify: verifies the cryptographic signatures of incoming transactions and filters out invalid transactions (each tile can handle 20-40,000 TPS);
dedup: checks and filters out duplicate incoming transactions;
pack: packs incoming transactions and intelligently schedules their execution when becoming a leader;
bank: executes the scheduled transactions (each tile can handle 20-40,000 TPS);
poh: a mechanism for continuously performing hash calculations in the background, mixing the generated hash values with executed transactions to prove order and timeliness.
shred: distributes block data to the network when becoming a leader; receives and retransmits block data when not a leader (throughput mainly depends on cluster size. In benchmark tests, if the cluster size is small, 1 tile can handle >1 million TPS);
store: receives block data when becoming a leader or receives block data from other nodes when other nodes are leaders and stores them in a local disk database;
metric: collects monitoring information about other tiles and provides it to HTTP endpoints;
sign: holds the validator’s private key and receives and responds to signature requests from other tiles.
It is worth noting that before the maturity of Firedancer, a transitional version called Frankendancer had already entered the Solana mainnet. Frankendancer is a hybrid of Firedancer and Agave, combining the advantages of Firedancer in network stack and block production with the functionality of Agave in execution and consensus. Firedancer, on the other hand, is built entirely from scratch and does not include any Agave code.
What is the impact of Firedancer?
Undoubtedly, the launch of Firedancer has a significant impact on the Solana ecosystem, greatly enriching the diversity of validators and further weakening the impact of single point of failure on network stability, building a stronger fortress for the reliability of the Solana network.
Furthermore, Firedancer maintains backward compatibility with existing protocols, ensuring a smooth transition of the ecosystem without major adjustments required by DApp developers and users.
Although Firedancer is currently in non-voting mode and requires continuous optimization and auditing, it paints a more hopeful blueprint for the future development of the Solana network.
References:
1. https://www.youtube.com/watch?v=InGI7BDUeX4&list=PLilwLeBwGuK4eY3nT0vvvJ4GmcJLImcQE&index=14
2. https://firedancer-io.github.io/firedancer/guide/tuning.html
3. https://solanacompass.com/learn/Validated/firedancer-w-kevin-bowers