BASE Commerce Payments 协议的安全性分析

审计

安全审计

由 Spearbit 和 Coinbase 协议安全团队审计。

安全分析

协议保证

操作者约束

为了简化商家和付款人的许多复杂性，我们引入了协议“操作者”的概念。操作者的主要工作是促进付款在其生命周期中的转换。操作者提交链上交易以发起、完成或取消付款，承担这些交易的 gas 费用，并简化技术水平较低的终端用户的集成过程。如果操作者被信任保管或管理支付流动性，那么这个实体将成为攻击者的磁石，其妥协可能导致资金的灾难性损失。该协议的核心理念是最大限度地减少对任何单个方的信任，同时最大限度地为所有参与者提供保护性保证。

为了避免将中心化的信任或控制权置于操作者手中，协议本身严格定义了资金如何、在哪里以及何时可以转移。操作者负责触发协议内的状态转换，但协议约束了哪些状态转换是有效的，并强制要求付款人的资金只能在付款人已授权的付款上下文中转移。当付款人授权付款时，他们以加密方式签署完整的付款条款：确切的金额、收款人、费用结构、时间限制、资金授权，以及更重要的是，允许为付款促进状态更改的特定操作者。唯一付款条款的哈希数据以及付款人对该信息的签名，实现了协议的加密强制保证，使得操作者无法修改条款、将付款人的授权重用于不同的付款，或者为他们未授权的付款触发状态转换。在最坏的情况下，操作者可能会变得不活跃或审查付款，并且该协议包括一个有时间锁定的资金检索机制，即使在这种情况下也能保护付款人。

该协议在设计上是无需许可和不可变的；任何人都可以充当该协议的操作者。操作者可以是像 Shopify 这样的支付处理商、独立的服务提供商、付款人或商家自己，甚至是实现自定义业务逻辑的智能合约。每笔付款都以加密方式绑定到特定的操作者，并且该操作者对资金的控制受到协议保证的严格约束。

唯一付款

该协议通过 PaymentInfo 结构、链 ID 和计算哈希的合约地址的哈希来唯一标识付款，从而使付款在每个链和每个 AuthCaptureEscrow 实例中都是唯一的。此数据结构定义了允许促进付款状态转换的操作者、代币转账的条款（代币、付款人、收款人、金额）、费用约束、付款生命周期的各种到期时间戳，以及用于实现唯一性的额外熵源。任何给定的付款都只能被授权一次。此结构的加密哈希标识付款，并且是付款人在授权代币转账付款时签署内容的一部分。

基于时间的保护

时间是整个付款生命周期中的关键保护机制，可防止付款（和相关流动性）最终陷入停滞状态。该协议使用三个不同的基于时间的保护措施，在PaymentInfo结构中定义，当通过时，会改变付款的可能性。 付款的preApprovalExpiry是指付款不能再被授权的时间点。 这样可以防止过时的授权，并确保付款人不会无限期地承诺他们已签署的授权。 authorizationExpiry定义付款的授权期限到期的时间点，并且付款不再可捕获。 此时，任何授权资金都可通过付款人自己收回。 最后，refundExpiry定义了付款不能再在协议中退款的时间点，从而为该付款提供最终确定性。 基于时间的保护通过智能合约逻辑自动工作，并创建可预测的窗口，在这些窗口中可以执行不同的操作，从而防止任何一方无限期地陷入困境。

操作者 TokenStore 中的流动性分段

AuthCaptureEscrow 是一个单例，旨在供多个操作者使用。 这可能会导致大量托管流动性保存在一个蜜罐中。 虽然 AuthCaptureEscrow 已经过彻底审计，并且受到显式保护以防止重入，但始终存在未发现的错误的可能性。 这种可能出现的最坏情况是能够从托管合约中耗尽流动性，甚至更严重的是，耗尽由其他/所有操作者获得的流动性。

为了防范这种最坏情况，我们引入了每个操作者的 TokenStore 合约，这些合约充当每个唯一操作者的简单流动性金库。 给定操作者的托管资金没有存储在 AuthCaptureEscrow 中，而是存储在以从当前与协议交互的特定操作者确定性导出的地址部署的专用 TokenStore 合约中。 从 AuthCaptureEscrow 与这些 TokenStore 的所有交互点都由特定操作者的 TokenStore 地址的派生来调解，从而降低了跨操作者干扰持有流动性的可能性。 TokenStore 只能由 AuthCaptureEscrow 调用。

