Minder geheugen klinkt niet als vuurwerk. Toch kan dat precies het punt zijn bij de nieuwste
XRPL-release.
De
XRP Ledger krijgt met versie 3.3.0 veel aandacht door privacy, sponsored fees en nieuwe functies voor tokenized assets. RippleX-engineer Mayukha Vadari wees juist op iets drogers: lagere geheugendruk, beter serveronderhoud en tientallen bugfixes.
Dat is geen bijzaak. Als XRPL meer financiële toepassingen wil dragen, moet de serverlaag vooral voorspelbaar blijven.
GitHub-release laat brede onderhoudsronde zien
De officiële
XRPLF-release op GitHub werd op 6 augustus gepubliceerd. De lijst met wijzigingen is lang en technisch.
Daarin staan nieuwe functies, maar ook veel schoonmaakwerk. Denk aan C++23, extra tests, strengere checks, betere buildprocessen en fixes rond bestaande onderdelen.
Vadari vatte de minder zichtbare kant samen: meer dan 15% lager geheugengebruik, betere online_delete-prestaties en ongeveer zestig fixes uit een AI-assisted red-teamtraject.
Voor eindgebruikers is dat niet direct zichtbaar in een wallet. Voor node-operators kan het verschil maken.
Minder geheugen verlaagt druk op node-operators
Een XRPL-server moet transacties verwerken, ledgerdata bewaren en met andere nodes blijven synchroniseren. Hoe meer functies het netwerk krijgt, hoe zwaarder die taak kan worden.
Lagere geheugendruk betekent niet automatisch dat de ledger ineens sneller wordt. Het kan wel helpen om servers stabieler te draaien, vooral bij zwaardere belasting.
Dat telt voor validators, exchanges en partijen die eigen XRPL-nodes gebruiken. Zij willen geen netwerklaag die afhankelijk wordt van steeds duurdere of complexere machines.
De
blockchain is dan niet alleen code. Het is ook beheer, geheugen, opslag, monitoring en fouten afvangen voordat gebruikers iets merken.
online_delete is saaier dan het klinkt
Ook online_delete kreeg aandacht. Dat is de functie waarmee een XRPL-server oude ledgerdata kan verwijderen, zodat lokale opslag niet blijft doorgroeien.
De officiële
XRPL-documentatie beschrijft dat een server de huidige ledgerstaat behoudt, maar oudere transacties en oude versies van ledgerdata kan opschonen.
Dat proces kost tijd en raakt disk-I/O en cachegebruik. Als het beter loopt, helpt dat vooral partijen die nodes langdurig willen beheren.
Dit is het soort werk dat geen koersgrafiek krijgt. Maar het bepaalt wel hoe soepel een netwerk blijft draaien als gebruik toeneemt.
AI-red team leverde tientallen fixes op
De bugfixes uit het AI-assisted red-teamproces zijn minstens zo belangrijk. XRPL krijgt steeds meer bewegende delen: lending, batches, permissioned functies, MPT’s en nieuwe vormen van delegatie.
Hoe meer onderdelen, hoe meer interacties. Juist daar ontstaan fouten.
Dat bleek eerder al bij Batch. Een
XRPL-securityrapport beschreef hoe een fout in de Batch-amendment had kunnen leiden tot onbevoegde transacties als die functie actief was geworden.
De functie was toen nog niet live op mainnet. Er stonden dus geen fondsen op het spel.
Wel was de waarschuwing hard. Nieuwe functies moeten niet alleen afzonderlijk kloppen. Ze moeten ook veilig blijven wanneer ze samen worden gebruikt.
De beste protocolupgrade is soms de update die gebruikers nooit merken, omdat het probleem al vóór activatie is weggehaald.
C++23 en testdekking zijn geen koersnieuws
De overstap naar C++23 klinkt voor beleggers als ontwikkelaarsjargon. Voor een protocolcodebase is het wel relevant.
Modernere code kan onderhoud makkelijker maken. Nieuwe taalopties en betere tooling helpen ontwikkelaars om fouten eerder te vinden en oude patronen weg te halen.
Ook hogere testdekking telt. Een test voorkomt geen fout in alle gevallen, maar vergroot de kans dat een wijziging breekt voordat software breed wordt uitgerold.
Voor een netwerk dat meer
tokenisatie wil ondersteunen, wordt dat zwaarder. Tokenized assets vragen niet alleen snelle transacties. Ze vragen ook betrouwbare regels rond eigendom, transfers, uitgifte en uitzonderingen.
Nieuwe functies zijn nog niet automatisch actief
XRPL 3.3.0 bevat ondersteuning voor nieuwe amendmentvoorstellen, waaronder ConfidentialTransfer, Sponsor, DynamicMPT, BatchV1_1 en PermissionDelegationV1_1.
Dat betekent niet dat elke
XRP-gebruiker die functies nu al kan gebruiken.
De
XRP Ledger werkt met een amendmentproces. Volgens de
XRP Learning Portal vereist een amendment 80% steun gedurende twee weken voordat de wijziging wordt toegepast.
Dat onderscheid is belangrijk. Software kan klaarstaan. Mainnet-activatie vraagt nog validatorsteun.
Headlines die doen alsof privacyfuncties direct voor iedereen actief zijn, gaan dus te snel.
Privacy trekt aandacht, stabiliteit draagt de last
Confidential Transfers zullen waarschijnlijk de meeste aandacht krijgen. Die functie is gericht op meer privacy rond bepaalde tokenbewegingen.
Sponsored fees zijn ook zichtbaar. Daarmee kunnen andere partijen kosten of reserves dragen, wat onboarding makkelijker kan maken.
Maar de stille kant van 3.3.0 zegt meer over de richting van XRPL. Het netwerk wordt niet alleen uitgebreid. Het wordt ook opgeschoond.
Dat is nodig als XRPL zich wil blijven richten op betalingen, instellingen en real-world assets.
Institutioneel gebruik vraagt saaie zekerheid
Een experimentele app kan soms leven met scherpe randen. Een financiële rail kan dat niet.
Exchanges, marketmakers en bewaarpartijen kijken naar uptime, foutafhandeling, voorspelbare kosten en nodebeheer. Een
wallet mag geen raadspel worden. Een validator mag niet omvallen door een randgeval in nieuwe code.
Daarom is lagere geheugendruk geen detail. Het raakt de kosten en betrouwbaarheid van de mensen die het netwerk draaiend houden.
XRPL 3.3.0 wordt verkocht via privacy en tokenized assets. De echte test zit dieper.
Als gebruikers niets merken van minder geheugen, betere online_delete en zestig bugfixes, heeft die stille laag precies gedaan wat hij moest doen.