2 篇博文 含有标签「Paymaster」

五年来，“交易所需的 SOL 不足”一直是 Solana 上代价最高昂的错误提示。每一个曾向非加密用户推销过的消费级应用，都在这一步流失了一定比例的用户——就在结账环节，一个陌生人必须先获取第二种代币，仅仅是为了花掉第一种代币。2026 年 4 月，Solana 基金会终于发布了解决方案：Kora，一个费用中继器和签名节点，它允许 dApp 原生赞助交易、使用任何 SPL 代币支付费用，并将签名工作外包给 TEE（可信执行环境）或 KMS 驱动的保管库。这并非一次华丽的发布，而是一次底层架构的升级。而底层架构的升级，正是 Base 和 Abstract 在过去 12 个月里悄无声息地占据消费级用户入驻市场的秘诀。

现在的问题不再是 Solana 能否追赶上 EVM 消费级链的无 Gas 体验。Kora 让这一部分变得轻而易举。真正的问题在于，弥补这最后一公里的差距是否足以赢回那些已经在其他地方构建应用的开发者。

Kora 究竟交付了什么​

剥开营销的外壳，Kora 其实是由三部分组成的结合体：交易中继器、远程签名者和策略引擎。dApp 构建一笔交易，将 Kora 节点设置为费用支付者（fee payer），用户通过嵌入式钱包签署有效负载，然后 Kora 运营商进行共同签名并广播。验证者仍然以 SOL 形式获得报酬，但用户无需持有任何 SOL。

真正有趣的是它的验证层。Kora 节点不会盲目中继用户提交的任何内容。在签名之前，它会进行三项检查：

• 指令校验：针对相关的 Solana 程序进行检查，以便在畸形或恶意指令到达 Leader 节点之前将其拒绝。
• 基于预言机的费用充足性校验：将提供的 SPL 代币数量与当前 SOL 价格（加上运营商利润）进行对比，确保中继器永远不会亏损运行。
• 程序和代币层面的白名单与黑名单强制执行：这样，为单个 dApp 运行 Kora 节点的运营商就永远不会意外赞助针对某些随机、未经审计合约的交易。

签名路径是该架构最具雄心的地方。Kora 开箱即用支持通过 Turnkey 和 AWS KMS 进行远程签名，这意味着支付费用的私钥永远不会存储在中继器的磁盘上。对于在 Solana 上构建的金融科技公司来说，这就是“我们自己搞了个支付主合约并祈祷不出错”与“我们的密钥托管方案通过了 SOC 2 审计”之间的本质区别。

整个项目已由 Runtime Verification 进行了审计和差异化模糊测试，这种细节只有在你希望机构用户关注时才会提及。

为什么“原生”在此处优于“智能合约”​

人们很容易将 Kora 与 ERC-4337 进行比较，并认为 Solana 正在迎头赶上。但两者的架构实现的是不同的功能，这种差异至关重要。

ERC-4337 是作为以太坊之上的并行系统实现的账户抽象。它引入了独立的内存池（mempool）、UserOperation 对象、Bundler（打包器）角色和 EntryPoint（入口点）合约——这些都是基础协议原生无法理解的。Bundler 封装用户操作，Paymaster 赞助费用，链上合约强制执行校验。它确实有效，并且已在以太坊主网和主要 L2 上部署，但这是一项耗时六年的工程，旨在改造一个协议从未预见的 UX 功能。

Solana 的设计早在几年前就在协议层消化了这种复杂性。每笔交易都已经包含一个 feePayer 字段。部分签名（Partial signatures）是原生的。程序可以验证任意指令。Kora 并不是一个“打包器与支付主合约”的构造；它是一个节点运营商，负责填充 feePayer 位置并使用协议已经接受的部分签名之一进行签署。

实际结果体现在延迟和开发者的触达面上。ERC-4337 交易通过具有自身排序规则和传播延迟的独立内存池。而 Kora 交易与所有其他 Solana 交易走同样的路径，具有相同的亚 400 毫秒最终确认性。无需考虑 Bundler 套利市场，无需跟踪 EntryPoint 合约版本，也无需调试 UserOperation 的 Gas 估算。

这为 Solana 开发者换来的是接近于“设置费用支付者字段，发布 dApp”的体验。失去的是 EVM 智能账户免费获得的一些可选性——例如多密钥身份验证、批量调用、链上会话策略——尽管其中大部分正通过 PDA 和程序控制账户在 Solana 上独立构建。

