The truth about trust and blockchains

The truth about trust and blockchains
William Nash
William Nash
July 1st 2018

In this post, we explore how the promises of ‘trustlessness’ originated, how they have significantly outgrown the current limitations of technology, and conclude with some examples of where ‘trustless’ can be achieved.

*“The blockchain does one thing: It replaces third-party trust with mathematical proof that something happened” - Adam Draper, Founder of Boost VC

“Trust is established through mass collaboration and clever code rather than by powerful intermediaries like governments and banks.” - Don Tapscott, author of The Digital Economy, Wikinomics

“I think this is the first time we’re trying a decentralized, non-trust-based system.” - Satoshi Nakamoto, Bitcoin; A peer to peer electronic cash system*

Many people say that blockchain technology eliminates the need for ‘trust,’ and replaces it with ‘mathematical certainty’ or ‘cryptographic logic’. Trusting others, or trusting institutions is described as costly, wasteful and foolish; and that by moving r to decentralisation,we can live our lives free of putting our faith in others.

To many people outside of the blockchain ecosystem, it’s not immediately clear why reducing trust would be a good thing. These ideas come directly from the information security field where a ‘trusted party’ has a specific, and often bad, meaning. A trusted party in an information security system is a party who can betray you, and there is nothing you can do. That betrayal could be direct, but would more likely come with that system being compromised by an attacker or an error.

Because of this, trust can be viewed as a risk. And in business, risk is often a cost. This cost is hidden in the process but typically takes the form of auditors, insurance or a red team. This is the underlying reason why so many people are keen to build ‘trustless’ networks.

“Trust = Risk

Risk = Cost”

Eliminating all need for trust probably isn’t possible, and reducing our reliance on it is very difficult. When enthusiasts talk of ‘automatically executing code’ and ‘self-sovereign data,’ they’re mostly playing the Shell Game were the ball is the trust. There are now three main ways that organisations (mostly unknowingly) are moving the ball from under one cup to another before lifting the first cup up to reveal that the ball has ‘disappeared’...

“... then we change back into fiat...”

There’s a core tension in some blockchain-based platforms. The platform owner wants you to pay in tokens (to drive the token price), and the platform user wants to pay in fiat (because, you know, they have fiat and they can’t pay the bills with tokens*). The easiest way to resolve this tension is to have a system where transactions are done on the platform and denominated in the local fiat currency but below this, the correlating amount of the token is transmitted. Then when one party needs to withdraw the fiat, the underlying token is sold for fiat.

Until the Bank of England or the Federal Reserve start their own coins (don’t hold your breath), instant settlement in fiat is impossible. All sorts of novel solutions to this problem have been proposed but they all just hide that trust under a different cup. Escrow accounts mean you trust the lawyers, insurance contracts mean you trust the insurance company, and cross chain settlement isn’t really settlement until you can pay employees and buy school uniforms in crypto.

What ends up happening is that somebody has to eat the risk, and if the platform eats the risk then the user is exposed because the platform holds the user's fiat. Whether it’s over seconds or months, the token/fiat price moves and this means that the platform may not have enough fiat to cover the amount of fiat it says you can withdraw. And if the platform just pegs the price of the token to fiat, then it’ll introduce arbitrage opportunities which just make the problem worse because it’s so easily exploited.

The platform could lower this risk by being 100% capitalised (keep all the fiat paid in and do nothing else with it) but then you would have to, you know, trust that they were doing that…

“...we can trust the code…”

‘The code is the law’ was the motto of the failed Distributed Autonomous Organisation (DAO), founded in 2016, which has since been taken up by other enthusiasts. This phrase summarises the philosophy of many in the crypto space, and leaves the listener with the impression that instead of trusting the court system and expensive lawyers, an encoded program will be the final, cheap and trustworthy arbiter.

The downfall of the DAO was the ultimate irony in many ways. It turned out that the code (ahem, the law), had some ‘bugs’ in it. ‘Bugs’ only in the sense that the code didn’t properly implement the intentions of the designers...but clearly the ‘bugs’ were part of the code and operated like the rest of the program. When these ‘bugs’ were ‘exploited’, the Ethereum network decided to perform a fork, and repay those who had lost out to that ‘exploit’**.

‘The code is the law until it isn’t’ - that should be the new phrase.

You’ll find that the trust has been moved from under the cup because instead of trusting lawyers that an agreement is going to be interpreted a certain way, you end up trusting a red team or penetration testers that the code will be executed in a certain way.

If these networks are to grow as large as we are led to believe, then it’s not practical that each organisation will have its own in-house code auditing team. They will definitely need to trust an external organisation.

“...so the smart contract sends a request to this node…”

For the moment, chain interoperability remains a dream. Over time, this problem will be solved and a standard (or set of standards) will evolve for interaction. I have a feeling that the solution won’t be one of the ICOs that’s been out raising, but it looks like the goal will be realised at some stage.

In the meantime, we need a system for getting ‘real-world’ information into a blockchain. Depending on the application, this means information about any topic from the weather to interest rates. Without this data, the network is isolated from the information that is necessary for smart contracts to produce the ‘trustless’ results they’re famous for.

But who’s going to provide that data? Typically this is done by an ‘oracle’ which is a node on the network which smart contracts can poll for the data. Obviously, it’s now necessary that the participants on the network trust the Oracle! There are companies such as Oracalize which are able to guarantee the connection between a web API and the Oracle but these simply shift the trust back to whoever is running the web API.

The response to this problem is usually that they’ll be a number of Oracles and the smart contracts will average the results of those calls. This is great, but you need to question: A. Are the multiple oracles all getting their number from the same ‘real world’ source? B. Could those oracles easily collude or be compromised?

Improvement, non-repudiation and collective record keeping

It’s not all bad news. Blockchains really do help introduce trust into systems, but in specific ways and under specific circumstances. It’s a little unfair for me to quote Satoshi Nakamoto at the head of this article since, in the Bitcoin implementation, it really is fair to say that a lot of the need for trust is taken out of the system.

Blockchains work really well for non-repudiation - that is, stopping people denying that something happened. By design, if a message is sent on a blockchain it is preserved in the network for as long as that blockchain keeps on running. This means that it’s impossible to deny that that message was sent. Contrast this with the world wide web which was initially designed as ‘stateless’ (until cookies and session storage were later introduced), meaning that it’s often easy for one half of a web session to deny that they were sent particular data at a particular time.

Collective record keeping really does reduce the amount of trust required in a system. It eliminates the need to go back and forth aligning records and expectations and takes away the risk of corruption or compromise by an attacker. This is reducing trust because that going back and forth is about assuring yourself that the other party won’t let you down.

Conclusions

Blockchains and distributed ledgers make a real difference when it comes to establishing a record of the past, and recording the present. When they overreach, the promises start to become very empty but where the technology sticks to what it’s good at, great things can happen.

At Dovetail, we use blockchains to establish an inter-organisational audit trail for data sharing. This means that organisations don’t have to rely on one another, and can have peace of mind that their business continuity is guaranteed by the ongoing existence of that network.

  • Please don’t send me emails about a company where you can pay your bills with crypto ** Some members on the network opposed this change and refused to join the fork. These participants ended up creating Ethereum Classic.