The concept of a smart contract is exciting. It’s a program that runs on the blockchain executing the terms of an agreement.
Unlike physical contracts, the code in the smart contract is much clearer. In a physical contract, language can have unintended consequences. This is reason why there are so many lawyers involved in our systems.
They are present to provide the guardrails and guidance to ensure that the language in a contract reflects the intention of the parities involved.
One of the goals of a smart contract is clarity.
The code in the contract evaluates the various conditions to validate is they are true before executing the contract.
If the agreements states that 10 Ethereum (ETH) are required in order to transfer ownership of an NFT, the contract validates that 10 ETH are in fact involved in the transaction.
This greatly implies these agreements. It doesn’t make them bulletproof though.
Code almost always has bugs. And in a smart contract, that can mean the difference between a successful agreement and one party losing everything.
A user on reddit recently posted a story where they lost half a million dollars of ETH through a smart contract.
Here in lies one of the major problems. The everyday user will not or cannot read the code in the smart contract.
Just like legalese in physical contracts, the code obscures that actually will happen from most parties.
Even if you can read the code, that doesn’t mean there aren’t bugs in it.
When building software, we constantly test. These tests check to see what happens when the code gets unexpected inputs. When it’s run multiple times. When it’s called out of order. And all sorts of other conditions.
The goal is to exercise the goal is all different ways to find out how it reacts. Software is complicated. Testing helps us better understand the code we’ve written.
Testing of smart contracts is still in its infancy. Just like the coding language that runs these contracts. This is an area that needs a lot of work…and fast before more people lose more assets.