ブリッジングとファイナリティ:序章

JumpCrypto和訳
by John
2022年12月19日

今後のシリーズでは、さまざまなチェーンが保証する「ファイナリティ」と、その保証を実現するブロック生成・コンセンサス・メカニズムについて掘り下げていきたいと思います。しかし、その前に、そもそも「ファイナリティ」とは何か、なぜそれがクロスチェーンプロトコルにとって特に重要な概念であるのか、批判的に考えてみる価値があります。

ファイナリティの重要性は、非中央集権的な分散システムの設計における基本的な問題から生じます。個々のエンティティはシステムの状態について異なる見解を持つことができ、基本的な正しい情報源を提供する機関は存在しません。その結果、自分の特定の見解が他の参加者と共有されていることを確認する迅速かつ容易な方法がありません。多くのブロックチェーンプロトコルでは、チェーンの状態を追跡しているうちに、ネットワークから受け取った新しい情報によって、以前の見解を修正することになり、その結果、ブロックが戻される可能性があります。プロトコルレベルでは、チェーンによって、ある時点以降にブロックが戻されないという保証を提供するために異なるアプローチをとっています。

抽象的に「ファイナリティ」について語るとき、私たちは通常、難しい技術的な仕様ではなく、合意を可能にする最終的な一貫性という、より一般的な性質を指しているのであって、実装の詳細は特定されていません。この単語が具体的な意味を持つのは、特定のプロトコルの仕組みと、それが生み出す保証の種類を調べるときだけです。にもかかわらずこの単語は、まったく異なる保証を持つプロトコルについて話すときに、しばしば同じように使われます。

カジュアルに話すときは、このように詳細を説明するのがよいかもしれません。一般ユーザが取引を行う場合、チェーンの基礎となるプロトコルの詳細や、それがどのようにセキュリティを提供しているかは必ずしも重要ではありません。一度行った取引が元に戻らないことを保証する何らかのメカニズムが存在する限り、それがどのように実現されるかの詳細は頭に浮かぶ必要はありません。しかし、クロスチェーンブリッジングでは、安全で堅牢、かつユーザーフレンドリーなプロトコルを設計する上で、ファイナリティの微妙な問題が自然に最前線に出てくる文脈になります。この微妙な問題を解明するために、まずビットコインを調べて、「ファイナリティ」という用語が意味する特定の一例を確認し、より広い議論に戻り、社会的合意に従うプロトコル内のプロパティとしてファイナリティが保証できることの基本的限界について推論します。この用語の一般的な理解に伴う様々な要因の概要を説明した後、これらの要因がブリッジ設計のための様々な検討事項（一部はセキュリティクリティカル、一部は実用的なUXに関連）をどのように引き起こすかを探ります。まずは、BitcoinのプロトコルとProof of Workの始まりから探ってみましょう。

基本に戻る

PoWについて復習する必要がなければ、遠慮なく次のセクションに進んでください。

Nakamotoプロトコル（すなわち最長チェーン型フォーク選択ルールとProof of Work）について話すとき、ファイナリティとは通常、最長チェーンであなたの取引を含むブロックの上に構築されるある固定数のブロックと理解され、その後あなたと受信者はそれが元に戻されないと確信することができるものです。例えば、取引所では通常、約4～6ブロックの確認後、ビットコインの入金を受け付けます。このような要件の動機付けを理解するために、極端な例を考えてみましょう。もし、ある取引をたった1回のブロック確認で、つまり、その取引を含むブロックがマイニングされるとすぐに受け入れたらどうでしょうか。もちろんこれは危険なことです。なぜなら、チェーンの先頭がオーファン/オマージュされる可能性があるからです（その方法は後述する）。しかし、直感を養うためにこの方法によってどのような問題が起こりうるか、そしてこのことがPoWプロトコルのファイナリティの概念にどのような影響を与えるかを正確に説明します。

