The capacity to scale is worth billions of dollars in the cryptocurrency market. Each year, a large number of Layer-1, Layer-2, and even Layer-3 networks have pooled their resources and raised billions of dollars in an effort to find a solution to the scalability challenge. The network that figures out a solution to that issue will hold one of the most important keys to chasm-crossing acceptance in the years to come.

Communications between validator nodes are at the heart of the issue that we're having. Validator clients are the software that the crypto validators run, and they provide the power for crypto networks. Cryptography cannot exist in the absence of a network of dispersed servers working together to execute and verify the transmission of information. Web2 doesn't have any issues with this at all. Almost every centralized server and database solution is easily capable of scaling up to support millions of users. Scalability is not an issue when there is, for all intents and purposes, only one node.

The challenge that Web3 faces is duplicating that level of scalability over a network of dispersed servers and decentralized data stores. There are, as of right now, generally speaking, two primary methods to accomplish this goal: the well-known modular approach and the monolithic approach.

The modular method often refers to the practice of dividing up transaction settlement, transaction processing, and data availability over numerous different chains. By performing transactions on Layer-2s, for instance, Ethereum's rollup architecture divides the process of transaction execution from the process of transaction settlement. Through the use of this strategy, Ethereum is able to keep a large collection of accessible nodes on L1, all while increasing the speed of transactions by executing them on a more limited group of nodes located on L2s.

Over the past couple of three years, the modular approach has seen a substantial increase in popularity.

The monolithic method is diametrically opposed to and contradictory to the modular approach. The monolithic theory maintains that node hardware can scale to the point where Web 2-level scalability can be reached at the Layer-1 level. This can be accomplished without the need to split functions across chains and without making a significant sacrifice to the degree to which decentralization is maintained.

Monolithic networks such as Solana believe that the scalability produced by the modular method can be replicated or even surpassed by making decisions regarding design, combining those choices with hardware and software improvements, and so on. The most significant of these improvements is brought about by an entirely new validator client for Jump Crypto called Firedancer, which is currently under development.

Technical Specs of the Firedancer

Firedancer is a validator client that has the goal of increasing the scalability of Solana by a factor of ten or more. The present theoretical maximum throughput for Solana is 50,000 transactions per second (including voting transactions), however, Firedancer hopes to increase that number to between 0.6 and 1.2 million transactions per second (TPS).

firedancer mechanism breakdown

At least at first blush, the idea of a single network being able to handle one million transactions per second across all of its nodes may seem like a pipe dream. Despite this, Jump Crypto has already given a live demonstration of these capabilities at the Breakpoint conference held by Solana the previous year. However, a production-ready validator client and a live demo are two wholly different things, so keep that in mind.

In a general sense, validators for Solana are accountable for the following operating duties:

Sending transaction data from network users to the leader validator and receiving transaction data as the leader validator are both part of the process known as transaction propagation.
Transaction Processing refers to the process of carrying out the computations required to carry out transactions, update account information, and maintain account status.
Broadcasting Transactions: Sending transaction information to validators located everywhere in the network
Verification of Transactions: Checking the Transactions' Validity and Completing the Transactions

Jump has committed to the release of Firedancer on a component-by-component basis, with the intention of making available to the general public optimized versions of each function as soon as they are live and ready. The first significant achievement was the completion of the fd_quic implementation of the QUIC transaction propagation protocol by the Firedancer team. Why QUIC is important?

solana quic

QUIC is responsible for handling transaction communications between clients and the lead validator client (the client that generates the current block).

It took the place of UDP, which had previously served as Solana's transaction dissemination protocol. This decision was taken in order to address previous outage difficulties that were brought on by problems with spam filtration that UDP was unable to manage.

fd_quic adjusts the parameters of the original QUIC so that it corresponds to the throughput that Firedancer is aiming for. After all, a network is only capable of processing transactions at the same rate as it can receive them. If the target is 1 million transactions per second, then the pace at which transactions are propagated must also be 1 million per second.

In order for networks to manage transaction propagation at any pace, let alone 1 million TPS, they need to "load balance." In other words, the processing needs need to be divided up in some kind. Traditionally, this has been accomplished at the level of the program by, for example, distributing the processing over many CPU cores that are contained within a single validator.

To grow load balancing up to one million transactions per second (TPS), Firedancer makes use of changes to both its hardware and its software.

Hardware: fd_quic is responsible for load balancing on the hardware side. It does this by distributing the work among many tiles on a single validator, and it may also distribute the work across numerous validators.

Software: Jump Crypto then combines this method with software that has been specified for Solana with the most recent algorithms and optimized data structures. This is done in conjunction with the hardware-based load balancing solution known as "Receive Side Scaling," or RSS.

The outcomes of pursuing this strategy appear to hold a lot of potential. The performance example provided by Jump Crypto demonstrated that fd_quic was processing transactions at a rate of 1.08 million TPS using only four CPU cores. As a point of comparison, it is suggested that Solana validators run with 12 cores or more.

