Creating Cross-chain bridges with Verifiable data streams
Cross-chain bridges
Cross-chain bridges act as data and transaction connections across multiple chains. They have applications across blockchain, but they are primarily used in decentralized finance applications to enable liquidity from multiple chains to be pooled together into one protocol. Examples of a cross-chain bridge would be locking token contracts where smart contracts on two chains are connected, where tokens can be transferred between chains in a wrapped format.
Drawbacks
Bridges and oracles suffer from several drawbacks:
- Smart contract and DApp specific: bridges must be built using custom-made smart contracts to account for the specific use-case and to accommodate the specific chain whose data is being used.
- Data cannot be readily verified, and must be updated through some type of consensus that cannot be deterministically disputed
- Need to relay the information from one chain to another
Generalizing the approach for cross-chain bridges
In order to solve the problem of cross-chain bridges, it is necessary to solve the “oracle problem”, being able to push data into the chain and rely on its authenticity. Once the data can be verified and disputed on-chain, it is possible to use these data updates as you would any other events or data in the blockchain. This example uses the data from the block headers of Ethereum, on another chain:
- You would have a “data layer”, push data into chain, and then use to have some updates on the smart contract. Change liquidity/burn
- Or you have a view of data that can be referenced by other transactions. Block Headers
Solving verification through Authenticated streams and views
It is possible to solve the oracle data problem by storing streams and materialized views in a Merklized database, and verifying the portions of data using the Merkle path. Data is pushed to generalized snapshot contracts, but it must be verified through unique fraud proof checks, that must be deterministic, and composed of a series of operations, this is shown later in the example section.
In the authenticated stream model, data from the blockchain is pushed into a Merklized database, and from there, snapshots can be submitted by relayers to a contract that stores the Merkle root of the current. Snapshots can be pushed through a layer 2 consensus or they can be updated through a centralized relayer, and DApps can use this data by verifying the hash and Merkle root of the snapshot. The snapshot is publicly available on the blockchain so any user can push transactions with data, without any consensus or trust.
This system does enable snapshots to be inaccurate or false, which is why there must be a dispute system where users can submit fraud proofs to the snapshot contract to dispute the updates that are being made. These fraud proofs can be submitted by a node, and can be deterministically using the consensus of the blockchain using the data.
Authenticated Stream of blocks from Ethereum
Updating snapshots
The snapshot contract can be described as a current snapshot root, and a map of snapshot numbers, here represented by block numbers, and snapshot roots.
- Current Snapshot root
- Current snapshot number
- Map of block numbers to snapshot root
In this example, a Block gets produced to stream and pushed to the Merklized database. At a block divisible by x, a new snapshot is pushed into the contract by a relayer which can be either centralized or based on a consensus. Once the snapshot is published, it is possible for users to submit fraud proofs in order to show an incorrect state transition between the roots.
Block Fraud Proof
- Block i + proof
- Block i-1 + proof
The first step is to check the block numbers and block hashes correspond to the blocks. The second step is to check if both blocks are in the snapshot. It can fail if: parent Hash of Block number i does not exist parent Hash of block number i does not have block number i -1.
Using blockchain data
- Blockchain Data: (Data bytes, Merkle Proof)
- Tx Inputs
Now that the snapshot root is published, it can be used in interactions with smart contracts. A user can submit the block header as data in a transaction that uses this data. The smart contract can use this data (either through schema or a string), and verify it by taking a hash of the bytes and checking the Merkle Proof.
One of the potential needs for the smart contract using the data, is a schema that can be used to convert the bytes into a block header data object.
Future Considerations and Bottlenecks
Of course there do exist some considerations for this method of data access. One of the drawbacks of this system is the time that it takes to update the snapshot. Data cannot be used in real-time, since each snapshot must be updated and verified. One fix for this would be to update snapshots every block in order to decrease the time between data updates. Another drawback is that before the data can be used additional time must be spent to open collect potential fraud proofs of the updated data. This can be fixed by including an audit root along with a snapshot root, and leave audit verification to the client.
One of the potential considerations for this system is how it will be impacted through MEV and miner attacks. Since these streams of data can be used by many different applications, it is possible to delay updates for a large quantity of applications, to use data from previous snapshots. This issue can be remediated by using encrypted transactions to reduce the likelihood of censorship from either the relayers or the miners.
