Recently, smart contracts are widely used in the Ethereum network mainly for ICO and management of issued tokens. Such contracts exist as long as necessary to service projects, and for months they provide uninterrupted interaction with thousands of clients. We will call them long-term smart contracts.

However, certain tasks require that the contract be executed literally in minutes, after which it becomes unnecessary. Moreover, for each user, special parameters may be needed, it is impractical to implement them within the framework of a large contract. Such contracts will be called short-term. Consider them in more detail in this article.

Smart contract

A smart contract can be presented as an automated wallet: you put money into it, it checks the conditions and either returns the money, either sends them to another wallet, or sends them to ten of these purses. But this analogy is incomplete, let's try another one.

Compare the contract with the website. You developed a website, put it on the Internet, and the provider registered in DNS that a certain website is located at www.company.com. The contract display on the Ethereum network can be viewed in a similar way: you developed the code, placed it on the network (that is, sent a special transaction “create a contract”) - and the contract has its own address in Ethereum, exactly the same as the address you give it to someone to send you the air.

At the same time, the “site” in Ethereum has useful properties for smart contracts:

• Code "site" can not be changed . The maximum you can nail it, if you pre-program the possibility of "loss" of the contract when you receive a special message. This does not mean that the code will disappear or the smart contract will be erased. Just any transaction sent to it will return an error.
• Each request to the "site" is an indisputable transaction, permanently stored in the blockchain . On ICO, you contributed one ether and received ten tokens - there was a record inside the contract that you have ten tokens. Your request has changed the status of the contract. Each such transaction is already technically indisputable. You can always prove that the transaction was and it was you who signed it (if you have the necessary secret key).
• Each request from the user to the "site" can contain any amount of funds . If we consider a contract as a site, then each request to the "site" is able to carry a broadcast. Imagine a website where you can attach any amount of money to each click on the buttons, while the website understands how much it has been sent to, knows how to give change, etc.
• Every request is visible to everyone . You can not limit the visibility of requests to the "site". You sent a request to the smart contract, and during the execution something broke - for Ethereum this is a normal situation, and the transaction that caused the error will still be placed in blocks, and the miners will still receive their commission for executing the contract code (from your ether naturally).

After the network "accepts" the code of the new contract (all miners checked the code, placed it in blocks, registered the block, published it in the network), the contract receives its own address and can accept transactions. We also do not forget that each transaction sent to the blockchain is data signed with an electronic signature with all its advantages (at least with confirmation of authorship). Why is there a blockchain? In simple terms, the thing is in the absence of a shared secret, known to two parties. PIN, bare password hash, insecure web session are all examples of what an attacker can use. In the case of the blockchain, the only secret is the key on the client, everything else requires neither secure communication channels nor authorization. Well, let's add that none of the parties can do something imperceptibly to the other: every change in the state of the contract is recorded, even unsuccessful or malicious transactions. The blockchain captures any operation that changes something inside the repository of every smart contract placed on the network. At the same time, the operation can be simple, and it can do quite complex things, and any network participant is absolutely sure that the contract code for all participants works exactly the same way as it does on his machine.

Even in the minimum option (in the short-term), smart contracts are great tools for accounting. They are extremely convenient to use in almost any projects, because out of the box we get the whole system of security and fault tolerance. As we will see later, sometimes even a minimum of standard functions is enough to implement many interesting tasks.

Long-term and short-term smart contracts

By the term of the contract in this article, I mean not only the time, but also the number of transactions serviced by the contract. If a contract takes a long time, it receives and sends a lot of transactions, it is considered long-term. If it accepts several transactions or runs for a limited time and then closes - short-term. We have divided the contracts into two types, having gained experience in developing several contracts and designing interaction protocols.

These contracts have a different gas economy, the complexity of the creation, the nature of sending to the network and help solve different business problems. Some contracts serve many users and transactions, store a lot of data. Others are applied one-time, for fixing and executing a single agreement (to sell one product, to make a lump sum payment, to receive funds previously placed in a contract, etc.). Therefore, we offhand called contracts long-term and short-term. If you have thoughts, how to name them more precisely, welcome.

