Buidler DAO 一文读懂 IBC：Cosmos 跨链通信协议

Buidler DAO

2022-11-18 18:00:40

Cosmos 被誉为「区块链互联网」，IBC 就是区块链互联网中的「TCP/IP」协议。

分享至

微信掃碼

作者：Buidler DAO

TL；DR

IBC 不仅解决了区块链互操作性问题，而且以信任最小化、安全、可扩展和通用的方式实现了跨区块链进行任意数据传输。「任意数据」包括资产的跨链和信息的跨链，比如代币和 NFT 资产的转移，也可以在使用一条区块链的同时管理另一条链上的账户，还可以从其他链上查询信息，等等。
IBC 协议的独特之处是它采用分层设计，传输层和应用层来实现整个工作流程。传输层 (TAO：transport layer) 提供必要的基础设施来建立安全连接和验证区块链之间的数据包。应用层（application layer）建立在传输层之上，它定义了数据包应该如何被发送链打包、以及如何被接收链解包。
IBC 的安全性是基于 IBC 轻客户端，不需要额外的信任第三方。使用基于源链的轻客户端也意味着其安全性与其区块链底层的安全性假设基本一致。
实现 IBC 的信任最小化的核心「轻客户端」，对于小团队来说这是一项艰巨的开发工作。跨链安全将允许其他区块链从 Cosmos Hub「租用」安全性，而不用建立和维护自己链的验证节点。
虽然 IBC 源自 Cosmos，但是它也可以用于其他链（未基于 Cosmos SDK 构建），甚至与 Tendermint 完全不同的共识也可以。只是这需要基于链的共识类型和区块链框架，开发 IBC 所需要的不同的组件。
IBC 可视化工具：MapOfZones 更直观的展示了链与链互连通道；Mintscan 更详细的展示了中继器的相关信息；IOBScan 更便捷的可以通过交易哈希进行搜索。

引言

互联网促进了世界上不同地区不同类型计算机之间的相互通信，TCP/IP 的简单性和灵活性使它成为了标准 Internet 通信协议，被用于计算机、服务器、手机，甚至是小型物联网设备。Cosmos 被誉为「区块链互联网」，IBC 就是区块链互联网中的「TCP/IP」协议。它提供了一种无需许可的方式在区块链之间中继数据包，实现区块链之间的相互通信。

图源

IBC 自推出以来已经 18 个月，它已成为安全、可互操作、跨链通信的标准。截至目前，IBC 已在超过 48 条活跃链中实现了超过 4300 万次跨链转账，拥有三百多万用户。

随着多链生态的发展，IBC 不仅支持 Cosmos 生态区块链的跨链通信，也正在与其他区块链生态互联互通，如 Composable Finance 正在将 IBC 带到 Polkadot & NEAR，Electron 使用 zkProof 将 IBC 带到以太坊等等。

本文将对 IBC 跨链通信协议进行详细解读，包括工作原理、关键应用、可视化工具以及安全性讨论。

IBC 是什么？

IBC（Inter-Blockchain Communication）是一种通用的互操作性协议，它支持两个不同的区块链互相通信，而无需信任中间的任何人。IBC 不仅可以用于基于 Cosmos SDK 开发的区块链，也可以用于其他区块链，如以太坊、Polkadot 等。

Cosmos 生态系统的基础设施主要有七个团队为其开发贡献，其中 IBC 协议规范是由 Interchain GmbH 团队领导的。该规范描述了支持 IBC 的链所需的数据结构和接口，包括 IBC 核心协议和基于 IBC 的应用程序，并整合为一套跨链标准 (ICS)。

IBC 解决了什么问题？

一句话概括，IBC 解决了「跨链通信」的问题。互联网使信息可以在世界各地轻松流动。同样，不同区块链之间的信息也需要跨多个平台的自由访问。当用户想要使用区块链 A 的稳定币，通过区块链 B 的去中心化交易所 (DEX) 的流动性池 (LP) 产生收益。这就需要链之间的互操作性来实现。

