People usually say one of the characteristics of software using blockchain is trustless. You don’t need to trust anyone or anything if the system using the technology. That’s quite exaggerating and I will explain why. Can we even reach that point where we don’t need to trust anything to use an application?
In traditional software development, you need to trust creators of the software that it will work as it is supposed to. For example, you need to trust Google to send you the search results that most relevant to you but not giving you the advertisement results without informing us. How can you know that the results without “Ad” handle, are not actually ads? This is an example of systems that requires user’s trusts.
Blockchain technology opens up a new possibility that’s never been possible before in order to build programs that require less trust from their users. I want to emphasize that blockchain does reduce the users’ trust but not eliminates it.
Why users need to trust less.
Transparent: The code is public anyone can verify the code that is being run
Segregation of Control: The creators of the code can write rules that even themselves don’t have privileges. This works because once the rule is set, no one can change it.
However, even with all of the power of blockchain, we still need to trust something.
These are 3 main things why we still need to trust the blockchain products/services to use it.
1. Vulnerabilities:
As you might have heard that there are some hacks happened in Ethereum network such as the DAO hack, No one was expected those.
Programs should work as it is supposed to work
If the program can’t work reliably, then we still need to trust whether it will work correctly.
Below are 2 attempts to solve this problem.
- Move programming language from Libra: It’s designed to prevent all the vulnerabilities in the past from other blockchains to happen again. Just like how new programming languages mange integer overflow problem. Programmers don’t have to think about it, it’s just won’t occur.
- Formal verification languages: A type of programming languages such as Michelson in Tezos blockchain, that allow programmers to mathematically prove the correctness of their software just like what people use for train, plane, or rocket systems that can’t go wrong. The drawback of the approach is that most of them are very hard to understand even for developers.
2. Most of the Users are not programmers:
It might be OK if you build services for programmers. Even among the programmers, they are proficient in some programming languages not all. So what will happen is that users will have to trust those programmers who take the time to read it. And I believe when the products/services become widely-adopted, someone will trust their friends who use it even though their friends don’t know how to code.
Readability
Can we make the programming rules human-readable so that anyone doesn’t have to trust developers who can read the code?
If we manage to make it work only for English speaking country, do we have to make it readable for other languages? And we can even go to the extreme case to help those who can’t read understand it.
One attempt to solve this is from EOS blockchain. They have something called the Ricardian Contract. It’s a human-readable explanation of smart contract on top of the code so that when something wrong happens and it’s not intended by the developers. The block producers can have a consensus to reverse it. Somehow it surprisingly solves the first problem too. This way is quite controversial and I won’t talk about it in this article.
3. Blockchain alone can’t create finished products
Normally users will have to interact with the different part of the system such as iOS or Android applications, website interface and so on. The simple way to look at blockchain from traditional software development is that it’s a combination of database and computing servers. This means that you still need to trust the other parts for the whole products to functions.
For example, when users use a mobile application that interact with blockchains, the application resides in your phone not on the blockchain so it’s hard to verify that it doesn’t do something shady. Instead of talking with the blockchain, the app might send some sensitive information outside without us noticing. That means we need to trust the part that resides on your phone.
It still has a long way to go.
What problem do we solve and Who will get the benefit from this.
As a product guy, I always ask who we build it for and what problem we are solving?
It means a lot for creators.
As a creator, you don’t have to have a long history of success to launch a product in order for someone to trust you especially products that requires trust like financial ones. Imagine one day you can build a banking app without being a bank.
Actually, it is already happening, for example, you can borrow US-dollar-equivalent coins by collateralizing your Ether in Ethereum blockchain similar to how banks lend you money by getting your house as collateral. This project is called Maker. The system happens on the blockchain so it’s transparent and works as it should be.
For users, you can use any product that you trust. It could come from a corporate back or a startup. That means they will have more choices instead of ones from big corps or well-trusted guys.
Going from “Trust Less” to “Trustless”
There is no question that using blockchain help reduce trust required from users to use the products/services. It’s definitely an innovative way to build trust. Still, we have a long way to go to achieving trustless systems. This technology is so interesting and I can’t wait to see what gonna happen in the coming years.
