paint-brush
Why smart contracts still need human logicby@s_o_s
849 reads
849 reads

Why smart contracts still need human logic

by Oleg StrelenkoJune 14th, 2018
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

<em>Smart contracts automate the execution of simple agreements, but what happens when mistakes in code are made and transactions need to be altered or reversed? Smart Laws introduce human logic to situations, pairing current legislation with distributed ledger technology so that justice can be done and data returned to their rightful owners.</em>

Company Mentioned

Mention Thumbnail

Coin Mentioned

Mention Thumbnail
featured image - Why smart contracts still need human logic
Oleg Strelenko HackerNoon profile picture

Smart contracts automate the execution of simple agreements, but what happens when mistakes in code are made and transactions need to be altered or reversed? Smart Laws introduce human logic to situations, pairing current legislation with distributed ledger technology so that justice can be done and data returned to their rightful owners.

The advantages of distributed ledger technology are clear to see: immutable nature, increased security and elimination of intermediaries. The ways to realise these advantages are also pretty evident: via a special cryptographic algorithm and decentralisation. So if we do the maths and add smart contracts to blockchain, we have the ideal tool which guarantees trust between parties without having to use intermediaries.

But, somehow, it doesn’t work like that, and after the DAO was hacked it became obvious that a system built on the principle that “code is law” is missing a key element. Maybe it’s the “law” part that is missing, the law part which isn’t code?

Are smart contracts really smart?

First and foremost, I want to take just a moment to draw attention to the fact that — and this has been known for some time amongst programmers — “smart” contracts such as Ethereum are not smart at all.

They are no smarter than a toilet tank: if the water reaches a certain level, the fill valve shuts and when you flush the water, the flush valve opens to let the water through. The same with a smart contract: it is just a simple algorithm which fulfils a standard set of operations with a certain set of data, differing in no way from any computer script.

If we write out an algorithm on a piece of paper and then put it into code, it does not become smart.

The problem with immutability and autonomy of ledgers

Traditional requirements for immutability and autonomy of distributed ledgers is understood as something unilateral and matter of fact.

It’s true, blockchain technology guarantees data integrity for any transaction up to the current moment in time; any attempt to tamper with even a byte of the data in a validated block isn’t feasibly possible. However, anyone can make changes to the register by completing further transactions. Although to do this correctly would mean that the procedure for making changes should initially be provided for in accordance with specific network rules or laws.

So, let’s say that a distributed ledger network has a “law” which, when executed, is able to transfer any digital asset (token) from one account to another: i.e. there is a law which takes away the opportunity to steal assets since they can subsequently be returned back to the victim’s account.

A condition of activating such a law within the system could be dependent on a signature given by over half of the network (which is somehow acknowledged to have the right to vote). So as not to sit waiting for the results of everyone voting, one participant could be elected and given the authority to launch another special law which freezes the funds. For this we don’t need anything smart or even smart contracts, just a regular algorithm to solve a problem that has existed since the beginning of civilisation: legislature.

It’s worth noting that the in example above, the application of laws doesn’t contradict the immutable nature of the register, nor it’s autonomy or its decentralised attributes since none of the previous entries have been altered. The problem has been resolved by the network using specially designed laws which work above the system of protocols. In such a system, every code should have a law which controls it and a decision making system for the law’s execution, a system which is able to amend the consequences of coding flaws.

Network security

The code can only ensure security in the most simplest of cases where allowances for all behavioural scenarios have already been made. When one needs to use a code whose function will execute a complex action, safety can only be provided for by collective reasoning, i.e. the creation of a legislative system made up not just of laws, but also of the people that create them and execute them.

Naturally, the issue arises as to whether a person can make an error when making a conscious decision to sign off a malicious contract and freeze an account. Of course they can, but when compared to the possible consequence of inaction, an error leading to a contract coming to a halt is the lesser of two evils. A set of laws which are able to cancel decisions made on part of human error or which launch contracts correcting the situation, just as a law which describes the procedure for handing over authority (and this is all based on a democratic system of voting) will make the network ecosystem sustainable.

