1. Less code. 2. Spend considerable time thinking about the design. 3. Only allow the user to interact with the protocol exactly how we expect. 4. Handle all cases, insolvent liquidations. 5. Avoid for loops (where possible). 6. Never use parallel data structures. 7. External Calls. a. DoS b. Gas Griefing c. return data d. reentrancy 8. Post-checks (invariant checks. 9. Documentation Thanks Owen for covering this up.
I took a break from auditing to build my own project for fun/learning after getting inspired by all the codebases I audited. I have a lot more respect for good devs who are security minded and can write condensed clean code. I had a fairly straightforward idea, and figured it would be like 200-300 LOC. I did all the mistakes, jumping in without a lot of thought on structure, and had to refactor its architecture many times. It's ~500 SLOC with very sound architecture and cleanliness now. There were so many edge cases and bugs that I thought of and fixed during the building phase though, which I'm proud of, and also gave ideas for audits. I realized that invariants can be one of the creative parts of auditing. During building I realized "Oh yeah, X should never change. Or Y should always be true". And they aren't all obvious immediately, and sometimes require deep understanding of the possible states and goal of the protocol.
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
1. Less code.
2. Spend considerable time thinking about the design.
3. Only allow the user to interact with the protocol exactly how we expect.
4. Handle all cases, insolvent liquidations.
5. Avoid for loops (where possible).
6. Never use parallel data structures.
7. External Calls.
a. DoS
b. Gas Griefing
c. return data
d. reentrancy
8. Post-checks (invariant checks.
9. Documentation
Thanks Owen for covering this up.
I took a break from auditing to build my own project for fun/learning after getting inspired by all the codebases I audited. I have a lot more respect for good devs who are security minded and can write condensed clean code.
I had a fairly straightforward idea, and figured it would be like 200-300 LOC. I did all the mistakes, jumping in without a lot of thought on structure, and had to refactor its architecture many times. It's ~500 SLOC with very sound architecture and cleanliness now. There were so many edge cases and bugs that I thought of and fixed during the building phase though, which I'm proud of, and also gave ideas for audits.
I realized that invariants can be one of the creative parts of auditing. During building I realized "Oh yeah, X should never change. Or Y should always be true". And they aren't all obvious immediately, and sometimes require deep understanding of the possible states and goal of the protocol.
100%
Invariant driven development is a very interesting idea
It will be interesting to know how Mutation testing works with less or verbose code.
Thank you Sir!
Ty for watching ser!
🔥