A beginner's guide to Ethereum development: Part 2
This post is a continuation of the first post, if you haven't given that a read yet, go for it! I'll try to delve a bit more in-depth in this particular post so best to keep some resources handy.
Reducing the attack surface
This is one of the most common phrases you'll hear in smart contract audits, and for good reason - and it's the same reason you wear your seat belt when driving or carry a parachute when skydiving. There's an interesting principle that applies to literally everything that happens, Murphy's law, it's not a law in the strict sense of the word's meaning but the law has probably been proven so many times in the entire life of every single human being that "prevention is better than cure" and "a stitch in time saves nine" are childhood sayings for most of us. The same applies here.
Anyway, on that note, let's take a trip through history.
Story time
There was a DAO, called The DAO (think of it as the OG DAO), that came into being on 30th April 2016. Hot off the press after a 28-day crowdsale, the entire ecosystem couldn't wait to see what came of this new autonomous and mostly decentralized being, it was being pitched as the next step in Web3, heck, even the word Web3 wasn't popular then probably. To give you an idea of how big this was, according to The Economist, the DAO had nearly 14% of the entire ether supply then, about $150 million of value at that time.
Soon after, in May, there was a paper released that talked about some vulnerabilities in the contract. In June, an Ethereum developer on GitHub pointed out recursive call vulnerabilities, which subsequently got blogged by the then founder of the Blockchain Foundation, a couple of days later. The DAO realizing that this might just be a real deal decided to rectify this right away (or soon enough, depending on your perspective) and on June 14th, they do the right thing and propose the fixes for governance approval, in the truly decentralized way.
On June 17th, 2016, the DAO contracts were exploited using a combination of vulnerabilities, including the one concerning recursive calls, that resulted in the transfer of 3.6 million ether, over one-third of what they owned and valued at around $50M then. Too little, too late?
But hey they thought of this, kind of? Timelocks were in place so it meant that they wouldn't actually have access to the funds until a while later. In this amount of time, the Ethereum community was in two minds, was it really fair they got blackhatted out of their crypto? And was it right that they would have to change the immutable nature of blockchain to undo the hack? Eventually, the widespread consensus was for a hardfork, with a relatively small number continuing on the historical chain, now called Ethereum Classic.
But that aside, let's talk about what "reducing the attack surface" actually entails.