Decentralisation

The concept of decentralisation can be seen from several different points of view and on different levels. From a technical standpoint, decentralisation guarantees network integrity, meaning it can continue operating even where there is failure amongst a significant number of nodes. From an informational perspective, the lack of a single centralised place for data storage solves the problem of integrity. However, there is also a third level of understanding centralisation and decentralisation: the management/governance level where decisions are taken and responsibility is taken for those decisions.

It was this third level that was ignored when Ethereum and, correspondingly, the DAO were created. That’s why when Ethereum encountered their problem, there were only two ways it could go: leave it as it is or turn back the clock.

So, as you can see, it’s not all so straightforward with decentralisation. On the one hand, it ensures data integrity and accuracy; on the other, the lack of a centralised element which can take instantaneous decisions means the system isn’t at all protected from malice and mishaps which are in any case unavoidable.

Immutable code

The immutability of contract code implemented by Ethereum, just as with decentralisation, has two sides to it. Of course, it’s a great idea to have contract code that can’t be altered post factum by either party and will be executed with the inevitability of law. But on the other hand, even the most thoroughly thought through governmental law isn’t safe from error. Moreover, a programmed contract can have gaps in it, leaving it susceptible to malicious use. Furthermore, whilst governmental laws can be repudiated in court and laws henceforth amended, problems with immutable contracts such as those on the Ethereum network are only solved via rolling back the clock.

We should always start from the fact that any contract cannot exist purely on its own, outside of some kind of general rules or laws which regulate its application and make provisions for situations where it must be amended or annulled. Moreover, such provisions make sense: every code, every not-so-smart contract should submit to a higher law which comes into force where an unforeseen situation (in the code) takes place. If we really need something smart to solve a problem, there should be a provision in law for that: a system where a person may intervene and alter the code. We could call this system of intervention “Smart Laws”.

Intermediaries

One of the main advantages of distributed ledgers its disintermediation. A notary officer who validates a particular document at a specific moment in time can very easily be replaced by code: sign with a private key and seal in a block. But what about when the task is more difficult? For example, contractual relations (privity) that require strict regulation via governmental law?

In the majority of cases, the intermediary who was supposed to disappear with the introduction of distributed ledgers becomes not an intermediary between the contractual parties, but an intermediary between them and the state. Moreover, we can only really talk about disintermediation and reductions in transaction costs when transferring the entire state system onto the blockchain. Here I don’t mean a transfer onto a private blockchain just for its own government operations, but to a single inter-state blockchain platform.

A law is a law

Any contract, just as any other socially significant action, can be realised only within a special legislative system. Just as with each citizen of a state, each user of a distributed ledger network which employs so-called “smart contracts” should know the current legislation and submit to it.

The creators of a contract should be sure that their data is protected from falsification and loss, and the algorithm should be executed successfully. However, they should also understand that there will be extreme cases when the code of the law, which protects the interests of the system and its users as a whole, will snap into action. This should be done by applying the real “smarts” of a person who by law has the right to take an immediate decision and correct an error or make right an injustice.

If someone takes advantage of an error in a contract for their own personal gain, they should know that the law will come into effect, thereby revoking the negative consequences of the unauthorised action. Here we aren’t talking about revoking the action by deleting part of the register to travel back in time, but to execute a series of new transactions. This solution means that the integrality of the register is not compromised since changes will take place in accordance with a contract-law which already exists on the network.

So, code is not law: it does not solve a problem. Code, just like you or I, can only create problems. Moreover, law is not code, but instead is a way to incorporate human reasoning to solve a problem and rectify problems with code. By bringing a system of law to code and creating Smart Laws built on top of smart contracts, we have a regulatory system where judicial recourse can be taken and wrongs can be put right.