Skip to content

Smart Contracts

sherminvo edited this page Dec 6, 2020 · 3 revisions

A smart contract is a piece of software that is processed by a distributed ledger. It is a rights management tool that can formalize and execute agreements between untrusted participants over the Internet, and comes with inbuilt compliance and controlling. Smart contracts can reduce the costs of formalization and enforcement of a simple agreement between two parties, the bylaws of an organization, or to create different types of tokens.

Would you enter into a contract with someone whom you’ve never met, and therefore don’t know and don’t trust? Would you become an investor in a small company in a foreign country? Would you agree to lend money to a stranger, like a farmer in Guatemala, a teacher in China, or a cashier in the UK? Or would you set up a legally binding contract for a 1 EUR purchase over the Internet, like buying a song from an artist? The answer in all of the above mentioned cases is probably no, as the cost of setting up the necessary legal contract to secure your transaction is too high. Alternatively, you could use trusted intermediaries to settle such contracts, paying them settlement fees for their services. The business models of many Web2 tech giants like Amazon, eBay, Airbnb, and Uber result from the lack of a trustful native value-settlement layer and user centric-identity systems. Smart contracts in combination with user-centric identity systems can provide a solution to both problems. They can formalize the relationships between people and institutions and the assets they own, entirely P2P, without the need for trusted intermediaries.

Although the concept of smart contracts is not new, blockchain networks seem to be the catalyst for smart contract implementation. A more primitive form of a smart contract is a vending machine. The rules of a transaction are programmed into a machine. You select a product by pressing a number related to the product you want and insert money. If you insert enough money, the machine is programmed to eject the product. If not, you would not receive the product, or if the machine ran out of the product, you would get your money back. Automatic vending machines made certain street sellers obsolete, but they also expanded service, offering 24/7 availability instead of the limited opening hours of a human-operated vendor.

Self-Enforcing Agreements

A smart contract is a self-enforcing agreement, formalized as a software. The code contains a set of rules under which the parties of that smart contract agree to interact with each other. If and when the predefined rules are met, the agreement is automatically enforced by majority consensus of the blockchain network. Smart contracts provide mechanisms for efficiently managing tokenized assets and access rights between two or more parties. One can think of it like a cryptographic box that unlocks value or access, if and when specific predefined conditions are met. Smart contracts therefore provide a public and verifiable way to embed governance rules and business logic in a few lines of code, which can be audited and enforced by the majority consensus of a P2P network.


Smart Contracts


A smart contract can be invoked from entities within (other smart contracts) and outside (external data sources) a blockchain network. External data feeds, so-called “oracles,” inject data that is relevant to the smart contract from the off-chain world into the smart contract. They can track performance of the agreement in real time and can therefore save costs, as compliance and controlling happen on the fly. Smart contracts reduce the transaction costs of agreements. Specifically, they reduce the costs of (i) reaching an agreement, (ii) formalization, and (iii) enforcement. If implemented correctly, smart contracts could provide transaction security superior to traditional contract law, thereby reducing coordination costs of auditing and enforcement of such agreements. Smart contracts also bypass the principal-agent dilemma[^1] of organizations, providing more transparency and accountability, and reducing bureaucracy (read more: Part 2 - Institutional Economics of DAOs).

The term “smart contract” itself is a bit unfortunate, since smart contracts are neither particularly smart nor do they reflect legal contracts: (i) A smart contract can only be as smart as the people coding it, taking into account all available information at the time of coding; (ii) While smart contracts might have the potential to enforce legal contracts if certain conditions are met, we first need to resolve many techno-legal questions, which will require time and interdisciplinary discourse between lawyers and software developers.

Furthermore, smart contract security is still an issue that needs to be resolved on a technical level. More sophisticated contractual clauses need to be implemented to make smart contracts compliant with legal contracts, including decentralized dispute settlement mechanisms. While such developments might take more time to mature, some interesting dispute-resolution solutions are already under development, examples of which are “Kleros,” “Openlaw,” or “Jur.” We will probably see a fusion of legal contracts and smart contracts emerge over the next few years. At the time of writing this book, best practices are still rare and will require a collective learning process. The technology is still nascent, and legal standards need to be adopted.

Industry Use Cases

