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

​For any smart contract (especially a contract that holds/manages a large number of tokens), the upgradeability process and its governance are an important aspect. This process defines who can and how to change the behavior of the smart contract by uploading a new version of the contract execution code. Obviously, the upgradeability process itself can be continuously adjusted and “upgraded”.

This article aims to introduce the upgradeability model of smart contracts, match it with the Rainbow Bridge architecture, and propose a phased plan for governance and other improvements to these upgrades. We will discuss the proposed plan here, adjust it based on the comments of the community and verification nodes, and determine the final plan. At present, we need to reach an agreement on the main plan, and the specific details can be adjusted slowly in the future. We will conclude the discussion on March 16, 2021 (Tuesday), and make the final decision on the upgradeability plan. We will continue to update the original article introducing the proposal based on user feedback.

Why this is important

As long as people have a way to change the contract code, even a contract that has been audited and extensively tested will still have serious vulnerabilities due to the version update, and eventually cause losses to the tokens held by the contract. This is crucial to the Rainbow Bridge contract. The Rainbow Bridge contract needs to deal with the locked pass, and has full control over the casting and destruction of the bridged pass. This is why all upgrades should be fully tested and verified, especially in the late stages of the project. However, security has pros and cons. In an ideal state, there are no defects in the contract code, so there is no need for quick or hidden upgrades to fix critical vulnerabilities (for the impact of such upgrades, see “Ethereum is a Black Forest” and “Escape from the Black Forest”. Article). In this case, we can upgrade in stages and join multiple representatives to vote on the upgrade (the time period is often very long). There are precedents for the use of such methods, such as the Bitcoin protocol upgrade. Unfortunately, the voting cycle may last for several months.

Article 1: https://twitter.com/ilblackdragon/status/1367408735837188096

Article 2: https://samczsun.com/escaping-the-dark-forest/

There are loopholes in the actual contract, especially in the early stage, this situation is especially obvious. Therefore, when the token is at risk, it is necessary to be able to quickly upgrade to solve such problems, and to minimize the upgrade time. This excludes the phased upgrade and voting methods, because hackers will be able to analyze the upgrade code to find the real vulnerabilities and take advantage of them. However, if the developer does not fully test the upgrade or deliberately implements some malicious behavior, the locked token may still be stolen. There is no one-size-fits-all solution: all solutions have various trade-offs. Because the Rainbow Bridge is a very important part of the NEAR ecosystem, everyone including users who do not plan to use Rainbow Bridge should know how to manage and upgrade Rainbow Bridge.

Problem scope

The “Rainbow Bridge Architecture Second Edition” adds to the complexity of this issue. Here are a few different aspects of the Rainbow Bridge architecture:

1. NEAR Blockchain

  • Core contracts, such as EthClient, EventProver
  • Core connector, such as FungibleTokenConnector
  • Customized connector, developed by a third party

2. Ethereum blockchain

  • Core contracts, such as NearClient, NearProover, BorshDecoder, Ed25519
  • Core connector, such as Erc20Connector
  • Customized connector, developed by a third party

3. Non-blockchain services

  • The block repeater is responsible for sending the block hair to the client to ensure the normal operation of the Rainbow Bridge
  • Supervisor-responsible for checking the NEAR block header submitted to Ethereum, and sending a question to the system when an incorrect block is submitted.
  • The transaction repeater (not yet developed) is responsible for sending the final transaction on behalf of the user, effectively atomizing the interaction between the user and the Rainbow Bridge

Non-blockchain services may be run by anyone. The design of Rainbow Bridge determines that even the wrong behavior of these services will not put funds at risk. As long as a pair of uncorrupted block repeaters and regulators is enough to have a healthy and up-to-date Rainbow Bridge infrastructure, we will be able to get up and running quickly. If there is any problem with the service, they will fix the vulnerability and restart. We encourage the community to either increase redundancy by hosting copies, or develop supervisor scripts, which will throw warnings when abnormal behavior is discovered. Although the customized connector does not seem to be very important to this discussion, there are two considerations that require our attention:

  1. If we can provide a suggested method on the upgradeability of the connector (the purpose is to avoid some problems in the core Rainbow Bridge upgrade), it will be very helpful for developers.
  2. Customized connectors are using core contracts, and the interface (methods, parameters) of the contract may change in the future according to upgrades, so these connectors should adopt a general upgrade plan.

In addition, what we need to remember is that the contract that stores the token/data is a connector, and the core Rainbow Bridge contract is only used for verification. Therefore, we need to pay more attention to the connector contract during the upgrade. The core Rainbow Bridge contract can be deployed to a new address again without causing any major damage to the system (the transfer will be delayed, and the connector needs to change the core Rainbow Bridge link and call interface).

