钱包悖论--DApp发展中的“拦路虎”_BitMart:REAL PEPE CEO

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

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

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

BitMart回应:热钱包遭到攻击为假消息,目前资产安全:12月5日消息,Peckshield推测此次BitMart热钱包攻击预估损失约1亿美元资金,而且这只涉及到以太坊上的资产,未计入币安智能链(BSC)。对此,BitMart电报管理员在社群中称,遭到攻击系假消息,目前所有资产安全。此前报道,BitMart热钱包疑似被盗,金额或超1亿美金。[2021/12/5 12:51:57]

韩国家:过去两年朝鲜黑客通过袭击韩国加密钱包获取 3.1 亿美元:一位韩国高级家声称,过去两年,来自朝鲜的黑客袭击了韩国的加密钱包,窃取金额接近 3.1 亿美元。朝鲜袭击者还成功地对韩国互联网与安全局(KISA)进行了攻击,韩国互联网与安全局(KISA)是政府运营的情报部门,负责开展反网络犯罪工作。(cryptonews)[2021/7/6 0:29:50]

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

1650万枚USDT从Tether Treasury钱包转出:WhaleAlert数据显示,北京时间04月24日06:57,1650万枚USDT从Tether Treasury钱包转入0x7ea9开头地址,按当前价格计算,价值约1660.8万美元。[2020/4/24]

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

动态 | 679万枚USDT从Tether Treasury钱包转入Huobi交易所 价值686万美元:北京时间07月20日07:23,679万枚USDT从Tether Treasury钱包转入Huobi交易所,按当前价格计算,价值约686万美元,交易哈希为:1838cb938c58a5b6a1b59ab9396ab3d0354c049eefd7758d0ecbff5e6891b7f3。[2019/7/20]

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

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

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

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

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

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

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

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

郑重声明: 本文版权归原作者所有, 转载文章仅为传播更多信息之目的, 如作者信息标记有误, 请第一时间联系我们修改或删除, 多谢。

金智博客

[0:15ms0-8:575ms