以太坊扩容引擎StarkEx作为自主托管型方案：合约可升级性

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

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

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

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

1.逻辑合约升级：

升级：各个逻辑合约版本的地址均存储在代理合约内。新版本在激活之前，先要锁定一段时间，即，我们所说的升级激活延迟：upgrade_activation_delay（设为 28 日）。upgrade_activation_delay比Escape Hatch（逃生舱口）的宽限期长得多。在特定时间点，所有版本中只有一个是激活的，不过授权管理员可以在未锁定的版本之间即时切换。

自主托管：在新版本解锁之前，系统预留了足够长的时间让用户进行审查。如果有用户认为新版本不可接受，可以选择退出 StarkEx ，并向其他用户发出示警。由于 upgrade_activation_delay 比宽限期久得多，用户有充足的时间取出资金。

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

2.验证者合约升级：

机制：逻辑合约内保存了验证者合约的列表。只有在被所有验证者接受的情况下，一个证明才会被视为有效。新的验证者可以立即添加到合约内。但是，在 upgrade_activation_delay 期间，删除验证者需要等待一段时间。

自主托管：验证者的任务是接受有效证明，拒绝无效证明。出于安全性考虑，添加验证者的操作是即时的（无延迟）—— 请注意，是即时添加而非替换。由于证明必须被所有验证者接受（才能被视为有效），即时添加验证者只会变得更安全而不是更不安全，因为无效证明还是不能被接受。时间锁可以保证已经部署的验证者不会被立即删除，让社区有充足的时间审查新添加的合约。

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

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

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

1.资金被锁定：

风险：用户存入智能合约的资金可能会因为漏洞而锁定（例如，Parity 多重签名合约漏洞）。

解决方案：添加一个新的逻辑合约版本来修复该漏洞。

2.资金被盗：

风险：恶意用户可能会利用合约中的漏洞来滥用 API ，盗走合约中的资金。StarkEx 应用运营者需要具备及时修复这类漏洞的能力，因为拖得越久损失越大。

解决方案：一超过时间锁限定的期限，就能立即切换到另一个逻辑合约版本。具体来说，系统中会有一个预先加载好且仅允许取款的极简版本。极简版本可以有效地关闭所有合约功能，仅允许用户取款。

3.验证者可靠性漏洞：

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

风险：这类漏洞会导致验证者合约接受无效状态转换的证明，进而导致用户余额被篡改，尤其会导致资金被盗。

解决方案：立即（不设时间锁）添加一个新的验证者合约即可解决可靠性漏洞，因为每一次状态转换必须被所有已部署的验证者接受：通过部署新的验证者合约来拒绝无效转换，就足以让系统将无效状态转换拒之门外了。