Smart contracts are code that is executed on a blockchain, a concept that is easy to understand if you are familiar with programming, and best explained with an example if you don’t.

If I ask you to loan me some money (say a thousand US dollars), we can settle on some process by which I will repay you, e.g. sending you every month 10% of the loan with a 1% interest on the initial amount, and if the payment isn’t made on time another 5% is added to the total to be repaid. The sum is too small to go through a formal agreement, but at the same time you’d like some sort of mechanism to ensure I am complying with the terms. On the other hand, I’ll be very busy trying to make this loan bear fruit, and not being very familiar with math I’m afraid I’ll end up sending you a lot more than required. Fortunately somebody wrote a smart contract that only needs the following pieces of information to be executed:

  • The initial loan amount;
  • Information about the lender’s wallet (i.e. where the payments need to be sent);
  • A function to keep track of how much is left to pay;
  • A function to calculate the next payment amount (including the interest);
  • A function to increase the amount to be repaid in case of missed payments.

Day by day, I can send small amounts to this smart contract; come the due date for the next repayment, it can check its balance and one of two things will happen: if there is enough money in its deposits, it will send the correct amount to your wallet; if there isn’t, I will postpone a payment but be “fined” with an increase in the total due.

After 10 months, if I always repaid on time, you will have your money back with interest, banking a nice 10% on top.

What smart contracts are useful for

A few key characteristics of this might jump out immediately.

First, the contract needs no input from me to run – it has its own logic to follow, and will do so whether I send money to it or not. It will always run, and run on time, because in principle it will be executed on every machine that runs a full blockchain node (though in reality only a part of the network will run my contract for scalability reasons). Unless the whole network is down the smart contract will run – and if all nodes in the distributed network are down, we’re in a “not the biggest problem we have right now” situation.

Additionally, It is impossible for me to cheat the rules of the contract itself – unless there’s a bug or vulnerability in the code, I cannot interfere with its execution.

Generally speaking, there are not many cases in which smart contracts will be a clear choice over other technologies, much like blockchain protocols themselves.good use cases for smart contracts are three, and are expectedly linked to the strengths of blockchain protocols themselves; the first is optimization of existing, simple processes: smart contracts are ideal because they are hosted on a “neutral” platform, and not on a proprietary database, they can be audited freely and represent a common ground that can be trusted. This can lead to a significant reduction in operational costs, but due to the difficulty of writing sound smart contracts more complex processes might incur in initial costs that are considerably higher.

The second use case is processes that require resilient execution: if some code needs to run no matter what, smart contracts are a good contender due to the redundancy built into blockchain protocols.

The third and final is trustlessness: many blockchains are public, whereas servers are not. If trust between parties is an issue, smart contracts can be the solution due to their transparent nature and indelible archive of transactions. All parties involved are free to audit the code, and disputes can be worked through with the certainty of knowing exactly what happened and when.

What could go wrong? A few things!

The narrative about smart contracts treats them as normal software, which is advantageous from a “what is a smart contract” perspective, but quite damaging in giving a clear picture of what their real strengths and weaknesses are. To this end, we can introduce some less-than-obvious concepts.

The world doesn’t exist for the blockchain

A blockchain, by design, doesn’t know about anything outside itself: a node must be able to “replay” all transactions at any time, including smart contract execution, and reach the same conclusion every time (represented by the balance of every wallet). It is deterministic, and inputs must therefore always be the same.

This has the unfortunate consequence of disqualifying a direct interface with very useful services, because they might go out of business and their data might not be available anymore: connecting to external services can be done, but is either costly or laborious because of that reason. There are companies like ChainLink and Oraclize that solve this by, ironically, being a middleman to get data from an API (for instance the weather data from OpenWeatherMap) and submit a transaction to your smart contract with that data attached. An experienced enough developer can do the same for any API needed by the smart contract, but it does represent a non-trivial amount of work.

