48-区块链间通信协议 conv.docxVIP

区块链间通信协议

Abstract

区块链间通信协议（IBC）是一个端到端的、面向连接的、有状态的协议，用于在独立的分布式账本上的模块之间进行可靠、有序和认证的通信。IBC是为异质账本之间的互操作而设计的，这些账本排列在一个未知的动态拓扑结构中，以不同的共识算法和状态机运行。该协议通过指定足够的数据结构、抽象和通信协议的语义来实现这一点，一旦被参与的账本实施，它们就可以安全地进行通信。IBC与有效载荷无关，并提供了一个跨账本的异步通信基元，可作为各种应用的组成模块。

IndexTerms—ibc;interblockchain;dlt

I.Introduction

由于其作为复制状态机的性质，必须在其上保持确定性的执行，因此必须保持对确切的确定性规则集的持续认同，单个分布式账本的吞吐量和灵活性都是有限的，必须用特定的应用优化来换取通用能力，并且只能为建立在其上的应用提供单一的安全模型。为了支持交易吞吐量、应用多样性、成本效率和容错性，以促进分布式账本应用的广泛部署，执行和存储必须被分割到许多独立的账本上，这些账本可以同时运行，独立升级，并以不同的方式进行专业化，其方式是保持不同应用之间的通信能力，这对于无权限创新和复杂的多部分合同至关重要。

一个多账本的设计方向是将一个单一的逻辑账本分散到不同的共识实例中，称为分片，这些分片同时执行并存储状态的不相干部分。为了对安全性和有效性进行全局推理，为了在分片之间正确路由数据和代码，这些设计必须采取自上而下的方法--构建一个特定的网络拓扑结构，通常是一个单一的根分类账和一个星形或树形的分片，以及工程协议规则和激励措施来执行该拓扑结构。然后，消息传递可以通过Polkadot的XCMP[1]和Ethereum2.0的跨分片通信[2]等系统在这种分片拓扑之上实现。这种方法在简单性和可预测性方面具有优势，但在保证状态转换的有效性方面面临着困难的技术问题[3]，需要所有分片都遵守单一验证器集（或随机选出的子集）和单一虚拟机，并且由于必须就网络拓扑结构或分类账规则集的改变达成全球共识，因此在随着时间推移升级方面面临挑战。此外，这种分片系统是很脆弱的：如果超过了容错阈值，系统需要协调全球停止和重新启动，并可能启动复杂的状态转换回滚程序--不可能安全地隔离网络图的拜占庭部分并继续运行。

区块链间通信协议（IBC）提供了一种机制，通过这种机制，独立的、主权复制的分类账可以安全、自愿地进行互动，同时只共享一个最低限度的必要的公共接口。该协议的设计接近一个不同版本的扩展和互操作性问题：使异质分布式账本的网络能够安全、可靠地互操作，以未知的拓扑结构排列，在可能的情况下保持数据保密，其中账本可以多样化、发展和重新排列，独立于彼此或特定的强加拓扑结构或账本设计。在一个广泛的、动态的互操作账本网络中，预计会出现零星的拜占庭故障，因此协议还必须根据所涉及的应用和账本的要求，检测、缓解和控制拜占庭故障的潜在损害，而不需要使用额外的信任方或全球协调。

为了促进这种异质性的互操作，区块链间通信协议采用了自下而上的方法，规定了在两个分类账之间实现互操作所需的一组要求、功能和属性，然后规定了多个互操作分类账的不同组成方式，以保持更高级别的协议要求。因此，IBC对整个网络拓扑结构没有任何假设和要求，对实施分类账只要求有一组已知的、具有特定属性的最小功能。IBC中的分类账被定义为它们的轻型客户端共识验证功能，从而扩大了分类账的范围，包括单机和复杂的共识算法。IBC的实现预计将与主机分类账上的更高级别的模块和协议共同驻留。托管IBC的分类账必须为共识成绩单(consensustranscript)验证和加密承诺证明的生成提供一定的功能，IBC数据包中继器（非分类账进程）预计可以访问网络协议和物理数据链，以读取一个分类账的状态并向另一个分类账提交数据。

IBC数据包中的数据有效载荷对协议本身是不透明的--每个分类账上的模块决定了它们之间发送的数据包的语义。对于跨账本的代币转移，数据包可能包含可替换的代币信息，其中资产在一个账本上被锁定，以在另一个账本上铸造相应的凭证。对于跨账本治理，数据包可以包含投票信息，其中一个账本上的账户可以在另一个账本的治理系统中投票。对于跨账本的账户授权，数据包可以包含交易授权信息，允许一个账本上的账户被另一个账本上的账户所控制。对于跨账本的去中心化交易所，数据包可以包含订单意图信息或交易结算信息，这样，不同账本上的资产可以通过过渡性托管和数据包序列进行交换，而不需要离开其主机账本。

这种自下而上的方法与TCP/IP规范[4]非常相似，并直接受其启发，用于包交换计算机网络中主机之间的互操作性。正如TCP/IP定义了两个