It is not known what the upper bound on scaling fd_quic is. During much of the tests, the connection between the number of CPU cores and performance was linear, but after reaching around 23 Gbps, it began to decline. The decrease in speed was mostly the consequence of the capabilities of the network that was being tested, which were capped at about 25 Gbps at their highest point.

The progress that Jump Crypto has made up to this point is tremendous, but the company still has a ways to go. The implementation of QUIC is just one important step among many important stages that must be taken in order to fully develop the Firedancer client. It is not clear what direction exactly Jump Crypto will go in terms of future releases; nonetheless, the ultimate version of Firedancer will need to rework each validator component in order to grow.

Since a network can only handle transactions at the speed of its slowest component, Firedancer is working on the other two primary components in addition to the networking layer. These are the consensus layer and the execution layer.

Firedancer is now working on increasing execution performance while simultaneously addressing the scalability of consensus by using hardware-accelerated signature verification (1 million sigverify per second on accessible off-the-shelf integrated circuits).

The components outlined above make up the current collection of those responsible for transaction processing inside Solana. In order to extend Solana's transaction processing to the throughput levels that Jump Crypto is aiming for, it will be necessary for Jump Crypto to rebuild each. However, this is not where the buck stops since the transaction validation unit that Solana utilizes will need its own separate set of component optimizations.

Firedancer unlocks new possibilities for Solana

Enough with the technology; why does any of this even matter? If and when Firedancer is successfully released, there will be three significant unlocks available to players:

DeFi levels up

DeFi Maturity describes the point at which decentralized exchanges achieve parity with centralized exchanges through the reduction of latency delays brought about by Firedancer improvements.

New Application Possibilities As a result of the 1+ million throughputs that are allowed by Firedancer scalability, Web2 apps are now conceivable on-chain.

Chain Resiliency: The introduction of Firedancer has led to a greater variety of customers, which has contributed to an increase in Solana's chain's robustness.

One of the most significant criticisms leveled against cryptocurrency is the fact that the vast majority of its activity does not even make use of cryptocurrency but is rather carried out on centralized platforms. Centralized exchanges have, with a few notable exceptions, maintained a significant trade volume advantage over decentralized alternatives for the entirety of the cryptocurrency industry's history. Latency is too high and inconsistent in comparison to centralized counterparts, which are 10 times faster than the majority of pre-Firedancer L1s on average, with some being 100 times quicker at their best. This is one of the primary reasons why this is the case.

It is not possible for Firedancer to implement latency at a quicker rate than the current goal block time of 400 milliseconds for Solana. Through optimizing the validator software, it is possible to reduce latency to the range of 400-500 milliseconds (down from the current median range of 1-2 seconds) and maybe boost consistency, as well. If that turns out to be the case, then Solana would be right up there with the upper end of observed CEX latency times, which is a characteristic that no other network would be able to claim at scale.

New dApps

The throughput and state storage capabilities of a blockchain often dictate the kinds of applications that may be created using this distributed ledger technology. Additionally, the loss of composability that occurs whenever one attempts to increase throughput by utilizing techniques like rollups and the like further narrows the application's potential use cases.

Therefore, if Solana can scale to the point where it can process 1 million transactions per second, all on the same chain, the potential apps that may be constructed would dramatically increase in comparison to the application protocols that are now in use. It has the potential to open high-throughput financial applications in addition to conventional consumer applications such as social media. Consumer, in particular, calls for an exceptionally high volume of simultaneous user actions (transactions) as well as an exceptionally low cost per transaction unit. For instance, social postings are examples of user activities that have a large volume but a low median value. For this to make any kind of sense from a financial standpoint, the transaction unit cost would have to be incredibly low.

On the DeFi side of things, if decentralized finance can't keep up with the demand from its core user base, then it will never be able to replace traditional financial railroads like it was predicted it would be able to do while DeFi was on its way to becoming more prominent. The throughput of modular solutions can be increased on Ethereum by a factor of ten from their prior levels, but at best, they can only match the throughput of Web2 for a single application per chain. If throughput requirements were met via a succession of appchains atop Layer-3s, this would be at the expense of decentralization and composability, which is perhaps the most important aspect of blockchains.

Firedancer makes it possible for a wide variety of applications to operate simultaneously on Solana at Web2 scale without compromising composability. Depending on how long it takes Firedancer to debut, it's likely that this new development won't be enough to attract the "soon-to-be's" of the globe.

Classifying the users into four levels provides a useful foundation for thinking about the application possibilities of a chain. These categories are current users, soon-to-be-users, refused users, and unexplored customers.

three tiers of customers

The vast majority of cryptocurrency applications developed today fall into one of the first two categories—current or soon-to-be—because their primary focus is on further developing their products and including new features. However, refusing consumers and undiscovered consumers are users who have never even entertained the idea of utilizing cryptocurrency apps because of certain fundamental product needs. Rethinking the fundamental structures of the chain and the protocols is necessary in order for application developers to successfully cater to the aforementioned user demographics. Solana and Firedancer are concentrating their efforts on figuring out how to address the fundamental limitations of the chain in order to facilitate the development of new kinds of apps for consumers who are not currently being served.

