In the Ethereum ecosystem, transaction costs are calculated using a straightforward formula: gasUsed × gasPrice. This determines the exact amount of Ether required to execute and include a transaction on the blockchain. Users must specify a gasLimit upfront and pay this estimated cost. If a transaction exceeds this limit, it fails and reverts, consuming the allocated gas without completing.
Solana, however, employs a different model. Instead of "gas," Solana uses "compute units" to measure computational effort. Each transaction is initially capped at 200,000 compute units. Exceeding this limit causes the transaction to revert, similar to Ethereum's gas mechanism.
While Ethereum combines computational and storage costs under a single gas metric, Solana treats storage separately. This distinction means that persistent data pricing on Solana involves different considerations, though computational opcode pricing follows a comparable logic.
Both blockchains execute compiled bytecode and charge fees per instruction. Ethereum uses EVM bytecode, while Solana operates on a customized version of the Berkeley Packet Filter (BPF), known as the Solana Packet Filter.
Ethereum assigns varying gas costs to different opcodes based on execution time, ranging from one to thousands of units. In contrast, every Solana opcode costs exactly one compute unit.
Strategies for Handling High Compute Demand
What happens when a transaction requires more than the standard compute unit limit? For computationally intensive operations, developers must break the work into multiple transactions. This involves saving intermediate progress to permanent storage—similar to handling large loops in Ethereum, where storage variables track the current index and partial results.
Optimizing Compute Unit Usage
Solana's compute unit system prevents the halting problem by limiting how long code can run. The default cap is 200,000 compute units per transaction, though this can be increased to 1.4 million for an additional fee. Transactions that exceed their allocated compute units terminate, revert all state changes, and do not refund fees. This safeguards the network against malicious actors attempting to degrade performance with infinite loops or resource-heavy operations.
Unlike Ethereum, Solana's transaction fees are not directly tied to compute unit consumption. Whether a transaction uses 400 or 200,000 compute units, the cost remains the same based on other factors.
Fees are primarily influenced by the number of signatures required for a transaction. According to Solana's documentation, each signature verification contributes to the total fee. Since each signature and its associated public key consume space within the transaction (max size 1,232 bytes), the practical limit is around 12 signatures per transaction.
Practical Fee Calculation Example
Consider a simple Solana program:
use anchor_lang::prelude::*;
declare_id!("6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC");
#[program]
pub mod compute_unit {
use super::*;
pub fn initialize(_ctx: Context<Initialize>) -> Result<()> {
Ok(())
}
}
#[derive(Accounts)]
pub struct Initialize {}Testing this with a client:
import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { ComputeUnit } from "../target/types/compute_unit";
describe("compute_unit", () => {
anchor.setProvider(anchor.AnchorProvider.env());
const program = anchor.workspace.ComputeUnit as Program;
const defaultKeyPair = new anchor.web3.PublicKey("EXJupeVMqDbHk7xY4XP4TVXq22L3ZJxJ9Gm68hJccpLp");
it("Is initialized!", async () => {
let bal_before = await program.provider.connection.getBalance(defaultKeyPair);
const tx = await program.methods.initialize().rpc();
let bal_after = await program.provider.connection.getBalance(defaultKeyPair);
console.log("diff:", BigInt(bal_before.toString()) - BigInt(bal_after.toString()));
});
});The output shows a fee of 5,000 lamports (0.000005 SOL), consistent with one signature verification. The compute units consumed (320) did not affect the cost.
Adding computational complexity:
pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
let mut a = Vec::new();
a.push(1);
a.push(2);
a.push(3);
a.push(4);
a.push(5);
Ok(())
}This increased compute usage to 593 units but the fee remained 5,000 lamports. This demonstrates that computational load does not currently influence transaction costs.
Why Optimize Compute Units?
Despite the lack of direct fee impact, optimizing compute usage remains important for several reasons:
- Future protocol changes may tie fees to compute consumption.
- Transactions with lower compute demands are more likely to be included during network congestion.
- Efficient programs are more composable; other contracts may avoid integrating with compute-intensive code due to shared transaction limits.
👉 Explore advanced optimization techniques
Data Types and Compute Efficiency
The choice of data types significantly affects compute unit consumption. Smaller integers generally use fewer resources. Consider these examples:
pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
// Costs ~600 CU (default Vec<i32>)
let mut a = Vec::new();
for _ in 0..6 { a.push(1); }
// Costs ~618 CU (Vec<i64>)
let mut b: Vec<i64> = Vec::new();
for _ in 0..6 { b.push(1); }
// Costs ~459 CU (Vec<i8>)
let mut c: Vec<i8> = Vec::new();
for _ in 0..6 { c.push(1); }
Ok(())
}Smaller types reduce memory usage and computational overhead. Similarly, generating Program Derived Addresses (PDAs) on-chain with find_program_address can be compute-intensive due to its iterative nature. Whenever possible, compute PDAs off-chain and pass the bump seed to the program.
Understanding eBPF and Solana's Architecture
Solana's bytecode derives from extended Berkeley Packet Filter (eBPF). Originally developed for Linux, eBPF enables safe execution of bytecode within the kernel in response to specific events like network activity, disk operations, or process creation.
Think of eBPF as JavaScript for the kernel: it triggers actions based on system events. This architecture supports various use cases including network analysis, security filtering, performance profiling, and system observability.
Solana Bytecode Format (SBF) modifies eBPF by removing the bytecode verifier. Instead of pre-verification, Solana relies on runtime compute metering to ensure program safety. This allows greater flexibility while maintaining security through resource limits.
Frequently Asked Questions
What are compute units in Solana?
Compute units measure computational work on Solana, similar to gas in Ethereum. Each operation costs one compute unit, with transactions limited to 200,000 units by default. This system prevents infinite loops and ensures network stability.
How are Solana transaction fees calculated?
Fees are primarily determined by the number of signatures required for a transaction. Each signature verification costs 5,000 lamports. Computational complexity currently doesn't affect fees, though this may change in future protocol updates.
Why optimize compute units if they don't affect fees?
Optimization improves transaction inclusion chances during congestion and enhances composability with other contracts. Future Solana versions might also tie fees directly to compute consumption.
What is the relationship between eBPF and Solana?
Solana uses a modified version of eBPF called Solana Bytecode Format (SBF). This execution environment allows safe runtime computation through metering rather than pre-execution verification.
How can I reduce compute unit usage?
Use smaller data types where possible, precompute values off-chain, and avoid unnecessary operations. For PDAs, calculate addresses off-chain and pass bump seeds to programs.
Can I increase the compute unit limit?
Yes, transactions can request up to 1.4 million compute units for additional costs. However, exceeding the chosen limit still causes reverts without fee refunds.
Understanding compute units and fee structures helps developers build efficient, cost-effective applications on Solana. As the network evolves, these concepts may change, but the fundamentals of resource management remain critical for successful dApp development.