Existing methods

This blog from OpenZepplin is the most comprehensive and latest article about the scalability method of Ethereum. For more information, you can also check the Consensys blog.

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

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

In short, the following methods are widely used:

1. Registration form . A special “registry” contract can track all versions of the contract. The user/contract should obtain the address of the latest version of the contract from the registry before interacting with the contract.

  • Advantages: simple, easy to audit, can work with multiple versions
  • Disadvantages: data migration is not clear, and additional calls are needed to query the actual contract used

2. Parameters/strategy configuration/specific functions . The contract has a method to update parameters or address links, and such addresses will execute some fragments of the logic.

  • Advantages: It can be fine-tuned, and the unchangeable feature of the main contract code brings additional security to users.
  • Disadvantages: Vulnerabilities in the main contract cannot be fixed, highly dependent on usage scenarios, and no standard tested code

3. Agency. A special agency contract is only responsible for entrusting code calls to the execution contract.

  • Advantages: address is static, data and execution are isolated
  • Disadvantages: The design is complicated, and many problems may occur due to some specific conditions of the EVM (function screening conflicts, storage conflicts)

4. Variable contracts (metamorphic contracts). The contract is deployed using the CREATE2 opcode and can be upgraded after using the selfdestruct opcode

  • Advantages: no proxy required
  • Disadvantages: The state of the contract is deleted during the upgrade process, and the upgrade cannot be initiated within a single transaction, which will cause the contract to be downtime

Governance

In addition to scalability, there are many different ways to upgrade governance:

1. Single key/externally owned account . A single key can upgrade the contract

  • Advantages: fast
  • Disadvantages: centralized, there is a single point of failure

2. Multi-signature . M must have N in the secret key to sign the upgrade

  • Advantages: Very fast when the number of participants is not large, and there is no single point of failure
  • Disadvantages: It is still a PoA model; additional trust entities need to be introduced into the {Ethereumconsensus, NEAR consensus} set.

3. Time lock . The owner of the contract (contract or a single secret key) can plan an upgrade. It usually takes 1 to 7 days from the start of the planned transaction to the completion.

  • Advantages: If the user does not agree to the upgrade, there is enough time to suspend the service
  • Disadvantages: unable to upgrade quickly, hackers can analyze the code and crack the current version during the planning period

4. Suspendability (with escape cabin). The contract can execute a method to suspend all operations. In the suspended mode, any operation on the contract is not allowed, or the user can also suspend the service.

  • Advantages: There is an escape cabin, which provides a solution for the safety upgrade of the time lock
  • Disadvantages: Pause is essentially centralized, so it should be limited in time

5. “Submit-Show” upgrade . The security upgrade proposal (in the form of a hash) is submitted to the contract, and the code is shown to a trusted security expert. After approval, the upgrade will be displayed and applied at the same time.

  • Advantages: Provides a solution to the security upgrade problem of time locks, reducing the risk of hackers developing vulnerabilities in reverse order
  • Disadvantages: almost no difference from multi-signature governance

6. DAO/total voting . The contract is governed by a vote of stakeholders. In the NEAR platform, we refer to the verification node voting.

  • Advantages: Completely decentralized. If there is a problem with voting, this means that there will also be problems with the NEAR protocol layer. At this time, the Rainbow Bridge will be a secondary problem.
  • Disadvantages: The speed may be slower, how to apply security patches is still unclear, and the scope of responsibility of the verification node will be expanded. The voting decision should also be sent to the Ethereum contract. If the Rainbow Bridge stops running, the above operations may cause problems.

Current transaction status

Note: Regarding the upgradeability of NEAR blockchain smart contracts, there is currently no fully definitive guidance plan. The most notable is this proposal. All methods from Ethereum can also be used.

Proposal: https://github.com/near/NEPs/pull/123 The current upgradeability of Rainbow Bridge is realized in the following way:

1. Ethereum

  • The core contracts are currently not upgradeable, but they have passed security audits. The core Rainbow Bridge upgrade is run by releasing a new Rainbow Bridge instance, so that the connector needs to change the address to verify the completion of the transaction
  • The homogenized token connector has a special function that allows the token to be transferred to a new deployment environment
  • The governance model uses a single key

2. NEAR

  • The core contract has passed the security audit, but has a complete access key. We can deploy a new version of the contract in the same account so that the connector does not need to change the proof address.
  • The homogenized token connector also has a complete access key, which can be updated without changing the address.

