In Ethereum, the price of a transaction is computed as $\text{gasUsed} \times \text{gasPrice}$. This tells us how much Ether will be spent to include the transaction on the blockchain. Before a transaction is sent, a gasLimit is specified and paid upfront. If the transaction runs out of gas, it reverts.
Unlike on EVM chains, Solana opcodes/instructions consume “compute units” (arguably a better name) not gas, and each transaction is soft-capped at 200,000 compute units. If the transaction costs more than 200,000 compute units, it reverts.
In Ethereum, gas costs for computing are treated the same as gas costs associated with storage. In Solana, storage is handled differently, so the pricing of persistent data in Solana is a different topic of discussion.
From the perspective of pricing running op codes however, Ethereum and Solana behave similarly.
Both chains execute compiled bytecode and charge a fee for each instruction executed. Ethereum uses EVM bytecode, but Solana runs a modified version of berkeley packet filter called Solana packet filter.
Ethereum charges different prices for different op codes depending on how long they take to execute, ranging from one gas to thousands of gas. In Solana, each opcode costs one compute unit.
When performing heavy computational operations that cannot be done below the limit, the traditional strategy is to “save your work” and do it in multiple transactions.
The “save your work” part needs to be put into permanent storage, which is not something we’ve covered yet. This is similar to if you were trying to iterate over a massive loop in Ethereum; you’d have a storage variable for the index you left off at, and a storage variable saving the computation done up to that point.
As we already know, Solana uses the compute units to prevent the halting problem and preventing running code that runs forever. It has a compute unit limit per transaction of 200,000 CU (can be increased up to 1.4m CU at some extra cost) which if it (the chosen limit) is exceeded, the program terminates, all changed states revert back and fees are not returned back to the caller. This prevents attackers that intend to run a never ending or computationally intensive program on nodes to slow them down or stop the chain.
However, unlike EVM chains, the computational resources used in a transaction does not affect the fees paid for that transaction. You will be charged as if you used your entire limit or if you used very little of it. For example, a 400 compute unit transaction costs the same as a 200,000 compute unit transaction.
In addition to compute units, the number of signers for the Solana transaction affects the compute unit cost. From the Solana docs:
“So right now, transaction fees are solely determined by the number of signatures that need to be verified in a transaction. The only limit on the number of signatures in a transaction is the max size of transaction itself. Each signature (64 bytes) in a transaction (max 1232 bytes) must reference a unique public key (32 bytes) so a single transaction could contain as many as 12 signatures (not sure why you would do that).”
We can see this in action with this little example. Start with an empty Solana program like so:
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 {}
import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { ComputeUnit } from "../target/types/compute_unit";
describe("compute_unit", () => {
// Configure the client to use the local cluster.
anchor.setProvider(anchor.AnchorProvider.env());
const program = anchor.workspace.ComputeUnit as Program<ComputeUnit>;
const defaultKeyPair = new anchor.web3.PublicKey(
// replace this with your default provider keypair, you can get it by running `solana address` in your terminal
"EXJupeVMqDbHk7xY4XP4TVXq22L3ZJxJ9Gm68hJccpLp"
);
it("Is initialized!", async () => {
// log the keypair's initial balance
let bal_before = await program.provider.connection.getBalance(
defaultKeyPair
);
console.log("before:", bal_before);
// call the initialize function of our program
const tx = await program.methods.initialize().rpc();
// log the keypair's balance after
let bal_after = await program.provider.connection.getBalance(
defaultKeyPair
);
console.log("after:", bal_after);
// log the difference
console.log(
"diff:",
BigInt(bal_before.toString()) - BigInt(bal_after.toString())
);
});
});
Note: In JavaScript, the “n” at the end of a number means it is a BigInt.
Run: solana logs also if you don’t already have it running.
When we run anchor test --skip-local-validator we get this output as the test logs and Solana validator logs:
# test logs
compute_unit
before: 15538436120
after: 15538431120
diff: 5000n
# solana logs
Status: Ok
Log Messages:
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC invoke [1]
Program log: Instruction: Initialize
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC consumed 320 of 200000 compute units
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC success
The balance difference of 5000 lamports is because we need/use only 1 signature (that of our default provider address) when sending this transaction. This is consistent with what we established above, i.e. 1 * 5000 = 5000. Also notice that this costs 320 in compute units but this amount does not affect our transaction fee.
Now, let’s add some complexity to our program and see what happens:
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(())
}
Surely, this should make some difference to our transaction fee right?
When we run anchor test --skip-local-validator we get this output as the test logs and Solana validator logs:
# test logs
compute_unit
before: 15538436120
after: 15538431120
diff: 5000n
# solana logs
Status: Ok
Log Messages:
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC invoke [1]
Program log: Instruction: Initialize
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC consumed 593 of 200000 compute units
Program 6CCLqLGeyExCFegJDjRDirWQRRSbM5XNq3yKvmaWS2ZC success
We can see that this costs more compute units, almost double our first example. But this does not affect our transaction fees. This is expected and shows that truly, compute units do not affect the transaction fees paid by users.
Regardless of the compute units consumed, the transaction charged 5000 lamports or 0.000005 SOL.
Back to compute unit. So, why would we want to optimize compute units since it does not affect fees paid for transactions?
The larger the value types used, the larger the compute unit consumed. It’s best to use smaller types where applicable. Let’s take the code example and comments:
pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
// this costs 600 CU (type defaults to Vec<i32>)
let mut a = Vec::new();
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
// this costs 618 CU
let mut a: Vec<u64> = Vec::new();
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
// this costs 600 CU (same as the first one but the type was explicitly denoted)
let mut a: Vec<i32> = Vec::new();
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
// this costs 618 CU (takes the same space as u64)
let mut a: Vec<i64> = Vec::new();
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
// this costs 459 CU
let mut a: Vec<u8> = Vec::new();
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
a.push(1);
Ok(())
}
Notice the reduction in compute unit cost as the integer type reduced. This is expected as larger types take up larger space in memory than smaller types regardless of the value represented.
Generating a program derived account (PDA) on-chain using find_program_address may use more compute units because this method iterates over calls to create_program_address until it finds a PDA that’s not on the ed25519 curve. To reduce the compute cost, use find_program_address() off-chain and pass the resulting bump seed to the program when possible. More on this is discussed in a later section as its out of scope for this section.
This is not an exhaustive list but a few points to give an idea of what makes a program more computationally intensive than another.
Solana’s bytecode is heavily derived from BPF. “eBPF” simply means “extended BPF.” This section explains BPF in the context of Linux.
Solana VM as you’d expect does not understand Rust or C. Programs written in these languages are compiled down to eBPF (extended Berkeley Packet Filter).
In a nutshell, eBPF allows execution of arbitrary eBPF bytecode within the kernel (in a sandbox environment) when the kernel emits an event the eBPF bytecode subscribes to, example:
You can think of it as JavaScript but for the kernel. JavaScript performs actions on the browser when an event is emitted, eBPF does something very similar for when events are emitted within the kernel, e.g. when a syscall is executed.
This allows us to build programs for various use cases e.g. (based on events listed above):
The program is only executed when we need it (i.e. when an event is emitted in the kernel). For example, say you want to get the name of a file and data written to it when it is written to, we listen/register/subscribe to the vfs_write() syscall event. Now, whenever that file is written to, we have that data at our disposal.
Solana Bytecode Format is a variant of eBPF with certain changes and the one that stands out the most is the removal of the bytecode verifier. The bytecode verifier is present in eBPF to ensure that all possible execution paths are finite and safe to execute.
Solana handles this using compute unit limit . Having a compute meter that limits computational resources spent with a cap moves safety checks to the runtime and allows arbitrary memory access, indirect jumps, loops, and other interesting behaviours.
In a later tutorial, we will deep dive into a simple program and it’s bytecode, tweak it, understand the different compute unit costs and learn exactly how Solana bytecode works and how to analyze it.
This tutorial is part of our Solana course.
Originally Published February, 23, 2024
Cross Program Invocation In Anchor Cross Program Invocation (CPI) is Solana’s terminology for a program calling the public function of another program. We’ve already done CPI before when we sent a transfer SOL transaction to the system program. Here is the relevant snippet by way of reminder: pub fn send_sol(ctx: Context<SendSol>, amount: u64) -> Result<()> […]
Reading Another Anchor Program’s Account Data On Chain In Solidity, reading another contract’s storage requires calling a view function or the storage variable being public. In Solana, an off-chain client can read a storage account directly. This tutorial shows how an on-chain Solana program can read the data in an account it does not own. […]
![#[derive(Accounts)] in Anchor: different kinds of accounts](https://www.rareskills.io/wp-content/uploads/2024/08/935a00_05694389f65848dfb3dee8af7aa05874mv2-1024x576.jpg)
[derive(Accounts)] in Anchor: different kinds of accounts #[derive(Accounts)] in Solana Anchor is an attribute-like macro for structs that holds references to all the accounts the function will access during its execution. In Solana, every account the transaction will access must be specified in advance One reason Solana is so fast is that it executes transactions […]
Modifying accounts using different signers In our Solana tutorials thus far, we’ve only had one account initialize and write to the account. In practice, this is very restrictive. For example, if user Alice is transferring points to Bob, Alice must be able to write to an account initialized by user Bob. In this tutorial we […]