まず、基礎固めをしましょう。ブロックの安全性について考えるとき、どのようなプロトコルであっても、ネットワークを観察している一人のクライアントの視点を持ち、あなたのローカルな視点が時間とともにどのように変化するかを推論することが有効です。他のネットワーク参加者からどのような情報を受け取れば、自分が見たブロックを元に戻せるでしょうか。それに関連して、ある高さでのチェーンの見え方が他の人と同じであると信じられるのはどのような条件下でしょうか。プロトコルに従うすべてのノードが、最終的には（少なくともある時点までは）それぞれのローカルな見解に同意するという保証があるからこそ、一貫した「ファイナリティ」状態、つまり唯一の正しいのブロックチェーンの状態を抽象化することに意義があります。

Proof of Workの話に戻り、最長のチェーンの先頭を追跡すると、我々の見解に何が起こるか見てみましょう。おもちゃのヒューリスティックでは、先頭で見た取引は確認することにしています。ある取引に興味があり、その取引を含むマイニング済みブロック（ブロックAと呼ぶ）を受け取り、さらに現在のチェーンの先頭を直接指すとします。ブロックAは前に見た最長のチェーンを延長しているので、我々のローカルビューでは最長のチェーンの新しい先頭になり、取引を受け入れることを選択します。

問題は、プロトコルが非同期的に実行されることです。マイナーは自分のチェーンの画像しか持っていないので、ブロックAが構築されたことを聞く前に別のマイナーが同じ高さのブロックBを構築し、ブロックBもネットワークを通じて伝播する可能性があります。AとBの両方を見た時点で、もはや明確な最長チェーンは存在せず、先頭が再確立されるにはタイが切れるのを待つ必要があります。

次に見たブロックがAではなくBを指していた場合、新しい最長連鎖にはもはやAは含まれず、我々の見解では事実上元に戻されたことを意味します。ビットコインのプロトコルは基本的に、直線的に進む有効ブロックのチェーンではなく、フォーク選択ルールによって区別されたツリーを中心に設計されているので、このブロックの再起動の現象は予想されることです。 より詳しく言うと、Bitcoin Coreのようなプロトコルのソフトウェア実装は、チェーンのローカルビューを管理するのが仕事ですが、適切な条件が満たされれば（つまり、今いるフォークよりも長いフォークが見つかった場合）、生成までの任意の長さのブロックシーケンスを戻します[1]。

もちろん、セキュリティの鍵は、Proof of Workが課す経済的パラダイムにあります。ブロック生成の仕組みにマテリアルコストが組み込まれているため、一般のマイナーは、自分のマイニングしたブロックが勝利したフォークに含まれる場合にのみ支出に対する報酬が得られるため、最も長いチェーンを構築するインセンティブが働きます。つまり、正直な参加者は最終的にチェーン履歴を統合的に見るようになり（ハッシュパワーの大部分を集団で所有しているという重要な仮定の下で）、そこで複数のブロック確認の必要性が生じます。

敵対的な観点からも、PoWは攻撃者が二重支出を目的とした大規模な再編成を行うことを抑制します。必要なフォークを行うには、チェーンの誠実なハッシュパワーを結集して対抗する必要があり、そのコストは再編成の深さに比例して大きくなります。ここで、このシステムのゲーム理論的な完全な考察には触れませんが、重要な考え方は、ビットコインのようなプロトコルによって提供されるブロックのファイナリティのタイプは、プロトコルとその周りに設計されたインセンティブの創発的特性であるということです。物理法則によって保証されているわけではなく、敵対的な環境においてインセンティブが十分に強固であるかどうかによって決まります。

つまり、プロトコルは（ネットワークの他の部分から受け取った情報に基づいて）あなたのローカルビューに存在する最長のチェーンを教えてくれますが、この結果を解釈し確認ルール（例えば、>N個の確認があるブロックを受け入れる）を適用して何を完全確認または「ファイナリティ」と判断するかはあなた次第です。それは、待ち時間と安全性(復帰の可能性)の統合的なトレードオフのポイントに過ぎず、ほとんどの実用的なユースケースにとって十分なものです[2]。

ファイナリティは本当にファイナリティなのか？

