如上可以看到，这些不足主要是 Substrate 的设计目标——通用——本身带来的客观依赖复杂性造成的。

　　瑕不掩瑜，作为目前为止最强的区块链开发框架之一，Substrate 受到了越来越多创新团队的欢迎，Compound 团队选择 Substrate 进行 Gateway 的开发也就顺理成章了。

　　从架构图可以看到，Substrate有如下几大组件：

• 　　P2p Networking P2p网络

• 　　Runtime 运行时

• 　　Storage 存储

• 　　Consensus 共识

• 　　RPC 远程过程调用

• 　　Telemetry 客户端监测工具

　　P2p网络，是区块链系统必备的子系统。多个节点通过 p2p 连接成组成同一个网络。在节点与节点之间发消息传递数据，网络中的消息传播有可能通过多个中继节点传播后到达。在Substrate 中，使用的是 rust-libp2p（https://github.com/libp2p/rust-libp2p），此项目也主要是由 Paritytech 在负责维护。

　　Runtime，运行时，是区块链业务逻辑的实现部分。也就是说要用区块链干什么实际的事，就需要写在这里面。Substrate 支持将 Runtime 代码编译成 wasm 字节码或 native code 两种模式运行（随着 wasm vm 运行速度的提升，未来 native code 模式可能会被抛弃，这也能降低一些内部复杂性）。在 Runtime 中可以操作 Storage，实现状态的变更，因此 Runtime 整体也被称作状态转移函数（State Transition Function, STF）。

　　Storage，存储子系统，是区块链系统中不可缺少的组成部分。在 Substrate 中，Storage 用于持久化 Runtime 的逻辑对状态的变更，同时也支持对外的 RPC 状态读取接口，Runtime 中的 Event 在发出前，也会在 Storage 中做短暂的存储。共识系统的目标，也是对 Storage 中的状态达成一致。Storage 子系统在底层用的是kv数据库 rocksdb 或 paritydb。

　　Consensus，共识子系统，用于在网络的参与方之间就区块链的状态达成一致，也就是“共识”。由于是分布式系统，所谓区块链的状态，并没有一个宏观的上帝视角能看到一个统一的宏观状态。这个状态，其实就是各个节点的状态，每个节点有自己的本地状态视图，也有一个“局部”的全局视图。每个节点通过本地视图与全局视图的比对，做出决策。共识系统要在各个节点上达成一个一致的状态，从而推动系统往前运行。

　　RPC，远程过程调用，用于向节点外部提供访问的接口。一个 Substrate node 本身可以作为一个服务而存在，外界可以通过这些 rpc 接口访问 node 的本地状态信息或向 node 提交变更请求。Substrate 同时提供 HTTP 和 Websocket 两种 rpc 通道。 (责任编辑：admin)