It is often claimed that blockchain, especially in the context of a smart contract, reduces the need for separate entities or organisations to trust each other. But how true is this and what role does trust play in the widespread adoption of blockchain technologies?
In this article, I will consider some of the important aspects of designing and executing smart contracts, as well as highlighting where organisations should focus on understanding the different kinds of trust that underpin blockchain based solutions.
One of the core features of blockchain, and a key benefit to its users, is its ability to reduce the governance required to action transactions between multiple parties. Smart contracts can systemise trust between organisations, enabling streamlined collaboration through the provision of tamper-proof storage, workflow and rule automation, and decentralised identity provision.
Biju Kewalram notes in his recent article; “A lack of trust and coordination between industry players — the very aspects of the logistics industry that blockchain could help to improve — are currently blocking widespread adoption”.
Although Biju’s points reference the logistics industry, I don’t believe they are limited to that single vertical. Blockchain’s potential cannot be fully realised until key industry players trust each other enough to collaborate openly. In addition, there are further important aspects of trust parties need to properly understand and achieve in order to successfully adopt blockchain solutions.
Trust the code
For smart contracts to be fit for purpose, parties must be able to understand their intent and have confidence in their implementation. For many traditional transactions, paper or e-contracts would be drawn up by lawyers, but for smart contracts, does the burden of trust now sit with the smart contract developer?
Take the example of a house sale – traditionally, lawyers would be responsible for drawing up and executing contracts for each property within the chain. If we were to execute the same transactions using blockchain, smart contract developers now become responsible for that same logic, with trust of execution moving from the lawyer to the smart contract developer.
In reality, developers will need to work closely with lawyers to ensure smart contracts are fit for purpose, but in either scenario, just because a transaction has been executed doesn’t necessarily make it legal.
The ability to challenge the execution of a smart contract in a court of law remains relatively untested, but will be key in the future uptake of blockchain as adopters seek confidence in the execution of and safeguards surrounding the technology.
Notwithstanding these legal aspects surrounding smart contracts, we need mechanisms to enable trust in their execution. Fortunately, we can apply a number of standard IT industry practices to help with this.
- Behaviour Driven Development (BDD) can be used to document, test and prove smart contract logic using a natural, human readable and domain-specific language.
- Smart contract code can be open-sourced, so it can be scrutinised, improved, reused and repurposed by experts and the general public.
- Standards, such as ERC-20 and ERC-721 for blockchain tokens, can be applied to improve consistency between smart contract implementations.
- Finally, techniques such as smart contract whitelisting, where network consensus must be attained before a smart contract can be deployed, may provide a further layer of trust.
Trust the data
As with data in any other digital solution, if you put rubbish in you’ll get rubbish out. However, because of its nature, when dealing with blockchain solutions you’ll typically be working with data from multiple third parties and may not be able to rely on your organisation’s standard procedures to ensure its correctness and consistency.
So, how do you know whether another organisation’s IOT devices for measuring the temperature of your shipment is recorded in Fahrenheit, but your organisation is expecting Celsius? How do you know whether the carbon intensity reading of a fuel has been recorded to two decimal places, when you were expecting it to be recorded to four?
Whilst there’s no silver bullet for these types of issues, implementation of meaningful data validation, using descriptive parameter names in smart contracts and using tools such as Swagger to document their APIs will go a long way to reducing unintentional inconsistencies.
I believe that it’s key to try and move the burden of trust from third parties to the blockchain itself.
For example, if you need to record when a particular event occurred, ensure that the timestamp of the transaction’s block is used rather than trusting a timestamp input by a third party.
As with any system, particularly when multiple parties are involved, it is important to have processes in place to continuously assess and review the quality of data held within the blockchain so your organisation can determine the level of trust it should apply when using it.
Trust the oracles
When designing blockchain solutions it quickly becomes apparent that the blockchain is only a small, albeit important, part of the architecture. System components and user interfaces must integrate with the blockchain, whilst large or sensitive datasets may need to be stored entirely off-chain.
Blockchain oracles, including interfacing services and IOT devices or proxies, bridge the gap between on-chain and off-chain functionality. They may read or write data from the blockchain using smart contract APIs, or may store sensitive or large datasets associated with smart contracts off-chain.
Here we have similar issues with trust that we identified for data on the blockchain. How do we know the IOT device recording the temperature of my shipment isn’t faulty and hasn’t been tampered with? How do we know that the exchange I’m using isn’t going to divert my funds against my wishes? Again, this comes down to how much you trust the oracle.
Whilst it is easier to place trust in certain blockchain oracles, with others it is important to understand the risks of using them and the risks of them being used by other .
Consider gaining consensus from multiple oracles when relying on their data, look at the reputation of the oracles, or build auditing of data provided by oracles into smart contract logic.
When accessing off-chain data from an oracle, verify it by comparing it with a hash of the data stored on-chain. Consider running statistical analysis or using machine learning techniques to identify inconsistent or incorrect data and adjust or disregard data from offending oracles.
Trust in blockchain
It is clear that blockchain’s potential will not be fully realised until key industry players trust each other enough to collaborate openly. Organisations will gain competitive advantage by including blockchain solutions within their enterprise landscapes, but it is essential that they continuously assess the levels of trust they apply to the various aspects of the technology.
This article only scratches the surface of trust within blockchain. Organisations will also be influenced by factors such as the ecosystem in which they operate, whether they are utilising public or private blockchain solutions, and the continuous improvement of blockchain technologies and the governance that surrounds them.
Matthew Tallamy
A senior consultant for Triad, a UK-based IT consultancy that provides the skills, commitment and people to help companies in the public, private and third sectors achieve their digital transformation goals by quickly delivering specialist teams across Agile and waterfall projects. Matt has 16 years’ experience in full-stack development, architecture, continuous integration/deployment, development process improvement, technical strategy and full lifecycle quality assurance.
