而往往我们需要与 Runtime 中的状态进行交互，这时就需要用到 Runtime API 了。Runtime API 是 Runtime 内与外的桥梁，也可以说是链上与链下的桥梁。

　　于是 RPC 与 Runtime API 组合起来，就可以将外部请求发起到获取链上状态的流程全部打通。配合自定义的 Runtime API 功能和 RPC 扩展接口功能，给予了开发者巨大的灵活性和可能性。也为 Substrate 成为一个一体化集成式的 Web3.0 开发框架打下基础。

　　为了搞清楚 Gateway 是如何使用 Substrate 的，我们直接拉它的源代码下来简要分析一番。

　　git clone https://github.com/compound-finance/gateway

　　cd gateway && ls

　　可以看到，有如下主要目录（我们加了简要注释）。

　　ethereum/ 以太坊上的 Starport 合约代码

　　ethereum-client/ 以太坊相关类型定义和基础工具函数

　　gateway-crypto/ Gateway 用到的密码相关的基础工具函数

　　integration/ 集成测试代码

　　node/ Substrate 的自定义 node 代码

　　our-std/ Gateway 的 std 代码，是对 sp_std 的简单封装，并添加了一点额外的东西

　　pallets/ Gateway 独立链的主体业务逻辑代码

　　runtime/ Substrate 的运行时构建代码

　　types-derive/ Gateway 用到的类型相关过程宏

　　可以看到，目前 Gateway 只实现了到 ethereum 的 startport 连接，其它链的对接还在开发中，会逐渐加入。

　　主体业务代码在 pallets/ 目录下，此目录下有三个子目录。

　　cash/ 主体业务逻辑

　　oracle/ 从喂价机获取价格的代码

　　runtime-interfaces/ 一些运行时接口

　　我们从 pallets/cash/src/lib.rs 看起。这是一个标准的 pallet 文件，其结构有

• 　　trait Config 的定义

• 　　decl_storage! 定义链上存储部分

• 　　decl_event! 定义事件输出部分

• 　　decl_module! 定义模块实现部分

　　在模块实现部分中，有 fn offchain_worker(block_number: T::BlockNumber) {} 这个函数。其实现主要是这两个函数调用：

　　internal::events::track_chain_events::

　　internal::notices::process_notices::

　　我们知道，Substrate 的 offchain_worker 入口，是在每个块导入本地状态数据库时调用。也即 fn offchain_worker(block_number: T::BlockNumber) 这个函数会被每个块驱动执行，每个块执行一次这个函数。因此，每增长一个块，上面的代码会分别处理 events 和 notices 这两块内容，而这两块内容的代码在 internal 模块中定义。

　　继续追踪 pallets/cash/src/internal/events.rs 和 pallets/cash/src/internal/notices.rs 文件后，可以整理出大体的逻辑要点：

• 　　Offchain_worker 每个块调用一次 (责任编辑：admin)