Long-term contracts . Usually, the business model of a long-term contract looks like this: we put it on the Ethereum network, and now thousands of users go to the contract and do something in it. As an example, we give a token contract. We post a contract to the network, keeping the balance of users. Thousands of investors come to us, and for each investor information about the number of tokens received is put into a token contract. Each time you send tokens to another address, you access the same contract located at the same address and instruct the contract to change the balance of the tokens (yours and the recipient).

The contract drags a large amount of data and lives as long as your project is alive. Tokens within it can move for years. There are no restrictions on the transfer of tokens within the contract, and it will always work as long as the network exists.

Another example of a long-term contract is Equity. Consider an example of a company in which you distribute shares: 10% Vasya, 10% Pete, and you - 80%. You want the entire profit of the company to be distributed accordingly: if 100 rubles are paid, Vasya and Pete get 10, and you - 80. Equity divides money into the flow, distributes incoming funds, and allows participants to receive their shares indisputably, at the same time fixing all payments and amounts. But it is planned that the company will work for a long time, so you once ask the programmer to post your contract on the network, and then quietly use the contract for years without additional efforts, sometimes redistributing the shares.

Short term contracts . They live not for long (hours, days) or spend few operations (single payment, a couple of fixations of events). These contracts are sharpened for an individual user, a separate transaction or a separate product. For example, selling washing machines can be placed on the network under a contract for each machine. The user enters into such a contract, one or two times does something (transfers funds, confirms something) - and after that the interaction ends. From short-term contracts, we need only a one-time I / O with the necessary checks and fixing the event in the blockchain. In the minimum version, any transaction, with or without air, is information itself. We, in general, do not have to invest in it: it already has the sender's signature and the time the unit is closed.

If a contract can only receive and give a fixed amount of funds (and issue, for example, change), then any successful transaction becomes an analogue of a cash voucher, and the blockchain becomes a convenient repository of transaction data. It turned out to hold a transaction - it means that the purchase is completed. Showing the ETH address of the store in the Federal Tax Service, you can explain: "Here are our checks and our sales." This generally saves stores from having to have cash registers, now their concern is to register keys and addresses belonging to the store, and ensure their security and the ability to change when hacked. You can also implement a tax payment right at the time of purchase, it would be where to pay without any problems with a couple of lines.

One-time contracts have advantages and disadvantages. The fact that there are a lot of contracts and they are small, greatly increases the cost of premises in the Ethereum network, because this is a rather expensive operation. But, on the other hand, contracts are responsible for relatively small amounts, it is much easier to replace them by simply switching to a new version. The security risks are much less because of the simplicity of the code and the small amount of data. The simplicity of the code also means cheap for users. There are a few more points, but about them later.

As examples, we describe, say, three types of simple short-term contracts:

• invoice-paid;
• commit-reveal;
• one-time multisig.

The first is an analogue of the invoice issued for payment, the second allows “to promise to give money” and “to allow them to be collected, proving the fulfillment of the task”, the third - to resolve the dispute, “whose money”, with the help of an arbitrator. Go.

Invoice-paid

In fact, we have a price tag. Imagine we sell watermelons. We release the price tag directly below the specific fruit with a specific weight, paste it on the watermelon and write: “It costs 1 ETH”. After that, we need the price tag to either accept 1 ETH or “rotten” in a day: perhaps the next day we will want to sell the watermelon for 2 ethers.

In the short-term version, we publish a short contract for a specific product for a limited period. From the internal data in the contract is only the price and the time when the contract becomes invalid.

When someone wants to buy a product, he sends the air to our one-time contract, and he, in turn, sends the air to the ETH address of the store, sends the change (if necessary) and closes. The transaction has been preserved in the blockchain, and analyzing transactions from contracts created by a store, it is easy to get the entire sales history. At the time of purchase, the contract can also pay tax or commissions to the person who brought the client to it.

Another rather close analogy of such a price tag contract is the invoice. Therefore, we called the contract invoice-paid: these are two working conditions in which it can be. In invoice mode, he is waiting for payment, in paid mode he accepted payment and does nothing. The third state, when the lifetime has expired (TTL - time-to-live), is standard for all short-term contracts. The expired TTL causes the contract to self-destruct or simply ignore any incoming transaction.

