XRP Ledger 开发者已于 9 月 16 日发布 xrpld 3.4.0 版本，新增两个修正案包，修订了拟议的原生借贷功能，并加固了多条交易路径，同时要求服务器运营商进行升级。
摘要
- XRPL 3.4.0 版本引入了两个修正案，涵盖借贷变更以及一个捆绑的协议修复包。
- LendingProtocolV1_1 增加了封闭式金库和收付实现制会计，但主网激活仍需持续的验证者共识。
- 敦促服务器运营商尽快升级，因为 XRPL 基金会现已分发签名的 Linux 软件包。
- fixCleanup3_4_0 加固了金库、AMM、MPT、托管、签名、凭证以及许可交易行为在各交易路径中的表现。
- 新的借贷修正案依赖于 XLS-65 和 XLS-66，这两者仍低于激活阈值。
XRPL 的官方发布说明称，3.4.0 版本引入了 LendingProtocolV1_1 和 fixCleanup3_4_0，同时退役了 fixAMMOverflowOffer，因为其在修正案后的行为已成为协议的永久组成部分。
该软件发布并不意味着任一新修正案已在主网上激活。XRPL 的修正案流程要求提案需连续两周获得超过 80% 的受信任验证者支持，其规则才会生效。
借贷 V1.1 增加封闭式金库和现金会计
XRPL 3.4.0 的发布说明称，LendingProtocolV1_1 通过引入具有明确认购期、投资期和赎回期的封闭式金库，改变了单资产金库和借贷协议的设计。
Ripple 的技术文档称，存款人可在认购阶段添加或提取资产。在投资期内，存款和取款停止，而资产可用于发放贷款。投资期结束后开始赎回，允许存款人在贷款到期后收回其份额。
一旦 LendingProtocolV1_1 激活，XRPL 的文档表示，新的贷款经纪人只能附加到封闭式金库。根据早期规则创建的现有贷款关系将获得单独处理，以便未平仓头寸可以继续管理。
会计模型同时发生变化。Ripple 的文档称，新金库将仅在借款人实际付款时确认利息。
在较早的模型下，所有预定利息在贷款发放时即被确认。收付实现制会计将未支付的未来利息排除在金库收入之外，直到付款到达，这会影响 AssetsTotal、贷款债务计算以及违约的会计处理。
V1.1 规则不会追溯转换旧金库。Ripple 的文档称，在先前会计方法下创建的金库在 V1.1 激活后仍保留该模型。
正如早前的修正案报道所述，Ripple 的验证者已在 8 月为底层的 SingleAssetVault 和 LendingProtocol 提案投票，但验证者批准率仍远低于主网激活所需的水平。
XRPL 3.4.0 打包了大量交易修复
第二个修正案 fixCleanup3_4_0 包含的修复涵盖借贷、金库、自动做市商、多用途代币、NFT、托管、许可交易和账户授权。
官方发布说明称，其中一项更改可防止 AMMClawback 在 MPT 舍入将计算出的回收金额降至零时，销毁持有者的流动性提供者代币却回收零底层资产。
另一项修复加强了 MPT 不变量。XRPL 开发者表示，此前仅生成日志的 ValidMPTBalanceChanges 和 ValidMPTTransfer 检查，现在在该修正案下强制执行，并且在交易失败时继续适用。
对于单资产金库，发布说明列出了存款、取款和回收过程中的精度与舍入更改。这些规则旨在当转换达到精度边界时，保持记录资产、可用资产和未偿付份额供应量一致。
许可交易获得多项更正。该软件包将已删除域报价排除在一项许可 DEX 不变量之外，收紧了域检查，并更正了 OfferCreate 或 Payment 交易运行时过期凭证的移除方式。
签名行为获得单独的保护措施。发布说明称，3.4.0 版本为交易对手签名和赞助者签名分配了不同的签名哈希前缀，因此为某一角色创建的签名无法被重放为另一角色。
该版本在修正案包之外还包含较低层级的节点加固。开发者修复了通过 TMGetLedger 进行的无界数据库查找，限制了传入 TMTransactions 列表的大小，并对无法反序列化的交易引入了费用。
XRPL 开发者表示，3.4.0 版本纳入了来自 MPT 和 DEX 审计及攻击马拉松发现的第一阶段修复。该版本并未将这些修复标识为主网上存在活跃漏洞利用的证据。
在此前的升级报道中，3.3.0 版本已经为几个单独提案引入了代码，包括修正后的批量功能、赞助费用和机密 MPT 转账，但仍需验证者批准才能激活。
验证者批准仍将发布与激活区分开来
XRPL 官方修正案规则指出，安装包含修正案的软件仅使服务器获得理解拟议规则所需的代码。验证者另行选择是否投票支持激活。
当前的 XRPLF 功能代码将 LendingProtocolV1_1 和 fixCleanup3_4_0 均列为受支持，同时保留 DefaultNo 投票行为。默认否设置意味着当运营者未配置其他选择时，运行该软件本身不会投出赞成修正案的票。
底层借贷组件仍未达到激活条件。9 月 17 日基于 XRPL 基金会验证者历史数据的快照显示，35 个受信任验证者中有 16 个支持 SingleAssetVault，35 个中有 13 个支持 LendingProtocol。
这些计数具有时效性，来自独立网络追踪器，并非发布说明中公布的固定数字。官方规则仍要求超过 80% 的支持率持续保持两周。
新的 V1.1 修正案依赖于底层借贷架构。当前的 XLS-66 规范描述了使用通过单资产金库汇集资金的固定期限、无抵押借贷，而借款人承销和信用风险评估仍在链下进行。
同一规范仍被归类为草案。本次更新所审查的任何来源均未显示通过拟议原生协议执行的主网贷款，也未显示 LendingProtocolV1_1 的激活日期。
节点运营者现在从 XRPL 基金会接收软件包
3.4.0 版本更改了 Linux 服务器软件包的分发路径。官方发布说明称，Debian 和 RPM 软件包现在通过 packages.xrplf.org 托管，并使用 XRPL 基金会密钥签名。
XRPL 开发者敦促服务器运营者“尽快”安装 3.4.0，以维持服务连续性。发布的 DEB 和 RPM 文件包含 SHA-256 校验和，以便运营者在安装前验证下载的软件包。
GitHub 现将 3.4.0 列为最新的不可变 xrpld 版本，对应提交 4a4fded2eba11427c48ce3f24d9c1aea5e7a9d17。该仓库表示，发布标签和版本提交均带有已验证的签名。
同一版本还停用了 fixAMMOverflowOffer。在 XRPL 的修正案模型下，停用并不会撤销该修复。它会在新规则已成为永久协议行为后，移除过时的修正前行为。
客户端支持与安全审查仍在推进中
应用库正与服务器版本同步推进。XRPLF 的 JavaScript 客户端历史记录在 xrpl.js 5.2.0（于 9 月 11 日发布）之后的未发布部分列出了对 LendingProtocolV1_1 的支持。
二进制编解码器历史记录显示，2.11.0 版本已包含 fixCleanup3_4_0 所使用的特定角色赞助方和交易对手签名前缀，以及由 xrpld 3.4.0 生成的协议定义。
借贷工作的安全测试一直与验证者投票分开进行。Sherlock 在 8 月 27 日的一份评论中表示，Ripple 已通过其 Audit Engine 启动了对 Lending Protocol V1.1 的纯 AI 审查。
Sherlock 表示将在审查完成后发布更多信息，但在本报告核查的其公开材料中未找到 V1.1 的最终发现。此前的测试覆盖了借贷系统的先前版本；此前的独立审计报道称，Halborn 早前的重新审计未发现关键或高风险问题，但识别出一个中危、两个低危和两个信息性发现。
