The complexity of handling assets safely in Ethereum has been exposed by TheDAO. I’d like to propose a change to Ethereum to increase safety for applications creators and users alike. The same proposal applies to all smart contract platforms and that can include non turing complete ones.
The fundamental issue is that Ethereum will protect assets of value yet it’s easy to accidentally or purposely include an exploit. Use of the exploit rewards the attacker, penalises users, and reduces trust in the overall system. Some may disagree but the system is supposed to work for users first and foremost.
If it doesn’t, how are we any different from the existing banking system which doesn’t care about the destruction caused by systemic failures, by error or design? I’d like a system which I can trust, yes, but also one which protects me. That’s speaking both as a user and an application developer.
I’d like to propose that Ethereum is tooled with standard asset holding and latching contracts (wallets essentially). These contracts would allow:
- Consensus based halt and emergency recovery. Edit: It’s up to users whether they trust those providing consensus, who may just be the developers, dao like curators, or formal arbitrators. (Note that users are already trusting the contract from the developers wrote and especially early on they can’t be sure of security, regardless of security reviews)
- Per user security controls, e.g. amount, withdrawal address, time, countersigning, recovery options
- Per application security controls for application withdrawals, e.g. D(A)O proposals, non solo splits, DO expenditure, royalties, ‘dividend’ payments
- Future: Arbitration
All assets should be held in contracts specifically designed to be highly limited in scope and, ideally, mathematically provable.
These contracts should be part of the standard toolkit, not just suggestions.
As well as the code, a human language intention of the contract should be expressed in full. Failure of any of these contracts should then be considered as an acceptable hard fork request since these should be considered as integral as the core protocol. These contracts should also include user wallets, and all of them should be natively supported by all wallet software.
The reasoning behind this is that the assets are the fundamental value that we care about. Ethereum has provided a wonderful system but it’s clear that it’s incomplete. Standard equivalents to hot and cold wallets, where application creators and users can be in control of their security, is something that decentralised platforms can do superbly well. This significantly reduces the chance of losses from both deliberately designed exploits and bugs, both of which are a deep concern.
As a result of the recent failure and should such contracts be viable technically, I firmly believe they should be a core part of Ethereum.
However, they will always be optional to use so contract authors who do not want those features can continue to operate as they wish. Think of it as using ethereum at a lower level. Anyone using such contracts then truly understands their risks.
Without them, I fear that generic smart contracts simply cannot be trusted. I also fear that we’ll be like Bitcoin where we see thefts galore and can do nothing about it, living in a deeply uncaring world I’m not comfortable with (and most of the world certainly wouldn’t be). By implementing protections within ethereum itself we can show the power of software but retain both a human aspect and empower individuals to choose their own security.
Update: From initial conversations it seems like it’s technically feasible for user controlled assets (ether, tokens) and possibly feasible in a sufficiently generalised for DAPPs. The latter may only result in template contracts that need minor amends for DAPP functionality rather than a fundamental contract with adjustable parameters, but that needs further research. It’s also important to understand that the parameters control the risk. Faulty logic and faulty set up can still cause errors but the wallet contract can limit the exposure.
It will also be easier to perform security reviews of the use of standard contracts which hold the assets. It may be impossible to predict the logic flaws of surrounding code, but it will be possible to evidence the risk of losses such that a human being can make a decision, including if they trust the arbiters to protect them.
The automation of asset transference has to be retained, so it’s about building in safeguards for when pre-agreed safe limits are breached. For example, this could be time based latches for all DAPP expenditure over a certain limit. For user wallets, it’s about supporting notions of multi-signature approval, latches to prevent more than agreed amounts moving per time period, and so on. This means there are also user experience considerations. With standard contracts in place containing a range of features, wallet developers can focus on UI.
Finally, developers are constantly told not to roll their own crypto. Managing assets of value on a blockchain should come with similar warnings. You can always do it but you better know what you’re doing. For everyone else, use the template contracts — and even they need handling with care.