<div align="center"> <img src="diagrams/TokenStoreDiagram.png" alt="Operator TokenStore Diagram" width="80%"> <p><em>每个操作者的 TokenStore 持有流动性</em></p> </div>

风险与缓解措施

操作者妥协

该协议旨在限制在现有付款的操作者被恶意行为者攻破的情况下可能发生的损害范围。 操作者无法从协议中窃取资金。 恶意或不活跃的操作者可能会通过未能将其支付通过其生命周期或过早地取消付款来审查付款。 操作者还可能对费用的行为方式具有一些管辖权，具体取决于它们在原始PaymentInfo定义中的配置方式。 操作者可以应用高达PaymentInfo中指定的maxFeeBps的费用，并且如果在PaymentInfo中将feeReceiver设置为address(0)，则该值可以在调用时动态配置。 因此，在最坏的情况下，操作员可以将最大可配置的费用率抽取到他们选择的地址。

恶意代币收集器

（有关完整文档，请参阅代币收集器）

AuthCaptureEscrow 通过以下方式防止恶意或不合格的代币收集器：

• 衡量余额变化以确保收集器合规性
• 使用 Solady 的 ReentrancyGuard 保护所有公共函数免受重入攻击

用于为付款和退款提供流动性的 TokenCollector 的选择是不受约束的，传递给该合约的 calldata 也是如此。 这种类型的开放式外部调用应立即引起安全问题，因为这种模式通常是与重入相关的错误的来源。 AuthCaptureEscrow 通过多种方式保护恶意代币收集器。 托管合约在调用代币收集器后执行余额检查，以确保操作者的“TokenStore”已收到付款的预期资金。 重要的是，AuthCaptureEscrow 上的所有公共非查看函数都是 NonReentrant，从而防止代币收集器的重入攻击，这些攻击会试图混淆 AuthCaptureEscrow 在授权给定付款时的状态。 最后，如上所述，流动性是按操作员进行分段的，这种缓解措施本身足以防止已知的重入攻击，即使所有函数都没有通过重入保护显式保护。

代币收集器仍然被付款人授予了大量的信任。 在授权付款时，无论是使用基于签名的方法（如 ERC-3009 和 Permit2）还是直接 ERC-20 批准，付款人都将代币收集器授权为他们资金的支出者。 重要的是，付款人授权的任何收集器的实施方式都应确保资金只能用于该特定付款的目的。 例如，收集器应派生一个由付款信息唯一确定的 nonce，并且收集器应仅允许来自“AuthCaptureEscrow”的调用。 未能强制执行这些属性可能会允许代币收集器代表不同的付款或在付款之外转移付款人的资金。 请注意，这种风险类别存在于用户生成签名的所有情况中，并且并非此协议独有或可防御的。

由于拒绝列表导致的拒绝服务

某些代币（如 USDC）实施了拒绝列表，禁止将资金转移到或从被阻止的地址转移。 由于链上交易的原子性，如果涉及付款资金转移的任何交易失败，则付款生命周期中的该步骤将无法完成。 对于可能已经授权的付款来说，这尤其令人担忧，因为这会启动购买的履行，并且由于收件人或feeReceiver被阻止而无法在以后捕获。 对于给定的操作员来说，捕获费用可能被认为不如维护协议的活跃度和履行待处理付款重要，这使得被拒绝列入的feeReceiver成为无法履行付款的不可接受的原因。 我们探索了在核心协议中减轻此风险的设计选项，例如将失败的费用资金托管起来以供以后检索，但这种机制的复杂性对于此边缘情况的严重性来说是不合理的。

如果 PaymentInfo 中指定的 feeReceiver 为 address(0)，则 feeReceiver 可以是动态参数。 对于那些关心优先考虑付款的活跃度而不是因操作员妥协而损失费用的风险的操作员，在初始 PaymentInfo 中将 feeReceiver 的值设置为 address(0) 是一种减轻因拒绝列表而永久无法履行给定付款的风险的方法； 操作员可以简单地为 capture 调用提供一个替代的 feeReceiver（对于任何数量的必要尝试）。

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