もし私たちがより一般的な「ファイナリティ」の定義を提示したいのであれば、それは必然的にかなり広範なものになり、この用語が異質な仮定とメカニズムの集合を抽象化する多くの作業を行うことを知っているので、塩漬けにしておく必要が出てきます。これまで議論してきたことを考えると、おそらく次のようなことが言えるでしょう：あるプロトコルのもとで確定したブロックとは、ネットワーク参加者の行動に関するある種の仮定（たとえば、ネットワークリソースのある割合が正直であるなど）のもと、そのプロトコルを順守する人の局所的見解において、決して元に戻されないか、ある無視できる確率で元に戻されるブロックのことです。

そのため、PoWのような経済的メカニズムがどのようにそれを保護するか、またそれが破られた場合にネットワークがどのように振る舞うかの両方を考慮する必要があります。この定義のもう一つの基本的な注意点は、プロトコルのルールの固定セットと、プロトコル内のコンセンサスによる決定とは別に、チェーンの進行に関してネットワーク参加者の間で継続的に合意がある場合にのみ意味を持つということです。

2010年（ビットコインの初期）、ある攻撃者がオーバーフローのバグを悪用し、入力値を超える取引出力を自分たちに信用させました。誰かがその取引に気づいた時には、すでに12ブロック以上深くなっており、自分のノードでチェーンを辿っている人は、単にプロトコルの出力を受け入れていれば、それが有効であると考えたでしょう。オーバーフローのバグ自体はクライアントコードの単純な更新で修正されましたが、マイナーが何もしなければ攻撃者のUTXOはその状態のままだったはずです。その代わり、フルノードのマイナーは攻撃トランザクションの上に構築されたブロックを文字通りローカルデータベースから削除し、そこからチェーンの再構築を開始しました。しかし、これはビットコインのセキュリティが損なわれたからではなく、チェーンを観察し、生成された状態の更新を手動で調べたコミュニティがこれらの更新はプロトコルの動作に合っていないと判断し、プロトコルの改訂版を実行する新しいチェーンに合意したためです。

攻撃者のトランザクションがファイナリティされたものであり、プロトコルの制限内で解決策を講じることが困難であったため、マージ前のイーサリアムにおけるDAOハッキングへの対応でも同様のパターンが展開されました。ハッキングが起こる前のブロックに戻すハードフォークが、最終的に問題を軽減することができる唯一の解決策となりました。その代わり、ネットワークの参加者は集団的かつ主観的に、いくつかの取引を無効とみなしました。たとえプロトコルを順守していたとしても、チェーンがどのように機能すべきかについて、より高いレベルの共有前提を破ったからです。

このシリーズの後半で紹介するもうひとつのプロトコルは、Tendermintです。このプロトコルには、「ハード」ファイナリティと呼ばれる、ブロックが元に戻らないことを保証する優れた特性があります（ある一定の前提が成立していることが前提です！）。CosmosはコンセンサスにTendermintを使用した最初のチェーンで、ハードフォークの復帰を見たことはありませんが、そのコミュニティもネットワークへの大きな攻撃に対応するための状態復帰型ハードフォークのオプションの重要性を認めています。

「Cosmos Hubの基盤となっている技術は、低摩擦のフォークとロールバックを可能にするために意図的に開発されました。私たちは、コミュニティがテストネットワーク上でこれらの技術を何度も実践しているのを見てきました。メインネットでも同様に使用する必要がありそうです。」 [ソース]

Tendermintチェーン（ハードファイナリティを与える）がロールバック（ファイナリティを戻す）を容易にするために設計されたという事実は、この2つのメカニズムが異なるレベルで動作することから、矛盾するものではありません。ファイナリティがどのような形であれ、プロトコル内のメカニズムであり、ロールバックはプロトコル外の、社会的に決定されるメカニズムです。Tendermintがどのように “ハード “ファイナリティを提供するか、そしてこの用語がより具体的に何を意味するかについては、別の記事で触れることにします。今のところ、この警告はナカモトプロトコルの特定の特性から生じるものではないことを改めて強調しておきたいと思います。むしろ、ハードフォークは基本的にプロトコル外の措置であるため、すべてのプロトコルに普遍的に適用されます。

