XRP账本放贷修复案等待80%验证者投票以免去借款人多付一单位

还款修正在8698号拉取请求中详解

一项目标明确的代码修正近日针对XRP Ledger的原生放贷协议发布,服务对象是金库运营方和借款人。此次修正要解决的是贷款还款的舍入方式,方案写在针对rippled(即运行XRP Ledger这一XRP背后的一层网络的参考服务器软件)的8698号拉取请求中。若该改动生效,每一笔还款后的余额将与贷款计划完全一致,不再在债务存续期内出现小额漂移。

整个提案围绕两个记账概念展开。TotalValueOutstanding指借款人在任一时点尚未偿还的总额,PeriodicPayment则是每期按时还款本应清偿的计划金额。在LendingProtocolV1_2之下,每次按时执行的LoanPay会把TotalValueOutstanding降至计划值,总期数减少一期,且永远不超过舍入后的PeriodicPayment。当借款人多还时,TotalValueOutstanding会重置为重构后PeriodicPayment对应的计划数字。舍入差异听起来微不足道,但一笔以程序化方式结算贷款的账本必须保证算术的确定性,因为所有节点在处理同一笔交易后必须得出相同的余额。

此次修正案延续了账本向原生放贷领域的推进,这类市场通常被归入去中心化金融范畴,且该业务与Ripple的RLUSD同处一条链上,其中一半发行于XRP Ledger。由于这是针对贷款记账的代码层面修正,对今日的XRP价格并无直接影响;其真正作用落在XRP生态的放贷技术栈上,即发行方设定贷款条款、借款人按计划还款的那一层。

舍入误差如何在各期还款间累积

现有实现在计算每笔还款的价值部分时各自独立处理。由此带来的结果是,舍入误差会在贷款存续期内不断累积:最后一期可能比舍入后的PeriodicPayment多出一个单位,相邻两期还款的价值部分还会上下交替,而不是保持稳定。该拉取请求的第一个提交把计划值计算从computeLoanProperties中抽出,移入独立的scheduledValue函数,这一步本身不改变任何行为。让创建贷款的LoanSet交易和记录还款的LoanPay交易都经由同一路由,意味着两侧对同一个数字的舍入方式完全一致。

没有写入任何APY的贷款还需要为本金部分设一个下限,因为这类贷款的价值按最近值舍入,而本金按进位法舍入。修正的核心是一种开发团队称为“望远镜式”的处理方法:它把每期按时还款的价值部分设定在PeriodicPayment的下限或上限,且永远不低于一个单位。这样一来,最后一期恰好落在舍入后的PeriodicPayment上,既补上了过去在还款计划末端才暴露的差额,也消除了各期之间的交替模式。金库是账本上的池化信贷结构,测试覆盖了Legacy、CashBasis和FixedPrecision三类金库,且每类都在修正案激活与未激活两种状态下分别运行,方便审查者单独定位其影响。

80%验证者投票进展如何

我们的判断是,这次修正主要面向发行方和金库工具,而非普通借款人。用户和投资者今天几乎感受不到影响:末期多付一个单位在实际操作中无足轻重,而已带着多出一个单位进入还款的老贷款维持原状,除非借款人提前多还,否则最后一期仍需支付PeriodicPayment加一个单位。小额多还大多被忽略,交易照常成功,也不会额外收取XRP。这套延伸至支付金融结算的账本信贷技术栈,由此获得更干净的算术,存量贷款无需任何迁移负担。

尚未迈出一步的是验证者群体。修正案激活需要80%的验证者连续两周保持一致,而LendingProtocolV1_2至今没有公布任何公开投票,激活日期因此无法确定。悬而未决的是时间问题而非方案本身:代码和测试都已就绪,缺的就是那一次投票。