Solana devs weigh proposal to juice validator revenue
The proposed amendment takes aim at Solana’s “compute budget” program, which was put in as a safeguard against computational waste
Artwork by Crystal Le
Today, enjoy the Lightspeed newsletter on Blockworks.co. Tomorrow, get the news delivered directly to your inbox. Subscribe to the Lightspeed newsletter.
In an attempt to pack Solana blocks more efficiently, Anza engineer Tao Zhu is proposing a core change to the Solana protocol. The amendment — laid out in Solana Improvement Document (SIMD) 0172 — takes aim at Solana’s “compute budget” program, which was put in as a safeguard against computational waste. Zhu argues this leads to an inefficient use of Solana blockspace.
While there seems to be reasonably broad agreement that the compute budget program should be changed, some Solana developers have argued that SIMD-0172 doesn’t go far enough. At its core, the proposal strikes a familiar chord in Solana engineering — the problem of handling data while building a blockchain that is fast, cheap and shares state across an entire network.
The compute budget is a line of code that dictates how many compute units — a Solana-native measure of computational resources — a transaction can use. Different transactions do different things, so they take up different amounts of CUs. But Solana doesn’t want wasteful transactions adding to the massive amount of data it already needs to keep track of, so transactions are given a limit of 200,000 CUs by default.
This means every Solana block — which contains a maximum of 48 million CUs — will save 200,000 CUs worth of space for transactions with the default compute budget.
The problem, in Zhu’s view, is that 200,000 is often an overestimation. Often, transaction creators don’t ask for a more precise compute budget, so blocks are essentially reserving empty space. (For what it’s worth, I glanced at my most recent SOL transfer, and it used 86,000 CUs).
Instead, Zhu wants to ramp the default of 200,000 down to zero CUs over 10 epochs, or roughly 20 days. Then, transactors will need to request a more exact amount of compute.
As a result, the 48 million CUs in a Solana block would be able to include more transactions, which means more fees would be paid to validators. This will be a welcome sight for validators who — as we’ve covered before — aren’t having the easiest go of things recently.
Not everyone is thrilled with Zhu’s proposed fix. Basically, even if the compute budget is defaulted to zero, transactions would still need to include instructions for the compute budget.
These instructions count against the maximum of 1232 bytes (a measure of data) that can be included in a transaction. Compute budget instructions take up 4% of the total, by one developer’s estimate.
This side would favor moving the compute budget to the transaction header, which is separate from instructions and could take up fewer bytes.
Solana could get rid of the compute budget program entirely, Zhu has said, but that’s for down the road. Not everyone was thrilled.
“Adding an interim fix just adds more pain for developers,” one Solana dev wrote.
Start your day with top crypto insights from David Canellis and Katherine Ross. Subscribe to the Empire newsletter.
Explore the growing intersection between crypto, macroeconomics, policy and finance with Ben Strack, Casey Wagner and Felix Jauvin. Subscribe to the Forward Guidance newsletter.
Get alpha directly in your inbox with the 0xResearch newsletter — market highlights, charts, degen trade ideas, governance updates, and more.
The Lightspeed newsletter is all things Solana, in your inbox, every day. Subscribe to daily Solana news from Jack Kubinec and Jeff Albus.
