A big portion of code auditing is staring at the screen at someone else’s code, and asking yourself:
“Why did they do it this way? Is there something they know that I don’t know? Why is there nothing about this function in the documentation?”
If you are a lucky auditor, things start to make sense hours or days into the audit. Then you have to start writing up what you learned and what you found as risky behaviour (a.k.a. vulnerability). Then you move on to compiling all of them together in a representable manner into a report.
There is no easy way to estimate how much time you’ll need to be done with a code review. Is reading everything once enough? What if the code has integrated many yield-farming interest-bearing tokens with a double-sided market that incentives users for specific behaviour? How do you measure code auditing? Punch cards can’t do shower thoughts.
This video, simply, shows all the efforts the Diligence team members put into creating audit reports. Nothing on how much time they were reading the code, how much time they spent pair-auditing or in meetings discussing the ‘what ifs’.
To explain what this video is showing on a technical level, we commit all audit reports in a Git repository which is rendered to be what you see at https://consensys.net/diligence/audits/ . The flashes in the video are commits and all the dots are a file in this giant hive.
It’s beautiful to see the dynamics between the people at the heart of Diligence, how they all work in concert — sometimes bumping into each other — and merging conflicts.
No Rolex was worn during creation of these 115 audit reports.
For some technical reads on what an audit is and how you can be more prepared to get the most out of it, checkout the following articles: