如何在稳定币原生链上对支付流程进行威胁建模

随着稳定币在链上活动中的占比越来越大，支付正在成为链上系统的主要用例，而不仅仅是次要的。稳定币的总市值现已超过 3000 亿美元，同时支付公司正越来越多地探索稳定币结算、支付、卡和面向商家的基础设施。不过，更有趣的转变不仅仅是稳定币的使用频率增加，而是基础设施现在正围绕支付流程本身进行塑造。

在代币层面，稳定币支付很简单：价值从一个地址转移到另一个地址。但在实践中，支付产品通常需要围绕该转账提供更多信息。发送方可能不想持有单独的 Gas 资产。接收方可能需要备注、发票参考或账户标识符来对账支付。应用程序可能希望赞助费用、批量转账、安排支付、强制执行接收规则，或在不同的稳定币之间进行路由。机构可能还关心策略控制、隐私边界和确定性结算。

这就是稳定币支付优先的链成为一个有趣设计类别的原因。在 Tempo、Arc、Plasma 等较新的生态系统中，一个共同的设计方向开始显现：特定于支付的行为正在向基础设施层靠拢。截至 2026 年 7 月，Tempo 和 Plasma 已在主网上线，而 Arc 仍在公共测试网上。在已上线和计划中的设计中，稳定币计价的费用、赞助交易、支付元数据、转账策略、批处理、计划执行和自定义 Gas 代币机制可以成为支付路径的一部分，而不是每个应用程序都在转账周围重新构建这些功能。这些特性决定了应用程序对支付创建、执行、观察和结算的假设。

对于构建者、集成者和安全研究人员来说，这种转变改变了需要提出的问题。当 Gas 可以用稳定币支付时，费用资产就成为支付模型的一部分。当费用可以被赞助时，赞助者就成为执行路径的一部分。当转账携带元数据时，对账数据可能需要隐私和完整性保证。而当策略或其他特定于支付的基础设施靠近支付流程时，应用程序可能会开始依赖它们，而无需显式命名信任边界。

本文聚焦于这种转变：特定于支付的原语如何改变构建者、集成者和安全研究人员需要思考的假设。 威胁模型是从在此基础设施上构建支付流程的团队的角度编写的，包括智能合约、钱包、交易服务、索引器和支付后端。

从代币转账到支付保证

在最低层面，稳定币支付可能看起来仍然熟悉：一笔交易被包含、余额更新、事件被发出。但对于支付产品来说，“转账已执行”和“支付已成功”并不总是相同的陈述。商家可能只有在正确的资产到达、金额与发票匹配、备注可对账、转账通过了相关策略检查，以及交易达到了应用程序依赖的最终性阈值时，才认为支付完成。

这是支付优先的基础设施改变威胁模型的第一个地方。分析单元不再只是代币合约或转账函数，而是完整的支付路径。例如，Tempo 的支付模型将 TIP-20 转账、备注和可配置的转账策略与共识级别的支付通道相结合，而 Tempo 交易支持原子调用批处理、费用赞助和计划执行。Arc 使用 USDC 作为其原生 Gas 资产，并提供用于备注和保留原始 EOA 发送方的批量调用的交易扩展。Plasma 正在通过协议维护的 Paymaster 构建自定义 Gas 代币支持，以便应用程序可以从用户体验中抽象出 XPL，并允许用户用他们已持有的代币支付费用。

对于构建者来说，这意味着支付保证必须被显式定义。成功是由交易包含、代币接收、发票对账、策略批准、最终结算还是这些因素的某种组合来衡量的？如果一笔支付与其他操作捆绑在一起，一个操作的失败应该回滚整个流程，还是应用程序可以容忍部分完成？如果赞助费用路径不可用，是支付失败，还是仅该特定执行路径失败？如果备注缺失或无法被接收方的后端解码，是应该接受资金但保持未对账，还是应用程序应将支付视为不完整？

定义支付成功也澄清了威胁模型试图保护什么。 除了稳定币余额本身之外，相关资产可能包括移动或赞助资金的权限、支付引用和策略结果的完整性、执行和对账的可用性，以及敏感支付数据的机密性。如果这些属性中的任何一个丢失，链上转账可以成功执行，但仍然代表一个失败的支付流程。

支付流程中的参与者和信任边界

