What is a smart contract, and how does it work?

This is a topic that has grown increasingly difficult to answer without igniting the digital equivalent of a bar fight. Most people immediately think “Ethereum,” “Solana,” “TRON,” or any of the other decentralized in name only (DINO) projects that have popped up since the genesis of Bitcoin when that term is spoken in a conversation.

Most new or inexperienced participants in this ecosystem believe that initiatives like Ethereum originated the phrase “smart contract” and that these projects invented them.

When people hear the term “smart contracts,” they typically think of decentralized autonomous organizations (DAOs), decentralized exchanges, automatic market makers, and other Turing-complete Ethereum applications. Anything that doesn’t approach that level of sophistication is likely to be disregarded as a smart contract by the majority of people. Nothing, however, could be further from the truth.

Introduction to Smart Contracts

Nick Szabo developed the term “smart contracts” in 1996, long before Satoshi Nakamoto had even thought of a blockchain. They have nothing to do with decentralized autonomous organizations (DAOs), decentralized exchanges, or any of the other concepts that come to mind when people hear the term.

The notion was far more basic and straightforward than any of the systems created on top of Ethereum. Smart contracts were essentially strategies to move the enforcement of traditional legal contracts out of the realm of governmental authority and into the realm of software and hardware enforcement as much as possible.

To quote Szabo,

“New institutions, and new ways to formalize the relationships that make up these institutions, are now made possible by the digital revolution. I call these new contracts ‘smart,’ because they are far more functional than their inanimate paper-based ancestors. No use of artificial intelligence is implied. A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”

There is no mention of “Turing completeness,” “decentralized autonomous organization,” or anything else in this description that implies a certain amount of complexity is required to be termed a smart contract. Some of the examples Szabo mentioned as forerunners to smart contracts — or, as I’d call them, “proto-smart contracts” — are very basic things like vending machines or point-of-sale (POS) systems.

This is a “proto-smart contract” integrated into hardware in the case of the vending machine. It implements a very simple “contract”: a user inserts coins into the machine, and the machine dispenses the food that the user has purchased. Overall, the machine’s security is determined by its physical hardware. It takes a long time and a lot of effort to open a vending machine and take food without paying for it, therefore that’s unlikely to happen in most circumstances without the culprit being discovered by police authorities or a worker at the location where the vending machine is located.

Another key point to remember is that contracts usually entail numerous steps between the parties concerned; very seldom can a contractual agreement be completed in a single step. The user inserts coins into the vending machine, which allows them to choose what they want to buy. They make their choice, and the machine dispenses the items. This is a four-step process: first, insert money; second, the machine advances to the good selection process; third, the user makes their selection; and fourth, the machine dispenses the user’s selection.

Here’s an important point to think about: The vending machine and the customer are both involved in the contract’s dynamic. It creates a very basic clause that is completed in the four phases outlined above: If you give the vending machine money, it will offer you food.

But what if you put money in the vending machine and the food isn’t delivered properly? Who is in charge of this issue? Who do you turn to address the problem and correctly resolve the “contract” when it has failed to do so on its own? To fix this failure to execute, either locate an employee at the business where the vending machine is located or contact the owner’s support line if one exists. Someone would have to intervene and correct the contract’s erroneous execution.

This leads me to an essential point: “smart contract” does not imply a lack of trust in third parties by definition. “Smart contracts generally require trusted third parties, exemplified by an intermediary, who is involved in the performance, and an arbitrator, who is invoked to resolve disputes arising out of performance (or lack thereof),” according to Szabo.

Consider this: In any sort of contract, one party or the other has the opportunity to cheat and fail to fulfill their contractual obligations. It’s entirely possible that the contract won’t work out. Someone or something, which is by definition a third party, must interfere in the event of a wrong execution and fix the situation to ensure the proper execution and, if necessary, impose sanctions for the improper execution.

The majority of proto-smart contracts, as well as fully smart contracts, are not trustworthy. Most of these aren’t even possible to automate on both sides. Consider someone purchasing a pack of cigarettes at a gas station using a debit card at a POS machine. After the POS system marks their payment as complete, the consumer must trust the person on the other side of the register to offer them the smoke. If the cashier refuses, the consumer must rely on their bank or card processor to issue a refund because they did not receive what they had paid for.

