ブロックブラウザが償還を確認しているのに、$BTC なぜまだ解放できない
Ethereum の取引はブロードキャストされ、パッケージ化（組み込み）され、receipt まで生成されており、redemption event も検索できます。ただし、それが証明しているのは、ある execution block にこの記録が含まれているという事実だけです。現在の公開テストネット上の TBV にとっては、そこからさらに、そのブロックが Ethereum によって最終的に採用された履歴に属することを示す必要があり、まだ BTC の解放には不十分です。
ユーザーが債務を完済して Vault を withdraw する場合、または清算プロセスによって Vault が後続の償還担当者へ引き渡される場合はいずれも redemption event を発火させます。オフチェーンの SP1 prover は、固定順序で証明を構築します。まず Beacon の finality が、beacon block がコンセンサス層で finalize 済みであることを確認。次に Execution の finality が、その finalized beacon block と、償還取引を含む execution block を接続します。最後に Receipt inclusion が、対象の redemption log がそのブロックの transaction receipt に存在することを確認します。Groth16 は最初の三層の証明だけを圧縮・集約してコンパクトな proof にしますが、ブロックに最終性を与えるわけではありません。
この層構造の変更により、私の判断はこう変わりました。私は「ブラウザが取引を見た」という事実を、クロスチェーン償還が成立した証拠だとはみなさず、同時に次の2点が証明できるかを確認します。— そのイベントが実際に含まれていること、そしてそれを運ぶ execution block も、finalized beacon chain に承認されていること。前者は「何が起きたか」に答え、後者は「それが Ethereum の最終状態として成立したか」に答えます。後者の層が欠けると、Bitcoin の Payout が、まだ安定していない外部履歴の上に組み立てられる可能性があります。
finality と inclusion の証明が完了した後で、claimer が圧縮 proof を Bitcoin 側の Claim、Assert、および challenge window に投入します。Ethereum の finality は、その外部イベントがどの最終履歴の区間に属するかを確認するものです。Bitcoin の challenge period は、Bitcoin 側に提出された proof が成立するかを検証します。これらは同じ「待機している区間」ではなく、互いに置き換えもできません。有効に覆されなかった proof のみが、Payout の実行へ進むのです。
境界も明確にしておきましょう。finalized な redemption event の証明は、その log が Ethereum の最終状態へ入ったことを示すだけで、上流のコントラクト、オラクル、または清算判断が経済的に正しいことを必ずしも意味しません。Ethereum のコンセンサスで深刻な障害が発生すれば、検証が停止したり誤りが起きたりすることもあります。@BabylonLabs_io が閾値を「最終履歴中のイベント」に置き、「ブラウザで見えるイベント」ではないのは、Bitcoin 解放後に外部チェーンで後続の変更が起きても、自動的に撤回されないからです。$ETH
$BABY
#baby
Ethereum の取引はブロードキャストされ、パッケージ化（組み込み）され、receipt まで生成されており、redemption event も検索できます。ただし、それが証明しているのは、ある execution block にこの記録が含まれているという事実だけです。現在の公開テストネット上の TBV にとっては、そこからさらに、そのブロックが Ethereum によって最終的に採用された履歴に属することを示す必要があり、まだ BTC の解放には不十分です。
ユーザーが債務を完済して Vault を withdraw する場合、または清算プロセスによって Vault が後続の償還担当者へ引き渡される場合はいずれも redemption event を発火させます。オフチェーンの SP1 prover は、固定順序で証明を構築します。まず Beacon の finality が、beacon block がコンセンサス層で finalize 済みであることを確認。次に Execution の finality が、その finalized beacon block と、償還取引を含む execution block を接続します。最後に Receipt inclusion が、対象の redemption log がそのブロックの transaction receipt に存在することを確認します。Groth16 は最初の三層の証明だけを圧縮・集約してコンパクトな proof にしますが、ブロックに最終性を与えるわけではありません。
この層構造の変更により、私の判断はこう変わりました。私は「ブラウザが取引を見た」という事実を、クロスチェーン償還が成立した証拠だとはみなさず、同時に次の2点が証明できるかを確認します。— そのイベントが実際に含まれていること、そしてそれを運ぶ execution block も、finalized beacon chain に承認されていること。前者は「何が起きたか」に答え、後者は「それが Ethereum の最終状態として成立したか」に答えます。後者の層が欠けると、Bitcoin の Payout が、まだ安定していない外部履歴の上に組み立てられる可能性があります。
finality と inclusion の証明が完了した後で、claimer が圧縮 proof を Bitcoin 側の Claim、Assert、および challenge window に投入します。Ethereum の finality は、その外部イベントがどの最終履歴の区間に属するかを確認するものです。Bitcoin の challenge period は、Bitcoin 側に提出された proof が成立するかを検証します。これらは同じ「待機している区間」ではなく、互いに置き換えもできません。有効に覆されなかった proof のみが、Payout の実行へ進むのです。
境界も明確にしておきましょう。finalized な redemption event の証明は、その log が Ethereum の最終状態へ入ったことを示すだけで、上流のコントラクト、オラクル、または清算判断が経済的に正しいことを必ずしも意味しません。Ethereum のコンセンサスで深刻な障害が発生すれば、検証が停止したり誤りが起きたりすることもあります。@BabylonLabs_io が閾値を「最終履歴中のイベント」に置き、「ブラウザで見えるイベント」ではないのは、Bitcoin 解放後に外部チェーンで後続の変更が起きても、自動的に撤回されないからです。$ETH
$BABY
#baby