进级：各个逻辑合约版本的地点均存储在署理合约内。新版本在激活之前，先要锁定一段时间，即，我们所说的进级激活延迟：upgrade_activation_delay （设为 28 日）。upgrade_activation_delay 比 StarkEx Escape Hatch（逃生舱口）的脱期期长得多。在特按时间点，所有版本中只有一个是激活的，不外授权打点员可以在未锁定的版本之间即时切换。
StarkEx 是一种自主托管式可扩展性引擎。我们已经先容过了自主托管式系统的各个方面，个中可进级性也是一个方面。本文将要先容我们为 StarkEx 构建的可进级性机制，这是确保 StarkEx 维持自主托管性的要害。进级机制和掩护自主托管
· 办理方案：当即（不设时间锁）添加一个新的验证者合约即可办理靠得住性裂痕，因为每一次状态转换必需被所有已陈设的验证者接管：通过陈设新的验证者合约来拒绝无效转换，就足以让系统将无效状态转换拒之门外了。
正如我们在上文所述，进级智能合约的主要原因之一是检测出了安详性风险。安详性风险可以分为以下三类：
· 办理方案：添加一个新的逻辑合约版原来修复该裂痕。
为了更好地领略这些验证合约的累积性，请把它们想象成筛子：验证者合约就像是网眼很密的筛子，仅答允有效语句通过。StarkEx 没有利用新筛子替换旧筛子，而是要求语句既要通过之前的筛子，又要通过新陈设的筛子。新的筛子不会让无效的语句通过验证，只能 进一步限制 被视为有效的语句荟萃。大大都比特币协议进级（软分叉）也是如此：一旦软分叉执行，之前被视为无效的区块依然是无效的，之前有效的区块也大概会酿成无效的。
2.验证者合约进级：
安详性风险及其办理方案
别的两个合约均提供验证处事：一个被用来验证 STARK 证明（验证者合约），另一个被用来验证数据可用性（DAC 合约）。这两个合约本质上是相似的，因此均由逻辑合约执行，而且回收沟通的方法进级。
· 风险：恶意用户大概会操作合约中的裂痕来滥用 API ，盗走合约中的资金。StarkEx 应用运营者需要具备实时修复这类裂痕的本领，因为拖得越久损失越大。
自主托管：在新版本解锁之前，系统预留了足够长的时间让用户举办审查。假如有用户认为新版本不行接管，可以选择退出 StarkEx ，并向其他用户发出示警。由于 upgrade_activation_delay 比脱期期久得多，用户有富裕的时间取出资金。
3.DAC 合约进级：与验证者合约在模式和道理上都沟通
3.验证者靠得住性裂痕：
· 风险：这类裂痕会导致验证者合约接管无效状态转换的证明，进而导致用户余额被改动，尤其会导致资金被盗。
· 风险：用户存入智能合约的资金大概会因为裂痕而锁定（譬喻，Parity 多重签名合约裂痕）。
StarkEx 应用智能合约（ASC）回收了署理模式（由 openZepplin 率先引入），因此包括多个子组件。署理合约内存储着所有数据和资金，并（通过一个指针）指向一个界说了成果的地点（也就是逻辑合约 Logic Contract）。通过署理合约，我们在署理合约情况内运行委托挪用（delegate call）来挪用逻辑合约。因此，StarkEx ASC 逻辑是由逻辑合约界说的；整个系统通过陈设新的合约和更新署理合约中的指针来进级（逻辑）。验证者（Verifier）合约和数据可用性委员会（Data Availability Committee，DAC）合约的地点均由逻辑合约而非署理合约引用。
在第一阶段，我们为逻辑合约、验证者合约和数据可用性委员汇合约都单独配置了进级机制。所有进级操纵都只能由颠末许可的地点执行。
自主托管：验证者的任务是接管有效证明，，拒绝无效证明。出于安详性思量，添加验证者的操纵是即时的（无延迟）—— 请留意，是即时添加而非替换。由于证明必需被所有验证者接管（才气被视为有效），即时添加验证者只会变得更安详而不是更不安详，因为无效证明照旧不能被接管。时间锁可以担保已经陈设的验证者不会被当即删除，让社区有富裕的时间审查新添加的合约。
这类裂痕大概会导致资金被锁定和被盗的环境，值得单独拿出来接头，因为 StarkEx 是基于零常识证明的系统。
StarkEx 应用合约
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