在定义了这些资产之后，下一步是识别谁可以影响它们。在简单的转账中，明显的参与者是发送方、接收方和代币合约。在支付优先的流程中，更多的组件可能变得重要。钱包或支付应用可能准备交易，赞助者可能覆盖费用，策略层可能决定转账是否被允许，代币发行者或管理员可能控制铸造、暂停或限制，索引器或后端可能负责将支付与发票或账户匹配。验证者可能确定顺序和最终性，而基础设施操作者可能影响交易提交、索引和对账。其中一些组件是智能合约，而其他则是钱包、后端、操作者或基础设施服务；对于支付产品来说，安全边界常常跨越这条线。

重要的一点是，并非每个与安全相关的参与者都需要直接控制用户资金。一些参与者影响支付是否可以被提交、包含、解释、接受或采取行动。不可用的赞助者可能破坏无 Gas 路径。策略更新可能改变转账是否被接受。备注解析器可能决定收到的资金是否与正确的发票匹配。

这在我们讨论的链中已经可见：支付路径可以包括费用逻辑、备注处理、策略检查、批处理、赞助或 Gas 抽象，以及应用程序自身的业务逻辑。对于构建者和审计者来说，这意味着安全审查应该覆盖完整的支付流程，而不仅仅是移动代币的合约。

做到这一点的一个实用方法是绘制支付路径，并标记每个可能阻塞、延迟、重新解释、重路由或最终确定支付的参与者或组件。然后标记每个价值、数据或权限跨越不同信任域的接口。这些接口就是信任边界。一旦它们可见，安全审查就可以将链上强制执行的属性与由钱包、后端、赞助者、操作者或策略系统处理的假设区分开来。

支付流程背后的五个安全假设

在映射了支付流程及其信任边界之后，下一步是确定系统所依赖的安全假设。这些假设将协议行为与暴露给用户、商家和支付后端的保证联系起来。将它们显式化将威胁模型转化为一组具体的属性，构建者、集成者和审计者可以验证这些属性。

假设一：有资金的支付需要有效的费用路径

拥有足够的稳定币来覆盖转账金额并不一定意味着交易可以被提交。Arc 使用 USDC 作为其原生 Gas 资产。Tempo 允许以美元计价的 TIP-20 代币用于支付费用。在执行之前，它会验证所选代币是否符合条件，费用支付者是否有足够的余额，以及当需要转换时，费用 AMM 是否有足够的流动性。Plasma 目前使用标准的 EVM Gas 模型，并将协议维护的自定义 Gas 代币支持记录为路线图功能。因此，集成假设在支付提交时存在一个被接受且资金充足的费用路径。费用路径失败应与支付资金不足、策略拒绝或交付失败区分开来。

假设二：赞助必须绑定到已批准的交易

赞助执行将发送方对交易调用的授权与费用支付者对覆盖其执行成本的授权分开。Tempo 通过单独的发送方和费用支付者签名使这一点变得明确。费用支付者的签名承诺了调用、发送方、费用代币、Gas 参数、nonce 和执行窗口，而一个单独的签名域防止该签名被重用为发送方的授权。对于集成，安全假设是赞助仍然限定于赞助者批准的确切交易和费用限制内。当交易提交时，赞助者的余额和签名必须保持有效，而后端应该在重试之前记录完全签名的交易是否已广播以及是否已执行。

假设三：支付上下文必须保持与价值转移的绑定

对账数据只有在能够与它所描述的资金流动绑定时才有用。Tempo 的带备注转账事件包括发送方、接收方、金额和备注。Arc 的备注扩展记录了原始 EOA 发送方、目标合约、转发调用的哈希、应用程序定义的标识符和备注数据。这些字段提供了将备注与相应调用对账所需的信息，而后端仍然需要验证导致的代币移动。一个熟悉的发票标识符本身并不是付款证明。对账处理也应该是幂等的，这样重新索引或重复引用就不能两次计入同一笔债务。在公共执行路径上，备注数据是在链上发出的，因此原始客户或业务信息应被视为公开信息。

假设四：集成必须考虑实时策略状态

有效的签名和足够的余额可能不足以让资金到达预期的接收方。在 Tempo 上，代币级别的策略失败会回滚转账，而接收者级别的策略阻止可以使调用成功，但将资金重定向到一个记录可恢复收据的守卫合约。Arc 同样记录了当黑名单限制生效时，原生 USDC 交易可能被拒绝或回滚，包括当黑名单状态在提交和执行之间发生变化时。因此，集成需要了解应用于资产和接收者的策略机制。仅交易状态可能不足：后端可能需要验证接收者余额、转账事件或阻止的支付收据。由于策略检查在执行时应用，计划、排队和重试的支付应根据当前的策略状态进行评估，而不是仅根据创建时的状态。

