xDai Stable Chain xDai Stable Chain BlockScout BlockScout TokenBridge TokenBridge

Ethereum to Binance Chain bridge

This description assumes that a new ERC20-to-BEP2 bridge will work similarly to the existing token bridge: the bridge validators nodes are running with the token bridge oracle, the oracles listens one of the chains (one side of the bridge) to watch the bridge related events, performs actions to approve relay requests in from of collecting signatures from the validators and sends confirmations of approval to another side of the bridge.

Related links:

Security

Operations security will be provided by different schemes on different sides of the bridge.

EVM-based chain side:

  • there is a token bridge contract
  • the contract receives requests from the user to relay assets (tokens) to the Binance Chain, the corresponding amount of tokens is locked on the contract
  • the contract allows to limit bridge operations: minimum/maximum amount of tokens per one transaction and maximum amount of tokens per day
  • the contract provides a permanent address for the bridge operations
  • the contract manages the list of validators, a validator can be added or removed from the list
  • the contract collect confirmation calls from the the bridge validators, checks if enough confirmations collected and released the tokens
  • it is possible to collect fees for the bridging operations and distribute them among the bridge validators

Binance Chain side

  • Threshold Signature Scheme is used by the token bridge validator nodes to prepare the signature for a transaction to unlock corresponding amount of tokens on the Binance Chain
  • TSS supports the mode when M of N validators is enough to generate proper signature
  • the validator nodes need to have p2p connection to communicate the signature computation by using multi party computation scheme
  • Hypothesis: a sidechain could be used for the validator nodes communication instead of direct p2p connection, a contract in this chain could also manage the order of computations to get the signature and assign a particular validator to send the eventual transaction
  • if the validator set is changed it requires to re-initialize the secret on every validator, it causes the change of the bridge account address since as per nature of TSS the new validator set will represent new account
  • this is still a open question still how to preserve the bridge account address to simplify user experience
  • one transaction to the Binance Chain could contain several outputs, so it could allow to combine several request to relay tokens in one transaction (mutlisend) as well as distribute the fee for the bridge operations among the validators

Note 1: TSS can be used on the EVM-based side also to commit validators approval.

Note 2: The approach described for the Binance Chain could be used with the Libra blockchain. They use ed25519 Edwards Digital Signature Algorithm so the corresponding implementation of TSS can be used.

Example of user operations

An EVM-based chain to Binance Chain

  1. Alice calls approve method for an ERC20 token linked with the bridge. The bridge contract address is pointed out as the spender.
  2. Alice calls a method (e.g. requestAffirmation) from the bridge contract. The arguments of this method: value and recipient. The method transfer value of associated tokens to itself and emits an event for the token bridge oracle. Step 1 and Step 2 can be combined if an ERC677 token is used. As result, the tokens are locked on the bridge account.
  3. Every bridge validator node catches the event and initiate TSS to sign the relay request. The signed message contain value and recipient. Where recipient is the address of tokens recipient in the Binance Chain.
  4. As soon as the signature generated, one of the validators sends a transaction to the Binance Chain. The transaction is to send value amount of tokens (if there is no fees for the bridge operations) from the account owned by the bridge validators. It means that tokens are unlocked.

Binance Chain to an EVM-based chain

  1. Alice transfers tokens to the bridge account. The field memo is used to specify the address of the recipient on the EVM based chain. The tokens are locked on the bridge account. The open question here is what the bridge should do if memo is empty or does not contain a proper ethereum account.
  2. The bridge validators nodes are subscribed to the Bincance Chain RPC nodes to catch the transfer. As soon as the request is caught the validators send confirmation to the bridge contract on the EVM-based chain. The confirmation contains the amount of transferred tokens and recipient of the tokens.
  3. As soon as enough confirmation is gathered, the bridge contract transfer the corresponding amount of the tokens to the recipient. This operation unlocks the tokens.

TSS orchestration

As it was described above a sidechain could be used to manage operations related to TSS. This chain could be the same chain where the token bridge is pegged if the transaction rate and transactions fees are OK.

Advantages of usage a TSS-orchestration contract on the sidechain are:

  1. Only approved validators could participate in the TSS re-initialization
  2. TSS requires orchestration to define the order of computations made by validator, the contract could perform this in decentralized manner.
  3. The contract could manage epochs when the corresponding set of validators is enabled. The validators of the epoch X-1 could vote for the set of validators of the epoch X. As soon as the TSS is re-initialized validators of the epoch X-1 sends a signed transaction to pass all locked funds to new account corresponding to the validators of epoch X.
  4. The contract could be used to synchronize validator set in the EVM based chain the token bridge is pegged. As soon as new epoch is applied a event with the bridge validators accounts set is distributed by the the old validators to the pegged chain.
10 Likes

Very interesting idea! Can you write a proposal to https://github.com/binance-chain/BEPs?

1 Like

Please refer to https://github.com/binance-chain/BEPs/blob/36b9045f6698641b0c1776f33a47c95407ace585/BEP12.md

1 Like

@HaoyangLiu thanks for the link! Who will develop the pre-defined scripts the BEP is describing? Do you know ETA of this feature in the Binance Chain?

1 Like

I think since the Binance Chain has instantly finality, we don’t need to wait for more blocks.

1 Like

Thanks for clarification! In fact, there I was talking about the confirmations sent by the bridge validators to the bridge contract, not about the block confirmations.

1 Like

Currently Binance Chain is not open source. So, community members can’t directly implement the code for pre-defined scripts. However, community members are free to create BEP(Binance Evolution Proposal).

1 Like

I will create a BEP for the bridge proposal on this week.

I also did some research and found that instead of memo the sender’s public key which is part of the transaction can be used. Similar could be done by the validator picking up the transfer on the Ethereum side by recovering the public key from serialized transaction data and the signature. So, it could bring the following benefits:

  • secure the bridge from the legal point of view (it will not be money transmitter after that);
  • avoid specifying the receiver address on the Ethereum side and the Binance chain side;
  • avoid performing two transactions on the Ethereum side to initiate transfer by the end user.
2 Likes