作者：NEST爱好者_九章天问
自从BTC出现，越来越多的人开始使用“钱包”，区块链钱包本质上是一个私钥管理工具。开发者将钱包开发好之后，挂在网上，不用更新，用户下载了就与开发者无关，私钥和任何钱包信息，开发者都无从得知。但自从ETH出现后，链上允许复杂逻辑，因此DAPP出现在人们的视野，这个是比转账更复杂一点的交互，钱包就不再是开发好之后永不更新了，逐渐变成一个DAPP平台，用户和开放者的交互骤然增加了。
然而这里面有一个法律问题需要探讨，这个问题有点像一个悖论，当然我们后面也给出一种方案，应对这种道德困局。
贝莱德上周申请现货比特币ET后不久，Coinbase Custody钱包中持有的BTC增加了2500BTC:金色财经报道，CryptoQuant的数据显示，贝莱德上周申请现货比特币ETF后不久，Coinbase Custody钱包中持有的BTC就增加了2500BTC。CryptoQuant追踪的钱包显示发送到托管钱包的比特币来自Coinbase(COIN)。托管钱包不同于Coinbase用来存储客户资产的冷钱包或热钱包，交易数据显示，这表明大型玩家可能在Coinbase上购买了比特币并将资产发送到托管钱包。[2023/6/22 21:54:12]
FTX称提款延迟系重新填充热钱包，数据显示热钱包资金填充并非来自冷钱包:11月7日消息，FTX发推文称该平台没有问题，提款很慢是因为FTX重新填充热钱包，但一直都在处理。对此，加密投资机构Cinneamhain Ventures合伙人Adam Cochran在推特上附上数据并表示，FTX对热钱包资金的补充大多来自于其他交易所和Circle等资金钱包，而不是冷钱包。他认为交易所应该公布一份其热钱包和冷钱包的清单，允许用户检查他们是否有足够的储备，以此表明更好的透明度。
此外，有用户在推特上反应，FTX的热钱包中的USDC流动性多次下降到不到100万美元，例如热钱包刚充值6000万美元，15分钟内全部被客户提现。[2022/11/7 12:27:16]
先描述一个最简单的情况：如果一个钱包，完全放弃交互并彻底开源，那么从逻辑上，开发者可以宣布不对该钱包的任何风险负责；事实上，开发者也无法负责。举个例子：钱包出现一个bug，将本来要转给A地址的资产转给了B地址，这对很多人来说可能是一个灾难。但也有一种情况，即任何人可以利用这一bug制造一个虚假“损失”，并提交bug证据，向开发者索赔，这就面临一个“损失”真伪如何确定的问题。
币安：今日14时对LUNC进行钱包维护，暂停充值和提现4小时:9月8日消息，据币安官方公告，币安将于北京时间2022年9月8日14:00对Terra Classic Network（LUNC）进行钱包维护，大约需要四个小时。钱包维护期间，LUNC的交易不受影响，Terra Classic Network（LUNC）暂停充值和提现，维护完成后重新开放充提。[2022/9/8 13:15:59]
在传统中心化结构里，这个损失是可以在后台服务器上检索到；而在区块链上，完全匿名的机制以及不被控制的“服务器”根本无法确定损失的真伪！这陷入一个谁来举证的两难问题。更严重的是，放任不管的话，可能有开发者故意开发免费的“钓鱼”钱包，让用户的资金以某种隐晦的方式转到一个不知名的地址，这又如何取证和追责？
比特币倡导者Nic Carter因支持钱包身份验证项目Dynamic而受到批评:6月29日消息，推特加密用户对知名比特币倡导者Nic Carter提出批评，原因是他参与了一个第三方钱包认证项目Dynamic。对于Dynamic而言，如果一个钱包被归类为存在风险，该项目可能会阻止其进行钱包交易。
Carter在推特上分享了他对支持该项目的兴奋之情，并发布了Dynamic最近的融资公告。随后，加密用户纷纷涌向Carter的推特，表达他们对此举的失望之情。然而面对批评，Carter坚持自己的立场，在推特上回应了这些指控，还称批评他的人不高兴的话可以取关自己。
此前消息，Web3身份验证初创公司Dynamic完成750万美元种子轮融资。（Cointelegraph）[2022/6/29 1:39:48]
上面这个案例是最简单的。回到到现实中，一旦钱包和用户存在频繁的交互，并且存在服务器的话，这里面的问题就更显得严重了。
首先服务器的存在是为了提供信息服务，这必然存在一个主体，否则服务器的成本如何支付？当这个主体存在，那么关联关系是否确定为法律关系？或者确定怎样的法律关系？其次，与上面简单例子类似，但我们更为直接一点，有人逆向工程了这个钱包，并制造“同样”的钱包，然后证明它造成了“损失”，是否可以向开发者或者提供服务器的主体申请赔偿？这是第一步。这第一步的疑问是，这个证据是否可信以及谁来举证，如果要求损失者证明确实是钱包的bug，并且证明损失是真实的，这对一个不懂技术的普通人，是否要求太高？第二步是，如果真的是钱包的问题，这样的流程是不是对使用者公平？或者是否会带来各种“钓鱼”程序的肆无忌惮？如果整个过程要求开发者和服务器提供方自证清白，这是不是已经假设了开发者应当为此负责，那么损失的规模是开发者无法定义的，都是使用者左手倒右手，这种风险敞口谁能承担得了？
以上是一个悖论，使用者需要安全，开发者又无法承担不安全导致的“损失”，这中间缺失了一环。
传统的互联网世界，这个风险是由公司或者项目方来承担的，因为他们能控制产品或者服务的整个流程。但是在区块链，这些所谓的开发者不能完全控制自己提供交互的全部流程，最重要的一部分是在链上完成的，他们实际上只提供了一个“前端工具”。
解决这个问题的未来方向，预计有两个：
第一个是使用者全部委托给开发者或者项目方，比如中心化交易所，我把币打给你，放弃了私钥管理，那责任就完全在你了，这个方向是逻辑闭环的。
第二个是开发者将自己的程序代码全部开源并定义清楚，上传到一个第三方中立平台，交由市场来评定，愿意用的就用，用则接受免责协议，开发者与此无关。
这第二个也能做到逻辑闭环，但代码的漏洞就由市场上的使用者来消化了。比较困难的是，提供了信息服务的DAPP，即存在服务器的产品，应当如何对信息服务的部分进行责任安排？这就需要法律的跟进了，因为这一块不像第一个问题影响那么严重，也不像第二个问题那样完全无关，这是整个钱包问题里最为复杂的情况了。需要对公链上应用的责任边界进行认定，涉及很多法律配套，是个漫长的基础设施建设过程。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。