将MPP扩展到每秒数十亿次支付

上周，我们发布了 MPP Sessions，这是我们为 Agent 使用稳定币进行网络规模支付的解决方案。它消除了链上瓶颈，使得与交易对手进行大量支付成为可能。

你可以用预托管的美元金额开启一个会话，在该额度内进行任意数量的支付（可以通过链上充值补充），并在需要时关闭会话。这可能将每个 API 提供商的支付量扩展到数千甚至数百万次。

但这还不够。我们需要更快、更大，并让供应方尽可能高效地利用底层基础设施进行结算。因此，会话应该是无状态的、CPU 密集型的、可水平扩展的，并且链应该尽可能简化会话操作。

提升 MPP 性能的方法

我们如何实现这一目标？我认为答案在于以下几个组成部分。首先，你需要在不进行大规模重新架构的情况下，使现有设置更快：

现有设置的优化

1. 批量开启会话：将“1 笔交易 = 1 个链上会话”改为“1 笔交易 = N 个链下会话”。
2. 批量结算会话：将“1 笔交易 = 1 次结算”改为“1 笔交易 = N 次结算”。
3. 加快链下凭证验证：使凭证尽可能自包含，这样 API 无需进行外部请求。

采用 ED25519

对于第 2 和第 3 点，我认为将 MPP 迁移到 ED25519 将至关重要，因为它比 secp256k1 签名和验证更快，并且支持批量签名验证。这意味着我们将添加一个 ED25519 预编译。所有这些都非常棒，我们将把它添加到 MPP Solidity 合约中。如果有人在我们之前完成，那也很好。

优化会话成本与资本效率

所以，你希望确保你的链能够最大化每秒的会话开启和结算次数。这也能解决“我的资金被锁定在这里”的问题，因为如果结算/开启成本低廉，那么你可以轻松地将你的会话从一方“转移”到另一方，而无需担心资本效率。

单次会话的理想成本

如果我们将开启/关闭会话的成本降到最优，而其他一切都可以忽略不计，那么（每个会话）将是：

• 开启会话：1 次转账，仅为托管。
• 结算/关闭会话：最佳情况为 1 次资金分配，最差情况为 2 次转账（给接收方和找零给发送方）。

这些转账的所有存储槽预计都已分配（即没有首次支付者），这意味着我们应该能够将成本降至接近最优。

支付通道状态与过期 Nonces

那么每个会话的支付通道状态呢？我认为我们将重用 TIP-1009: Expiring Nonces 中的想法——鉴于通道会过期，我们不需要像对待普通存储那样定价。相反，我们可以分配一个缓冲区，其写入成本比普通状态更低。我普遍看好这种协议使某些类型的状态更便宜的想法，因为它知道如何清理它们。关于这一点，更多细节将在设计完成后公布。

预估 Gas 成本

这意味着什么？我们有可能将开启/关闭会话的成本降至每个会话约 10K Gas，这基本上与进行标准 TIP20/ERC20 转账一样便宜。

这意味着如果你要向交易对手进行两次以上的转账，那么开启一个会话总是划算的，我认为这在大多数情况下都适用。

请记住，链上节省的每一份 Gas 都能让你在链下做更多事情，因此收益会复合增长。

MPP 的未来展望：中心化支付通道网络

我们还能做些什么更疯狂的事情？MPP 是单向、单跳的。那么，那些想要重新分配功能的 AI 网关呢？理想情况下，我只有一个交易对手，但该交易对手可以像瀑布一样流向其他方。

关于这一点，有很多关于基于中心的支付通道网络的文献。我认为这将是扩展 MPP 的下一个前沿，超越我上面描述的想法。

更多资源

请尽快深入了解 MPP Sessions：https://mpp.dev/payment-methods/tempo/session。这是合约代码：https://github.com/tempoxyz/tempo/blob/main/tips/ref-impls/src/TempoStreamChannel.sol。

如果你对如何优化设计、智能合约或对支付通道文献有任何其他想法，请回复。

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