不幸な道を設計する:BitVM2アーキテクチャの理解 パート3:正準状態はチェーンコンテキストを必要とする BitVM2のペグアウト証明は、証明される状態の良さにかかっています。 もしオペラが紛争中にパブリック入力を選択できれば、誤った/フォークされたL2履歴に対して有効な証明を生成し、それでも退出を試みることができます。暗号解析は正しいです。文脈が間違っている。 GOAT Networkの修正策は、ビットコインにアクティブシーケンサーセットをコミットすることで、どのL2履歴が正典かを固定することです。 仕組み(概念的): • L2は分散型シーケンサーネットワークを運用しており、シーケンサーの公開鍵(またはそれへのコミットメント)はビットコインにアンカーされています。 • シーケンサーセットの更新は、事前署名されたトランザクションフローを通じて実行され、更新は現在のセットの十分な閾値(例:2/3)で承認された場合にのみ有効です。 • 更新フローは次のラウンドのシーケンサーセットハッシュをビットコインにコミットします(検証を容易にするためのOP_RETURNコミットメントも含む)。 そして、ペグアウト検証時には、システムが「オペレーターの最新状態を信頼しない」ことがあります。これは演算子に以下を証明することを強制します: ・関連するシーケンサーセットの更新トランザクションは、最も長い有効なビットコインチェーン(チェーンコンテキスト)で確認されていること、 ・参照されるL2状態は、最も最近コミットされたシーケンサーセット(標準性)から導き出されていること、 ・資産の焼却はその標準的なL2状態に含まれます。 「ウォッチタワー」は、チャレンジで使われるビットコインチェーンのコンテキスト(最長チェーンのヘッダーや証拠)を提供・証明するために存在し、紛争が「最新」を運営者の選択ではなくビットコインの現実に結びつけることができるようにしています。 その結果、オペレーターはプライベートフォーク上の証明を使って安全に退出できません。なぜなら、証明はビットコインにアンカリングされたシーケンサーの履歴と整合していなければならないからです。 次回:任意のユーザー引き出し - ユーザーの「引き出したxBTC」フローとオペレーターの返金証明フローを分離します。