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，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 支援。
binary-codec 歷史記錄顯示，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 先前的重新審計未發現任何關鍵或高風險問題，同時識別出一項中等、兩項低風險和兩項資訊性發現。
