Door AI gegenereerde slimme contracten: waar ze helpen, waar ze tekortschieten en hoe je ze veilig kunt gebruiken.

Door AI gegenereerde slimme contracten kunnen de afstand tussen een idee en werkende Solidity-code verkorten, maar dat gemak verandert het risicoprofiel van de ontwikkeling in plaats van het te elimineren. De sterkste toepassing is momenteel niet "vraag een model om een ​​contract en implementeer het". Het gaat erom AI te gebruiken als assistent binnen een gedisciplineerd engineeringproces dat specificaties, tests, toegangscontrole, keuzes voor afhankelijkheden, audits en implementatiebeheer nog steeds als menselijke verantwoordelijkheden beschouwt.

Dat onderscheid is belangrijk omdat slimme contracten activa kunnen bevatten en onomkeerbare statuswijzigingen kunnen afdwingen. De beveiligingsrichtlijnen van Ethereum, voor het laatst bijgewerkt op 26 februari 2026, benadrukken dat het moeilijk of onmogelijk is om de code van geïmplementeerde contracten direct te patchen en bevelen onafhankelijke beoordeling, testen, statische analyse, compilerwaarschuwingen, documentatie en zorgvuldige toegangscontrole aan. De huidige beveiligingsrichtlijnen voor slimme contracten van Ethereum blijven daarom een ​​nuttige basislijn, zelfs wanneer code met behulp van AI wordt gegenereerd.

Wat is er veranderd met de ontwikkeling van slimme contracten met behulp van AI?

De belangrijkste verandering is de snelheid. Een ontwikkelaar kan nu een escrow-regeling, een vesting-schema, een NFT-minting-regel, een rollensysteem, een stakingcontract of een testcase in begrijpelijke taal beschrijven en binnen enkele seconden een plausibele implementatie ontvangen. Modellen kunnen ook onbekende code uitleggen, randgevallen suggereren, unit-tests genereren, vertalen tussen frameworkpatronen en helpen bij het documenteren van interfaces.

Wat niet is veranderd, is de beveiligingslast. De eigen beveiligingsdocumentatie van Solidity waarschuwt nog steeds dat contracten interageren met kwaadwillende aanroepers, openbare statusinformatie, externe contracten, compilergedrag en uitvoeringsomgevingen, wat tot onverwachte resultaten kan leiden. De beveiligingsaspecten van Solidity blijven de nadruk leggen op re-entrancy, risico's van externe aanroepen, openbare zichtbaarheid van de status en het belang van patronen zoals Checks-Effects-Interactions.

Een preprint uit 2026 getiteld "Evaluating the Vulnerability Landscape of LLM-Generated Smart Contracts" rapporteerde terugkerende ernstige gebreken in contracten die door verschillende huidige taalmodellen werden gegenereerd. Omdat het een preprint betreft en geen definitieve industriestandaard, moeten de exacte bevindingen niet worden beschouwd als universele foutpercentages. Het is echter wel nuttig bewijs voor een praktische conclusie: syntactisch geldige en functioneel complete AI-output is niet gelijk aan productiegereed beveiligingsniveau.

Waar levert AI de meeste waarde op?

1. Snelle prototyping

AI is met name nuttig wanneer het doel is om snel ontwerpopties te verkennen. Een team kan een minimaal escrow-contract vergelijken met een op rollen gebaseerde versie, een upgradebare versie of een pull-payment-ontwerp voordat ze zich vastleggen op één architectuur. Dit kan de kosten van vroege experimenten verlagen.

Het nadeel is dat prototypes vaak essentiële controles weglaten die in de productieomgeving van belang zijn: logica voor noodpauzes, expliciete rolgrenzen, gebeurtenisdekking, foutmodi, upgradeautorisatie, tokencompatibiliteit of afhandeling van uitzonderlijke gevallen. Hoe sneller het prototype wordt gemaakt, hoe belangrijker het wordt om te voorkomen dat aannames uit het prototype ongemerkt in de productieomgeving worden overgenomen.

2. Standaardformuleringen en algemeen bekende normen

AI kan tijd besparen op repetitieve code wanneer het gewenste gedrag al overeenkomt met vastgestelde standaarden. Het kan bijvoorbeeld helpen bij het samenstellen van een ERC-20- of ERC-721-implementatie met behulp van vertrouwde componenten, in plaats van de basislogica voor tokens helemaal opnieuw op te bouwen.

