我可能是如何構建 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。 這顯然是一個更好的模型——通過將支付創新與初始鏈的選擇解耦來降低風險。 這是一種更好的模型，即使在考慮到 Paradigm 通過推出一個不誠實的理由的 alt L1 所激發的敵意和阻力係數之前。 哪個 Stripe 競爭對手最終會首先嘗試類似上述的事情？只是時間問題。