One of the design philosophy that help the airline industry to achieve such a high safety record was the "redundancy philosophy".

Each critical computers are designed to be fully redundant. That mean each computer is equiped internally with two independents channels: COM and MON for command and monitoring (channels are physically independent cards within the computer unit, each computers are actually two independent ones).

Each channels are designed and developed by two completely independent team.

This is to prevent a bug/unwanted behavior, two independent teams are very unlikely to implement the same bugs.

Each time the redundant computer do any computation, the result from both channel is compared. If there is any discrepancies the computer stop and go in "fault" mode to prevent any non-standart behavior/command.

My question is:

Could this concept help to prevent bugs/vulnerability in smart contracts? (Like we have seen with the DAO event)

It would require the smart contract to be coded by two independent team and every request executed by the said smart contract will have to go trough "smart contract channel A" and then trough "smart contract channel B" the result compared and only executed if both channels give same result.

It seems very unlikely that two independent team end up coding the same vulnerability.

(I will also double the gas cost if I understand well)

Does this kind of concepts exist in software development (redundancy)?

Sorry fro my English I am not a native speaker.

  • Simple question: did this redundant system ever fail? – Oleg V. Volkov Jun 22 '16 at 17:55
  • In software development usually there's no redundancy. It is expensive, you will need twice the resources because you can't have the same team develop two different systems. In critial system usually a team develops following well stablished standards. And a completely different team (or more than one) validates the job, their job is to try to break the system. And in those systems often validation may tak as long as development. – Ismael Jun 22 '16 at 19:30
  • True, it is more expensive and resourceful. But in the case of a smart contract that once out in the wild cannot be modified and hold massive value, it might make sense (to prevent as much as possible any deviations or non-standart "behaviors".) (sorry if I don't use the proper terminology, I am not a coder) @Ismael – ant Bldel Jun 22 '16 at 20:00
  • 1
    The ethereum virtual machine doesn't work like that. But I see how your approach can be implemented. A coordinator contract, and two or more evaluators contracts. For each operation the coordinator asks the evaluators, if all of them give the same result the operation can proceed. – Ismael Jun 23 '16 at 9:46
  • 1
    But I still prefer the method with a formal verification. The advantage of Ethereum is that operations are reproducible and deterministic. You formally verify the operations from contract really do what was intended to do. @antBldel – Ismael Jun 23 '16 at 9:53