Hier is de keuze van de bibliotheek van belang. OpenZeppelin beschrijft zijn huidige Contracts-pakket als een bibliotheek met door de community goedgekeurde componenten voor standaarden, machtigingen en herbruikbare bouwstenen voor slimme contracten. De documentatie maakt ook onderscheid tussen gecontroleerde stabiele releases en ontwikkelingsreleases. Zie de OpenZeppelin Contracts-documentatie . Voor veel productieprojecten is het veiliger om AI te vragen goedgekeurde bibliotheekcomponenten samen te stellen dan om de AI te vragen equivalente primitieven helemaal zelf te bedenken.

3. Hulp bij het opstellen en beoordelen van toetsen

AI kan effectief zijn bij het genereren van standaard unit tests, vijandige scenario's, eigenschappenideeën, documentatie en beoordelingschecklists. Het is ook nuttig om uit te leggen waarom een ​​verdachte functie kwetsbaar zou kunnen zijn en om aanvullende tests voor te stellen met betrekking tot toegangscontrole of externe aanroepen.

De beperking is dat AI-gebaseerde beoordeling precies de belangrijkste fout in de bedrijfslogica kan missen. Een model kan bijvoorbeeld een re-entrancy-fout herkennen, maar niet begrijpen dat de economische aanname, de prijsbron, de boekhoudkundige volgorde of de governance-overgang van een protocol onjuist is. Onderzoek uit 2025 toonde ook aan dat op LLM gebaseerde kwetsbaarheidsdetectie kan leiden tot zowel valse positieven als een lage recall voor sommige moderne Solidity-zwakheidsklassen. Dit is een reden om AI-beoordeling te combineren met uitvoeringsgebaseerde tests, statische analyse, fuzzing, invarianten en beoordeling door experts, in plaats van deze te vervangen.

Welke veiligheidsrisico's zijn het belangrijkst?

De OWASP Smart Contract Top 10 voor 2025 noemt kwetsbaarheden in toegangscontrole, manipulatie van prijsorakels, logische fouten, ontbrekende invoervalidatie, re-entrancy, ongecontroleerde externe aanroepen, flash-loan-aanvallen, rekenkundige problemen, onveilige willekeurigheid en denial-of-service-aanvallen als belangrijke categorieën van zwakheden in slimme contracten. De volledige lijst is beschikbaar via het OWASP Smart Contract Security-project . Door AI gegenereerde code kan elk van deze categorieën tegenkomen; er is geen aparte uitzondering op de beveiliging omdat de broncode door een model is geproduceerd.

Is AI veiliger wanneer het gebruikmaakt van vertrouwde bibliotheken?

Meestal wel, maar alleen als de integratie correct is. Het gebruik van bestaande componenten kan de hoeveelheid aangepaste, beveiligingsgevoelige code verminderen, wat waardevol is. Het garandeert echter niet dat rollen, parameters, overerving, initialisatie, upgradelogica of externe integraties correct zijn.

Denk bijvoorbeeld aan toegangscontrole. OpenZeppelin merkt op dat toegangscontrole bepaalt wie mag minten, stemmen, transfers bevriezen of andere gevoelige acties mag uitvoeren, en biedt zowel eenvoudige eigendomsmechanismen als meer gedetailleerde, op rollen gebaseerde mechanismen. De documentatie over toegangscontrole maakt duidelijk dat de keuze van het mechanisme moet aansluiten bij de toepassing. AI kan Ownablesnel een contract invoegen, maar een protocol met meerdere beheerders, vertraagde bewerkingen, noodrollen en governanceverantwoordelijkheden heeft mogelijk een meer gestructureerd autorisatiemodel nodig.

En hoe zit het met opwaardeerbare contracten?

Upgradebaarheid brengt een duidelijke afweging met zich mee. Onveranderlijke contracten beperken de mogelijkheden voor een beheerder om het gedrag na de implementatie te wijzigen, maar maken het ook moeilijker om defecten te herstellen. Upgradebare proxysystemen maken het mogelijk om bugs te verhelpen en functies te wijzigen, maar brengen wel beperkingen met zich mee op het gebied van opslagindeling, geprivilegieerde upgradepaden, initialisatieregels en governance-risico's.

De huidige upgrade-documentatie van OpenZeppelin legt uit dat proxy-gebaseerde upgrades het proxy-adres en de status behouden tijdens het wisselen van implementaties, en waarschuwt dat de opslagindeling niet willekeurig kan worden gewijzigd. Dit is een lastig gebied voor blinde AI-generatie, omdat code die er op zichzelf redelijk uitziet, de status kan beschadigen wanneer deze als upgrade wordt gebruikt. Als upgradebaarheid vereist is, gebruik dan tools die de opslagcompatibiliteit controleren en zorg voor een reviewer die het proxy-model begrijpt.

