The Problem

In our previous publication “Turing, Gödel and Chaos in Smart Contracts: why bugs are inevitable and why it is a much bigger problem for Ethereum than for any other computer” we have discussed the reasons why Ethereum and other Turing-complete smart contracts can not be considered as business-ready. The takeaway from that text is the following:

Ethereum [at the present state] decentralizes only computing resource, but centralizes computations themselves, creating unmeasurable and uncontrollable risks. <…> Within Ethereum (and possible future-release Turing-complete smart contracts) we can’t measure possible damage, and thus, insure possible risks.

Existing Solutions

Are there any ways to mitigate these risks and resolve the problem? Smart contracts and Ethereum are very promising for disrupting many industries, driving the 4th Industrial revolution, so it would be great if we would be able to find a way to “fix” its “genetic bug” of computation centralization that creates a single point of failure within the core of the system itself.

Certainly, there could be a number of possible approaches. One is to limit the value at risk: amount of money (ether or tokens) on the contract address. Being suggested in official Solidity documentation this approach is not very well suited for real business applications and represents rather “patch” then a “feature” :)

Plasma.io proposition by Joseph Poon and Vitalik Buterin could be seen as a further development of the same line of thoughts. It proposes to put the risks outside of the main Ethereum chain into something that can be thought as an analogy to Lightning channels in Bitcoin, additionally creating some check- and reverse-points that can be used to restore the system state if a hack was revealed. However, this still needs to be implemented in a real-world system and before such implementation it is hard to estimate would it really provide a tool for risk mitigation or create more controversy and debates alike those arose following The DAO hacks and hard-fork “reversals”.

Taking Examples From Life and Evolution

Here we propose another approach: to take an analogy from natural systems and introduce robustness via cross-disciplinary analogy from the living organisms. There, DNA and cellular protein expression works like a sort of Turing-complete machine, and a special protection from bugs (like mutations) has been developed evolutionally, limiting and reducing risks of the “code hacks” within DNA itself. What is this system? It’s a famous “double helix” of DNA molecule and a special reparation machinery that uses duplicated information in DNA helixes to repair possible damaging mutations before they affect the cell functioning.

At the very early stages of evolution life was “working” on single-stranded RNAs, and was very vulnerable to mutations, data loss etc. After some millions of years passed, evolution had “found” a double-stranded RNA analogy (DNA itself), which appeared much more robust and stable and was adopted by most of the living organisms today (or even by all of them, if we do not count RNA viruses as “living organisms” :).

Proposed Double-Stranded Ledger Architecture

Our proposition is to adapt a similar strategy and create architectures based on two independent implementations (called “strands”) done using different contracts, languages (Solidity and Viper), or even different blockchains. Thus, three possible “DNA” options for smart-contracts are available (called “double-stranded ledgers” or DSL):

1. Double-Stranded Contracts (DSC): two contracts implementing the same business logic are written by different developers or teams implement the same functionality (business logic), but in different ways.
2. Double-Language Contracts (DLC): two contracts implementing the same business logic are written using different languages of the same platform (Serpent and Viper in case of Ethereum). This will allow to reduce risks not only from human errors, but also from compiler bugs, which already had put at risks some of the real-world projects like Augur.
3. Double-Stranded Blockchains (DSB). For those apps that do not require Turing-completeness one may use Ethereum and OMNI Layer; others may wait until other Turing-complete projects would go live (Rootstock, EOS, Aeternity and others) and implement their solution on top of both.

One may ask: “Wait a minute, but how we would synchronize/compute the state of a such double-stranded ledger?” It would require another level on top, which will represent the state of the system to the external observer. In case of double-stranded contracts and double-language contracts it will be represented by a separate minimalistic smart-contract in the same blockchain (Ethereum), that will report the state of the system only if it is represented in both of the underlying “strands” exactly the same (for instance, both underlying smart contracts reports the same balance for some address); otherwise this contract will report “failed” state and a special fallback mechanism will be activated.

For double-stranded blockchains possible architecture will be more complex. A separate offchain code is required, that must work on the side of both blockchain full nodes and interact with both of them, providing clients with the synchronized state information via some API. Thus, a full node for double-stranded blockchains will actually consists of the two full nodes for the selected blockchains plus this additional standalone code (see the image on the side).

How Will Tokens Work?

Tokens, existing in double-stranded ledger systems will be presented as two “half-tokens” of underlying smart contacts (A and B), each of which would have no value by itself. The real value would be virtually “held” in the synchronized information created by the top-level minimalistic contract or standalone code, which would create the “holistic” token from those “halves”.

If a hacker would find a bug in one of the contracts (A) and stole an amount of “half-tokens A”, the top-level contract will come into “failed” state and would provide the ability to return stolen tokens without hard forks of the blockchain(s) — like one of DNA strands can be repaired from a mutation by using the “state” of the second DNA strand.

As for Ethereum-based double-stranded or double-language contracts this could be seen as a three ERC20-token contracts: two (“A” and “B”) with the same business logic holding “half-tokens”, and the third one (top-level) without the token, but with ERC20 interface presenting “holistic token” to the external world.

Estimating Risk Reduction

Lets assume that probability (P) of some given Smart Contact (c) having a bug is proportional to the amount of the contract features (V):

P(c) ~ V(c)

Then, for double-stranded ledgers the probability of the bug in each of the underlying contracts A and B will be respective:

P(A) ~ V(A); P(B) ~ V(B)

However, the probability that the same feature of the business logic has a bug in both contracts at the same time is a multiplication of probabilities P(A) * P(B), that results in multiple-fold reduction of the risk.

For instance, if the probability of a bug in contracts A and B is 10% per feature, then probability of the same bug in the same feature in the both contracts will be only 1%, which reduces risks tenfold. However, the usual normal risks for a bug per feature are kept at levels <1%, which means that the corresponding risk in double-stranded implementation will be reduced 100-fold and more.

Liked the article? Don’t forget to subscribe to Event Horizons on Facebook and Twitter. We have also started a project that implement Artificial Intelligence computations on top of Blockchain technology, called Pandora Boxchain. You can read more about it in recently published white paper.