Two years ago I started this personal project: a bridge between two Ethereum-type blockchain, to send crypto from one chain to one token to the other, and vice versa. One chain could be Ethereum and the other RSK. An Ethereum user could send ethere (Ethereum’s currency) and receive tokens in RSK representing that tokenized cryptocurrency. And when that user in RSK wants to convert that tokenized ether into ether in Ethereum, it could go the reverse way. It could also be that the cryptocurrency to be managed is RBTC (RSK’s) and that in Ethereum, in counterpart, a token is managed that represents it.
In the chain 1 (where the cryptocurrency to be managed resides), there are two smart contracts: the Vault and the Vault Manager. If a user want to transfer crypto from chain 1 to token in chain 2, these are the steps involved:
1- The user send cryptocurrency to the Vault smart contract, to lock it.
2- The Vault smart contract emits an event, and that event is listen by off-chain scripts, named gateways (it could be only one, if you want).
3- The gateway scripts send transaction to a Token Manager smart contract residing into the Chain 2. This smart contract collects the votes of the gateways.
4- If enough gateways votes the release, the Token Manager smart contract mint new tokens that represents the locked cryptocurrency. And it assigns this new amount to the user account in Chain 2.
In this way, the Token Manager acts under the control of a federation of authorized gateways, accepting the release if n of m gateways approved it. Alternatively, it could be only one authorized manager. It depends of the business built around this lock crypt/release token operation. In the case of a federation of gateways, there is code to change the federation members, using the votes of the majority.
The reverse operation:
The steps are:
1- The user in Chain 2 transfer his/her tokens to a special address (ie Token Manager address)
2- The Token smart contracts knows that that address is special, burns the token, and emits an event.
3- The off-chain Gateways scripts listen the event and votes the release on the Vault Manager
4- When enough votes are collected, the Vault Manager instructs the Vault to release the cryptocurrency.
5- The Vault transfer the locked crypto to the user in Chain 1.
As usual, I follow the simplest path. Some decisions:
- The bridge is only for one crypto, one token (not for multiple chains)
- Gateways could be replaces by only one, if the business around the system justifies the centralization
- The token in Chain 2 is a simple token, with mint and burn operations
- The smart contracts ARE NOT upgradable
It’s important to remark: the business around this bridge is the pillar of the system. Gateway scripts run cost machine time and their transactions have associated gas costs.
Simple modifications could allow to have TOKENs at both sides (instead of crypto and token).
Maybe a minimum and a maximum of crypto value and/or token amount to be locked/released could be established.
An special case to be implemented is when the account address of the user in Chain 1 is different of his/her account address in Chain 2 (a common use case when the users use hardware wallets).
Angel “Java” Lopez