You can put useful data in invoice-paid, for example, set such an invoice to a specific address right at the moment when the buyer decided to purchase the goods. In this case, the contract takes the air strictly from the specified address. A hash of any data can be added to the contract: photos of the goods, id's ads on Avito, an archive with a package of documents, etc.

Commit-reveal

This scheme in the blockchain is used to promise to do something and then prove that the deed is done.

When a transaction is sent to the network, any node transferring a transaction over a p2p network can analyze the contents of the transaction before it is included in the block. Such a node can create its own transaction with a higher commission, which block-producers are more likely to include in the block and which will be higher in the list of transactions than the original one. Let's remember the game "rock, paper, scissors". It is impossible to play it directly by sending transactions. It is clear that I will not send scissors to the contract: my opponent can spy on a public transaction and create his own, with a “stone.”

The solution of the problem is in the scheme, when the proving party (in our example there are two of them, my opponent and I) “promises” to show some value in the future, while the secret one (our “scissors” or “paper”). To do this, we send to the contract first the hash from the word “scissors” (I), then the hash from the word “paper” (my opponent). Only then can I openly publish the "scissors", and my opponent - the "paper". There is no way to deceive here: I will open the “scissors”, only when I see the opponent’s hash decision, the same goes for it. The meaning of the stage of placing hashes is well conveyed by the word commit, and the stage of disclosure of values ​​- reveal, hence the name.

It is necessary to note that before calculating the hash the string (“scissors” or “paper”) must be supplemented with a random number. The ability to “guess” the choice of an opponent by the published hash depends on the cryptographic strength of the number, so its generation must be approached with all seriousness. This number is a temporary secret, it is published along with the line at the reveal stage, so that participants can verify the correctness of the hash.

Let's consider the commit-reveal contract option for courier delivery. The store sends the courier along with the goods to the customer and wants the courier to receive payment only if he delivers the goods in three hours and handles it personally to the customer. For this, the store generates a secret word, creates a contract, puts a hash of words and time (three hours) into it, after which the store can simply return its funds by sending a refund transaction to the contract. The store gives out to the courier (in his mobile application or browser) the address of the contract, and the courier sees that in three hours he will be able to pick up the payment if he finds out the secret word. The word shop sends by SMS to the client. The contract logic is described by the phrase “If a courier sends a word within three hours - a prototype of the hash used to create the contract, I will send the funds to the courier”.

In the event of a conflict with the buyer, the store may itself unlock the funds for the courier, simply by sending a secret word to that.

Of course, for real use, contracts also contain modifications — additional data and checks, commissions, entry thresholds, dynamic changes in shipping costs, etc. But the main commit-reveal scheme is the basic one for building convenient interaction protocols for business agents.

One-time multisig

This contract is an address from which you can withdraw funds by providing N from M signatures.

Suppose a husband and wife decide to keep part of their family savings in cryptocurrency. I would like the contract to accept and keep the funds, but did not allow them to be withdrawn from the contract until it receives at least two of the three confirmations - from a husband, wife or bank. If a phone is stolen from the wife, the husband will be able to go to the bank and, having received the signature of the bank, withdraw the money. In normal mode, the funds are withdrawn from the contract when both the husband and wife have provided their signatures. This is extremely convenient, because hacking one of the participants does not threaten unauthorized withdrawal of funds.

In general, multisig can operate with arbitrary N and M, but its “two out of three” option covers a huge number of business tasks where a third party is required. When you buy an apartment and the bank gives the keys to the cell, only when it receives documents for real estate, this is multisig 2/3. The money is put on the multisig-address where the apartment seller, the buyer and the bank participate. The bank, as soon as it sees an agreement on the change of ownership, puts its electronic signature. Such a contract also includes time limits and, of course, a commission for the bank. For single tasks, operating with large amounts, it is reasonable to use one-time contracts. Vulnerability in a huge universal contract that will manage all letters of credit can lead to far more serious consequences than a successful attack on a one-time contract.

