Thread by @moo9000

1/ CAN #DEFI SMART CONTRACTS EVER BE SAFE?

Is it possible to write bug-free software?

No spoilers, to get the answer you need to read this thread on Twitter *NOW*, before Muskalypse starts.

#infosec #ethereum

👇👇👇

2/ #DeFi keeps scoring higher and higher in the value of "hacks", counting losses in dozens of millions of dollars. This will make the users legitimately worried.

3/ But not just users as "heists" make great headlines that the press likes to tout, often missing the positive benefits, or "innovation" in blockchain and #defi industries.

4/ In this thread, we look at the security aspect of DeFi and this aspect only.

The security (or lack of it) is the next argumentation point for "DeFi can never happen" folks after we get over the argument "DeFi does not create anything valuable".

5/ For the value creation argument, public blockchains and decentralised finance can create fundamental value, not just speculative value and negative effects.

For insight into what this value is please read my blog post here:

tradingstrategy.ai/blog/most-effi…

6/ So let's divulge the details of the interesting question "WYAAAAAR DEFI CAN NEVER BE SAFE REGULATE REGULATE PONZI HACK NORTH KOREA SANCTIONS LAZARUS GROUP SCAM RUG I HOPE ALL DEFI BURNS" argument.

7/ CAN YOU WRITE BUG-FREE SOFTWARE?

👇👇👇

8/ Yes. See my screenshot.

9/ Now when we have gotten "no bug free software can exist" out of the way, let's dice the bugs a bit more. Hakuna matata.

10/ The argument "no bug free software exists" often comes from software developers. Often this argument comes from software developers that have never written smart contracts themselves.

11/ "no bug free software exists" argument is not a mature opinion; It is very easy to write simple software without any bugs (see above). It is harder to write complex software without bugs.

The wrong question is "is it not possible". The right question is "how hard is it"?

12/ Smart contract programming is closer to embedded programming (automotive/aero/space/toasters) than traditional programming which most of the software developers are familiar with.

Also, smart contracts are closer to math than programming.

13/ Real #DeFi products are "protocols". Protocols entail a small core, with a number of limited rules and equations.

The core of Uniswap v2 protocol is here, around 400 lines of code:

github.com/Uniswap/v2-cor…

14/ I bet any senior software developer agrees that you can write 400 lines of code without any bugs. Which is the case. Uniswap v2 has never been "hacked". Uniswap v2 and its derivates have transacted billions of dollars of volume.

tradingstrategy.ai/trading-view/e…

15/ Furthermore, unlike in real-world industries in the meat space, smart contracts are deterministic.

You do not need to deal with failing analogue inputs or components. No sandstorms blocking your solar panel or no failing integrated circuits.

16/ Smart contracts also can be often mathematically proven to be right.

This is called formal verification.

Here is an example of formal verification of "Ethereum 2.0" deposit contract :

daejunpark.github.io/deposit.pdf

17/ Also, attack vectors are well-known at this point - new attack vectors are getting rare after 6 years of smart contract evolution. Makes the job easier when you know the enemy.

An example security check list:

ethereum.stackexchange.com/questions/8551…

18/ I DO NOT BELIEVE YOU; HACKS STILL HAPPEN. PROVE ME THEY DO NOT HAPPEN.

👇👇👇

19/ I have $150B reasons to say writing secure #DeFi is possible.

Here is a list of some of the "blue chip" projects that have "never" been hacked.