Smart contract use cases range from simple to complex. They can be used for simple economic transactions like sending money from A to B. Smart contracts can also be used for registering any kind of ownership and property rights, like land registries and intellectual property, or managing smart access control for the sharing economy. Use cases can be found in banking, insurance, energy, e-government, telecommunications, music and film industry, fine art, mobility, education, and many more. Each agreement, process, task, or payment can be collectively managed. Many traditional intermediaries, like lawyers, brokers, and bankers, or public administrators, and Internet platforms might no longer be necessary, or at least some of their services might become obsolete: Cars could use smart contracts to pay their own bills upon fueling up at the gas station, or charging up at an electric charging pole. Invoices could be settled upon arrival of a product shipment. Smart share certificates in the form of tokenized securities could be programmed to conduct automated payout of dividends (read more: Part 4 - Asset Tokens & Fractional Ownership).

Smart contracts can provide a native settlement layer for the sharing economy, currently brokered and processed by Internet platform operators. The P2P nature of payments enabled by smart contracts reduces the transaction costs, which means that micropayments could become economically more feasible than they are today.[^2] Smart access controls between two peers who do not trust each other could provide a practical solution for the sharing economy without centralized platform providers, who currently own a disproportionate part of our data, and therefore also the economic value created. This could lead to a sharing economy on steroids: apartments, cars, washing machines, bicycles, lawn mowers—once all those devices are tagged with their own blockchain address (or DID) they could be managed by a smart contract that acts as a digital lock.

A more complex example of a smart contract is the use case of a self-managing forest, as in the case of “Terra0,” where a smart contract on the Ethereum blockchain manages the logging and selling of trees from a forest in Germany. Drones and satellites monitor the growth of the forest and trigger events in the smart contract, like subcontracting agreements to log the forest and sell off the wood.

Furthermore, smart contracts can be used for much more complex agreements between a multitude of actors, along the supply chain of goods or services, or for governing a group of people that share the same interests and goals without the need of traditional centralized institutions. Decentralized autonomous organizations (DAOs) are such an example and probably represent the most common form of complex smart contracts. The smart contract hereby formalizes the governance rules of an organization—like the bylaws, governing statutes, rules of procedure—and replaces day-to-day operational management with self-enforcing code.

Smart contracts and DAOs could also disrupt social media as we know it. Web2-based social media networks extract rent in the form of data from the users that they monetize. In the Web3, smart contracts can enable purpose-driven ecosystems, in which users can benefit from their network activities by getting rewarded with network tokens. An example thereof would be “Steemit,” a decentralized social network that is organized as a DAO and incentivizes user contributions with network tokens (read more: Part 4 - Steemit).

Smart contracts and distributed ledgers could also be a catalyst for machine-to-machine settlement in an “Internet of Things.” This, however, requires that all objects in such an Internet of Things have a blockchain identity, and can thus be uniquely addressed. Addressability of each single machine or other physical object needs to be tamper proof. This can be achieved by tagging or chipping objects with a so-called “crypto accelerator,” which is also referred to as a “digital twin.” A crypto accelerator is a small micro-controller optimized to run the most important cryptographic algorithms. It can have the size of a sticker on a piece of fruit and therefore serve as a basis for use cases like supply chain transparency. With a digital twin, any physical object can send unique digital signatures, or send and receive tokens. Projecting the current rate of development of this technology into the future, and taking into account convergence with other emerging technologies like IoT, Big Data, and AI, we can now envision a world where individuals, organizations, and machines can freely interact with one another with little friction and at a fraction of current costs.

Smart contracts can furthermore be used to create and manage cryptographic tokens that can represent any asset or access rights, and even incentivize behavior. Tokens might emerge to be one of the most important applications of smart contracts, potentially revolutionizing asset management as we know it. This is why the last two parts of this book are dedicated entirely to the topic of tokens.

Oracles

Blockchain networks and smart contracts cannot access data from outside of their network. In order to know what to do, a smart contract often needs access to information from the outside world that is relevant to the contractual agreement, in the form of data feeds, also referred to as “oracles.” These oracles are services that feed the smart contract with external information that can trigger predefined actions of the smart contract, which in turn induce state changes to the ledger. This external data stems either from software (Big Data application) or hardware (Internet of Things).

Software oracles: handle information data that originates from online sources, such as temperature, prices of stocks or commodities, flight or train arrival times, etc.

