XRP LedgerのBatchアップグレードが.validator票を回復:10月9日の有効化が依然として条件付きである理由
重要ポイント
- •BatchV1_1は9月26日時点で35の信頼済みバリデータのうち30票を回復し、XRP Ledgerで新たな2週間の承認期間を開始した。
- •XRPLの修正案には80%を超えるバリデータの支持、すなわち35票中最低29票が必要で、現在の票数はその要件を1票上回っている。
- •9月25日の一時的な過半数喪失により承認カウントがリセットされ、最速の条件付き有効化予想日は10月9日頃となった。
- •BatchV1_1は、研究者が認可の欠陥を発見したためMainnet有効化前に撤回された以前のBatch修正案の修正版であり、ユーザー資金への影響はなかった。
- •有効化はレジャーに記録されるEnableAmendment擬似トランザクションによってのみ確認でき、ダッシュボードの票数だけでは確定しない。

XRPL Dashboardが9月26日04:43 UTCに確認したところ、追跡対象の35の信頼済みバリデータのうち30が賛成票を投じていました。この票数はBatchV1_1修正案の新しい承認期間の開始を意味しますが、それ自体で有効化プロセスが完了するわけではありません。
主なポイント:
- BatchV1_1が35票中30票のバリデータ票を回復。
- 以前の2週間の承認カウントがリセット。
- 今後は最低29票を維持する必要がある。
- 10月9日は最速の条件付き日付。
- アップグレードの確定はオンチェーンでの有効化による。
票数は回復したものの、日付はリセット
BatchV1_1は9月15日に30の支援バリデータに到達しました。当初のスケジュールでは、有効化は9月29日頃と見込まれていました。その後、過半数は9月25日に失われ、同日の遅くに再形成されたため、予想は約10日後にずれました。
ダッシュボードは、以前の過半数が失われ、新しい過半数が記録されたフラグレジャーを特定します。なぜ一時的な変動が起きたのか、あるいは個々のバリデータの判断理由を開示するものではありません。確認できた事実はリセットそのものです。修正案が承認されるには、票数が後で同じ水準に戻ったとしても、全期間を通じて途切れない支持が必要です。
そのため、10月9日はレジャーの現在の過半数記録から導かれた条件付きの予想日です。有効化前に再びずれる可能性があります。
賛成30票は必要ラインを1票上回る
XRPLの基準はしばしば「80%の支持」と略されますが、ルールはより厳格です。修正案は信頼済みバリデータの80%を超える支持を必要とします。ダッシュボードの監視対象にある35のバリデータでは、28票がちょうど80%に相当します。BatchV1_1が過半数を開始・維持するには29票の賛成が必要です。
現在の30票は約857%に相当し、29票の要件を1票上回っています。30票から29票への低下ではカウントダウンは維持されますが、28票になると該当するフラグレジャーで再度リセットが発生します。
XRPLの修正案プロセスはフラグレジャーを中心に票を確認し、通常は約15分ごとに行われます。これらのフラグレジャーは支持を測定する定期的なチェックポイントとして機能し、2週間のカウントは票数が基準を上回り続けている間のみ進行します。修正案が2週間にわたり80%を超える支持を維持すると、変更は以降のレジャーバージョンに恒久的に適用されます。
サーバーコードとMainnetルールは別の段階
Coindooは以前、BatchV1_1が関連する支払い指示を連携させる仕組みを説明しました。今回のリセットで問題となっているのはその機能ではありません。現在の課題は、修正版の修正案が、それらのトランザクションルールをMainnetで有効にするために必要なバリデータプロセスを完了できるかどうかです。
サーバーソフトウェアに実装されることで、修正案はバリデータ投票の対象となりますが、Mainnetの挙動はネットワークが有効化した後にのみ変化します。この分離があるため、ダッシュボード上の日付は製品リリースの発表ではなく、ガバナンスの進捗の最新の予想として読むべきです。
以前のセキュリティ上の撤回が今重要な理由
BatchV1_1は、研究者が認可の欠陥を発見したためMainnet有効化前に撤回された、以前のBatch修正案の修正版です。元のバージョンは有効化されなかったため、この問題でMainnetのユーザー資金が危険にさらされることはありませんでした。
XRPLの脆弱性開示によると、修正版では署名および認可チェックに変更が加えられ、投票に戻る前に追加の審査を受けました。この一件は、プロセスが意図どおりに機能することを示しています。サーバーソフトウェアに実装されたコードでも、Mainnetのルールが変わる前であれば止めることができます。新たな14日間の期間が、修正版実装に対する現在のガバナンスの試練となっています。
注目すべき確認はレジャー上で
10月9日が意味を持つのは、過半数が全期間を通じて維持された場合のみです。確認は、レジャーに記録されるEnableAmendment擬似トランザクションによってもたらされ、その後BatchV1_1は以降のレジャーに対する有効なMainnetルールとなります。
そのイベントが現れるまでには、関連する情報はバリデータ過半数の継続性です。ダッシュボードは現在のカウントダウンを把握するのに有用ですが、修正版のBatch修正案が実際にライブのXRPLインフラの段階に達したかどうかは、レジャーの有効化記録によって決まります。
この記事は情報提供を目的としたものであり、金融または投資に関する助言を構成するものではありません。バリデータの支持状況と修正案のステータスは変動する可能性があります。