At last week’s Solana Breakpoint conference, the atmosphere was vibrant with product launches and various engaging side events. A standout highlight was the early version of the Solana validator client Firedancer officially launching on the mainnet.
This milestone achievement received special attention, signaling a significant performance leap for the Solana network while mitigating the risk of network downtime caused by a single client failure.
Firedancer’s development traces back to 2021-2022, spearheaded by Jump Trading Group as Solana’s second validator client (with the original client, Agave, developed by Anza). Its primary goal was to eliminate single points of failure, enhancing the overall robustness and resilience of the network.
Unlike the original Rust-based validator, Firedancer is written in C, excluding Rust code. This choice significantly reduces the potential impact of vulnerabilities on the network, adding a strong layer of security to Solana.
How Does Firedancer Perform?
During a presentation at Solana Breakpoint, Jump Crypto’s Chief Scientist Kevin Bowers showcased Firedancer’s capability to process over 1 million transactions per second (TPS), far exceeding Solana’s current theoretical limit of tens of thousands of TPS. He metaphorically compared this achievement to widening a “country road” into an “interstate highway,” indicating a dual optimization of network costs and capacity.
Core engineer Liam Heeger shared progress on the testnet, noting that Firedancer successfully produced over 20,000 blocks with a staking ratio of 1%. Another engineer, Aryaman Jain, demonstrated Firedancer’s performance under specific conditions, revealing a TPS of up to a million in a 10-validator environment, with over 1.2 billion computations per second and 3.5 Gbps blockspace capacity.
How Does Firedancer Operate?
Firedancer is built around three main components: a high-performance computing stack, a network stack, and the runtime and consensus mechanisms. Its ability to elevate Solana’s performance to 1 million TPS (current protocol limits around 81,000 TPS) lies in its innovative architecture and data flow optimization.
The validator employs a concurrency model that executes diverse tasks across a few threads, with each thread focusing on specific tasks like network packet processing, transaction validation, and block packaging. This design maximizes resource utilization and significantly speeds up transaction processing.
Specifically, each thread executes one of 11 different tasks. Some tasks require only one thread, while others necessitate multiple threads working in parallel. Each thread operates on a dedicated CPU core, ensuring it never sleeps or gets repurposed by the operating system.
Firedancer also introduces an architecture called “tiles,” where each tile represents a job, its running thread, and allocated CPU core. This combination allows for flexible and efficient performance tuning. For instance, net and quic tiles can handle over 1 million TPS, while verify and bank tiles focus on transaction validation and block execution, sufficient for high-concurrency scenarios.
Firedancer’s official documentation lists the following 11 tiles:
- net: Sends and receives network packets (each tile can handle >1 million TPS);
- quic: Receives transactions from clients, managing connection and packet processing for the QUIC protocol (each tile can handle >1 million TPS);
- verify: Validates the cryptographic signatures of incoming transactions, filtering out invalid ones (each tile can handle 20-40,000 TPS);
- dedup: Checks and filters duplicate incoming transactions;
- pack: Packages incoming transactions when acting as the leader, smartly scheduling them for execution;
- bank: Executes scheduled transactions (each tile can handle 20-40,000 TPS);
- poh: Continuously hashes in the background, mixing generated hashes with executed transactions to prove ordering and timing;
- shred: Distributes block data to the network when acting as the leader; when not, it receives and retransmits block data (throughput mainly depends on cluster size, with benchmarks indicating >1 million TPS for small clusters);
- store: Receives block data when acting as the leader or from other nodes when they are leaders, storing 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 responds to signing requests from other tiles.
Notably, before Firedancer matures, its transitional version, Frankendancer, has already entered the Solana mainnet. Frankendancer is a hybrid of Firedancer and Agave’s code, leveraging Firedancer’s advantages in network stack and block production while retaining Agave’s execution and consensus functionalities. In contrast, Firedancer is built entirely from scratch without any Agave code.
What Is Firedancer’s Impact?
Undoubtedly, the launch of Firedancer has significant implications for the Solana ecosystem, greatly enhancing validator diversity and further reducing the risk of single points of failure, thereby fortifying the network’s reliability.
Moreover, Firedancer maintains backward compatibility with existing protocols, ensuring a smooth transition for the ecosystem without requiring substantial adjustments from DApp developers and users.
Although Firedancer is currently in non-voting mode and undergoing continuous optimization and auditing, it paints a hopeful picture for the future development of the Solana network.
-
-
-
-
-
-
-
-