The objective of a Smart Contract

Let’s go over the four main objectives of contract design as defined by Szabo now that we’ve established the conceptual trust models of proto-smart contracts.

Observability: The persons (or things) participating in the contract must be able to see that the other party is adhering to the contract’s terms, as well as be able to demonstrate that they are adhering to the contract’s terms.

Verifiability: All parties to a contract must be able to demonstrate to the contract’s arbitrator that the contract has been performed correctly or that one or more parties have breached their contractual responsibilities.

Privacy and Space: The contract should be structured in such a way that it is as private as feasible. The amount of private information regarding the contract or the parties involved that is disclosed to the public or other third parties beyond them should be confined to the absolute minimum required for contract execution.

Enforceability: There must be a mechanism in place to ensure that things run smoothly, even if one or more parties violate their contractual commitments, and the contract should be written in such a way that enforcement is unlikely. Contracts should encourage parties to fulfill their contractual responsibilities voluntarily.

The design goals outlined above effectively exist to ensure that contracts execute correctly in the vast majority of cases, while also protecting contract details from the prying eyes of the public unless revealing those details is necessary to ensure that the contract ends with proper execution of the terms.

Principles of Smart Contract

Smart contracts must have cryptographic protocols as part of their definition. “Basic building elements that implement the better tradeoffs between observability, verifiability, privity, and enforceability in smart contracts,” according to Szabo.

So, what are the fundamental building blocks for implementing cryptographic protocols? Of course, there are cryptographic key pairs.

To participate in a smart contract, the main participants and arbitrators must each produce a private key and then derive a public key from it to share with the other participants as a means of interacting with each other during the smart contract process. There should also be a digital signature scheme in place for participants to sign off on the smart contract’s terms and execution, as well as provide proofs in the form of those signatures to the arbiter if necessary, demonstrating their agreement to the contract’s initial terms and whether or not the contract was executed properly as defined by those terms.

This establishes a fundamental need for anybody involved in the construction and execution of smart contracts: the safeguarding of private keys. For two reasons, this is critical.

To begin with, if your smart contract’s private key is compromised and stolen, the thief can make it appear as if you intended to execute the contract inappropriately. Second, by doing so, the thief gives the impression to the other smart contract participants that you are an untrustworthy counterparty (and potentially to the public at large as well). It tarnishes your reputation.

At the very least, such an occurrence would make the smart contract’s counterparty reluctant to participate in transactions in which you are a counterparty. Furthermore, if the breach of contract occurred publicly or was somehow known to the public, the public’s apprehension to participate in smart contracts with you would most likely spread to the rest of the world. Reputations can be linked to legal identities or simply pseudonyms, therefore the degree of reputational harm varies depending on what a reputation is linked to, but reputational harm can still happen. The only difference is the difficulty of later distancing yourself from that identity with a tarnished image (i.e., a pseudonym on the internet versus your real name).

Let’s have a look at a very basic smart contract now.

When Szabo first created the word in the 1990s, David Chaum’s digital e-cash was one of the most interesting cryptographic tools of the time (described in-depth here). I’ll just give you a quick rundown: Consider e-cash to be digital notes issued by a government (the arbitrator of the contract). These notes are essentially huge, random integers with the authority’s cryptographic signature certifying their validity. To use one, hand it over to the person you’re paying, who will redeem it with the central authority and receive a new one. Furthermore, because of the way the signing process works, the authority is unable to determine who pays who, making it a very private transaction.

The spender and receiver are involved in this smart contract, with the central authority deciding whether or not a transfer between the spender and receiver has occurred. Now, part of the architecture of such a smart contract back then was based on two modes of use: one, with an active internet connection, redeeming digital notes as soon as you receive them; and two, postponing the redemption process and redeeming digital notes in batches.

There should be no chance of being deceived using a note that has already been redeemed by the authority if the first approach is used with an honest central authority. In the case of offline use, the receiver risks having a consumer spend a digital note multiple times, with only one of those recipients being able to redeem it at the authority. Everyone else is out of pocket.

In future contracts, the defrauded party (or parties) will have no choice but to evaluate the reputation of the person who fooled them differently. They would rationally refuse to furnish products or services to that customer until they had successfully redeemed their digital note from the central authority if they would do business with the customer at all in the future.

