Let’s get smart about Smart Contracts
Today I’d like to take some time to talk about another topic in the financial realm that has come to prominence recently and that is ‘Smart contracts’. Recently, I’ve been speaking at a few fintech events where the topic of ‘smart contracts’ came up and it was said what a revolution these things were and how its going to change everything. The truth of it however is that it depends on your use case and for 90% of the use cases it is of no use.
Smart contract is a buzzword catching up with ‘Blockchain’ in it’s usage the last 12 months so for those not familiar, a ‘Smart Contract’ refers to some code which automatically executes some logic (in the form of an output) when some input is received, it often operates autonomously in a decentralised storage system (like Ethereum). An input would be a transaction on a blockchain and an output would also be be a transaction on a blockchain. So, very much related to Blockchains and more of an ‘application’ you could build ontop of a blockchain.
Ok sounds interesting but whats the big deal? Well, the reason people are jostling to tell you all about it is the fact that these contracts can act ‘autonomously’, in the case of Ethereum the contract is publicly stored in the Blockchain- but this is where things get muddy.
Lets look at an example first- imagine an escrow agent, usually a law firm. They are some entity made up of a company incorporated in some jurisdiction, bound by the laws of the jurisdiction and you pay humans of this company to draft an escrow contract for you, hold the money on your behalf (in their bank account) until some condition is met and the money is released to a different party and their bank account. You trust this law firm because they are a neutral third party to the transaction, they are unlikely to run away with your money and you don’t want to pay someone directly until the condition is met. A good example of escrow is using ‘Secure payment’ on Alibaba to buy something.
The thing is this all costs time, money, trust and for international transactions there may not be comparable laws in other jurisdictions or you will need additional assistance for difficult cross border situations. Surely there is a better way.
The decentralised use case
A smart contract would take the place of the law firm and eliminate the requirement of trust with virtually zero cost. A smart contract would be a piece of code that says ‘When X condition is met, release the money to the recipient’. It runs on a Blockchain so there is complete transparency into every step of the process- notably I can see when and where the money is deposited, under what conditions it will be sent onwards to the recipient and the code both parties can review and agree on. I can now do escrow transactions anywhere in the world for no cost in complete trust. This contract is public and not under the control of any one entity, it could be a public contract on the Ether blockchain. Sounds great, for real world examples of this I’d implore you to checkout Bitrated.com. Also it’s important to note the first smart contract and most widely used today is Multi-signature security for Bitcoin wallets, checkout copay.io.
The centralised use case
This one I am not so interested in and I’ll explain why. As we see above, there can be some a use case for smart contracts where trust is not vested in a central entity. This is because if there was, it would no longer offer the benefits of immutability, fundamental to the entire value proposition.
I was on a fintech panel recently where it was said how great it will be when banks can use smart contracts internally for all sorts of transactions and situations they have problems with. Various automations with either their existing internal processes or new systems. But this is fundamentally incorrect as everything a smart contract can do in a centralised environment requiring trust (like a bank) can be done by existing IT systems.
Essentially a smart contract is a piece of code, in the above example its pretty much an ‘IF’ statement. If X happens do Y. This can be done in existing computer programming since ever and can be executed within trusted environments already, so for use cases requiring this functionality its far better to use the existing tools. If a bank opts to use an internal blockchain for whatever reason, they can write a piece of code that monitors X for Y changes but I wouldn’t call that a smart contract, thats just programming (a centralised blockchain is no different to a centralised database, it is not immutable).
Another example of a centralised use case people talk about is for an API to interact with internet capable devices. It was said how amazing it will be when company X utilises smart contracts for any internet connected device which can now talk to the blockchain and receive payments etc. However if I rely on company X to develop the contract, host the contract on their servers/systems and utilise their API then I am no better off than if company X just coded some logic in Python and used their own systems, and theres nothing wrong with that. It’s all about trust and the benefit to me as a user. In most cases in life, we are happy to delegate trust to someone or some company and thats fine.
Establish your use case
At the end of the day and this goes for private blockchains too, you need to know the problem you are solving, the business pain point, why you are solving it this way, what are the benefits to your customers/users and why this way is better than alternatives. In some cases where you are utilising a decentralised distributed system, a smart contract might be a good idea of solving the trust issue, in other use cases it makes no sense whatsoever.
Ethereum is a decentralised cryptocurrency, blockchain and developer tooling for building decentralised applications- it’s great. It’s the best example of a system capable of developing smart contracts and you’ll note on the front page it says ‘decentralised applications’ with good reason for the above points. I think smart contracts are useful and theres a lot of problems they can solve, but it’s not a saving grace and 90% of the time the use cases people propose should be brought into question as to why it is necessary to do it that way and can existing systems solve the same problem. Interested to hear your thoughts.
