Preventing The DAO

A lot of talk exists about preventing The DAO with EOS, but there is little progress being made on realising that dream. Below I will present my proposal for preventing loss of funds from a smart contract when the code behaves otherwise than intended.

What was The DAO?

The DAO was a smart contract on the Ethereum platform which was created with the intention of funding new projects (essentially a crowdfunding platform).

What was different was that it was to be run as a Decentralised Autonomous Organization, an organisation designed to run itself democratically by stake-weighted vote of the token holders (does that sound familiar?). Rewards were to be allocated to the projects which received the most votes.

People sent Ether to the contract and they were returned DAO tokens. By mid-May 2016, the fund contained over $150M in ETH tokens and had attracted over 11,000 individual accounts to invest.

What happened?

On June 17th 2016, a bug was being exploited in the DAO smart contract which meant that anyone was able to request a withdrawal of funds from the DAO, even if they never invested. Luckily The bug could only drain a limited amount of funds at a time and white-hat hackers managed to recover a large portion of the funds in a race against the black-hats.

Eventually, Ethereum forked the entire chain (creating Ethereum and Ethereum Classic chains) to fix this problem. The underlying reason was that they could not update the smart contract to fix the small bug so they had to fork to remove the code.

This would be similar to block producers deciding to roll back the entire EOS mainnet because a bug was discovered in a single smart contract running on top of it.

How is EOSIO different?

Updatable code

EOSIO allows contract developers to update their smart contract if they choose, this means that when a bug is discovered, it can be fixed quickly. Instead of white-hat hackers fighting to save the funds, they would have updated the contract and the attack would stop.

Updatable code is one of the reasons I back EOS, as a developer I do not want to have to be woken up to discover that a bug in my code has drained all the funds of my customers.

Speed

When you have 0.5s block times and high throughput, tokens can move around very quickly. We have seen many instances of stolen funds moving around the network way more quickly than we can keep up with. Once funds leave the control of an account, they should be assumed to be gone forever.

Even with third parties trying to keep up, it is impossible to compete with an automated system splitting up funds (a recent attack on EOS split the stolen funds into thousands of accounts). This is even harder now that we can transmit value across EOSIO chains within minutes.

Permissions system and protocol-level time delays

One of the best features of EOSIO against any other blockchain is the permissions system. Many people are aware of owner and active keys but there are also accounts and waits which means you can configure very complex permissions.

Preventing tokens leaving

Once tokens leave control of the account, it is game over. We need to prevent unauthorised transactions from leaving the account in the first place.

Time delays on permissions are critical to this (do not confuse this with staking which is being used as an EOS-only feature). We must set a long enough time delay so that we can validate and cancel transactions.

A time delay only needs to be long enough for the systems which are verifying them, if the rules for transferring tokens are automatable then the delays can be very short.

An automated system detects a delayed transaction being entered onto the blockchain (time delays can be enforced at the core of EOSIO) and then it validates the action and if it fails the checks then it will cancel the transaction before it is allowed to execute.

Specific to preventing The DAO

The particular use case of preventing The DAO is much more simple than protecting individual user accounts. A smart contract is designed to only pay out tokens under very specific situations. If there is a clear specification on what the contract should do then external teams can write the validators, making it less likely that they will create the same errors. At worst, a bug in the contract AND a bug in the validator would cause funds to leave. Adding multiple independent validators would further decrease the risk of a mistake.

What happens when ALL validation fails?

At some point, all of the systems designed to protect property will fail and the tokens will leave control of the account. What happens then?

To answer that, we should look at the real world. To protect the assets in our home or business we use physical security measures such as doors, locks and alarms. When these fail (and they do regularly), we rely on insurance for reparation. The analogy with smart contracts which hold value is using time locks and external monitoring, then if those fail insurers can step in.

One day, insurers will be able to assess the risk of loss from a smart contract, they will even be able to verify the code being used to protect it before making a decision.