json檔案的chain spec
chainspec JSON是一個大的JSON物件，透過substrate build-spec命令生成。此命令透過引用節點的匯入runtime模組並查詢需要定義的公開配置來工作。這些將是空值或提供預設值。
本質上，runtime模組可以依賴於“創世配置”，換句話說，我們在區塊鏈首次初始化和構建其狀態時提供的配置。這一狀態是透過創世地塊-第一個生產的區塊鏈啟動的。chainspec json檔案的任務是定義這個初始狀態。
一旦生成，我們可以在執行節點之前開啟此chainspec chain並修改任何我們認為必要的值。
注意：如果我們的鏈寫了我們不再需要的狀態呢？也許我們已經更新了一個模組，或者任何鏈配置，並且想要反映來自Genesis塊的更改？我們可以清除鏈-刪除塊歷史-有效地重置節點。
您的節點為此提供了purge-chain命令，通常用於開發工作流：
# optional --dev flag to specify development chain
substrate purge-chain--dev
除此之外，框架還提供了三個預設的chain“spec”（pre-filled configurations），它們根據我們是執行節點進行測試還是生產目的來定義一些基本值。
實際上，預設情況下提供了三個spec：dev，local和staging：
dev spec是離實際用例最遠的規範，主要配置為幫助您使用鏈。我們為您提供了一系列帳戶，併為所有預打包的runtime模組提供了配置。
local spec類似於dev規範，在private network substrate教程中使用，由parity託管。假設您希望在本地測試多使用者場景，它會為多個帳戶提供“許可權”。
staging是一個更保守的規範，定義了有限數量的帳戶，並省略了特定於模組的配置。這是您在構建生產鏈時選擇的規範。
我們可以做的是使用substrate build-spec命令基於這些提供的選項之一構建新的chain spec，將結果輸出到單獨的檔案。如果我想複製我自己的鏈的開發chain spec，我可以執行以下命令，在我的主目錄中的新my-chianspec.json檔案中輸出規範：
substrate build-spec --chain=dev > ~/my-chainspec.json
在編輯器中開啟此檔案以檢視可用的配置選項。
注意：您可能希望摺疊genesis.system.runtime區塊，其中包含一個無法讀取的執行時區塊。
id欄位可以修改為您自己的名稱，以及名稱欄位，這是一個更易於理解的chain spec名稱。一些值得注意的常見選項包括：
遙測端點(Telemetry endpoints)：透過遙測端點為遙測服務提供端點。這將允許您使用已連線的節點填充UI，與Polkadot遙測不同。
在您的節點處理原生令牌的情況下，提供初始帳戶的餘額列表。
抵押配置（staking configuration）：鏈支援該功能。配置選項，如初始驗證器帳戶、驗證器和儲存變數。
最終，根據runtime包含的模組，還會有各種其他變數。幫助您熟悉chain spec檔案的建議方法是參考主substrate節點chain spec。
substrate build-spec --chain ~/chainspec.json --raw > ~/mychain.json
最後，為了執行我們的區塊鏈，我們提供了這種chain spec的substrate。從這裡我們將假設您正在執行自定義編譯的Substrate節點，我們將<node_path>替換為該節點的執行時。
<node_path> --chain ~/mychain.json --validator
注意：您的鏈開始生成區塊需要驗證者標誌。
接下來讓我們看看初始化和編譯自定義Substrate節點。
初始化substate節點
到目前為止，我們一直在使用透過安裝指令碼獲得的已編譯substrate節點。這對於測試開發鏈是非常友好的。但是它限制了我們引入自己的runtime模組和自定義配置。為此，我們需要下載substrate原始碼。
我們有兩種方法可以開始使用我們自己的定製substrate鏈：
1、下載易於配置的節點模板（例如，從第一部分完整安裝中下載的測試網節點模板，或特定供的Substrate Kitties節點）。
2、使用Substrate Scripts，下載官方節點模板，一個簡單的Substrate節點指令碼，其中包含準備好進行runtiem模板。我們可以使用我們之前安裝的Substrate Scripts來完成這項工作。
使用以下命令生成新節點模板：
// substrate-node-new <node_name> <author>
substrate-node-new my-node "Ross Bulat"
這可能需要一些時間，具體取決於您的系統 - 將獲取和編譯最新的Substrate原始碼。
完成後，節點的執行時現在可以透過lib.rs檔案在runtime/src資料夾中編輯。其中還包括一個runtime模組的模板，模板為template.rs。接下來我們將檢視一個runtime模組。
構建自定義節點
在節點目錄中，使用附帶的build.sh指令碼將節點編譯為wasm，然後使用cargo編譯binary檔案：
# build wasm
./scripts/build.sh
# build binary
cargo build --release
現在將在節點的./target/release/目錄中編譯節點。
在我們使用substrate呼叫特定於節點的命令的地方，我們現在可以參考我們新建的binary檔案，在我們的定製鏈上執行命令。要清除鏈並重新執行它，我們將使用binary檔案：
# clear chain state
./target/release/<node_name> purge-chain--dev
# run in dev mode
./target/release/<node_name> --dev
我們在這裡介紹的最後一個主題是runtime模組。讓我們探討它們是什麼以及如何將它們包含在Substrate節點中。
介紹substrate的runtime模組
什麼賦予Substrate實用性是一種通用的模組化結構，允許開發人員將功能插入其runtime，從而建立符合其要求的自定義區塊鏈。
注意：Substrate執行時的另一個術語是狀態轉換函式或STF。這實際上是執行塊的函式，導致區塊鏈發生狀態更改。
這些功能包稱為模組，或者更具體地說，是runtime模組。預先與Substrate一起打包的這些runtime模組系列共同形成了一個模組目錄，稱為substrate的runtime模組庫或SRML。
這些模組非常有用。它們為我們期望從其他區塊鏈框架獲得的一系列功能新增了功能，並且可以在github上瀏覽。讓這些模組隨時可用可以避免開發人員重新發明輪子——在實現了全新功能的地方，它們也可以作為runtime模組開發。
以下是一些可用的模組：
assets：為可替代資產提供支援的模組——想想ERC20代幣。
balance：為管理賬戶餘額提供支援的模組。
Staking：一個模組，提供管理網路維護者所關注資金的功能。
您會注意到，每個模組都被格式化為Rust crate，旨在匯入到Substrate runtime環境中。
每個SRML模組都會被打包起來，並在模組名稱前面加上srml_字首，每個模組都可以在Parity的crate庫的左側選單中找到。
模組結構概述
每個模組都在自己的src / lib.rs檔案中定義符合特定的結構。我們已經可以看到Substrate模組的高階特性：
模組可以定義為一個檔案、module-name.rs或更常見的lib.rs。模組還可以有其他支援檔案，通常都位於特定目錄中。
模組必須符合特定結構，依賴於特定substrate API。
這最後一點究竟意味著什麼？嗯，這取決於你的模組實際做了什麼。模組為區塊鏈提供了功能 - 我們已經知道了很多 - 但是這個功能可以以一系列元件的形式出現：
事件（event）：模組可以定義在滿足特定條件時要呼叫的自定義事件 - 當您製作新的不可替換的令牌時，可能是TokenCreated事件。事件包含在decl_event!marco：
decl_event!(
pub enum Event<T>
where
<T as system::Trait>::AccountId,
<T as system::Trait>::Hash
{
TokenCreated(AccountId, Hash),
}
);
儲存（storage）：模組可以定義要在鏈上持久化的資料結構，如對映、列表等。我們實際上可以儲存一系列資料型別，其中大部分都在這裡記錄。儲存項在decl_storage! macro：
decl_storage! {
trait Store for Module<T: Trait> as NFTStorage {
TokenToOwner get(token): map T::Hash => Token<T::Hash, T::Hash>;
TokenIndex get(get_token_by_index): map u64 => T::Hash;
TotalTokens get(total_tokens): u64;
...
}
}
Dispatchable函式：可以在runtime透過JSON RPC呼叫執行的公共函式。所有可排程函式都包含origin引數，其中包含有關函式呼叫源的資訊，例如呼叫者的公共地址和其他後設資料。
如果我們檢視Assets模組可排程函式，我們可以看到為我們定義了issue，transfer和destroy。可排程函式透過帳戶呼叫。我們將進一步使用特定工具管理帳戶。
public或private函式：模組可以提供可以從runtime環境中的任何位置呼叫的公共函式，以及只能在模組實現中呼叫的私有函式。這些都不是可排程的功能，例如它們無法透過JSON RPC協議從外部訪問，也不需要origin引數。
結構(Structs)：模組可以定義該模組可能需要的結構。例如可能會為用於跟蹤全球貨件的鏈定義ShipmentItem結構：
#[derive(Encode, Decode, Default, Clone, PartialEq)]
pubstructShipmentItem<Hash, Balance> {
id: Hash,
container_id: Hash,
price: Balance,
weight: u64
}
請注意，我們可以將其他型別引入結構中，就像我們在上面的示例中使用Hash和Balance一樣。
標準型別（如hash）在runtime原語庫中定義，但型別也通常在其他runtime模組中定義，在這些模組中我們引入了依賴關係的概念。
正如我們已經發現的，模組可以是crates，因此可以作為cargo.toml中的依賴項。這樣可以確保其他人依賴的模組不會丟失。
回到即插即用的模擬，模組定義了可在runtime內（執行）的可插入（匯入）功能，為您的鏈提供額外的功能。這個可插入的方面只是意味著將所需的模組宣告並匯入到Substrate執行時。
透過對substrate模組實際是什麼的概念性理解，讓我們使用substrate-module-new用程式來生成一個簡單的模組模板。
初始化新模組
與substrate-node-new程式一樣，我們還下載了一個substrate-module-new程式，它可以提供最新的模組模板供我們使用。
在節點runtime目錄中，使用以下命令準備新模組：
substrate-module-new <module_name>
讓我們用my-module的名稱來執行它。輸出將提示我們將模組新增到runtime / src / lib.rs檔案中：
cd runtime/src
substrate-module-new my-module
> SRML module created as ./my-module.rs and added to git.
> Ensure that you include in your ./lib.rs the line:
> mod my_module;
生成的檔案my module將與最初包含在目錄中的template.rs檔案相同。但是執行substrate module new是在事件模板中啟動新runtime模組的首選方法同時rs已被編輯。
總結
這篇關於substrate的介紹已經介紹瞭如何安裝框架，以及如何使用包含的工具來幫助部署自定義節點和模組。
我們使用了Polkadot JS程式，瞭解它如何作為Substrate管理實用程式工作，同時充當鏈資源管理器和管理器。該應用程式旨在提供通用功能，不會假設您的鏈支援什麼 - 應用程式的UI將根據您的chain spec和您在runtime定義的模組更新。
關於chain spec的主題，我們介紹瞭如何透過substrate構建規範生成規範JSON檔案，其內容將根據鏈的runtime將runtime模組而變化。還有三個預先配置的chain spec，用於填充開發或生產節點的規範。在編譯為原始狀態並與執行時一起使用之前，可以編輯chain spec。
