FIP9: "trustless" bridge using on-chain light clients

[sirpy]

Currently bridges on Fuse are centralized or require trusted operators that bear the costs. A "trustless" bridge advantages are:

1. enable anyone to create his own bridge and logic based on the initial trusted bridge setup
2. anyone can proove a bridge transfer thus moving the cost to the prover
3. security guarantee of mainnet for ETH->Fuse and POS security for Fuse->ETH

It is now possible to create a trustless ETH->Fuse bridge by storing the latest ETH block header on-chain Then anyone can prove that a storage value or TX exists in the current EVM state. see for example https://github.com/aragon/evm-storage-proofs. The question is always how do you TRUST the current block header that is written on-chain, for ETH it is basically a matter of verifying the proof of work, so anyone can submit a new block header which will be accepted if it passed POW validation. The missing part is to be able to validate POW on-chain you need the ethash function which needs to be pre-compiled and added as an opcode. see https://github.com/lukepark327/ethash-compilable-solc For the beta version it is possible to relax the requirement and start without "ethash" and simply to require 66% of validators to approve the new block header

For the Fuse->ETH bridge it is again the question of how do you trust the current blockheader of fuse that is written on mainnet. The solution again is asking at least 66% of validators to sign the current fuse block header in a specific contract on Fuse + the current set of validators. on mainnet we keep an initial contract with the set of current validators. anyone can submit the current signed block header from fuse to this contract as long as it is signed by >0.66 of the current set of validators. a signed list of the current set of validators can also be submitted in order to update the validators list.

To summarize the following changes are required in order to support a trustless bridge with the security guarantee of the Fuse network

1. extend validator app to sign each X blocks the current fuse block header + list of validators and submit it to a designated contract (0 gas contract?)
2. extend validator app to sign current ETH (mainnet) block header and submit it to a contract

If we want to have ETH->Fuse bridge with the mainnet security guarantee we need to

1. add precompiled ethash contract to parity node each validator is running

[fileflume]

Beyond my scope technically, but the point of this is that anyone on fusenet can make a bridge tx and they pay for it themselves?

“2.anyone can proove a bridge transfer thus moving the cost to the prover“?

---

How to maintain security and stop malicious actors when anyone can make their own bridge?

“1. enable anyone to create his own bridge and logic based on the initial trusted bridge setup"

[fileflume]

So it's possible to create free bridges, and bridges that perform multiple actions? Is the vision that everyone with a fuse wallet has their own bridge so that they always pay their fee (or no fee) ?

How do we secure bridges so that malicious actors don't create ones that send the tokens to their wallet (for example) ?

Is there a way to deploy this on mainnet and reduce eth>Fuse tx fees?

[sirpy]

yes. you can prove to the bridge contract you transfered it a token on the other chain. thus you pay the fee.

anyone can create a bridge but each bridge is separate. meaning each bridge is a set of different smart contracts so there's no security issue here.

yes, you can create any logic you want in your bridge based on a proof that something happened on the other blockchain.

no you would still want to use just one (or not many) token bridges, because otherwise each bridge will control a different token on the sidechain. so you can end up with many tokens representing for example DAI. you want to enjoy the network effect here, but that bridge misbehaves you can always create a competition

well mainnet will always be expensive. but you can make the user perform the transfer operation instead of the bridge operator.

[fileflume]

Thanks @sirpy

[fileflume]

The benefit of this is increased functionality for the network - custom bridges are cool. The downside is increased complexity, the potential for malicious actors to bring Fusenet into disrepute, for exploitations, for multiple spam tokens, duplicates etc.

So, this could be a good addition to a verified community (something needing KYC etc), but maybe not accessible for everyone?

Another 'how decentralised' debate...

[sirpy]

I dont see why it would increase complexity nor malicious actors. Users will still use the same UIs they use, Fuse can keep operating their current bridge or move their bridge to this new tech. Anyone can also create their custom bridge now with the existing technology. My new suggestion doesnt enable anyone to create an "official" bridge. It just enables developers to easily create a trustless bridge customized to their own needs without depending on Fuse inc and without depending on what is currently a centralized single point of failure.