XRP Ledger-upgrade loopt minstens tien dagen vertraging op na validatorreset
De klok stond bijna op nul. Eén terugval in validatorsteun was genoeg om twee weken voortgang voor BatchV1_1 weg te vegen.
De belangrijke XRP-upgrade zou rond 29 september kunnen activeren. Dat wordt nu op zijn vroegst 9 oktober rond 14:46 UTC, oftewel 16:46 uur Nederlandse tijd.
De steun is alweer terug naar 30 van de 35 trusted validators. Alleen moet die meerderheid nu opnieuw veertien dagen onafgebroken blijven staan.
Eén dip zette de teller terug naar nul
De XRP Ledger gebruikt amendments om grote protocolwijzigingen te activeren.
Validators stemmen over zulke wijzigingen. Een amendment moet vervolgens twee weken lang steun houden van meer dan 80% van de trusted validators voordat het automatisch kan worden ingeschakeld.
Met 35 validators ligt de echte grens daardoor op 29 stemmen.
28 van 35 is precies 80% en telt niet als voldoende meerderheid.
BatchV1_1 had sinds 15 september een geldige majority-periode lopen. Op 25 september viel de steun tot 80% of lager en verdween die opgebouwde periode.
Steun kwam vrijwel direct terug
Lang duurde de terugval niet.
BatchV1_1 herwon op 25 september om 14:46:02 UTC zijn meerderheid.
De huidige stand is 30 stemmen voor van 35 trusted validators, ongeveer 85,7%. Er zijn minimaal 29 stemmen nodig.
Vanaf dat moment begon de veertiendaagse klok opnieuw.
Blijft de steun boven de grens, dan ligt de eerst mogelijke activatie op:
9 oktober 2026 om ongeveer 14:46 UTC.
Zakt de steun opnieuw naar 28 validators of lager, dan begint het hele proces nogmaals van voren af aan.
De XRP Ledger zelf heeft geen storing
Dat onderscheid is belangrijk.
Er is geen uitval van het netwerk en de bestaande transacties blijven gewoon doorgaan.
De vertraging zit uitsluitend in het proces waarmee nieuwe regels aan de blockchain worden toegevoegd.
Dat systeem is bewust traag.
Een protocolwijziging moet langdurige steun hebben voordat alle servers dezelfde nieuwe regels gaan gebruiken.
Wat doet BatchV1_1 eigenlijk?
BatchV1_1 laat gebruikers meerdere transacties samen in één Batch-transactie indienen.
Volgens de officiële XLS-56-standaard kunnen minimaal twee en maximaal acht inner transactions worden gecombineerd.
Die transacties mogen bovendien van verschillende accounts komen.
Dat maakt complexere handelingen mogelijk zonder dat iedere stap volledig los van de rest hoeft te worden uitgevoerd.
Maar niet iedere batch werkt op dezelfde manier.
Er bestaan vier uitvoeringsmodellen
XLS-56 definieert vier modi:
- All-or-Nothing: alle transacties slagen, of geen enkele blijft staan;
- OnlyOne: alleen de eerste succesvolle transactie wordt uitgevoerd;
- UntilFailure: transacties lopen door totdat de eerste mislukt;
- Independent: iedere transactie wordt los van de andere verwerkt.
Vooral All-or-Nothing is belangrijk voor atomic settlement.
Daarbij geldt echt: alles of niets.
Het is dus te breed om te zeggen dat iedere Batch automatisch volledig atomair wordt teruggedraaid.
Betaling en asset kunnen tegelijk bewegen
Neem een getokeniseerd financieel product.
Een koper moet betalen.
De verkoper moet tegelijkertijd het token leveren.
Met All-or-Nothing kunnen beide handelingen aan elkaar worden gekoppeld. Mislukt één kant, dan wordt de andere kant eveneens niet definitief uitgevoerd.
Dat verkleint het risico dat geld wel wordt verstuurd maar het financiële product niet arriveert.
Of andersom.
Precies voor zulke samengestelde financiële transacties kan Batch interessant worden.
BatchV1_1 heeft al een beladen voorgeschiedenis
De vertraging krijgt extra gewicht door wat eerder dit jaar gebeurde.
De oorspronkelijke Batch-versie bevatte een ernstige fout in de controle van handtekeningen.
Onder bepaalde omstandigheden had een aanvaller inner transactions namens een ander account kunnen uitvoeren zonder diens private key. Daarmee waren ongeautoriseerde betalingen theoretisch mogelijk.
De fout werd ontdekt vóór activatie op mainnet.
Er zijn daardoor geen fondsen via deze bug verloren gegaan.
Oude Batch werd volledig ingetrokken
Na ontdekking adviseerden ontwikkelaars validators om tegen de oorspronkelijke Batch te stemmen.
xrpld 3.1.1 schakelde zowel Batch als het bijbehorende fixBatchInnerSigs uit.
Daarna werd een gecorrigeerde versie gebouwd.
BatchV1_1 verscheen op 6 augustus in xrpld 3.3.0 en vervangt de oude implementatie.
Dat maakt de huidige vertraging iets anders dan een nieuwe bug.
Er is nu geen technisch probleem met BatchV1_1 gemeld.
De stemdrempel werd simpelweg tijdelijk niet gehaald.
Dat laat juist zien wat het amendmentsysteem doet
Voor gebruikers is tien dagen vertraging vervelend.
Voor het protocol is dit precies waarvoor het stemproces bestaat.
Een upgrade gaat niet live omdat ontwikkelaars een datum op een kalender zetten.
De datum ontstaat pas wanneer validators lang genoeg dezelfde wijziging steunen.
Daardoor kan een geplande activatie zelfs vlak voor de deadline verdwijnen.
BatchV1_1 bewijst dat nu in realtime.
9 oktober is nog altijd geen vaste lanceringsdatum
De markt kan 9 oktober dus niet als gegarandeerde activatiedag behandelen.
Het is de vroegst mogelijke datum.
De huidige steun van 30 validators biedt wat marge boven de vereiste 29.
Maar één of meerdere validators kunnen hun stem aanpassen of tijdelijk niet meetellen.
Zodra de geldige meerderheid wegvalt, wordt de datum opnieuw doorgeschoven.
Ook andere XRPL-upgrade liep vertraging op
BatchV1_1 staat niet alleen.
PermissionDelegationV1_1 verloor eerder eveneens zijn meerderheid en moest opnieuw aan een veertiendaagse periode beginnen.
Die wijziging staat nu op 29 van 35 stemmen en kan, als de steun blijft staan, op zijn vroegst op 8 oktober activeren.
Dat onderstreept hoe dynamisch het proces is.
Een ruime meerderheid vandaag biedt geen garantie voor activatie over twee weken.
Voor XRP-houders verandert vandaag weinig
De vertraging zelf verandert niets aan bestaande XRP-saldi of gewone betalingen.
BatchV1_1 voegt nieuwe mogelijkheden toe voor ontwikkelaars.
Het is geen verplichte migratie van XRP en gebruikers hoeven hun munten niet te verplaatsen.
De economische betekenis ontstaat pas wanneer applicaties Batch daadwerkelijk gaan gebruiken.
Vooral toepassingen rond tokenized assets, handel en gecombineerde betalingen kunnen daar baat bij hebben.
Nu telt iedere validatorstem opnieuw
De belangrijkste teller begon op 25 september opnieuw.
30 van de 35 validators stemmen momenteel voor.
29 zijn er minimaal nodig.
Blijft dat zo, dan kan BatchV1_1 op 9 oktober rond 16:46 uur Nederlandse tijd eindelijk live gaan.
Valt de steun opnieuw terug, dan schuift de datum weer op.
De code is klaar. De volgende test zit nu niet in de software, maar in veertien dagen onafgebroken validatorsteun.
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