Upgradability concept

  • The number of vulnerabilities in the code peaked at the beginning of Rainbow Bridge’s operation, and then gradually decreased
  • The Rainbow Bridge test range will gradually expand
  • There will be more and more upgrade tests, and the consideration will become more and more important.
  • The user base of the product will gradually increase
  • The locked value in Rainbow Bridge will gradually increase (the cost of errors will also increase)

General considerations

Taking into account the assumptions and common practices, we suggest a phased approach to the upgradeability of the Rainbow Bridge contract: there will be a simple upgradeability model in the early stage, the governance model will be more centralized, and then it will develop into a more It is a decentralized method.

Phase 1: Centralized governance, no fixed interface

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

* The purpose of this is to avoid bridging/locking tokens from migrating, while allowing users to withdraw tokens. The method is very simple, allows rapid iteration, and can quickly respond to major leaks by storing the token in a safe place. Important: In the future, all DApps integrated with Rainbow Bridge (either at the contract level or outside the blockchain) should be able to update the integration code, including the contract address and interface.

Phase 2: Independent multi-signature governance, agency model

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

A group of experienced safety engineers and several companies formed the Rainbow Bridge Governance Committee. These entities hold the secret keys for the multi-signature contract of the two chains. The core Rainbow Bridge contract and the Ethereum connector implement the proxy model, but the actual interface of the contract may change in the future. We have ruled out the risk of a single point of failure, but the price is that the system’s response speed to vulnerabilities will be reduced. In general, this method allows Rainbow Bridge to have a stronger risk tolerance. Important: In the future, all DApps integrated with Rainbow Bridge (either at the contract level or outside the blockchain) should be able to update the integration code, although the contract address will not be changed.

Stage 3: Independent multi-signature governance, with functions/features such as agency mode during freezing period, suspendability, escape cabin and fixed interface

NEAR发布以太坊彩虹桥升级和治理方案,通过 4 个阶段逐渐去中心化 At this stage, the governance model will be changed, but the upgradeability model will not be changed. By allowing users to suspend the system at any time, we are increasing the predictability of Rainbow Bridge and making it more user-friendly. We use the freeze period to deal with vulnerabilities. Multi-signature contracts cannot permanently stop the execution of Rainbow Bridge. In addition, at this stage, each interface is roughly fixed, which means that it is not necessary to upgrade the integration of Rainbow Bridge and the Rainbow Bridge itself at the same time. Important: Users who use Rainbow Bridge need to pay attention to the update of Rainbow Bridge at this stage. In the event of capital risk and the development team cannot fix the problem in time, we will ask users to use the escape cabin service to withdraw funds from the Rainbow Bridge. Once the suspension period is over, the funds still deposited in Rainbow Bridge will be at risk.

Phase 4: Verification node DAO, proxy mode, with functions/features such as freezing period, suspending, escape cabin, fixed interface, etc.

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

In this phase, we will transition to a completely decentralized and permissionless governance model, which is consistent with NEAR’s consensus mechanism. The entity that can update the Rainbow Bridge and the connector is a verification node DAO. 2/3+1 pledge is required to complete the upgrade. However, for more serious vulnerabilities, we still retain the security team responsible for this matter. The team will be able to suspend the operation of the Rainbow Bridge and the connector, and notify the verification node of the vulnerability. This method ensures that Rainbow Bridge users can receive the best security protection. Note: In order to update the Ethereum contract, NEAR validators should vote on the NEAR chain, after which the system will use a new custom connector to bridge their decisions to Ethereum.

Phase transition roadmap

The transition between phases should be agreed by the community, and is likely to depend on the experience of using Rainbow Bridge: user activity, total lock value, bug bounty items, frequency of major bugs, etc. It is difficult to predict when the transition between phases will occur. The Rainbow Bridge development team is committed to developing code that can execute upgradeability and governance models, but we will give the community the power to decide on the transition indicators, which is similar to the community’s decision on the second phase of the mainnet transition. According to our vision of Rainbow Bridge, we believe that the transition to the fourth stage is our ultimate goal. The process leading to this stage needs to ensure the safety of Rainbow Bridge users.

Concluding remarks

Although the proposed upgradeability and governance plan looks a bit complicated, in fact, the plan implements a simple idea: only add a small part of the final functionality at a time.

  • In the second phase, operations such as multi-signature contracts and agency models were launched
  • In the third stage, functions such as freezing period, tentativeness and escape cabin are introduced
  • Decentralized governance launched in the fourth phase

During these migrations, almost no code was deleted (except for the multi-signature governance of Ethereum contracts in the fourth phase). The order of function release corresponds to the increase in the ratio of their complexity to value.