What is a smart contract?
This is a question that, these days, has become impossible to answer without starting the digital equivalent of a bar fight. The minute that term is thrown out in a conversation, most people immediately think “Ethereum,” or “Solana,” or “TRON” or any of these decentralized in name only (DINO) projects that have popped up over the years since the inception of Bitcoin.
Most new or uninformed people in this ecosystem probably think that the term “smart contract” was coined by projects like Ethereum, and that these projects literally invented them.
When they hear “smart contracts,” they probably immediately start thinking about decentralized autonomous organizations (DAOs), decentralized exchanges, automatic market makers and other such Turing-complete applications on Ethereum. Conceptually, anything that doesn’t approach that level of complexity is probably immediately dismissed by most people as not a smart contract. But nothing could be further from the truth.
The Birth of Smart Contracts
“Smart contracts” as a term was coined by Nick Szabo back in 1996 before the idea of a blockchain was even a twinkling in Satoshi’s eye. They had nothing to do with DAOs, or decentralized exchanges or any of these types of constructs that people tend to think of when they hear the term.
The concept was drastically more simple and basic than any of these systems built on top of platforms like Ethereum. Smart contracts were simply taking conventional legal contracts and finding ways to move the enforcement of them outside of the scope of governmental jurisdictions into the realm of enforcement through software and hardware as much as possible.
“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.”
Nowhere in this definition is mentioned “Turing completeness,” or “decentralized autonomous organization” or anything that implies that some minimum level of complexity is required in order to be considered a smart contract. Some of the examples Szabo gave as forerunners to smart contracts — or as I would define them, “proto-smart contracts” — are very basic things, such as vending machines or point-of-sale (POS) systems.
In the instance of the vending machine, this is a “proto-smart contract” embedded in hardware. The “contract” it implements is very simple: a user inserts coins into the machine, and the machine dispenses the food that the user purchased. Overall, the security of the machine boils down to the actual physical hardware. It’s very time consuming and difficult to open a vending machine and remove food from it without paying for it, so that’s very unlikely to be something that can be done in most cases without the perpetrator getting caught by law enforcement or some employee at the place where the vending machine is situated.
Another important detail is that contracts generally involve multiple steps between the involved parties; very rarely can something involving a contractual arrangement be facilitated in a single step. The user inputs coins into the vending machine, which then allows the user to select what they are purchasing, the user then makes their selection and the machine dispenses the goods. That’s a four step process: one, inserting money; two, the machine advancing to the good selection process; three, the user making their selection; four, the machine dispensing the user’s selection.
Now, here is an important point to consider: The dynamic of the contract involves two parties, the vending machine and the customer. It instantiates a very simple clause accomplished in the four steps defined above: give the vending machine money, the vending machine gives you food.
But what happens if you put your money into the vending machine and the food isn’t properly dispensed? Who deals with this problem? Who do you go to in order to get it solved and resolve the “contract” properly after it failed to do so on its own? To resolve this failure to execute, you would need to either find an employee at the business that the vending machine is situated at or contact the support line, if any, for the owner. Someone would have to step in and actually correct the improper execution of the contract.
This brings me to a very important point: “smart contract” does not by definition mean devoid of trust in third parties. In fact, in the words of Szabo, “Smart contracts often involve 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).”
Really think about that: In any type of contract, the potential exists for one party or another to cheat and refuse to make good on their end of the contract. It is always possible for the contract to not execute properly. Someone or something, that is by definition a third party, has to intervene in the event of improper execution and correct for that to enforce the appropriate execution and potentially enforce penalties for the initial improper execution if appropriate.
Most proto-smart contracts and even fully smart contracts are not trustless. Most can’t even be automated on both sides. Think of the case of someone buying a pack of cigarettes with a debit card on a POS machine at the gas station. That customer actually has to trust the human being on the other side of the register to hand them the cigarettes after the POS system flags their payment as completed. If the clerk refuses to do so, the customer has to trust their bank or the card processor to refund the payment because they did not receive what they paid for.
The Goals Of Smart Contracts
So, now that we’ve established the conceptual trust models of proto-smart contracts, let’s go over the four important objectives of designing a contract as delineated by Szabo.
Observability: The people (or things) involved in the contract have to be able to see that the other party is performing correctly to the terms of the contract, and be able to prove that they themselves are performing correctly to the other party.
Verifiability: All parties to a contract need the ability to prove to the chosen arbitrator of the contract that it has either been performed correctly or that one party (or parties) have breached their obligations in the contract.
Privity: The contract should be structured as privately as possible. The amount of private information about the contract or the parties involved that is disseminated beyond them to the public or other third parties should be kept to the bare minimum necessary to execution of the contract.
Enforceability: There needs to be some mechanism of ensuring that things execute correctly, even in the case of one or more parties violating their obligations under the terms of the contract, and as well, the contract should be structured to make the likelihood that enforcement will be needed very unlikely. Contracts should encourage parties to voluntarily comply with their obligations under the terms.
The design goals above effectively exist to provide the highest odds that contracts will execute correctly in the vast majority of cases, while simultaneously protecting the details of the contract from the prying eyes of the public unless revealing those details is absolutely necessary to give the contract the highest odds of ending with proper execution of the terms.
Primitives Of Smart Contracts
Cryptographic protocols are a definitional component of smart contracts. Szabo called them the “basic building blocks that implement the improved tradeoffs between observability, verifiability, privity, and enforceability in smart contracts.”
So, what are the basic primitives required to implement cryptographic protocols? Cryptographic key pairs of course.
In order to engage in a smart contract, the principal participants and arbitrators are each required to generate a private key and then derive a public key from that to share with the other participants as a means to interact with each other through the process of the smart contract. There also needs to be a digital signature scheme for the participants to sign off on the terms and execution of the smart contract, and also provide proofs in the form of those signatures to the arbiter if necessary, showing the agreement to the initial terms of the contract and whether or not the contract was executed properly as defined by those terms.
This introduces a foundational requirement for any party involved in the creation and execution of smart contracts: protecting your private keys. This is very important for two reasons.
First, obviously if your private key involved in a smart contract is compromised and stolen, the thief can make it seem like you attempted to execute the contract improperly. Second, the thief doing so creates the perception to the other participant(s) of the smart contract that you are an untrustworthy counterparty (and potentially to the public at large as well). It gives you a bad reputation.
At a bare minimum such an occurrence would lead to the counterparty of that smart contract likely not wanting to involve themselves in contracts to which you are a counterparty. Beyond that, if the breach of contract occurred publicly or somehow was revealed to the public, that hesitance to get involved in smart contracts with you would likely spread to the wider public as well. Reputations can tie themselves to legal identities, or just pseudonyms, so the degree of reputational damage can vary depending on what a reputation is tied to, but reputational damage can still occur. The difference is only in the difficulty of separating yourself from that identity with a damaged reputation after the fact (i.e., a pseudonym on the internet versus your real name).
Let’s look at a very basic example of a smart contract now.
In the 1990s, when Szabo originally coined this term, one of the most exciting cryptographic tools of the time was David Chaum’s digital e-cash (described in depth here). I will just quickly summarize though: Think of e-cash as digital notes issued by a central authority (the arbitrator of the contract). These notes are simply large, random numbers with a cryptographic signature from the authority proving they are valid. To spend one, you give it to the person you are paying and they redeem it with the central authority and are issued a new one. Also, because of how the signing process works, the authority cannot figure out who pays who, so it is very private.
In this smart contract, you have the spender and receiver, and the central authority arbitrating whether or not a transfer between the spender and receiver has occurred. Now, part of this design back then was based around two modes of using such a smart contract: One, with an active internet connection redeeming digital notes the instant you receive them; or two, delaying the redemption process and redeeming digital notes in batches.
In the case of using the first method, with an honest central authority, there should be no risk of being defrauded with a note that has already been redeemed by the authority. In the case of offline use, the receiver runs the risk that a customer spends a digital note in multiple places, meaning that only one of those receivers can actually redeem it at the authority. Everyone else loses money.
The cheated party (or parties) have no option now but to assess the reputation of the person who cheated them differently in future interactions. Rationally, from that point onward they would refuse to render goods or services to that customer until after successfully redeeming their digital note from the central authority, if they would even engage in business with the customer at all in the future.
The central authority in a Chaumian e-cash system is the enforcing authority, and the users are oracles providing data to that authority to enforce an outcome. When the receiver of a digital note goes to redeem it, they are functioning as an oracle (a person or thing claiming something, and in cases where possible, providing proof that something is true). They are stating, as an oracle to the authority, that they have been paid a digital note by someone. Their proof of that statement is the digital note itself, and they will only be issued a new one by the authority if it deems the statement that the oracle has made is valid.
It’s worth pointing out for later that it is possible to have third-party oracles involved in a transaction, i.e., two people transferring digital notes to a third-party oracle with the purpose of all of the notes being transferred back to one participant or the other based on the outcome of a football game. The only real difference here compared with the simple example of a basic transaction is that the truthfulness of the oracle’s statement cannot be verified by an automated computer in the same way that cryptography authorizing a basic note transfer can be. Only human beings can verify many kinds of statements that oracles can make.
So, what does this ultimately illustrate regarding the nature of this smart contract? Either the incentives for both parties to act honestly are good enough (i.e., the merchant won’t sell you food in the future if you cheat them), or they have to trust the arbitrator to properly enforce the contract so the customer has no room to act dishonestly. So, not only do both sides have to trust each other to act honestly, but if a participant tries to act dishonestly, the other participant has to trust the arbitrator to act honestly to protect them. There is no way to escape that.
Bitcoin As A Smart Contract Platform
So, let’s bring all of this home to Bitcoin. Bitcoin is literally a smart contracting platform. That’s what it is, what it always was, what it was designed to be.
The Bitcoin network functions as a giant distributed arbitrator enforcing the proper execution of smart contracts without relying on a single central authority to do so. It provides a mechanism for contracts to be observable, verifiable and enforceable. The only quality of a contract it has fallen short on historically is privity — all the terms of Bitcoin smart contracts are public for all to see. It does, however, at least protect the real identities of those engaging in contracts, and Taproot’s recent activation is a massive improvement in terms of hiding the clauses of a contract unless needed to enforce them.
Every time a Bitcoin transaction occurs, the sender acts as an oracle claiming the ability to spend money and providing proof in the form of a digital signature. The receiver, and every single participant on the network, observes the transaction propagating through the network and verifies that the digital signature is correct. Then, whatever miner successfully finds the next block steps in and takes the place of a central authority and “executes” the smart contract by including the transaction in a block and propagating it through the network. And finally, the receiver and the entire network verifies the correctness of every signature and contract witness in the block.
Ultimately, contracts executed on Bitcoin still require trust in an arbitrator to execute properly, but the arbitrator is a distributed network of everyone cross checking everyone else. The more people involved in participating in that network cross checking each other, the more trusted the network is to always execute things properly. That is the single greatest achievement of Bitcoin, but it’s also the greatest limitation of Bitcoin (and any blockchain that has any shred of actual decentralization).
The blockchain (or rather all of the nodes participating on the network verifying their copy of it) can enforce 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 preventing a coin from moving until a certain time expires, etc. It can automatically enforce any contract that only requires inputting cryptographic data, because an oracle either publishes 100% verifiable cryptographic data directly to the network or they don’t. But it cannot automatically enforce properly any contract that requires inputting data that cannot be represented in cryptography that is verifiably correct, i.e., Bitcoin cannot automatically enforce that a bet on a football game executes correctly. There is no way for a blockchain to verify the score at the end of the game that an oracle asserts is correct.
So, while Bitcoin can make the execution of basic transactions, or transactions with relatively simple cryptographic conditions, trustless, it cannot make the execution of any arbitrary contract trustless. Only contracts that can be proven 100% correct with data that can be published on the blockchain can be enforced trustlessly.
Now, different blockchain architectures can allow different degrees of complex things to be proven purely by on-chain data, but that involves discussing security tradeoffs that are outside of the scope of this piece. Any contract involving conditions not provable 100% by publishing data on chain requires, by necessity, introducing trust, but as discussed above, having a third party involved does not exclude something from being a smart contract.
So, to answer the question of “What is a smart contract?” Literally everything occurring on a blockchain.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
