Solana 核心概念：计算单元与交易成本解析

在本文中，我们将阐明计算单元（CUs）、交易成本以及它们与 Solana 交易费用之间的区别。尽管这些术语经常被互换使用，但它们在 Solana 的交易处理流程中有着不同的作用。理解这些区别对于构建高效的程序以及确保交易在网络吞吐量增长时能够得到确认至关重要。我们还将详细分析在交易处理过程中计算单元的消耗位置，以及这对开发者为何重要。

计算单元（CUs） vs 交易成本 vs 交易费用

计算单元（Compute Units, CUs） 用于衡量运行时的执行成本。最小的运行时操作消耗 1 个 CU，程序默认每个指令的限制为 20 万 CU，每笔交易的最大限制为 140 万 CU。

你可以在这篇文章中了解更多关于保留最小 CU 的程序。

交易成本是对处理一笔交易所需所有资源的综合估算，以计算单元为单位。交易成本被领导者（leader）用于调度交易和设置区块限制。它不仅包括运行时执行，还涵盖了签名验证、账户数据加载和写锁管理等执行前的开销。

交易费用是你为了补偿验证者处理交易所支付的 SOL（以 lamports 为单位）。这与以计算单元（CUs）衡量资源使用的交易成本不同。

具体来说，交易费用的计算方式如下：

• 优先费用：由交易的计算预算得出，计算公式为：

Compute Unit Price (priorityFee) × Compute Unit Limit (either explicitly set or the default)

• 基础费用：固定收费包括：
  • 每笔交易签名 5,000 lamports。
  • 每个内置指令签名验证（如 Ed25519、secp256k1）5,000 lamports。

这种区别很重要，因为一笔交易可能具有较高的 CU 成本，但除非明确添加优先费用，否则不一定会产生更高的 lamport 费用。

为何这对开发者很重要

通过设置执行 CU 和外围 CU（如账户数据和写账户锁）的限制来优化交易成本，有助于提高交易的优先级/确认率，并为应用程序的未来发展做好准备。

为提高 CU 区块限制做准备

Anza 的目标是在 2025 年将区块空间扩大一倍，并将 CU 限制提高到每个区块 6000 万，这有可能实现每秒 10 万笔交易的吞吐量。按照 Solana 目前每笔交易默认最大 64MB 账户数据的设置，理论上每个区块可能会产生 2.5TB 的潜在数据加载量。

采用 setLoadedAccountsDataSizeLimit 的开发者可以将其视为提高交易确认率的必要准备，因为区块限制和网络吞吐量会不断增加。那些不优化账户数据使用的开发者，在网络拥堵情况下可能会面临越来越高的交易拒绝率和较低的优先级。你可以在这里关于加载账户数据 CU 优化的内容。

此外，Solana 即将推出的 transaction v1 格式（SIMD-0296）将网络交易负载的最大限制从 1232 字节提高到 4096 字节，并移除了地址查找表。这将使开发者能够在单个交易中直接包含更多账户，而无需使用捆绑的解决方法。

优先费用计算

优先费用仅使用执行 CU 计算，而不是总交易成本。领导者使用的优先费用计算方式如下：

Priority Fee = Compute Unit Limit * Compute Unit Price

例如，一笔基本的代币转账可能只需要 6k 执行 CU。但是，如果你没有明确限制加载的账户数据大小，Solana 会默认加载最大 64MB 的数据，这会额外增加 16k CU 的开销。这样一来，总交易成本就会跃升至 22k CU。这种较高的总 CU 成本会降低每个 CU 的有效优先费用，可能会降低交易的优先级。

区块打包决策

在区块打包过程中，领导者使用交易成本来决定哪些交易适合放入区块。在 CU 限制下，领导者通过优先处理奖励与成本比率最高的交易，以最大化每个 CU 的收益。

Block Packing Priority = Reward / Transaction Cost
Reward = Priority Fee + (Transaction Fee - burn)  *By default 50% of transaction fee is rewarded to validators

Solana 交易成本细分

在底层，Solana 中一笔交易的成本由五个主要部分组成，所有部分都转换为 CU 以进行统一衡量：

1. 执行 CU（程序执行成本）：这代表你设置的计算预算。如果程序在执行过程中耗尽了此预算，交易将立即失败。可通过 setComputeUnitLimit 进行修改。

2. 加载的账户数据成本：每笔交易默认加载 64MB 的账户数据，每加载 32KB 消耗 8CU。这意味着即使你的交易没有加载那么多数据，默认也会有 16k CU 的消耗。可通过 setLoadedAccountsDataSizeLimit 进行修改。

3. 写锁成本：这反映了获取交易修改的账户的写锁的成本。每个写锁会产生固定的 300 CU 成本。

4. 签名成本：交易中的每个签名都会因加密验证产生固定的 720 CU 成本。

5. 数据字节成本：交易本身的大小也会增加成本。包含更多指令或大型输入数据的交易需要更多带宽和内存，因此会有更高的 CU 成本。

开发者建议

1. 设置特定的计算限制：不要依赖默认值。模拟你的交易并增加 10% 的缓冲来设置合适的单元限制。

2. 优化账户数据大小：使用 setLoadedAccountsDataSizeLimit 来请求你需要的账户数据大小，这不仅能提高优先级，还能在 CU 区块限制增加时防止未来交易被拒绝。

3. 监控交易成本：使用 RPC 方法 getBlock() 并检查交易数组元数据中的 computeUnitsConsumed 和 costUnits（代表交易成本）。这有助于你分析和优化应用程序。

4. 理解权衡：相同费用下，较高的交易成本意味着较低的优先级，但同时也要确保你的交易有足够的资源来成功执行。

结论

总之，计算单元是 Solana 上计算的基本衡量标准，交易成本是以 CU 衡量的处理一笔交易的总权重。交易费用是你以 lamports（SOL）支付的费用，除非你添加优先费用，否则在很大程度上与你使用的 CU 数量无关。开发者应该优化程序以减少 CU 的使用，并注意账户数据加载和不必要的计算预算余量等开销。随着 Solana 向更高的 TPS 和更大的区块扩展，优化这些因素变得越来越重要。反过来，你的交易将执行得更高效，并且在网络持续扩展时更有可能被优先处理。

---

作者：Brian Wong - DevRel, Anza
原文：https://www.anza.xyz/blog/why-solana-transaction-costs-and-compute-units-matter-for-developers
本文内容仅代表原作者观点，旨在分享技术知识。由于编者水平有限，不保证翻译的完全精确性、完整性和时效性。内容仅供参考，不构成任何建议。