ここで、ファイナリティがどのように構築されようとも、保証できることの限界に達しました。ブロック復帰を脅かすような攻撃やプロトコルのコンセンサスに関するローカルな矛盾に対する保護は提供しますが、正規の状態を決定する究極の要因である社会的コンセンサスについては何も保証しない（できない）のです。マイナーやバリデータはいつでもプロトコルの外に出て、状態やプロトコルのルールを修正した新しい別のチェーンを立ち上げ、リソースをそちらに切り替えることに合意できます。分散化の重要性の根本はここにあります。分散化は、単一の当事者がプロトコルや状態を恣意的に変更することを抑制し、チェーン自体の正当性を強化する（欠けている場合は弱める）役割を果たすからです。結局のところ、このプロセスは本質的に主観的なものですが、いったんハードフォークに移行するというコミットしたネットワーク参加者の集団的合意があれば、その新しいチェーンを正規のものとしてユーザーが受け入れる客観的理由が生まれます。なぜなら、そのチェーンのセキュリティを保証するリソースコミットメント（例えばハッシュパワーやステーク重量）を保持できるためです。

では、どうすればいいのでしょうか。核となる仮定に依存することに加え、ファイナリティはプロトコルのルールや状態に関する固定された社会的コンセンサスがある場合にのみ意味を持ちます。確定したブロックのより適切な定義は、ステート・リバーシング・ハードフォークによってのみ無効化されるブロックであり、これは主要なブロックチェーンの寿命の一部であることが分かっています。

一般ユーザーとしては、どのチェーンでもいったん取引が確定すれば、同じブロックやその前に大規模な攻撃がない限り、またネットワークが十分に分散化されている限り、その状態を維持できると確信することができます。しかし、最終的に確定した取引は、すぐに人生を賭けられません。なぜなら、社会的合意によって受け入れられた状態回復型のハードフォークが、以前の標準的なチェーンに取って代わる可能性があるためです。

All or Nothing？

コンセンサスモデルを深く考慮することは、ロールバックのような重要なケースを理解するためだけでなく（これについては次のセクションで説明します）、ブリッジの設計により多くの情報を提供するためにも重要です。大まかに言えば、ブリッジとはソースチェーンの状態に対する証明を生成するプロトコルであり、デスティネーションチェーンの実行環境において検証できます。直感的に、ブリッジが状態に対する証明を作成するのは、それが適切なレベルのブロック安全性を達成し、自信を持って標準的と見なせる（つまり、元に戻されない）ことが分かってからでなければ安全ではないため、ファイナリティの重要性はすぐに明らかになります。

このカジュアルな定義から、汎用ブリッジに不可欠な2つの主要部分を特定できます。そのうちの一つは、プロトコルの「バックエンド」と呼ばれるもので、接続するチェーンのそれぞれにフックし、コンセンサスの状態を検証するコアアーキテクチャです。「フロントエンド 」は、ブリッジがコンセンサスを処理した後に生成する、特定のチェーンの状態に対する消費可能な証明、そのフォーマット、チェーンについて伝える情報の種類、そしてその上に構築される高レベルの抽象化に関するものです。これにより、どんな使用例が可能か、開発者がクロスチェーンのアプリケーションにどのように統合するかが決まります。コンセンサスに関する一連の仮定は、これら2つの側面が存在し、絡み合うデザイン空間を生み出します。コンセンサスプロトコルは、ブロックの安全性の唯一の尺度は、ブロックがあるブーリアン条件に従って「確定」されたかどうかであり、ブリッジはその条件を満たしたときにのみ状態の一部を証明するチェーンを生成するという単純な仮定をすることです。