IBC 不仅解决了互操作性问题，而且以信任最小化、安全、可扩展和通用的方式实现了跨区块链进行任意数据传输。「任意数据」包括资产的跨链和信息的跨链，比如代币和 NFT 资产的转移，也可以在使用一条区块链的同时管理另一条链上的账户，还可以从其他链上查询信息，等等。

IBC 是如何工作的？

IBC 协议的独特之处是它采用分层设计，传输层和应用层来实现整个工作流程。传输层 (TAO：transport layer) 提供必要的基础设施来建立安全连接和验证区块链之间的数据包。应用层（application layer）建立在传输层之上，它定义了数据包应该如何被发送链打包、以及如何被接收链解包。

一个容易理解的类比： IBC 的工作原理类似邮件传递系统。当你通过邮政服务向某人发送一封信，这个邮政服务会把装有信件的信封存入收件人的邮箱。然后收件人打开信封并阅读你的信。IBC 的传输层可以被认为是邮政服务。邮政服务根本不关心信的内容是什么。它只执行从 A 点收取信封并发送到 B 点的动作。信封本身可以看作是从一条链发送到另一条链的 IBC 数据包。在这个信封上，你写了收件人的地址，这相当于 IBC 的数据包里包含发件人和收件人信息。最后，收件人（应用程序）收到信（数据包）打开它并阅读其中的内容。

两个区块链之间 IBC 数据包流，图源：the-interchain-foundation

IBC 各组件间工作流程，图源：the-interchain-foundation

传输层

需要跨链的消息被打包在数据包（packet）中，传输层负责传输、验证和排序这些数据包。在传输层，不关心数据包里面是什么，也不关心接收链怎么解码这个数据包。从传输层的角度来看，数据包中的信息只是随机字节。

传输层的关键组件是轻客户端、中继器、连接和通道。

轻客户端

负责验证数据包中的消息证明。轻客户端是运行完整节点的轻量级替代方案。与完整节点不同，它不存储所有区块数据也不执行交易。相反，他们只验证区块头。IBC 轻客户端实际上是某个区块链中的一种验证算法，用于跟踪另一个区块链的状态变化（时间戳、根哈希、下一个验证节点集哈希），这节省了空间并提高了处理共识状态更新的效率。

也就是说，使用 IBC 交互的两条独立区块链 A 和 B 具有彼此交易对手链的轻客户端。比如，链 A 上有个链 B 的轻客户端，当链 A 想与链 B 通信某个消息 X 的时候，它会将包含消息 X 的区块的块头和消息证明的数据包发送给链 B。然后链 B 使用接收到的数据包进行加密验证以确定链 A 执行了消息 X。反之亦然。

IBC 安全模型是基于轻客户端的而不是链。也就是说，IBC 协议并不关心链的信息，只要 IBC 轻客户端保持着有效的共识更新可以对 Merkle 证明进行验证就可以。这类似 IP 地址和 DNS，其中 IP 地址是 IBC 的 clientID，而 DNS 是 chainID。

中继器

在 IBC 中，区块链彼此间不会通过网络直接互相传递消息，而是依赖中继器进行通信。中继器是链下进程，负责监视运行 IBC 协议的每条链的状态，并将更新的数据包中继给交易对手链。如上一段的例子，当 A 向 B 发送消息 X，A 会在其状态机中提交或存储包含消息 X 的数据包的哈希值。当中继器看到 A 在状态机中提交了一条打算发送给 B 的消息 X 时，他们只需要拿起这条消息 X 并将其传递给 B。

中继器负责来回发送数据包，不能修改数据包，也不对数据包进行任何验证，因此不需要被信任。在建立连接和通道握手的时候，也需要使用中继器。当连接的某一端的链试图分叉或者其他恶意行为，中继器也可以提交不当行为作为证据。

