V神:探讨打造安全中心化交易平台方法

  每当大型中心化交易平台崩溃时,一个常被提及的问题是:我们是否可以利用加密技术来解决这个问题。交易平台可以通过创建密码学证明的方式证明其链上持有的资金足以偿付用户,而不仅仅依靠政府牌照、审计员、调查公司治理以及交易平台法人背调等「法币」方案。

  更有野心的是,交易平台可以建立一个未经储户同意无法提取储户资金的系统。我们可以尝试探索「不作恶」有职业素养的 CEX 与「无法作恶」却泄漏隐私的低效链上 DEX 之间的界限。这篇文章将深入探讨让 CEX 更加去信任的历史尝试,与其采用技术的局限性,以及一些依赖 ZK-SNARKs 等先进技术的有力手段。

  余额表和 Merkle 树:传统的可偿付证明

  交易平台试图用密码学来证明自己没有欺骗用户的最早尝试可以追溯到很久以前。2011 年,当时最大的比特币交易平台 MtGox 通过发送一笔移动 424,242 个 BTC 到预先公布地址的交易来证明他们拥有该笔资金。2013 年,大家开始讨论如何解决该问题的另一面:证明用户存款的总规模。如果你证明用户的存款等于 X (负债证明 proof of liabilities),并证明拥有 X 个代币的私钥(资产证明 proof of assets),那么就提供了可偿付证明(proof of solvency):你证明了交易平台有足够的资金偿还给储户。

  提供存款证明的最简单方法是公布一个列表。每个用户都可以检查他们在列表中的余额,而且任何人都可以检查完整的列表:(i)每项余额都是非负的;(ii)总额是宣称的金额。

  当然,这会破坏隐私,所以我们可以稍微改变一下该方案:发布一个 username, salt), balance> 列表,并私下给用户发送 salt 值。但即使这样也会泄漏余额与其分布。为了保护隐私,我们采用了后续技术:Merkle 树技术。

  绿色:Charlie 的节点。蓝色:Charlie 收到用于证明的节点。黄色:根节点,向所有人公布

  Merkle 树技术会将用户余额表放进 Merkle 总和树。在 Merkle 总和树中,每个节点都是对。底层叶子节点表示各个用户的余额以及用户名的加盐哈希。在每个更高层的节点中,余额是下面两个节点余额的总和,而哈希是下面两个节点的哈希。Merkle 总和证明和 Merkle 证明一样,是一个由叶子节点到根节点路径上所有姐妹节点组成的「分支」。

  首先,交易平台会向每个用户发送一份其余额的 Merkle 总和证明。然后,用户能够确定其余额作为总额的一部分而被正确地包含。可以在这里找到简单的示例代码。

  Plasma 的一个版本的极简图。代币被保存在智能合约中,该合约在取款时会强制执行 Plasma 协议的规则。

  OmiseGo 试图基于此协议创建一个去中心化交易平台,但从那时起,他们就转向去做其他事了——就这而言,Plasma Group 也是如此,他们去做了 optimistic rollup 项目 Optimism。

  2018 年对 Plasma 的局限性(如,证明代币碎片整理)的探讨让大家从根本上怀疑 Plasma 的可行性。自 2018 年对 Plasma 的探讨达到顶峰以来,ZK-SNARKs 在扩容相关用例上变得愈加可行,正如我们上面所说的,ZK-SNARKs 改变了一切。

  Plasma 更新的版本是 Starkware 称为 validium 的方案:除了数据被保存在链下以外,基本上与 ZK-rollup 相同。该构造适用于许多用例,可以想象其适用于任何中心化服务器需要证明其正确执行代码的场景。在 validium 中,运营方无法窃取资金,但根据具体的实现细节,如果运营方消失,一些用户资金可能会被卡住。

  现在看来一切很棒:CEX 和 DEX 远非二选一,事实证明,其中有一系列的选择,包含各种形式的混合中心化,在那里你能获得一些好处,比如效率,但仍有很多密码学保障,可以防止中心化运营方的大部分形式的恶意行为。

  然而,余下的基本问题也值得思考:如何处理用户错误。到目前为止,最重要的错误类型是:如果用户忘记了密码、丢失了设备、被黑或无法访问其帐户,那该怎么办?

  交易平台可以解决这个问题:首先利用电子邮件恢复,如果连这都失败了,再通过 KYC 进行更复杂的恢复。但若要解决这些问题,交易平台需要真正控制这些代币。为了能够合理地恢复用户资金,交易平台需要拥有同样可用于无故窃取用户资金的权力。这是一个不可避免的权衡。

  理想的长期解决方案是依靠自我托管,用户在未来可以方便地使用诸如多签及社交恢复钱包等技术来帮助处理紧急情况。而短期内,有两种明显的替代方案,有着不同的成本和收益:

  另一个重要问题是对跨链支持:交易平台需要支持很多不同的链,诸如 Plasma 和 validiums 等系统需要用不同的语言编写代码以支持不同的平台,并且在当前形式下无法在一些平台(尤其是比特币)上实现,这有望通过技术升级和标准化来解决;然而,从短期来看,这是如今托管型交易平台保持托管模式的另一个原因。

  结论:展望未来更好的交易平台

  短期内,有两种明确的交易平台类别:托管型交易平台和非托管型交易平台。如今,后一类即像 Uniswap 那样的 DEX,未来我们可能还会看到受密码学约束的 CEX,其中用户资金会以类似 validium 智能合约的方式持有。我们也可能会看到半托管型交易平台,其中我们信任其对法币而非加密货币的处理。

  这两种类型的交易平台将继续存在,而提高托管型交易平台安全性的向后兼容最简单方法是增加储备证明。这包括资产证明和负债证明的结合。为两者都设计出优秀的协议仍存在着一些挑战,但我们能够且应当推动两类技术的齐头并进,并尽可能开源软件和程序,以便所有交易平台都能获益。

  从长远来看,我希望我们向着所有交易平台皆为非托管的方向发展,至少在加密货币上如此。钱包恢复将会存在,可能需要为小额资金的新用户和出于法律因素需要此类安排的机构提供高度中心化的恢复选项,但这可以在钱包层而非交易平台内部完成。在法币方面,传统银行系统和加密货币生态系统之间的移动可以通过 USDC 等资产背书稳定币原生的资金进出流程完成。然而,我们仍有很长的路要走。

  [1] 译者注:

  每 16 个数字代表一个用户(前面 15 个数字代表该用户的余额,最后一位代表目前为止用户余额总和跟声明的差额)。我们可以看到上面的举例代表了两个用户(这里要读者洞察一下)

  宣称的用户平均余额:185

  用户 1 的余额:20 -> 000 0000 0001 0100

  差额:20 - 185 = -165

  用户 2 的余额:50 -> 000 0101 0011 0010

  差额:-165 + 50 -185 = -300

  最终遍历完所有用户,最后一个用户的差额要求为 0

  四个等式的解释

  等式 1:递推的初始值为 0

  等式 2:每个用户余额需要跟 KZG commitment 相对应

  等式 3:每个用户余额的递推公式,约束余额 >= 0 且 214

  (上面说余额 215 应该是笔误,因为按照等式 3,递推公式只有 14 个取值,I(zi) 214,

  16 个数字对应:I(z)=0| I(z) | I(z) | … | I(z) | 差值

  16 个数字对应最大取值:0 | 21-1 | 22-1 | … | 214-1 | 差值)

  等式 4:约束所有用户总余额与交易平台宣称的余额一致

以上内容为新媒号(sinv.com.cn)为大家提供!新媒号,坚持更新大家所需的财经知识百科。希望您喜欢!

版权申明:新媒号所有作品(图文、音视频)均由用户自行上传分享,仅供网友学习交流,不声明或保证其内容的正确性,如发现本站有涉嫌抄袭侵权/违法违规的内容。请发送邮件至 k2#88.com(替换@) 举报,一经查实,本站将立刻删除。

(0)
上一篇 2023-01-04
下一篇 2023-01-04

相关推荐

发表回复

登录后才能评论