3/5日目 ~ 開梱確認 ~ チェーンがファイナリティをどのようにモデル化し、アプリが確率論的に考える必要があるのか ~ 昨日は、「確認」がチェーンにどのように依存するかを探りました。今日は、これらのチェーンが実際にファイナリティをどのようにモデル化するか、そしてアプリが「確認済みと未確認済み」のバイナリビューを超える必要がある理由を解き明かしてみましょう ほとんどのチェーンは、明確な答えを 1 つも提供していません。代わりに、スペクトルを操作しています。 1. 決定論的なファイナリティ: BFT スタイルのコンセンサス (cosms、一部の alt-DA など)、L1 決済 (ファイナリティ後の ethereu など)、およびほとんどの PoS を使用するチェーンは、一度確定するとトランザクションを元に戻すことはできません。 2. 確率的ファイナリティ: PoW チェーン (ビットコインなど) とイーサリアムの「プレファイナリティ」は、統計的な保証を提供します。深さ12ブロックに埋もれたtxが再編成される可能性は低いですが、不可能ではありません。深くなればなるほど安全です。 3. ソフトシグナル: シーケンサーの確認、mempool の組み込み、ビルダー リレー - 高速ですが、リスクが伴います。これらの信号は便利ですが、慎重に扱う必要があります。 アプリでは、多くの場合、次のソースが同等に扱われます。 → 「X ブロックを待つ」 → 「シーケンサーを信頼する」 → 「包含のチェック」 しかし、相互運用性が移行するとすぐに、その抽象化は壊れます。 クロスチェーン アプリは、次のことにまたがる可能性があります。 ~ 高速ファイナリティBFTチェーン ~ 7日間の不正ウィンドウを備えた楽観的なロールアップ ~ 確率的ファイナリティを持つ L1 ~ シーケンサーのみの保証付きチェーン アプリロジックでは、画一的なルールをハードコーディングすることはできません。 「この tx が元に戻る可能性はどのくらいですか?そして、誰がそれを強制するのでしょうか?」 ==>ファイナリティはバイナリではなく、速度とセキュリティのトレードオフは線形ではありません。(たとえば、マルチシグはスピードや信頼を獲得しません。 →必要なのは、プログラム可能なチェーンを意識した信頼度==各コンテキストで「確認済み」が何を意味するかを表現する方法です