依赖中继器通信存在一个缺陷：想象一下，如果每一对区块链之间都运行中继器，这将是非常复杂的，也及其浪费资源。所以 Cosmos Hub 为此而生，作为区块链之间传输数据的枢纽。只需要在区块链和 Cosmos Hub 之间运行一个中继器，这个区块链就可以与其他已经连接到 Cosmos Hub 的区块链彼此之间传输数据。

目前，链下中继器的运营方式短期内是可行的，但长期是不可持续的。对此，IBC 在跨链标准 ICS-29 中，提出了链上中继激励方法，包括三种不同的方式，费用中间件、费用补助、预算模块。目的是希望为中继者提供一个可持续的收入模式。

注：由于本文主要描述 IBC 协议的工作原理，若想了解更多关于中继器的内容，可以在文章尾部的参考资料中，阅读中继器相关文章。

连接（Connection）

负责连接两个不同链上的轻客户端，通过四次握手验证其各自交易对手的客户端是否是正确的。简单理解就是，在轻客户端验证数据包之前，连接先要对「轻客户端」这个验证者的身份进行验证。这四次握手的所有操作都是由中继器来触发，并且在每次握手更新连接状态之前，会先更新两个链上彼此的轻客户端的状态，以保证其共识状态是最新的。概述过程如下：

握手 1 – OpenInit，从链 A 发起的此握手将其连接状态更新为 INIT
握手 2 – OpenTry，链 B 根据在其轻客户端中链 A 的信息（算法和共识状态的最后快照，包含最新高度的根哈希以及下一个验证节点哈希），验证链 A 的身份。同时还验证交易对手链 A 是否拥有链 B 的身份信息。均验证通过后，从链 B 发起这个握手将其连接状态更新为 TRY
握手 3 – OpenAck，链 A 在其轻客户端中验证链 B 的身份，同时验证链 B 上是否拥有链 A 的正确身份信息。都验证通过后，从链 A 发起的此握手将其连接状态更新为 OPEN
握手 4 – OpenConfirm，链 B 确认自我识别和交易对手识别都成功，将其连接状态从 TRY 更新为 OPEN 握手结束，成功建立 IBC 连接

从上述四次握手的描述可以看到，链 A 和链 B 互有其对手链的轻客户端，在建立连接的过程中，各自验证自己链的对手信息和对手链的自己的信息，来防止有恶意的冒充，验证彼此互为彼此。

Connection State 图源：interchainacademy

通道（channel）

IBC 中应用程序之间的通信是通过通道进行的，是在这些不同链上的应用程序模块之间传输数据包的管道。一个连接可以有任意数量的关联通道。但是，每个通道仅与一个连接 ID（ConnectionID）相关联，这个 ConnectionID 用于识别轻客户端，通道还有一个端口 ID（PortID），用于识别连接通道的应用程序。

链上的应用程序模块负责如何解码和处理数据包数据。通道传输的数据包可以是有序的（ORDERED），由接收模块按照发送的顺序进行处理；也可以是无序的（UNORDERED），按照它们到达的顺序进行处理。要强调的是，在大多数的应用中发送数据包时并不关心顺序，所以可以以任何顺序发送数据包以及任何顺序接收它们。

这尤其对于代币转移来说非常重要。因为如果一个数据包超时，就无法继续再按顺序接收它们，有序通道就会关闭。而且对于区块链之间的通信来说，大多数时候都是异步的，很难保障其按发送的顺序收到数据包。

与建立连接的方式类似，通道也是通过四次握手建立的，其中每一步都由中继器发起。建立通道的握手过程如下：

握手 1 – ChanOpenInit，将链 A 设置为 INIT 状态。此过程中，应用程序通过回调可能自定义一系列检查，如端口是否正确、通道是否按预期顺序、应用程序的版本是否一致，等等
握手 2 – ChanOpenTry，链 B 若验证链 A 状态为 INIT，则将链 B 设置为 TRY 状态
握手 3 – ChanOpenAck，链 A 若验证链 B 状态为 TRY，则将链 A 设置为 OPEN 状态
握手 4 – ChanOpenConfirm，链 B 若验证链 A 状态为 OPEN，则将链 B 设置为 OPEN 状态