In a Charmian e-cash system, the enforcing authority is the central authority, and the users are oracles who provide data to that authority for it to impose a result. When a digital note’s recipient goes to redeem it, they are acting as an oracle (a person or thing claiming something, and in cases where possible, providing proof that something is true). They are announcing to the authorities, as an oracle, that they have been paid a digital note by someone. Their proof of that declaration is the digital note itself, and the authority will only issue a fresh one if it believes the oracle’s statement is correct.

It’s worth noting for future reference that third-party oracles can be used in a transaction, for example, two people transferring digital notes to a third-party oracle with the goal of all of the notes being transferred back to one participant or the other depending on the outcome of a football game. The only real difference between this and the simple example of a basic transaction is that the oracle’s statement’s truthfulness cannot be checked by an automated machine in the same way that cryptography allowing a basic note transfer can. Many of the statements made by oracles can only be verified by humans.

So, what does this finally demonstrate about the smart contract’s nature? Either the incentives for both parties to perform honestly are sufficient (i.e., the merchant would refuse to sell you food in the future if you cheat them), or they must trust the arbitrator to effectively enforce the contract, leaving no opportunity for dishonesty on the part of the consumer. So, not only must both parties trust each other to act honestly, but if one party attempts to act dishonestly, the other party must trust the arbiter to protect them. There is no way to get out of it.

Is Bitcoin a Smart Contract Platform?

So, let’s bring it all back to Bitcoin. Bitcoin is a smart contracting platform in and of itself. That’s what it is, has always been, and was intended to be.

Without relying on a single central authority, the Bitcoin network operates as a massively distributed arbiter, enforcing the proper execution of smart contracts. It establishes a system for contracts to be visible, verifiable and enforced. The one aspect of a contract on which it has historically fallen short is privity – all of the provisions of Bitcoin smart contracts are visible to everyone. It does, however, preserve the real identities of persons who engage in contracts, and Taproot’s recent activation is a huge step forward in terms of hiding contract clauses until they are needed to enforce them.

When a Bitcoin transaction takes place, the sender acts as an oracle, claiming the ability to spend money and proving it with a digital signature. The receiver, as well as every other network participant, monitors the transaction’s progress and verifies that the digital signature is correct. Then, whichever miner succeeds in finding the next block steps in and “executes” the smart contract by inserting the transaction in a block and propagating it around the network in place of a central authority. Finally, the receiver, as well as the entire network, validates that each signature and contract witness in the block is correct.

To be effectively implemented, contracts conducted on Bitcoin still require trust in an arbitrator, but the arbitrator is a distributed network of everyone verifying everyone else. The more people who are active in that network and cross-check each other, the more likely it is that the network will always execute things correctly. That is Bitcoin’s single greatest achievement, but it is also its greatest constraint (and any blockchain that has any shred of actual decentralization).

The blockchain (or rather, all of the nodes on the network verifying their copies of it) can impose all kinds of rules on its own, such as transactions only being processed if the digital signatures authorizing them are correct, or only after a timelock prevents a coin from moving until a certain amount of time has passed, and so on. Because an oracle either publishes 100 percent verifiable cryptographic data straight to the network or doesn’t, it can automatically enforce any contract that simply involves entering cryptographic data. However, Bitcoin cannot automatically enforce any contract that needs the input of data that cannot be represented in verifiably correct cryptography, such as a bet on a football game. There is no method for a blockchain to verify that an oracle’s score at the end of the game is correct.

So, while Bitcoin can make basic transactions or transactions with very simple cryptographic requirements trustless, it cannot make any arbitrary contract trustless. Only contracts that can be demonstrated to be 100 percent correct using data that can be published on the blockchain may be trusted to be enforced.

Now, different blockchain architectures can allow for varying degrees of complexity to be demonstrated only through on-chain data, but it necessitates a discussion of security considerations that is beyond the scope of this article. Any contract including conditions that cannot be verified 100 percent by publishing data on-chain must, by necessity, introduce trust; yet, as previously stated, the presence of a third party does not preclude something from being a smart contract.

To answer the question, “What exactly is a smart contract?” Almost everything takes place on a blockchain.