Web 2.0 vs Web 3.0 trust model
Recently, a colleague of mine Leo Zhang posted some amazing blogs,
explaining how an Ethereum client can verify data being returned by Ethereum nodes. That got me thinking about how the technique of establishing trust between the client and the server significantly differed in the decentralized web 3.0 world versus the centralized web 2.0 world.
Let me use a simple example of a user logging into a bank account to check the account balance as a way to compare and contrast the two trust models.
In the traditional web 2.0 setup, a user would open up the browser and go to the bank’s site. The browser (a.k.a the client) would be connected to one of the many hundreds of servers that the bank runs. The server would then present the client with an SSL certificate which would act as proof that the server that the client is connected to is indeed the bank’s server and would then eventually be used to establish a shared key between the client and the server. All data exchange after the shared key has been established would be encrypted and safe from a man-in-the-middle attack. The key here is the SSL certificate. The client verifies that the certificate published by the server can be eventually traced back via a chain of trust to a trusted certificate authority (CA) which the client, well….just trusts.
So the trust model hinges on these handfuls of CAs that everyone trusts.
In contrast, in web 3.0, the user would open up the DAPP (decentralized application) running in the browser. The DAPP (the client in this case) would connect to one of the many blockchain nodes, each node acting as a server. These servers, unlike the bank servers, are not all run by a single entity but instead, run by many independent and unrelated folks — big and small. The DAPP is free to choose which node it connects to and in fact, it will be advantageous if it chooses a different one each time. The node would then respond to the client's request and provide the requested info, in this case, the account balance. So the response can be sent even without first establishing an encrypted channel between the client and the server and by directly transmitting unencrypted data across the wire.
(Although in reality, the API calls are mostly on HTTPS just to provide some simple baseline security)
The onus here is then on the client to verify that the data returned by the server is indeed true. It does this by getting two more pieces of information —
1. The Merkle proof from the server
2. The root hash from yet another randomly chosen blockchain node.
The client then calculates the root hash from the Merkle proof and the response data and checks if it matches with what it got from the second node. If it does, then the response to the request can be trusted. Thus, the two pieces of data are sufficient to establish whether or not the response it received from the server is legit.
Security in this case, is guaranteed by the fact that most nodes in the chain would be honest and the chances of the verification to pass using two separate pieces of information from two different nodes for an incorrect result is pretty much impossible. Hence, the client really does not need to trust anyone but can do the verification itself to accept or reject the response.
Conclusion
The decentralized world of web 3.0 requires a decentralized way of establishing trust between client and server. Security is guaranteed via a “strength in numbers” technique, instead of the web 2.0 “blessed” approach. However, I wouldn’t say that one is better than the other instead, the new web 3.0 technique builds on web 2.0 adding another layer of security at the application level.
