引介 | StarkEx 作为自主托管型方案,Part-1:引言

引言

StarkEx 是一种可扩展性引擎,同时支持用户自主托管资金;这才刚刚登陆以太坊主网(有关整个系统的整体架构和流程,请见 此处 )。StarkEx 实现了 STARK 证明系统的零知识(Zero-Knowledge Proof,ZKP)版本。实现自主托管功能的道路崎岖难行:托管方案会更简单、更便宜,而且(最重要的是)更容易理解 —— 大家已经习惯托管型的软件系统很多年了。“自主托管系统”,或者叫 “非托管型系统”,其实运用得相当广泛。只要是用户能预设自己可以(一键)完全控制自己资金的系统,都可以这么称呼:免许可型区块链一开始就是被当成托管型系统的替代方案而提出的,想到这一点,你会觉得现状很魔幻。我们知道建立一个完全自主托管的系统的难度,也知道在这个圈子里搞创新有很多维度。我们还觉得,随着时间推移,大家会发现迁移到一个更加自主托管的系统中总是有用的。 本系列的博文 会详细说明我们做出的选择,以及我们为 StarkEx (在这个维度上)设定的方向。

本文是我们系列博客的第一篇,准备讲讲我们在保证 StarkEx 是并且永远是自主托管型方案的道路上付出的努力。

首先,有必要定义一下 “自主托管(self-custodial)”是什么意思。在我们看来,仅当一个系统满足下列属性时,它才能被叫做 “自主托管型系统”:

  1. 没有用户的明确签名,资金就不能转移;
  2. 在签名的时候,用户可(通过钱包的用户体验设计)获得所有的信息;
  3. 资金随时可退出;
  4. 代码升级机制即使被滥用也不能破坏上述机制。

本文将致力于解释:(1)为什么说 证明系统 最适合于支持自主托管型方案;(2)StarkEx 智能合约的 审计 状况。后续博文会依次讲解(3)我们所用的 智能合约升级机制 ;(4) 钱包支持 (STARK 签名方案及整合方法);(5) 数据可用性 (从我们第一个版本所用的数据可用性委员会方案,到完全免信任的链下数据可用性方案)。

自主托管性作为一个神圣的理想,可追溯到区块链最初的愿景,一句话:“没拿着私钥的,就不算你的币(not your keys, not your coins)”。早些时候,因为 Layer-1 的吞吐量局限,自主托管这个理想往往让位于可扩展性(以及流动性)。这种让步的结果就是中心化的交易所:交易所托管着交易者的密码学资产,交易者得到的好处是流动性(还有 相当大的对手方风险 )。但今天,ZKP 系统背后的科学和工程技术都变得更成熟了,尤其是 STARK,我们已经完全迎来了奇点 —— 再也没必要去作这种让步了。

ZKP 系统的历史 既美丽又复杂 。重点是,ZKP 系统能以免信任的模式,为公链提供可扩展性和隐私性。而自主托管型解决方案恰好需要免信任的基础设施。换句话说,如果需要信任某个实体,即使没让 “自主托管” 变成一句空话,也会大大削弱其意义。

ZKP 系统有两个部分:提供 “ 计算完整性(CI) ” 的基础层,以及在此之上保证零知识的概率层。要实现可扩展性的时候,我们实际上只需要 CI 层。CI 层可帮助参与协议的一方(即证明者)为任意计算(或者说状态转换)在链下生成一个证明,而任意数量的另一方(验证者)可在链上以非常小的计算开销验证这个证明。

理论上来说,信任假设当然是越少越好。具体而言,对 STARK 来说:

  • 不需要对验证者作任何信任假设,既不需要实时的信任关系,也不需要预处理的信任关系,因为 STARK 不需要受信任的初始化设置(trusted setup)。说得极端一些,即使由一个恶意团体使用恶意的硬件来充当证明者,计算不同则证据一定不同,错误的计算所生成的证明无法通过检验。
  • 验证者在链上运行,需要保证资源是足够的。

StarkEx 是一种为交易所设计的可扩展性引擎,但 STARK 也可以用于为其它应用提供可扩展性。使用的时候,应用的部分逻辑要在链下实现,而需要与链上实体(智能合约、账户,等等)交互的逻辑则要作为应用智能合约(ASC)在链上实现。

StarkEx 的一个用户是我们的合作伙伴,DeversiFi,一个自主托管型交易所。DeversiFi 会使用 StarkEx 来扩展交易操作(包括交易也包括转账)的吞吐量。ASC 保证了没有用户的签名资金就无法转移(签名是通过对 STARK 证据的验证来验明的)。StarkEx 要求用户存储资金到 ASC 中,这就使该 ASC 容易成为黑客的目标。这份 ASC 代码已经经过 审计 和高强度的测试,以保证其正确性和安全性。此外,我们还计划继续使用其它工具,比如形式化验证,来保证代码的正确性和安全性。

审计并不能保证一个系统是安全的,因为合约的掌控账户(admin)可以给合约做一系列升级,让自主托管变成一个空架子。智能合约的升级(或者换句话说叫迁移)让开发者可以修复 bug 并扩展功能。下一篇博客,我们就要讲讲我们是如何设计智能合约升级机制,来保证 StarkEx 能永远保证其自主托管性。

对了,还要提醒一句:大家一般用来形容 “自主托管型方案” 的形容词是 “非托管型(non-suctodial)”,我们不喜欢这个词,因为它是否定形式的,似乎暗示了托管型系统(比如中心化交易所)才是基准,才是值得借鉴的。但托管型解决方案是与公链的精神相悖的。强制托管方回到自己原有的角色,是比特币和以太坊的精神所在,这就是为什么我们更喜欢 “自主托管” 这个词。

原文链接: https://medium.com/starkware/introduction-proof-systems-audits-8ae3512b0df

作者:Tom Brand & Uri Kolodny

翻译:阿剑

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章