Een storing bij Cloudflare legde deze week zwakke plekken bloot in Web3. Verschillende dapps waren tijdelijk moeilijk bereikbaar, ook voor gebruikers in Nederland en Europa. Oorzaak: veel diensten leunen op Cloudflare voor DNS, beveiliging en webgateways. De ketens van blokken zoals Bitcoin en Ethereum bleven draaien, maar de toegang voor gebruikers stokte.
Cloudflare als zwakke schakel
Cloudflare is een veelgebruikt bedrijf voor internetbeveiliging en verkeer. Veel Web3-sites gebruiken het voor DNS, caching en bescherming tegen aanvallen. Valt die laag uit, dan verdwijnen websites en API’s, ook als de onderliggende blockchain gezond is. Dat gebeurde tijdens de storing: front-ends waren weg, terwijl nodes gewoon produceerden.
Voor DeFi, wallets en NFT-marktplaatsen is dit een pijnlijk punt. Hun slimme contracten werken op de keten, maar gebruikers bereiken die contracten via webpagina’s. Als die pagina’s via één partij lopen, ontstaat een enkel storingspunt. De belofte van decentralisatie botst daar met de praktijk.
Ook Europese projecten bleken geraakt door dezelfde afhankelijkheid. Dat maakt incidenten grensoverschrijdend. Voor aanbieders in de EU wordt het daarmee een vraagstuk van continuïteit, niet alleen van techniek.
Een RPC-endpoint is een toegangspoort tot een blockchain. Apps gebruiken het om data op te vragen en transacties te versturen. Valt zo’n poort of de route ernaartoe uit, dan voelt de keten voor de gebruiker “offline”, ook als die gewoon draait.
RPC en gateways kwetsbaar
Veel dapps gebruiken centrale RPC-aanbieders om met Ethereum (ETH) of andere ketens te praten. Die aanbieders zitten vaak achter Cloudflare voor bescherming en routing. Bij een storing kunnen verzoeken naar de blockchain tijd uitlopen of falen. Het resultaat: “wallet kan geen netwerk vinden” of een vastlopende app.
Daarnaast hosten veel teams hun statische bestanden via CDN’s zoals Cloudflare. Denk aan de webapp, scripts en stijlbestanden. Als die niet laden, komt de interface niet op. De slimme contracten zijn er nog, maar de gebruiker ziet een lege pagina.
Iets soortgelijks speelt bij IPFS-gateways. Bestanden staan gedistribueerd, maar publieke gateways zorgen voor de webtoegang. Als de gatewayketen afhankelijk is van één infrastructuurpartij, is “decentrale opslag” in de praktijk toch centraal bereikbaar.
Front-ends blokkeren toegang
De meeste gebruikers bedienen DeFi en wallets via een browser. Zij typen een URL in of klikken op een link in de wallet. Een DNS- of CDN-storing breekt die route af. Zonder alternatief kanaal is de drempel om direct met een node te praten te hoog.
Geavanceerde gebruikers kunnen via een eigen node of een andere RPC-provider transacties indienen. De gemiddelde gebruiker kan dat niet. Hierdoor concentreert het risico zich bij de weblaag. Dat maakt adoptie kwetsbaar, zeker tijdens marktstress.
Exchanges en brokers hebben vaak redundantie, maar ook zij gebruiken externe beveiligingslagen. Bij storingen nemen wachttijden toe en vallen sommige functies uit. Dit raakt liquiditeit en vertrouwen, ook als Bitcoin (BTC) en Ethereum (ETH) zelf stabiel blijven draaien.
Nederlandse eisen aan weerbaarheid
Voor Nederlandse aanbieders groeit de druk om storingsbestendig te opereren. MiCA brengt regels voor cryptodienstverleners, met aandacht voor governance en incidentprocessen. Daarnaast treedt in de EU de DORA-verordening voor digitale weerbaarheid in werking, die de lat voor kritieke ICT-risico’s verhoogt bij financiële partijen. Dit maakt leveranciersrisico en uitwijk een bestuursthema, geen puur technisch detail.
Gebruikers in Nederland merken vooral de praktische gevolgen. Inloggen lukt niet, balances laden traag, of swaps falen. Dat onderstreept het belang van statuspagina’s, heldere updates en alternatieve ingangen. Transparantie verkort de onzekerheid en beperkt paniek.
Toezichthouders letten bij incidenten op continuïteit en klantcommunicatie. Partijen die afhankelijkheden spreiden en scenario’s oefenen, herstellen sneller. Dat scheelt reputatieschade en mogelijke klachten.
Zo beperk je uitval in Web3
Bouwers kunnen hun risico’s spreiden met meerdere DNS- en CDN-providers. Ook helpt het om front-ends via verschillende paden aan te bieden, zoals alternatieve domeinen en IPFS met meerdere gateways. Voor de ketenverbinding is multihoming met verschillende RPC-providers en regio’s zinvol. Een eigen light- of full node als fallback geeft extra zekerheid.
Voor gebruikers zijn er enkele praktische stappen. Sla contractadressen en officiële alternatieve URL’s op. Gebruik wallets die meerdere RPC’s ondersteunen en schakel tijdig over. Controleer altijd statuspagina’s voordat je opnieuw probeert of hoger gas geeft.
- Gebruik meerdere RPC’s in je wallet-instellingen.
- Bewaar een offline lijst met officiële domeinen en alternatieven.
- Controleer statuspagina’s van dapps, wallets en RPC-providers.
- Overweeg een eigen light node of trusted RPC via een Europese aanbieder.
De storing toont vooral één les: decentralisatie vraagt ook om gedecentraliseerde toegang. Zonder redundantie in de weblaag blijft Web3 afhankelijk van één schakel, hoe robuust de keten zelf ook is.