当链 A、链 B 的通道状态都为 OPEN 时，通道建立成功。在每次握手中，都需要检查应用程序版本一致性。因为数据包是由应用程序来解析的，如果应用程序版本不同，可能会导致解析数据包失败。

注意，虽然握手流程相似，但连接（Connection）连接的是两个区块链。而通道（channel）连接的是两个模块。

Channel Handshake 图源：interchainacademy

数据包的传输流程

在上述内容中，分别介绍了传输层的关键组件，轻客户端、中继器、连接和通道都是如何工作的。那么，一个将要跨链的数据包是如何被传输的呢？

Packet Flow 图源：https://ibcprotocol.org/

如上图所示，有两个数据包流程的示例，第一个是成功的数据包流程，第二个是超时情况下的流程。详解如下：

链 A 中的 APP A 调用 sendPacket 向链 B 中的 APP B 发送一个数据包，链 A 的核心 IBC a 提交数据包更新自己的状态，中继器监测到这个数据包并向链 B 的核心 IBC b 发送消息。在这个过程里，核心 IBC a 和核心 IBC b 会进行各种验证，验证数据包确实由链 A 发送的，数据包的顺序是否正确，数据包的消息证明是否有效，等等。如果核心 IBC 验证成功，这个数据包到达 APP B。APP B 从核心 IBC 接收到数据包后，会将其按照预期结构解包，然后走相应的应用逻辑。在处理完数据包之后，同时也会给链 A 一个回执。

在 IBC 协议中的数据包结构里，规定了超时时间戳（TimeoutTimestamp）和超时块高度（TimeoutHeight），如果数据包到达链 B 的时间超时了，则该数据包不会被处理。而链 A 在发送的数据包超时后还没有收到回执，就会对数据包的状态做回滚操作，比如，代币转移的应用将会取消托管锁定的代币等等。

应用层

应用层是与最终用户交互的地方。它是基于传输层构建的各种应用程序，负责处理来自传输层通道的数据包。目前用的比较多的 IBC 应用是跨链代币转账和跨链账户。

跨链代币转账

用户可以跨支持 IBC 的链发送代币，遵循跨链标准 20（ICS-20）。ICS-20（Interchain Standards -20）指定了数据包的结构以及接收链如何解码它们。通过在源链上托管代币实现，托管证明和代币元数据被中继到目标链，由存储在目标链上的轻客户端验证托管证明。如果验证通过，将为目标链上的代币生成凭证，并将确认发送回源链。还有一种情况是代币从目标链转移回源链，先由目标链销毁代币，然后源链释放托管的代币。

跨链代币转账应用逻辑，图源：interchainacademy

IBC token transfer on Mintscan，图源：interchainacademy

跨链账户

遵循 ICS-27，基于 IBC 构建的跨链账户管理协议。同时启用了 ICS-27 的链可以在对方链上通过编程创建账户，并通过 IBC 发送数据包来控制这些账户，而不必使用私钥签名。跨链账户允许区块链之间不仅是交换数据，而且可以写入状态。跨链账户包含普通账户的所有功能（即质押、发送、投票），它通过 IBC 由单独的链管理，即控制链（controller chain）。控制链上的账户具有对主链（host chain）上的账户的完全控制权。

进一步解释，为什么跨链账户不用密钥签名也可以实现普通账户的所有功能？简单来说，通过控制链向主链发送带有「编程指令」的 IBC 数据包，以编程的方式控制主链中的账户。

跨链账户还有一个特点是，它提升了跨链交互的体验，它使用户可以保持在同一界面上，而无感实现跨链的交互。

