Solana Firedancer dev sheds light on the project’s difficulties
Firedancer has yet to go fully live, but its progress has been “pretty impressive,” a dev said
Andis Rea/Shutterstock and Adobe modified by Blockworks
This is a segment from the Lightspeed newsletter. To read full editions, subscribe.
Solana’s Firedancer client — a high-performance implementation of the blockchain’s software being built by Jump — was first announced in 2022.
Nearly three years later, the project still comes with training wheels.
That’s a very long time in the crypto world, so when Firedancer developer Michael McGee joined me on the Lightspeed podcast this week, I was curious to get his take on the client’s timeline. McGee painted an enormously difficult engineering task: rewriting a poorly documented codebase from scratch while the original software sees constant upgrades.
“The fact that…the product is alive…is, I think, pretty impressive,” McGee said of Firedancer.
Firedancer’s biggest current obstacle is the conformance problem, McGee said, where the validator must perfectly match the existing Agave client’s behavior under all circumstances. Conformance is made harder by the fact that Solana developer shop Anza ships a lot of new code, so the software is something of a “moving target,” McGee said.
Anza’s proposed Solana consensus rewrite, Alpenglow, is a “perfect example of something that makes our life very, very difficult,” McGee said, noting that he had personally implemented what he saw as the best possible proof-of-history implementation into Firedancer.
Under Alpenglow, proof-of-history will go away, making all that work moot.
In the meantime, Firedancer’s more limited client has seen growing adoption. Frankendancer is up to 9.3% of all staked SOL, according to Blockworks Research data. Validators running Frankendancer have noticed better-packed blocks, we reported previously.
With Solana’s current block limit of 50 million compute units, McGee said Firedancer can’t push performance as far as it would like to, so it has focused on more efficiently packing blocks in the interim.
When I asked him for Solana’s ideal block limit — which basically defines how compute-intensive blocks can be — McGee said the barrier should be removed entirely, and validators should be left to come to a block size equilibrium.
So that hallowed figure of one million transactions per second is likely a way off, but in the meantime, a number to watch will be 20%. When that proportion of Solana stake is running Frankendancer, the network will be vulnerable to stoppages from the client but better protected from an infinite mint bug.
Get the news in your inbox. Explore Blockworks newsletters:
- The Breakdown: Decoding crypto and the markets. Daily.
- 0xResearch: Alpha in your inbox. Think like an analyst.
