本文介绍了 Solana 中新的 Compute Budget 指令 setLoadedAccountsDataSizeLimit,该指令允许开发者通过限制加载的账户数据大小来优化交易优先级,尤其适用于钱包和嵌入式钱包等低 CU 应用,可显著减少 CU 消耗和提高交易处理优先级。
本文将探讨新的计算预算指令“setLoadedAccountsDataSizeLimit”,并帮助开发者了解如何在生产环境中使用它。正确使用 setLoadedAccountsDataSizeLimit 有潜力显著减少许多高性能应用程序中使用的 CU 数量。
主要目标是使具有低 CU 应用程序(例如钱包、嵌入式钱包提供商等)的开发者能够通过减少其请求的加载账户数据大小来提高其交易优先级。 这种优先级排序机制与新的计算预算规则一致,后者偏向于优化数据使用的交易,可能会影响 CU(计算单元)成本。
在添加此指令之前,交易默认加载高达 64MB 的账户数据,导致大量的内存消耗,费用为每 32KB 8 CU。这种低效的默认设置将额外花费 16K CU,最终降低交易优先级(计算为 (reward_to_leader)/total_CU)并增加成本。 LoadedAccountsDataSizeLimit 指令通过允许开发者(尤其是在像 DeFi 这样对计算敏感的应用程序中)显式指定更小的数据大小限制来解决此问题。 通过仅请求必要的账户数据量而不是完整的 64MB 默认值,交易可以减少其 CU 消耗,提高其处理优先级,并可能在新计算预算规则下实现更好的成本效率。
这种优化对于处理代币转账和其他低 CU 操作的钱包提供商和嵌入式钱包解决方案(如 Phantom、Solflare、Backpack 和 Privy)尤其有价值。 虽然账户数据使用量最少的普通用户可能仍然不受影响,但实施 setLoadedAccountsDataSizeLimit 可以在不影响费用的情况下提高交易优先级。 庄家和 MEV 机器人运营商还可以通过最小化账户数据大小来提高每个区块内的交易优先级,从而使其成为简单操作和高性能应用程序的有用功能。
集成使用 setLoadedAccountsDataSizeLimit 可以显著减少 CU。
以下是演示如何使用 Node.js 实现新指令的代码片段(在 GitHub 上查看):
import { getSetLoadedAccountsDataSizeLimitInstruction } from "@solana-program/compute-budget";
import {
appendTransactionMessageInstruction,
createTransactionMessage,
pipe,
setTransactionMessageFeePayerSigner,
setTransactionMessageLifetimeUsingBlockhash,
} from "@solana/web3.js";
const transactionMessage = pipe(
createTransactionMessage({ version: 0 }),
m => setTransactionMessageFeePayerSigner(feePayerSigner, m),
m => setTransactionMessageLifetimeUsingBlockhash(latestBlockhash, m),
m => appendTransactionMessageInstruction(
getSetLoadedAccountsDataSizeLimitInstruction({
accountDataSizeLimit: 32 * 1024, // 32KB limit
}),
m,
),
);
通过设置 setLoadedAccountsDataSizeLimit,开发者可以请求降低其交易中账户数据大小的默认限制。 例如,默认数据限制为 64MB 是标准配置,但降低此限制(例如,降至 32KB)可以根据公式“16K - actual-loaded-accounts-size”减少 CU 使用量。 计算预算限制提高了 Solana 的区块处理能力。
下面你将找到一个假设场景,演示了使用 setLoadedAccountsDataSizeLimit 正确进行的潜在实际性能提升,并以代币转账为例:
1 个签名
3 个写锁(签名者、来源地址、目标地址)
5 个账户(签名者、来源地址、目标地址、代币程序、计算预算程序)
请求计算预算限制为 8000 CU
支付优先级费用:每个 CU 1.25 lamports
让我们进一步假设:
代币程序指令消耗了 6000 CU
通过 2 个计算预算指令总共消耗 300 CU,实际执行成本 = 6000 + 300 = 6,300 CU
所有账户占用空间均小于 10M 字节
以下是可能发生的情况:
| 指标 | 没有指令 | 使用 10M 限制 |
|---------------------------------|------------------------------|----------------------------|
| 加载的账户数据大小限制 | 64M | 10M |
| 数据大小成本计算 | 64M * (8/32K) | 10M * (8/32K) |
| 数据大小成本 (CUs) | 16,000 | 2,500 |
| 领导者奖励计算 | (1 * 5000 + 1.25 * 8000)/2 | (1 * 5000 + 1.25 * 8000)/2 |
| 领导者奖励 (lamports) | 7,500 | 7,500 |
| 交易成本公式 | 1*720 + 3*300 + 8000 + 16000 | 1*720 + 3*300 + 8000 + 2500|
| 交易成本 (CUs) | 25,471 | 11,971 |
| 优先级分数 | 0.30 | 0.63
如果交易明确请求了足够的字节来加载账户,则优先级会提高一倍以上。
新的计算预算指令为开发者提供了一种通过设置账户数据大小限制来控制交易优先级的方法。 虽然是可选的,但它对于在拥塞环境中需要高优先级处理的低 CU 应用程序很有用。
沟通和示例应针对高数据应用程序中的开发者,以展示利用计算预算的最佳实践,包括 Solana 2.0 增强的处理框架中的潜在成本差异和优先级优势。
- 原文链接: anza.xyz/blog/cu-optimiz...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!