Invarianten vor Contracts
Aufzuschreiben, was immer gelten muss, bevor man den Code schreibt, der es nie brechen darf, ist die billigste Smart-Contract-Sicherheit, die es gibt.
Normale Software hat ein nachsichtiges Verhältnis zu Fehlern. Man findet einen, behebt ihn, liefert aus. Ein ausgelieferter Contract, der fremdes Geld hält, kennt diese Nachsicht nicht: Ein Fehler ist kein Ticket, sondern ein Verlust — und er ist öffentlich.
Die Praxis, die Ergebnisse mehr verändert als jede andere, ist, zuerst die Invarianten zu schreiben. Bevor die Implementierung existiert, halten Sie die Eigenschaften fest, die immer gelten müssen. Das Gesamtangebot entspricht der Summe der Guthaben. Der Pool kann nie mehr auszahlen, als er hält. Keine Funktion lässt einen Aufrufer die Position eines anderen abheben.
So geschrieben werden die Eigenschaften ausführbar. Foundry führt sie als Invariantentests aus, wirft erzeugte Aufruffolgen gegen den Contract und versucht, sie zu verletzen. Das findet eine Fehlerklasse, die beispielbasierte Unit-Tests strukturell nicht finden können, weil Sie an die Folge nicht gedacht haben.
Der Effekt zweiter Ordnung betrifft den Entwurf. Eigenschaften, die sich schwer formulieren lassen, deuten meist auf einen Contract, der zu viel tut. Wenn Sie nicht ausdrücken können, was wahr bleiben muss, ist das das Signal, die Sache zu teilen — nicht, einen längeren Satz zu schreiben.
Nichts davon ersetzt ein externes Audit, und das sagen wir jedem Kunden, der darauf hofft. Es macht das Audit billiger und weniger beunruhigend, weil die Befunde, die es bis zum Auditor schaffen, die subtilen sind statt jener, die ein Eigenschaftstest schon in Woche eins gefunden hätte.