NEAR发布以太坊彩虹桥升级和治理方案，通过 4 个阶段逐渐去中心化

对任何智能合约（尤其是持有/管理大量通证的合约）来讲，可升级性流程及其治理都是重要的一个方面。该流程定义了谁能够以及如何通过上传一套新版本的合约执行代码来改变智能合约的行为。显然，可升级性流程本身也是可以不断加以调整和“升级”的。

本文旨在介绍智能合约可升级性模式，将其与彩虹桥架构进行匹配，并提出对这些升级进行治理等改进的阶段性计划。 我们会在这里对提出的计划进行讨论，并根据社区和验证节点的评论加以调整并确定最终方案。当前我们需要对主要方案达成一致，具体细节则可以以后慢慢调整。我们会在2021年3月16日（星期二）结束讨论，形成对可升级性计划的最终决定。我们会根据用户的反馈对介绍提议的原始文章不断更新。

为什么这很重要

只要人们有办法对合约代码进行更改，那么即便是已经经过审计和广泛测试的合约，仍然会由于版本的更新而出现严重漏洞，并最终给该合约持有的通证带来损失。这对彩虹桥合约是至关重要的。彩虹桥合约需要跟锁定通证打交道，对桥接的通证的铸造和销毁拥有全部控制权。这也是为什么所有的升级都应该接受全面测试和验证，尤其是在项目晚期阶段更应如此。然而，安全方面有利有弊。在理想状态下，合约代码没有缺陷，所以不需要快速的或隐性的升级以修补关键漏洞（有关此类升级的影响，可参见‘以太坊是一片黑森林’以及‘逃离黑森林’这两篇文章）。在这种情况下，我们可以分阶段升级并联合多方代表就升级进行投票（时间周期往往很长）。对此类方法的使用已有先例，比如比特币协议升级就是采用的这类方法。不过遗憾的是，投票周期可能会持续数月之久。

文章一： https://twitter.com/ilblackdragon/status/1367408735837188096

文章二： https://samczsun.com/escaping-the-dark-forest/

现实中的合约是存在漏洞的，尤其是在早期阶段，这种情况尤为明显。因此当通证存在风险的时候，能够快速升级以解决此类问题，将升级时间缩至最短就变得很有必要。这样就把分阶段升级和投票的方法排除在外，因为黑客将能够分析升级代码，找到真正的漏洞所在并加以利用。然而，如果开发者未对升级进行充分测试，或者故意实施某些恶意行为，被锁定的通证仍然可能失窃。不存在一体适用的解决方案：全部方案都有各种权衡。因为彩虹桥是NEAR生态中很重要的一部分，包括不打算使用彩虹桥的用户在内的每个人都应该知道彩虹桥的治理方式和升级方式。

问题范围

“彩虹桥架构第二版”增加了这一问题的复杂性。以下是关于彩虹桥架构的几个不同方面：

1. NEAR区块链

核心合约，比如EthClient,EventProver
核心连接器，比如FungibleTokenConnector
定制化连接器，由第三方开发

2. 以太坊区块链

核心合约，如NearClient,NearProover, BorshDecoder, Ed25519
核心连接器，如Erc20Connector
定制化连接器，由第三方开发

3. 非区块链服务

区块中继器，负责把区块头发给客户端，保证彩虹桥运正常运转
监管者-负责对提交给以太坊的NEAR区块头进行检查，发生错误区块被提交的情况时，给系统发送质疑。
交易中继器（尚未开发）负责代表用户发送最终交易，有效地将用户与彩虹桥之间的互动变得原子化

非区块链服务可能会由任何人运行，彩虹桥的设计方式决定了即使是这些服务的错误行为也不会将资金置于危险之中。只要有一对未被破坏的区块中继器和监管者便足以拥有一套健康的和最新的彩虹桥基础设施，我们将能够快速运转起来。服务若发生任何问题，它们会修复漏洞并重启。我们鼓励社区或者通过托管副本提升冗余，或者开发监管者脚本，后者会在发现异常行为时抛出警告。尽管定制化连接器对本次讨论来说似乎不是很重要，但有两点考虑需要我们注意：

如果我们能就连接器的可升级性提供一个建议方法（目的是避免核心彩虹桥升级出现的一些问题），这对开发者来讲将会是很有帮助的。
定制化的连接器正使用核心合约，合约的接口（方法、参数）未来可能会根据升级发生改变，所以这些连接器应该采用一种通用的升级方案。

