引介

StarkEx 作为自主托管型方案,Part-2:合约可升级性

曾汨   |     |   424 次阅读

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


动因

StarkEx 是一种自主托管式可扩展性引擎。我们已经介绍过了自主托管式系统的各个方面,其中可升级性也是一个方面。本文将要介绍我们为 StarkEx 构建的可升级性机制,这是确保 StarkEx 作为自主托管型系统的关键。

需要升级智能合约代码的情况有两种:增加新功能和修复安全性漏洞。难点在于如何在不损害系统自托管性的前提下引入升级。如果 StarkEx 逻辑被恶意更换,应用运营者就有可能掌控所有用户资产。StarkEx 通过一个新型可升级性机制来保护用户资产。简单来说,这个机制利用了时间锁和三类临时性智能合约(详见下文)。

StarkEx 应用合约简介

1

2

StarkEx 应用智能合约(ASC)采用了代理模式(由 openZepplin 率先引入),因此包含多个子组件。代理合约内存储着所有数据和资金,并(通过一个指针)指向一个定义了功能的地址(也就是逻辑合约 Logic Contract)。通过代理合约,我们在代理合约环境内运行委托调用(delegate call)来调用逻辑合约。因此,StarkEx ASC 逻辑是由逻辑合约定义的;整个系统通过部署新的合约和更新代理合约中的指针来升级(逻辑)。验证者(Verifier)合约和数据可用性委员会(Data Availability Committee,DAC)合约的地址均由逻辑合约而非代理合约引用(如果你想要复习关于 StarkEx 组件的简介,请点击此处)。

升级机制和保护自主托管

在第一阶段,我们为逻辑合约、验证者合约和数据可用性委员会合约都单独设置了升级机制。所有升级操作都只能由经过许可的地址执行。

1.逻辑合约升级:

  • 升级:各个逻辑合约版本的地址均存储在代理合约内。新版本在激活之前,先要锁定一段时间,即,我们所说的升级激活延迟:upgrade_activation_delay (设为 28 日)。upgrade_activation_delay 比 StarkEx Escape Hatch(逃生舱口)的宽限期长得多。在特定时间点,所有版本中只有一个是激活的,不过授权管理员可以在未锁定的版本之间即时切换。
  • 自主托管:在新版本解锁之前,系统预留了足够长的时间让用户进行审查。如果有用户认为新版本不可接受,可以选择退出 StarkEx ,并向其他用户发出示警。由于 upgrade_activation_delay 比宽限期久得多,用户有充足的时间取出资金。

另外两个合约均提供验证服务:一个被用来验证 STARK 证明(验证者合约),另一个被用来验证数据可用性(DAC 合约)。这两个合约本质上是相似的,因此均由逻辑合约执行,并且采用相同的方式升级。

2.验证者合约升级:

  • 机制:逻辑合约内保存了验证者合约的列表。只有在被所有验证者接受的情况下,一个证明才会被视为有效。新的验证者可以立即添加到合约内。但是,在 upgrade_activation_delay 期间,删除验证者需要等待一段时间。
  • 自主托管:验证者的任务是接受有效证明,拒绝无效证明。出于安全性考虑,添加验证者的操作是即时的(无延迟)—— 请注意,是即时添加而非替换。由于证明必须被所有验证者接受(才能被视为有效),即时添加验证者只会变得更安全而不是更不安全,因为无效证明还是不能被接受。时间锁可以保证已经部署的验证者不会被立即删除,让社区有充足的时间审查新添加的合约。

3.DAC 合约升级:与验证者合约在模式和原理上都相同

为了更好地理解这些验证合约的累积性,请把它们想象成筛子:验证者合约就像是网眼很密的筛子,仅允许有效语句通过。StarkEx 没有使用新筛子替换旧筛子,而是要求语句既要通过之前的筛子,又要通过新部署的筛子。新的筛子不会让无效的语句通过验证,只能 进一步限制 被视为有效的语句集合。大多数比特币协议升级(软分叉)也是如此:一旦软分叉执行,之前被视为无效的区块依然是无效的,之前有效的区块也可能会变成无效的。

安全性风险及其解决方案

正如我们在上文所述,升级智能合约的主要原因之一是检测出了安全性风险。安全性风险可以分为以下三类:

1.资金被锁定:

  • 风险:用户存入智能合约的资金可能会因为漏洞而锁定(例如,Parity 多重签名合约漏洞)。
  • 解决方案:添加一个新的逻辑合约版本来修复该漏洞。

2.资金被盗:

  • 风险:恶意用户可能会利用合约中的漏洞来滥用 API ,盗走合约中的资金。StarkEx 应用运营者需要具备及时修复这类漏洞的能力,因为拖得越久损失越大。
  • 解决方案:一超过时间锁限定的期限,就能立即切换到另一个逻辑合约版本。具体来说,系统中会有一个预先加载好且仅允许取款的极简版本。极简版本可以有效地关闭所有合约功能,仅允许用户取款。

3.验证者可靠性漏洞:

这类漏洞可能会导致资金被锁定和被盗的情况,值得单独拿出来讨论,因为 StarkEx 是基于零知识证明的系统。

  • 风险:这类漏洞会导致验证者合约接受无效状态转换的证明,进而导致用户余额被篡改,尤其会导致资金被盗。
  • 解决方案:立即(不设时间锁)添加一个新的验证者合约即可解决可靠性漏洞,因为每一次状态转换必须被所有已部署的验证者接受:通过部署新的验证者合约来拒绝无效转换,就足以让系统将无效状态转换拒之门外了。

原文链接: https://medium.com/starkware/contract-upgradability-d3a4451877c
作者: Tom Brand、Lior Goldberg、Michael Riabzev
翻译&校对: 闵敏 & 阿剑


你可能还会喜欢:

时髦的密码学工具能帮助 DeFi 吗?

以太坊可更新智能合约研究与开发综述

智能合约灵活升级

 
0 人喜欢