The evolution of a contract
When you hear the term “smart contract”, what do you think of? If you have no idea what a smart contract is, you might try to make parallels with ideas you’re familiar with.
Maybe you think of a smart phone. You think, “A smart contract is an evolved contract, like a smart phone is an evolved flip phone.” You know that a smart phone is a more capable version of its “dumb” predecessor. A smart phone does more than handle calls.
Does a smart contract relate in any way to a contract? If so, is it a “smarter” version of a contract? A contract is a legally binding agreement. It defines the obligations between two parties. A smart contract is a program that exists on a blockchain. It’s hard to make a comparison based on those definitions.
Blockchain
Before we expand on those questions, lets try to understand what “a program on a blockchain” means.
Bitcoin’s emergence gave rise to other blockchains. While the purpose of Bitcoin was a medium for peer to peer exchange of monetary value, developers saw potential for much more.
The Ethereum blockchain’s whitepaper details why it was created. Ethereum took the idea of blockchain and theorized it could be used for much more than monetary transactions: custom currencies, ownership, non-fungible assets. All of this would be made possible through “smart contracts”.
Bitcoin uses a custom programming language called Script to handle transactions. That is all it is meant to do. Ethereum uses more complex programming principles to create a “Turing complete” environment that allows for the creation of smart contracts. We’ll explore our initial questions from the perspective of the Ethereum blockchain.
Turing Complete
It took me some time to wrap my head around the concept of “Turing complete”. I don’t quite understand the idea of a “Turing machine”. Is it an actual machine? Is it just a concept? Maybe I haven’t wrapped my head around Turing completeness.
But what I do understand is that Bitcoin’s Script language is (intentionally) not Turing complete. When a programming language is Turing complete, it can potentially run a program in an infinite loop. If an infinite loop were to occur on the Bitcoin network, it could destroy the entire system. Much like a denial-of-service attack, the network would be stuck, possibly forever. For this reason, Script is intentionally limited.
Ethereum developers decided Turing-completeness would be necessary to achieve their ambition.
Code is law
We’re grappling with the idea of whether a smart contract is an upgrade to a contract just as a smart phone is an upgrade to a flip phone. We established that smart contracts are programs that exist on a blockchain. The parameters of the program are defined by the code within the smart contract.
In the context of smart contracts and programming, “code” is a set of instructions. Instructions define the logic or behavior of an application or system. Ethereum’s friendliness towards Turing-completeness allows complex code to exist on the Ethereum network.
A contract relies on the legal system as the enforcer. A smart contract needs only to exist on a blockchain. The code that defines the smart contract is law.
So does that make a smart contract the next evolution of a contract? Let’s take a look at a few more details before we come to a conclusion.
Immutable
Once a smart contract is deployed to a blockchain, it is immutable. That means it can’t be changed.
As the legal system is the enforcer of contracts, immutability is the enforcer of smart contracts. The immutable nature of a smart contract is what makes code the law.
Escrow
As an example, a developer can deploy a smart contract that serves as an escrow. In the real world, a contract would define the stipulations between two parties, and a third party would serve as the escrow. On the blockchain, the smart contract plays the role of the third party escrow. The code within the smart contract declares the obligations between the two parties. When these obligations are met, the smart contract is executed.
Let’s say you agree to sell me a car. This transaction could be mediated through a smart contract. We could use a smart contract that would require both of our digital signatures to complete the transaction.
First, we define the parameters of our agreement. You establish the amount I need to pay, and I deposit that amount into the escrow contract. You have proven you’re the owner of the car. I’ve test driven the car, and I want to complete the transaction. I complete the transaction by providing my signature to the contract. The contract releases the funds to your wallet and gives me ownership of the title.
Let’s say I decide to drive away with the car, never to see you again. Well, the funds are still stuck in the escrow, and the title is still in your name. The smart contract would not exchange title ownership without my approval, and the funds won’t find their way back to your wallet. Not exactly the perfect crime. If we reverse the roles and you wanted to play criminal, you wouldn’t be able to get the money from the escrow smart contract without my signature. The point is, the smart contract has obligations that must be met. If they aren’t met, the transaction will either be reversed or remain stuck.
A smart contract can take on the role of a traditional contract and do more. By no means does it replace the legal system. It just makes the legal process less complicated by creating a convenient platform for verifiable proof.
Trustless
Our escrow example highlights how smart contract immutability removes trust from the equation. Because the smart contract can’t change after it is deployed, users don’t have to rely on trust. Immutability creates a trustless environment by ensuring that the code is law. A trustless environment enhances two key aspects of smart contracts: state and self-execution.
State
We mentioned that smart contracts are a vehicle for verifiable proof. We also established that smart contracts can be executable evidenced by the escrow contract. Just as important, they are also a means to store information. Smart contracts have their own “state” and this state can be updated.
For our escrow example to work, we have to imagine a world where we store a lot more information on the blockchain. Perhaps Ethereum becomes the blockchain of choice for governments. This means that information like titles to cars would exist in a smart contract on the Ethereum network. Our escrow contract and a smart contract that stores car titles would exist on the Ethereum blockchain.
During our transaction, you were able to prove ownership of the car thanks to a smart contract that contains car titles and their owners. When we interacted with the escrow smart contract, it communicated with the car title smart contract.
So a smart contract can be viewed as a program on a blockchain that keeps track of information. This information is the state of the smart contract, and while a smart contract is immutable, its state can be changed.
Self executing
A trustless environment also provides a platform for reliable self execution. Smart contracts are intended to automatically execute when their parameters have been met.
The escrow contract we used to make our transaction only required that we interacted with it.
As long as the blockchain the smart contract has been deployed to is functioning, the smart contract will always be accessible. Once we initiate our transaction with the escrow contract, it requires conditions to be met. After the conditions are met, we can rely on the smart contract to execute actions like transfer funds between accounts (you received the funds I deposited to the escrow smart contract) and modify state to update ownership (the smart contract updated information on the ownership of the car title). These actions would self execute once both parties have agreed that the obligations between them heave been met (we provided our digital signatures in our escrow transaction). A third party wouldn’t be needed to hold funds or initiate ownership changes.
Upgradable smart contracts
There are situations where immutability can be a hindrance. In traditional software engineering, programs can be fixed when bugs are found. Since smart contracts are immutable, once a bug is found on a deployed smart contract, the smart contract may become useless based on the severity of the bug. Immutability means the bug can’t be patched.
The Ethereum blockchain accounts for this and allows upgradable smart contracts. Smart contracts aren’t inherently upgradable. Developers have to decide which type of upgrade mechanism to utilize and implement the pattern accordingly.
Common among all the upgrade patterns is that the deployed version of the contract will always exist on the blockchain. While a traditional application will have updates that need to be downloaded every once in a while, an upgraded smart contract will just be the utilization of a new smart contract. The old contract will still exist. So technically, even with “upgrades”, contracts remain immutable. Upgradability in smart contracts is just developers changing the contract that users interact with.
The elimination of immutability means we are no longer operating in a trustless environment, so upgradability is a choice that developers must carefully consider.
Gas
When we were exploring Turing completeness, we learned that an infinite loop in a blockchain would be a terrible outcome. It could halt the blockchain. But the Ethereum developers still chose an environment that followed Turing complete rules. Why weren’t they afraid of the infinite loop like Bitcoin developers? What if a developer deploys a smart contract that contains an infinite loop?
Ethereum developers accounted for this threat through the implementation of gas. Gas plays other roles, but it places constraints on smart contracts and the general behavior of the Ethereum network. These constraints help mitigate the risk of an infinite loop.
Bitcoin transactions require fees. The miners that build the Bitcoin blockchain are rewarded with the fees. In the Ethereum network, gas plays the same role. Every interaction with a smart contract (like our interaction with the escrow contract) is a transaction. Validators in the Ethereum network are reward with gas fees associated with transactions.
Let’s go back to our escrow example. When you initiated the transaction and set the amount I needed to pay for your car, that transaction had a gas fee. When I was satisfied with the test drive, my confirmation to the escrow contract, another transaction, also required a gas fee.
The amount of gas needed per transaction is always changing. It is based on the previous block. Each block in Ethereum has a maximum amount of gas it can contain. That means that the cumulative amount of gas from all the transactions in a block cannot exceed a certain amount. In this example block we can see the “Gas Limit” field.
We won’t dive deeper into gas because it’s not a concept directly related to smart contracts. But it is important to know that infinite loops are prevented by gas constraints. Gas is paid in the Ethereum network’s native token ether. So either a user will run out of funds to pay the gas fees for a smart contract with an infinite loop, or validators would not add transactions that exceed gas limits to any blocks.
Can we say that a smart contract is the evolution of a contract?
Conclusion
We’ve learned that smart contracts are indeed comparable to contracts. And we can argue that a smart contract does more than a regular contract. A regular contract defines the terms of an agreement. A smart contract plays the same role, but also manages everything else that would be involved in the process.
A contract acts as a guide setting ground rules. Everything else that occurs, transfer funds and change of ownership, occurs outside of the contract mediated by third parties. On the other hand, a smart contract can handle funds as well as maintain a history of ownership. Smart contracts either remove third parties or play the role of an immutable, trustless bookkeeper.
As landlines and flip phones evolved into the smart phone, we may see the contract evolve into a smart contract in our life time.