In general, multisig is like a Kalashnikov machine gun, with the help of short-term multisig 2/2 and 2/3, transactions with escrow are easily realized, transactions requiring collective decisions, and further adding functionality to multisig and dynamic changing of N and M is already a transition to equity voting. and management (but this is a topic for a separate article).

The benefits of short-term smart contracts

1. Simplicity and, as a result, safety. In Solidity, you have to think literally at every step, every operation costs gas, every extra call to an external contract is a potential vulnerability, this is where a large number of security problems lie. A short-term contract contains little code and does not require interaction with other contracts; therefore, it is safer than its elder long-term brother.
2. The less code, the cheaper. It is cheaper to publish, develop and write tests for it. A simple contract has a simpler and unified interface that can be easily displayed outside in any constructor. This allows other developers to work with your smart contracts, easily adapting them to their needs.
3. Short-term smart contracts are easy to transfer to other blockchains. If you make a simple short-term smart contract, then, most likely, you will be able to implement it without any problems on graphene, EOS and other platforms. Simple logic is more likely that this has already been implemented in competing engines, which means that development is cheaper and the contract is more reliable.
4. Very convenient to fix. A hole in the token is a serious problem. You have to replace the token and drag the balance - it costs a huge amount of gas. In the case of short-term versions, we are not deploying contracts, but fixing their version, and then just waiting for the bad contracts to "rot" and be replaced by new versions.
5. Correctly destroying contracts, we will clean local storage on clients, optimizing the used space. There is still a subtle point, whether the selfdestruct removes the contract from the storage db physically on the client, but, in theory, it should. This will allow not to inflate strongly the blockchain volume.
6. Ttl. If we are looking for price contracts on the blockchain and know that they live no more than a day, then the search engine for Ethereum can be configured to work only with the blockchain for the last 24 hours. This makes such search engines convenient and fast, because there is little data, and the sites working with short-term contracts are very fast and functional. Otherwise, wool hundreds of gigabytes of blockchains, making tracking thousands of accounts, is not an easy task for programmers.

Problems and Solutions

Everything is not very good. The first problem is gas. For every smart contract you have to spend gas. The service, which “shoots” tens of thousands of contracts, requires serious research and balancing. In Ethereum today you can send a transaction at a gas price of 5 Gwei, and it will arrive in a minute. And sometimes you have to put 50 Gwei for gas and wait an hour. Those who use smart contracts are not very pleased with the growth rate of the broadcast, for this means a rise in the cost of sending contracts to the network. Laying out a contract in the network is an expensive procedure, so short-term contracts are not cheap.

We consider not only Ethereum and on our platform we plan to use several networks working with smart contracts at once. The problem of execution cost is their common problem. Sooner or later it will be decided - either the competition for the cost of executing a single contract line will greatly lower the cost. In addition, most likely, even the same types of operations will differ in cost, so I do not rule out the emergence of strategies like “we execute contracts with crypto-transformations in one blockchain, and with string operations in another”.

The second problem is the dead, but not finished selfdestruct contracts. We “pulnuli” a smart contract, paid for it, and he died in the blockchain, having done nothing. This is not good for a state-database, and we are thinking what to come up with. Perhaps the “janitors” scripts for a small commission will cause selfdestruct contracts with expired TTL. :)

The third problem is the complex infrastructure for sending contracts to the network. Managing such a number of smart contracts, their deployment, monitoring requires a serious add-on around Ethereum and the rest of the blockchains. This includes a blockchain search engine, an automatic deploer, and queues for managing push clients for mobile clients, as well as managing funds with large amounts of air, addresses and keys. All this is a very serious story in terms of security and architecture.

So, we looked at some of the features of smart contracts, described a few cases and talked a bit about problems and solutions. Construction of a platform that can support the launch of a large number of different types of contracts without sacrificing security and decentralization is already underway - this is our Smartz.io project. The platform gives developers and small teams the opportunity to earn money when placing their DApps, and for simple users it provides a convenient way to launch and start using one of the many useful DApps for personal use with a few clicks. We will be familiar :)