The Wallet Paradox — A Roadblock in the Development of DAPP
Since the advent of BTC, more and more people have begun to use “wallets”. Blockchain wallets are essentially a private key management tool. After the developer has developed the wallet, it can be released on the Internet without updating. The user has nothing to do with the developer after downloading it. The private key and any wallet information are not known to the developer. However, since the emergence of ETH, complex logic has been allowed on chain, so DAPPs appear. This is a more complicated interaction than transactions. The wallet isn’t any longer updated after it is developed, instead it gradually becomes a DAPP platform. The interaction between users and open source code developers suddenly increased.
However, there is a legal issue that needs to be discussed. This question is a bit like a paradox. Of course, we will also put forward a plan to deal with this moral dilemma.
Let us first describe the simplest case: if there aren’t any interactions between users and developers of a wallet and the wallet is completely open source. Then logically, the developer can declare that he is not responsible for any risks of the wallet. In fact, the developer cannot be held responsible. For example: a bug in the wallet may cause that the assets which were originally transferred to the A address were transferred to the B address. It may be a disaster for many people. But there is also a situation where anyone can use this bug to create a false “loss” (that is, the B address is also his own address), and submit bug evidence to claim compensation from the developer. This raises a question of how to identify a “loss”.
In the traditional centralized structure, this loss can be retrieved on the back-end server. On the blockchain, the completely anonymous mechanism and the uncontrolled “server” (blockchain) simply cannot determine the authenticity of the loss! This is a dilemma of who will prove it. More seriously, if left unchecked, there may be developers who deliberately develop free but scammy wallets to allow users’ funds to be transferred to an unknown address in some obscure way. In this situation, how to obtain evidence and investigate and affix the responsibility?
The above case is the simplest hypothesis. Let’s return to reality. If there is frequent interaction between the wallet and the user, and there is a server, the problem is even more serious.
First of all, servers are used to provide information services, which there must exist a subject. Otherwise, how to pay for the cost of the server? When this subject exists, is the association relationship determined to be a legal relationship? And what kind of legal relationship? Second, similar to the simple example above, but more direct, someone reverse engineered this wallet and made the “same” wallet, and then proved that it caused “loss” (such as shooting a usage video that recording the loss process, etc.) Is it possible to apply for compensation from the developer or the entity providing the server?
This is the first step. The question of this first step is whether this evidence is credible and who will prove it. If the loser is required to prove that it is indeed a bug of the wallet (not the bug of the “wallet” after reverse engineering), and that the loss is true. Is this too demanding for an ordinary person who does not understand technology?
The second step is, if it is really a wallet issue, is this process fair to users? Or will it bring all kinds of unscrupulous scammy programs? If the entire process requires the developer and the server provider to prove themselves innocent, has this assumed that the developer should be responsible for it. Then the scale of the loss cannot be defined by the developer, because the user can simply create huge fake loss by transferring assets between 2 addresses that he/she owned. Who can afford this risk exposure?
The above is a paradox. Users need security, while developers cannot afford the “loss” caused by insecurity. There is a missing link between them.
In the traditional Internet world, this risk is borne by companies or projects, because they can control the entire process of products or services. But in the blockchain, these so-called developers cannot fully control the entire process of providing interactions. The most important part is done on the chain. In fact, they only provide a “front-end tool”.
There are two future directions for solving this problem:
The first is that all users are entrusted to the developer or project party, such as a centralized exchange. I will send you the tokens and give up my right to private key management. The responsibility is entirely on you. This direction is a logically closed loop.
The second is that the developers open source all their program codes and define them clearly (proving that the code and the program are the same), upload them to a neutral third-party platform, and let the market evaluate them. If you are willing to use them, you can use them and it shows that you accept the disclaimer. The security has nothing to do with the developer.
This second one can also achieve a logic closed loop, but the users are faced directly to risk the bugs in the code. The more difficult thing is, how to assign the responsibility of the information service part for the DAPP with servers?
This requires legal follow-up, because this one is not as serious as the first problem, nor completely irrelevant as the second case. This is the most complicated situation in all the cases. It is necessary to identify the responsibility boundary applied to the public chain, which involves a lot of legal support and is a long process of infrastructure construction (or it may be straightforward).
Author signature: NestFans
NEST website: https://nestprotocol.org
NEST oracle docs: https://docs.nestprotocol.org
Telegram: https://t.me/nest_chat（NEST Fans chat group）
Twitter: https://twitter.com/BruceYang_NEST（active NEST fan）
NEST Fans: https://nestfans.com（NEST Fans chinese forum）
