Lately I've been talking again about "who to trust in cross-chain," so I did a review: one cross-chain/message passing, frankly, you don't just trust the front end of that bridge. You need to trust the finality of the source chain (no rollbacks), the verification logic of the target chain (how it recognizes your message), the intermediate relay/validators/multisig (who has permission to approve), plus the contract implementation itself (whether it has strange upgrade permissions). The relatively comfortable point about IBC is that it puts the "how to prove what happened on the other chain" into the light client rules, but you're still trusting the consensus + client of both chains, and the relayer is just a courier, not to cheat or delay. Recently, before the main chain's upgrade/hard fork, everyone guesses whether projects will migrate, but I'm actually more concerned about whether issues like message stalling, delays, or replays during the upgrade window will be amplified. Looking at these documents for a long time makes my eyes a bit sore. Anyway, I now prefer to do fewer cross-chain steps rather than save a couple of transaction fees and risk exposing too much trust.

View Original
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Reward
  • Comment
  • Repost
  • Share
Comment
Add a comment
Add a comment
No comments