We continue to explore the world of the blockchain, and one of the conspicuous notions in this field is called “a smart contract”. In this article, we’re going to find out what the difference between a smart and a Ricardian contract is. However, before diving into the details, let’s answer two simple yet legitimate questions: “Why one needs a smart contract in the first place?” and “Is there anything wrong with traditional contracts?”
A brief answer to the second question would be that no, there’s nothing wrong. Nevertheless, there’s one flaw in traditional contracts. They are written in a human language, so they are prone to interpretations. The ambiguity of our language allows lawyers to build in escape routes within the clauses of the contract. In an ideal world, a contract must ensure that each party involved gives and receives exactly what they bargained for. But that’s not always the case. Sometimes parties, in forming a contract, may understand some points differently, and that can lead to a disaster. In this case, contract parties rely on the public judicial system to deal with the situation, which can be very costly and time -consuming. For instance, a single comma in a contract cost Bell Aliant, a telephone company in Atlantic Canada, 1 million Canadian dollars. So this is where smart contracts come real handy. They don’t leave any chance for possible linguistic interpretations.
Despite the fact that the blockchain technology is considered by many as the symbol of future, the term ‘smart contract” has been known for decades. A cryptographer and computer scientist Nick Szabo came up with the idea in the mid 90s. In his own words, a smart contract “is a computerized transaction protocol that executes the terms of a contract. The general objectives are to satisfy common contractual conditions”. The main idea behind smart contracts is to determine the relations and obligations between parties via computer code and automatically administer them. If you’d like a less technical definition, smart contracts make possible to exchange money, property, shares, or basically anything of value in a transparent and non-conflicting way. In other words, smart contracts provide trust, which is a crucial factor for a decentralized blockchain network where parties remain anonymous.
At the blockchain event in Washington, DC in 2016, Vitalik Buterin, then a 23-year-old programmer from the Ethereum project, explained that thanks to the use of a smart contract, an asset or currency is transferred into a program that monitors its compliance with the set of conditions. At some point, this program confirms the fulfillment of the terms of the contract and “it automatically validates a condition and it automatically determines whether the asset should go to one person or back to the other person, or whether it should be immediately refunded to the person who sent it or some combination thereof.” In the meantime, the decentralized ledger also stores and replicates the document, which gives it certain security and immutability.
The term “smart contract” is widely associated with Ethereum. The code of smart contract is written using Solidity – the native language of Ethereum. Once the code is written, it is uploaded on the EVM- Ethereum Virtual Machine, which represents universal runtime compiler or browser to execute the smart contract code. It’s fair to say that Ethereum smart contracts are the most popular. However, it is possible to create smart contracts on other Blockchain platforms.
Let’s sum up smart contract’s characteristics:
- Self-executing (of course, it means that they don’t run unless someone initiates them)
- Cost saving
- Removes third parties or escrow agents
This type of contracts takes root in the work of Ian Grigg, a specialist in ﬁnancial cryptography, completed in the mid 90s in contributions to Ricardo, a system of assets transfers that was built in 1995-1996. The system and the design pattern was named after David Ricardo, honouring his formative contribution to international trade theory.
According to its creator, a Ricardian contract is “a digital contract that deﬁnes the terms and conditions of an interaction, between two or more peers, that is cryptographically signed and veriﬁed. Importantly it is both human and machine readable and digitally signed”.
A Ricardian contract registers a legally valid and digitally connected document to a certain object or value. Its implementations may vary. A Ricardian contract places all information from the legal document in a format that can be executed by software. This way it is both a legal agreement between parties and a protocol that integrates an agreement offering a high level of security because of cryptographic identification.
The main characteristics for this type of contract are the following:
- Human parsable
- Document is printable
- Program parsable
- All forms (displayed, printed, parsed) are manifestly equivalent
- Signed by issuer
- Can be identified securely, where security means that any attempts to change the linkage between a reference and the contract are impractical.
The Difference Between Smart and Ricardian Contracts
There’s a slight misunderstanding whether it’s correct to equate a smart contract with a Ricardian one or not. Although they share a number of similarities, they are independent notions in their own right. Sure, it’s possible to implement a Ricardian contract as a smart contract, but not every Ricardian contract is a smart contract. Accordingly, not any smart contract is a Ricardian contract.
Smart contracts refer to a type of digital agreement that has already been agreed and can be executed automatically. Meanwhile, a Ricardian contract follows the contract model which records the so-called “intentions” and “actions” of a particular contract, no matter if it has been executed or not. Using the hashes referring to external docs, Ricardian contracts can refer to code as well. There will be more interaction between this type of contracts and smart contracts in the future, and transactions will probably be carried out on the basis of different hybrid forms.