Substrate
區塊鏈系統可以分為兩部分：
- 區塊鏈基礎部分（core）
- 區塊鏈功能部分（runtime）
其中，區塊鏈基礎（core）一般由以下幾部分構成：
- 共識系統
- p2p連接與廣播系統
- 存盤系統
- 交易池系統
- RPC系統（也就相當于api，用于與外界互動）
而區塊鏈功能（runtime）有以下例子：
- 位元幣和以太坊1.0的記賬方式——UTXO
- 以太坊虛擬機，及智能合約系統，以太坊2.0的賬戶系統
- eos賬戶系統，及虛擬機
- 亂數，對賭……等等的各種功能
Substrate就是這樣一個區塊鏈框架，它將區塊鏈分為上面所說的兩部分：
- Substrate Core
- Runtime
根據這樣的劃分，當開發者使用Substrate框架的時候，無需關心區塊鏈基礎功能（也就是Core部分）的作業，只需關心自己鏈能夠提供的功能，也就是Runtime部分的作業，
虛擬機EVM也是Runtime的一個組件，與以太坊的結構相比，相當于把以太坊的智能合約功能也能隨意作為一個鏈的功能組件添加進入使用Substrate開發的鏈中，
由于Substrate將Runtime單獨抽離出來，Substrate實作了經典區塊鏈都無法實作的unique功能：區塊鏈系統升級，
區塊鏈版本升級是一件非常復雜的事情，首先需要社區/開發者提出，將升級方案廣播給每一個區塊鏈上的網路節點，再由每個網路節點自行選擇是否認可，進行升級，而如果有一定數量（小于拜占庭容錯）的節點出現分歧，則會在區塊鏈上產生硬分叉，將導致這些節點上運行著不同的區塊鏈版本，而如果大部分節點都不支持升級，則可能導致社區分裂等更嚴重的問題，
并且，當一個區塊鏈系統升級后，開發者不得不在代碼中進行許多重復的“區塊高度判斷”，以區分不同高度下運行的代碼版本，兼容舊版本資料，保證區塊鏈節點的同步能夠正常執行，
這種做法很原始但是又無法繞開，給開發者帶來極大的思維負擔，且需要大量的測驗來保證不出現Bug，比如目前位元幣的原始碼中就有許多的區塊高度判定使得在同步老區塊的時候執行老代碼，新區塊的時候執行新代碼，
Substrate的出現完美的解決了這個區塊鏈升級的問題，其采用模塊化思想，將Runtime作為一個單獨的組件，一個以wasm（WebAssembly）形式存在并運行的“鏈上代碼”，
簡單來說，Runtime在Substrate框架下，將會用同一份代碼編譯出兩份可執行檔案：
一份Rust的本地代碼，我們一般稱為native代碼，native與其他代碼無異，是這個執行檔案中的二進制資料，直接運行，在Substrate的相關代碼以native命名
一份wasm的鏈上代碼，我們一般成為wasm代碼，wasm被部署到鏈上，所有人可獲取，wasm通過構建一個wasm的運行時環境執行
，在Substrate的相關代碼以wasm命名在節點啟動的時候可以選擇執行策略，使用native
possible，wasm或者both，不同的執行策略會執行不同的執行檔案，這部分后續以后的文章詳細描述，由于這兩份代碼是由相同的代碼編譯出來的，所以其執行邏輯完全相同
(有一些很小的暗坑要注意)，其中wasm將會部署到鏈上，所有人都可以獲取到，也就是說即使本地運行的不是最新版本的節點，只要同步了區塊，一定可以獲取到最新的wasm代碼，換句話說，一個寫在Runtime內部的代碼，也就是代表這條鏈功能性的代碼，存在兩份，分別是native與wasm，wasm代碼被部署到鏈上，是“鏈上資料”，可以通過同步區塊所有人統一獲取并執行，這樣就可以保證在區塊鏈中所有礦工執行的都是最新的代碼，
ps:這里需要強調，代碼的部署可以通過“民主提議”，“sudo控制權限”，“開發者自定一種部署條件”等方式進行，到底哪種方式“更區塊鏈”，“更合理”，不在本文討論范圍內，這與這條鏈的設計目的相關，Substrate只是提供了這種“熱更新”的強大機制，如何使用這種機制是這條鏈的問題，
總而言之，使用wasm進行區塊鏈升級絕對是一個全新的思路，
由此可見，由于wasm代碼的存在，可以保證即使節點沒有更新到最新版本，仍然能夠以最新的代碼運行，保證不會因為代碼的不同而分叉，同時在節點同步老資料的程序中也不會因為本地代碼是最新的而導致同步出錯，
本文參考內容來自：https://zhuanlan.zhihu.com/p/56383616
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/286821.html
標籤：區塊鏈