工程不幸之路：理解 BitVM2 架構 第三部分：標準狀態需要鏈上下文 BitVM2 的 peg-out 證明僅與其所證明的狀態一樣好。 如果操作員可以在爭議期間選擇公共輸入，他們可以在不正確/分叉的 L2 歷史上生成有效的證明，並仍然嘗試退出。加密學是正確的；上下文是錯誤的。 GOAT Network 的解決方案是通過在 Bitcoin 上提交活動排序器集來確定哪個 L2 歷史是標準的。 它的工作原理（概念上）： • L2 運行一個去中心化的排序器網絡，排序器的公鑰（或對它們的承諾）被固定在 Bitcoin 上。 • 排序器集的更新是通過預簽名的交易流程執行的，只有在當前集的足夠閾值（例如 2/3）批准的情況下，更新才是有效的。 • 更新流程在 Bitcoin 上提交下一輪的排序器集哈希（包括 OP_RETURN 承諾以便於驗證）。 然後，在 peg-out 驗證期間，系統不會“信任操作員的最新狀態”。它強迫操作員證明： • 相關的排序器集更新交易在最長有效的 Bitcoin 鏈上被確認（鏈上下文），並且 • 被引用的 L2 狀態是從最近提交的排序器集派生的（標準性），並且 • 資產燒毀包含在該標準的 L2 狀態中。 “監視塔”專門存在以提供和證明在挑戰中使用的 Bitcoin 鏈上下文（最長鏈標頭/證據），因此爭議可以將“最新”綁定到 Bitcoin 現實，而不是操作員的選擇。 最終效果：操作員不能安全地使用私有分叉的證明退出，因為該證明必須與固定在 Bitcoin 上的排序器集歷史一致。 接下來：任意用戶提款 - 將用戶的“提取 x BTC”流程與操作員的報銷證明流程分開。