The concept of the smart contract was introduced by Nick Szabo in 1993, but it wasn’t until cryptocurrencies really took off before smart contracts have become possible. There are generally two types of contracts–those for goods and those for services. When a service provider or seller provides the goods or services to the buyer, performance has been completed. When the buyer pays the service provider or seller, contract satisfaction is completed. Here, the concepts of contract performance and satisfaction are applied to the blockchain. It has been close to one year since I was first introduced to the concept of the blockchain.
In those first days, I remember thinking that I would never be able to master the concepts and gain an insightful understanding of the topic. Prior to this, I was familiar with the concept of cryptocurrencies, such as Bitcoin and others. In the early days, there were only a few players in the space, but now, the global digital economy boasts more than 600 different forms of cryptocurrencies and each has their own method of ensuring the integrity of the transaction and guaranteeing the transfer of funds. Two of the most appealing aspects in the use of cryptocurrencies are the complete anonymity and the decentralized manner in which the transactions are regulated; i.e. there are no banks, governments or watchdogs.
The entire infrastructure is monitored through complicated computer algorithms where computers run computations until they ‘guess’ a very specific set of values that represent a particular transaction. Once the transaction has been guessed twice, the transaction is considered valid and that locked and replicated to all copies of the ledger. When five transactions are locked, that group is called a block and is closed. Each of these blocks have a start sequence and an end sequence and are strung together, one after another–hence, the blockchain. From a legal perspective, this concept can be translated to contracts by building software that interacts with the blockchain to complete specific milestones within the terms of the contract. Evidence of completion is submitted and tracked by the software and the payout transactions are completed against the blockchain.
For example, imagine a situation where a writer were paid when submitting an article. The author would upload the article, and the application would accept the article and record a transaction on the blockchain. Yes, this is a simple illustration and one that is in place today using regular ‘hard’ currency, but the benefit to this scenario is that there is no bank. The author doesn’t need to configure routing numbers and accounts, along with trial deposits and withdrawals. The transaction takes the sender’s hash, along with the recipient’s hash, the transaction ID and amount, and is recorded to the blockchain. It is forever recorded and is reportable by anyone with an understanding of the details of the transactions.
By taking this example one step further, we can add a reviewer where after the article is submitted, an event is triggered requiring the article to be reviewed by a third party. The reviewer completes the review and notifies the system, which then posts the transaction of paying the review to the blockchain. Once acceptance is made, a second transaction paying the author is posted as well. Here, we don’t need three different banks, routing numbers and accounts. The system interacts with only one ledger–the blockchain.
Prior to this model, each author would enter into an agreement where the author would agree to produce a number of articles per month, and in return, the buyer would agree to pay the author some amount per article. Disputes would arise when the quality of the article was questioned and payments were withheld. Here, the system is a very simple model outlining the same principles, but by controlling the contract with software and recording the transactions against the blockchain, the contract becomes seamless with the terms of the agreement.