Waarom is de beveiliging van slimme contracten anders dan gewone softwarebeveiliging?

De beveiliging van slimme contracten is anders, omdat de code openbaar is, vaak rechtstreeks geld beheert en na ingebruikname meestal niet meer kan worden gewijzigd. Een fout in een webapp kan in één nacht worden verholpen; een fout in een contract kan worden ontdekt door iedereen die de code leest en worden misbruikt voordat het team wakker wordt. Ethereum.org schat de verliezen door fouten in slimme contracten op meer dan een miljard dollar en noemt de DAO-hack uit 2016 als een vroeg voorbeeld.

Neem een fictieve studio met vier medewerkers, Larkspur Labs, die een eenvoudige gezamenlijke spaarpot bouwt waarin leden geld storten en hun aandeel opnemen. Ontwikkelaar Kofi laat vóór de ingebruikname deze controlepunten achter: 'withdraw verstuurt geld en zet daarna saldo op 0. setFee is openbaar, beperk toegang later. gebruik oude compilerversie uit handleiding. prijs van beloningstoken uitgelezen uit één kleine handelspool. tests: één keer handmatig storten + opnemen geprobeerd, werkt'. Elke regel is een bekend type kwetsbaarheid.

Wat zijn de meest voorkomende kwetsbaarheden in slimme contracten?

De meest voorkomende kwetsbaarheden in slimme contracten zijn gebrekkige toegangscontrole, manipulatie van prijsorakels, logische fouten, ontbrekende invoercontroles en herintreding. Deze staan bovenaan de OWASP Smart Contract Top 10 voor 2025. Ethereum.org behandelt dezelfde hoofdcategorieën.

Herintreding

Een contract maakt geld over of roept een ander contract aan voordat het zijn eigen administratie bijwerkt. Een kwaadwillende ontvanger roept het contract opnieuw aan terwijl het oude saldo nog zichtbaar is, en neemt opnieuw geld op. De opnamefunctie van Kofi, die uitbetaalt voordat het saldo op nul wordt gezet, is het klassieke voorbeeld. De gebruikelijke oplossing is om eerst de toestand bij te werken en pas daarna met andere contracten te communiceren. Dit wordt vaak controles, effecten, interacties genoemd.

Toegangsbeheer

Gevoelige functies die iedereen kan aanroepen. Met de openbare functie setFee van Kofi kan iedere buitenstaander de vergoeding wijzigen. Ethereum.org beschrijft patronen zoals een eigenaarsrol, rolgebaseerde toegang en goedkeuring met meerdere handtekeningen.

Overloop en onderloop van gehele getallen

Rekenkundige overloop: zodra een grens wordt overschreden, begint de waarde aan de andere kant van het bereik, waardoor een saldo onder nul een enorm getal wordt. Ethereum.org vermeldt dat Solidity 0.8.0 en later dit standaard afwijzen, terwijl oudere code expliciete controles nodig heeft. Daarom is de oude compiler van Kofi van belang.

Manipulatie van orakels

Een prijs aflezen uit één markt met weinig liquiditeit die een aanvaller kan beïnvloeden, vaak met een flitslening: een lening die binnen één transactie wordt afgesloten en terugbetaald. Robuuste ontwerpen gebruiken gedecentraliseerde orakels of tijdsgemiddelde prijzen.

Logica- en validatiefouten

Regels die niet overeenkomen met het beoogde ontwerp, of invoer die nooit wordt gecontroleerd, zoals een nulbedrag of een onverwacht adres.

Hoe testen en controleren teams slimme contracten?

Teams testen en controleren slimme contracten in meerdere lagen, omdat geen enkele methode alles opspoort: geautomatiseerde tests, analysetools, uitrol naar een testnetwerk, onafhankelijke beoordeling en, bij contracten waarin aanzienlijke waarde is vastgelegd, een externe audit en beloningen voor het melden van kwetsbaarheden.

1. Eenheidstests en eigenschapstests

