Ripple's XRPL-upgrade gaat vandaag niet live: validatorstemmen schuiven datum op
De XRP Ledger krijgt vandaag geen PermissionDelegationV1_1. De upgrade werd aan 5 oktober gekoppeld, maar de validatorsteun waarop die verwachting rustte viel in september tijdelijk weg.
De vereiste meerderheid werd pas op 24 september opnieuw bereikt. Daardoor begon de verplichte periode van twee weken opnieuw en ligt de vroegste activatie nu rond 8 oktober om 21:25 UTC, oftewel 23:25 uur Nederlandse tijd.
Dat is geen nieuwe vertraging door een ontdekte bug. Het is precies hoe het governanceproces van de XRP Ledger is ontworpen.
Validatorsteun viel weg en zette de klok terug
Nieuwe functies op de XRP Ledger worden via amendments toegevoegd.
Volgens de officiële XRPL-documentatie moet zo'n wijziging meer dan 80% steun van vertrouwde validators krijgen. Die meerderheid moet vervolgens twee weken onafgebroken blijven staan.
PermissionDelegationV1_1 had die meerderheid eerder bereikt.
Op 23 september ging de steun echter verloren. Een dag later, op 24 september rond 21:25 UTC, stond de vereiste meerderheid opnieuw.
Daar begon dus ook een nieuwe periode van veertien dagen.
29 van 35 validators is momenteel genoeg
In de huidige stemset worden 35 vertrouwde validators gevolgd.
Omdat de steun meer dan 80% moet bedragen, zijn minstens 29 ja-stemmen nodig. Met 29 van de 35 validators zit PermissionDelegationV1_1 daar momenteel net boven.
Dat geeft de upgrade weinig marge.
Wanneer de steun opnieuw naar 80% of lager zakt voordat de volledige periode is verstreken, vervalt de opgebouwde meerderheid opnieuw. Een nieuwe tweewekenteller begint dan pas wanneer voldoende validators weer voor stemmen.
Een verwachte activatiedatum op XRPL werkt daardoor fundamenteel anders dan een klassieke releasedatum van een softwarebedrijf.
Wat PermissionDelegation precies verandert
De functie laat een account beperkte bevoegdheden aan een ander account geven.
De eigenaar hoeft daarvoor niet de signing keys te delen waarmee volledige controle over het account mogelijk is.
Volgens de XRPL-documentatie over Permission Delegation kan een aparte account bijvoorbeeld toestemming krijgen om specifieke soorten transacties uit te voeren. Bevoegdheden waarmee sleutels kunnen worden gewijzigd of nieuwe rechten kunnen worden uitgedeeld, kunnen juist niet zomaar worden gedelegeerd.
Dat maakt een ander beveiligingsmodel mogelijk.
Een bedrijf kan gevoelige sleutels offline houden, terwijl een operationeel systeem alleen de rechten krijgt die het dagelijks nodig heeft.
Juist voor financiële partijen is dat interessant
Denk aan een uitgever van digitale activa die regelmatig transacties moet uitvoeren.
Nu ontstaat snel een onaangename keuze: de belangrijkste sleutel beschikbaar houden op een online systeem, of veel handelingen moeilijker automatiseren.
Permission Delegation probeert daar een tussenlaag voor te bouwen.
Een operationele account kan bepaalde acties uitvoeren zonder volledige controle over het onderliggende vermogen te krijgen.
Dat kan relevant zijn voor custodians, betalingsbedrijven, tokenuitgevers en andere partijen die functies over verschillende medewerkers of softwaresystemen willen verdelen.
Het lijkt daarmee meer op role-based access control uit traditionele bedrijfssoftware dan op simpelweg één wallet met één machtige sleutel.
Eerste versie werd juist vanwege een bug vervangen
De toevoeging heeft al een voorgeschiedenis.
De oorspronkelijke PermissionDelegation werd uitgeschakeld nadat een kritieke fout was ontdekt. XRPL-versie 2.6.1 trok die versie terug en kondigde aan dat een gerepareerde variant later zou volgen.
Die opvolger is PermissionDelegationV1_1.
De nieuwe versie kwam in augustus mee met xrpld 3.3.0, samen met onder meer BatchV1_1 en andere amendments.
Dat de huidige activatie naar 8 oktober schuift, betekent dus niet dat opnieuw dezelfde fout is gevonden.
Deze keer draait het om validatorstemmen.
Er geldt nog wel een technische waarschuwing
Helemaal zonder voetnoot is de nieuwe functie niet.
De actuele XRPL-documentatie waarschuwt om de specifieke PaymentBurn-bevoegdheid voorlopig niet te delegeren totdat fixCleanup3_4_0 actief is. Zonder die fix kan die toestemming onder bepaalde omstandigheden breder werken dan bedoeld.
Volgens XRPL zijn andere granular permissions daar niet door geraakt.
Dat staat los van de reset van de tweewekenteller, maar is voor partijen die de nieuwe functie straks daadwerkelijk willen gebruiken wel relevant.
8 oktober blijft een verwachting
De datum van 8 oktober is dus nog geen garantie.
Wanneer de huidige meerderheid standhoudt, kan PermissionDelegationV1_1 na de volledige wachtperiode worden geactiveerd. De exacte verwerking gebeurt rond een zogenoemd flag ledger, waardoor het uiteindelijke moment iets na de genoemde tijd kan liggen.
Verandert het stemgedrag vóór die tijd opnieuw, dan schuift de datum weer op.
Daar zit meteen de belangrijkste les van deze vertraging.
Op de XRP Ledger bepaalt een ontwikkelaar niet zelfstandig wanneer nieuwe protocolregels live gaan. De code kan klaarstaan en de software kan verspreid zijn, maar uiteindelijk moet voldoende validatorsteun lang genoeg overeind blijven.
Voor PermissionDelegationV1_1 loopt die klok nu richting 8 oktober.
Stop met te veel betalen voor je crypto. Bij de Amsterdamse exchange Finst handel je tegen de laagste tarieven van Nederland, zonder verborgen kosten.
👀 Bekijk Finst nu ›Let op: Beleggen in crypto brengt risico’s met zich mee. Handel alleen met geld dat u kunt missen.
Ga verder met lezen
Dit vind je misschien ook leuk
Laat mensen jouw mening weten
Lees ook
Populair Nieuws
Loading
