アメンドメントプロセスを詳しく見る

XRPレジャーのプロトコルルールがどのように変更されうるか、そしてそのプロセスに組み込まれた安全策を詳しく解説します。

本ウィキの技術セクション全体で説明されているネイティブ機能 — AMM、NFT、エスクローなど — はすべて、同じ正式な仕組み、すなわちアメンドメントプロセスを通じてXRPレジャーに実装されました。このページでは、What Is the XRP Ledger?での簡単な言及よりも深く掘り下げます。

アメンドメントとは何か

アメンドメントとは、XRPレジャーのプロトコルルールに対する、提案された個別の変更です — (AMMやNFTのような)まったく新しい取引タイプの追加から、既存の動作のエッジケースの修正まで、あらゆるものが含まれます。アメンドメントは名前と一意のハッシュによって識別され、rippledのコードベースに事前に実装され、ソフトウェアリリースで配布されますが、ネットワーク自体がそれを投票で承認するまでは有効化されません。

なぜ有効化がコードの配布と分離されているのか

これは意図的な安全設計です。ソフトウェア開発者は、新しいアメンドメントのコードを十分に前もって書いて配布し、ノードやバリデーターの運営者にソフトウェアを更新する時間を与えることができますが、バリデーターが明示的に支持を表明するまで、新しいルールは実際のネットワーク上で発効しません。これにより、「コードが存在し利用可能である」ことと「ネットワークがそれを使用することに合意した」ことが分離され、単一のソフトウェアリリースが密かにコンセンサスルールを変更することを防いでいます。

投票の仕組み

あるアメンドメントをサポートするコードがデプロイされると、バリデーターは自らが生成に関わるレジャーに、そのアメンドメントへの「賛成」票を含めることができます。アメンドメントが有効化されるのは、次の条件が満たされたときのみです。

少なくとも**信頼されたバリデーターの80%**がそれに賛成票を投じており、かつ
その80%以上の支持レベルが2週間継続して維持されている。

2週間が経過する前のいずれかの時点で支持が閾値を下回った場合、カウントダウンはリセットされます。これにより、このプロセスは短期的・一時的な支持の急上昇に対して意図的に耐性を持ち、真に持続的なコンセンサスが要求されます。

これが何を防いでいるか

一方的な変更はできない。 バリデーターを運用し、広く使われているデフォルトUNLを公開しているRippleでさえ(詳細はUnique Node List and Validatorsを参照)、単独でアメンドメントを有効化することはできません — 信頼されたバリデーターの集合全体にわたる広範な合意が必要です。
密かな強制アップグレードはない。 提案された変更に同意しないノード運営者は、単にそれをサポートするソフトウェアへのアップグレードを行わないという選択ができ、ネットワークの十分な部分が彼らに同意する限り、その変更は有効化されません。
警告なしの偶発的な恒久的ミスはない。 2週間の持続的な超多数派要件により、取引所、ウォレット提供者、アプリケーション開発者を含むエコシステムは、変更が即座に切り替わるのではなく、発効前に実質的な事前通知を得られます。

ネットワークが合意しない場合はどうなるか

原理的には、多数派が望むアメンドメントを、意味のある少数派のバリデーターが支持することを拒否し、その不一致が解消不可能である場合、ネットワークは2つの互換性のないチェーンに分裂する可能性があります(「ハードフォーク」)。しかし実際には、XRPLのアメンドメントの歴史において、この種の対立的な分裂は発生しておらず、提案されたアメンドメントは一般に、広範な受け入れに向かって収束するか、コミュニティでの議論の後に見送られるかのいずれかとなっています(ある機能がバリデーターの投票に達するかなり前に行われる議論段階については、XLS: How New Features Get Proposedを参照)。

古いアメンドメントの廃止

アメンドメントは、機能が完全に置き換えられた後、「廃止」としてマークすることもできます。これにより、稼働中のネットワーク上ですでに有効化されている動作を妨げることなく、時間の経過とともにコードベースを整理できます。