XRP Ledgerのアップグレードで私の注目を引いたのは、10月5日という日付ではありません。

この機能には、すでに一度深刻な問題があったという事実があります。

PermissionDelegationV1_1は、9月21日に14日間の有効化カウントダウンを開始し、約35の信頼できる検証者のうち29がこれをサポートしていました。

サポートが80%のしきい値を上回ったままであれば、この機能は10月5日に有効化される可能性があります。

そのアイデア自体が実用的です。

1つのアカウントにすべての権限を付与する代わりに、事業者は役割ごとに権限を分割して委任できます。コンプライアンス・システムはトークン保有者を承認でき、主要な鍵はオフラインのまま維持されます。オペレーション用のアカウントは、鍵を変更したりアクセスを付与したりする権限を得ることなく、支払い処理を行えます。

各委任者は最大 10 個の権限を受け取ることができ、これらの権限は変更または取り消しできます。

ですが、以前のバージョンでは、なぜ慎重なテストが必要なのかが明らかになりました。

コミュニティのテスターは、一部の失敗したトランザクションでも手数料が請求される可能性がある一方で、署名の前に権限がチェックされていたことを発見しました。

それによって、潜在的なスパムおよび手数料の悪用の問題が生じました。

バリデータは、本番投入される前に最初のバージョンを拒否しました。

修正は xrpld 3.3.0 で出荷され、手数料が請求される前に署名の検証が行われるようになりました。

私にとっては、これは通常の機能有効化よりも現在のカウントダウンを面白くします。

問題は、単にバリデータが別のアップグレードを承認するかどうかだけではありません。

それは、新しい実装が最初の試行を停止させた障害モードに対処できたかどうかについてです。

同時に、XLS-65 と XLS-66 は別のインフラの一部に向けて取り組んでいます。

シングル・アセット・ボールトは、ユーザーが 1 つの資産をプールして持分を受け取れるようにします。XLS-66 は、これらのボールトを用いて固定期間の融資を行います。

融資の作成と返済はオンチェーンで行われ、引受はオフチェーンのままになります。

自動清算もないため、この設計は事業融資や運転資金の用途により適しています。

しかし、これらの機能には、技術的なデプロイ以上のものがまだ必要です。

必要なのは実ユーザーです。

私にとっては、したがって 10 月 5 日はカレンダー上の日時というよりも、XRPL が権限管理や融資インフラを、企業が実際に使うものへと変えられるかどうかにかかっています。

このアップグレードにはもう一つのやり直しの機会があります。

これで、実装はそれに値することを証明しなければなりません。