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.
- Fast Multiparty Threshold ECDSA with Fast Trustless Setup
- Implementing Open-Source TSS to Binance Coin (BNB)
- Two Party signatures JS SDK
- Binance Chain Transaction Encoding Specification
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
- Alice calls
approvemethod for an ERC20 token linked with the bridge. The bridge contract address is pointed out as the spender.
- Alice calls a method (e.g.
requestAffirmation) from the bridge contract. The arguments of this method:
recipient. The method transfer
valueof 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.
- Every bridge validator node catches the event and initiate TSS to sign the relay request. The signed message contain
recipientis the address of tokens recipient in the Binance Chain.
- As soon as the signature generated, one of the validators sends a transaction to the Binance Chain. The transaction is to send
valueamount 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
- Alice transfers tokens to the bridge account. The field
memois 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
memois empty or does not contain a proper ethereum account.
- 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.
- 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.
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:
- Only approved validators could participate in the TSS re-initialization
- TSS requires orchestration to define the order of computations made by validator, the contract could perform this in decentralized manner.
- 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.
- 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.