Hardware oracles: Some smart contracts need information directly from the physical world, for example, a car crossing a barrier where movement sensors must detect the vehicle and send the data to a smart contract, or RFID sensors in the supply chain industry.

Inbound oracles: provide data from the external world.

Outbound oracles: provide smart contracts with the ability to send data to the outside world.

Consensus-based oracles: get their data from human consensus and prediction markets like “Augur” or “Gnosis.” However, using only one source of information could be unreliable, as markets can be manipulated; rating systems for oracles might be needed. A combination of different oracle services might further increase data reliability if, for example, three out of five oracles could determine the outcome of an event.

The main challenge with oracles is that people need to trust these outside sources of information, whether they come from a website or a sensor. Since oracles are third-party services that are not part of the blockchain consensus mechanism, they are not subject to the underlying security mechanisms that this public infrastructure provides. One could replicate “man-in-the-middle attacks”[^3] standing between contracts and oracles. The robustness assurance of this “second layer” is of utmost importance. Different trusted cryptographic tools and computing techniques can be used as a way of solving these issues. If oracle security is not adequately provided, it will be a show stopper for widespread smart contract implementation.

It is important to note that a smart contract does not wait for the data from an outside source to flow into the system. The contract has to be invoked, which means that one has to spend network resources for calling data from the outside world. This induces network transaction costs. In the case of Ethereum, this would be the cost of “Gas.”

Use Case of Buying a Second-Hand Car

If two people, let’s say Alice and Bob, don’t know and don’t trust each other, they usually need a trusted third party to serve as an intermediary to verify transactions and enforce them. With smart contracts and blockchain networks, you no longer need those trusted intermediaries for the clearing or settlement of your transactions. Take the example of buying and selling a car: If Alice wants to purchase a car from Bob today, a series of trusted third parties are required to verify and authenticate the deal. The process differs from country to country but always involves at least one, but usually more, trusted third parties: motor vehicle registration authority, in combination with a notary and/or insurance company. It can be a complicated and lengthy process, including resulting fees. If and when all involved authorities and companies use distributed ledgers, a smart contract could be used to formalize all the rules of a valid car sale, including the settlement for add-on services like buying a car insurance policy. If Alice wanted to buy the car from Bob using smart contracts, the potential process could look like this:

_* Bob will use the Internet to find a service where he can post his used car and define the terms of sale, using a smart contract—on some decentralized version of eBay, for example. This step is no different from today, but smart contract–based services need to be Web3 compatible, to communicate with a blockchain network. This smart contract service might also provide a smart garage that also communicates with a blockchain network. Bob will therefore need to download a software that is Web3 with an inbuilt wallet, which will provide him with a unique blockchain identity—a blockchain address with a related public-private key pair (read more: Part 1 - Cryptography). _

* Alice will also use the Internet, just as she does today. She will search the Web to find the decentralized version of eBay, where Bob posted his car. Alice will also need to download a Web3-compatible browser.

* If Alice finds a car that she likes and wants to buy—let’s say Bob’s car—she will click on “buy,” and the smart contract-based service will use a blockchain network to check whether Bob is the owner of the car, and whether Alice has enough funds available. The information about both states—the ownership titles of the car Bob claims to sell, and the amount of tokens Alice has—is recorded on the ledger. Upon clicking the “buy” button, the smart contract service might also give her the option to select an insurance plan, with selected insurance companies that are also registered on the ledger and connected with the smart contract service providing this insurance (in such a future scenario, the insurance plan could probably be calculated on the fly, where rates would be based on the car’s data and Alice’s driving history).

* If the network agrees that both states are true—that Alice has enough funds, and that Bob is really the owner of the car—the blockchain network registers Alice as the new owner of the car, and their funds balances are automatically updated: Bob now has 20,000 more tokens on his account, while Alice has 20,000 less tokens in her wallet. Alice then receives an access code to the smart lock for the garage. Furthermore, Alice is now also registered with the car insurance company of her choice, which she selected upon buying the car, triggering another smart contract.

* Bob can now park his car in the garage. His car, which also has a unique identity on the blockchain, will now be registered as being parked in the garage, and Alice will receive a notification about where to pick up the car with her access code.

* Alice can now pick up the car in the specified garage, protected by a smart lock connected to the blockchain and managed by the smart contract that both Bob and Alice use. She can unlock the garage with her private key, which identifies her as the rightful owner of the car. The car is hers, it is registered to her name, and it has insurance.


