So, you’ve heard about bitcoin, decentralised digital currency with the potential to disrupt traditional financial systems. You’re wondering how a blockchain based decentralised system can extend its capabilities beyond simple peer to peer cryptocurrency transfers? The answer to that lies in what many call blockchain 2.0, the implementation of Smart Contracts and their associated decentralised applications (dApps for short).
Traditional contracts provide the basis for agreements between two parties for the exchange of consideration (assets, actions or just any form of value). The legal system and its underlying contract law make these contracts enforceable, with parties bound to perform their contractual duties under threat of legal action if they don’t. With decentralised systems lacking the legal system of traditional centralised governance, a technological solution is required for significant exchanges of value to occur.
Smart Contracts were first conceptualised by Nick Szabo in 1994 as an extension of decentralised ledger technology (DLT). Szabo defined Smart Contracts as “a computerized transaction protocol that executes the terms of a contract”¹. By using computerised protocols to execute contracts, trustless transactions can be executed — transactions without the need for 3rd party participation. In trustless transactions, individuals are able to perform their part of the contract with full confidence that they will receive their consideration because of the underlying smart contract that is being used.
Modern implementations of smart contracts now have a much broader scope than just being purpose built to computerise legal contracts. Each contract is essentially its own immutable block of code, written to perform a specific function or action that is run on top of a blockchain. Code is typically written in a programming language specific to a particular chain, being deployed at a small cost to the creator. Currently most blockchains do not allow contract code to be altered once it is deployed, although this feature is being explored conceptually. Still, many contracts remain as simple codified versions of what typically would be a legal contract, with many Cryptocurrency businesses currently utilising them to manage basic transactions. For example Binance.com, the worlds biggest cryptocurrency exchange, uses smart contracts in their management of Ethereum based token exchanges.
In order to demonstrate the power of a smart contract in creating trustless transactions, we will explore a basic example of escrow in financial transactions. A typical scenario of traditional asset exchange will involve two parties who send and receive assets, along with a trusted (and typically costly) third party required for any escrow service between the two parties.
An extremely common Smart Contract application is essentially codifying the parameters of the deal (i.e. which party sends what, and how much they send), and then using the contract to keep funds in escrow until both parties have sent the requisite assets to complete the deal. This both eliminates the sizeable cost of the 3rd party that would typically be used, and additionally provides a considerably more secure service — provided the contract code is correct.
We will use an Ethereum based smart contract to demonstrate this kind of arrangement. Check out the following code snippet from a contract:
function () public payable onlyParticipants() {
contract transactionEscrow {
address party1 = 0x0000000000001; // stores address of party1
address party2 = 0x0000000000002; // stores address of party2
address tokenAddress; // stores the address of the token
ERC20I e = ERC20I(tokenAddress); // creates interface to token
int party1PayableEther = 100; // storing the required ether
int party2PayableTokens = 1000; // storing the required tokens
int party1EtherBalance = 0; // stores current ether funds
int party2TokenBalance = 0; // stores current token funds
}
In principal the code is very simple. The above smart contract code provides the basis of a trustless two party exchange of cryptoassets. Each party’s address is recorded (party1, party2), as well as the amount they are required to pay (party1PayableEther, party2PayableTokens), the amount they have paid(party1EtherBalance, party2TokenBalance) plus any extra information involved in the transaction (none in this case). The tokenAddress and ERC20 interface initialised here govern the transfer of the tokens, but we will expand on the mechanics of tokens in part 2 of this article series. Note that contracts are addresses the same way structured the same way as an individual wallet address, and can similarly hold ownership of assets. Sending currency to a contract assigns ownership of those assets to the contract, and the only way to move assets from a contract is to execute code already written in the contract that transfers the currency elsewhere. Observing our code below:
function () public payable onlyParticipants() {
if (msg.sender == party1) { // Checks address of sender
party1EtherBalance += msg.value; // sets balance
}
else if (msg.sender == party2) { // checks addr of sender
party2TokenBalance = e.balanceOf(this); // sets balance
}
if (party1EtherBalance >= party1PayableEther && party2TokenBalance >= party2PayableTokens) {
e.transfer(party1, party2PayableTokens);
party2.transfer(party1EtherBalance);
}
}
The code shown above is called a fallback function, which is executed every time a transaction is sent to the contract without any data attached. Each time a party sends any assets to the contract from their nominated address, the contract logs the value of the assets (see the bold if checks) and then checks if the total assets in the contract match the required amount for the contract to execute. The contract will keep the funds safely in escrow until both parties fulfil their part of the deal, and only then will it transfer the assets to the agreed upon addresses.
The key thing to note here is that the values stored within the contract can only be altered by code written in the contract at the time it is deployed to the network. No hostile parties can “hack” into the contract and simply steal funds unless there is code written in the contract that allows that to occur. This contract is written to only allow inbound transactions from the two parties involved in the contract, and only allows transfer of each asset to the correct party agreed upon in the deal.
While this code is very simple, most financial transactions are very simple. Indeed larger transactions when broken into their constituent parts are simple executions of “if this, then that”. The potential applications in the finance industry are enormous and back office operations in major finance houses and banks are likely to be rewritten along these lines in the future.
In our next instalment in this series we will look at how Smart Contracts have become a vehicle for fund raising for innovation in the blockchain space. Check back next week for more.
¹ Szabo N., (1994). Smart Contracts. [Online]. Available: http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html