假设五：工作流完成必须与最终性分开定义

最终性确定记录的链上结果不会被重组；它并不决定该结果是否满足应用程序的支付工作流。Arc 提供确定性最终性，但其批处理扩展可以配置为在子调用失败时回滚整个批次，或者返回该失败由应用程序处理。Tempo 的原生批次是原子执行的，而计划交易只能在其定义的时间窗口内执行。因此，即使允许的子调用失败，Arc 交易也可以是最终的，而计划的 Tempo 交易可能在未执行的情况下过期。应用程序必须定义哪些操作是强制性的，哪些失败是可以接受的，以及哪个经过验证的链上结果授权链下效果，例如放行商品、计入账户或标记发票为已付。

应用威胁模型：构建者和审计者的检查清单

威胁模型只有在可以转化为对实现及其周围系统的检查时才有用。对于原生稳定币支付应用，这些检查应涵盖合约、钱包、交易服务、索引器和操作后端。

费用和赞助执行

• 记录集成启用的每个费用路径，包括接受的费用资产、所需余额、转换或流动性依赖关系，以及任何赞助者或中继依赖关系。
• 在 UI 和错误模型中将支付资金与执行资金分开。不支持的费用代币或不可用的赞助者不应表现为支付余额不足。
• 对于赞助交易，验证赞助者授权了哪些具体的调用、发送方、费用代币、Gas 限制、最大费用字段和执行窗口。
• 记录完全签名的交易是否已广播，并在重试前检查其链上状态。赞助者或中继的超时并不证明交易从未被提交。

交付、策略和对账

• 在计入发票或账户之前，验证成功的链上结果、预期的代币、接收者和金额，以及当流程需要特定发送者时的付款人。可识别的备注标识符是支持上下文，而不是付款证明。
• 使支付记账幂等，这样事件重处理、重复引用或后端重试就不能两次计入同一笔债务。
• 将公共执行路径上发出的备注数据视为公开数据，除非系统提供了文档化的机密性保证。
• 识别每个可以暂停、拒绝、阻止或重定向转账的代币或策略机制。如果协议可以在不贷记预期接收者的情况下完成调用，则不要仅依赖交易成功。
• 对于计划、排队或重试的支付，不要假设早期的策略检查仍然有效。交付应根据交易实际执行时强制执行的策略状态来解释。

完成和恢复

• 对于每个批次或多步骤支付，记录所选原语提供的执行语义。确定哪些操作必须成功，哪些失败可以容忍，以及一个操作的失败是否回滚整个流程。
• 定义在触发链下操作（如放行商品、计入账户或标记发票为已付）之前需要经过验证的链上结果。根据流程的不同，这可能包括交易最终性、成功执行的强制性子调用、预期的转账事件，以及确认资金已到达预期目的地。
• 将交易最终性、批次成功和支付完成视为独立的状态。
• 测试集成使用的失败模式，包括赞助者拒绝或不可用、计划交易过期、接收策略重定向，以及索引器事件丢失或重放。持久化交易标识符和处理状态，并使重试和恢复幂等，这样不确定性不会造成重复的贷记或重复的链下操作。

使支付保证显式化

原生稳定币链不仅仅是稳定币可以移动的地方。它们暴露了面向支付的原语，将费用处理、赞助、对账、策略执行、批处理和结算带到了交易流程附近。对于构建者和集成者来说，重要的问题不仅仅是这些原语是否按设计工作，而且是应用程序从中获得什么保证。

一个有用的威胁模型使这些保证变得精确。它识别必须保持保护的资产，围绕支付映射参与者和信任边界，记录集成所依赖的假设，并定义每种失败应如何处理。由此产生的支付流程应该回答具体的问题：交易何时可以提交，资金何时真正到达预期接收者，支付如何与其链下上下文匹配，以及哪个经过验证的结果允许更广泛的系统采取行动？

目标不是消除支付路径中的每个依赖关系。而是确保每个依赖关系是可见的，其失败语义被理解，并且应用程序从不承诺比底层系统所能提供的更强的支付保证。

如果你正在 Tempo、Arc、Plasma 或其他原生稳定币链上构建支付应用或集成，Certora 可以帮助审查和保护支付流程。这包括智能合约审计和链上组件的形式化验证，以及威胁建模连接交易逻辑、钱包、赞助者、索引器、策略系统和支付后端的假设。 联系我们 讨论架构审查、审计合作或长期安全支持。

• 原文链接： certora.com/blog/threat-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～