The technique used by Solana and Firedancer may, in the long term, prove to be a dominating tactic akin to blue ocean competition. The exceptional trifecta of cheap transaction unit cost, high concurrent throughput, and asset composability has the potential to fuel applications that cannot be supported by the EVM-centric architectures that are now in use.

Increased Solana Resilience Obtained Through Increasing Client Diversity

Chain halts have been frequently recorded throughout Solana's history. These have often been caused by defects that manifest themselves in reaction to any variety of problems, the most common of which are spam attacks (which were stopped by QUIC). The introduction of a backup client, such as the Labs client or the Jito client, considerably reduces the severity of this issue risk. This is due to the fact that it is extremely uncommon for two clients, particularly ones built in completely different coding languages, to experience a bug out at the exact same time. In a universe in which Firedancer is operational, a flaw may in theory, bring the system to a halt, but Solana would not be affected because the network can simply shift the burden to validators that are operating Solana Labs or Jito clients.

Having stated that, even if a bug were to successfully bring down Firedancer, it would downgrade the performance of the chain because the other clients do not have comparable performance capabilities. Large increases in transaction fees would be the most likely outcome if Firedancer were to go down. This is because the volume of transactions that are now being processed at over 1 million TPS would suddenly be throttled down to the low thousands of TPS.

Associated Threats to the Solana Ecosystem

There are potential downsides to each significant technological innovation. For the Firedancer project, we have determined that there are three primary axes to consider: execution, timing, and competitive threats.

Execution risk

The development of Firedancer is a mammoth undertaking. Its momentum is good for the time being, but it might slow in the future for any one of a variety of causes that are now unknown. It would appear that the Solana ecosystem is putting all of its hopes into the success of a single Firedancer in order to achieve the subsequent step-function improvement in throughput scaling. Solana will suffer a significant setback in the event that the basket cannot be delivered by Jump Crypto.

There is a record in the cryptocurrency industry for significant technological advances not delivering as promised. Sharding, which was once slated to be introduced in 2020 as part of Ethereum's original roadmap for Ethereum 2.0, was originally envisioned as the major scaling method. Instead, the focus shifted toward the rollup-centric strategy in 2021 and 2022 as the primary objective.

The Solana ecosystem, which does not have the same set of luxuries that Ethereum did between 2018 and 2020, will collapse under the weight of similar delays and vision shifts. As the leader of the market, Ethereum had the luxury of delaying its launch and later making a course correction because its competitors at the time were primarily funny projects that lacked even the most basic capabilities. In comparison, Solana has anything from three to ten rivals, depending on the market, and it has to deal with competition on several fronts. In the event that Firedancer would not make it to the market, Solana's opportunities there would be greatly reduced.

It is important to keep in mind that the chance of such a turn of events occurring is not known. Due to the fact that it has prior experience in high-frequency trading, Jump Crypto is one of the very few companies that currently exists that has a realistic opportunity to pull it off.

Timing Risk

What if Jump Crypto fulfills its obligations, but it is already too late? If lock-in from Ethereum developers or liquidity network effects is too powerful for any competitor's technological shift to overcome, then a significant technical improvement on the size of Firedancer could as well be pointless. This might be the case for a variety of different reasons. In light of the fact that significant corporations such as Visa have already begun producing studies focused on Ethereum, time is working against Solana in this regard.

Competition risk

There are other companies than Jump that are working on scaling blockchains to more than 1 million transactions per second (TPS). There's a good reason why scalability is a buzzword worth a billion dollars. Teams from a variety of ecosystems are all fighting with one another to achieve this aim. The monolithic chains Sui and Aptos, both of which are built on the Move programming language, are already considered to be "next-gen Solanas." Although these rival chains have not yet demonstrated the performance to support that assertion, there is a good chance that they will in the future. If that day arrives before Firedancer does, then Solana is going to find itself in a difficult situation.

Within the realm of modular approaches, sophisticated rollup designs could be able to approximate Firedancer-level scale by utilizing OP Stack Superchains, rollups-as-a-service models, volitions, and other mechanisms. Although these models may not have the same amount of inherent composability as Solana's method, it is possible that the apps that enroll millions of cryptocurrency users will not require that level of composability. In addition, Ethereum rollup-based alternatives have the advantage of being able to tap into Ethereum-based liquidity and development talent with more ease, providing them a competitive edge over the Solana ecosystem as it exists now.

Some bottom lines

In the apparently counterintuitive Solana technology stack, Firedancer is the newest crucial cog, joining state compression and local fee markets as new vital components. If Firedancer is successfully implemented, Solana will have the unique capacity to provide throughput scaling on a level that has never been seen before, near-parity with the latency times of centralized exchanges, inexpensive transaction, and asset issuance costs, leading composability capabilities, client variety, and more.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

Firedancer: Solana's Endgame