You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

In the realm of cryptocurrency, the pursuit of scalability continues to dominate discussions and technological innovations. A key contender in this space is the Firedancer, a validator client aimed at significantly increasing the scalability of Solana, potentially up to ten times or more. The objective is to take Solana's theoretical maximum throughput from the current 50,000 transactions per second (inclusive of voting transactions) to an impressive range of 500,000- ~1 million transactions per second (TPS).

Firedancer is new, independent Solana validator client being developed by Jump Crypto. Developed by a separate team from the Solana validator, Firedancer will help increase client diversity on Solana and make bugs less likely to halt the network (due to the low overlap of bugs in both clients, if one fails, the other can continue running). The main difference between Firedancer and the Solana Rust validator is its modular architecture, which runs many individual C processes called "tiles" (compared to the Solana Rust validator, which runs as a single process). 

Key Features of Firedancer:

1. Modular Design: In contrast to Solana's monolithic Rust validator, Firedancer is built on multiple independent C processes called tiles. This structure improves resilience against failures and facilitates seamless upgrades without any downtime.

2. High-Speed Packet Processing: Firedancer incorporates an innovative message-passing framework that allows it to access network interface buffers directly. By utilizing high-performance computing principles, Firedancer can handle and filter around 100 Gbps of network traffic on a standard Solana validator server.

3. Runtime Consistency: Firedancer prioritizes dependable results for every stage of the blockchain process to ensure reliability. Comprehensive testing strategies, including integration testing, fuzz testing, and the creation of specification documents, will further enhance the validator's runtime accuracy.

4. Secure Supply Chain: To reduce dependency on external sources, Firedancer relies on a minimal number of external dependencies, treats all build-process tools as dependencies, and uses the Bazel build system to ensure high-reliability software.

This capacity has already been showcased live by Jump Crypto at Solana’s Breakpoint conference last year. It is important to note the distinction between a live demo and a production-ready validator client – two very different stages of implementation.

Solana validators are primarily responsible for various operational functions, such as transaction propagation, transaction processing, transaction broadcasting, and transaction verification. Jump has pledged to release Firedancer piece by piece, ensuring that each function is optimized and ready for public use. The first significant milestone was the Firedancer implementation of the QUIC transaction propagation protocol, known as fd_quic.

QUIC plays a crucial role in transaction messaging from clients to the lead validator client, who produces the current block. Solana employs a proprietary UDP-based protocol to transfer transactions between RPC nodes and the current leader. Unfortunately, this means there is no meaningful method of prohibiting nefarious behavior or spam. To remedy this, Solana has implemented QUIC, a protocol invented by Google, designed for rapid asynchronous communication like UDP, but with sessions and flow control like TCP.

Upgrade 1.10 was released in Q2 2022 and aimed at solving many of Solana's previous spam issues (discussed in the Vulnerabilities section) through three specific changes: QUIC, stake-weighted transaction QoS, and fee-based execution priority.

QUIC is a transport protocol that came out of Google and stands for Quick UDP Internet Connections. It replaced UDP for packet delivery within the Solana protocol and is sent straight from the RPC Node directly to the block leader. By switching to QUIC, Solana can mitigate most "IP spoofing" while not sacrificing much speed. This means QUIC will disallow an anonymous spoofer to send the same transaction multiple times, a popular strategy in spam bots.

QUIC will help ensure that block producers are not hammered by millions of transactions through Gulfstream and that they can verify all their transactions within Solana’s 400ms block time. During this initial release, QUIC is optional for RPC and dApps, giving them time before having to officially upgrade. 

Source

Stake-weighted transaction Quality of Service (QoS) works in parallel with QUIC, aiming to prioritize network bandwidth based on stake-weight e.g., how much SOL a validator has staked relative to other nodes. It is a computer science methodology to control data traffic for bandwidth-constrained networks. So, a node with a 1% stake-weight should be able to transmit 1% of packets to the leader.

fd_quic is an extension of QUIC designed to achieve the throughput levels Firedancer aims for. For a network to process transactions at a rate of 1 million per second, transaction propagation must be capable of matching that speed.

To manage transaction propagation at such a high rate, networks must utilize "load balancing," or the distribution of processing requirements. Traditionally, this is achieved at the software level – dividing processing across multiple CPU cores within a single validator, for instance. Firedancer takes a combined approach, using both hardware and software-based upgrades to scale load balancing up to the 1 million TPS target.

On the hardware side, fd_quic divides the work across multiple tiles on the same validator, and optionally across multiple validators. This hardware-based approach is complemented by software specified for Solana, using the latest algorithms and optimized data structures. This software assists with "Receive Side Scaling," or RSS, when combined with the hardware-based load balancing.

Despite the impressive progress so far, much work lies ahead. The QUIC implementation is a significant but solitary step in a sequence of crucial steps needed to fully realize the Firedancer client. The final version of Firedancer will need to rewrite each validator component for scalability. This is critical because a network can only process transactions as quickly as its slowest component.

For this reason, Firedancer is focusing not only on the networking layer but also on the consensus and execution layers. The scalability of consensus is being addressed through hardware-accelerated signature verification, with efforts underway to enhance execution throughput. Ultimately, each component responsible for Solana's transaction processing will need to be recreated by Jump Crypto to achieve the desired throughput levels. This endeavor will also involve additional optimizations for Solana's transaction validation unit. The journey is ongoing, but the initial progress is promising and indicative of the potential for scaling blockchain networks to new heights.