Motivation
See
Thoughts
If we can get a ZK-friendly subset of chain state (e.g. a market? a new sector storage structure?) then we can verify state proofs in another chain with SNARK.
Verifying consensus of another chain will be slow – need to wait for finality on that chain.
References
We build zero-knowledge and multi-party computations systems to enable new cross-chain blockchain use cases
Big focus on privacy
The best design for blockchain interoperability, assuming two chains with different validator sets, is to have an on-chain light client for a source chain running on the target chain (which is what IBC does). With this design, there are no additional trust assumptions placed on cross-chain communication, aside from trusting the economic security of the consensus of each participating chain.
→ Potential collabs
- General purpose interop
- Looks oracle-based
- Critique from L2Beat
Vitalik chain interop, 2016. https://allquantor.at/blockchainbib/pdf/buterin2016chain.pdf
Algorand state proofs: consensus nodes attest to state root. https://developer.algorand.org/docs/get-details/stateproofs/
More academic (formally secure) and privacy focused approaches exist based on MPC, which allow private cross-chain smart contracts and private cross-chain smart contracts, also confidential token amounts for input/output.
In-house expertise on these as @Tore Frederiksen is a co-author on both.
Idea: faster light client sync via snapshots, allow fast skipping between snapshots. Combine this with fast-finality epochs?
Near Rainbow bridge is “trustless”, validates headers on Eth/NEAR in smart contract.
- https://github.com/aurora-is-near/rainbow-bridge/tree/master/contracts
- (Older): , https://github.com/near/rainbow-bridge-sol/blob/master/nearbridge/contracts/NearBridge.sol,
- Relies on a challenge mechanism, e.g. https://decrypt.co/108015/nears-rainbow-bridge-blocks-another-attack-costing-hackers-5-ethereum
Light clients
Finality gadgets