XRP Ledgerの貸出修正、80%バリデータ投票待ちで借手の追加1単位回避へ

プルリクエスト8698で返済の丸め処理を修正

XRP Ledgerのネイティブ貸出プロトコルを利用するボールト運営者と借手が、新たに公開されたコード変更の想定受益者だ。この修正はローン返済額の丸め処理を整えるもので、XRPを支えるレイヤー1ネットワークであるXRP Ledgerの参照サーバーソフトウェアrippledに対するプルリクエスト8698として示された。有効化されれば、返済のたびに残高がローンのスケジュールと正確に一致し、債務存続期間中のわずかなずれが積み重なる状況はなくなる。

提案の中核を担う会計用語は二つある。TotalValueOutstandingは借手が任意の時点でまだ負っている額の累計値を表し、PeriodicPaymentは期限通りに支払われる各回の予定返済額を表す。LendingProtocolV1_2では、期限通りの各LoanPayがTotalValueOutstandingを予定値まで引き下げ、支払い回数全体で一回分が減り、かつ丸められたPeriodicPaymentを上回ることがない。借手が過剰に支払った場合、TotalValueOutstandingは組替え後のPeriodicPaymentの予定額へリセットされる。丸めの微小な差異は些細に見えるが、プログラム的にローンを決済する台帳では算術の決定論性が必須であり、同じトランザクションを処理したすべてのノードが同一残高に到達しなければならない。

今回の修正案は、台帳のネイティブ貸出への推進を一段深めるものであり、その市場は一般にDeFiと分類される分野だ。RippleのRLUSDと同じブロックチェーン上に位置し、半分がXRP Ledger上で発行されている。ただし変更内容はローン会計のコードレベルでの補正にすぎず、今日のXRP価格への直接的な影響はない。効果が及ぶのは、発行者が貸付条件を設定し借手がスケジュールに従う、XRPエコシステムの貸出スタックだ。

丸めずれがローン返済で生じる仕組み

現行実装では各支払いの価値要素を個別に算出する。その結果、丸め誤差がローン期間中に蓄積する。最終回が丸められたPeriodicPaymentより1単位多く要求されることがあり、連続する支払いの価値要素も安定せず上下に振れる。プルリクエストの最初のコミットは、予定額の計算をcomputeLoanPropertiesから独立したscheduledValue関数へ切り出したもので、単体では動作を変えない。両経路を共通ルーチンへ通すことで、ローンを生成するLoanSetと支払いを記録するLoanPayが同じ方法で丸めることになる。

APYを明示しないローンでは元本部分に下限も必要になる。価値は四捨五入される一方、元本は切り上げられるためだ。修正の中核は開発者がテレスコーピングと呼ぶ手法で、期限通り各支払いの価値要素をPeriodicPaymentの切り捨て値か切り上げ値に設定し、1単位を下回らないようにする。最終回は丸められたPeriodicPaymentに正確に一致し、スケジュール末尾で顕在化していたずれが解消され、回ごとの交互振動も消える。ボールトは台帳のプール型信用構造であり、テストはLegacy、CashBasis、FixedPrecisionの各ボールトを対象に、修正案有効時と無効時の両方で実行され、審査者が効果を切り分けられるようにした。

80%バリデータ投票の現在地

当メディアの読みでは、この修正案は日常の借手よりも発行者とボールトツールを主な対象としている。ユーザーや投資家が今日受ける影響はごく小さい。最終回の追加1単位は実務上ほとんど変わらず、既存のローンでスケジュールを1単位上回る分がすでにあるものはそのまま維持されるため、借手が先に過剰支払いしない限り、最終回はPeriodicPaymentに1単位を加えた額が必要だ。少額の過剰支払いは概ね無視され、トランザクションは成立し追加のXRPは請求されない。PayFi決済にも及ぶ台帳の信用スタックは、既存ローンに移行負担を課すことなく、より整った算術を得る。

動いていないのはバリデータ側だ。有効化にはコンセンサスメカニズムを支えるバリデータの80%の賛成が2週間連続で維持される必要があるが、LendingProtocolV1_2に関する公開投票はまだ発表されておらず、有効化時期は未定のままだ。論点は是非ではなく時期にあり、コードとテストはすでに存在し、欠けているのは投票そのものである。