フロントエンド側では、ブリッジがトランザクションを確認するために保持しなければならない二項条件としてファイナリティを考えることは、素晴らしいメンタルモデルであり、確かにフレンドリーなインターフェイスになるでしょうが、普遍的な標準としてこれを採用するにはいくつかの明確な落とし穴があります。ビットコインで見たように、ファイナリティは実際には明確に規定された曖昧でない意味を持たず、遅延とリスクに対する好みによって個人が決定するものです。そのため、この前提で設計すると、その主観的な判断をコアプロトコルのどこかに埋め込む必要があり、下流のユーザーすべてに強制されます。

裏を返せば、チェーンによってはネイティブに提供されるブロックの安全性に関する有益な情報を、ユーザが二元的な分類から外れてしまうことを意味します。例えば、ビットコインの取引では、ブロック確認の回数を知ることは、「確定した」「していない」と言われるよりも厳密により表現的です。この文脈でファイナリティを定義する方法は、その値を縮小した範囲にマッピングする関数であるためです。なぜこのような情報が重要なのでしょうか。資産の移動をサポートするトークンブリッジは、取引を確認する前に非常に高いレベルのブロック安全性を必要とします。例えば、多くのブロック確認や完全なPBFTファイナリティのようなものです。一方、クロスチェーン電子メールのようなアプリケーションでは、取引が取り消されることに関連するコストはそれほど高くないかもしれません。そのため、1ブロック後に取引を確認したり、あるファイナリティ前の安全条件に従って取引の確認が安全になります。この概念は、ブリッジされるメッセージが価値の直接的な移転を意味しない他のケースにも適用できます。

この種の情報によって可能になるもう1つの興味深いアイデアは、ブリッジ取引を完了する意思のある第三者とユーザーをマッチングさせる仕組みを作ることです。トークン・ブリッジ自体は、最終段階に達するまでブリッジ資産を払い出すように設計されてはいけませんが、その上にプロトコルを構築し、引き出しをトークン化した負債として扱い、ユーザーが流動性プロバイダーに売却できるようにすれば、ユーザーから見れば早期引き出しのように見えます。この方法では、復帰リスクはLPが引き受け（ユーザーから支払われる手数料で補償される）、ブリッジ自体は追加の信頼前提を必要とせずに追加のリスクを引き受けます。

より一般的には、ファイナリティの一般化された概念（これは必然的にいくらか不安定な構造である）を唯一の指標として主張するよりも、より柔軟な原則は、取引の確認状態についてより詳細な情報を与えることを試み、その情報をどう解釈するか、そして復帰リスクとレイテンシーの間でどんなトレードオフを行うかを、実際にメッセージを使うプロトコル側に決定させることです 。ブロックの安全性より意味のある情報へのアクセスと、それに応じてよりニュアンスのあるモデルから生まれるアプリケーションデザインの新しい可能性は、各プロトコルにおける潜在的で恣意的なポイントを「ファイナリティ」としてラベル付けして終わりにするのではなく、この種のトレードオフを熟慮して検討する価値があることを意味します。

バックエンドに焦点を当てると、任意のコンセンサスモデルに接続できるインターフェイスを構築することは、すぐに明白な解決策にはなりません。Tendermintのコンセンサスは、投票と弱同期ラウンドに基づいており、ブロック生成のプロセス自体でビューの断片化を解決しています。イーサリアムのように、ビットコイン（LMD GHOST）のようなフォーク選択ルールとテンダーミント（Casper FFG）のようなラウンドベースのPBFT的メカニズムの両方を備えたハイブリッドモデルを採用しているプロトコルもあり、チェーンは非同期に進行しつつ、最終的には「ハード」ファイナリティに到達します。この例として、ニア（Doomslug/Nightshade）やポルカドット（BABE/GRANDPA）などもあります。

例えばOptimismロールアップでは、シーケンサの受信、L1ブロックのポスト（およびファイナリティ）、そして最終的には不正防止期間の経過によって安全性が徐々に強く保証されますが、zkロールアップでは、L1で実行証明が検証されてそこでファイナリティされると同時にブロックがファイナリティされます。SolanaのTowerBFT、AvalancheのSnowball、TuskやBullsharkのようなDAGベースのBFT構築はさらに不一致のモデルであり、その他にも理解し検討すべきファイナリティに対する独自のアプローチがあります。これらのモデルについては、後ほど詳しく説明します。今のところ、私たちの目的は、これらすべてをカバーする解決策を求める場合、対処しなければならない複雑さの幅を強調するだけです。