此外，需要我们记住的是存储通证/数据的合约是连接器，而核心的彩虹桥合约的用途仅限于验证。因此，我们需要在升级期间对连接器合约多加留意。核心的彩虹桥合约能够被再次部署至新地址，并且不会对系统造成任何重大损害（转账会有些延迟，连接器需要更改核心彩虹桥的链接以及调用接口）。

现有方法

这篇来自 OpenZepplin的博客是讲述以太坊可升级性方法的最全面同时也是最新的一篇文章。若想了解更多信息，也可查看Consensys博客。

OpenZepplin: https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/

Consensys: https://consensys.github.io/smart-contract-best-practices/software_engineering/

简而言之，以下方法被广泛使用：

1. 注册表 。一个特殊的“注册表”合约，可对合约的各个版本进行追踪。用户/合约在与合约交互之前应该从注册表中获得最新版本的合约的地址。

优点：简单，易于审计，能与多个版本协作
缺点：数据迁移不清晰，需要额外调用来查询实际使用的合约

2. 参数/策略配置/特定功能 。合约拥有更新参数或地址链接的方法，此类地址会执行该逻辑中的部分片段。

优点：可以进行微调，主合约代码不可更改的特性为用户带来额外的安全性。
缺点：主合约中的漏洞无法被修复，高度依赖使用场景，没有标准的经过测试的代码

3. 代理。 一个特殊的代理合约，只负责将代码调用委托给执行合约。

优点：地址是静态的，数据与执行是隔离的
缺点：设计复杂，可能会因为EVM的某些具体情况（函数筛选冲突，存储冲突）导致很多问题发生

4. 可变合约 （metamorphic contracts）。合约使用CREATE2操作码部署，能够在使用selfdestruct操作码之后进行升级

优点：不需要代理（proxy）
缺点：合约状态在升级过程中被删除，不能在单个交易内发起升级，由此带来合约会有停机时间

治理

除了可升级性，升级治理还有很多不同的方法：

1. 单一秘钥/外部拥有账户 。一把单一秘钥能够对合约进行升级

优点：速度快
缺点：中心化，存在单点故障

2. 多签。M把秘钥中要有N把对升级进行签名

优点：参与方数量不是很大的情况下非常快速，不存在单点故障问题
缺点：仍然是PoA模型；需要为{Ethereumconsensus, NEAR consensus}集合引入额外的信任实体。

3. 时间锁 。合约的所有者（合约或单个秘钥）能够筹划升级，从筹划交易开始到完成，一般耗时1~7天

优点：用户如果不同意升级，有足够的时间中止服务
缺点：无法快速升级，在筹划期黑客可以分析代码并破解当前版本

4. 可暂停性 （带有逃生舱）。合约可以执行一个暂停全部操作的方法。在暂停模式下，对合约进行的任何操作都是不被允许的，或者用户也可以中止该项服务。

优点：有逃生舱，为时间锁的安全升级问题提供了解决方案
缺点：暂停本质上是中心化的，因此应该在时间上有所限制

5. “提交-展示”升级 。安全升级提议（以哈希形式）被提交给合约，代码被展示给受信任的安全专家。审批通过之后，升级就会被展示并同时被应用。

优点：为时间锁的安全升级问题提供了解决方案，减少了黑客对漏洞进行倒序开发的风险
缺点：与多签治理几乎没什么区别

6. DAO/total voting 。合约由利益相关者的投票治理。在NEAR的平台中，我们指的是验证节点投票。

优点：完全的去中心化，如果投票出了问题，这意味着NEAR协议层也会出现问题了，这时彩虹桥会是次要问题。
缺点：速度可能会慢一些，如何应用安全补丁尚不清楚，验证节点的职责范围会被扩大。投票决策也应该被发送至以太坊合约，如果彩虹桥停止运行，上述操作可能会发生问题。

当前事务状态

注：关于NEAR区块链智能合约的可升级性，目前还没有完全确定的指导方案。最值得注意的是这份提议。来自以太坊的全部方法也都可采用。

提议： https://github.com/near/NEPs/pull/123 目前彩虹桥的可升级性按照以下方法实现：

1. 以太坊

核心合约目前是不可升级的，不过它们已通过了安全审计。核心彩虹桥升级通过发布新的彩虹桥实例来运行，使得连接器需要更改地址来进行交易完成性的验证
同质化通证连接器拥有特殊功能，可允许转移通证至新的部署环境
治理模型使用单个秘钥

2. NEAR

核心合约通过了安全审计，不过拥有完整的访问秘钥。我们能够在同样的账户里部署新版本的合约，这样连接器不用再更改证明地址了。
同质化通证连接器也拥有完整的访问秘钥，可以在地址不发生改变的情况下被更新。