跨链账户，图源：interchainacademy

除了上述的跨链代币转移和跨链账户之外，IBC 还有：

跨链安全（Interchain Security）: 在 Cosmos 2.0 大会上被重点提出并升级。它使区块链能够从另一条链（如 Cosmos Hub）租用安全，而不需要建立自己的验证节点，只需要付出一点租用的费用就行。
费用中间件：遵循 ICS-29，用于激励数据包中继者。
跨链 NFT 传输：ICS-721，是一个应用层协议，可以允许基于 IBC 连接的区块链（包括同构链和异构链）之间实现跨链 NFT 互操作。

IBC 的安全性如何？

Cosmos 生态主要的七个开发团队中，Informal Systems Team 主要负责安全性审查。IBC 协议规范、协议审查和基于模型的测试都是由这个团队来做的。

IBC 安全性的设计围绕两个主要原则

相信链（共识）而不是桥（第三方）

IBC 中数据包的验证是由轻客户端完成的。因此，IBC 的安全性取决于轻客户端的安全性。也就是说在使用 IBC 在链间进行交互不需要额外的信任第三方，也是所谓「信任最小化」。使用基于源链的轻客户端也意味着其安全性与其区块链底层的安全性假设基本一致。

故障隔离机制

可以限制在这些链受到恶意行为影响时所造成的任何损害。

在 Tendermint 中，需要链的快速确定性（即交易被快速打包且无法撤销或更改），也是 IBC 的先决条件，因此原则上不应发生分叉的情况。如果在使用 IBC 跨链通信中的一个链出现恶意行为，中继器可以提交不当行为证明，另一条链上的轻客户端会被冻结。在攻击被消除后，可以通过治理建议解冻轻客户端，从而收回资金。

众所周知，Terra 链稳定币 Luna 几乎归零，在这次危机中，虽然生态中有区块链受到了影响，但多数都是经济模型上的影响，而安全性方面使用了 IBC 协议也经受住了考验。

与跨链桥相比，IBC 的信任最小化使安全性更高。但是也有其缺陷，实现 IBC 的信任最小化的核心「轻客户端」，对于小团队来说这是一项艰巨的开发工作。在 Cosmos2.0 白皮书中提到了「跨链安全」或许可以解决这一难题。

跨链安全将允许其他区块链从 Cosmos Hub「租用」安全性，而不用建立和维护自己链的验证节点。可以理解为，Cosmos Hub 是供应商链，其他应用链是消费者链，供应商链为消费者链生成区块，而消费者链向供应商链及其验证者发放区块奖励。对于小团队来说，使用跨链安全可以减少早期承担过多的技术负担，又同时可以保障其区块链的安全性。

IBC 如何利用其他非 Cosmos 链？

虽然 IBC 源自 Cosmos，但是它也可以用于其他链（未基于 Cosmos SDK 构建），甚至与 Tendermint 完全不同的共识也可以。但是这需要基于链的共识类型和区块链框架，开发 IBC 所需要的不同的组件，比如：

IBC 传输层的实现
链上的轻客户端的实现，用于跟踪要连接的交易对手链。（交易对手链的轻客户端在本链技术架构下的实现）
基于链的共识类型的轻客户端的实现，将用到交易对手链上

如前所述，开发这些组件不是一件简单的事情。在跨链基金会（ICF）的支持下，正有一些开发团队，将 IBC 用于 Bitcoin、以太坊、Polkadot 等。

使用 IBC 的应用链有哪些？

自 2021 年 4 月 Cosmos 推出区块链跨链通信协议（IBC）以来，Cosmos 区块链互联网正在快速发展。从 IOBScan 上的数据来看，截止到目前，通过 IBC 连接的应用区块链已达 53 条，活跃链 48 条，已经发生了 920 万笔 IBC 交易。IBC 的成功实施吸引了更多用户加入 Cosmos，这使得整个生态系统都跟着受益。