もう一つ考慮すべき点は、コンセンサスを追跡するために実際に計算を行う場所と、それをチェーン上でどのように検証するかです。この議論も後回しにしますが、バリデータ/マルチシグ、ライトクライアント、オプティミズムブリッジなどの様々なソリューションの検討につながります。今のところ、これらのコンセンサスモデルの異質性、したがって一方ではブロックの安全性の表現力豊かなモデルの必要性（多くの異なるチェーンを効果的に統合できるように）と、開発者がこれらの異なるモデルの深いドメイン知識を必要とせずにクロスチェーンのアプリケーションを構築できる、統一されていて近づきやすいAPIの要望の間に緊張関係があり、このトレードオフに沿って効果的に設計するには個々のチェーンのメカニズムを完全に把握する必要があることを認めたいと思うだけです。

ブリッジングのジレンマ

先程の章では、チェーンの状態はファイナリティが社会的合意に左右されることを説明ました。つまり、ある取引が本当に正統なものであるのは、ネットワーク参加者が集合的にそれが有効であると合意した場合のみで、プロトコル自体が出力するものではない、ということです。（ネットワークが十分に分散化されていれば）通常のブロックが最終的に任意に戻されることを心配する必要はありませんが、ロールバックは依然として、大規模な攻撃によってチェーンが危機に陥ったときにネットワークが取り得るバックポケットのオプションであることを念頭に置くことが重要です。

（ブリッジについて考えるとき）ロールバックの可能性は、難しいエッジケースを生み出します。なぜなら、ブリッジの明確に定義された概念は、本質的にソースチェーンの一貫した状態に依存しているからです。いったん取引が「ブリッジ」されると、つまりソースチェーン上の取引に対する証明が作成され、その証明を検証する取引が成功すると、元の取引がソースチェーン上のハードフォークによって戻されたかどうかにかかわらず、その成功した検証はデスティネーションチェーンに書き込まれて確定されます。

ソースチェーンの取引がハードフォークによって取り消された場合、デスティネーションチェーンはソースチェーンと矛盾したビューを保持することになります。ブリッジの認証とそれに伴う状態の変更は、ソースチェーンではなくデスティネーションチェーンのファイナリティの対象となるため、これを解決する簡単な方法はありません。Vitalik Buterin氏が二重消費を例に説明したように、コンセンサスレベルであっても、ネットワークの参加者が必要だと合意すれば、あらゆる種類の攻撃はロールバックによって修正できます。

上記の点は、ブリッジが提供できる保証の限界に関して認識することが重要です。また、これまで見てきたような本質的に限られたファイナリティの保証だけでなく、ブリッジのセキュリティはそのコア・プロトコルとスマート・コントラクトの実際の実装に大きく依存しており、スタックのどのレベルにおいても脆弱性がプロトコル全体に対する潜在的脅威となります。しかし、このことはブリッジを完全にあきらめたり、安全なブリッジが不可能であると断定したりする理由にはならないと、私たちは主張します。ブリッジが提供するクロスチェーンユーティリティの有望な可能性は、多くの関係者がすでにこれらの難しい問題に対応するソリューションを構築し設計していることを意味し、この分野が成長し続けるにつれ、潜在的に新しい構築者とともにそうし続けることでしょう。

つまり、ブリッジのある世界とブリッジのない世界では、未来は変わらないということです。ブリッジプロトコルは、様々なリスクを軽減する安全機構を開発することが目標です。時にはUXとトレードオフになりながら、主要な攻撃ベクトルに対処できる効果的なソリューションがあります。例えば、トークンブリッジは、ソースチェーンを保護するリソースの価値に比例して転送を制限できます。これにより、ブリッジによる二重消費攻撃の潜在的な影響が、事実上上限なしから、経済的伝染を脅かさない管理可能な値まで緩和されます。実装レベルのセキュリティについては、有意義なバグバウンティと外部監査（高品質でレッドチームマインドの開発者の実践とともに）が、本格的なプロトコルの基本的な必須事項となっています。