Welke ontwikkelingsaanpak past bij welke behoefte?

Hoe moeten teams door AI gegenereerde contracten beoordelen?

Begin met de vereisten, niet met de code. Beschrijf wie elke gevoelige functie mag aanroepen, welke activa worden verplaatst, wat altijd waar moet blijven, welke externe contracten betrouwbaar zijn, hoe prijzen worden verkregen, wat er gebeurt bij een storing en of het contract kan worden geüpgraded. Vergelijk vervolgens de gegenereerde code met deze vereisten.

Behandel de uitvoer vervolgens alsof het code is van een nieuwe bijdrager wiens werk nog niet is beoordeeld. Compileer met een geschikte, stabiele compiler, los waarschuwingen op, voer unit tests uit, test de invoer met fuzzing-functies, test invarianten, gebruik statische analysetools, controleer externe aanroepen, inspecteer machtigingen en verifieer de versies van afhankelijkheden. De huidige beveiligingsrichtlijnen van Ethereum bevelen expliciet versiebeheer, beoordeling van pull-requests, statische analyse, builds zonder waarschuwingen, documentatie en onafhankelijke beoordeling aan vóór implementatie.

Scheid tot slot het opstellen van een contract van de goedkeuring ervan. De persoon of het systeem dat een contract opstelt, mag niet het enige mechanisme zijn dat bepaalt of het veilig is. Bij contracten met een hoge waarde is onafhankelijke beoordeling een controlemechanisme, geen bureaucratie.

Wanneer moet door AI gegenereerde code worden afgewezen in plaats van gerepareerd?

Herschrijven is vaak beter dan patchen wanneer de gegenereerde architectuur moeilijk uit te leggen is, onnodige complexiteit bevat, incompatibele patronen combineert, afhankelijkheden verzint of niet netjes kan worden gekoppeld aan een geschreven specificatie. Beveiligingsbeoordeling wordt lastiger omdat beoordelaars meer tijd besteden aan het achterhalen wat de code probeert te doen.

Een kleiner contract, opgebouwd uit bekende componenten, heeft wellicht de voorkeur boven een complex, gegenereerd ontwerp dat niemand in het team met vertrouwen kan onderhouden. De Solidity-documentatie beveelt al lange tijd aan om contracten klein en begrijpelijk te houden, juist om deze reden.

Hoe weet je dat AI het ontwikkelingsproces verbetert?

Meet de resultaten die er echt toe doen. Nuttige indicatoren zijn onder andere een kortere tijd om gecontroleerde code te produceren, een grotere testdekking, meer geïdentificeerde randgevallen vóór de implementatie, minder beoordelingscycli voor routinewerk en betere documentatie. Gebruik "aantal gegenereerde regels code" of "tijd tot eerste compilatie" niet als belangrijkste succesindicator; beide kunnen verbeteren terwijl de beveiligingskwaliteit verslechtert.

Houd ook bij welke problemen zich voordoen: defecten die na beoordeling zijn gevonden, kwetsbaarheden die tijdens het testen zijn ontdekt, terugdraaiingen van implementaties, noodpauzes en bevindingen uit audits. Als AI het coderen versnelt, maar tot ernstigere bevindingen tijdens de beoordeling leidt, moet de workflow worden aangepast.

Kortom

Door AI gegenereerde slimme contracten zijn het meest nuttig als versnellingslaag voor ontwikkelaars die al een veilig ontwikkelproces hebben. Ze kunnen repetitief werk verminderen, prototyping versnellen, tests uitvoeren, code uitleggen en teams helpen alternatieven te verkennen. Ze zijn het minst betrouwbaar wanneer ze worden beschouwd als een autonome beveiligingsautoriteit of als een vervanging voor het begrijpen van de bedrijfslogica.

Voor kleinschalige experimenten kan AI een groter deel van het ontwerpwerk overnemen. Voor productiesystemen met een aanzienlijke waarde is de veiligere afweging beperkter: laat AI helpen met code en analyse, terwijl mensen verantwoordelijk blijven voor specificaties, architectuur, machtigingen, keuzes met betrekking tot afhankelijkheden, testen, audits, upgrades en implementatie. De maatstaf voor succes is niet of het contract compileert. Het is of het contract precies doet wat de bedoeling was onder ongunstige omstandigheden, en of het team dat met bewijs kan aantonen.