Solana 曾经真正存在的最后一公里差距​

尽管都在谈论 Solana 在 2025 年和 2026 年的开发者势头，但消费级钱包层曾是滞后的部分。基础设施栈成熟得很快：Pump.fun 的 DEX 交易量在 2026 年第一季度突破了 20 亿美元，Jito 和 Marinade 主导了流动性质押，Tensor 将 NFT 交易变成了专业的终端。但这些产品中的每一个都不得不针对“用户没有 SOL”这一问题推出自己的解决方案。

这些绕过方法各具创意。Pump.fun 通过嵌入式法币入口引导初始代币获取；Jito 为用户账户预先注入微量资金；Tensor 依靠 Phantom 和 Backpack 在用户进入出价单之前处理 SOL 获取步骤。这些方法在个体上都奏效了，但它们无法协同。一个通过 Pump.fun 流程入驻的用户，在到达 Tensor 时并不会拥有一个可以支付费用的余额。

与此同时，Base 推出了 Coinbase 智能钱包的通行密钥（passkey）流程，通过 Coinbase 开发者平台提供免费的 Gas 赞助，并提供了一个 SDK，将私钥的概念完全隐藏在邮件登录之后。Abstract 则更进一步，通过嵌入式钱包让体验感觉就像 Web2 应用。2025 年，这对消费级应用开发者的组合推销方案是：在 Base 上构建，你的用户不会知道他们在链上，你扩展规模时我们来付钱。

Kora 并没有逐字复制那个推销方案。它所做的是消除了 Solana dApp 无法写出相同方案的架构障碍。有了 Kora，Solana 团队现在可以提供：

• 通过 Privy、Turnkey 或 Coinbase 嵌入式钱包进行的邮件或通行密钥注册。
• 交易无需 SOL 余额。
• 以 USDC、BONK 或 dApp 自身代币（如果有）支付费用。
• 亚秒级最终确认性，路径中无需 Bundler。

这些拼图此前已经存在。Octane 是开源的先驱。Circle 的 Gas Station、Openfort、Portal、Gelato、Biconomy 以及其他六家供应商都提供了费用中继服务。Kora 改变的是 Solana 基金会现在亲自交付标准的、经过审计的、兼容 KMS 的参考实现。这为每一个之前在自己开发或付费使用供应商方案的团队，从决策树中移除了“我们该信任哪个第三方支付主合约”的难题。

Kora 之上的供应商层​

有趣的是，对于那些已经围绕 Kora 刚弥补的空白建立业务的嵌入式钱包供应商来说，情况会如何发展。

Privy（2025 年 6 月被 Stripe 收购）一直是寻求支持邮箱登录的 Solana dApp 的首选消费级应用钱包。虽然 Solana 在官方定位上是 Privy 的次要链（其深耕领域在 EVM），但其嵌入式钱包流程已扩展到 Solana，且 Privy 已经支持配置由应用管理的手续费支付者钱包（Fee Payer Wallet）。Kora 并没有取代 Privy；它为 Privy 提供了一个标准化的后端接入点，使开发者无需为每个客户运行自己的 Paymaster 服务。

Turnkey 是安全优先的嵌入式签名器，与 Kora 的远程签名 API 是天然的搭档。Turnkey 明确表示不包含 Paymaster 基础设施，因此以前那些希望同时拥有硬件隔离密钥和无 Gas 体验（Gasless UX）的 Solana 团队，不得不强行将两个供应商的产品拼接在一起。Kora 简化了这种集成。

Dynamic（2025 年被 Fireblocks 收购）为机构团队带来了多链认证方案。背靠 Fireblocks 的定位使 Dynamic 成为那些既需要 Solana 和 EVM 覆盖，又需要满足企业级合规要求的金融科技公司的自然选择。Kora 为 Dynamic 提供了一个简洁的 Solana 手续费抽象方案，无需 Fireblocks 亲自开发竞争性的 Paymaster 产品。

Coinbase 开发者平台（Coinbase Developer Platform）的情况则有些尴尬。Coinbase 投入了大量资源，通过 Coinbase 智能钱包（Coinbase Smart Wallet）、Base 免费 Gas 和嵌入式钱包 SDK，将 Base 打造成默认的消费级区块链。Kora 缩小了 Base 一直在推销的差异化优势，尤其是对于那些希望通过原生 USDC 流程（Solana 在此领域已具备规模优势）吸引用户的应用。

