BEP-174: Cross Chain Relayer Management

[bnb-tw]

BEP-174: Cross Chain Relayer Management

1. Summary

This BEP introduces a new governance proposal type to manage the set of whitelisted Relayers.
A Relayer whitelist was introduced recently to the BSC genesis contracts (PR-198).
This BEP will improve the management of the relayer whitelist by introducing Relayer Managers, where a Relayer Manager can manage the registration of a single Relayer.
Managers will be elected and ejected via governance.

2. Abstract

This BEP introduces a new governance proposal type to manage Relayer Manager public keys that will be stored in the RelayerHub genesis contract on BSC.

Relayer Managers will be able to manage their individual relayer public key. Only Relayer public keys registered via Managers will be able to invoke the RelayerHub smart contract for cross chain transfers.

3. Status

This BEP is under progress. See bnb-chain/bsc-genesis-contract#205.

4. Motivation

After the BSC Bridge exploitation it is important we introduce some mechanism in place that enhances the security of the system. A governance based set Manager public keys who manage a single Relayer adds an extra layer of security.

5. Specification

5.1 Current Relayer Whitelist

Currently whitelisted relayers are hardcoded in the System genesis smart contract. This list needs to be updated manually by deploying a new version of the smart contract.

5.2 The New Whitelisting Mechanism

After the implementation of this BEP:

• A Relayer Manager role will be introduced with corresponding public keys.
• The set of Managers will be updated via governance using the existing param change proposal mechanism.
• Managers will NOT have to deposit any BNB (as opposed to the previous 100BNB deposit requirement).
• Once selected by governance, Managers will be able to add an associated Relayer public key.
• There will be a 1:1 relationship between Manager public key to active Relayer public key.
• Only associated Relayers can send cross chain messages.
• Managers can modify public key of their Relayer at any time. This will facilitate rotation of Relayer instances.
• The old unregister function will still be active to allow the existing whitelisted relayers to safely exit.

5.3 RelayerHub Smart Contract Changes

Relayer Manager functions

function updateParam(string calldata key, bytes calldata value) external override onlyInit onlyGov

The pre-existing function will be updated to support addManager and removeManager keys to facilitate adding and removing of managers via governance.

function removeManagerByHimself() external

Allows a manager to remove himself if required.

fuction addManagerByGov(address) external onlyGov

Adds a Manager public key to the current set of Managers. This is only called via governance. Emits an event on success.

function updateRelayer(address relayerToBeAdded) public onlyManager

This can be used by the manager to add or remove its relayer. Overwrites Relayer if there is an existing Relayer already added. Emits an event on success. The relayerToBeAdded parameter can be set to 0 address to enable removal of a relayer (e.g. if the private key gets compromised).

function whitelistInit() external 

This is to ensure smooth transition so that the presently existing hardcoded whitelisted relayers continue to be relayers after the hardfork. This function needs to be manually called once after the hardfork.

Relayer functions

function isRelayer(address relayerAddress) external override view returns (bool)

This will be called by the Relayer codebase, instead of registering. Relayer can stop if this returns false

updateParam Changes

  function updateParam(string calldata key, bytes calldata value) external override onlyInit onlyGov{
    if (Memory.compareStrings(key,"addManager")) {
       // TODO check and parse value
       // addManagerAddress(...)
    } else if (Memory.compareStrings(key,"removeManager")) {
       // TODO check and parse value
       // removeManagerAddress(...)
    } else {
      require(false, "unknown param");
    }
    emit paramChange(key, value);
  }

The updateParam function will be modified accept two new keys

• addManager to add a Manager to the stored Manager set.
• removeManager to remove a Manager from the stored Manager set.

Also requiredDeposit and dues will be removed. So no need to account for them in the keys check.

Functions to be Deprecated

These Relayer functions will be deprecated:

function register() external payable ...

unregister() function isn't deprecated to allow existing hardcoded whitelisted relayers to have safe exit.

5.4 Relayer Changes

Update Relayer codebase to no longer register and deposit. Update abi? and run code generation to call new verifyRelayer method on RelayerHub smart contract and proceed to relay cross chain messages on success.

5.5 Existing relayer key migration

Manager keys will need to be supplied for the existing two relayers. Manger set will be seeded with these two Manager public keys. Relayer public keys will be registered to these Managers.

Existing Relayers will need to pull down relayer code once the RelayerHub SC has been upgraded.

5.6 CLI commands

## mainet
./bnbcli params  submit-bscParam-change-proposal  --key "addManager" --value "ADDRESS"   --target 0x0000000000000000000000000000000000001006 --deposit 200000000000:BNB     --voting-period 100   --side-chain-id  bsc  --title "add new super trusty relayer"  --from alice  --trust-node   --chain-id Binance-Chain-Tigris

## testnet
./tbnbcli params  submit-bscParam-change-proposal  --key "addManager" --value "ADDRESS"   --target 0x0000000000000000000000000000000000001006 --deposit 200000000000:BNB     --voting-period 100   --side-chain-id  chapel  --title "add new super trusty relayer"  --from alice  --trust-node   --chain-id Binance-Chain-Ganges

The commands used to create a change proposal to governance.

7. License

The content is licensed under CC0.

[jonesk7734]

😀