What exactly is the highly anticipated Firedancer on Breakpoint?
How does the Solana validator client Firedancer perform? How to run it?Author: Karen, Foresight News
At last week's Solana Breakpoint conference, the atmosphere was lively, with a series of ecological product launches and a variety of colorful side events adding to the excitement. Among the highlights of this feast, the early version of the Solana validator client Firedancer officially launched on the mainnet, a milestone achievement that received special attention, marking a qualitative leap in the performance of the Solana network while mitigating the risk of network downtime caused by a single client failure.
The development of Firedancer can be traced back to 2021-2022, as the second validator client for Solana led by Jump Trading Group (the original client Agave was developed by Anza). Its design intent was 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 in C language and does not contain Rust code, a choice that significantly reduces the potential impact of vulnerabilities on the entire network, adding a solid line of defense for Solana's security.
How does Firedancer perform?
According to Jump Crypto's Chief Scientist Kevin Bowers during his presentation at the Solana Breakpoint conference, Firedancer demonstrated the ability to process over 1 million transactions per second, a figure far exceeding Solana's current theoretical limit of tens of thousands of TPS. Kevin Bowers vividly likened this achievement to widening a "country road" into an "interstate highway," indicating a dual optimization of network costs and capacity.
Jump Trading's core engineer Liam Heeger shared the progress of Firedancer on the testnet, where the client has successfully produced over 20,000 blocks and achieved a 1% staking ratio.
Another engineer, Aryaman Jain, further revealed Firedancer's performance under specific conditions, such as in an environment with 10 validators, where its TPS can reach millions, processing over 1.2 billion compute units per second, while demonstrating a Blockspace capability of 3.5 Gbps and a VM execution efficiency of 500,000 TPS.
How does Firedancer operate?
Firedancer is built around three main components: a high-performance computing stack, a network stack, and a runtime and consensus mechanism. The key to Firedancer's ability to elevate the performance of the Solana network to 1 million TPS (the current protocol-level limit restricts performance to around 81,000 TPS) lies in its innovative architecture design and data flow optimization.
The validator employs a concurrency model that executes diverse tasks with a small number of threads, each focused on specific tasks such as network packet processing, transaction validation, and block packaging. This design achieves maximum resource utilization and a significant increase in transaction processing speed.
Specifically, each thread executes one of 11 different tasks. Some tasks require only one thread to complete, while others need many threads to perform the same work in parallel. Additionally, each thread has a CPU core to run on, and the thread owns that core: it will never sleep or allow the operating system to use it for other purposes.
Firedancer also introduces an architecture called "tiles," where each tile represents a task and its running thread and allocated CPU core. This combination allows for flexible and efficient performance tuning. For example, each tile for net and quic can handle >1 million TPS, while verify and bank tiles focus on transaction validation and block execution, although their processing speed is relatively lower, it is sufficient to meet the demands of high-concurrency scenarios.
The official documentation of Firedancer lists 11 types of tiles, which are:
- net: Sends and receives network packets from network devices (each tile can handle >1 million TPS);
- quic: Receives transactions from clients, manages all connection management and packet processing to implement the QUIC protocol (each tile can handle >1 million TPS);
- verify: Validates the cryptographic signatures of incoming transactions and filters out invalid transactions (each tile can handle 20-40 thousand TPS);
- dedup: Checks and filters out duplicate incoming transactions;
- pack: When becoming the leader, packages incoming transactions and intelligently schedules their execution;
- bank: Executes the scheduled transactions (each tile can handle 20-40 thousand TPS);
- poh: A mechanism that continuously hashes in the background, mixing the generated hash values with executed transactions to prove order and timing.
- shred: When becoming the leader, distributes block data to the network; when not the leader, receives and retransmits block data (throughput mainly depends on cluster size. In benchmarks, if the cluster size is small, 1 tile can handle >1 million TPS);
- store: Receives block data when becoming the leader, or receives block data from other nodes when they are the leader, and stores it 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 Firedancer matured, its transitional version Frankendancer had already entered the Solana mainnet. Frankendancer is a hybrid of Firedancer and some code from Agave, combining Firedancer's advantages in network stack and block production while retaining Agave's functionalities in execution and consensus. In contrast, Firedancer is built entirely from scratch without any Agave code.
What impact does Firedancer have?
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 points of failure on network stability, building a more solid fortress for the reliability of the Solana network.
Moreover, Firedancer maintains backward compatibility with the existing protocol, ensuring a smooth transition for the ecosystem without requiring significant adjustments from DApp developers and users.
Although Firedancer is currently still in non-voting mode and requires continuous optimization and auditing, it paints a more hopeful blueprint for the future development of the Solana network.
