Telegram Channel
这几天在看 cross chain bridge,顺带简单了解了一下 cosmos 的 IBC(Inter-Blokchain Communication Protocol)。

前文介绍过,跨链桥的作用是跨链转移资产,其根本原理就是在 source chain 质押资产,然后在 target chain 取出新的资产。这一流程最大的挑战,就在于 source 和 target 两个chain 之间无法直接通信,而间接通信的可靠性和可信度都很成问题,使得质押和取款这两个操作很难具有原子性。

IBC 的解决办法很直观,甚至说有点简单粗暴。既然间接通信不可靠,那就让它们直接通信好了。通信的方式就是在 target chain 的底层协议中,支持运行 source chain 的 light client。用户在 source chain 完成资产质押后,将质押交易和 block header 通过 Relayers 转发给 target chain,target chain 通过 light client 验证 block header 的真实性,从而确认质押交易的有效性。简而言之,就是将确认第三方链上交易真实性的 Oracle,以轻客户端的方式直接集成进了链的底层协议之中。

注:light client 就是某个链的客户端,但是只下载 block headers,可以验证链的完整性,但是不包含具体的交易信息,相对 full-client 要轻量得多。

注:前文提到的这个 Relayers 仅负责监听和转发,不需要信任它,所以 IBC 是不需要引入可信第三方(Trusted Third Party)的。

这样做一个问题是,如果你想要和尽可能多的链桥接,那么你的协议中就得同步运行很多的轻客户端,这会使得协议的复杂度和资源消耗都大大增加。为了缓解这个问题,cosmos 提供了一个集成了很多轻客户端的中转链 cosmos hub。你可以将自己的链桥接到 cosmos hub,然后再从 cosmos hub 上接入其他链,这样就可以大大减少你自己的链上所需要维护的轻客户端的数量。

这个做法我感觉蛮奇葩的,我觉得仅利用 Oracle 就可以很轻量地实现类似的功能。 #blockchain

refs:
- https://laisky.notion.site/ELI5-What-is-IBC-ea3aa65210c545a6ab63b4ec43d8ee26?pvs=4
- https://laisky.notion.site/IBC-Getting-Started-With-IBC-Understanding-the-Interchain-Stack-and-the-Main-IBC-Implementations-996375ac5fa04dc5a538e1fb238c2ead?pvs=4
 
 
Telegram Channel