Solana 计算单元与交易费用概述

  • 0xE
  • 发布于 11小时前
  • 阅读 134

本文对比了以太坊和 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.getBalance(
      defaultKeyPair
    );

    console.log("after:", bal_after);
    console.log(
      "diff:",
      BigInt(bal_before.toString()) - BigInt(bal_after.toString())
    );
  });
});

运行 anchor test,输出:

# 测试日志
before: 500000000000000000
after: 499999999999995000
diff: 5000n

# Solana 日志
Status: Ok
Log Messages:
  Program HDSz41Lh841S6AFdLBw1bt34NLkFNY5TAUsfzyFqmQKf invoke [1]
  Program log: Instruction: Initialize
  Program consumed 221 of 200000 compute units
  Program success

费用差额 5000 lamports 对应单一签名(1 × 5000 = 5000),CU 消耗 221 不影响费用。

增加复杂性

修改程序:

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(())
}

输出:

# 测试日志
before: 500000000000000000
after: 499999999999995000
diff: 5000n

# Solana 日志
Status: Ok
Log Messages:
    Program HDSz41Lh841S6AFdLBw1bt34NLkFNY5TAUsfzyFqmQKf invoke [1]
    Program log: Instruction: Initialize
    Program HDSz41Lh841S6AFdLBw1bt34NLkFNY5TAUsfzyFqmQKf consumed 461 of 200000 compute units
    Program HDSz41Lh841S6AFdLBw1bt34NLkFNY5TAUsfzyFqmQKf success

CU 消耗升至 461(约两倍),但费用仍为 5000 lamports,验证了费用与 CU 无关。

优化动机

尽管 CU 不影响费用,优化仍重要:

  1. 未来调整:Solana 可能引入 CU 相关的费用机制,激励节点公平处理复杂交易。
  2. 区块竞争:高网络活动时,小型交易更易被包含。
  3. 程序兼容性:低 CU 消耗便于与其他程序组合,避免占用过多共享限制。

整数类型与计算单元优化

较大整数类型消耗更多 CU,应尽量使用较小类型:

pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
    // 消耗 600 CU(默认 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);

    // 消耗 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);

    // 消耗 600 CU(显式指定 i32)
    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);

    // 消耗 618 CU(与 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);

    // 消耗 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(())
}

分析:u8(459 CU)比 u64/i64(618 CU)更省 CU,因内存占用更小,与值大小无关。

PDA 计算优化

链上使用 find_program_address 生成程序派生地址(PDA)会增加 CU 消耗,因其迭代调用 create_program_address。建议链下计算 PDA 并传递 bump seed,减少开销(后续文章详述)。


eBPF 与 Solana 字节码

什么是 eBPF?

Solana 字节码基于 eBPF(扩展伯克利数据包过滤器),源于 Linux 内核。Rust 或 C 程序编译为 eBPF,在沙箱中执行,响应内核事件(如网络、磁盘操作)。eBPF 支持 64 位操作(故 Solana 最大整数为 u64),类似“内核的 JavaScript”。

用例包括网络分析、安全过滤和性能追踪,仅在事件触发时运行。例如,订阅 vfs_write() 可捕获文件写入数据。

Solana 字节码(SBF)

SBF 是 eBPF 的变体,去除了字节码验证器,依赖 CU 限制确保安全性。运行时检查替代静态验证,支持循环、间接跳转等复杂行为。后续教程将剖析 SBF 示例及其 CU 成本。


【笔记配套代码】 https://github.com/0xE1337/rareskills_evm_to_solana 【参考资料】 https://learnblockchain.cn/column/119 https://www.rareskills.io/solana-tutorial

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
0xE
0xE
0x59f6...a17e
17年进入币圈,Web3 开发者。刨根问底探链上真相,品味坎坷悟 Web3 人生。