Skip to content
This repository has been archived by the owner on Apr 11, 2024. It is now read-only.

Latest commit

 

History

History
99 lines (64 loc) · 9.31 KB

REP-0002.md

File metadata and controls

99 lines (64 loc) · 9.31 KB
Raw

REP-0002: Move Bridge into a standalone application

Preamble

REP-0002
Title: Move Bridge into a standalone application
Author: Ronin Core Team
Type: Standards Track
Status: Executed
Created: 2023-06-19

Abstract

REP-0002 describes the process of moving the bridge into a standalone application on Ronin. This will allow the bridge to be operated by its own set of operators, instead of requiring validators to run it. It is the initial step towards building a sustainable business model for bridge operators.

Rationale

Currently, validators on Ronin are obligated to operate a bridge operator node, which leads to a close integration between the smart contract code of the bridge and the consensus code responsible for maintaining the validators and their delegators. This architectural approach introduces unnecessary complexities. Despite the significant efforts invested in securing the current design, the tight coupling of these components severely limits the ability to implement enhancements or introduce new features. Without a change in approach, Ronin risks falling behind other blockchain systems. Therefore, in order to facilitate future improvements for Ronin, it is essential to decouple the bridge from the consensus, effectively transforming it into a standalone application.

Specification

With this upgrade, the bridge will have its own set of operators, and the validators are no longer required to run bridge operator nodes. As a result, nodes do not need to relay the set of bridge operators on the Ethereum chain every day. Plus, unavailability bridge operator slash is modified, and relaying slash is removed.

Bridge operator selection

The initial set of bridge operators will be approved (on-chain) by the governing validators. After that, operators can be added/removed by a proposal that is approved by at least 70% of the operators.

We are considering the following methods to choose the initial set of the bridge.

  • Select 22 bridge operators based on a snapshot the current validators 2 weeks before the hardfork.
  • Select 22 bridge operators, including 12 governing validators, the remaining 10 will be selected based on the vote of governing validators vote. The voting list includes standard validators and validator candidates.

Bridge governance

All bridge operators will have the same power (there are no differences between governing validators and the remaining). Any operator can create a proposal to add a new operator, remove an old operator, or pause the bridge. A proposal is executed if it gets approved by 70% of operators.

Rewards

Currently, the rewards for bridge operators are funded by RON allocation rewards.

  • We allocated 1,000,000 RON for bridge operator reward in the first year.
  • The rewards are automatically given to the bridge operators at the end of each period.
    • In each period, each bridge operator will be given a reward that is proportional to the number of votes in the period. After this period, we will need to find other sources of rewards for the bridge operators. We are planning to introduce other types of rewards with the goal that the operators are profitable without receiving the fund from RON allocation rewards. See the Economic section for more details.

Slashing

Similar to the current design, the unavailability bridge operators are slashed.

  • There are two tiers for slashing.
    • Tier 1: If a bridge operator misses more than 10% votes in a day, the operator is penalized for 1 day, i.e., it doesn't earn the bridge reward on that day.
    • Tier 2: If a bridge operator misses more than 30% votes in a day, the operator is penalized for 5 days, i.e., it doesn't earn the bridge reward for the next 5 days.
  • If a penalized bridge is slashed, the penalty will be stacked.
    • For example, if an operator gets tier 2 slashed on day 1, it will be penalized until day 5. Then, if the operator gets tier 1 slashed on day 2, it will be penalized until day 6. Finally, if the operator gets tier 2 slashed on day 4, it will be penalized until day 11.
  • If an operator gets penalized for 20 days (e.g., at day 100, it is penalized until day 120), it will be removed from the operator set.

Implementation plan

Once the REP is approved, we anticipate a timeframe of 4-6 weeks for the implementation and thorough testing of the REP.

Security analysis

By moving the bridge to a standalone application, the consensus code of Ronin is significantly simplified. This simplification can save time and effort for future updates on Ronin. Moreover, it effectively minimizes the potential for introducing unforeseen security vulnerabilities, reinforcing the overall robustness of the system.

Allowing new developments/improvements on Ronin consensus and bridge

The integration of the smart contract code of the bridge with the consensus significantly increases the size of the contract. Consequently, some contracts in the current design of Ronin approach the 24KB limit of smart contracts. For example, the RoninGatewayV2 contract, which manages the bridge, is over 20KB in size, and the RoninValidatorSet contract, which manages the set of validators, is over 23KB. Decoupling the bridge and the consensus would effectively reduce the contract size, preventing it from reaching the limit when making further improvements.

Improving security by modular design

Improvements made to either the bridge or the consensus have the potential to introduce unanticipated security vulnerabilities for the other components. Decoupling these two components allows for a more modular approach to the design of Ronin, thereby improving security by design. This modular framework allows for individual improvements in each component while minimizing the risk of unintended consequences on the overall system's security.

In line with this approach, we have two independent roadmaps for the validators and the operators.

  • Validators will be responsible for upholding network performance and security.

    • We plan to introduce a fast finality method, reducing the confirmation time (i.e., the period between when a transaction is submitted to the network and when it becomes irreversible) from ~45s to ~6s. This will help to improve the user experience and make Ronin more competitive in the market.

  • Operators will focus on delivering various services on Ronin, including operating the bridge.

    • In the roadmap, we plan to introduce the following services:
      • NFT bridge, allowing users to transfer NFTs between Ronin and Ethereum.
      • On-chain random number generator.
      • Price oracle.

    By providing these services, we can greatly improve the ecosystem of Ronin, thus attracting more dApps (especially web3 games).

    • We also looking to create a sustainable business model for bridge operators. At present, operators solely rely on the Ronin allocation rewards, which are limited to 1,000,000 RON for the first year. Once this period ends, we need to find other sources of rewards for operators. Otherwise, operators will cease to receive rewards, thus losing the incentive to continue running the operator nodes. In the future, this REP opens up the possibility for us to address this challenge. We can consider various solutions for sustainable sources of rewards for operators, including but not limited to:
      • Expanding the range of services offered by introducing additional features (as we mentioned above). These services have the potential to generate more profits for the operators.
      • Implementing transaction fees for bridge transactions, e.g., users will be required to pay a transaction fee equal to 0.1% of the transfer amount.

However, as previously mentioned, the current design, which couples the bridge with the consensus mechanism, is impeding the introduction of these new features.

Defending against stopping attacks

To execute a bridge transaction, a minimum approval of 70% (16) of the bridge operators is required. In other words, the transaction will only proceed if at least 16 out of 22 operators agree to it. a potential issue arises when a single organization controls at least 30% (7) of the bridge operators, granting them the power to obstruct any transaction from being executed. If the organization chooses to do so, they only risk losing rewards for that period.

In the new design, we introduce a new logic that identifies and removes bridge operators who consistently fail to participate in voting. By taking this step, operators who deliberately attempt to stop transaction execution are at risk of being removed from the operator set. This proactive approach aims to ensure that the bridge is operated by trustworthy individuals who are genuinely committed to executing transactions in good faith.

For a more catastrophic attack, where the attacker attempts to steal tokens from users, they must control at least 70% (16) of the bridge operators. Specifically, the attacker needs to control at least 6 governing validators, since 12 out of the 22 bridge operators are governing validators. However, given the reputable standing and incentivized nature of these governing validators, such an attack would be virtually impossible to execute.

License

The content is licensed under CC0.