20/ (First, let's define hack as "losing a significant amount of money that makes headlines and kills the project due to the programming error".)

21/ DeFi bluechips

- makerdao.com
- curve.fi
- aave.com
- uniswap.org

22/ Then we have popular ERC-20 token contracts that have $100B assets tied to them

- USDT tether.to (might be questionable for other reasons, but not for technical security)
- USDC circle.com

Never hacked.

23/ So writing an unhackable ERC-20 token contract is definitely possible.

24/ Then we have Bitcoin that has never been hacked (at least since not after 2010):

en.bitcoin.it/wiki/Value_ove…

25/ Note that the same "never hacked" argument can be applied to centralised cryptocurrency exchanges. There are exchanges that have never been hacked, although their users have been: Kraken, Coinbase.

26/ A lot of crypto would have already disappeared to North Korea by Lazarus group if it were possible to take it.

27/ BUGS STILL HAPPEN.

Don't take me as a fool, as I have written software for 25 years.

Then we mitigate.

28/ Risks can be managed with a framework.

A risk framework comes down to only a few factors

Risk
- likelihood
- impact
- mitigations
- residual (after mitigations)

29/ *Likelihood*: In long term, it is a game of statistics, like the insurance business. We can say numbers like bugs per line of code and so on.

30/ *Impact*: Protocols governing millions and billions of dollars need less residual risk (more mitigations) because the impact would be larger.

Also, they have more money to pay for the mitigations.

Nobody cares if your school project gets hacked.

31/ *Mitigations*: Have a solid software development process. We discuss this in a bit.

32/ *Residual*: After the risk mitigations, the likelihood of a bug number should go so low that we never get hit any bugs during our lifetime.

33/ WHAT DOES SECURE SOFTWARE DEVELOPMENT LOOK LIKE?

But maybe it is just a miracle these protocols have not been hacked yet?

No, it's all about mitigations and good risk management.

👇👇👇

34/ As impact goes up (millions, billions dollars) better to suit you up and make sure you do your development well.

How to write bug-free software?

With patience, slowly, a lot of ceremony and people.

35/ Linus's law is the assertion that "given enough eyeballs, all bugs are shallow".

Increase your eyeballs to code ratio. It's easier if the core protocol is small (unlike in e.g.embedded sw dev.)

36/ Key factors

- High-quality software development process
- External independent audits
- Open source bug bounty programs
- Risk management framework

37/ A lot of this is summarised in this excellent presentation by @Corpetty

docs.google.com/presentation/d…

38/ For more technical discussion on "how to build software securely" happy to engage more, so ping me if you need hints or want to cricitize.

39/ Some projects like MakerDAO and Aave have risk committees which also look at factors outside pure software:

makerdao.world/en/learn/gover…

40/ My current grief with #DeFi projects is that there is little mitigations reduce the impact of realised risks - like hacks.

41/ The lack of speedbumps helps attackers to get outsized rewards, like in the case of Wormhole and Ronin hacks.

If withdrawal speeds were limited, the impact would have been lesser.

42/ I STILL DO NOT BELIEVE YOU. PROJECTS GET HACKED EVERY DAY. INVESTORS LOST MONEY ON A SCAM TOKEN PROMOTED BY KIM KARDASHIAN.

A good point. If it is so well known how to build high quality, bug-free, unhackable #DeFi why do the hacks still happen?

👇👇👇

43/ The short answer is: "arrogance" and "greed".

The projects get hacked either because they underinvest to high quality software development practices vs. to the impact of the realised hack risk.

44/ Before we go further, let's first discard

- Did not have money to do this at the beginning

We are not interested in small hacks, because if you have a high quality project with a growing AUM, rising capital to cover security is easy.

45/ Cap the AUM growth until mitigations/impact is correct.

Have a budget number e.g. 5% of free cash flow or $1M/year to spend on security.

46/ This leaves us big hacks that did not have sufficient risk framework in place. Two main reasons. to get hacked:

- Do not want to invest in security in the first place, because the management does not plan to stay around (are here just to cash easy VC money for lifestyle)

47/ Or....

- Now have the money, but are too busy to party

48/ For example, the Ronin bridge hack is an example on how to lose $500M lose because of your arrogance.

rekt.news/ronin-rekt/

49/ VCs often call this "scaling too fast" but for me the security always comes first, because established actors know the risks of blockchain industr. If you under invest in security someone more capable should replace you and your business in long run.

50/ What happened with Ronin? They disregarded some the core of the cryptographic security principles that have been in place since 80s.

51/ - No risk management framework - They did not even realised money was gone until 5 days later.

52/ - Not open source and transparency - third parties could not vet if the sound software development practices were followed.

53/ - No true decentralisation - compromise of one party (Sky Mavin) lead loss to all the capital

- They even knew about the compromise, but still did nothing

54/ Because Ronin/Axie Infinity/Sky Mavis is large they can raise equity capital to cover losses of users. But incompetent founders should be diluted away in this process.

55/ Another similar story is Aku NFT auction where they lost $42M.

56/ The auction smart contract was neither audited or not professionally written. No open source on Github, no evidence of solid software development practices followed.

57/ People were even reaching out to the team on Discord and begging them to stop the auction, because they saw bugs in the contract.

58/ Aku team ignored them with "Trust us, we know what we are doing."

Obviously they didn't know.

59/ HAHAHA YOU JUST PROVEN DEFI IS NO SECURITY NIGHTMARE AGAINST YOUR ORIGINAL ARGUMENT

👇👇👇

60/ Not really. To get exposure to unsafe #DeFi projects you need to work hard.

It's unlikely you can buy them at Coinbase.

61/ It's not like 90s predatory pink sheet stock marketing (Wolf of the Wall St). People are not calling your grandma and ask her to put money on this new NFT auction using her Metamask.

62/ To get to be exposed to risky stuff where you can lose money, you really need to learn about DeFi and work hard for it.

In this process, you learn about the rule "Beyond this line it's going to be high risk. Only invest capital you can afford to lose."

63/ So don't be salty when you lose your money. There is always risk/reward ratio and you, like DeFi projects themselves, need to manage the risk. Not all investments can make profit (see startups/NASDAQ tech stock.)

64/ Although DeFi hacks happen, the hacks are not a significant % of the overall market. It's similar to credit card business - there is always % of the fraud of overall market.

[NUMBER CITATION NEEDED PLZ]

65/ For comparison, the UK COVID-19 relief loan program saw GBP 20B loss because of fraud and errors, from £260bn - £370bn overall.

theguardian.com/world/2022/feb…

66/ Compared to Boris's numbers, DeFi security is doing really really well.

And it will do better in the future, because the industry matures, we get over of the bootstrap hick-ups and bad actors get cleaned out.

67/ One can be still skeptic. It is ok to be cautious and critical about DeFi, and I even encourage this. Some things only mature and become less risky over time. But it is very incorrect to say secure DeFi cannot exist now, or in the future.

68/ FIN.

GM.

Thank you for the @RektHQ for inspiring me to write this thread and for their non-disclosed sponsorship.

69/ Ps. Subscribe to my *new* newsletter

newsletter.tradingstrategy.ai

Pps. More about losing money in TradFi. And this is your tax money, not magical DeFi money.

archive.ph/carsS