While developing Turing-complete smart contracts it is always hard to assure the absence of significant bugs and errors. Decades of software development in modern computer industry have shown that software code executed on Turing-complete machines always has some bugs that get discovered only with time. This is not strange: being a dynamical system Turing-complete code will show chaotic behavior. As with any chaotic system, minimal difference in input parameters will lead to exponentially-different result with time, making it practically impossible to predict all possible system behaviors, since all possible input data can not be enumerated and tested beforehand.
Gödel looks at Turing-complete system as if it’s incomplete (source)
Arguably we can also take another example from Gödel theorems and later developments, showing that within any complex system there exist such true axioms that can not be proven to be true using the apparatus of the system itself. Thus, within Turing-complete code there could be true (working) solutions or patterns of behavior (exploits) which can not be detected with Turing-complete machine (another computer). [Not all mathematicians would strictly agree with this statement, though]. Also, we can not test all possible inputs to see all possible outcomes of computations due to the reason mentioned in the previous paragraph (the nature of dynamic systems). Thus bugs are inevitable and there is no way to detect all of them beforehand with any type of code audit or tests.When we work with common computers, whether it’s a desktop, laptop, mobile or enterprise mainframe, we have very strict address and code separation spaces at the level of the processing unit (CPU, GPU etc). Bugs appearing in the code can create damage only within this space, i.e. the damage is limited by (a) the cost of the computer itself, (b) information kept on it and (c) collateral damage related to functions performed by this computer in the real world (for instance if this computer operates some other system, bug in the code may destroy that system as well). So the damage is located, measurable — and thus can be insured. That’s why computers and software can be used in business: risks created by them can be controlled.As with Ethereum, or many other smart-contracts blockchains making ICOs these days, we have global execution and address space: one smart contracts in EVM can call method of any other smart contract or library and invoke operations across them. It is like if there were no threads within CPUs, no protected kernel/user modes for software in the OS, and all the world code was executed on a single processor! What would happen? The damage of a software bug would be unlimited: it would be able to affect all value of the entire computing network! That is the situation we have today with Ethereum.We can draw a very important conclusion from this:
Ethereum decentralizes only computing resource, but centralizes computations themselves, creating unmeasurable and uncontrollable risks
Let’s look at the recent past:
- The DAO hack;
- Parity multisig wallet hack happened in a library code, which spread damage across many businesses, startups and even investment funds;
- Multiple ICOs and Ethereum-based project hacks: one, two, three etc
- Serpent compiler vulnerability causing Augur project rewrite
- and so on…
So, within Ethereum (and possible future-release Turing-complete smart contracts) we can not measure possible damage, and thus, insure possible risks. This basically renders the system to be unusable for business, adding a lot of deep sense to the previous statements from Ethereum team that it is an early-stage highly experimental technology that should not be used by mission-critical business and production environments.
However, this is not an unresolvable problem. We will talk on the possible scenarios in our further publications. One of them — to separate computation space much like it is done in modern OSes and CPUs. Something like ships that are split inside into watertight compartments to reduce possible damage from water and limit risks. Another way — to introduce completely new contexts by taking analogy from natural systems and implementing robustness via cross-disciplinary samples from the living organisms: DNA and cellular expression system is a sort of Turing-complete machine, and special evolutionary protection has being developed to limit and reduce risks of “code hacks” within DNA itself. We will write more on this topic in our next publication about the proposed “Double-helix blockchain”, which will be used in our Pandora Boxchain technology. Stay tuned!