Invarianten vóór contracten
Opschrijven wat altijd waar moet zijn, vóór u de code schrijft die dat nooit mag breken, is de goedkoopste smart contract-beveiliging die er is.
Gewone software heeft een vergevingsgezinde verhouding tot bugs. U vindt er een, u herstelt die, u levert op. Een uitgerold contract dat andermans geld beheert kent die ruimte niet: een bug is geen ticket, het is een verlies, en het is openbaar.
De praktijk die uitkomsten meer verandert dan welke andere ook, is de invarianten eerst opschrijven. Voordat de implementatie bestaat, benoemt u de eigenschappen die altijd moeten gelden. Het totale aanbod is gelijk aan de som van de saldi. De pool kan nooit meer uitkeren dan die bevat. Geen enkele functie laat een aanroeper andermans positie opnemen.
Zo opgeschreven worden de eigenschappen uitvoerbaar. Foundry draait ze als invariantentests, gooit gegenereerde reeksen aanroepen tegen het contract en probeert ze te schenden. Dat vindt een categorie bugs die op voorbeelden gebaseerde unittests structureel niet kunnen vinden, omdat u niet aan die reeks had gedacht.
Het tweede-ordeeffect zit in het ontwerp. Eigenschappen die lastig te formuleren zijn, wijzen meestal op een contract dat te veel doet. Kunt u niet uitdrukken wat waar moet blijven, dan is dat het signaal om het op te splitsen, niet om een langere zin te schrijven.
Niets hiervan vervangt een externe audit, en dat zeggen we tegen elke klant die daarop hoopt. Wat het wel doet, is de audit goedkoper en minder alarmerend maken, omdat de bevindingen die de auditor bereiken de subtiele zijn in plaats van die welke een eigenschapstest in week één had gevangen.