Audit je fotografija, test suite je navika

Audit smart contracta pregledava jednu verziju koda, u jednom trenutku, a pregledavaju ga ljudi koji ga nisu napisali. To je vrijedan posao i to je ujedno fotografija. Ne govori ništa o sljedećem commitu, a kod će ih imati mnogo.

Što audit ne pokriva

Nakon isporuke reporta kod se i dalje mijenja. Digne se dependency, prilagodi se fee parametar, doda se funkcija za jednog klijenta, deployment skripta se izmijeni u zadnji čas. Nijednu od tih promjena ne opisuje dokument star tri mjeseca. Audit ostaje istinit za verziju koju je pregledao, a o verziji koja je stvarno deployana govori sve manje sa svakom promjenom od tada. To je obični život svakog codebasea i zato jedan datiran izvještaj ne može biti jedini dokaz da se ugovor ponaša kako treba. Pitanje koje revizor treba postaviti nije postoji li audit, nego koliki dio deployanog koda on još opisuje.

Tri vrste testova koje nose audit dalje

Unit testovi provjeravaju svaku funkciju zasebno i čine osnovu. Fork testovi pokreću ugovore nad kopijom stvarnog stanja chaina, pa se integracija s već deployanim protokolima provjerava, a ne pretpostavlja. Invariant testovi izriču svojstva koja moraju vrijediti što god se dogodilo: zbroj balansa jednak je ukupnoj ponudi, nitko ne može podići više nego što je uplatio, pauzirani ugovor ne prima transfere. Fuzzer zatim generira nizove poziva koji ta svojstva pokušavaju slomiti, uključujući nizove na koje nitko iz tima nije pomislio. Alati poput Foundryja i Hardhata podržavaju sva tri stila.

Testovi i za ono što nije logika ugovora

Mnogi incidenti u produkciji dolaze iz deploya i upgradea, a ne iz logike koju je audit pročitao. U suite stavite deployment skripte, argumente constructora i initializera te upgrade put. Sve pokrećite u continuous integrationu na svaku promjenu, tako da invariant koji pada zaustavi release jednako kao što bi to učinio neuspjeli unit test u bilo kojem drugom projektu.

Kako iskoristiti auditora

Tražite od auditora da svaki finding preda kao reprodukciju i pretvorite ga u test koji pada prije nego ga popravite. Finding koji postane test ne vraća se neprimijećen. Pitajte i koje je invariante pretpostavio dok je čitao kod te ih zapišite kao testove. Nastaje suite koji bilježi što je audit naučio, pa sljedeći revizor kreće odatle, a ne od nule. Za tvrtke u regiji koje rade za strane klijente i partnere to je i dokaz: partner neće pitati samo imate li audit, nego i što se dogodilo nakon njega.

Pravilo je kratko. Audit je prekretnica, a test suite je proces. Koji invariant vašeg ugovora danas nije zapisan kao test?