引介 | StarkEx 作为自主托管型方案，Part-2：合约可升级性

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

动因

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

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

StarkEx 应用合约简介

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 是基于零知识证明的系统。风险：这类漏洞会导致验证者合约接受无效状态转换的证明，进而导致用户余额被篡改，尤其会导致资金被盗。解决方案：立即（不设时间锁）添加一个新的验证者合约即可解决可靠性漏洞，因为每一次状态转换必须被所有已部署的验证者接受：通过部署新的验证者合约来拒绝无效转换，就足以让系统将无效状态转换拒之门外了。

（文内有许多超链接，可点击左下 ”阅读原文“ 从 EthFans 网站上获取）

原文链接:

https://medium.com/starkware/contract-upgradability-d3a4451877c

作者: StarkWare

翻译&校对: 闵敏 & 阿剑