THAT parity wallet exploit

So, I have been quiet the past two weeks, mostly due to studies and work commitments, but I thought I would just quickly give my thoughts on the parity smart contract exploit as it is something that certainly caught my attention.

For the uninitiated, parity offers multi signature wallets locked into smart contracts. Now a smart contract at the end of the day is just code and not following secure practices will be a problem. And that is exactly what happened, a function that should not have been public was declared (default) public and therefore exposed. It was a bad coding error, but it is not the first time this has happened and certainly not the last. However, it would appear that hackers have gotten away with at least 30 million USD value in ether. An anonymous group that calls themselves the white hat group and the ethereum community though stepped in and restricted the damage by draining these same vulnerable contracts into a temporary holding wallet in order to secure the funds. They will be returning funds once the issue has been completely patched. These rescued funds total around 76 million USD. 

On the whole I am both impressed and appalled at the same time. Appalled because the smart contract code responsible for the exploit really is a howler. In short, the method responsible for the exploit is declared without any modifier so it defaults to public. It really is Solidity 101, here is an excerpt from consensys best practice document to illustrate it more clearly :

// bad

uint x; // the default is private for state variables, but it should be made explicit

function transfer() { // the default is public

    // public code

}

// good

uint private y;

function transfer() public {

    // public code

}

function internalAction() internal {

    // internal code

}

Reference : https://github.com/ConsenSys/smart-contract-best-practices/blob/master/README.md

Now, have a look at the bug fix which really was quite simple :

https://github.com/paritytech/parity/commit/e06a1e8dd9cfd8bf5d87d24b11aee0e8f6ff9aeb

The positive to come out of all of this is how well the community rallied to hunt down all the contracts with this exploit. Kudos to the white hat group, whoever they may be. 

Mostly though, I hope that we all learn from this. It is a given that something like this was going to happen at some point in time and it is a given that it will happen again. This is in many ways no different to a publicly exposed rest endpoint method containing a critical exploitable flaw - and that is a daily occurrence in various traditional systems worldwide. However, the aim should be to be better than traditional centralized systems, we should not make the same mistakes the corporate world is making by rushing out products that aren't ready. The Ethereum development community has a huge responsibility as far as that is concerned. We are off to a bit of a shaky start.

A few things I would like to see happen is the emergence of very robust and secure coding standards, bug bounty programs and proper review processes. Hopefully, Solidity v2.0 does a heck of a lot more to help protect the developer. And solid development and testing suites. In my mind, with the rapid growth and interest from the EEA it should be top priority to give us developers these tools. It should be possible to attract some of the best talent around with the funds that has been generated - there really is no excuse.

However at the end of the day, the tools can be as good as you want, but what is most important of all is to deploy your contracts ONLY WHEN READY. There should be no such thing as fixed timelines when it comes to development. In the corporate world this may not be the case, as a developer working in such an environment myself I know this well enough, but aren't we trying to build something better ?