可能的结果是，对于每一个不想亲自运营 Paymaster 服务的嵌入式钱包供应商来说，Kora 将成为他们默认的 Solana 后端。供应商们在身份认证用户体验（Auth UX）、密钥管理和策略控制上进行竞争，而 Kora 在底层处理手续费中继。这比之前的状态更健康：以前每个消费级 Solana dApp 都要独立做供应商决策，并评估每个候选者自研中继器的安全性。

这解决了什么，又没解决什么​

Kora 彻底填补了一个空白，但仍保留了其他几个空白。有必要精确区分它们。

Kora 解决的问题：

• 对于任何愿意用另一种代币补贴手续费的 dApp 来说，消除了“用户必须持有 SOL”的用户体验断层。
• 为以前必须在运营负担和供应商锁定之间做出选择的团队，解决了“自研还是购买 Paymaster”的决策难题。
• 弥补了机构接受度方面的差距，因为审计和 KMS 支持让受监管实体可以运行 Kora 节点，而无需自建。

Kora 未能解决的问题：

• 钱包获取本身 —— 用户仍然需要从某个地方获取嵌入式钱包，无论是 Phantom、Privy、Turnkey 还是 Coinbase。
• 账户抽象原语，如批量调用（Batched Calls）和会话密钥（Session Keys），这些仍需通过 PDA 和其他程序级模式在 Solana 上单独构建。
• 谁来支付 Kora 运营商垫付的 SOL 的经济问题。对于有代币收入或稳定币现金流的 dApp 来说，这没问题；但对于免费产品，Gas 赞助仅仅是获客成本（CAC）。
• 跨链用户体验，这仍然需要用户与桥或链抽象层（如 LayerZero、Wormhole 或 Across）进行交互。

“无 Gas 基础设施作为协议原语”这一论点具有两面性。Solana 现在拥有主流公链中最简洁的原生手续费抽象方案。但也意味着竞争的焦点上移到了钱包用户体验、恢复流程和账户抽象功能，而 EVM 在这些领域已有数年的领先优势。

开发者的战略解读​

对于在 2026 年中期选择公链的团队来说，权衡逻辑已经发生了变化。十二个月前，消费级用户入驻的答案只能是 Base、Abstract 或新的 EVM 消费级链。当时 Solana 拥有开发者的关注度和基础设施势头，但却因“获取 SOL”这一步骤而流失了零售用户。现在情况已不再如此。

今天在 Solana 上启动的消费级 dApp，如果前端使用 Privy 或 Turnkey，后端使用 Kora，其功能上的用户体验面与 Base 上的等效堆栈几乎一致：邮箱登录、无 Gas 交易、USDC 支付手续费、亚秒级最终性。剩下的区别仅在于运行时模型、工具生态系统和可用流动性。对于一个渴望 Solana 高吞吐量和 DEX 深度的应用来说，选择 EVM 的用户体验理由已大幅削弱。

对于已经在 Base 上发布产品的团队来说，Kora 不会改变当下的决定。但它确实改变了长期的竞争压力。如果具备最简洁用户体验的消费级 dApp 开始在 Solana 上涌现，仅仅是因为新基础设施减少了一个集成烦恼，那么围绕 Base 消费级入驻门槛的引力就会开始倾斜。

诚实的评价是，Kora 是必要的，但还不够。它消除了开发者不选择 Solana 开发消费级应用的特定理由，但其本身并没创造出一个选择 Solana 的新理由。接下来的两个季度将揭示嵌入式钱包供应商是否真的会默认采用 Kora，新的消费级 dApp 是否会将其列为选链原因，以及现有的 EVM 消费级链是否会通过改进自己的基础设施方案来做出回击。

无论如何，“用户在交易前必须获取 SOL”终于成了一个历史遗留问题，而非现状。单凭这一点，就值得发布。

BlockEden.xyz 为构建消费级 dApp、支付通道和交易系统的团队提供生产级的 Solana RPC 基础设施。如果你正在集成无 Gas 流程或扩展 Solana 产品，请 探索我们的 API 市场，获取专为下一代消费级加密应用设计的低延迟节点。

参考资料​

