关注章鱼网络，开启 Web3.0 浪潮
章鱼网络已经完成 NEAR-IBC 项目 pre-release.1 版本的开发工作，并与 Blocksec 达成审计合作，进入合约的审计阶段。
章鱼网络核心工程师杨镇老师，受 NEAR 生态中文开发者公开课的邀请，将向 NEAR 开发者和 COSMOS 生态开发者介绍 NEAR-IBC 项目的概况和技术实现方案。
核心内容包括：
https://www.bilibili.com/video/BV1Xk4y1T7xY/?spm_id_from=333.337.search-card.all.click&vd_source=4edb68f7b58109177898f55a84f2335b
大家好，我是章鱼网络的杨镇。
首先感谢 NEAR 社区的邀请，还有 IBCL 社区的组织和宣传。
我们章鱼网络是大概 2021 年的下半年上线了我们的第一个版本的 LPoS 协议，就是在 NEAR 上部署的租赁安全的智能合约，通过租赁 NEAR 生态的 OCT 资产来为 Substrate 应用链提供安全性。2022 年底的时候，我们开始规划 Octopus 2.0 的版本，全面地拥抱 Cosmos 生态，我们希望可以做一个基于 IBC 协议的、托管在 NEAR 上的租赁安全 Hub，让 NEAR 资产可以为基于 Cosmos SDK 构建的应用链提供安全性。我们这个 Hub 还是在 NEAR 上通过智能合约来实现。
NEAR-IBC 就是一个 NEAR protocol 上的 IBC 协议的实现，是 Octopus2.0 的重要基础组件。只有 NEAR-IBC 实现之后，我们才能去实现章鱼网络面向 Cosmos 应用链的租赁安全协议。
图 3
图 3
首先我们来看一下 IBC 协议最简单的概念模型，Cosmos 生态的开发者或者对 IBC 协议感兴趣的朋友可能会看过 IBC 协议，知道这是一个非常繁杂的基础设施协议，有很多组件，很多 SPEC。但我今天想从最高的层级上给它先做一下简化，让大家先知道 IBC 协议是怎样的一个运作方式。IBC 协议是一个通用的跨链协议，它解决了两个区块链之间如何传递具体的数据、如何去做互操作，如何去完成任务的问题。抽象的看大概是图里显示的样子：假设 Chain A 和 Chain B 要进行跨链互操作或者跨链通信，在每一个 Chain 上都会有 IBC 协议的实现，两个 Chain 中间有一个 Relayer。这个 Relayer 有三个职责：
1、Monitor，Relayer 会监视两侧的区块链产生的 Event；
2、一旦收到 IBC Event 之后，Relayer 会把它转换为实际的 IBC message；
3、将转换后的 IBC message deliver 到对面的链上去。
Relayer 本身是 permissionless 的（无需许可的），之所以 Relayer 能够做成无需许可的，是因为我们的 IBC message 在被 deliver 到对侧链的时候，会有相应的密码学验证和一些其他类型的验证（可能不是密码学的验证）。总之就是 Message 本身在到对侧链执行之前会有对应的验证过程。这就是 Relayer 的大致结构。
那么具体的 IBC 协议，是一个分层协议，如图 3 所示，是分成两层，一层是 IBC/TAO，那 TAO 的话是 Transport Authentication 和 Ordering 三个英文的缩写，也就是传输、认证和排序。Transport 和 Authentication 的话，指的是这个数据从 A 链 Deliver 到 B 链上去，然后在 B 链执行之前会有对应的 Verification 来去检查 Messenger 里边所附加的 Proof 是不是合法的这么一个过程。排序主要是指的 IBC 对应的 Message 是有顺序的，即可以基于单向增长的 Sequence 来生成的。由此可见，IBC/TAO 这一层主要做 IBC 协议的基础服务。
在 IBC/TAO 之上有 IBC/APP 也就是应用层协议。IBC/APP 与 IBC/TAO 之间会有固定的内部接口，也就是说通过底层协议把数据传到对侧链之后，对侧链上的应用可以有对应的接口来接到数据并进行具体的处理。
所以图 3 就是整个 IBC 协议的总体架构，4 个重要的概念：Relayer、IBC Message，以及 IBC 分层协议中的 IBC/TAO 是传输层，IBC/APP 是应用层，知道这些概念就可以了。
图 4IBC/TAO 传输层里边的话有三个最重要的基本概念，就是 Client、Connection 和 Channel。
Client 的话其实是跟早期 Ethereum 社区里谈的 Light Client 是等价的，也就是说是在区块链外去验证区块链上的数据，或者验证区块链状态所要使用的一些外部的数据。那 IBC 里边，如果 Chain A 要和 Chain B 相连的话，Chain A 上面就应该有一个 Chain B 的 Client，然后在 Chain B 上会有一个 Chain A 的 Client，Client 负责验证从区块链获取数据的合法性。因为区块链本身是一个封闭、自洽的密码学系统，它里面的数据产生都必须经过严格的密码学算法的验证和共识，所以在链外需要用链上数据的时候，就需要有 Client 去做对应的验证。IBC/TAO 里边最重要的两个概念的话，其实是 Connection 和 Channel。在图 4 里，我是尝试用一个比较容易理解的方式把 Connection 和 Channel 的概念给大家介绍一下。因为我相信有些朋友可能看过 IBC 相关的一些资料里边经常会提到说，拿 IBC 里的 connection 和 channel（可能还有 port），去跟我们 TCP/IP 协议里边的一些类似的概念去做比较，但是我个人觉得从技术概念上它们还是有较大差异的，所以我直接按 IBC 中的定义来介绍这两个核心概念。
Connection，抽象一点可以理解为要进行 IBC 协议跨链的这两个区块链的的配对关系。在这个图 4 里，Chain A 和 Chain B 之间的 Connection，代表的就是 Chain A 上的 ClientB 和 Chain B 上的 ClientA 的配对关系。Connection 不是实际存在的物理连接，而是一个逻辑定义，是限定了该 Connection 下建立的所有 Channel，必须通过 Connection 绑定的两个 Client 进行验证。
Connection 的唯一标识是通过它在两个链上的 Connection ID 来决定的。在这个图中， Chain A 上的 ID 是 0， Chain B 上也是 0，就是一个配对关系。Connection ID 的计数是以链本身的 Connection 数量进行递增的。比如这里 Chain A 连接了两个链，分别是 0 和 1， Chain B 只连接了一个，所以是 0。也就是说，Chain A 和 Chain B 之间这个 Connection，是由两端 ID 为 0 的 Connection End 组成的一个逻辑配对关系，这就是 Connection 的概念。
Channel 的概念的话，其实是某一个特定的 APP，左边这些 IBC/APP 中的某个特定的 APP 和另一个链上的特定的 APP 之间通信的一个通道，被叫做 Channel。
这里的 Channel 是指两个链上的特定 APP 模块间的一条通信通道。它与 Connection 类似，也是一个逻辑配对关系，由两个链上的 Channel End 构成。每个 Chain 上的 Channel ID 都包含 Channel 所属的应用模块名字，也称作 Port，以及一个自增的序号。比如这里 Chain A 上的 Transfer Port 有 4 个 Channel，所以 ID 是从 0 到 3，Chain B 上有 2 个，所以是从 0 到 1。绿线表示两个 Channel ID 的对应关系。这些都是一些逻辑概念，实际通信通过 Relayer 中继完成。我觉得初学者只要明白这几个关键概念就可以基本理解 IBC 的运行机制了。
我们暂时不再讨论 IBC 协议的更多实现细节，因为非常复杂和严谨，我们关注抽象出来的逻辑概念就可以。这里列出了 IBC App 应用层中一些常用的模块，其具体功能后面会简要介绍。当前我们只需要知道，IBC App 层会有许多不同的应用来丰富协议功能，因为 IBC 底层本身没有业务逻辑，具体的业务实现都在 App 层中。
图 5接下来我们看一下 IBC Message。它是 IBC/TAO（传输层）中对跨链通信的一种抽象。IBC 协议里目前定义了四种消息类型，Client Message、Connection Message 和 Channel Message 分别对应前面我们提到的三个核心概念，用于同步其状态。还有一种是 Packet Message，它是为 IBC/App 应用层定制的，可以包含自定义的数据供 App 处理。
IBC/TAO 对需要发送给应用层模块的数据，进行了一个自定义二进制数组的封装。当这个数据 relay 到目标链上的 IBC 实现后，会根据 Packet 指定的目标 App，找到对应的 Module 实现，然后把数据交给它进行解码和执行。
图 6
简单介绍完 IBC/TAO 的一些基础概念。接下来看一下 ICS20 模块，这可能是目前在 IBC 里最容易实现也最有价值的模块。它实现了 Fungible Token 的跨链转账，类似于以太坊的 ERC20。
ICS 20 的主要功能就是四个 Use Case ：从 Chain A 转 Fungible Token 到 Chain B ，并可以 Redeem Token 回 Chain A；从 Chain B 转 Fungible Token 到 Chain A ，也可以 Redeem Token 回 Chain B。虽然看起来是对等的，但因为不同链实现上的差异，技术实现也会有较大不同，我们后面会介绍 NEAR-IBC 中实际使用的设计。
接下来我们来讨论一下使用智能合约来实现 IBC 协议会面临哪些技术挑战。
图 7首先是 gas Limitation，因为智能合约受执行平台本身的资源限制，我们不能给智能合约无限的计算资源。无论是以太坊还是 NEAR ，都设计了 gas Limit 来限制合约的可用计算量。
有了 gas Limit 之后，在 IBC 验证中就可能会遇到验证签名时 gas 不够的问题。因为对侧链上，POS 链通常会有一个 Validator Set 的概念，这是一个保障链上安全的验证人集合。这个集合需要定期更新，更新时需要收集旧的验证人对新集合的签名，达到一个确定的门限，比如 NEAR 是 2/3 的总抵押量。要做更新验证就需要在智能合约中验证签名。如果某条链的验证人数量非常大，比如超过 200 或者 300，那么验证签名的计算量可能就会超过智能合约平台单个函数的 gas 上限，导致验证失败。比如 NEAR 的限制是 200T gas。根据我们的测试，200T gas 大概只够验证 50 到 100 个签名左右。此外，除了签名验证，合约还需要做其他处理，包括各种数据转换和检查逻辑等，这些都需要 gas。所以实际可用的 gas 一定达不到最大上限。另一个问题是，在 IBC/App 这层中，不同模块具体所需的计算资源是不可知的。所以可能会遇到某个新增的 App 模块，在处理 Packet 消息时会超过当前 gas 的限制。这些 gas Limit 都会造成 IBC 实现的一个困难和挑战。
第二个挑战就是 On-chain Asset Management。我们知道类似 Cosmos SDK 或 Substrate 都有通过协议级来处理链上资产的注册，甚至可以在无需用户交易的情况下直接操作用户资产。但在智能合约平台上是没法做到这一点的， Fungible Token 数据都是由单独的智能合约管理的。所以这类逻辑在智能合约平台无法直接使用，需要改变具体实现方案，这也是后面会讨论最多的一个点。
第三点是虚拟机的 Sandbox Limitation。我们知道当前的智能合约平台都是基于虚拟机，它提供一个封闭可控的环境，但访问宿主链的能力是有限的，比如智能合约无法获取链上的共识状态等信息。我们知道在以太坊上有 world state，也就是世界状态的概念，这个世界状态的话实际上是用了一个数据结构，把这个链上所有发生的存储的变更组织到一个树里面去，然后用这个树的 root 哈希来去表示这个世界状态。NEAR 也有类似的状态根概念。这些状态信息，智能合约都是无法直接获取到的，这些是宿主环境无法直接暴露给虚拟机的信息，就需要我们在实现上做额外处理。还有一个小细节可以提一下，就是因为 NEAR 是异步链，如果一笔跨合约调用跨到了不同块，也会增加复杂度。这会导致 Relayer 在获取状态上出现偏差。所以，虚拟机的 Dandbox 机制也会带来一些挑战 。
最后一个挑战就是这个 On Chain Storage，就是我们怎么在链上去保存数据，在智能合约平台保存数据和在 Cosmos 链上存储数据的方式是不一样的。
目前来讲，绝大多数区块链系统的它的这个链上存储都是一个 KV 数据库，那么 KV 数据库里边这个 key 是怎么来确定的呢？像 Cosmos 和 Substrate 链是通过链上原生的协议级别的逻辑来去确定这个存储键的键值的构成。但是在智能合约平台里会有平台本身的设计，比如说在 EVM 里边是用这个账户地址加上合约里的 Slot Number，用这两个东西去生成的存储键值，然后再生成到这个状态树里边去。比如 NEAR 的话是用 NEAR SDK 里边的 Collection 或者 Store 这些 Module 里边提供的这个工具类，比如说这个 Lookup Map，然后去存链上数据的时候，由 SDK 约定的一个算法来去生成这个存储键值。比如当我们在 New 一个新的 Lookup Maps 的时候，会传一个 Prefix 作为存储键的前缀，最后实际生成到存储里边的键值就是用这个 Prefix 加上 Map 里边的 key 的实际值，然后生成一个存储键值。
但是 IBC 协议里边有严格的规定，要通过存储键值去链上获取这个键值对应的那个值的 Proof（密码学的证明），所以它需要一个比较严格的 Path Rule（存储键值规则）。比如我要存这个 NEAR Client 的状态数据，就要基于这个 Path Rule，这是 IBC 协议里规定的一个固定的 Path，就是 Clients/<client ID>，用这个固定的 Path 去链上获取这个数据的 Proof。
因为智能会议平台本身有这个链上存储键值的生成的规则，所以如果这个智能合约平台的规则和 IBC 协议的这个规定不符合的话，我们就要去做额外的处理，那么这就会引入额外的复杂度，也会引入额外的 bug 风险。
总体来说，智能合约平台自身的一些特性和限制，会使 IBC 实现更具挑战，需要在工程解决方案上下功夫。后面我们会关注更容易理解的 High level 的解决思路，比如说账户的设计之类的具体方案介绍。
图 8NEAR IBC 项目是我们团队去年底启动的，已经完成了 pre-release.1 版本，现在请 Blocksec 进行安全审计。当前版本实现了 IBC/TAO 基础传输层的所有接口，还有 ICS20 的 4 个 use case。这个 pre-release.1 版本是基于 IBC-RS 0.28 版本开发的。IBC-RS 是一个 Cosmos 社区维护的 repository，是用 Rust 语言写的 IBC 协议的实现。
NEAR IBC 是站在巨人的肩膀上，在 IBC-RS 的基础上做了增强与适配，主要实现了链上存储相关的接口，以及获取链上数据的协议级接口。我们正在开发 pre-release.2 版本，会升级基础库到 IBC-RS 0.4x，同时增加 Solomachine Client 的支持，以支持我们自己的这个 VP solution，就是 vertication proxy，配合我们自己的验证方案，也就是我们年初提到的 Adaptive IBC 解决方案，这里就不展开说明了。
另一个变化是修改链上存储的键值生成逻辑。因为 pre-release.1 版本还是直接使用了 NEAR SDK 的存储结构，但规则与 IBC 规范不符，所以 pre-release.2 版本会重新按规范来实现存储相关代码。
图 9从 High level 来看的，NEAR IBC 在工程实现上主要是定制了 ICS20 资产管理的部分。我们采用了基于 NEAR 子账户机制设计的方案。在该设计中，图 9 上半部分子账户用于支持从其他链跨入 NEAR 的资产，存证、Redeem 的流程。下半部分子账户用于支持从 NEAR 向其他链做出资产跨链。
上部分是支持从其他链过来的资产，每种资产会有一个 Asset ID。NEAR 里边的子账户机制，对于我们实现 IBC 这种复杂协议，是一个比较好的机制，能够让我们免去 hard code 实现一些访问权限的控制。
一个完整的账户，比如这个 asset ID1 完整账户就是 asset ID 1.token-factory.transfer.<NEAR ibc>，那么这其中 asset ID 1 是一个账户，token-factory 是一个账户，transfer 是一个账户，NEAR ibc 是一个账户，总共是 4 个账户。
通常跨账户因为已经不在一个账户里了，所以他一定是不可信的。但是有了这个子账户的机制（因为子账户只能通过父账户创建），就有了一个天然的授权机制。可以把子账户看成父账户内部的一个 module，可以在合约代码里通过 predecessor account ID 去跟当前的 account ID 做比较，判断调用者是否是父账户或者子账户，从而原生地进行访问权限控制。这也是我认为一个比较有用的经验，希望有更多 NEAR 开发者能灵活运用这个机制，开发一些复杂的智能合约。
图 10这里解释一下前面提到的资产 Asset ID 生成逻辑。在 IBC 里面，假设我们有一种资产，这个资产叫 asset 0，它是 chain A 上的资产。它通过一个跟 chain B 的 channel ，transfer/channel-0 到 chain B 的 transfer/channel-0，这两个 channel ID 组成的 channel 转到了 chain B 上。然后这个资产从 chain B 又转到了 chain C 上，是通过一个独立的 channel ，从 transfer/channel-1 到 transfer/channel-5，通过这个 channel 又转到了 Chain C 上面。
这样的话，这个 asset 0 其实际来源是 chain A 。所以我们要唯一标识这种资产，就需要一个 tracing path 这个概念。在 chain B 上，这个资产来自 chain A 的 channel 0 到 chain B 的 channel 0，所以它的 tracing path 是用 chain B 上的这个 channel end 来唯一标识的，就是 transfer/channel-0 来标识的，但转到 chain C 的时候，它是从 chain B 的连接过来的。所以它在 chain C 上的 channel ID 是 transfer/channel-5。那么原始 tracing path 上就会加上它之前过来的 channel ID ，在 chain B 上的 channel ID ，它是从这里过来的。所以这个资产的 tracing path 就变成了 transfer/channel-0/transfer/channel-5。
这样的话，这个资产因为来源不同，在 IBC 里面就会有对应的 tracing path 来标识这种资产。实际上标识资产是用这个 tracing path 加上资产本身在 IBC 协议中的标识，称为 denomination。我们可以理解为 NEP-141 中的 name 或 symbol，这个 name 和 symbol 跟 ERC20 的 name 和 symbol 是类似的概念，是一个唯一标识。
NEAR IBC 为了唯一标识资产，就用了 tracing path 加上 asset 的 denomination，用这两个做 SHA256 哈希，然后取前 128 位，转换成 HEX 之后是一个 32 字符长的 HEX 编码。之所以这样处理是因为 NEAR 里账户 ID 长度有限制，最大为 64。所以根据之前的子账户设计，完整的子账户 ID 也需要限制，否则账户名会超长，后续用 factory 创建子账户时就会失败，因为是无效的子账户名。因此做了这个处理，确保账户 account ID 长度在协议允许的范围内。
图 11后面的几页是 NEAR IBC 要解决前面提到的 ICS20 里的 4 个 use case 所用到的 high level 的 sequence（时序）设计。
首先是从其他链转资产到 NEAR 上，这个首先要按 IBC 协议要求，在 IBC/TAO 里创建对应的 connection 和 channel。创建 channel 后可以用 Governance 账户（NEAR IBC 里会有一个预置的 Governance 账户）。这个 Governance 账户通常是链上的 DAO，比如 NEAR 的 AstroDAO，或者 AstroDAO 的账户作为 Governance 账户。这个 Governance 确定现在这个桥要支持某一种资产，就可以在 DAO 里发一个 Proposal，这个 Proposal 投票通过后就可以产生一个 Function Call 调用 NEAR IBC 的 Setup Token 函数。这个函数里需要传过来资产的 Tracing ID，也就是前面说的 Tracing Path 和 Denomination，还有其他信息。然后 NEAR IBC 合约会调用它的子账户，就是 token factory.transfer.<near-ibc>。这个 token factory 里有一个 setup asset 函数，这个函数会创建对应的子账户。用前面介绍的算法生成子账户 ID，然后创建子账户，做必须的初始化，把这个代币账户初始化好。这是一个一次性的处理，就是说当 NEAR IBC 决定要接收某个链的某种资产时，先把需要的 Connection 和 Channel 创建好，然后从对端链获取 Tracing Path 和 Denomination 等信息。通过 Governance 发起调用，创建对应的子账户。这相当于是一个初始化工作。
这个工作在 Cosmos SDK 里可能是要用 Bank 模块注册一个资产；在 Substrate 里也类似，大概是用 Assets 模块注册新资产，这是一个一次性的过程。这个子账户创建成功后，后续转账就是用标准流程。通知 Relayer，它收到对侧的转账消息后，会把它转化成 Packet Message，（前面也介绍过，Packet Message 里会指定这是一个要交给 Transfer Module 处理的消息。）然后 Relay 到 NEAR IBC 合约里。因为 IBC 合约继承了 IBC RS，会做消息解析，路由，判断这是要交给 Transfer Module 的消息，然后把消息交给 Transfer Module。在 Transfer Module 里会有对应的函数，是一个它暴露的接口，叫 mint/burn。这个接口里我们可以调用 Token Factory 的 Mint Asset 函数。然后 Token Factory 再调用实际管理跨链资产的 Token 账户合约的 Mint 函数。为什么这里没有直接用 NEAR IBC 调用 Token 合约，是因为有 Asset ID 的逻辑。我希望这部分逻辑都在 Token Factory 处理，而不需要跟 NEAR IBC 合约耦合。所以做了解耦设计，由 Factory 统一管理跟 Asset ID 相关的逻辑。
那个 Asset 其实是基于 NEAR 的 NEP-141 标准合约定制的 Fungible Token 合 约。它是有特权的 Mint 函数，Mint 函数权限就是前面介绍的子账户机制。这个合约的 mint 只接受父账户发来的请求。这是一个简单自然的访问控制方式。
这就是从其他链转资产到 NEAR 的流程。
图 12这个相反的流程是把转过来的资产 Redeem 回原链的流程。
这个流程是由 Token Holder 在 NEAR 直接发起的。相当于我从其他链转了资产到 NEAR 上的这个代币子账户里。然后我需要直接给子账户发一个签名的交易，表示我要把部分 Token Redeem 回原来的链上。
这个函数我们起名叫 requestTransfer。这个 requestTransfer 会在 Token 合约里生成一个 Transfer Request。相当于是一个预记账，预记账的意思是因为这是一个跨合约调用，而 NEAR 合约是异步执行的，而异步处理也可能失败。所以我必须在原始合约先做记账，就是把用户要转的部分 Token 从用户账户划到当前合约账户，锁在合约里。然后发起 processTransferRequest 调用到 NEAR IBC 合约。NEAR IBC 合约会来处理这个情况，就是 IBC RS 里的 sendTransfer 函数。这也是一个特权函数，只接收 NEAR IBC 子账户发来的请求，这也是天然的权限控制的方法。
然后在 processTransferRequest 函数里调用 IBC RS 的 sendTransfer，这个会有对应的检查，按 IBC 协议里 ICS20 模块的业务检查。如果检查通过，会回调到 token 合约调用 applyTransferRequest。就是把前面预记账的部分实际 burn 掉。因为这是把从其他链跨过来的资产再跨回其他链，所以这里是 burn。前面把 token 已经锁到合约了，我现在跨回去的时候就把它 burn 掉。然后在 NEAR IBC 生成 IBC event 通知 relayer。relayer 再把成功的消息 relay 回另一侧的链的 IBC implementation 里面去。
如果 sendTransfer 检查失败或其他原因失败，程序还能执行的话，会执行 cancelTransferRequest，回调到 token 合约。因为之前只是预记账，如果知道要取消，就把锁在合约的 token 退还给用户。如果这里直接 panic，不能回调，就需要人工介入。但因为合约里有 transfer request 计数，所以可以处理退款。大概是这样处理。
这个流程因为是跨账户处理，所以引入了复杂度。但因为我们没有办法在一个 NEAR IBC 账户处理所有跨链资产，所以这个设计是必须的。
图 13这张图内容比较多，我简单介绍下流程。其实跟之前的流程类似，就是反过来了。这个流程是要把 NEAR 侧资产 transfer 到其他链，也需要一次性初始化。初始化出来的子合约用 Channel ID 标识。也就是要跟某个链做反向转账时，只要 channel 创建好，可以通过 Governance 做托管合约的初始化。
托管合约初始化后，还需要通过 Governance 注册资产到托管合约里。也就是 Register Asset For Channel。一个 Channel 可以转不同资产，需要把资产注册到托管账户里。最下面的序列是从 NEAR 发起的跨链转账，同样由 Token Holder 发起。它直接调用资产的 NEP-141 代币合约（这是独立账户管理资产）。这里需要调用 ft_transfer_call，这个函数有默认回调 ft_on_transfer。这时需要用户调用时指定回调是托管合约，然后标准的 fungible token 合约发起回调，告诉托管合约要转多少 Token 给谁。这里同样生成 transfer request，逻辑类似。相当于预记账，先记下要转给谁，调用 NEAR IBC 的 sendTransfer 接口，如果检查通过，再调用回托管合约，成功则 Apply，Apply 就是删除之前的预记账信息，相当于 Token 就锁到合约了。这个 Apply 只是删掉预记账信息。如果失败，可以调用取消，取消同样是删除预记账信息，退还锁定的 Token。如果这里 Panic，也需要后续人工处理。因为账户已做预记账，知道谁转过来的，就可以人工处理退款。
图 14最后这个流程比较简单，相当于从对侧链发起 Redeem，从 NEAR 转出的资产再转回 NEAR。同样，Relayer 把对端 IBC Event 转成 Packet Message，发到 NEAR IBC 合约里。它判断这是托管合约的某种资产，就会调托管合约的 doTransfer，把锁定的 Token 还给接收者。比较简单。
这就是 NEAR IBC 怎么通过跨账户实现 ICS20 的四个主要序列。我们看到四个流程实现不一样，实际流程也不同。这是因为智能合约平台自身设计引入的额外复杂度，需要我们在实现时处理。
最后简单谈谈 NEAR IBC 项目的愿景。这个项目还是希望做成公共基础合约，任何其他项目或开发者基于 IBC 做跨链桥时都可以 fork 使用。
图 15我们准备追加的 APP，第一个是 Octopus 2.0 必须做的 LPOS 实现。LPOS 跟 IBC 里的 CCV 模块类似，是共享安全方案，把 NEAR 上验证人数据通过 IBC 传到应用链。这需要最两侧的链做定制：NEAR IBC 需要增加 LPOS 模块，另外就是在 Cosmos SDK Appchain 模板里面集成支持 LPOS 的模块。
LPOS 跟 IBC 里的 CCV 都不是对等协议，有主链和子链之分。在这里，NEAR 是主链，应用链是子链，这不是对等协议，不像 ICS20。这个计划今年上线。
针对 LPOS，我们还会做 NEAR 上的 Restaking 合约，就相当于 validator 可以使用 NEAR 原生 Token 在我们的 Restaketing Base 合约里边去做 Restaking。也就是把 NEAR 质押到这个合约里边，然后通过这个合约去跟我们另外要做的 LPoS Market 合约去做交互。这个 LPoS Market 合约想要实现的一个主要功能，就是我们 1.0 里边实现的 Delegator 功能。这几个合约后续开发出来后会再找机会介绍。因为我们认为 Restaking 也是 NEAR 生态的重要创新之一。
其它模块现在看 Interchain Accounts 是想象空间最大的。它可以在 A 链账户和 B 链账户做绑定，在 A 链上交易，通过 interchain account 把请求转 B 链，用绑定的 B 链账户在 B 链生成一个具体交易，这是一个很有想象空间的功能。
NFT 转账与我刚才介绍的 ICS 20 的 Foundable Token Transfer 有些类似。在 NEAR 这侧如果要实现 NFT 转账，也需要通过我刚才提到的子账户的方式进行实现。
在之前介绍子账户时，我提到 transfer 子账户是一个占位符，是给 IBC/APP 这一层的应用预留的。以后如果我们需要实现 NFT 转账，我们会再创建一个 NFT Transfer 的子账户，在这个子账户下管理对应的跨链 NFT 资产。
这个子账户保留的一级是从中间件的角度考虑，中间件可以提供更好的兼容性和复用方式。
例如，IBC 规范里有 Fee Management，可以从用户那里获取给 Relayer 的奖励。因为 Relayer 没有激励机制，所以如果一个项目想自己运行 Relayer 需要承担成本。如果想构建一个公共网络，由其他链来当 Relayer，又因为没有激励，所以没有人愿意做这件事。
Fee Management 提出可以通过协议获得给 Relayer 的用户奖励。这显然是一个通用功能，不同的应用都可能需要。比如转账、NFT 转账等都需要用户支付手续费给 Relayer。所以 APP 需要一个可复用的机制。
于是中间件的想法被提出，在 IBC APP 层里加了一个 Middleware 层。在 Middleware 之上的 APP 只需要实现两个固定接口就可以与 Middleware 交互，从而集成 Middleware 的功能。这相当于是两个接口，也就是 APP 向 Middleware 输入消息，并从 Middleware 获取输出。实现这两个接口后，Middleware 内部的额外逻辑就被追加到整个流程中了。
这种方式可以提高复用性，大家如果感兴趣可以再看看 IBC 规范。
最后一个应用是 Atomic Swap，可以在不进行跨链的前提下，进行两个链上不同资产的交换。
如果没有 Atomic Swap，我们需要先把资产跨链，然后在另一链上兑换，兑换后再转回原链，过程复杂。Atomic Swap 通过锁定不同链上的资产，可以一步完成交换。用户只需要签一个交易。这为 DEX 带来更多可能性。
此外还有一些正在起草或设想中的模块就不详细说明了。上面介绍的都是我认为相对比较重要或有想象空间的模块。
我们做 NEAR IBC 是希望它能成为 NEAR 生态公共基础设施。有兴趣的朋友可以用这个合约或者 fork 它来搭建自己的跨链桥，增加自己的模块。这种开放协议的方式比封闭协议的方式显然更有潜力，也更能得到社区拥护。我们希望 NEAR IBC 成为 NEAR 生态有长期生命力的项目，会持续维护，给大家高质量代码。
今天分享到此结束，谢谢。
Q：一个问题，你说它因为 ICS 20 这样，它实际上已经可以做资产桥了。那么，章鱼这边会做资产桥吗？还是不准备实现?
A：会的，因为我们现在版本里已经包含了 ICS 20，所以上线的桥里一定会包含这个模块。
Q：就是说你会做一个公开的资产桥，对吧?
A：对，因为 NEAR IBC 合约它每个实例都包含一套账户逻辑，就是一个桥。我们自己会运行一个桥。这个桥主要功能还是要支撑我们自己的 APP，但如果单纯做资产跨链的桥，目前没有计划。但是我们自己的桥一定有资产跨链功能，就是支持这个功能。只不过因为桥是我们维护的，所以我之前也提到，要在桥上做资产跨链需要通过我们的治理流程决定。
Q：已经是公开可用的，对吧?
A：对，没错，只要治理同意开启这个功能，然后对端通道创建好，就是公共的，任何人都可以用。
Q：你们预计到 Cosmos 系列链的资产跨链时延是多少?
A：时延目前还没有实际生产环境的数据，但预计在分钟级别。
Q：说到时延问题，我问下你们桥未来和彩虹桥关系是什么样?能跟大家做个对比吗?
A：彩虹桥是独立的 Ethereum 到 NEAR 的桥。我们的主要目标是连接章鱼 Appchain 或者其他可能使用我们桥的 Cosmos 链，区别在这里，没有直接关系。
现场交流
有开启 IBC 的链理论上都可以接入里面，对吧。你之前说时延是分钟级别。我个人还是挺期待的，因为 IBC 现在异构链领域也提了不少方案，但都还在进行中，你们先做出来可以有很好的示范效应。因为 IBC 安全性比单链桥好多了，现在已经是共识，但还没有落地成工程标准。大家理论认可但没有实际看到，所以不承认。有人先做出来可以推进整个领域。我觉得可以申请 Grant，这工作量不小。而且 Cosmos 生态是 IBC 的天下，没有对手，把 IBC 扩展到各个角落的可能性非常大。所以我觉得你们这项工作非常关键，之前如 Polyman 他们做了一段时间后力度缓下来了，所以需要一个团队强力推进，示范效应一旦形成会非常好。因为 IBC 能力现在被严重低估，被按在地板上起不来。主要是以太生态的人不愿正视，其他生态又没看到这个能力。但从 Cosmos 生态整体看还是非常乐观的。
所以你们起头后，需要社区各方全力支持，无论是技术生态还是用户。我们可以继续跟基金会深化合作，你们也得到一些支持，后面也可以加大力度，我觉得 10 月前完成上线会有很好的示范作用。
Q：刚才你提到 EVM，如果未来通过桥，跟 EVM 打通，会是什么样的效果？
A：我们在 Octopus2.0 准备第一个 Cosmos 链，是一个社区链，名为 Ottochain，会支持 EVM。所以任何 solidity 生态项目都可以在 Ottochain 发展。
Q：它跟现在 EVM 兼容的链都是走跨链桥，走咱们这个跨链桥和一般的桥有什么区别？
A：这要看是独立链还是应用链。Ottochain 是 Octopus 2.0 的第一个应用链，需要 LPoS 模块，是 Cosmos SDK 链，会在链上支持 EVM。如果是一个独立链要接入 NEAR，目前只能用 IBC/TAO 和 ICS20。我们的桥上线后这种功能可以支持，一个独立链如果只想用 ICS20 也没问题，可以满足。
Q：计划 10 月份会上线吧？
A：对，10 月份上主网。
Q：相比目前其它跨链桥，你们的难点和区别在哪里？
A：比如很多 ZK 方案，它们链上验证都通过 Light Client，Relayer 中继时做 ZK 验证。
然后我们在引入的 Adaptive IBC 概念，支持 Solomachine Client，就是为我们的验证方案。简单说就是用 Solomachine 作为链上验证，而不是用对端链 Client。真正的验证客户端放在第三条公链上，用 Relayer 中继，两条链都用 Solomachine Client。这样可以完美配合其他的各种方案。这也是我们后续的工作重点。
Q：Cosmos 验证 Ethereum 难，反过来容易点吧？
A：反过来的问题是 Cosmos 链的 validator set 如果太大，验证 gas 就可能超限，就容易失败。
Q：之前提到给你们搭了框架后，会让更多 NEAR 开发者有应用开发机会，利用你们的技术架构，对吧？
A：这个项目开源的，任何人都可以 Build 新的 APP。我们会按自己规划先做，可能 Interchain Accounts 优先级更高，但还需要讨论，目前只确定了 LPOS 模块。
免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议。
| 往期精选 |
NEAR will be a Cosmos zone SOON
通过 Substrate-IBC 实现 Substrate 资产跨链
Louis 谈 dYdX “叛逃”以太坊
专用预言机 -- Substrate 应用链独有设计模式
【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。
