Substrate 入门 - 项目结构 （四）

本文经作者 金晓授权，转载自 https://zhuanlan.zhihu.com/p/98684002。

在开始讲解 Substrate 的内容之前，还需要补充一个当前 Substrate 的项目结构。之所以这里强调“当前”是因为 Substrate 从之前的结构到现在已经发生了巨大的变化，如果不重新再介绍一下，后续的文章介绍起来就会有一些麻烦。

笔者在一年前已经写过一个 Substrate 的项目结构《Substrate 设计总览 （二）》的介绍，但是截止目前项目的结构几乎已经全部变了。因此重新进行介绍。（在看本文前最好先了解了 Substrate 的设计总览：《Substrate 设计总览》）

本文所基于的 Substrate 提交为：a98625501be68cc3084e666497c16b111741dded，即 2019 年 12 月 21 日的提交。

本文首发于知乎专栏__金狗喵喵喵的区块链研习，版权属于@ 金晓。如需转载，需取得同意并标明出处，并涵盖版权信息！

core->primitives + client

以前的 core 目录包含了所有的链的功能模块的部分，也就是所谓的 Substrate 的框架主体内容。在现在的版本中，拆成了 primitives + client 两个部分。

其中：

• primitives：元语，赋予了新的含义，用于定义一条链中很多基础设置的模块。实际上这个归类也是比较笼统的，但是主要还是用来定义用的，举例来说：
  • primitives/core 中定义了密码学类型如 ed25519，sr25519 等，定了 hash，定义了 H160，H256，H512 等长度类型，
  • primitives/runtime 定义了“Runtime”中需要用到的基础类型，如区块头 Header，区块 Block，交易体 extrinisic，区块头附带的信息“digest”，“Runtime”编写过程中用到的一些基础工具，如错误处理 DispatchError，兼容多种类型签名的 MultiSignature，Runtime 中的随机数，交易合法验证，offchain 的一些类型定义等等
  • primitives/consensusSubstrate 提出的新共识的核心 aura，"babe"，以及“pow”的一些类型定义，注意这里只是一些定义以及对于 Runtime 的 api 接口，实现在 client/consensus 对应的模块下。
  • primitives/apiruntime 的 api 的工具宏定义
  • primitives/trie 对 MPT 的包装，MPT 见上文介绍，实现在 trie-db 这个库中
  • primitives/std 和 primitives/io 原来的 sr-std 和 sr-io，用于提供 Runtime 中的对于 wasm 编写的支持以及 runtime 访问 trie 的接口。
  • 等等内容

而对于另一个模块 client 而言：

• client 是对于很多模块的功能实现以及集成功能模块组件
  • client/api 就是对于 runtime api 调用包装的实现
  • client/consensus 是对共识模块的实现。
  • client/network 是对网络 p2p 的实现，底层使用 Libp2p
  • client/state-db 是对每个块提交到 MPT 的过程的管理
  • client/service 是对许多功能模块的集成，例如网络模块，交易池，rpc 等等，service 相当于启动了这些模块并持有这些模块的引用
  • client/cli 是对命令行的解析并根据相应的参数配置 service
  • 等等 ... 由于本系列主要是为了介绍使用 substrate，而不是讲解 substrate 怎么实现，所有就不必说的很细致了。

所以在今后的文章中介绍 primitives/client 即代表着这些是 Substrate 框架内的代码，若要修改，需要进行 forkps:（这是不严谨的说法，实际上也可以引用 primitives，自己实现 client，只所以这么说是因为 client 可以看做 Substrate 定义的基础结构的一种实现，当然可以独立进行另一种 client 的实现。但由于当前的 client 里面是一种实现，因此里面的模块都是互相关联的，很难只修改其中某个组件，如果需要沿用 Substrate 的实现但是需要修改其中的某些实现，那么只能 fork 修改了。）

srml -> frame

参见笔者之前的《Substrate 设计总览》与《Substrate 设计总览 （二）》，应该知道了 Runtime 的概念，与 Substrate 中实现 Runtime 的模块 srml （Substrate Runtime Module Library）。在新版中，srml 命名为了 frame。对于 frame 而言，模块之间没有很大的迁移，基本沿袭了原来的命名与结构，只不过新增了很多的 runtime module 模块。如理解了这两篇文章的内容，那么应该可以理解 frame 中除了“system”之外，都是可以由开发者自由实现的，实际上使用 Substrate 链编写的应用链的核心部分就是开发自己的 Runtime Module。编写自己的 Runtime Module 不会写的时候，就需要去模仿 frame 模块中这些模块的编写技巧。其中提供了很多最佳实现这类的东西。

node + node-template + subkey + 其他 -> bin

对于上文的 primitive，client 或者再加上 frame 中的 system 共同构成了 Substrate 的框架，而对于新版本中的 bin 则是对 Substrate 框架的使用案例（一种实现），因此 bin 中的内容就是 Substrate 的框架外的部分。在新版本中把原来的 node，node-template 等全部移动到了 bin 中，代表这些模块是可以进行“可执行文件”的入口。因此调试也好，研究数据流流转也好，都是从这个入口开始。所以在今后的文章中，介绍 bin 中的代码，即代表着这是使用者可以自由进行定制的部分，可参考 bin 中的一些组件进行修改。而 bin 中的案例即是如何把 runtime 和 service 组合在一起的案例。对于本系列而言，只用参考 node 的实现就够了，因为它的实现是最全面的。

更多该系列内容：

Substrate 入门 - 具备状态的链（三）

Substrate 入门 - 运行与调试 （二）

Substrate 入门 - 环境配置与编译（一）

Substrate 设计总览（三）

Substrate 设计总览（二）

Substrate 设计总览 (一)

扫码关注公众号，回复 “1” 加入波卡群

关注 PolkaWorld

发现 Web 3.0 时代新机遇

点个 “在看” 再走吧！