また、ブロックチェーンは単なる技術的なプロトコルではなく、社会的なコンセンサスへの主観的な依存を内在したプロトコルを実行する参加者のネットワークであることを述べてきました。ブリッジ自体は、そのコアとなる技術的なアーキテクチャだけでは存在できないため、潜在的な非決定性を処理するための分散型ガバナンスも不可欠な要素です。ブリッジは、より一般的なオンチェーンの構築と同様に、本質的にリスクの高いビジネスです。しかし、ブリッジを構築するチームが、綿密な対策によってあらゆる脅威に効果的に対処し、その挑戦に立ち向かうことが期待されます。

まとめ

この投稿では、分散型プロトコルがどのように最終的な一貫性を達成し、私たちが安全に取引を行うために依存する「ファイナリティ」を生み出すのか、その具体例を探るためにビットコインを取り上げました。その後、より一般的なファイナリティの説明に戻り、他のプロトコルがこの同じ高レベルの特性を達成するためにどのように異なる基本的なメカニズムを使用しているか、そしてこのことが一般的なブリッジングプロトコルが取り組むデザインスペースにどのように影響するかを議論するための舞台としました（セキュリティに関する短い余談を含む）。今後このシリーズでは、他のチェーンで使われているコンセンサスプロトコルと、それらを考慮するために私たちの一般的なファイナリティモデルをどのように調整すればよいかを探っていきますので、ご期待ください。

Ben Huan、Nihar Shah、Rahul Maganti、Chase Moran、そして他の方々のフィードバックに深く感謝します。

[1] Bitcoinで使用されている実際のフォーク選択ルールは、最高総難易度であり、これは、各ブロックが可変の重みを持つ最長チェーンルールをより洗練させたものに過ぎません。

[2] もう少し正式に言うと、攻撃者がある一定の割合のハッシュパワーを持つ二項過程としてブロック生成をモデル化すると、あるブロックの再起動の成功確率はチェーンが進むにつれて指数関数的に低下することを示すことができる。つまり、誠実なハッシュパワーがあれば、あるブロックに対する信頼度は100%にはなりませんが、確認が増えるにつれて漸近的に100%に近づくことができます。Proof of Workのセキュリティに対するより意味のある批判は、確率的に確実であることが十分でないということではなく、ベイズ的な考え方をすれば、確実性からの漸近的に小さな距離は、間違いなく確実性自体の良い定義です。

[3] もちろん、BTC/BCHやETH/ETCのようなケースのように、常にオール・オア・ナッシングで割り振られるわけではありません。その場合、2つのフォークは両方ともネットワークリソースのそれぞれのシェアで継続しますが、リソースの少数シェアしか持たないフォークは、セキュリティの低下に悩まされる可能性があります。

[4] 完全な粒度を提供することは、もちろん、あまりにも思い切ったことです。その時点で、ブリッジは実際にはあまり機能しなくなり、インテグレータはコンセンサスロジックを実装するためのすべての作業を行う必要があります。

原文：Bridging and Finality: An Introduction(https://jumpcrypto.com/bridging-and-finality-an-introduction/)

Scalablyメディアをフォローしましょう！

Scalablyのブログをフォローして世界のWeb3 VCやアクセラレーターの最新の発信をチェックしよう！

• Scalablyブログ: https://medium.com/scalably-community
• Website: https://scalably.com/
• Twitter: https://twitter.com/ScalablyInc
• LinkedIn: https://www.linkedin.com/company/scalably
• オープンチャット「Web3.0発掘コミュニティ｜プロダクトハンター」 https://line.me/ti/g2/EirJxjb_EpajyaNUilgFWvWrysudfHcgIZVd6Q?utm_source=invitation&utm_medium=link_copy&utm_campaign=default
• プロダクトハンターJapanイベント情報 https://www.meetup.com/ja-JP/web3tokyo/