Author: Karen, Foresight News

At last week's Solana Breakpoint conference, the atmosphere was lively, with a succession of ecological product releases and a variety of colorful peripheral activities. The most eye-catching 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 Solana's network performance and avoiding the risk of network downtime caused by 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 of Solana developed by Jump Trading Group (the original client Agave was developed by Anza), its original intention was to eliminate single point of failure, 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. This choice significantly reduces the potential impact of vulnerabilities on the entire network, adding another strong line of defense to Solana's security.

How does Firedancer perform?

According to Kevin Bowers, Chief Scientist of Jump Crypto, 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 likened this achievement to widening a "country road" to 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, 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 achieving a million-level TPS in a 10-validator environment, processing over 1.2 billion computational units per second, demonstrating a 3.5 Gbps Blockspace capability, and a 500,000 TPS VM execution efficiency.

How does Firedancer operate?

Firedancer is built around three main components: high-performance computing stack, network stack, runtime, and consensus mechanism. The key to its ability to increase 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 concurrent model, executing a diverse set of 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 executes one of 11 different tasks. Some tasks require only one thread to complete them, while others require many threads to execute the same work in parallel. Additionally, each thread has a CPU core to run and owns that core: it never sleeps or lets the operating system 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 makes performance tuning flexible and efficient. For example, each net and quic tile can handle >1 million TPS, while verify and bank tiles focus on transaction verification and block execution, with relatively lower processing speeds but sufficient for high-concurrency scenarios.

The official Firedancer documentation lists 11 types of tiles, namely:

1. net: sending and receiving network packets from network devices (each tile can handle >1 million TPS);
2. quic: receiving transactions from clients, managing connections, and packet processing to manage and implement the QUIC protocol (each tile can handle >1 million TPS);
3. verify: verifying the cryptographic signatures of incoming transactions, filtering out invalid transactions (each tile can handle 20-40,000 TPS);
4. dedup: checking and filtering out duplicate incoming transactions;
5. pack: when acting as a leader, packaging incoming transactions and intelligently scheduling their execution;
6. bank: executing the scheduled transactions (each tiles can handle 20-40,000 TPS);
7. poh: a mechanism continuously performing hash calculations in the background, mixing the generated hash values with executed transactions to prove order and time;
8. shred: when acting as a leader, distributing block data to the network; when not a leader, receiving and retransmitting block data (throughput mainly depends on the cluster size. In benchmark tests, if the cluster size is small, 1 tile can handle >1 million TPS);
9. store: receiving block data when acting as a leader, or receiving block data from other nodes when other nodes are leaders, and storing it in a local disk database;
10. metric: collecting monitoring information about other tiles and providing it to the HTTP endpoint;
11. sign: holding the validator's private key and receiving and responding 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 Agave, combining the advantages of Firedancer in network stack and block production, while retaining Agave's functionality in execution and consensus. Firedancer, on the other hand, is built from scratch and does not contain 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, further weakening the impact of single point of failure on network stability, and building a more robust 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 the need for major adjustments 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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。