[SPEC] Decentralizing Trust on the Signature Bridge via Light Client-like Functionality (in progress)

[akileshtangella]

Overview

How Things Work Currently

Let us take the anchor update proposal, as an example. Say we have a signature bridge with two chains, chain 1 and chain 2. When anchor 1 wants to update its information about the root of anchor 2, the following process occurs:

• An element is inserted into the Merkle tree on anchor 2, which in turn updates its Merkle root
• Relayers monitoring the blockchain create an anchor update proposal and submit it to the DKG for signing
• If the number of relayers that submit the proposal for signing is greater than a certain threshold, the proposal is signed by the DKG and submitted to chain 1's signature bridge for verification
• If the signature verifies on chain 1's signature bridge, anchor 1's edge to anchor 2 is updated

What Needs to Improve and High Level Overview of How We Will Do It

Currently, we need to trust the relayers to propose valid anchor Merkle roots for updating. They can collude and propose invalid Merkle roots, which can cause the anchors to update to roots that contain malicious inserts. This can allow people to withdraw moneys that they never deposited. Instead, it would be nice if we can verify that anchor 2's Merkle root is actually what the relayers are saying it is. We can do this by storing chain 2's block hashes on-chain (somewhere in the DKG system, for example). Relayers then create Merkle proofs against this block hash about anchor 2's state. If this proof successfully verifies on-chain (in the DKG system), then an anchor update proposal is formed, signed, and submitted to anchor 1.

The question then is, how do we get the block hashes on-chain? We can do this via a vote amongst relayers in the DKG system. One way to think of it is: relayers now act as oracles over block hashes instead of Merkle roots.

Implementation/Code Details

Proposing and Voting on Block Hashes

2. Store block hashes for each chain type (i.e. Ethereum, Polkadot, etc.) on the DKG parachain.
3. The data structure for storing block hashes will be double mapping from chain_type to block_number to block_hash. Store a bounded number of block hashes, say 10,000 block hashes and keep wrapping around (using modulo function).
4. Relayers propose and vote using the [check which pallet] pallet

One thing to note: after anchors are already linked it is possible to update the root information about one anchor on another anchor. But how do we link them in the first place. Basically:

1. Initially anchor 1 and anchor 2 are detached, and inserts happen independently on them.
2. We utilize the force_submit_unsigned_proposal functionality to propose that two anchors be linked to each other [include more details...which proposal is used...etc.]

Another question is: once anchors are linked how do we propagate a Merkle root update across all the edges?

1. We have a bridge registry on the [check which pallet] pallet. This bridge has two mappings. [ask Drew where this registry is located again].
2. Move bridge registry to DKG.

Creating Proofs Against Block Hashes

Anyone can construct proofs and submit them to the DKG parachain for verification. Need to construct a proof about blockchain state (i.e. the Merkle root of the anchor) against a block hash. On Ethereum, this can be done using the eth_getProof RPC call. On Polkadot, this can be done via getReadProof, see https://polkadot.js.org/docs/substrate/rpc/.

Verifying Proofs On-Chain

The proof is a Merkle proof for the particular data structure that stores blockchain state (a Merkle tree, Merkle trie, etc.). For Polkadot, can use https://substrate.stackexchange.com/questions/1889/verify-storage-entry-with-getreadproof. For Ethereum, one thing to note is that the proof must be verified in a Rust-based system...so might need to write the verification algorithm from scratch, in-house.

Forming and Signing Proposals

Let's again take the anchor update proposal, as an example. Once an anchor's Merkle root is verified against the block hash, we need to actually form the anchor_update_proposals and the DKG needs to sign them. In general, a proposal looks like: [check the code]

Other Details

Proving State about L2s

new chain id for l2s

Dealing with Blockchains Forking and/or Immediate Blocks Not Being Final

How do we consider something finalized...not yet for against very new stuff