Ripple's XRP Ledger herbouwt twee upgrades na fouten in eerdere versies

Acht transacties in één bundel en accountrechten uitdelen zonder de volledige controle weg te geven. De XRP Ledger werkt met BatchV1_1 en PermissionDelegationV1_1 aan precies die twee mogelijkheden.

Daar zit wel een belangrijke rem op. De functies vereisen eerst activering van hun amendment voordat ze op het netwerk kunnen worden gebruikt. De officiële lijst met XRPL-amendments beschrijft beide upgrades, maar de publiek weergegeven documentatie geeft niet overal rechtstreeks hun actuele activatiestatus weer.

Dat onderscheid telt. Ondersteuning in software betekent nog niet automatisch dat een functie ook op Mainnet bruikbaar is.

BatchV1_1 laat gebruikers maximaal acht transacties samen indienen. Die bundel kan verschillende regels meekrijgen voor wat er gebeurt wanneer één onderdeel mislukt.

De XRPL-documentatie over Batch-transacties noemt vier uitvoeringsvormen. Bij All or Nothing moet ieder onderdeel slagen. Faalt één transactie, dan gaat de hele bundel niet door.

Dat maakt combinaties mogelijk die anders uit meerdere losse stappen bestaan.

Een gebruiker kan bijvoorbeeld een NFT aanmaken en direct een verkoopaanbod plaatsen. Mislukt het aanbod in de alles-of-nietsmodus, dan wordt ook het aanmaken van de NFT teruggedraaid.

Er bestaan daarnaast modi waarbij slechts één transactie slaagt, verwerking stopt na de eerste fout of onderdelen onafhankelijk worden behandeld.

Een batch is dus niet automatisch hetzelfde als volledige ondeelbaarheid. De gekozen modus bepaalt hoeveel transacties van elkaar afhankelijk zijn.

Juist bij zo'n functie is correcte autorisatie belangrijk.

De eerdere Batch-amendment werd uitgeschakeld nadat een ernstige fout in de controle van onderliggende transacties was gevonden. Volgens XRPL kon die fout onder bepaalde omstandigheden ongeautoriseerde transacties mogelijk maken. De amendment was toen nog niet op Mainnet geactiveerd.

BatchV1_1 vervangt die eerdere versie en bevat de aangepaste implementatie. De nieuwe variant werd met xrpld 3.3.0 toegevoegd aan de software.

Dat verleden maakt de activatiestatus meer dan een technisch detail. Nieuwe transactiemogelijkheden moeten niet alleen aanwezig zijn in de code, maar ook het validatorproces doorlopen voordat Mainnet ze accepteert.

De tweede upgrade draait om bevoegdheden.

Met Permission Delegation kan een account specifieke rechten aan een ander account geven. De eigenaar kan die rechten later wijzigen of weer intrekken.

Dat kan vooral nuttig zijn wanneer een account meerdere taken uitvoert.

Een bedrijf kan bijvoorbeeld sleutels met volledige controle apart bewaren en een ander account alleen toestemming geven voor terugkerende handelingen. Wordt dat tweede account geraakt, dan hoeft niet automatisch iedere functie van het hoofdaccount open te liggen.

Ook geautomatiseerde software kan van zo'n model profiteren. Een bot hoeft dan niet dezelfde macht te krijgen als de eigenaar van het account.

Daar zit wel een grens aan. De beschikbare fijnmazige rechten zijn vooraf vastgelegd. Gebruikers kunnen niet zelf iedere mogelijke regel samenstellen, zoals een bevoegdheid die uitsluitend voor één gekozen valuta geldt.

De documentatie waarschuwt op dit moment expliciet voor PaymentBurn.

Zolang fixCleanup3_4_0 niet is geactiveerd, adviseert XRPL om deze specifieke bevoegdheid niet te delegeren. Een account met PaymentBurn kan vóór die reparatie onder bepaalde omstandigheden ook fungibele tokens aanmaken.

Volgens de documentatie treft dat probleem de andere afzonderlijke bevoegdheden niet.

Daarmee wordt ook zichtbaar hoe gevoelig permission delegation is. Een kleine fout in de afbakening van één recht kan een account meer macht geven dan de eigenaar bedoelde.

Op papier vullen beide upgrades elkaar goed aan.

Batch-transacties kunnen meerdere handelingen koppelen. Permission Delegation kan bepalen welk account die handelingen namens een ander mag uitvoeren.

Dat kan interessant worden voor exchanges, wallets, handelssoftware en geautomatiseerde bedrijfsprocessen. Minder losse transacties en beperktere sleutelmacht kunnen processen overzichtelijker maken.

Maar de code alleen beslist niet wanneer gebruikers daarvan profiteren.

Daarvoor moeten de amendments op het netwerk zijn geactiveerd. Daarna moeten wallets en andere toepassingen de functies ook correct ondersteunen en duidelijk tonen welke rechten een gebruiker precies weggeeft.

Voor XRPL ligt daar de volgende test: niet hoeveel nieuwe functies er in de software zitten, maar hoeveel controle gebruikers houden zodra die functies daadwerkelijk geld en accountrechten mogen aansturen.