• GitHub：solana-foundation/kora
• Kora — 不再因 “SOL 余额不足” 而流失用户
• 如何通过 Kora 在 Solana 上启用无 Gas 交易 — QuickNode
• Solana 基金会推出 Kora：实现零手续费交易及自定义费用代币 — Metaverse Post
• Kora 费用中继器助力 Solana 应用入门与费用管理 — Cryptonomist
• 费用赞助 — Solana Cookbook
• 什么是 Solana 上的 ERC-4337？ — Solana Developers
• 账户抽象：以太坊 vs Solana 详解 — Squads
• Circle 的 Gas Station 如何在 Solana 上利用费用支付者实现无 Gas 交易
• 在 Solana 上赞助交易 — Privy 文档
• 2026 年最适合开发者的 Solana 钱包 — Openfort
• Coinbase 智能钱包 — 钱包现状报告（第二部分）
• Anza 概述 2026 年 Solana 的关键发展趋势 — Phemex

想象一个用户可以无缝地与你的 dApp 交互，而无需持有任何原生代币（SUI）的世界。这已不再是遥不可及的梦想。借助 Sui 的 Gas Station（亦称 Paymaster），开发者可以代替用户支付 gas 费用，彻底消除新用户进入 Web3 的最大障碍之一，实现真正无摩擦的链上体验。

本文提供了将你的 dApp 升级为免 Gas 的完整指南。我们将深入探讨 Sui Paymaster 的核心概念、架构、实现模式以及最佳实践。

1. 背景与核心概念：什么是赞助交易？​

在区块链世界中，每笔交易都需要网络费用，即“gas”。对于习惯了 Web2 无缝体验的用户而言，这是一道显著的认知和操作障碍。Sui 在协议层面通过 赞助交易 来解决此挑战。

核心思路很简单：允许一方（赞助者）为另一方（用户）的交易支付 SUI gas 费用。这样，即使用户钱包中没有 SUI，也能成功发起链上操作。

Paymaster ≈ Gas Station​

在 Sui 生态系统中，赞助交易的逻辑通常由称为 Gas Station 或 Paymaster 的链下或链上服务处理。其主要职责包括：

1. 评估交易：接收用户的免 Gas 交易数据（GasLessTransactionData）。
2. 提供 Gas：锁定并分配交易所需的 gas 费用。通常通过由多个 SUI Coin 对象组成的 gas 池来管理。
3. 生成赞助者签名：在批准赞助后，Gas Station 使用其私钥（SponsorSig）对交易进行签名，表明其愿意支付费用。
4. 返回已签名交易：将包含 gas 数据和赞助者签名的 TransactionData 发送回去，等待用户的最终签名。

简而言之，Gas Station 就像为你的 dApp 用户提供加油服务，确保它们的“车辆”（交易）能够在 Sui 网络上顺畅运行。

2. 高层架构与交互流程​

典型的免 Gas 交易涉及用户、dApp 前端、Gas Station 和 Sui 全节点之间的协同。交互顺序如下：

流程拆解：

1. 用户 在 dApp UI 中执行操作，构造一个不含 gas 信息的交易数据包。
2. dApp 将该数据发送至指定的 Gas Station 请求赞助。
3. Gas Station 验证请求的有效性（例如检查用户是否符合赞助条件），随后为交易填充 Gas Coin 并签名，将半成品交易返回给 dApp。
4. 用户 在钱包中看到完整的交易详情（例如“购买一个 NFT”），并提供最终签名。这一步至关重要，确保用户对其操作保持同意和控制。
5. dApp 将包含用户和赞助者签名的完整交易广播至 Sui 全节点。
6. 交易在链上完成后，Gas Station 可通过监听链上事件或回执进行确认，然后通过 webhook 通知 dApp 后端，以完成业务流程的闭环。

3. 三种核心交互模型​

你可以根据业务需求单独或组合使用以下三种交互模型。

模型 1：用户发起 → 赞助者批准（最常见）​

这是标准模型，适用于绝大多数 dApp 内的交互。

1. 用户构建 GasLessTransactionData：用户在 dApp 中执行操作。
2. 赞助者添加 GasData 并签名：dApp 后端将交易发送至 Gas Station，后者批准交易、附加 Gas Coin 并添加签名。
3. 用户审阅并给出最终签名：用户在钱包中确认最终交易详情并签名。随后 dApp 将其提交至网络。

