我可能是如何构建 tempo 作为一个 L2 的 将 tempo 分成多个组件： - 一个 zk validium OP stack L2。这避免了通过将交易数据保留在链外来解决 blob 激增定价的问题。 - 一个 tempo 应用层 SDK，以体现他们想要的所有支付自定义功能，例如内置备忘录和使用任何稳定币支付 gas。这是 Stripe 进入该堆栈的切入点。 - tempo enshrinement SDK，这是他们期望在任何 "tempo chain" 上存在的一组标准/"TempoERC" 合约。 - 在 tempo SDK 中自动使用多个 L2，尤其是基于 tempo L2 validium 和像 Mega 和 Rise 这样的超规模 L2 的分形 L3 扩展。 - 使用绑定的 L2 预确认以实现快速最终性，这绝对足够好；不要让他们告诉你 alt L1 的 "最终性" 更好，因为实际上没有什么能阻止他们重写 alt L1 的历史。 绑定的预确认非常有前景且尚未被充分探索（Arb 开创了这一领域）： 例如，你向 tempo 支持的 L2 提交一个支付交易，在 200 毫秒内，他们给你一个有界的可证明的最终性保证，否则他们会支付你 1000 万美元。 这些类型的预确认债券可以在 Tempo 支持的第三方链上工作，Tempo 不运行排序器，例如 Mega 或 Rise。 预确认还可以提供分层结构的最终性保证，例如 "在接下来的 N 个 L2 块内包含，以及在接下来的 M 个 L1 块内，除非 L1 gas 激增超过 Z gwei，在这种情况下，L1 最终性将在接下来的 100*M 块内得到保证"。所有这些都可以在未满足保证时自动支付。 支付的快速通道可以采取专门为某些客户或价格点设计的分形 L3，或在核心 tempo L2 中提供更强/更快的最终性保证的快速通道。 Tempo 是一个令人兴奋的项目，由两个组织（Stripe 和 Paradigm）运营，他们正是那些准备进行上述前沿架构的严肃技术参与者。 IMO，他们应该从一个提供立即不足的 TPS 的 L2 开始，并利用上述模式迅速发展。 讽刺的是，Patrick 说用户/支付客户不应该关心他们使用哪个链，而他们决定推出自己的唯一真实链，而出色的多 L2/L3 架构随时可用——不仅使用 tempo 自己的 L2/L3，还包括优秀的第三方超规模 L2。 ...