# Byzantine Fault Tolerant Cross-Chain Bridges

**URL:** <https://forum.polkadot.network/t/byzantine-fault-tolerant-cross-chain-bridges/2399>\
**Category:** Tech Talk\
**Created:** [March 23, 2023, 11:21am UTC](https://forum.polkadot.network/t/byzantine-fault-tolerant-cross-chain-bridges/2399 "2023-03-23T11:21:25Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![seunlanlege](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/seunlanlege/32/285_2.png) [@seunlanlege](https://forum.polkadot.network/u/seunlanlege)\
**Post date:** [March 23, 2023, 11:21am UTC](https://forum.polkadot.network/t/byzantine-fault-tolerant-cross-chain-bridges/2399/1 "2023-03-23T11:21:25Z")

</div>

In this research article i show that consensus proofs when naively used by on-chain consensus clients leaves them vulnerable to byzatine attacks that are cheap to perform and carry no risks. However by introducing fraud proofs to these consensus clients they can become resilient to byzantine behaviour, enabling the first of it’s kind byzantine fault tolerant cross chain bridges.

> **[Consensus Proofs](https://research.polytope.technology/consensus-proofs)**
>
> In this research article, I explore the technical definition of consensus proofs, review their vulnerabilities, and examine the mitigations for these vulnerabilities. I then show how these mitigations enable consensus proofs to be safely used...

This research can serve as the foundation for any kind of cross-consensus bridge including the DOT \<\> KSM bridge.

---

<div class="post-metadata">

**Author:** ![rphmeier](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/rphmeier/32/126_2.png) [@rphmeier](https://forum.polkadot.network/u/rphmeier)\
**Post date:** [March 24, 2023, 1:30am UTC](https://forum.polkadot.network/t/byzantine-fault-tolerant-cross-chain-bridges/2399/2 "2023-03-24T01:30:05Z")

</div>

An optimistic approach makes sense here, broadly. Although once you have the ability to interpret consensus proofs between chains, an optimistic approach is useful as a time/space optimization, just to avoid eagerly verifying signatures.

I’m wondering about potentially exploring this approach for Ethereum bridging, i.e. since its light client protocol isn’t particularly secure (ref: [Altair is no Light Client - by James Prestwich](https://prestwich.substack.com/p/altair)). It might make sense to just reimplement the entirety of CasperFFG on a parachain and replay all necessary attestations to interpret finality.

---

<div class="post-metadata">

**Author:** ![seunlanlege](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/seunlanlege/32/285_2.png) [@seunlanlege](https://forum.polkadot.network/u/seunlanlege)\
**Post date:** [March 24, 2023, 10:39am UTC](https://forum.polkadot.network/t/byzantine-fault-tolerant-cross-chain-bridges/2399/3 "2023-03-24T10:39:12Z")

</div>

> [@rphmeier](#):
>
> It might make sense to just reimplement the entirety of CasperFFG on a parachain and replay all necessary attestations to interpret finality.

This actually crosses into the territory of my next article on how parachains can scale secure interoperability to all chains.