该模型在安全性与用户体验之间取得了极佳的平衡。

模型 2：赞助者发起的空投/激励​

该模型非常适用于空投、用户激励或批量资产分发。

1. 赞助者预填 TransactionData 并签名：赞助者（通常为项目团队）预先构建大部分交易（例如向特定地址空投 NFT），并附加赞助签名。
2. 用户的二次签名使其生效：用户只需对该“预批准”交易签名一次，即可执行。

这提供了极其流畅的用户体验。用户只需点击一次确认，即可领取奖励或完成任务，显著提升营销活动的转化率。

模型 3：通配符 GasData（信用额度模型）​

这是一种更灵活且基于权限的模型。

1. 赞助者转移 GasData 对象：赞助者首先创建一个或多个具有特定预算的 Gas Coin 对象，并直接将所有权转移给用户。
2. 用户在预算范围内自由消费：用户随后可以在预算上限和有效期内自由使用这些 Gas Coin 来支付其发起的任何交易。
3. Gas Coin 被归还：当 Gas Coin 用尽或过期后，可设计为自动销毁或返回给赞助者。

该模型相当于为用户提供一张限时、限额的“gas 费用信用卡”，适用于在游戏赛季期间提供免费试玩体验等需要高度用户自主性的场景。

4. 典型应用场景​

Sui Paymaster 的强大之处不仅在于解决 gas 费用问题，还在于它能够深度融合业务逻辑，创造新可能。

场景 1：付费墙​

许多内容平台或 dApp 服务要求用户满足特定条件（例如持有 VIP NFT、达到某会员等级）才能访问功能。Paymaster 可以完美实现此逻辑。

• 流程：用户请求操作 → dApp 后端验证用户资质（如 NFT 持有） → 若符合条件，则调用 Paymaster 为其赞助 gas 费用；若不符合，则直接拒绝签名请求。
• 优势：该模型天然抵御机器人和滥用行为。由于赞助决策在后端完成，恶意用户无法绕过资质检查而耗尽 gas 资金。

场景 2：一键结算​

在电商或游戏内购买场景中，简化支付流程至关重要。

• 流程：用户在结算页点击“立即购买”。dApp 构造包含业务逻辑的交易（例如 transfer_nft_to_user）。用户只需在钱包中签名批准业务交易，无需关心 gas，gas 费用由 dApp 的赞助者承担。
• 优势：可以将业务参数如 order_id 直接编码进 ProgrammableTransactionBlock，实现后端订单的精准链上归因。

场景 3：数据归因​

精准的数据追踪是业务优化的基础。

• 流程：构造交易时，将唯一标识（如 order_hash）写入交易参数或将在执行时触发的事件中。
• 优势：Gas Station 在收到成功交易的链上回执后，可通过解析事件或交易数据轻松提取该 order_hash，实现链上状态变化与后端订单或用户行为的精准映射。

5. 代码骨架（基于 Rust SDK）​

下面是一个简化的代码片段，演示核心交互步骤。

let tx_data = TransactionData::new_gasless(...);
let signed_tx = gas_station.evaluate_and_sign(tx_data)?;
let final_tx = user.sign(signed_tx)?;
submit(final_tx);

完整实现请参考官方 Sui 文档的 Gas Station 教程，其中提供了开箱即用的代码示例。

6. 风险与注意事项​

虽然 Sui Paymaster 带来了诸多好处，但仍需关注潜在的风险和考量。

安全风险​

如果 Gas Station 的私钥泄露，攻击者可能伪造签名并耗尽 gas 资金。

• 密钥管理：确保私钥存放在安全硬件模块中或采用多签方案。
• 交易验证：严格验证传入的交易请求，防止恶意负载。

经济考量​

开发者需要评估赞助 gas 费用的成本，尤其是在高交易量的场景中。

• 预算管理：保持充足的 gas 池并监控使用模式，避免意外耗尽。
• 定价模型：部分项目采用分层赞助（如免费额度后由用户自行支付），以平衡成本与用户体验。

7. 结论​

Sui Paymaster 是一项强大的工具，能够显著提升用户体验，降低 Web3 应用的准入门槛。通过掌握其核心概念、架构和交互模型，开发者可以将其无缝集成到 dApp 中，为用户提供真正免 Gas 的流畅体验。