截至 Q3，Cosmos 生态系统的 TVL，图源：CosmosATOMDaily Twitter

Kava 以 2.912 亿美元的 TVL 排名第一，Osmosis，TVL 为 2.09 亿美元。排名第二，Thorchain 以 1.0585 亿美元排名第三

深入了解使用 IBC 的应用链，可以掌握未来对 Cosmos 生态投资的主动性。以下简单介绍使用 IBC 的 Cosmos 生态项目，数据均来自「Cosmos Ecosystem - Q3 2022 Quarterly Report」。

Osmosis – Cosmos 上的顶级 DEX

链接

Osmosis 的 TVL 为 2.09 亿美元，在 Cosmos 生态系统中排名第二。Osmosis 始终提供高流动性的流动池，是 Cosmos 生态首选。

在 IBC 统计数据中，Osmosis 一直是排名第一的，在第三季度，30 天 IBC 的交易额每个月都在增长。9 月，Osmosis 的 IBC 总交易额为 4.6873 亿美元，目前有 46 个 peers 和 174 个 channels。此外，Osmosis 拥有 62,027 名 IBC 月活跃用户，占整体 MAU 的 45.4%。

Osmosis 流动性最高的顶级流动池，图源：CosmosATOMDaily Twitter

2022 年 9 月 Osmosis IBC 数据，图源：CosmosATOMDaily Twitter

Kava – Cosmos 的首个 DeFi 平台

链接

Kava Network 是一个 Layer1 区块链，其提出的「co-chain」的架构可以支持以太坊 EVM 和 Cosmos 的跨链流动。其致力于为产品应用和开发者们提供无门槛的永久性金融服务基础设施。同时，其团队打造的 Kava DApp 是 Cosmos 上首个 DeFi 平台，类似 MakerDAO，提供主流数字资产抵押贷款及稳定币的跨链去中心化金融服务。

目前，Kava 的 TVL 为 2.912 亿美元，在 Cosmos 生态系统中排名第一，超过了 Near Protocol。此外，SushiSwap 和 Curve 都已经宣布部署到 Kava。

Kava 生态系统 TVL，图源：CosmosATOMDaily Twitter

Secret – Cosmos 生态的隐私链

链接

Secret 网络是第一个可定制隐私区块链。用户可以选择分享什么，与谁分享，以及如何分享。这保护了用户，并使开发人员能够构建更好的 Web3。

Secret 目前正在使用 CosmWasm 0.10 版，随着 Shockwave Delta 主网升级将升级到 CosmWasm1.0 版。借助 CosmWasm1.0，Secret 智能合约可以在 IBC 协议的帮助下在多个链上运行。

图源：CosmosATOMDaily Twitter

Juno Network – Cosmos 生态的跨链智能合约平台

链接

Juno 是 Cosmos 官方团队开发的，一个可互操作的智能合约网络，可部署 DApp。与以太坊 EVM 使用 Solidity 智能合约不同，基于 Juno 的智能合约是使用 CosmWasm 的。

很多人吐槽 Juno，如果要做 DAPP 可以去以太坊何必来 Juno 呢？其实，Juno 可能更多的是 Cosmos 官方团队用于生态发展的实践产品，就像在 Osmosis 之前，Cosmos 官方团队开发了 Gravity DEX，被 Osmosis 后来者居上后就关闭了。而且由于 Cosmos SDK 模块开发比较容易上手，选择 Juno 上构建 DApp 也可以享受到 Cosmos 生态的助力，很多小型 DApp 产品选择 Juno 很有优势。

Juno Network 的 dApp 和工具，图源：CosmosATOMDaily Twitter

Cosmos 生态是一个区块链互联网，而 IBC 担负着「跨链通信」的职责，这类似 Web2 互联网中的「TCP/IP」。Osmosis（DEX）、KAVA（DEFI）、Secret（隐私）、Juno（智能合约 DApp），都是一个个独立的区块链，他们的发展方向各有不同，但是他们都使用了 IBC，加强了彼此的互操作性可组合性，使得生态中的用户不断增加，彼此受益。

