Dev Exploration: An Analysis Of ‘Traditional’ Cross-chain Asset Bridges Using Testnet Examples
[DISCLAIMER]: The following analysis uses testnet examples from various protocols using different contract implementations. This analysis does not approximate mainnet conditions using real assets. This blog post was sparked by curiosity and used exclusively as a simple investigation.
Benchmarking traditional asset bridge performance
I’ve been playing around a lot lately with cross-chain bridging examples. Working on the Sygma interoperability team as a devRel kinda necessitates deeper understanding of the cross-chain ecosystem and the protocols that dot the landscape. To start, I really wanted to understand what each protocol offers in performance from a competitive standpoint, not in the least of which how and where Sygma stands up to other offerings.
For the following exercise, I wanted to test out traditional asset bridging examples (tokens that are locked/released or burnt/mint, either in an escrow smart contract or some other). Two specific questions I wanted fairly simple and naive answers for:
- How much gas would it cost?
- How long would it take?
The exercise also needed to use the same source-to-destination route to get a relatively apples-to-apples comparison, especially since some chains finalize faster than others.
I compared performance between a few protocols that have working examples from their GitHub repos or docs (links inline):
[Disclaimer] Some of the mechanisms tested use pure (sic escrow) token bridges. Escrow token bridges may not necessarily be the only standard for bridging anymore. Nowadays, bridging protocols lean towards more flexible generic message passing (GMP) networks or “intent”-based solver networks, neither of which require locking (and thereby risking) ERC-20 assets in a smart contract. However, for the purposes of science and benchmarking performance, it was still worth it to do a side-by-side comparison of each protocol.
Ready? Here’s what I found:
Performance matrix
Bridges must model security
It’s important to understand that blockchain “bridges” function essentially as offchain oracles. Their primary role is to monitor events on one chain and relay them to another. A key part of this responsibility involves discerning whether these events are canonical — that is, representing the true state of affairs on the source chain — and determining the trustworthiness of these onchain computations. As such, the “performance” of a bridge is not merely a matter of speed or cost efficiency; it is intertwined with the bridge’s security model and how it establishes criteria for accepting or rejecting the results of onchain computation from any chain.
Crucially, in the current multi-party computation (MPC) setup, protocol Sygma is configured to wait for 20 block confirmations on Ethereum mainnet and testnet before processing cross-chain transactions. This block delay is to account for the possibility of reorg attacks. And to settle on this number, Sygma looked at the largest block reorg in Ethereum history and added a multiplier for safety. Other small factors may contribute to the delay, including 1) RPC delay or 2) in the case where the selected “coordinating relayer” on the Sygma MPC network temporarily goes down. But all of these account for < 30 seconds of impact. These factors combine to give Sygma a ~3 minute turnaround time on asset bridging, and as you can see from the above matrix, is highly competitive with other bridge offerings.
Ofcourse, as I’ve alluded earlier, pace of cross-chain transact is not necessarily indicative of “better”. Every bridge models its security differently, so it is important to consider the parameters and levers a protocol might adjust, or layers of security a protocol might add on top of, which may lead to longer or shorter cross-chain transact. For example, Chainlink implements three decentralized oracle networks (“DONs”), one for each cross-chain action–1) committing source Merkle proofs, 2) blessing/cursing said proofs, and 3) executing on the destination chain– while conjunctively awaiting Ethereum block finality. Axelar uses a similar approach with Ethereum block finality plus additional security logic layered on top via quadratic voting by their validator (sic relayer) network.
Don’t trust, verify
Indeed, this was a fruitful exercise to gleam insights from. And as the ancient wisdom says: don’t trust [my word], verify [for yourself]! All of the examples were relatively easy to implement and run — so you should try them out yourself! Ofcourse, I am biased towards Sygma and how quickly you can get set up to test your own Sepolia ➡️ Mumbai cross-chain token transfer :) Give it a shot when you get a chance!
If you’ve got any questions about running any of the examples, I’d be more than happy to help out. You can reach out here or via Twitter @haochizzle.
Up next, general message passing…
Appendix
Sygma source hash: Tx hash; Dest hash: Tx hash
CCIP source hash: Tx hash; Dest hash: Tx hash
