What is the much-anticipated Firedancer on Solana Breakpoint?

Foresight News

24-09-24 12:49

Read this article in 11 Minutes

AI summary

View the summary

Original title: "What is the much-anticipated Firedancer at Breakpoint?"

Original author: Karen, Foresight News

At last week's Solana Breakpoint conference, the atmosphere was lively, ecological product releases followed one after another, and various colorful peripheral activities were the icing on the cake. In this feast, the highlight that particularly attracted attention was the official launch of an early version of the Solana validator client Firedancer on the mainnet. This milestone achievement was given special attention, marking that the Solana network will achieve a qualitative leap in performance, while avoiding the risk of network downtime caused by the crash of a single client on Solana.

Firedancer’s development history dates back to 2021-2022. As the second Solana validator client led by Jump Trading Group (the original client Agave was developed by Anza), its original design intention is to eliminate single point failure risks and enhance the overall robustness and resilience of the network. Unlike the original Rust-based validator, Firedancer is written in C and does not contain 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 Jump Crypto Chief Science Officer Kevin Bowers’ demonstration at the Solana Breakpoint conference, Firedancer demonstrated the ability to process more than 1 million transactions per second, a number far exceeding Solana’s current theoretical limit of tens of thousands of TPS. Kevin Bowers also figuratively likened this achievement to widening a "country road" into an "interstate highway", which indicates the dual optimization of network cost and capacity.

Liam Heeger, a core engineer at Jump Trading, shared the progress of Firedancer on the test network. The client has successfully produced more than 20,000 blocks and achieved a 1% staking ratio.

Another engineer, Aryaman Jain's demonstration further revealed the performance of Firedancer under specific conditions. For example, in an environment with 10 validators, its TPS can reach millions, processing more than 1.2 billion computing units per second, while 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 a network stack, a runtime, and a consensus mechanism. The key to Firedancer's ability to increase the performance of the Solana network to 1 million TPS (current protocol-level limitations limit performance to around 81,000 TPS) lies in its innovative architectural design and data flow optimization.

The validator adopts a concurrency model that performs a variety of jobs through a small number of threads, each of which focuses on a specific task, such as network packet processing, transaction verification, block packaging, etc. This design maximizes resource utilization and significantly improves transaction processing speed.

Specifically, each thread performs one of 11 different jobs. Some jobs only require one thread to complete them, but some jobs require many threads to do the same work in parallel. In addition, each thread has a CPU core to run on, and the thread has ownership of that core: it will never sleep or let the operating system use it for other purposes.

Firedancer also introduces an architecture called "tiles", where each tile represents a job and the thread and CPU core it runs on. This combination makes performance tuning flexible and efficient. For example, each tile of net and quic can process>1 million TPS, while verify and bank tiles focus on transaction verification and block execution. Although their processing speed is relatively low, it is enough to meet the needs of high concurrency scenarios.

Firedancer's official documentation lists 11 tiles, namely:

1.net: Send and receive network packets from network devices (each tile can handle>1 million TPS);

2.quic: Receive transactions from clients, perform all connection management and packet processing to manage and implement the QUIC protocol (each tile can handle>1 million TPS);

3.verify: Verify the cryptographic signature of incoming transactions and filter invalid transactions (each tile can handle 200,000-40,000 TPS);

4.dedup: Check and filter out duplicate incoming transactions;

5.pack: When becoming a leader, it packages incoming transactions and intelligently schedules them for execution;

6.bank: executes scheduled transactions (each tile can handle 200,000-40,000 TPS);

7.poh: is a mechanism that continuously performs hash operations in the background, mixing the generated hash values with the executed transactions to prove sequentiality and timeliness.

8.shred: When becoming a leader, distribute block data to the network; when not a leader, receive and retransmit block data (throughput mainly depends on the cluster size. In the benchmark, if the cluster size is small, 1 tile can handle>1 million TPS);

9.store: Receive block data when becoming a leader, or receive block data from other nodes when other nodes are leaders, and store it in the database on the local disk;

10.metric: Collect monitoring information about other tiles and provide it to the HTTP endpoint;

11.sign: Hold the validator private key, and receive and respond 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 Agave code, combining Firedancer's strengths in network stack and block production while retaining Agave's execution and consensus capabilities. Firedancer was built completely from scratch and does not contain any Agave code.

What is the impact of Firedancer?

Undoubtedly, the launch of Firedancer has a significant impact on the Solana ecosystem, which will greatly enrich the diversity of validators, further weaken the impact of single points of failure on network stability, and build a more solid fortress for the reliability of the Solana network.

In addition, Firedancer maintains backward compatibility with existing protocols, ensuring a smooth transition of the ecosystem without requiring DApp developers and users to make major adjustments.

Although Firedancer is still in non-voting mode and needs to undergo continuous optimization and review, it paints a more promising blueprint for the future development of the Solana network.