I’m reviving this proposals for the consideration of the assembly.
Short reminder:
The bridge works by validators signing the block headers of both fuse + other evm network
The signed blocks are saved only on fuse (so no gas required from validators)
From the block header you can prove that any TX/storage is valid.
That’s it. On top of that everyone can build an innovate with their own smart contract that acts as a bridge.
How does that work?
Anyone that wants to prove to the custom bridge smart contract that he did something on the “other” network submits the signed block + the tx/storage proof
The smart contracts verify that the signed block was actually signed by enough validators and if so verifies the tx/storage proof and executes its custom logic.
That’s basically it. Another thing that needs to be handled is updating the validators, that can be solved by validators also signing the set of current validators.
This bridge has the same security guarantee as the Fuse consensus.
In the future it is possible to add a new op code so the fuse network can actually validate the proof of work consensus of ethereum and have the same security guarantee of ethereum on validating tx/storage proofs on fuse
read the original proposal.
in any case finality has nothing to do with it. finality is an issue for all Bridges. and it is not 16 hours.
my proposal is for a generic bridge everyone would be able to enforce his own rules and security on top of the basic service
Your original proposal says it’s like Near, the performance stats come from them in the link I provided:
“Sending assets from NEAR back to Ethereum currently takes a maximum of sixteen hours (due to Ethereum finality times) and costs around $60 (due to ETH gas costs and at current ETH price).”
How does your idea overcome the limitations they identify in their product?
They don’t explain how they reached these numbers, but finality means, when can you trust the blockchain state not to change because of a fork. on bitcoin it is assumed that 6 blocks is safe. but it is not a “science”, it is a probabilistic measure, so for example an exchange can decide it only accepts your bitcoin deposit if 8 blocks have passed. So finality is a specific product decision.
The bridge i’m proposing has no preferences, what i’m proposing is that validators simply sign both ethereum and fuse blocks. That’s it. on top of that anyone can build their own smart contracts with their own specific set of rules that act as a bridge.
The problem that a “bridge” solves, is “how do you know that a specific action happened on the other blockchain”
A blockchain header hash, “contains” ALL actions and storage, so now the bridge problem is reduced to “how do you trust a block header” and the answer is that “it was signed by X fuse validators”
The gas fees issue is solved for the VALIDATORS because they only write the signed header to Fuse.
It is the responsibility of the specific bridge/user that wants to use the bridge to make sure block headers are submitted.
so how does such a bridge work
I create a smart contract that checks that a blockheader that is submitted needs to be signed by 90% of the validators (another person can create a smart contract that checks that it was signed only by 66%)
since validators simply sign the blockheaders and write the result to fuse, ANYONE can read the signed blockheader and submit it to any of the above smart contracts. The Validators play NO ROLE here.
now a user wants to prove to a smart contract that he transfered X tokens to some Y address at block numer Z
so the user will send the merkle proof that such a transaction does exists in the blockhash of block number Z.
Because the smart contract wants a finality of 20 blocks, it will only accept the proof if the latest block submited is Z+20. Like explained some other contract might require a finality of only 10 blocks, or even just 1.
I’m assuming all validators have to sign every block mined (such that the required % of validators is reached) therefore this is an additional process each validator does each block.
Are there any gas costs involved with this to the validator (usually aren’t for signing)
What are the potential % savings in gas costs? Fuse > eth would still incur a minting gas fee on eth?
Would the savings be significant on other chains IE fuse <> bsc?
what other applications could be built on top of validator block signing?
How would it be implemented. A fork of open Ethereum client, or stand alone code?
1-2. yes, but it will be part of the consensus contracts that require 0 gas on fuse
3. this bridge is more expensive then a single oracle bridge. But as i’ve detailed before, it is not the validators responsibility anymore to post data to ETH. So it will not cost the validators anything. verifying on ETH that a set of data was signed by the validators can be relatively expensive, 700K gas, so furhter optimization might be required to make it more attractive on ETH. like bulk submitting the past hour blocks. but in any case this is no longer a concern for the validators but for anyone running a bridge.
4. no, this bridge is more expensive in terms of gas.
5. for example we need it for scaling voting on ethereum. our users will vote on Fuse. and anyone will be able to post the signed block + a proof that the proposal passed in this block to ethereum. Our custom bridge contract on ethereum will validate that the block was in did signed and contains the event and will then execute the proposal decision on ethereum.
6. the basics that is required from Fuse is a smart contract + modifying the validators node app
a proof of concept for a smart contract implementing custom bridge over it can also be developed but is not required