David Schwartz: XRPL-hub draait na manifest flood weer ‘rock solid’ met piek van 423 verbindingen
423 gelijktijdige verbindingen en bijna geen geregistreerd misbruik. David Schwartz, een van de oorspronkelijke architecten van de XRP Ledger, zegt dat zijn private XRPL-hub na weken sleutelen weer stabiel draait.
Dat is relevant na de manifest flood die eind juli grote aantallen verbindingen tussen XRPL-servers wegdrukte. De XRP Ledger zelf bleef tijdens dat incident echter transacties verwerken en consensus houden.
Schwartz ziet twee weken stabiele verbindingen
De telemetrie die Schwartz deelt loopt van 25 augustus tot en met 8 september.
Zijn hub hield in die periode grofweg 400 verbindingen tegelijk vast. De piek lag op 423 peers.
In een van de metingen waren 135 inkomende en 271 uitgaande verbindingen zichtbaar. De latency kwam uit rond 165 milliseconden.
Een tijdelijke uitschieter op 6 september tikte ongeveer 1,49 seconde aan. Volgens de gedeelde gegevens had die piek geen zichtbaar effect op consensus.
Ook de indicator die Schwartz als Abuse volgt, zakte vrijwel naar nul.
“Rock solid.”
Twee lege stukken in zijn grafieken zouden volgens Schwartz bovendien door een fout in de monitoring zijn ontstaan. Niet doordat de hub zelf uitviel.
Waarom honderden peerverbindingen ertoe doen
XRPL-servers praten rechtstreeks met andere servers via het peer-to-peerprotocol.
Via die verbindingen worden transacties, ledgerdata en informatie voor consensus gedeeld. De officiële XRPL-documentatie beschrijft deze peerlaag als de belangrijkste communicatieroute tussen servers.
Een hub helpt andere servers peers te vinden en verbindingen te onderhouden.
Dat betekent niet dat één hub de XRP Ledger bestuurt. Het betekent wel dat storingen in deze communicatielaag veel andere servers tegelijk kunnen raken.
Precies daar ging het eind juli fout.
Manifest flood joeg peers van elkaar los
Op 30 juli begon een enorme hoeveelheid validator manifests door het netwerk te stromen.
Zo'n manifest koppelt een validatoridentiteit aan de publieke sleutels waarmee die validator zich kenbaar maakt. Het systeem gebruikt deze berichten onder meer wanneer validators hun tijdelijke signing keys wijzigen.
Volgens het officiële XRPL-rapport werden grote hoeveelheden synthetische revocation-only manifests verspreid.
De servers verwerkten niet alleen die ongewenste data. Ze gaven de berichten ook weer door aan andere peers.
Daar zat de pijn.
Wanneer een server eenmaal veel rommel in zijn cache had staan, kon hij die bij nieuwe verbindingen opnieuw verspreiden. Verbindingsproblemen veroorzaakten daardoor nieuwe verbindingen, die weer nieuwe golven manifests konden uitlokken.
Een zichzelf versterkende lus.
Veel nodes verloren binnen minuten het grootste deel van hun peers. Ook servers rond Ripple en XRPSCAN werden getroffen.
Ledger bleef draaien
Dat onderscheid is belangrijk.
Volgens het officiële postmortem stopte of forkte de XRP Ledger niet. De overgebleven validators hielden consensus vast.
Er werden door deze manifest flood ook geen private keys buitgemaakt. Het rapport meldt evenmin verlies van fondsen of aantasting van ledgerdata.
Het probleem zat vooral in beschikbaarheid en overbelasting van de peerlaag.
Dat is iets anders dan het kraken van het consensusmechanisme of het leegtrekken van een wallet.
Een netwerk kan dus ernstig worden gehinderd terwijl de onderliggende ledger correct blijft werken.
Hotfix zette harde grenzen op manifestdata
De ontwikkelaars reageerden binnen een dag.
Op 31 juli verscheen xrpld 3.2.1, een noodupdate voor de reference server van XRPL. De release staat openbaar op GitHub.
De aanpassingen legden grenzen op aan drie plekken waar die eerder ontbraken: de grootte van individuele manifests, het aantal manifests per bericht en de hoeveelheid niet-vertrouwde data in de cache.
Operators kregen daarnaast het advies hun server na de upgrade gecontroleerd opnieuw te starten. Daarmee kon eerder opgeslagen ongewenste manifestdata worden verwijderd.
De eerste grenzen bleken vervolgens op sommige punten te streng.
Tijdens de flood kon legitieme informatie van nog niet vertrouwde validators daardoor eveneens worden weggedrukt. In xrpld 3.3.0, uitgebracht op 6 augustus, werden die instellingen aangepast.
Het doel was simpel: schadelijke hoeveelheden data afremmen zonder normaal peerverkeer onnodig te blokkeren.
423 verbindingen zijn geen audit van heel XRPL
Daar moet de nieuwe update van Schwartz ook stoppen.
Zijn grafieken laten zien dat zijn private hub twee weken lang honderden verbindingen kon vasthouden. Dat is een bruikbaar praktijkbeeld na de patches.
Het bewijst niet dat iedere XRPL-server wereldwijd dezelfde prestaties levert.
Een validator in een ander datacenter kan andere verbindingen, hardware, configuraties en verkeerspatronen hebben. Netwerkgezondheid beoordelen op één hub zou daarom te makkelijk zijn.
De XRPL-ontwikkelaars zijn zelf ook nog niet klaar. In het postmortem noemen ze bredere filtering van binnenkomend verkeer, throttling, backpressure en betere telemetry als vervolgwerk.
De manifest flood is dus technisch onder controle gebracht, maar heeft ook blootgelegd waar de peerlaag harder begrensd moet worden.
Walletincident rond XRP staat hier los van
Die nuance telt extra nu er ook vragen spelen rond een afzonderlijk beveiligingsincident bij XRPH Wallet van XRP Healthcare.
XRP Healthcare meldt zelf dat digitale diensten tijdelijk niet beschikbaar zijn vanwege beveiligings- en herstelwerk na het recente walletincident.
Dat zegt niets over een nieuwe fout in het XRPL-protocol.
Een walletapp kan bijvoorbeeld verkeerd omgaan met gevoelige sleutels terwijl de onderliggende blockchain normaal functioneert.
Andersom kan de communicatielaag tussen nodes onder zware belasting komen zonder dat gebruikers hun private keys verliezen.
De term “XRP-hack” verbergt dat verschil.
Bij de manifest flood lag het probleem tussen servers. De nieuwe cijfers van Schwartz laten zien dat zijn eigen hub na de patches weer ongeveer 400 peers tegelijk aankan.
423 verbindingen zijn geen bewijs dat ieder risico verdwenen is. Ze zijn wel het eerste harde praktijkbeeld dat de serverlaag die eind juli onderuit werd geduwd, op deze hub weer normaal werk levert.
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
