XRPLの既知の修正一覧ページには、5月27日にfixCleanup3_1__3が有効化されると記載されており、このイベントは設計上メンテナンスアップグレードです。
rippledバージョン3.1.3には、NFT、許可されたドメイン、バウト、およびレンディングプロトコルの修正が含まれており、XRPLブログはこれらの修正の重要性からデフォルトの投票を「はい」に設定しました。
修正プロセスには、新しいルールが恒久的に適用される前に、信頼できるバリデーターの80%以上の支持が2週間継続される必要があります。
締切を超えてこのエピソードを検討する価値があるのは、XRPLの共同作成者David Schwartzが、本物のフォークに実際に何が必要かについて語った点です。彼の回答は、あらゆるブロックチェーンにおけるプロトコルの正当性がどのように機能するかを明らかにしています。
シュワルツの主張の核心は、ノード数の単純なカウントが合意力の不適切な代用指標であるということである。ノードがその数に比例して投票するシステムでは、誰でも低コストで数千台のマシンを起動できるという攻撃面が生じる。
XRPLモデルでは、各サーバー運営者が、コラボレーションしないことを信頼するバリデーターの選別されたセットであるユニークノードリスト(UNL)を維持し、UNLはコンセンサス中にサーバーがカウントするバリデーション投票を決定します。

サーバーはネットワーク全体の多くのノードから検証メッセージを受け取り、そのUNL上のバリデーターが、これらのメッセージのうちどれがサーバーの台帳に対する見方を形成するかを決定します。
シュワルツは、XRPL上の合意の正当性が信頼リストとバリデーターの調整を通じて実現され、UNLの整合性と経済的採用が分割時にどの台帳が生き残るかを決定するシステムを生み出していると説明した。
本物のフォークには完全な調整キャンペーンが必要な理由
5月27日のXRPL投票において、改定ブロックされたサーバーは、レジャーアクセスの妥当性を決定したり、トランザクションを送信または処理したり、コンセンサスに参加したり、今後の改定に投票したりできなくなります。
これにより、pre-3.1.3 ソフトウェアをまだ使用しているすべての取引所、ウォレット、エクスプローラー、またはインフラ運用者は、運用上重要な締切に直面します。これらのサーバーは、運用者がアップデートするまで、正規の台帳の参加者ではなくなります。
改訂がブロックされたインフラは、アップグレードされたチェーンへのアクセスを失い、機能的な対抗チェーンを確立するための調整インフラも欠いています。
信頼できるフォークを生み出すには、古いルールに従って台帳の生成を継続する検証者が必要であり、検証者がいないと、追跡可能な台帳のストリームは存在しません。
それらは、信頼できるバリデーターリストがなければノードが旧ルールに対して調整する手段を持たないため、サーバーが設定可能またはソフトウェアがデフォルトで使用できる競合するユニークノードリストを必要とします。
さらに、彼らは古いルールを維持し、デフォルトで競合するUNLを指すように設定されたコード配布が必要であり、ウォレット、取引所、エクスプローラー、およびアプリから、古いルールの台帳にアクセス可能で取引可能にするためのインフラサポートが必要です。

XRPLのドキュメントは、最悪の場合、フォークを防ぐために競合するUNL間に90%の重複が必要であることを示す研究を引用しており、つまり、競合するUNLは内部の一貫性を維持するために、標準的なUNLとほぼすべての信頼されたバリデーターセットを共有する必要があることを意味します。
劇的に異なるバリデータセットを中心に形成されるフォークは、自らのコンセンサスを維持できないだけでなく、市場の採用を引き付けることも困難になります。
修正プロセスが実際に追跡するのはバリデーターの支持であり、2週間で80%の閾値は、ネットワークが信頼するエージェントが新しいルールを永続化する前に安定した合意に達したことを保証します。
アップグレードされていない非バリデーターノードの大部分は、カノニカルな台帳の進行状況について何ら示唆するものではなく、インフラの遅れを反映する可能性があります。
インフラの遅れと競合チェーンとの距離
ベアケースでは、5月27日のアクティベーションに遅れた取引所、ウォレット、またはインフラ運営者は改定ブロックされ、台帳参加者としての機能を停止します。
これらのプロバイダーを経由するユーザーは、トランザクションが送信できない、エクスプローラーが帳簿の有効性を確認できない、アプリが支払いを処理できないなどのサービス障害に遭遇します。
その運用コストはアップグレードを後回しにしたオペレーターが負担し、アクティベーション時に3.1.3以前のノードを引き続き使用している主要な取引所またはキューディアンについては、特に追跡する価値があります。
十分な数のプロバイダーで継続的なインフラ遅延が発生すると、規則が変更された後も正規の台帳は継続されますが、ユーザーに実際の摩擦をもたらします。
牛市シナリオでは、fixCleanup3_1_3がバリデータのスーパーマジョリティが維持された状態でスケジュール通りに活性化し、インフラ運用者が大きな問題なく更新を行い、このエピソードは通常の改定活性化となる。
NFT、許可されたドメイン、バウト、およびレンディングプロトコルへの修正が適用され、ネットワークは進みます。ガバナンスの議論は、アップグレードによって浮上しましたが、シュワルツが本物の分岐に必要な条件を説明した内容は、今後のすべての改訂に適用されるため、どの結果にも残ります。
古いルールを維持するには、古いソフトウェアを実行する反対グループが、競合するUNLを中心にバリデーターを募り、ウォレット、取引所、および市場メイカーに、他のすべての人がアップグレードされたチェーンを指し示すデフォルト設定に対して、彼らの台帳を正統なXRP Ledgerとして認識させることが必要です。
すべてのブロックチェーンにはガバナンス層があります
シュワルツは、Stellar Coreの状態アーカイブバグに対する安定性修正であるStellarのProtocol 24アップグレードと比較し、これは同じ種類の調整されたバリデーターの採用を必要とするメンテナンスイベントであった。
Bitcoinの同等の正当性層は、マイナー、経済的ノード、クライアント実装、および取引所上場を通じて機能します。Ethereumの正当性層は、バリデーター、ステーキングインフラ、クライアントの多様性、コア開発者、およびアプリ層の採用を通じて機能します。
XRPLがUNLを通じて明示しているものは、他のネットワークではマイニングパワーの分布やステーキング経済、またはクライアントソフトウェア開発者が信頼する社会的コンセンサスに組み込まれている。
Bitcoin、Ethereum、XRPLではメカニズムが異なりますが、ルール変更を恒久的に実施するためには人間の協調した意思決定に依存するという点はすべてに共通しています。

5月27日のアクティベーションは、XRPLのガバナンスレイヤーがバリデータの合意を台帳の永続性に変換する方法を示しており、UNL設定がどの合意を有効とするかを決定します。
fixCleanup3_1_3に不同意なオペレーターは、古いソフトウェアを実行し、競合するUNLを設定する技術的自由を持っています。
どの取引所が生成されたトークンを上場しているか、どのウォレットがそれをサポートしているか、またはどのマーカーが流動性を提供しているかは、プロトコルがそれらのために答えられません。
その調整の不一致が、広く採用されているネットワークでのプロトコルアップグレードが持続的なフォークをめったに生まない理由です。カノニカルチェーンに従う経済的利点は、ほぼ常に新しい並列チェーンをゼロから構築する経済的利点を上回り、カノニカルチェーンとは市場が現実であると判断するチェーンです。
投稿 XRPLの5月27日のアップグレードは、バリデーターと市場がブロックチェーンの分岐をどのように決定するかを示しているは、CryptoSlateで最初に公開されました。

