A proposal for safer contracts: More redundancy, less complexity.

The last minute ENS postponement should remind us that we still don't have adequate procedures for dealing with bugs, even more than half a year after the DAO incident.

More testing and validation is good, but it's not good enough for a system where even a single obscure bug can have disastrous consequences.

Peter Borah's fault-tolerant contract idea is even better, but there is a fundamental problem with this idea: By adding more complexity to the contract, you risk introducing even more bugs in addition to the ones you are trying to mitigate.

I propose the following architecture:

1. Create a "guard contract" that wraps around your "operational contract". Its sole purpose is to block transactions originating from the operational contract. Ideally, the guard contract should be simple, generic, and part of a standardized library.

2. Write 3 copies of your operational contract, for example, one in Solidity, one in Serpent, one in LLL. Ideally, they should be written by different teams of developers.

3. Run the 3 copies in parallel. When you send Ether, you split it into 3 equal parts and send an equal amount to each individual contract.

4. Withdrawals can only happen via the guard contract. It imposes a series of conditions such as "If, within a certain time window, recipient_from_solidity == recipient_from_serpent == recipient_from_lll Then allow transaction Else send funds to a recovery account".

5. Communication with the guard contract is designed to be one way. It can receive messages and transactions from the operational contracts, but it cannot send them back. This is to eliminate causal interdependence between the operational
   contracts.

Benefits:

• Lower probability of critical bugs, since a bug needs to be replicated in 3 independent code bases.

• By separating the guard contract and keeping it simple and generic, it will be easy to peer review and harden.

• Even if an attacker finds a bug that bypasses the guard contract, they will only be able to steal 1/3 of the funds (other variations of how to split up the funds are possible).

• By keeping the subsystems more isolated from each other, the system as a whole has less complexity than a single contract packed with safety features.