Smart Contracts Explained (for Lawyers) part -1
For a few weeks now I’ve been experimenting with smart contracts. A smart contract is a program running on a blockchain that facilitates, verifies, and/or enforces arrangements between parties. It is particularly useful for managing payments, digital assets, digital identity, and IoT devices. It can also be useful for assessing performance, when performance is objectively measurable. The use case people are probably most familiar with today is buying, selling, and trading cryptocurrencies, like Bitcoin (BTC) and Ether (ETH). When you purchase or transfer cryptocurrency, a smart contract transfers the currency from one wallet to another, and records the transaction to the blockchain.
“A smart contract is a program running on a blockchain that facilitates, verifies, and/or enforces arrangements between parties.”
On the Ethereum blockchain, smart contracts are written in “Solidity”, a scripting language similar to JavaScript. In Solidity, terms and conditions are written as logical expressions (if-then, for loops, etc.) instead of legal prose. In this regard, writing a smart contract is nothing like writing a conventional contract. To write or even understand a smart contract, you need to have some familiarity with computer programming (see example below). But that will change eventually, and groups like OpenLaw (part of ConsenSys) are working to make smart contracts accessible through templates and markup language.
More than mere memorialization, a smart contract automates aspects of an agreement, bridging conventional contracts with enterprise technology, online services, and IoT devices. Implementing contractual terms in computer code isn’t new (e.g., automated trading and digital-rights-management), but what separates smart contracts from other programmatic contracts is immutability and consensus. Once a smart contract is launched onto the Ethereum blockchain, the code (i.e., “terms” of the agreement) cannot be changed. This gives the contracting parties assurance that the terms will be carried out as agreed — because no one can change the code. In addition, a consensus process is used whenever a transaction is recorded to the blockchain (like a distributed ledger), so all parties to the contract have the same information, at about the same time. Moreover, the code ensures that the obligations are carried out automatically. So even if the parties don’t trust each other, to some extent, they can trust that the contract terms will be carried out in a deterministic and transparent way.
“[Parties] can trust that the contract terms will be carried out in a deterministic and transparent way.”
When exchanging things of value — say for example, buying music on-line — the contract can act as an escrow, taking possession of both the item and the payment, and releasing them only when the terms of the agreement are satisfied. This way, the seller can be certain he or she will be paid, and the buyer can be certain he or she will receive the content. No intermediary is needed to facilitate the transaction. Purchasing a song or album is a relatively trivial transaction, but you can imagine how this would play out when more is at stake.
“No intermediary is needed to facilitate the transaction.”
Besides certainty and trust, Solidity introduces useful features that many attorneys may be unaccustomed to, including the ability to “inherit” contract terms, “interface” with other contracts, and “require” verification.
Inherit
Inheriting is sort of like incorporating by reference some or all the terms of one contract into another. Even if there are only portions of a contract you want to incorporate into another, Solidity’s inherit feature allows you to do so. What’s useful is that you can write a term once and replicate it consistently across all contracts incorporating that term.
Interface
An interface allows your contract to interact with other contracts on the blockchain. Say you have a contract that is contingent upon information or data in a third-party contract; adding an “interface” allows your contract to access that third-party information or data. If, for example, you had a contract that was contingent on prices set by a third-party, and that third-party had a smart contract with a function that reported its current prices, with an interface, your contract could read the prices and factor them into the execution, perhaps to match prices.
Require
“Require” is a feature that verifies if something is true before proceeding with a term of the contract. For example, it could be used to verify that a wallet has sufficient funds before allowing a purchase. It could also be used to the verify the identity of the party trying to enter into a contractual transaction; for instance, by checking the address and signature from where the request came.
When a smart contract is associated with IoT devices like sensors, requirements can be used to verify real world conditions, such as location, weather, traffic, bio-metric information, and more. The possibilities are endless. As an example of how this might work, an airline could issue a smart contract that releases funds to passengers if a flight is canceled.
This is a simplified explanation of just a few of the nifty features of Solidity. There are obviously nuances to this, but at a high level, you can see how these features can prove useful in the automation of contractual arrangements. At the same time, there are also some drawbacks, which I’ll address in another post. I should also mention that Solidity is not the only smart contract language; just like Ethereum is not the only blockchain. In addition to Ethereum, there are also Cardano, EOS, Hyperledger Fabric, Stellar, and other blockchain networks. Each has its own language for writing smart contracts, and each language has its advantages and drawbacks. But we’ll cover those later too. Stay tuned!