Buying a second hand car in the Web2


Buying a second hand car in the Web3


Using smart contracts, we can now avoid manual interference of certain institutions like motor vehicle authorities, insurance companies, and in some countries, also notaries, if and when the regulatory environments permit it. Every computer running the blockchain protocol will be able to check whether someone is the rightful owner of a car or not. Stealing cars won’t be as easy as it is today, once cars are equipped with digital keys using smart contracts for access control. Certain automated processes will also require the convergence of smart contracts with data feeds from external software and hardware, as would be the case of pictures taken in the garage to monitor the state of the car. As the owner of the car, you could furthermore use smart contracts to authorize other people to drive your car, registering their blockchain identity with the smart contract of your car.

Smart contract security is an important issue for widespread adoption of use cases: (i) Oracle security: making sure that data coming from off-chain sources can be trusted; (ii) Secure coding and formal verification: computer-aided checking and testing of code with respect to behavioral specifications; (iii) Procedural security and dispute settlement: additional on-chain and off-chain mechanisms to resolve complaints or unforeseen situations arising from the runtime usage of smart contracts. Alternative smart contract programming languages to the ones that are in use today might be an interesting aspect to tackle, both from a security point of view and from a market adoption point of view. The merging of smart contracts and legal contracts is another important question that will require cross-disciplinary research and development. Furthermore, smart contracts should be designed in a way where personalized data is only revealed to those actors involved in the process who need to know explicit information. Smart contracts will need to be compliant with privacy-preserving regulations (privacy by design).

As indicated above, many smart contract use cases will only be possible interplaying with other technologies like big cata applications and the “Internet of Things.” Such an interplay of technologies can pave the way for completely new products, services, and asset classes over the decades to come. However, many socio-political questions might also arise. Once all objects have been tagged with a unique blockchain address (identity), and can therefore be uniquely referenced in a blockchain network, and if they are controlled by more or less intelligence software, these devices could become autonomous economic agents in a man-machine economy. However, the questions of (i) whether and how we will transfer the mandate from humans to machines, (ii) what socio-political implications such developments could have, and (iii) how we want to shape such phenomena as a society, need to be publicly discussed before designing such systems.

History of Smart Contracts

While the term “smart contract” has become more mainstream since the advent of first Bitcoin and then Ethereum, it was first coined by Nick Szabo in 1996, and thus precedes the development of blockchain networks. It was in the early days of the Web when Szabo pointed out that the digital revolution would not only create new institutions but could also formalize economic and social relations. That was twenty years before Ethereum saw the light of day, and created a renaissance of this term. Szabo justified the term “smart” with the functionality that comes with digital contracts to be automatically verified and executed: a digital transaction log that automatically executes the terms of an agreement with the aim of fulfilling the agreed contractual terms. Automatic management of relationships and obligations of all parties involved, purely with computer code.

As opposed to traditional contracts, which guarantee contractual security with reactive procedures using instruments of the existing legal system, smart contracts—according to Szabo—could proactively prevent this reactive “after the fact” security through automated mechanisms, by making a potential breach of contract possible but expensive. Szabo pointed out that the reactive procedures of existing legal systems could be minimized but never fully eliminated. To provide for such a level of proactive security, smart contracts should be automatic and (a) observable, (b) verifiable, and (c) enforceable. In any case, Szabo warned that (d) the privacy of the data must be guaranteed by only revealing necessary data, and only to contracting parties that are entitled to view it.

Szabo was very specific in his descriptions of how to technically formalize these relationships, and listed a variety of cryptographic methods that could be used, such as public-key cryptography and digital signatures, and in particular, blind signatures[^4] and zero-knowledge proof cryptography.[^5] Some of these cryptographic methods described by Szabo can be found in the implementation of Bitcoin. However, Szabo was much more far-sighted in his thought processes than Satoshi and many other early developers of Bitcoin and alternative blockchain networks, such as Ethereum. While he was referring to more privacy-preserving methods like blind signatures and zero-knowledge proofs back in 1996, these methods are only slowly finding their way into the blockchain world. Such privacy-preserving techniques also have the potential to meet the requirements of “Privacy by Design,” specified in the General Data Protection Regulation (GDPR) of the European Union, much better than the cryptographic methods that are currently used in most state-of-the-art blockchain networks (read more: Part 1 - Cryptography).

