本文对比了以太坊和 Solana 的交易费用与计算模型,深入探讨了 Solana 计算单元(CU)的使用、优化策略及字节码执行逻辑,并通过示例验证了 CU 消耗与费用无关的特点,同时介绍了 eBPF 和 SBF 的技术背景。
在以太坊中,交易费用通过公式 gasUsed × gasPrice 计算,反映包含交易所需的以太币成本。发送交易前需预设 gasLimit,若燃气耗尽,交易回滚。
Solana 则不同,其操作码/指令消耗“计算单元”(Compute Units, CU),而非“燃气”。每个交易默认上限为 20 万 CU(可额外付费提升至 140 万 CU),超出限制则交易回滚。与以太坊将存储成本纳入燃气计算不同,Solana 的持久存储定价另行处理,因此本文聚焦操作码执行的费用模型。
两者的字节码执行逻辑相似:以太坊运行 EVM 字节码,Solana 使用改进的 伯克利数据包过滤器(即 SBF,Solana Bytecode Format),并按指令收费。以太坊根据指令复杂性收取 1 至数千燃气,Solana 则统一每条指令为 1 CU。
对于超出限制的重型计算任务,常用策略是将工作分拆,跨多个交易执行。这需要“保存中间状态”至持久存储(后续文章详述)。类似以太坊处理大循环时,需存储“停止索引”和“计算结果”两个变量。
Solana 使用 CU 限制运行时资源,防止无限循环或停机问题。交易默认上限为 20 万 CU,若超出,所有状态变更回滚,费用不退还,保护网络免受恶意密集计算攻击。
与 EVM 链不同,Solana 交易费用与 CU 消耗无关。无论使用 400 CU 还是 20 万 CU,费用恒定,仅由签名数量决定。据 Solana 文档,每个签名固定收取 5000 lamports,交易最多支持 12 个签名(受 1232 字节大小限制)。
以下空程序展示基础费用:
use anchor_lang::prelude::*;
declare_id!("HDSz41Lh841S6AFdLBw1bt34NLkFNY5TAUsfzyFqmQKf");
#[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", () => {
anchor.setProvider(anchor.AnchorProvider.env());
const program = anchor.workspace.ComputeUnit as Program<ComputeUnit>;
const defaultKeyPair = new anchor.web3.PublicKey("5NhLjdFKocoRMqic9sqAe5TxLagJCoCBunzg51ioMYot");
it("Is initialized!", async () => {
let bal_before = await program.provider.connection.getBalance(
defaultKeyPair
);
console.log("before:", bal_before);
const tx = await program.methods.initialize().rpc();
let bal_after = await program.provider.connection.getBalan...
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!