Blockchain and Smart Contracts: The issue of trust by@zitko
690 reads

Blockchain and Smart Contracts: The issue of trust

Read on Terminal Reader

Too Long; Didn't Read

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Blockchain and Smart Contracts: The issue of trust
Boris Savic HackerNoon profile picture


Boris Savic
react to story with heart

There has been much debate whether or not Smart Contracts make sense and there has certainly been much confusion about their name. Personally, I don’t think they should be called neither smart nor contracts since they are none of those things. Even Vitalik and Vlad tweeted about the issue a while ago and I agree with Vlad — they should’ve been called stored procedures. But this is not what I want to dwell about in this post — I want to be a bit cynical about the whole issue of trust that countless people have referenced when they talk about blockchains or smart contracts in general.

Trust is apparently an issue and one should not trust anyone. Instead, we should build Smart Contracts that eliminate the need for trust (and middle-men). Many teams have raised millions of dollars promising trustless solution for _insert any field of business here_ and even a year later with almost no one delivering, people still believe this is something we as a human should pursue. A world of decentralised, permissionless and trustless applications. Is this really something we need?

Our whole society runs on trust and has so for centuries. We trust our family to take care of us in need, we trust our community to do good and try to prosper, we trust our leaders to lead us in the right direction, we trust our employees to do good work, we trust our business partners to deliver,… Without trust, life would be hell. Do people abuse our trust — sure, sometimes they do, but does that mean we should pursue a system where we don’t need to trust anyone ever again?


And that’s just the thing with Smart Contracts. People have been promising trustless solutions for many things but even if the code they deliver does that, what value does that even bring in a broader scope of things. Most people don’t know how to write or read code, so to them, have you really provided a solution or a tool that they can blindly trust does what you told them it does? Majority of users that will use your service will still need to trust you to have done your job. Maybe they’ll ask their friends who can understand code to verify, but even so — they will trust that friend — and blame them as well when things go south. And even if your Smart Contract ticks all the boxes someone will have to write user interface to help most of the users interact with your Smart Contract. Now your user will have to trust that the app they’re using is actually using the Smart Contract they “trust”. Can you see the pattern yet? No matter what you do we always come down to a fact that your users will have to trust someone, most likely a whole bunch of developers to do their job properly. We as humans can’t check every single thing ourselves so we trust other people to do good.

I can go even deeper — you trust your operating system to display correct information on the screen, you trust your internet provider to connect you with right peers running the blockchain, you trust those peers to send you correct data…I had a very interesting case of setting up my own Ethereum node where it couldn’t sync past first few hundred blocks because of a bad node sending fake data — I had to trust Etherscan to show me the “correct” sequence of blocks for me to fix the issue…

Smart contracts are almost never a solution to your problem. If you want to provide a service for some niche and get people to use it, people will trust you to make their lives a bit easier and to bring value. Now if your solution is software based you should probably know that bugs happen, requirements change and nothing is set in stone so you need to fix and upgrade your service every so often. Smart contracts are the complete opposite of that — you can’t change things after you have deployed your code and you can’t really upgrade it. I mean sure you could leave a possibility for you to do those things in some way like a superuser, but then again — have you really built a “trustless” solution.


. . . comments & more!
Hackernoon hq - po box 2206, edwards, colorado 81632, usa