IBC 可视化工具

推荐三个 IBC 网络的可视化工具，可以查看 IBC 网络中的链（hub&zone）、连接、通道、交易的信息，也可以帮助选择中继器。

MapOfZones

Cosmos 网络浏览器。可以直观的看到 Cosmos 生态网络下各个链之间的连接关系和当前的活动信息，包括：IBC 转账次数、IBC 交易量、成功率、成交量、交易量等等。

https://mapofzones.com/home

zones/osmosis-1/peers

如上图所示，MapOfZones 还可以展示链与链之间的连接列表。同时还可以看到所选链与其它链之间的通道信息。

Mintscan

也是 Cosmos 网络浏览器。Mintscan 的特点是除了基本 Cosmos 生态网络链与链之间的关系和 IBC 信息的展示之外，还可以在详细页面中看到连接、发送 / 接收交易、中继器交易历史和中继器交易量的信息，其对中继器的信息展示的非常详细。

https://www.mintscan.io/osmosis/relayers/channel-0

IOBScan

与前两个类似，也是 Cosmos 网络浏览器。IOBScan 的一个特点是，可以通过交易哈希进行搜索。

https://ibc.iobscan.io/home

结语

未来是多链共存的，这几乎已经成为加密圈内的共识。但未必是跨链的，这是当下还存在疑虑的。当可以将所有应用程序都放在一个通用链上时，为什么还要有多个区块链呢？毕竟，在一条链上拥有多个应用程序使它们更容易通信和共享数据。

其原因有两方面，一方面是资源竞争，区块链上的区块空间是有限的，应用程序在同一个区块链上自然免不了要彼此竞争。

另一方面是专业化。应用程序存在于通用链上必须适应通用链的功能，如果想要开发独特的功能或许会受限于通用链的底层设施。而为某一类应用类型而定制的区块链可以更好的优化性能、安全、主权等等。所以，既然应用区块链的发展是必然的，那么应用链与通用链之间、应用链与应用链之间，跨链通信、跨链组合也是必然的。只是当下，区块链基础设施还不完善，各项技术还处于发展中，所以很难说在跨链技术方面，哪一种是最佳的。

在 IBC 之前，跨链通信主要由跨链桥来实现。然而，在过去这半年由于一系列的黑客攻击，这些跨链桥在过去几个月中饱受争议。与第三方跨链桥相比，IBC 提供了一个信任最小化的通信环境，通过使用轻客户端加密验证交易对手链的共识状态。

这使 IBC 跨链通信的安全性与每个区块链底层的安全性基本一致。但是 IBC 的这种设计理念，以确保网络安全性作为第一目标，当然会牺牲一部分的可扩展性和成本。轻客户端的开发难度、部署成本，在一定程度上限制了 IBC 的可接入的链数量。当然，在跨链基金会（ICF）的支持下，已经有一些开发团队将 IBC 扩展到 Cosmos 以外的生态系统，相信这将进一步推进 IBC 协议的应用。

对于 Cosmos 生态来说，IBC 推动了其快速发展，成功的实现了 Cosmos「区块链互联网」的第一步「跨链互连」。

随着 Cosmos 2.0 的升级，如跨链安全、跨链调度、跨链分配，以及 ATOM 新的经济模型，这一系列组件环环相扣，使共享安全的落地成为可能。有了共享安全，应用链不需要自己实现共识机制、维护验证节点，应用链可以更专注于与用户交互的体验和功能。同时，也将进一步的降低 Cosmos 应用开发难度，可以让小团队非常容易地创建新项目，对开发人员的友好一定会助力生态的繁荣。

由于时间和精力所限，本文只是简单的介绍了 IBC 的实现原理和一些基本面信息。未来希望可以带来更多 Cosmos 的内容。