Smart Contracts — The Blockchain Running Applications
A blockchain can do more than simply storing data; it can also run software — meet smart contracts.
This article is part of the Horizen Academy expert content and the chapter “What is a blockchain?”.
If you feel like there is more information in this article than you need, consider reading the advanced level version of it. It conveys the same concepts but in less detail and complexity.
Many people have said it and so do I: smart contracts are neither smart nor contracts. In most general terms they are pieces of software on a blockchain. A smart contract needs to be written in a specific language defined by the protocol of the blockchain it lives on.
A contract can be defined as an agreement between parties that binds them to something happening in the future. The term “smart” comes from the automatic execution of these digital “contracts”.
While the first cryptocurrency, Bitcoin, already supported rudimentary logic to be run on top of it using a scripting system called Scrypt. Sophisticated smart contract languages like Solidity enabled more elaborate smart contracts on platforms such as Ethereum.
There is a tradeoff between simple scripting systems and more sophisticated, Turing-complete ones. While the former does not allow for complex logic, it is easier to write programs and secure them. Feature-rich languages allow for more refined smart contracts, but they are more error-prone and harder to secure.
Security in the context of smart contracts means considering every possible way in which a contract could execute and to account for each of these scenarios. Simple smart contract languages have fewer potential use cases but make the possible states of the contract easier to enumerate, examine, and account for, resulting in easier to secure contracts.
Static Code vs. Contract Instance
The term smart contract can have two meanings. It can refer to static code in a given language or a contract instance, a dynamic object that executes the code. There is a similar distinction between programs and processes in operating systems.
“One can think of a smart contract instance as a trusted third party to which users can send coins, and that can distribute coins between the parties, according to conditions written in its static code.” — Dziembowski, Faust, Hostáková, State Channel Paper
Let’s look at some smart contract use cases below to develop an intuition for what smart contracts are good for.
Cryptographic Tokens
Cryptographic tokens or simply tokens are digital items on a blockchain. They can represent the right to use a platform, a financial asset, or a piece of digital real estate.
A hypothetical Netflix2.0 might sell Netflix-token and you would need to use one token each month if you want to access their streaming services. A token could also represent a share of a bond and ownership comes with regular interest payments and repayment at the maturity date.
Most tokens are issued on the Ethereum blockchain using the Ethereum Request for Comment (ERC-20) standard, which was first proposed by Fabian Vogelsteller.
A token is issued within a smart contract that defines the total supply and the conditions for token transfers, among other things. The ERC-20 token standard is a smart contract template that allows for easy issuance and integration with different wallets and exchanges. If you would like to take a closer look at the process of issuing a token or even try it out for yourself, here is an easy-to-follow guide for you.
Payment Channels
Another use case that is oftentimes not associated with smart contracts is payment and state channels. In most general terms, they allow for interactions happening off-chain to be just as trustless as if they were to happen on-chain. The most popular payment channel network is arguably the Lightning Network on Bitcoin.
Reducing the Need for Middlemen
Smart contracts promise to significantly reduce the need for middlemen, such as lawyers or notaries, and thereby reduce the cost of doing business. Most importantly, they save participants time by disposing of intermediaries. Many use cases can be constructed that achieve just that.
Imagine a sports club and its ticketing process. Instead of having a third party involved that takes fees, it only takes one open-source implementation of a ticketing platform to render many ticketing services obsolete.
An informal, high-level description of an algorithm is called pseudocode. As an example, here is what the pseudocode for a ticketing smart contract could look like:
program Ticketing
while (number of tickets sold <= max. amount of tickets available for the event)
{
if only personalized tickets can be issued {
ask buyer for personal details
safe personal details
put address on the whitelist
} if amount x is received from address Y {
if there is a whitelist && Y is not on the whitelist {
refund address Y
end program
} send Y the correct amount of tickets
increment "number of tickets sold"
} if address Y sends message "I want to sell" {
refund address Y
invalidate ticket
decrement "number of tickets sold"
}
}
Not only could the sale and refund for tickets be realized with smart contracts. An automated secondary market with self-enforcing rules could be built. While the example above is obviously an overly simplified, it should give you an idea of the kind of logic used in smart contracts.
The execution of certain actions by a smart contract is triggered by messages. These messages can be transactions transferring money or they could be messages only transferring data. We will get back to smart contracts getting triggered by data later.
When a set of conditions is combined to enable an application, this collection of smart contracts is called a dApp — a decentralized Application. The line separating smart contracts and dApps is slightly blurry though.
Decentralized Applications — dApps
Smart contracts are often discussed in the context of decentralized applications or dApps. A dApp can be pretty much everything, from a decentralized exchange to an auctioning platform or a game. You can find an extensive overview of what is on the market today on State of the dApps.
A dApp allows its users to perform a set of functions, tasks, or activities, just like any other application. Most traditional applications use API’s — application programming interfaces — to communicate with their various components, such as social media integrations, underlying databases, or microservices.
A dApp uses one or more smart contracts to communicate with its underlying blockchain but also non-blockchain components. The smart contracts can be used to detect incoming payments from users, issue payments to its users, to serve as an escrow, or to trigger an action based on some form of submitted data.
We are still in the early stages of decentralized applications. There have been and will be many growing pains. Some bugs have caused a loss of funds for their users, others make inefficient use of on-chain transactions. While well developed and audited smart contract libraries will make the development of dApps easier and more secure, scaling approaches like sidechains can allow the communication of smart contracts to scale. Smart contract platforms are specifically designed to enable not just money on the blockchain, but also the deployment of smart contracts and dApps.
Smart Contract Platforms
The digital world seems to favor winner-takes-all or at least winner-takes-most scenarios — think Google, Facebook, Netflix, or Amazon. It is conceivable that the market for smart contract platforms will develop in a similar direction. Better tech attracts better developers, which build better tools and libraries, which make it easier for projects to use the platform, which in turn brings in more developers.
Not only does this make the platform itself more attractive. It is easier to integrate tokens into existing wallets; listing on exchanges is simplified with widely accepted standards, and the interoperability between dApps is increased. All this might play out very differently, and there is a lot of debate in the space about it. But from today’s perspective, a winner-takes-most scenario definitely has to be accounted for with a non-zero probability.
But there might be an important differentiator to the centralized web of today: Users can own their data on the underlying blockchain. Lock-in effects are reduced, and switching from one dApp to another might come at a lower cost than today. The Fat Protocol thesis, proposed by Joel Monegro in 2016, describes this effect of value being captured in the protocol layer, rather than the application layer. Today, most people oppose the thesis, but it still holds some water and is regularly discussed.
We wanted to include this little excursion to account for the multi-disciplinary nature of blockchain technology. It’s not just technology. It’s a mix of economics, socio-economics, game theory, computer science, and much more.
In order to consider yourself an “expert” in the field, you should be aware of some of the discussions and thought experiments that go beyond the tech itself. But for now, let’s move on.
Scaling with Smart Contracts
Smart contracts put an additional burden on the limited throughput of a blockchain. Not only does it need to store transactions and data clearly visible to the user. Many data-only transactions are used for communication between smart contracts. The launch of CryptoKitties put a lot of stress on the Ethereum blockchain, resulting in a sharp rise in transaction fees and long confirmation times.
Using the Right Accounting Model
There are two different balance or accounting systems in blockchains — the UTXO model and the Account-based Model.
“The first model is a directed graph of assets moving between users, the second is a database with the current network state.” — Dmitry Mishunin
The account model is used by most smart contract platforms because it makes the development of smart contracts more intuitive and is less data-intensive. There can be two types of accounts:
- private key controlled user accounts
- contract-code controlled accounts.
Each has its own balance, storage, and code-space for calling other accounts or addresses.
Moving Data Off-Chain
On top of the protocol-layer efficiency gains achieved by the account model, second-layer technologies like state channels are a promising approach to make smart contract platforms scale. They are one of several techniques for moving state modifications off-chain, relocating the required operations to a secondary environment where they can be performed at a lower cost.
Only the opening and closing of a state channel between two parties requires an on-chain transaction. After that, the two parties can interact almost indefinitely without broadcasting any updates to the blockchain.
“[T]he interaction of the parties with the contract instance is always “local”, i.e., the parties themselves compute the new states […] and then just exchange signatures [on it].” — Dziembowski, Faust, Hostáková, State Channel Paper
Parallelizing Processes
Another scaling approach is using sidechains. While sometimes referred to as a second-layer technology as well, it is actually an approach based on parallelization. A sidechain is a blockchain in itself with the ability to communicate with a central mainchain. This communication can comprise the exchange of data or assets.
A dApp can be launched on a dedicated sidechain where parameters are optimized towards the specific needs of the application at hand. It can even run a different consensus mechanism than the mainchain. Depending on the specific construction, incentives might have to be provided in order for nodes to run sidechains (in a PoS sidechain model) or for miners to perform merged mining (in a PoW sidechain model).
There are many approaches to enable scalable smart contract platforms, oftentimes also combining different methods. But besides creating systems with sufficient throughput to enable large scale adoption of smart contracts and dApps, there is another problem to solve: the oracle problem.
The Oracle Problem
The promise of smart contracts is to allow trustless execution with automatically enforced rules. But can they actually live up to this promise?
Most assets are subject to their respective local jurisdiction. This means a contract, no matter if smart or not, requires additional trust in the jurisdiction besides the trust put in the contract itself. Possession in a smart contract does not equal possession in the real world. Just as with regular contracts, the terms can be subject to changing circumstances and interpretation thereof. An illegal contract is not legally binding. We will need to see an entirely new generation of tech-savvy lawyers emerge to enable a meaningful adoption of legally binding smart contracts.
The other another major challenge to overcome is called the oracle problem. A smart contract needs to learn about real-world events (depending on the use case) in order for it to function and execute. An oracle is an entity submitting data to a smart contract. The trust problem that comes with this is referred to as the oracle problem.
Imagine a smart contract running a betting platform in a supposedly trustless environment. An oracle needs to submit the result of a game in order to have the smart contract distribute funds to the winners. Because the oracle determines what a smart contract sees, it also controls what it does.
Centralized oracles are not considered a solution to the oracle problem. No matter what the actual implementation looks like, the incentives to untruthfully submit data might outweigh the benefits of acting honestly in some cases. And what is the point of having trustless execution on the basis of information provided by a trusted third party? As Jimmy Song puts it: “A smart contract that trusts a third party removes the killer feature of trustlessness.”
No matter if centralized or decentralized, an oracle will always come at a cost. Acting honestly must always be the most profitable strategy, and therefore strong incentives need to be in place for submitting truthful data. This is a problem that needs a game-theoretic evaluation and incentive design.
Prediction Markets
A use case for smart contracts highly reliant on an oracle is a prediction market. A prediction market creates a market for a specific event and market participants basically “trade outcomes”. The most notable projects working on prediction markets are Augur and Gnosis.
To illustrate let’s assume an event with a binary outcome: does team X or team Y win the Superbowl. A participant buys in for $1 and gets two futures contracts, one for each outcome. The futures contract whose outcome materialized pays $1, the other one $0.
With an equally likely outcome, a participant wouldn’t know which contract to keep and which to sell. Both should trade at around $0.50. If a participant has high confidence in one outcome, let’s say team X wins, he will sell the contract that pays in case Y wins.
If many people think alike, this creates an increasing demand for contract X and increasing supply for contract Y. Futures contract X rises in price, while Y gets cheaper, e.g. $0.70 vs. $0.30. The price of the futures contracts can be interpreted as the likelihood of the respective event happening, in this case, a 70% chance of team X winning.
What this construction relies on is some oracle providing information about the outcome of the event. Some trusted entity could submit this information, but this would create a dependency on a new type of intermediary. A decentralized solution to the oracle problem does not exist today.
Since prediction markets have the potential to influence the outcome of an event as Dan Finley suggests, it remains to be seen how they function on a large scale.
Before solving the problem of creating legally binding smart contracts, and the oracle problem, the use of smart contracts will be limited. The creation of tokens is a valuable use case, independent of the aforementioned current shortcomings. Another example of a potential use case would be in-game payments triggered by certain achievements that are objectively verifiable by code.
Summary
Smart Contracts can ensure objective execution on the basis of mutually agreed-upon terms enforced by code. They have the potential to reduce middlemen and thereby reduce cost and save time. They will most likely foster a closer connection between software developers and the judicial system.
The creation of tokens and the deployment of state- and payment channel networks are the most common use cases for smart contracts. Before we can see widespread adoption, we have to overcome some hurdles. Scaling issues have to be addressed because smart contracts running entirely on-chain put a lot of stress on their underlying blockchain. Second layer technologies such as state channels or parallelization approaches like sidechains could solve this.
For many use cases, smart contracts need to learn about real-world events through oracles. Centralized solutions remove the killer feature of smart contracts — trustlessness — while prediction markets might create incentives around the probability of an event in a problematic fashion. There is a long way to go before we see the broad use of smart contracts across different domains, but they are most definitely a concept worth exploring.
If you found this article valuable please consider visiting the Horizen Academy. There you will also find a further reading list below most articles, referencing great articles on the same subject.
Horizen Academy articles are available in three levels of complexity: Beginner, Advanced, and Expert. If you start reading an article only to realize it is too detailed or not detailed enough, you can simply switch levels using the sidebar.
Below there’s an overview of the entire content at the time of writing.
In case you want to follow me on Twitter: here you go;)
