While we are starting to use more efficient AMB bridges for ERC 20 tokens, there was no secret that the Fuse bridge was struggling to function in the last months.
To solve this, need to pin the reasons for the malfunction:
with more validators in the Fuse network, the fees for relaying between networks increase
gas on the Ethereum is unstable, which is a big instability factor for the relay fees.
validators have no incentive to keep the bridge to function. And every once can join being a validator.
The deployment of FIP8 last week reduced significantly the number of validators, currently from 80 to 30. But taking 1-3 in mind, it’s more like a patch but not a cure for all issues.
We discussed internally a few solutions to reduce the fees ,like using more advanced signatures (Schnorr, BLS) or trying commit-challenge protocol where the signature validation (the expensive computation) is done only when someone’s challenging the relay transaction. These solutions being elaborated bring more complexity to the system and do not solve the validators incentives.
Eventually, we’ve come to the conclusion that the right thing to do is to separate the consensus validators and the bridge validators set. It would mean that:
The bridge validator set would be a closed one that rarely changes. We’ve discovered that having a liquid set is problematic for stability of the bridge. In the future, it is possible to bring a DAO to govern the validator set updates and bridge updates in general.
The validators would earn fees for relaying Fuse token from Fuse network to Ethereum (withdrawal fee). This may not be available on stage one.
Regarding the consensus. Validators would have to relay the minting of new Fuse from Fuse to Ethereum, to keep the supply of Fuse correct. The NewValidatorSet update will not be needed which releases the burden to relay the most expensive transaction.
The plan of action is to deploy this bridge with a constant set of validators by the end of the month. We would be pleased if community members would join (or re-join) as bridge validators, but since the top priority is to have a well functioning bridge to relay Fuse between networks, the economic incentives might be missing at the launch time.
Hi @leonp,
Thanks for the updates and explanation.
My understanding:
All validators are still validators who earn inflation rewards and process txs.
There are 2 additional responsibilities:
a) Being part of the consensus set
b) Being part of the bridge validation set
Consensus set:
All staked validators can be chosen (by the contract) to be in the end of cycle consensus set. They have to pay Eth fees to mint new Fuse tokens on Mainnet. This should be cheaper than previously due to lower nodes, and no ‘NewValidatorSet’ update on mainnet.
Bridge set:
Fixed set of validators, who will have to pay Eth fee when anyone moves Fuse from Fusenet > Mainnet. At sometime a withdraw fee will be implemented, so that validators earn a fee for moving these tokens.
Questions:
Who choses which validator(s) are in the Bridge set?
What is the predicted cost in Eth for each Fusenet > Mainnet tx.
Can one leave or join the Bridge set at any time.
What will be the withdraw fee and when will it be implemented.
I have an idea to replace bridge… why not just have the mainnet sides token contract use its transfer and transfer_from functions to bridge tokens… that way they can be sent mainnet side but still reside on fusenet. even exchanges would still work. user would even pay mainnet transfer fees. This can solve a lot of problems.
token would appear to exist on both chains but would really only exist in fusenet. Effectually you would be able to transfer fuse token on either chain just like you normally do and skip the extra step of having to send back and forth between chains
nonce and chain id will be different on both chains so cant just simply transfer the transaction data directly between networks so might also need fusenet fuse to be erc777 so operators can move fusenet fuse on behalf of the user on fusenet
maybe a bit late for that but could have a token swap to the new fuse token
Yep we are separating one responsibility into two.
Consensus set:
Not exactly, the consensus set should not deal with relaying at all. The bridge set will handle all the relays, including minting. I don’t think they should take fee for the minting relay.
Bridge set:
Correct. They are responsible for relaying both directions, but will take fee only for Fuse -> ETH direction.
Questions:
We choose the validators on start, we’re considering to add a DAO later so the validators have control of adding and removing members. Leaving the set is possible but not automatic as leaving the consensus.
Need to think how much the fees are gonna be, and how the mechanism is going to work. As I said we first plan to launch it functional, then adding features.
Didn’t run the calculations myself but looking into the transaction history of the bridge:
with 6 validators (3 signatures)
gas: 119,464
estimatedPrice: ~2.5$
with 10 validators (5 signatures)
gas: 220,298 gas
estimatedPrice: ~4.5$
with 12 validators( 6 signatures): 318,265 gas
estimatedPrice: ~6.5$
`https://etherscan.io/tx/0x1b97bf48a5bb8257b316260734b8408241384439743ed100bd0d28bb724f22dd
Looking at this I think we aim for number in range of 3-7 validators, while 5 sounds good.
We are also thinking to raise the required signatures from 51% to 66% for the bridge.
why not just have the mainnet sides token contract use its transfer and transfer_from functions to bridge tokens… that way they can be sent mainnet side but still reside on fusenet
If fusenet tokens (including fuse token itself) were erc777 you can have what they call an operator that moves tokens on behalf of the user. If the operator contract on fusenet was notified when mainnet getBalance, transfer and transfer_from functions it would simply be carrying these out on fusenet rather than mainnet (initiated from mainnet contract and carried out on fusenet). So wouldn’t need an actual token on mainnet side at all (the mainnet contract would be a list of functions broadcast to fusenet). You are in effect broadcasting transactions to be carried out on fusenet rather than mainnet and the broadcasting the results back to mainnet.
As far as mainnet is concerned it would see the token as if it were existing on mainnet even though it only exists on fusenet. Think of it like remote commands from mainnet to fusenet. The mainnet contract would simply trigger the actual command on fusenet and relay results between the two.
Does that make more sense?
There would be no tokens on mainnet. No minting, etc. Everything would be on fusenet and the actual bridging would only take place in transfer and balance calls.
