A few months ago I wanted to figure out what the whole hyip was about: bitcoin, tokens, smart contracts, ICO. With bitcoin, everything was relatively simple, because there is a wonderful bitcoinbook book.
With smart contracts it was more complicated. As it turned out, the cause is not the most successful name. When we hear the word "contract", the legal meaning of the term comes to mind: a contract between two or more parties. And such an understanding of smart contracts has the right to exist, but the essence of the phenomenon is much broader, and the contract is not the most interesting and important case.
In the wake of the popularity of ICO we are talking about government regulation. I am not a fan of either the state or regulation, but I must admit that the state is one of the most important institutions, and one cannot do without it. Nevertheless, it seems to me that the community has focused its efforts on the particular case of the problem, and not the most important one. The technology in question, if properly applied, can change beyond recognition in many areas of life. Instead of looking at an isolated ICO case and coming up with an “analogous” regulation with an IPO, it’s worth taking a more systematic approach.
When a new technology appears, and it is not quite clear how to apply it, there is a temptation to focus on the old models. So it was with smartphones: the first versions of Windows Mobile smartphones tried to fit the desktop operating system interface into a small screen; with icons, mouse and the start button. Such smartphones could be used, but the real revolution happened when the developers realized that the smartphone is not a small computer, but something fundamentally different, and user interaction should be based on completely different models.
A continued analogy with a smartphone: smart contracts are not “self-executing contracts.” To understand how they fit into our lives, you need to figure out what they are after all, and then carefully think about how their properties can be used for your own benefit.
Immediately make a reservation that I do not pretend to be an expert in this field. The purpose of this text is to set out my vision and stimulate dialogue. It may well be that in some place I said nonsense or missed something very important. In that case, welcome to the comments.
The second disclaimer relates to the technical features of blockchain systems. For simplicity, I suggest that all the stated warranties of these systems are indeed fulfilled. We consider conceptual issues of application, therefore, vulnerabilities, shortcomings and weaknesses of specific implementations are left out of the box - this is a topic for a separate discussion, in which I am not qualified to participate. In addition, when I use words like "impossible", they actually mean "very expensive in terms of time and resources." The blockchain guarantees are probabilistic in nature, therefore they are “guarantees” in a practical, not logical sense of the word.
First, I want to offer to forget the word "contract" and look at the phenomenon from a respectful distance.
Imagine that you have a computer. It works just like the computers we are used to. On it you can run programs written in special programming languages. However, it has several important features:
- it cannot be stopped or destroyed
- it ensures that program instructions are executed exactly as the developer wrote them down.
- anyone who has access to the Internet can use it
- each program knows exactly which user is accessing it, that is, no user can impersonate another
- programs can interact with other programs just like users
In most existing implementations, there is another property: each user sees what is happening "inside" programs, that is, a computer cannot hide private information. However, this is not a fundamental principle, so I placed it outside the main list.
What does a program running on such a computer look like? The program has two parts: data and rules for changing them. The computer guarantees that the data will not be changed, unless there is a rule that allows this.
For a person not familiar with programming, the above is likely to bring little clarity, so consider an elementary example.
You are a manufacturer of bags in the premium segment. Everyone knows that the biggest parent of such companies and their customers is fakes. Well, we have a solution.
We launch a program on our computer that looks like this:
What happens next? Then we, the manufacturer, transfer the bag to the wholesale warehouse, changing the owner to the "Wholesale warehouse". A representative of the store arrives at the wholesale warehouse, and the warehouse sells the bag to the store and changes the owner in an electronic certificate to "The shop of indecently expensive bags."
A customer comes to the store looking for a bag. Wanting to protect himself from fakes and other unpleasant surprises, he checks his computer and sees the following:
The bag has the number
349587 , the customer sees it. The manufacturing company has indeed announced that it has released a bag with such a serial number, because no one else can pretend to be Horns and Hoofs. And, most importantly, there is a continuous chain of transfer of goods, from the manufacturer of bags and to the store.
The customer does not trust the store. There is a suspicion that the store owner is more profitable to sell a convincing copy made by the hands of powerless workers in some hot country. But the client trusts the manufacturing company and the system guarantees.
One could argue: why not sew a fake with serial number
349587 ? You can do this, but in order to sell it later, you need to be the current owner of a genuine bag, which makes no economic sense if you sell bags.
So, the client now knows that the bag is genuine and was not stolen.
Despite the fact that this example is a toy, it demonstrates one of the most important possibilities of smart contracts: to register the right of ownership and reliably transfer it between owners.
Blockchain systems are often called trustless, that is, allowing users to interact without trusting each other. This is true in some particular cases (Bitcoin), but in most situations, trust is still required. In the counterfeit example, we must trust the manufacturer. The system allows you to extend this trust further along the chain.
In the example above, two parallel processes occur. Ownership moves from the manufacturer to the final consumer, and the money moves in the opposite direction. It would be convenient to combine these two components.
Imagine that you have found a brave bank that developed and launched such a smart contract:
To ensure the operation of such a contract, the bank must be able to freely accrue and withdraw money from users' accounts - just as it does now when transferring cash to a virtual account. That is, users must trust the bank. However, transactions are initiated by users, and are carried out by the system; the only thing the bank does is to guarantee the exchange of tokens for fiat money at a fixed rate.
Also in the contract you can notice something strange. The bag also has a bank account. A little later, it becomes clear why this is necessary, but for now let us remember that programs can interact with programs, that is, the contract is in some sense an equal user of the system. So nothing prevents the certificate from having its own account. Of course, the certificate can not come to the bank and get cash or deposit cash on the account, but this is not necessary.
Suppose that by the time the bag was released, each of the four participants in the process had already exchanged some amount of the national currency for the virtual one.
In its original form, a contract-certificate allows you to own a bag and transfer ownership. Let's add it so that the bag can be sold for virtual money, and the seller and the buyer should not trust each other - but only the bank and the manufacturer.
It turns out that now the transfer of rights is tied to the transfer of virtual money. They either occur simultaneously, or do not occur at all. The seller has no reason to fear that he will transfer ownership to the buyer, and the bank will cancel the transaction. The buyer knows that if he pays the right amount, the right will go to him, or the money will go back. Of course, such a contact cannot guarantee the transfer of a physical object from hand to hand, but we will discuss this later.
Main government service
Unfortunately, in real life is not so simple. Of course, our computer does not directly identify users (people). Identification requires special encryption keys.
They are called "private key" (it must remain secret) and "public key" - it is the user ID in the system, like a login on a traditional site. The public and private keys are mathematically connected in such a way that only the owner of the private key can prove that he is this particular user, and for this it is not necessary to disclose the private key. It turns out that the user's access to the system is provided by the user's physical access to the private key, which is usually stored on some data carrier.
It is assumed that the person who has access to the key of the company "Horns and Hoofs" is its representative and acts in its interests. Which, of course, is not always the case.
The key can be lost or stolen. You can force the owner to perform the actions necessary for the attacker. In our example, the price of such a vulnerability is a few hundred dollars. But imagine that we do not sell bags, but, for example, real estate or shares in a business.
Here comes the state. Despite the dubious desire to fill in more and more new areas of life, the state has several useful properties: it is impersonal, has a monopoly on violence and a large stock of trust. Those who are faced with the work of the state machine may grin bitterly at the last statement, but this is a fact. Specific functions of the state or its representatives may lose your trust, but if you look closely, it turns out that we all trust the documents and certificates issued by the state (citizen passport, driver's license, certificate of ownership). When concluding transactions, we assume that they are recognized by the state, and our interests are under its protection.
It is sometimes said that the blockchain will lead us to digital anarchy, but this is nothing more than dreams. Clever cryptography does not save us from physical security problems.
How can the role of the state look like?
John Locke on steroids
The most obvious problem that needs to be solved is the user's physical access to the key and identification. The system needs to be built in such a way that when a key is lost, a person does not lose access to their contracts. To do this, we need some entity that is controlled by the specified key, but the key can replace the state at the request of a citizen.
That is, in all the examples above, we have to replace users (key owners) with a special contract that symbolizes an entity that can perform legally significant actions (natural or legal person).
Let's imagine that you store tokens in the trust bank. The account is tied to a private key. Losing the key, you always lose access to tokens. What will happen if the bill is tied not to the key, but to the contract, which is the avatar of a physical person?
Now, in case of losing the key, you can come to the state and ask for a new key for you, changing the owner of your avatar to it. In order to immediately block all actions of this contract, you may have a trustee who has such an opportunity.
Since the state has our exclusive confidence in identifying people, it is difficult to manage without it. Does the blockchain forbid us to use smart contracts in any other way, for example, to bind tokens directly to the key, bypassing the certificate issued by the state? Actually, it does not prohibit, but the state regulates this sphere - not in the sense of "telling everyone how to live." In this case, this means that the state declares: only smart contracts that comply with the established form are under my protection . If you do not make transactions in the prescribed form, and something unexpected happens, this is your problem.
We replaced the user with an individual. But the individual contract has an issuer, and this is another important entity: the state. This entity will also have to be presented in the form of a smart contract, for the same reasons: security. If a citizen in case of unforeseen circumstances can turn to the state for help, the state has nowhere to turn. I will not consider the details of the implementation of such a contract here - this is a topic for a separate article. Probably, the state should be controlled by several keys, which by voting can exclude a key if it was compromised.
The contract-state symbolizes jurisdiction, the sovereign, the social contract - as you like. For him, yet to come up with a term, but I liked the word Empires . In general, it seems to me a good idea to borrow terminology from ancient Roman law: the terms will not overlap, so the discussion will not have to specify what kind of citizenship we are talking about: a real or a citizen-contract.
Of course, I omitted a lot of details in order to explain the concept in general terms. The scheme is as follows: we transfer legal entities into smart contracts, describing the rules by which they interact. The basic elements of the scheme are the state, individuals, money, and ownership, and it is with them that one should begin.
Probably, information about the money will be stored in one contact, and the state will provide licensed banks with the right to exchange national currencies for tokens.
What other legal entities to translate into smart contacts?
- legal entities: IP, LLC, JSC
- ownership of different objects: real estate, cars
- secured loans, with automatic transfer of ownership in case of failure to comply with the terms of the loan
- various licenses
- civil status: an individual can be capable, incapable, alive, dead, married or in other civil relations
- will and automatic inheritance
- Voting and appointment: the elected person can automatically be "appointed" to the position, while the contract-position has the rights, and the position holder changes in accordance with the specified rules
All the business models that I have met today are related to the transfer of old processes to the rails of smart contracts. We heard a promise to save us from intermediaries, while many startups appeared trying to mediate with the help of the blockchain. We see all the same payment systems and trading platforms. I hope that other companies will soon appear, which will concentrate their efforts on providing a convenient interface to the general decentralized exchange system and extracting commercially useful information from the blockchain.