XRPLs Entwurf für geschlossene Vaults wird zu Patches auf XLS-65 und XLS-66
Victoria Shinder2 Min. LesezeitPR #636 von Tapanito ist in XRPL-Standards eingegangen und strukturiert die Spezifikation für geschlossene Vaults über acht Dateien mit 453 Ergänzungen und 620 Löschungen um - netto 167 Zeilen weniger. Verschwunden ist ein eigenständiger XLS-draft-closed-ended-vault; erschienen sind verschachtelte Patches gegen die Dokumente, die das Feature tatsächlich ändert: 65.1.1-unmodifiable-vault-fields.md und ein neues 65.1.4-closed-ended-vault.md unter XLS-0065 Single-Asset-Vault sowie 66.1.2-closed-ended-loan-gates.md unter XLS-0066 Lending-Protokoll.
Die Commit-Spur benennt die Prüfergebnisse statt sie zu verstecken: die Zusammenfassung in 65.1.1 wurde geklärt und verlinkt nun die übergeordneten XLS-65-Abschnitte aus dem Patch; die Formulierung der Laufzeit-Invariante für Kredite wurde korrigiert; die Anforderung wurde zwischen VaultCreate und LoanBrokerSet abgegrenzt; Testplan-Abschnitte kamen hinzu; die Formatierung von Code-Spans wurde bereinigt.
Was das bedeutet
Mehr zu löschen als hinzuzufügen und dabei Testpläne zu ergänzen ist ein gutes Zeichen für eine Spezifikation, und der Grund ist struktureller Natur. Ein eigenständiger Entwurf, der eine Variante eines bestehenden Features beschreibt, muss das Grundverhalten wiederholen, um seine Abweichungen zu erklären - und jede Wiederholung ist eine Kopie, die vom Original abdriften kann. Die Variante als Patches auf XLS-65 und XLS-66 zu formulieren heißt, den Grundtext zu zitieren statt zu reproduzieren: eine spätere Änderung am Single-Asset-Vault kann der Beschreibung des geschlossenen Vaults nicht mehr stillschweigend widersprechen, weil es keine zweite Beschreibung gibt, der man widersprechen könnte.
Es ist dieselbe Krankheit, die diese Branche im Code immer wieder neu entdeckt: zwei Beschreibungen einer Sache, und die zweite verfault. Hier wurde die Korrektur an der Prosa vorgenommen, bevor jemand gegen das Duplikat implementiert hat.
Die Abgrenzung VaultCreate gegen LoanBrokerSet ist das Detail, das Implementierer zuerst lesen sollten. "Welche Transaktion trägt die Anforderung" bestimmt, wo die Prüfung liegen muss und in was ein bestehender Vault nachträglich umgewandelt werden kann - eine Unklarheit dort erzeugt zwei Clients, die darüber streiten, ob ein bestimmter Zustand erreichbar ist. Die neuen Testplan-Abschnitte machen das aus dem Dokument beantwortbar statt aus der ersten Implementierung, die ausliefert.