Szabo said that for smart contracts to “be embedded in the real world in the form of self-enforcing code,” they must be designed to be trustworthy and attack resistant, both against intentional attacks and against unintentional vandalism. However, at that time, Szabo had no idea how to fully decentralize trust and make such a system sybil attack resistant, and therefore described the necessity of a trusted intermediary. He described the economic utility function of a potential attacker and referred to concepts of theoretical computer science and information security when outlining solutions. In 1998, he went on to develop his ideas around smart contracts into real life implementation of P2P value transfer. He came up with an idea for electronic cash that would be as inflation resistant as gold, which he called “Bit Gold.” Bit Gold was never implemented because Szabo didn’t find a way to replace the trusted intermediary with a sybil attack-resistant system. Ten years later, Bitcoin’s major breakthrough was addressing exactly this issue with the introduction of “Proof-of-Work.”

Szabo envisioned an entanglement of different scientific fields in order to formalize smart contracts, such as law, economics, and cryptography, but criticized that these disciplines hardly communicated with each other. However, he was not the first to think about contractual automation. Two years earlier, Ian Grigg described his thoughts on Ricardian Contracts, specifying how to make real-world contracts machine readable and machine enforceable. He wanted to create a system that would allow maintaining human readability of contract intentions as well as resulting actions, before an agreement is executed, while optimizing machine authentication and processing through encryption techniques, such as hash functions and digital signatures. His aim was to guarantee the linking and processing of legal documents and related matters to provide more transparency and security than traditional legal procedures. The first hybrid solutions of smart contracts and Ricardian Contracts exist. “Openbazaar” is a P2P e-commerce platform that is already working with Ricardian Contracts.

Since the advent of the Ethereum project, the term “smart contract” has experienced a renaissance. Ethereum decoupled the concept of programming smart contracts from the underlying blockchain network processing the agreements. As opposed to Bitcoin, the Ethereum protocol aims to provide a cost-saving infrastructure where one can create any type of smart contract with just a few lines of code. Ethereum inspired many more projects to work on similar smart contract blockchain networks, such as “EOS,” “Cardano,” or “Waves,” all of which have varying degrees of technical maturity, scalability, network security, and often use different smart contracting languages.

Chapter Summary

A smart contract is a piece of software that is processed by a distributed ledger. It is a rights management tool that can formalize and execute agreements between untrusted participants over the Internet, and comes with inbuilt compliance and controlling.

Smart contracts can reduce the costs of formalization and enforcement of a simple agreement between two parties, the bylaws of an organization, or to create different types of tokens.

The term “smart contract” was first coined by Nick Szabo in 1996 and precedes the development of blockchain networks. It was still the early days of the Web when Szabo pointed out that the digital revolution would not only create new institutions but could also formalize economic and social relations.

Smart contract use cases range from simple to complex. The most complex form of a smart contract is a decentralized autonomous organization. Smart contracts can also be used to create tokens.

Smart contracts have the potential to disrupt many industries. Use cases can be found in banking, insurance, energy, e-government, telecommunication, music & film industry, fine art, mobility, education, and many more.

Oracles provide the external data necessary for the smart contract and trigger smart contract executions when predefined conditions are met. Oracles are services that find and verify real world occurrences and submit this information to a smart contract, automatically triggering state changes on the blockchain. The primary task of oracles is to provide these values to the smart contract in a secure and trusted manner. These data flows stem either from software (Big Data application) or hardware (Internet of Things).

Chapter References & Further Reading

Footnotes

[^1]: Principal-agent dilemma occurs when someone (the agent) has the power to make decisions impacting another person or institution (the principal), but fails to do so in their best interest, such as the relationship between politicians and voters, or managers and shareholders.

[^2]: The challenge with micropayments today is that the fee charged by third-party payment providers is higher than the micropayment itself.

[^3]: In computer security, “man-in-the-middle attacks” refer to incidents where an attacker relays and possibly alters the communication between two parties who believe they are directly or secretly communicating with each other.

[^4]: Blind signatures are digital signatures that disguise the content of a message before it is signed. They can be verified against the original message just like a regular digital signature.

[^5]: Zero-knowledge proof cryptography allows the validation of information without revealing that information to the verifier of that information.

Clone this wiki locally