可升级性方案设想

代码中的漏洞数量在彩虹桥的运行初期达到峰值，之后会逐渐下降
彩虹桥测试范围会逐渐扩大
升级的测试次数会越来越多，考量也会越来越重
产品的用户基础会逐渐增加
彩虹桥中的锁定价值会逐渐增加（错误的成本也会增加）

一般考虑事项

将设想和通用实践考虑在内，我们建议就彩虹桥合约的可升级性使用分阶段的方法：早期阶段将会有简单的可升级性模型，治理模式将更为中心化，之后会发展为更为去中心化的方法。

阶段1：中心化治理，没有固定的接口

* 这样做的目的是为避免迁移桥接/锁定通证，同时让用户可以提取通证。该方法十分简单，允许快速迭代，可通过将通证存放在安全地方的方式对重大漏快速做出反应。重要：未来和彩虹桥集成（无论是合约层面还是区块链外部）的全部DApp都应该能够更新集成代码，包括合约地址和接口。

阶段2：独立的多签治理，代理模式

由一小组经验丰富的安全工程师和若干家企业组成了彩虹桥治理委员会。这些实体持有两条链的多签合约的秘钥。核心彩虹桥合约和以太坊连接器实现代理模式，不过合约的实际接口未来可能会有所改变。我们排除了单点故障的风险，但代价是系统对漏洞的反应速度会有所降低。总体来说，该方法让彩虹桥拥有了更强的风险承受能力。重要：未来和彩虹桥集成（无论是合约层面还是区块链外部）的全部DApp都应该能够更新集成代码，尽管合约地址不会被更改。

阶段3：独立的多签治理，拥有冻结期的代理模式、可暂停性、逃生舱和固定接口等功能/特点

该阶段会改变治理模型，但不会改变可升级性模式。通过允许用户在任何时候都可以中止该系统，我们正在增加彩虹桥的可预测性，使其对终端用户更加友好。我们使用冻结期处理漏洞。多签合约不能永久性地停止彩虹桥的执行。此外在这一阶段，各个接口大致是固定的，这意味着不必同时升级彩虹桥的集成和彩虹桥本身。重要：使用彩虹桥的用户在该阶段需要关注彩虹桥的更新。发生资金风险以及开发团队无法及时对问题进行修复的情况时，我们会要求用户使用逃生舱服务将资金从彩虹桥取出。一旦暂停阶段结束，仍然存放在彩虹桥内部的资金将会处于风险之中。

阶段4：验证节点DAO，代理模式，拥有冻结期、可暂停、逃生舱、固定接口等功能/特点

在本阶段中，我们将向完全去中心化和无需许可的治理模型过渡，该模型与NEAR的共识机制是一致的。能够更新彩虹桥和连接器的实体是一个验证节点DAO。完成升级需要2/3+1个质押。然而，对于较为严重的漏洞，我们仍然保留了安全团队负责此事。该团队将能够暂停彩虹桥和连接器的运转，并将漏洞通知给验证节点。该方法保证了彩虹桥用户能受到最好的安全保障。注：为了更新以太坊合约，NEAR验证节点应该在NEAR链上投票，之后系统会使用一个新的定制连接器将他们的决策桥接至以太坊。

阶段过渡路线图

阶段之间的过渡应该经过社区同意，且很有可能取决于彩虹桥的使用体验：用户活跃度、总锁定价值、漏洞赏金项目、重大漏洞出现频率等。现在很难预测阶段间的过渡什么时候会发生。彩虹桥开发团队致力于开发能够执行可升级性和治理模式的代码，不过我们会把过渡的各项指标的决定权交给社区，这与社区决定第二阶段主网过渡一事类似。根据我们对彩虹桥的设想，我们相信过渡至第四阶段是我们的终极目标，通往该阶段的过程需要对彩虹桥用户确保安全。

结语

尽管提议的可升级性和治理计划看起来有些复杂，事实上，该计划实施了一个简单的想法：一次只增加最终功能的一小部分.

第二阶段推出多签合约和代理模式等操作
第三阶段推出冻结期、可暂定性和逃生舱等功能
第四阶段推出去中心化治理

在这些迁移过程中，几乎没有删除任何代码（除了第四阶段中对以太坊合约的多签治理）。功能发布的顺序和他们的复杂度与价值的比例的提升是相对应的。

原创文章，作者：CoinKaola，如若转载，请注明出处：https://www.coinkaola.co/news/216214/