XRP Ledgerが5つの改正を廃止、ユーザーに影響なし

XRP Ledgerの開発者は、xrpldバージョン3.3.0で5つの長期間にわたって活動していたプロトコル改正を廃止しましたが、この動きはそれらの機能を削除したり、XRP保有者に行動を求めたりするものではありません。

Summary

• XRPL 3.3.0は5つの長期活動改正を廃止し、アクティベーション後の動作をコアプロトコル内で恒久的なものとしました。
• Clawbackは廃止後も利用可能で、xrpldソフトウェアからは古い改正前のコードのみが削除されます。
• XRPLのドキュメントでは、レガシーの複雑さを減らすために、Mainnetアクティベーション後2年で改正を廃止できるとしています。
• 6つの新しい改正がバージョン3.3.0に追加されましたが、各改正はMainnetアクティベーション前にバリデーターの承認が必要です。
• ノードオペレーターは迅速にバージョン3.3.0にアップグレードする必要がありますが、ユーザーは廃止に関連する行動を求められることはありません。

RippleXのソフトウェアエンジニアであるMayukha Vadariは、廃止がプロトコル変更が数年間運用された後に残された古い改正前のコードを削除することを説明しました。改正された動作自体はそのまま残ります。公式のXRPLドキュメントは、廃止された改正がコアプロトコルの無条件の部分になることを確認しています。

この区別は、8月6日にxrpld 3.3.0がリリースされた後に重要になりました。このリリースでは、Clawback、fixDisallowIncomingV1、fixInnerObjTemplate、fixNFTokenReserve、fixUniversalNumberが廃止されました。言い換えれば、「Clawbackを廃止する」ということは、XRP Ledgerの発行者がClawback機能を失うことを意味しません。ネットワークは、改正がアクティブになる前のトランザクションの動作を説明する古いコードパスを削除しているのです。

XRP Ledgerの廃止により古いルールが恒久化

XRP Ledgerの改正システムは、プロトコルの変更を導入することを可能にし、すぐにすべての新しいルールをMainnetに強制することはありません。バリデーターは改正に投票し、提案はアクティブになる前に2週間連続して80％以上の信頼できるバリデーターの支持を維持する必要があります。一度有効になると、新しい動作は、別の改正が後に変更しない限り、恒久的に適用されます。

アクティベーション後の期間中、xrpldは現在のロジックと一部の改正前のコードの両方を保持します。そのレガシーコードは、開発者が古い元帳の動作を再現するのに役立つことがありますが、何年も古いブランチを保持することは、コードベースに複雑さを追加します。

公式の改正ドキュメントによれば、Mainnetの改正は2年間有効になった後に廃止できます。廃止は古いコードパスを削除し、変更を条件付き改正として扱うのを停止し、新しい動作を無条件にプロトコルに組み込みます。

Vadariはこのプロセスを「純粋にコードベースのクリーンアップ」と表現し、「ユーザーには影響しない」と述べました。彼女は、開発者は一般的に2年間待つ理由は、以前の実装が古いトランザクションのデバッグに役立つ可能性があるからだと付け加えました。XRPLのテストドキュメントも、歴史的に正確なトランザクションの再生には、古い改正が廃止された後にトランザクションを最初に処理したxrpldバージョンを実行する必要があるかもしれないと警告しています。

ClawbackはXRPLから削除されていない

Clawbackは、5つの廃止された改正の中で最も認知度が高く、誤解されやすい機能です。この機能は2024年2月8日にMainnetでアクティブになり、適格な発行者が必要なClawback設定を有効にした場合に、保有者から発行されたトークンを回収できるようにします。ただし、発行者がネイティブXRPを回収することはできません。

したがって、改正を廃止することは、ネットワークがClawbackが存在しなかったXRPLのバージョンのためのコードをもはや必要としないことを意味します。現在のClawbackの動作はプロトコルの一部として残ります。XRPLの既知の改正ページは、改正前の機能を廃止されたものとして明示的にマークしています。

他の4つの退職も同じ原則に従っています。fixDisallowIncomingV1は信頼ラインの承認問題を修正しました。fixInnerObjTemplateは内部AMMオブジェクトに関するエラーに対処しました。fixNFTokenReserveはNFTオファーが受け入れられる際にリザーブチェックを追加し、fixUniversalNumberはXRPLの小数浮動小数点計算の一部を統一しました。古いパスが削除されているにもかかわらず、彼らの改正後のルールは依然として有効です。

これは新しいガバナンスメカニズムではありません。XRPLは、ルールが十分に確立された後に以前の改正を退職させてきました。たとえば、バージョン3.2.0は、チェック、入金承認、アカウント削除、その他のプロトコル機能に関する古い変更を退職させました。

バージョン3.3.0は新しい改正サイクルを開始します

5つの古い改正が条件付きステータスを離れる一方で、バージョン3.3.0はxrpldに6つの新しい提案を追加します。それらはBatchV1_1、ConfidentialTransfer、DynamicMPT、PermissionDelegationV1_1、Sponsor、fixCleanup3_3_0です。これらがソフトウェアに含まれているからといって、これらの機能がすでにMainnetでアクティブであることを意味するわけではありません。

各提案は、XRPLのバリデータプロセスを独立してクリアする必要があります。改正が有効になる前に、80%以上の支持が2週間持続する必要があり、支持が閾値を下回るとタイマーがリセットされる可能性があります。

したがって、これらの新しい改正と退職した5つの改正との違いは大きいです。新しい提案はネットワークの承認を待っています。退職した改正は数年前にその段階を通過し、確立されたネットワークの動作となり、現在では古いコードを維持する必要がないと見なされています。

XRPLオペレーターにとって次に何が起こるか

通常のXRP保有者にとって、5つの改正が退職したために特に移行、ウォレットの更新、または取引は必要ありません。Clawbackやその他の影響を受けたプロトコルの動作は、確立されたルールの下で引き続き運用されます。

サーバーオペレーターには異なる考慮事項があります。XRPL 3.3.0のリリース通知は、サービスの継続性を維持するために、できるだけ早くバージョン3.3.0にアップグレードするようオペレーターに指示しています。最新の状態を維持することも重要です。なぜなら、サーバーは後にアクティブになる可能性のある改正のコードを含むソフトウェアが必要だからです。アクティブな改正がないサーバーは改正ブロックされ、ネットワークに通常参加できなくなる可能性があります。

注意は、退職した改正からバージョン3.3.0の6つの追加に関するバリデータの決定に移ります。以前に報告されたように、ConfidentialTransferは、機関のトークン化された資産のためのXRPLのツールを拡張することを目的とした提案の1つですが、その使用は依然としてバリデータの承認に依存しています。

しかし、退職した5つの改正については、同等の投票はありません。退職は彼らの移行期間の終わりを示すものであり、機能の終わりではありません：改正されたルールは現在、XRP Ledgerの恒久的なコア動作の一部となっています。