正文
2 示例场景
为了使讨论不那么抽象，这里用例子说明一个具体情形是如何工作的。Alice想从她在Cosmos分区X上的账户发送30个wink币（示例代币名称）给Cosmos枢纽上的Bob。假设分区X已经跟枢纽建立了一个IBC连接，Alice将在分区X上创建一个交易来发起传输。分区X会将那些代币冻结在某个托管账户，然后创建一个IBC数据包请求枢纽在Bob的账户中创建相应数量的代币。本质上，分区X上的验证节点集合会保证销毁这些代币以换取在枢纽上重铸它们。
一个独立的中继进程（任何人都可运行的客户端软件）可以从分区X提取那个IBC数据包的证明并将其发布到枢纽。枢纽将验证区块头，Merkle证明和顺序号来确保这是一个从分区X来的有效的IBC数据包。这下我们面临两个选择：要么分区X在枢纽上有足够信用来铸这30个wink币从而数据包被接受，要么信用不够而数据包被拒绝。如果数据包被接受，枢纽就在Bob的账户中铸30个新鲜的wink币，并将数据包连同成功记录存在它的传入队列中；如果数据包被拒绝，则不会创建代币，且队列中会存入一个失败记录。
我说的“信用”指的是什么？我们不希望每个连接到枢纽的链都能在枢纽上随意创建任意数量的任意代币，否则所有经济保证很快就变得毫无意义。枢纽必须使用它自己的逻辑来验证它是否足够信任分区X并接受那30个wink币。如果分区X是wink币的本源（X的原生代币），那么在发送wink币到枢纽这件事上，它将得到枢纽的极大信任。如果枢纽之前已经向分区X发送过500个wink币，那么它必须记住这个信息并允许分区X将（不超过）那500个wink币发送回枢纽，从而实现代币的自由流动。这个逻辑可以为代币传输提供安全性，其它应用则需要在不完全信任网络中所有分区的情况下，运用它们自己的逻辑来维护全局约束条件。
在枢纽成功或不成功地执行了那个交易之后，我们希望将交易的收据（连同证明）传回到分区X以完成这个循环。此收据只是另一种类型的IBC数据包，其执行方式与发送一样。唯一区别是，在发起分区处理收据绝不能产生错误。（根据收据内容）如果交易是成功的，则分区X将销毁托管的30个wink币，代币在分区间转移成功；如果交易因任何原因被拒绝，那么托管代币就会释放回Alice的账户 – 就像什么都没有发生过一样。
这意味着，在收到响应（成功或失败）之前，谁也不能碰分区X上的托管代币。除非我们有证据证明该数据包被接收链拒绝，已经发出的代币不会被释放。没有代币会被无端创建或销毁，也不可能执行双花，代币不会莫名消失在跨链操作中。发送方只需要等待两个数据包的转发和执行（很多情况下是十来秒钟）。对处理硬分叉分区（如ETH/ETC或BTC/BCH）的考虑会在下面的高级章节讨论。
3 消息传递语义
在试图扩展区块链时，必须找到一种不违反任何安全保证的可行方法，来增加并行写的数量。防止双花需要为任何给定账户提供严格的串行访问（读和写），但是我们需要一些安全的方法来允许多个交易同时执行，而又不给恶意利用竞态条件提供可能性。
通过IBC协议，我们寻求避免一个问题，那就是允许多个独立节点将交易应用到相同的状态空间。如果你不想丢失任何数据（比如：强最终一致性），这个问题即便不考虑拜占庭角色也是困难的，在面对恶意行动人寻求利用任何不一致为自身牟利的情况下，则变得极其困难。安全地将不同的部分排序协调成一致的全局排序的最严谨方法是CRDTs（无冲突数据复制类型），它保证一组固定交易的所有可选的部分排序都将收敛到相同结果。CRDTs确实很有趣，但由于其固有特性，不允许在区块链用例中强制执行约束条件（例如，账户余额永远不能为负数）。
这个问题的另一个解决方案是使用分片，每个分片都只能访问状态空间的一部分。这可以增加吞吐量，但也会使任何涉及多个分片的交易极难正确执行。触及多个分片并需要一致视图的查询可以通过使用快照来执行，但是在高度分布的环境中这可能很困难。如果您想在两个分片上安全地、原子地查询和修改数据，就需要类似锁和三阶段提交的机制，这在许多数据库中都使用过。但是，如果您想要保证顺序并在通信层引入同步和定时假设，这就是一个阻塞操作，这使得它不适合分布式(多)区块链的场景。
