[jongjong]

This is because such bridges rely on proofs derived from other blockchains over which validators have no visibility. These add a huge amount of complexity and increase the attack surface. Simpler bridges such as capitalisk-dex https://github.com/Capitalisk/capitalisk-dex (written with only 5K lines of code including dependencies) have a lot smaller attack surface. The principle behind it is to rely on the security of underlying blockchains instead of adding a separate proof mechanism on top; DEX validator nodes have direct visibility over participating blockchains and work directly with on-chain data so they can verify everything directly using each blockchain's native cryptographic clients.

[kirse]

Isn't this the purpose behind tech like State Proofs on the Algorand network, i.e. trustless cross-chain activity is basically solved at this point + deprecates the need for any intermediary trusted bridges:

https://medium.com/algorand/algorand-state-proofs-707d64038e...

https://developer.algorand.org/docs/get-details/stateproofs/

[jongjong]

There is no silver bullet, every approach has benefits and drawbacks.

One of the drawbacks of the Algorand approach is that both participating blockchains involved a swap need to be aware of each other's block signers/validators in order to be able to verify each other's proofs. These validator lists need to be kept up to date on both blockchains and this adds performance costs (since block validators can change over time). A blockchain which serves as a hub for many other blockchains (such as the Algorand mainchain) would have to keep track of the state of validators on many different blockchains. Recurring fees need to be paid in order to keep track of validator lists. This is not suitable for low-volume markets with low fees since trading fees need to be sufficient to cover the ongoing blockchain fees. The Algorand approach is only suitable for certain blockchains where the block validator list is relatively stable and predictable, it's not suitable for a broad range of consensus mechanisms including proof of work.

With Algorand, the proof-generation Algorithm should ideally be baked into the blockchain consensus mechanism (this adds complexity and performance costs/fees to the blockchain). Aside from having the proof algorithm baked into the blockchain's code, the alternative approach is to have a separate federation of 'proof validators' on each chain which are distinct from block validators... This setup has essentially the same security characteristics as a standard multi-chain federated bridge (whose validators have visibility over both participating blockchains) except it has more complexity (risk/attack surface).

The benefit of the Algorand approach (assuming that the proof-generation is baked directly into the blockchain logic) is that it offers the maximum degree of decentralization (which matches that of the underlying blockchains). Though this is at the cost of higher fees. Markets based on it would have to have good volume in order to make it viable.

Finally, in practice, most smart contracts are controlled and can be updated by certain multisig wallets (and their members) so they're really just federations behind the scenes.