Meer dan 10.000 regels code kunnen uit de
XRP Ledger verdwijnen.
Ripple wil XChainBridge afvoeren omdat Axelar de belangrijkste toepassing heeft overgenomen en ontwikkelaars nauwelijks andere vraag hebben laten zien.
Tegelijk beweegt fixCleanup3_3_0 richting mogelijke activatie. De amendment kreeg op 28 augustus 29 ja-stemmen, goed voor 82,86% steun. Blijft die meerderheid twee weken overeind, dan kan het pakket vanaf 11 september actief worden.
Ripple wil XLS-38 niet langer meeslepen
De amendment, bekend als XLS-38, moest native verbindingen mogelijk maken tussen de
XRP Ledger en andere chains.
Daarvoor gebruikte het ontwerp zogenoemde witness servers. Die servers observeren beide netwerken en bevestigen wanneer assets aan de ene kant zijn vastgezet, zodat ze aan de andere kant beschikbaar kunnen worden gemaakt.
Het plan was breed.
Private sidechains, permissioned networks en experimentele netwerken konden allemaal via dezelfde techniek aan
XRPL worden gekoppeld. Ook de EVM Sidechain moest oorspronkelijk XLS-38 gebruiken.
Dat gebeurde uiteindelijk niet.
Axelar nam de belangrijkste taak over
Voor de XRPL EVM Sidechain koos Ripple samen met andere betrokken ontwikkelaars voor Axelar.
Ripple zegt dat vooral beveiliging en beheer van een publieke bridge zwaar wogen bij die keuze. Een groter netwerk van witnesses kan de spreiding verbeteren, maar maakt coördinatie en verantwoordelijkheid ook ingewikkelder.
Volgens Ripple vraagt het beheren van grote cross-chain bridges om specialistische kennis die het bedrijf niet zelf op grote schaal wilde opbouwen.
Axelar was daar specifiek voor ontworpen.
Daarom maakte Ripple in juni 2024 al bekend dat de EVM Sidechain via Axelar met XRPL-mainnet zou worden verbonden. Ripple bleef met zijn eigen validator tegen XLS-38 stemmen, maar gaf andere ontwikkelaars nog 12 tot 15 maanden om aan te tonen dat zij de techniek nodig hadden.
Die ontwikkelaarsvraag kwam niet
Volgens Ripple leverde die periode onvoldoende concrete projecten op.
Het bedrijf zegt communityfora, ontwikkelaars en nieuwe voorstellen te hebben gevolgd. Er verscheen geen grote groep bouwers die voor private of experimentele sidechains specifiek afhankelijk was van XLS-38.
Daarmee bleef een flink stuk code aanwezig zonder duidelijke route naar gebruik.
Ripple schat dat volledige verwijdering van XChainBridge meer dan 10.000 regels uit xrpld kan halen.
Dat is niet alleen schoonmaakwerk.
Code die niet wordt gebruikt moet nog altijd worden getest, beoordeeld en meegenomen bij toekomstige veranderingen. Meer code betekent daarnaast meer plekken waar onverwachte fouten kunnen ontstaan.
Ripple kan de bridge niet zelfstandig verwijderen
Daar zit wel een belangrijke grens.
Ripple bepaalt niet alleen wat er met het
blockchain-protocol gebeurt.
“This is a recommendation, not a unilateral decision.”
Ripple beschikt over één validatorstem binnen het grotere consensusproces. Het bedrijf stelt daarom een stapsgewijze afbouw voor.
Eerst moet XChainBridge in een toekomstige versie van xrpld de status VoteBehavior::Obsolete krijgen.
Validators die die software draaien, stemmen vervolgens automatisch tegen XLS-38.
Wanneer het netwerk de amendment breed als obsolete behandelt, kan de daadwerkelijke code in een latere release worden verwijderd.
Ook fixXChainRewardRounding, een correctie die specifiek bij XChainBridge hoort, moet dan verdwijnen.
Voor de EVM Sidechain verandert niets
Gebruikers van de XRPL EVM Sidechain hoeven door het voorstel niet van bridge te wisselen.
Axelar blijft daar de route tussen de EVM Sidechain en XRPL-mainnet.
Het schrappen van XLS-38 betekent evenmin dat XRPL stopt met cross-chain verbindingen.
Ripple noemt verschillende technieken voor verschillende toepassingen, waaronder Axelar, Wormhole, zero-knowledgeoplossingen en L2-achtige ontwerpen.
De conclusie is smaller: Ripple denkt niet langer dat één native bridgearchitectuur al die problemen tegelijk moet oplossen.
Tegelijk komt fixCleanup3_3_0 dichterbij
Aan de andere kant van de codebasis gebeurt precies het tegenovergestelde.
De op 6 augustus uitgebrachte
xrpld 3.3.0 bevat fixCleanup3_3_0. Dat is geen nieuwe DeFi-functie, maar een verzameling correcties voor verschillende transactieregels.
Op 28 augustus bereikte de amendment volgens de gerapporteerde validatorstand 29 ja-stemmen.
Dat kwam neer op 82,86% en zette de tweewekentermijn in gang.
XRPL gebruikt voor amendments een duidelijke regel: een voorstel moet langer dan twee weken meer dan 80% steun van trusted validators houden voordat het definitief actief wordt.
Zakt de steun tussendoor terug naar 80% of lager, dan vervalt die lopende meerderheid en moet de termijn later opnieuw beginnen.
Daarom is 11 september geen gegarandeerde releasedatum.
Het is het vroegste moment op basis van de meerderheid die op 28 augustus werd bereikt.
De fix raakt AMM’s, Checks en lendingcode
De lijst met wijzigingen is behoorlijk technisch.
fixCleanup3_3_0 bevat correcties voor onder meer Automated Market Makers, de permissioned DEX, Checks, pseudo-accounts, Single Asset Vaults en het Lending Protocol.
Bij pseudo-accounts worden bijvoorbeeld freeze- en deep-freezecontroles gelijkgetrokken voor verschillende transactietypes.
Een pseudo-account is een speciaal XRPL-account dat door protocolfuncties wordt gebruikt, niet een normale gebruiker met een geheime sleutel.
Juist daarom moeten transacties die doen alsof zo'n account zelf iets heeft ondertekend worden tegengehouden.
Een AMM-fout met deling door nul wordt afgevangen
Ook de bestaande AMM-code krijgt meerdere correcties.
Een specifieke AMMWithdraw-situatie kon een berekening bereiken waarbij door nul werd gedeeld. De nieuwe regels laten zo'n transactie gecontroleerd stoppen met een foutcode.
Daarnaast worden controles toegevoegd rond rekenprecisie.
Bij financiële software zijn zulke kleine afrondingsproblemen niet cosmetisch. Een afwijking kan doorwerken in prijsberekeningen of bepalen welke transactie wel of niet wordt geaccepteerd.
Ook de voorwaarden waaronder een AMM-object mag worden verwijderd worden strenger gecontroleerd.
Permissioned DEX krijgt eigen reparaties
De permissioned DEX wordt eveneens geraakt.
Daar konden hybride offers uit het publieke orderboek verdwijnen wanneer het account achter de order later de toegang tot een permissioned domain verloor.
fixCleanup3_3_0 past dat gedrag aan.
Ook werd AMM-liquiditeit meegenomen bij bepaalde kwaliteitsberekeningen voor permissioned orderboeken waar die niet op dezelfde manier hoorde mee te tellen.
Het zijn randgevallen.
Maar juist randgevallen worden gevaarlijk zodra er steeds meer geld op dezelfde regels vertrouwt.
Niet alle geraakte DeFi-functies zijn al live
Hier moet één nuance scherp blijven.
Single Asset Vaults en het Lending Protocol zitten wel in de XRPL-code, maar hun eigen amendments zijn nog afhankelijk van afzonderlijke activatie.
De
officiële amendmentlijst behandelt SingleAssetVault en LendingProtocol apart. Zonder hun eigen activatie kunnen transacties die ervan afhankelijk zijn niet zomaar op mainnet worden gebruikt.
fixCleanup3_3_0 maakt die code dus alvast strenger en consistenter.
Dat is iets anders dan zeggen dat de volledige lendingmarkt op XRPL al draait.
Node-operators moeten wel opletten
Voor operators krijgt een geactiveerde amendment praktische gevolgen.
Een server moet nieuwe transactieregels begrijpen om correct met het netwerk mee te blijven doen.
XRPL waarschuwt daarom bij xrpld 3.3.0 dat operators moeten upgraden. Ook Clio 2.8.0 voegde ondersteuning voor fixCleanup3_3_0 en andere recente amendments toe.
Een achterlopende node kan amendment blocked raken wanneer het netwerk regels activeert die zijn software niet ondersteunt.
Dat mechanisme voorkomt dat oude software stilletjes ledgers blijft verwerken volgens regels die niet meer gelden.
Minder code kan juist winst zijn
Daarmee komen beide ontwikkelingen bij hetzelfde punt uit.
XChainBridge is uitgebreide code waarvoor Ripple na jaren onvoldoende reden ziet om haar te behouden.
fixCleanup3_3_0 doet het omgekeerde: code die onderdeel blijft van de toekomstige XRPL wordt op meerdere randgevallen aangescherpt.
Voor
XRP-houders verandert hierdoor niet plotseling het maximale aanbod of de escrowstructuur.
De impact ligt lager in de stack.
Hoe minder ongebruikte code ontwikkelaars jarenlang moeten meeslepen, hoe kleiner de onderhoudslast. En hoe harder actieve en geplande functies worden getest, hoe minder ruimte er blijft voor onverwacht gedrag wanneer er later grotere bedragen doorheen bewegen.
September krijgt daardoor twee technische vragen.
Houdt fixCleanup3_3_0 zijn meerderheid lang genoeg vast om actief te worden?
En vindt iemand nog een usecase die sterk genoeg is om meer dan 10.000 regels XChainBridge-code van de prullenbak te redden?