What is Firedancer, the much-anticipated project at Breakpoint?
TechFlow Selected TechFlow Selected
What is Firedancer, the much-anticipated project at Breakpoint?
How does the Solana validator client Firedancer perform? How to run it?
Navigating Web3 tides with focused insightsBy Karen, Foresight News
At last week's Solana Breakpoint conference, the atmosphere was vibrant, with a continuous stream of ecosystem product launches and a variety of engaging side events adding to the excitement. Among the highlights of this grand event was the highly anticipated debut of Firedancer—the early version of Solana’s second validator client—going live on mainnet. This milestone achievement has drawn significant attention, signaling that the Solana network is poised for a qualitative leap in performance while also mitigating the risk of network outages caused by failures in a single validator client.
Firedancer’s development journey dates back to 2021–2022. As the second validator client for Solana—complementing Agave, which was developed by Anza—Firedancer is led by Jump Trading Group. Its primary goal is to eliminate single points of failure and enhance the overall robustness and resilience of the network. Unlike the original Rust-based validator, Firedancer is written entirely in C and contains no Rust code, significantly reducing the potential impact of vulnerabilities on the broader network and adding another strong layer of security for Solana.
How Does Firedancer Perform?
According to Kevin Bowers, Chief Scientific Officer at Jump Crypto, during his presentation at Solana Breakpoint, Firedancer demonstrated the ability to process over one million transactions per second (TPS)—a figure far exceeding Solana’s current theoretical limit of tens of thousands of TPS. Bowers vividly compared this advancement to upgrading from a "country road" to an "interstate highway," foreshadowing dual optimizations in network cost and capacity.
Liam Heeger, a core engineer at Jump Trading, shared updates on Firedancer’s progress on testnet, noting that the client has successfully produced over 20,000 blocks and achieved a 1% staking share.
In another demonstration, engineer Aryaman Jain revealed Firedancer’s performance under specific conditions: in a setup with 10 validators, it reached TPS levels in the millions, processed over 1.2 billion compute units per second, demonstrated 3.5 Gbps blockspace capability, and achieved VM execution efficiency of up to 500,000 TPS.
How Does Firedancer Work?
Firedancer is built around three core components: a high-performance computing and networking stack, Runtime, and consensus mechanism. The key reason Firedancer can scale Solana’s network performance to 1 million TPS—despite current protocol-level constraints capping performance at around 81,000 TPS—lies in its innovative architectural design and data flow optimization.
The validator employs a concurrent model where a small number of threads handle diverse tasks, with each thread dedicated to a specific function such as network packet processing, transaction validation, or block packing. This design maximizes resource utilization and dramatically improves transaction processing speed.
Specifically, each thread performs one of 11 distinct jobs. Some jobs require only a single thread, while others involve many threads executing the same task in parallel. Each thread runs on its own CPU core and exclusively owns that core—it never sleeps or allows the operating system to repurpose it.
Firedancer introduces an architecture called “tiles,” where each tile represents a job along with its associated thread and allocated CPU core. This modular approach 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. Though their throughput is relatively lower, they are still sufficient to meet demands in high-concurrency scenarios.
The official Firedancer documentation lists 11 types of tiles:
-
net: Sends and receives network packets from network devices (each tile handles >1 million TPS);
-
quic: Receives transactions from clients, manages all connection handling and packet processing required to implement the QUIC protocol (each tile handles >1 million TPS);
-
verify: Validates cryptographic signatures of incoming transactions and filters out invalid ones (each tile handles 200,000–400,000 TPS);
-
dedup: Checks for and filters duplicate incoming transactions;
-
pack: When acting as leader, bundles incoming transactions and intelligently schedules them for execution;
-
bank: Executes scheduled transactions (each set of tiles handles 200,000–400,000 TPS);
-
poh: A mechanism that continuously performs hash computations in the background, mixing generated hashes with executed transactions to prove order and timing.
-
shred: When leader, distributes block data across the network; when not leader, receives and retransmits block data (throughput mainly depends on cluster size. In benchmarks, one tile can handle >1 million TPS with smaller clusters);
-
store: Receives block data when acting as leader, or fetches it from other nodes otherwise, storing it in a local disk-based database;
-
metric: Collects monitoring data from other tiles and exposes it via HTTP endpoints;
-
sign: Holds the validator’s private key and responds to signature requests from other tiles.
Notably, even before Firedancer’s full maturity, its transitional version—Frankendancer—has already entered the Solana mainnet. Frankendancer is a hybrid combining parts of Firedancer and Agave code, leveraging Firedancer’s advantages in networking and block production while retaining Agave’s execution and consensus functionalities. In contrast, Firedancer itself is built entirely from scratch without any code from Agave.
What Impact Will Firedancer Have?
Undoubtedly, the introduction of Firedancer carries profound implications for the Solana ecosystem. It will greatly enrich validator diversity, further reduce the risks posed by single points of failure, and build a more resilient foundation for Solana’s network reliability.
Moreover, Firedancer maintains backward compatibility with existing protocols, ensuring a smooth transition for the ecosystem without requiring major adjustments from DApp developers or users.
Although Firedancer currently operates in non-voting mode and requires ongoing optimization and auditing, it paints a far more promising picture for the future development of the Solana network.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
Foresight News
