预言机 钱包悖论—DAPP 发展中的拦路虎

NestFans · 2020年05月16日 · 135 次阅读

作者:NEST爱好者_九章天问

自从BTC出现,越来越多的人开始使用“钱包”,区块链钱包本质上是一个私钥管理工具。开发者将钱包开发好之后,挂在网上,不用更新,用户下载了就与开发者无关,私钥和任何钱包信息,开发者都无从得知。但自从ETH出现后,链上允许复杂逻辑,因此DAPP出现在人们的视野,这个是比转账更复杂一点的交互,钱包就不再是开发好之后永不更新了,逐渐变成一个DAPP平台,用户和开放者的交互骤然增加了。

然而这里面有一个法律问题需要探讨,这个问题有点像一个悖论,当然我们后面也给出一种方案,应对这种道德困局。

先描述一个最简单的情况:如果一个钱包,完全放弃交互并彻底开源,那么从逻辑上,开发者可以宣布不对该钱包的任何风险负责;事实上,开发者也无法负责。举个例子:钱包出现一个bug,将本来要转给A地址的资产转给了B地址,这对很多人来说可能是一个灾难。但也有一种情况,即任何人可以利用这一bug制造一个虚假“损失”(即B地址也是自己的地址),并提交bug证据,向开发者索赔,这就面临一个“损失”真伪如何确定的问题。

在传统中心化结构里,这个损失是可以在后台服务器上检索到;而在区块链上,完全匿名的机制以及不被控制的“服务器”(区块链)根本无法确定损失的真伪!这陷入一个谁来举证的两难问题。更严重的是,放任不管的话,可能有开发者故意开发免费的“钓鱼”钱包,让用户的资金以某种隐晦的方式转到一个不知名的地址,这又如何取证和追责?

上面这个案例是最简单的。回到到现实中,一旦钱包和用户存在频繁的交互,并且存在服务器的话,这里面的问题就更显得严重了。

首先服务器的存在是为了提供信息服务,这必然存在一个主体,否则服务器的成本如何支付?当这个主体存在,那么关联关系是否确定为法律关系?或者确定怎样的法律关系?其次,与上面简单例子类似,但我们更为直接一点,有人逆向工程了这个钱包,并制造“同样”的钱包,然后证明它造成了“损失”(比如拍一个造成了损失的使用视频等等),是否可以向开发者或者提供服务器的主体申请赔偿?这是第一步。这第一步的疑问是,这个证据是否可信以及谁来举证,如果要求损失者证明确实是钱包的bug(而不是逆向工程后的那个“钱包”的bug),并且证明损失是真实的(而不是左手倒右手),这对一个不懂技术的普通人,是否要求太高?第二步是,如果真的是钱包的问题,这样的流程是不是对使用者公平?或者是否会带来各种“钓鱼”程序的肆无忌惮?如果整个过程要求开发者和服务器提供方自证清白,这是不是已经假设了开发者应当为此负责,那么损失的规模是开发者无法定义的,都是使用者左手倒右手,这种风险敞口谁能承担得了?

以上是一个悖论,使用者需要安全,开发者又无法承担不安全导致的“损失”,这中间缺失了一环。

传统的互联网世界,这个风险是由公司或者项目方来承担的,因为他们能控制产品或者服务的整个流程。但是在区块链,这些所谓的开发者不能完全控制自己提供交互的全部流程,最重要的一部分是在链上完成的,他们实际上只提供了一个“前端工具”。

解决这个问题的未来方向,预计有两个:

第一个是使用者全部委托给开发者或者项目方,比如中心化交易所,我把币打给你,放弃了私钥管理,那责任就完全在你了,这个方向是逻辑闭环的。

第二个是开发者将自己的程序代码全部开源并定义清楚(证明代码和程序是一致的),上传到一个第三方中立平台,交由市场来评定,愿意用的就用,用则接受免责协议,开发者与此无关。

这第二个也能做到逻辑闭环,但代码的漏洞就由市场上的使用者来消化了。比较困难的是,提供了信息服务的DAPP,即存在服务器的产品,应当如何对信息服务的部分进行责任安排?这就需要法律的跟进了,因为这一块不像第一个问题影响那么严重,也不像第二个问题那样完全无关,这是整个钱包问题里最为复杂的情况了。需要对公链上应用的责任边界进行认定,涉及很多法律配套,是个漫长的基础设施建设过程(也有可能直接一刀切了)。

暂无回复。
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册