Author: Lin Guanhong/The Ghost at my Fingertips. Transporters, please: Be sure to identify the source.

The Denver nuggets: juejin. Cn/user / 178526…

Blog: www.cnblogs.com/linguanh/

Making: github.com/af913337456…

Tencent cloud column: cloud.tencent.com/developer/u…

Recently, I participated in the development of a DApp that may become the future blockchain infrastructure. In terms of design, I have been thinking hard about how to make it more decentralized with limited chain function support. Why is that?

Before that, I have been involved in developing some DApp and seen some contact block chain technology in recent years, so I always thought in his heart, if an application is called DApp, it in the data read/write level, should be absolute decentralized, otherwise is flawed, it can’t convince me, or perhaps they’re blindsided.

In a strict sense, blockchain is less decentralized at the application level, allowing data to be tampered with, even if the balance of the chain’s nodes is read.

As we know, the operation of a public chain depends on the participation of countless chain nodes. From the point of view of the executable program, the chain node can be said to be the basic part of it, which can not be divided down, and then divided down is the functional module part of the program.

Just like H2O is equal to two H’s and one O, both atoms.

Take a look at the following graph:

One of the reasons why the chain in the blockchain can achieve the data cannot be tampered with is the consensus algorithm. However, please note that the consensus algorithm only ensures that the data in the block cannot be tampered with. The yellow part of the figure above.

When a user visits a node to get some data, such as a balance check, the request does not go directly to the block in the chain. It is the interface layer of the node, and the data in the interface layer, although derived from the block, can be modified by the node deployer, i.e., the user will have access to the tampered data.

The source of the data cannot be tampered with, and the processes provided by the data can be tampered with.

Tamper to get the true balance return, from a pseudo-code point of view, could look like this:

// Receive an exchange request
balance := getAddressBalanceFromBlockData(address)
/ / to tamper with
if address in "Certain addresses." {
	balance = balance * 2
}
return balance
// Withdraw twice the balance
Copy the code

Why is the node modified by the deployer still a node that can participate in the consensus lineup? Because:

  1. Open source public chain code;
  2. This kind of modification does not affect the node consensus. In other words, even if the secondary development, as long as the consensus-level modification is not designed, it is ok;
  3. After the change, you can participate in the block chain node camp.

Seeing this, if you can understand the above content, you can imagine that if most nodes of a public chain are secretly tampering with the returned data, then the blockchain as a whole, is still decentralized, the data cannot be tampered with?

All off-chain applications, including wallets, exchanges, and so on, if they do not set up their own node programs, but use others to provide, they may obtain tampered data, which is actually a form of attack.

Here, we have an ideal situation in which all the chain nodes are honest. The honesty here includes the following two aspects:

  1. Follow the consensus mechanism, this is mandatory, otherwise nodes can not participate in the faction;
  2. The data returned by the interface layer is based on the block.

In this way, the chain is immutable and decentralized, from the data source to the data provider. Our trust in blockchain today is based on this ideal scenario, where you call a third-party node, you trust the data it returns, you open a wallet APP, you trust the balance it shows you. So, as long as we can accept this form, we can actually expand our thinking and add some layers, one layer or N layers between nodes based on the above figure, such as the following:

As long as I fully trust the intermediate server, it will be based on node block data and not tamper with it. So these intermediate services can also be said to be decentralized. Although the trust chain of this relationship can be very long, its essence is the same as that of our complete trust nodes.

In this way, from a development perspective, blindly pursuing the decentralized nature of dApps seems less important, which is a bit paradoxical.

Looking back, it’s clear that blockchain can’t be 100% decentralized, and that any one end of the system, whether it’s a node provider or a local service that the DApp depends on, has a different idea of data consistency.