SDT:Cobo CTO:Merkle Tree储备证明的缺陷及改进思路_fud币总量

原文作者:蒋长浩,Cobo联合创始人兼CTO

随着FTX倒闭后对中心化机构信任的崩塌,CZ在Twitter上呼吁交易所采用MerkleTree的储备证明方法来证明他们没有挪用用户资产。随后多家交易所开始响应并积极准备储备金证明,以向客户保证他们的资金是安全的。然而MerkleTree储备证明方法存在一些基本缺陷。具体来说,中心化机构很容易通过一些路径绕过这种储备证明方法希望实现的无挪用检查。

下文中,我将阐述现有MerkleTree储备证明方法的两个基本缺陷,并就如何改进提出一些想法。

现有储备证明方法的工作原理

为了缓解用户和中心化机构之间的信息不对称,现有的储备证明通常采用传统的审计方法,即由受各方信任的第三方审计公司出具审计报告,证明中心化机构链上持有的资产数量与用户资产余额总和相匹配。

对于负债证明,中心化机构需要生成包含用户帐户信息和资产余额的MerkleTree。MerkleTree本质上建立了用户账户资产余额的匿名化且不可篡改的快照。每个用户可以独立计算其账户的哈希值,并确定他们的账户是否包含在MerkleTree中。

对于储备证明,中心化机构需要提供其持有的链上地址,并对其进行验证和审计。一种常见的做法是要求中心化机构提供数字签名以证明其对链上地址的所有权。

在MerkleTree的快照和链上地址所有权确认完成后,审计机构对负债和储备两端各自的资产总量进行核对,进而判断中心化机构是否挪用了用户资金。

现有储备证明方法的缺陷

1.使用借贷资金通过审计的可能性

储备证明方法存在的一个问题是,审计只是基于某一个特定的时间点并且通常每隔几个月甚至几年才进行一次。也就是说,中心化交易所仍然有机会挪用用户资金并轻易通过借贷的方式在审计期间填补空缺。

2.与外部资金方进行合谋通过审计的可能性

提供相关数字签名并不同于对于相应地址上资产的所有权。中心化机构可以与外部资金方合谋提供链上资产证明。外部资金方甚至可以使用同一笔资金为多家机构同时提供资产证明。目前的审计方法很难对这种欺诈行为进行识别。

关于改进证明方法的一些想法

一个理想的储备证明系统应该向审计者和最终用户提供对负债和储备进行实时检查的能力。但是,它也会随之带来高昂的成本和/或用户帐户信息的泄露。在获得足够数据的情况下,第三方审计公司甚至可以根据匿名数据推断出用户的仓位信息。

为了防止审计期间储备证明被伪造的可能性且不以泄露用户信息为代价,我在此提出以下两个主要想法:

1.抽查式随机审计

以不可预测的时间间隔进行随机审计将使中心化机构很难操纵账户余额和链上资产。这种方法还可以通过对被随机性审计抓包的忌惮来威慑不当行为。

如何实践:审计请求可以由受信任的第三方审计机构随机发送至中心化机构。在收到指令后,中心化机构需要生成MerkleTree,其中包含在该特定时间点即按照区块高度编号标记的用户账户余额。

2.用MPC-TSS方案来加速储备证明

在随机审计期间,中心化机构需要在很短的时间内提供储备证明。这对于为用户管理大量链上地址的中心化机构来说是一个很大的挑战。即使中心化机构可以将其大部分资产存储在几个固定的地址上,存储在大量链上地址中的资金总量仍然很大。在审计期间将所有这些地址中的资金归集到少数的公开地址上是一项非常耗时的工作。这样的时间差也给了挪用行为足够的空间可以去寻求借贷或资金帮助来填补空缺。

中心化机构是否有可能直接在其真正持有资产的地址上证明储备,而无需将链上资产整合到少数地址上?一种可能的方法是利用MPC阈值签名方案(MPC-TSS)技术。

概括来说,MPC-TSS是一种先进的加密技术,它将私钥分成两个或多个私钥分片,并在加密后由多方持有。这些私钥分片的持有者可以在无需交换各自的私钥分片或合并私钥的情况下共同合作签署交易。这个MPC-TSS托管技术也是Cobo最近已经推出的一个产品。

在这个解决方案下,第三方审计机构可以持有一份私钥分片,而中心化机构持有剩余的私钥分片。只要将「阈值」设置为大于一的数字,所有资产仍将处于中心化机构的控制之下。同时要指出的是,为了让中心化机构能够生成大量由审计方共管的地址,MPC-TSS共管方案需要支持BIP32协议。由于拥有一把私钥分片,审计机构可以确定的知道中心化机构链上的地址集合,并且统计出在指定区块高度中心化机构的资产规模。

感谢包括DiscusFish、LilyKing、Jeanette、Tavia、Linfeng、Ellaine在内的Cobo同事们在撰写本文期间所提出的所有宝贵讨论和建设性建议。

原文链接

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

区块博客

[0:31ms0-3:517ms