Getting information into the blockchain is a problem on its own, that is currently dealt with through oracles, semi-trusted third parties whose job is to send a smart contract the information it requires to function. The two companies mentioned above set up oracles (that’s the service they provide), and in truth there is no limit to who or what can be an oracle, from a weather station that submits reports periodically to a person that is notified by an app when input is required. If in my loan repayment smart contract I want the “market” interest rate (which fluctuates), we could agree agree on a rate every month and send it to the smart contract; we could use a service to manage an oracle for us; we could set up one ourselves; in any case, a solution requires effort to be implemented because of how blockchains operate.

Contracts are immutable

Another consequence of the design of blockchains is that once deployed smart contracts cannot be changed, like transactions. This means that any bug in the code can eventually be exploited, like what happened in one of the most infamous hacks for the Ethereum chain, when an imperfection was used to siphon millions of Ether (the Ethereum currency) from a smart contract that was holding them. It was not vulnerabilities in the Ethereum code that were taken advantage of, but in the smart contract itself.

Admittedly, this class of problem will become less prominent in the future as standard libraries that offer more complex functionality in a standardized way become available, but as the current state of non-blockchain development shows we will never be free of bugs. If that’s the case, how can we deal with them?

There are only three ways:

  1. Leave it as it is and hope nobody finds the fault and exploits it;
  2. Deploy a completely new contract;
  3. Find a way to update the contract.

The first one is criminal in its negligence, so we won’t cover it.

The second and third options both have pros and cons, mostly to do with complexity and continuity. Every smart contract has a “memory” of sorts, an internal database of balances. A new smart contract won’t have the same balances, and so the users will need to transition to the new one or they will be open to a potential attack.

Another option, number 3, is to write the smart contract in a modular way, with pointers to each other that can only be changed by an approved account. So I might write a contract whose job is simply to keep tabs on users, and have my other contracts ask that one for their addresses and balances. Then have a contract that only deals with calculating the current market rate of interest for loans, etc. This is the approach used by many larger projects, but it becomes rather expensive to develop and maintain (remember that all transactions on the blockchain, which the contracts would require to communicate between themselves, can have an associated fee), and the resulting complexity can in fact make bugs and vulnerabilities both more common and more difficult to spot.

There is no one-size-fits-all answer to the question of efficiently upgrading smart contracts, and tradeoffs should be weighed carefully in relation to the complexity, development schedule, and possible consequences of a vulnerability for every specific project. Additionally, open source and widely used smart contracts are generally better than creating an in-house version by virtue of having been proven not to contain bugs, unless a custom smart contract is required.

Smart contracts are not free

As hinted in the previous section, there are fees associated with smart contracts, which are divided in two types:

  • Transaction fees, which are the normal fees paid on the blockchain for transactions, which may even be 0 depending on the specific blockchain
  • Execution fees, to pay for the computing time of the nodes running the smart contract.

Since every computer on the network will, in theory, run every smart contract interaction every to be initiated in the blockchain, there needs to be some incentive to limit the computing time required to execute a contract. This exists in the form of execution fees (for instance “gas” in Ethereum) which are calculated based on the code itself: the more complex the smart contract, the more it will cost to run it, and there is a hard maximum that will make the code simply stop executing, so that there cannot be infinite loops that hang up the machine running the smart contract.

The execution fee is usually paid by the user of the smart contracts, which is a problem in and of itself because the user is required to own at least that amount in the first place, but alternative payment schemes are being studied and tested, such as ones where the contract itself pays for its running costs.

In closing

Smart contracts are a microcosm of the potential and hype of blockchain: on one hand they offer a type of resilience that would otherwise be incredibly costly to build and maintain, a trustless system to automatically execute actions on the blockchain, and all with little overhead after some basic capacity building. On the other, if not coded with the proper caution, they can misbehave and be responsible of considerable losses of funds. Whether they are the best solution to a problem should therefore be a question at the forefront of any project looking into this technology, but if so they are unparallelled in the advantages they offer.

Further reading (if you’re interested)

    Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.