Schrijf tests voor elke functie, ook voor situaties met kwaadwillende invoer, zoals een ontvanger die de functie opnieuw aanroept. Bij fuzzing worden automatisch duizenden willekeurige invoerwaarden uitgeprobeerd.

2. Statische analyse

Ethereum.org noemt hulpmiddelen zoals Slither, Mythril en Aderyn, die code scannen op bekende risicovolle patronen.

3. Test netwerken

Implementeer eerst op een openbaar testnetwerk voordat u naar het hoofdnetwerk gaat. Ethereum.org beveelt Sepolia aan voor de ontwikkeling van toepassingen en contracten; ether op een testnetwerk hoort geen echte waarde te hebben, dus fouten kosten niets.

4. Beoordeling door vakgenoten en gecontroleerde bibliotheken

Gebruik versiebeheer, onafhankelijke beoordelaars bij elke wijziging en grondig beoordeelde bibliotheken zoals OpenZeppelin Contracts, in plaats van toegangsbeheer helemaal zelf te schrijven.

5. Audit, beloning voor gemelde kwetsbaarheden en monitoring

Onafhankelijke audits zorgen voor extra controle, maar vinden niet elke fout, zoals ethereum.org opmerkt. Beloningsprogramma's voor het melden van kwetsbaarheden, noodstopfuncties en monitoring van gebeurtenissen helpen de resterende risico's af te dekken.

Hoe ziet een zwakke beveiligingsbeoordeling eruit, en hoe een verbeterde?

Zwakke beoordeling: 'Storten en opnemen handmatig getest, werkt goed, klaar voor ingebruikname.' Een test van het normale verloop laat zien dat het contract werkt voor eerlijke gebruikers, en dat zijn aanvallers nu juist niet.

Verbeterde beoordeling: Herintreding: withdraw zet het saldo nu op nul voordat er wordt overgemaakt, en een test probeert met een kwaadaardig ontvangend contract opnieuw de functie aan te roepen. Toegangsbeheer: setFee is beperkt tot een eigenaarsrol uit een geaudite bibliotheek, met een test die controleert of een aanroep door een buitenstaander mislukt. Compiler: bijgewerkt naar een actuele 0.8-versie, zodat overloopcontroles zijn ingeschakeld. Orakel: de prijs uit één liquiditeitspool is vervangen door een gedecentraliseerde prijsfeed, met een plausibiliteitsgrens voor plotselinge schommelingen. Testen: unittests, een fuzztest en een statische analyse waarbij elke bevinding is toegelicht, gevolgd door twee weken op Sepolia waarin een collega probeert het contract te laten falen. Er is een externe audit ingepland voordat er echt geld wordt geaccepteerd.

Wat zijn veelgemaakte fouten bij de beveiliging van slimme contracten?

De meest voorkomende fout is alleen het verwachte verloop testen, alsof iedereen die het contract aanroept eerlijk is. Andere fouten: beheerdersfuncties openlaten om ze later te beperken, code uit een handleiding met een verouderde compiler overnemen, op één prijsbron vertrouwen, een audit als garantie zien, de testnetfase overslaan en uitrollen zonder plan om te pauzeren of bij te werken.

Waar staat deze les binnen Tosheo.ai?

Dit is een programmeerles in de categorie Blockchain en de blockchaincursus. Deze gratis pagina legt elke stap in tekst uit; de volledige praktijkversie, waarin u echte contractcode controleert en verbetert en tests uitvoert op een testnetwerk, vindt u na aanmelding in het optionele programmeertraject. Begin met de uitleg over slimme contracten als de basis nieuw voor u is. Tosheo.ai is geen voltijds intensief opleidingsprogramma en leidt niet op tot professioneel auditor. Niets op deze pagina is beleggingsadvies; contracten waarin echte waarde is ondergebracht, vereisen een specialistische audit.

Bronnen en reikwijdte

ethereum.org, beveiliging van slimme contracten (gecontroleerd op 19 oktober 2026) ↗

OWASP top 10 voor slimme contracten, 2025 (gecontroleerd op 19 October 2026) ↗

ethereum.org, netwerken en testnetwerken (gecontroleerd op 19 oktober 2026) ↗