戰(zhàn):無分叉升級與pallet模塊化設(shè)計)
1. 為什么我在2024年選擇Substrate搭鏈而不是從零開發(fā)或直接fork其他鏈1.1 先說結(jié)論Substrate解決的是“業(yè)務(wù)鏈長期演進(jìn)”這件事我大概從2023年下半年開始密集評估區(qū)塊鏈底層方案當(dāng)時接了一個偏業(yè)務(wù)性質(zhì)的項(xiàng)目要把一套存證確權(quán)加積分流轉(zhuǎn)的邏輯搬到鏈上同時又要保證后續(xù)能不斷加新功能而不是上線即凍結(jié)。評估了一圈之后最后選定了Substrate這個決定到今天回看依然不后悔。Substrate給我的第一印象是它特別不像傳統(tǒng)意義上的“公鏈代碼庫”。Parity Team維護(hù)的這套框架本質(zhì)上是把區(qū)塊鏈公共組件——存儲、P2P網(wǎng)絡(luò)、共識、交易隊(duì)列、運(yùn)行時執(zhí)行環(huán)境——全部模塊化讓你能用搭積木的方式快速產(chǎn)出一條鏈。它不是一個給你“現(xiàn)成產(chǎn)品”的項(xiàng)目而是一套“生產(chǎn)工具”。這也是為什么很多團(tuán)隊(duì)會用“Substrate搭一條鏈”而不是“抄一份鏈代碼”來形容這個過程。不過我在這里要強(qiáng)調(diào)一點(diǎn)選Substrate不等于選Polkadot。雖然兩者關(guān)系緊密但Substrate可以獨(dú)立使用你可以跑出完全屬于自己的單鏈不接Polkadot中繼鏈不用Polkadot的代幣經(jīng)濟(jì)模型。這一點(diǎn)對內(nèi)部項(xiàng)目、聯(lián)盟鏈、私有業(yè)務(wù)鏈特別友好。很多人誤以為用了Substrate就要發(fā)幣、接波卡生態(tài)事實(shí)上完全可以切成 solo chain 模式自由度高得多。我最終敲定用Substrate核心原因是三個第一鏈上升級不需要硬分叉第二業(yè)務(wù)邏輯以pallet形式拆分模塊間邊界清晰第三Rust實(shí)現(xiàn)的性能和工程化成熟度在區(qū)塊鏈框架里屬于第一梯隊(duì)。接下來這幾段我會圍繞這三點(diǎn)展開把這些年的實(shí)踐過程記錄下來也給想入坑Substrate的朋友一些能直接用的經(jīng)驗(yàn)。1.2 為什么我堅決排除了“從零開發(fā)”和“fork一條現(xiàn)成鏈”先說從零開發(fā)。區(qū)塊鏈最麻煩的不是鏈本身而是那些容易被忽略的周邊網(wǎng)絡(luò)層、序列化、密碼學(xué)、存儲引擎、共識協(xié)議、P2P同步、交易池。真要自己寫光是把區(qū)塊同步和雙花防護(hù)做對就足夠燒掉大半年人力。而且即便你把主線功能跑通了安全性驗(yàn)證又是另一座山。業(yè)務(wù)團(tuán)隊(duì)真正需要的是把業(yè)務(wù)邏輯放在鏈上而不是花一年時間證明你的共識實(shí)現(xiàn)沒有bug。也有團(tuán)隊(duì)喜歡直接用EVM兼容鏈比如fork一份geth或者基于某種現(xiàn)成鏈改。這個方案對“純智能合約”的業(yè)務(wù)確實(shí)省事但如果業(yè)務(wù)上需要自定義密碼學(xué)、自定義存儲結(jié)構(gòu)、自定義共識規(guī)則、自定義出塊邏輯你會發(fā)現(xiàn)智能合約抽象限制非常多。最典型的問題是合約只能跑在沙箱環(huán)境里訪問不到鏈層狀態(tài)定價、存儲模型、手續(xù)費(fèi)機(jī)制都受制于底層實(shí)現(xiàn)能做定制化的空間非常有限。這種時候Substrate的“framework”定位就顯得非常合適。它把最復(fù)雜的底層封裝好了同時把業(yè)務(wù)層徹底開放給你。你沒必要關(guān)心P2P網(wǎng)絡(luò)細(xì)節(jié)但你有權(quán)決定一條交易怎么處理、一個存儲項(xiàng)怎么組織、一個區(qū)塊的weight怎么計算。用我們工程上的話講它把“可替換部分”和“不可替換部分”分得很清楚。1.3 Substrate最打動我的是哪三個設(shè)計先說無分叉升級。傳統(tǒng)鏈一旦部署邏輯代碼就凍結(jié)在創(chuàng)世區(qū)塊里想改業(yè)務(wù)邏輯只能通過硬分叉協(xié)調(diào)全節(jié)點(diǎn)升級。而Substrate把鏈的“業(yè)務(wù)邏輯”放進(jìn)了RuntimeRuntime是一個Wasm blob存在鏈上。于是升級變成了一次普通鏈上調(diào)用只要治理機(jī)制通過調(diào)用set_code就可以換上新的Runtime邏輯普通節(jié)點(diǎn)會自動同步到新區(qū)塊并執(zhí)行新邏輯。聽起來像魔法但它就是這么運(yùn)作的。對一個需要持續(xù)迭代的業(yè)務(wù)系統(tǒng)來說這個能力可以說是“續(xù)命”級別的。第二點(diǎn)是pallet機(jī)制。pallet可以理解成Substrate里的“業(yè)務(wù)模塊插件”一個存儲定義、一組事件、一組調(diào)用函數(shù)打包成一個獨(dú)立的Rust模塊。Substrate官方提供了幾十個pallet比如Balances、Staking、Session、Sudo、Treasury業(yè)務(wù)上排名靠前的社區(qū)也都貢獻(xiàn)了。自己的業(yè)務(wù)邏輯只要照著pallet的規(guī)范寫就能像插USB設(shè)備一樣把它集成進(jìn)Runtime。模塊內(nèi)部可以獨(dú)立測試模塊間還可以用Config接口做依賴解耦工程體驗(yàn)非常舒服。第三點(diǎn)是共識的可插拔性。Substrate支持Aura、Babe、Grandpa、PoW等多種共識方案還能混合使用。我在項(xiàng)目初期用Aura加Grandpa跑后面切到Babe加Grandpa做更復(fù)雜的出塊策略整個切換并沒有傷筋動骨。對業(yè)務(wù)場景來說有好幾種共識選項(xiàng)兜底就不用被鎖死在某一種設(shè)計上。2. Substrate核心設(shè)計拆解Runtime、FRAME和pallet是如何協(xié)作的2.1 節(jié)點(diǎn)殼與Runtime先分清“外面”和“里面”Substrate的架構(gòu)我習(xí)慣用“殼”和“核”來理解。殼就是節(jié)點(diǎn)客戶端負(fù)責(zé)網(wǎng)絡(luò)同步、交易池、數(shù)據(jù)庫存儲、RPC接口和共識引擎等外部工作。核心則是Runtime也就是鏈上狀態(tài)機(jī)的業(yè)務(wù)規(guī)則它被編譯成Wasm字節(jié)碼后被節(jié)點(diǎn)加載執(zhí)行。節(jié)點(diǎn)殼和Runtime之間通過一套Host接口通信比如讀寫鏈上存儲、調(diào)用指定函數(shù)等。這種“殼核分離”最大的好處是Runtime升級后節(jié)點(diǎn)客戶端完全不需要重新編譯。舊的節(jié)點(diǎn)只需同步新的Runtime Wasm并通過執(zhí)行環(huán)境運(yùn)行新的業(yè)務(wù)邏輯即可。也就是說你不用催促全網(wǎng)節(jié)點(diǎn)手動升級軟件業(yè)務(wù)升級就能生效。這在整個區(qū)塊鏈系統(tǒng)設(shè)計里就是顛覆性的思路。從開發(fā)視角看Runtime代碼不直接跑在物理CPU上而是通過Wasm解釋器或JIT執(zhí)行。這意味著你不僅不能用標(biāo)準(zhǔn)庫里的std能力連浮點(diǎn)數(shù)都要小心不同Wasm運(yùn)行時對浮點(diǎn)運(yùn)算的舍入行為可能不同。這也是為什么Substrate的pallet源碼里文件開頭經(jīng)常能看到#![cfg_attr(not(feature std), no_std)]這樣的聲明。它告訴編譯器當(dāng)作為鏈上Runtime編譯時不要鏈接標(biāo)準(zhǔn)庫只用core子集。2.2 FRAME用宏把業(yè)務(wù)代碼變成鏈上模塊FRAME是Substrate上最常用的一套Runtime構(gòu)建框架它通過一系列過程宏procedural macro來批量生成樣板代碼。你只需要寫業(yè)務(wù)關(guān)心的部分比如存儲項(xiàng)、事件、調(diào)用函數(shù)、錯誤類型其余的模塊注冊、事件分發(fā)、存儲讀寫接口宏都會幫你生成。舉個例子在Substrate上寫一個“篡改審計”pallet最核心的代碼大概分為這么幾塊#[pallet::config]定義pallet對外需要的配置項(xiàng)和依賴的類型比如事件類型、外部賬戶類型。#[pallet::storage]定義鏈上存儲結(jié)構(gòu)可以用StorageValue存單個值StorageMap存鍵值映射StorageDoubleMap存雙層映射。#[pallet::event]定義業(yè)務(wù)事件比如“某賬戶寫入了一條存證”。#[pallet::call]定義可被外部觸發(fā)的函數(shù)即鏈上業(yè)務(wù)接口。#[pallet::error]定義業(yè)務(wù)錯誤類型方便調(diào)用方理解失敗原因。這個模式對后端工程師來說很友好因?yàn)楸举|(zhì)上它就像寫一個面向接口的Rust服務(wù)只不過持久化層由Substrate的存儲封裝好了并發(fā)安全也由Runtime執(zhí)行環(huán)境保證了。你基本不用考慮數(shù)據(jù)庫事務(wù)問題因?yàn)槊看握{(diào)用函數(shù)要么完整執(zhí)行成功要么結(jié)果全部回滾——和數(shù)據(jù)庫事務(wù)的原子性一個道理。2.3 無分叉升級為什么能改變鏈的運(yùn)營方式傳統(tǒng)項(xiàng)目的升級流程是發(fā)版、協(xié)調(diào)全節(jié)點(diǎn)、等待社區(qū)跟進(jìn)、切到新邏輯。Substrate只要求你有合適的“鏈上治理”流程。一個常見的實(shí)踐是用Sudo pallet設(shè)一個超級管理員賬戶來調(diào)用set_code完成Runtime替換。更成熟的做法是用Democracy pallet組織鏈上投票票數(shù)通過后自動執(zhí)行升級。我在實(shí)際項(xiàng)目中早期用的是Sudo模式因?yàn)閳F(tuán)隊(duì)還在快速迭代每天可能升級兩三次。等業(yè)務(wù)穩(wěn)定后再引入多簽治理或民主投票機(jī)制。這里有個經(jīng)驗(yàn)升級前一定要備份鏈上狀態(tài)并且在小范圍測試網(wǎng)絡(luò)里演練一遍全套升級動作。雖然Substrate升級本身是“輕量”的但你的業(yè)務(wù)數(shù)據(jù)遷移邏輯如果寫成鏈上函數(shù)那它有bug同樣會讓整條鏈進(jìn)入不健康狀態(tài)。升級方案簡單不等于可以不做預(yù)案。另外升級時還要注意Runtime版本號的維護(hù)。Substrate在Runtime中有一個RuntimeVersion結(jié)構(gòu)包含specific_version、impl_name、authoring_version等字段。這些字段不只是抬顯客戶端會依據(jù)它們判斷是否需要執(zhí)行狀態(tài)遷移State Migration。版本號不更新可能導(dǎo)致升級后舊節(jié)點(diǎn)無法同步新邏輯或者客戶端直接從緩存里返回舊版本這種坑很隱蔽。3. 從零搭建并運(yùn)行第一條Substrate鏈環(huán)境準(zhǔn)備與工程結(jié)構(gòu)3.1 Rust工具鏈和Wasm編譯目標(biāo)Substrate開發(fā)基本綁定Rust所以第一步是裝好Rust工具鏈。我是用rustup管理的因?yàn)樵赟ubstrate項(xiàng)目里經(jīng)常需要切換stable和nightly工具鏈。Substrate本身要求nightly版本編譯Runtime原因是部分宏和編譯器特性還沒有完全穩(wěn)定到stable。我這里給一份安裝流程直接復(fù)制粘貼可以跑curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh rustup default stable rustup toolchain install nightly-2024-03-01 rustup target add wasm32-unknown-unknown --toolchain nightly-2024-03-01注意后面的版本號建議你打開Substrate官方倉庫的rust-toolchain.toml確認(rèn)推薦的nightly版本不要隨意裝最新。因?yàn)镽ust編譯器偶爾有回歸Substrate生態(tài)里最穩(wěn)妥的做法是鎖定官方驗(yàn)證過的某一天版本。我吃過一次虧用了一個很新的nightly結(jié)果編譯Wasm時報了一堆宏展開錯誤后來回退到官方指定版本就好了。裝完工具鏈后還需要安裝一些系統(tǒng)依賴比如Ubuntu上需要clang、libssl-dev、protobuf-compiler。這些主要是編譯節(jié)點(diǎn)二進(jìn)制和生成RPC代碼需要的。如果是macOS一般只需要確保Xcode Command Line Tools裝好。3.2 用node-template快速起項(xiàng)目初始化項(xiàng)目建議直接用官方模板省去自己配構(gòu)建腳本的時間。Substrate官方維護(hù)了幾個模板倉庫最簡單的是substrate-node-template。clone下來后目錄結(jié)構(gòu)里最關(guān)鍵的是pallets目錄和runtime目錄前者放業(yè)務(wù)pallet后者負(fù)責(zé)把pallet組合成完整的鏈。git clone -b latest --depth 1 https://github.com/substrate-developer-hub/substrate-node-template cd substrate-node-template cargo build --release首次編譯會非常久我印象中在一臺8核的機(jī)器上要半小時以上主要是在編譯幾百個依賴項(xiàng)目。如果你只是想快速驗(yàn)證可以先用cargo check來檢查代碼能不能過編譯速度會快很多。真正需要跑節(jié)點(diǎn)的時候再執(zhí)行release編譯。編譯完成之后模板里自帶了一個最簡單的runtime包含Balances、Sudo、Template pallet等初始模塊。它默認(rèn)跑的是dev配置開發(fā)者不需要配置創(chuàng)世驗(yàn)證者就能直接啟動。3.3 啟動節(jié)點(diǎn)和前端調(diào)試臺的完整過程本地啟動節(jié)點(diǎn)很簡單./target/release/node-template --dev --tmp--dev表示單節(jié)點(diǎn)開發(fā)模式--tmp表示臨時存儲重啟后數(shù)據(jù)清空。跑起來后你會看到終端持續(xù)打印出塊日志說明節(jié)點(diǎn)已經(jīng)開始出塊了。這時候需要有前端工具來交互。官方提供了substrate-front-end-template它基于React和polkadot.js API用起來非常方便git clone -b latest --depth 1 https://github.com/substrate-developer-hub/substrate-front-end-template cd substrate-front-end-template yarn yarn start啟動前端后它會默認(rèn)連接本地節(jié)點(diǎn)的ws://127.0.0.1:9944。你可以在頁面上查余額、發(fā)交易、調(diào)用runtime的extrinsic還能看鏈上事件和存儲的變化。這個工具在調(diào)試階段幾乎是必需品因?yàn)楹芏喙?jié)點(diǎn)日志不會暴露的狀態(tài)變化在它上面一眼就能看到。我第一次跑通的時候其實(shí)有點(diǎn)驚訝于整個體系的成熟度一個空模板就能讓你直接在瀏覽器里操作鏈上狀態(tài)后面寫業(yè)務(wù)pallet時每次新增一個extrinsic前端模板幾乎不需要改動就能調(diào)用到。這對團(tuán)隊(duì)里不熟Rust的同事非常友好他們可以用前端快速驗(yàn)證功能。4. 手寫第一個業(yè)務(wù)pallet從需求到鏈上邏輯落地4.1 先設(shè)計業(yè)務(wù)再寫存儲存證場景的建模過程業(yè)務(wù)pallet聽起來高大上但落到代碼層面其實(shí)就是把業(yè)務(wù)規(guī)則翻譯成“存儲 調(diào)用函數(shù) 事件”。我在第一個實(shí)戰(zhàn)項(xiàng)目里寫的是一個簡單的存證pallet用戶提交數(shù)據(jù)的哈希值鏈上保存哈希、提交賬戶和提交時間任何人可以驗(yàn)證某條數(shù)據(jù)在某個時間點(diǎn)已經(jīng)存在過。存儲設(shè)計很直接我用的是一張StorageMap#[pallet::storage] #[pallet::getter(fn evidence_digest)] pub type EvidenceStoreT: Config StorageMap_, Blake2_128Concat, Vecu8, (T::AccountId, BlockNumberForT);存儲結(jié)構(gòu)里digest是值賬戶和塊號用來記錄提交者和提交時間。之所以用Blake2_128Concat哈希key是因?yàn)樗m合隨機(jī)key分布且能提供部分key信息避免遍歷時的額外成本。設(shè)計存儲時一定要想清楚未來會不會按某個維度查詢會不會有刪除操作會不會有數(shù)據(jù)增長上限存證場景數(shù)據(jù)只增不減所以我沒有做清理邏輯后續(xù)如果擔(dān)心膨脹再通過鏈上治理加一個歸檔機(jī)制即可。4.2 代碼落地存儲、事件、錯誤與調(diào)用函數(shù)pallet的核心代碼我盡量寫得精簡實(shí)際開發(fā)時可以按自己風(fēng)格組織。下面是我項(xiàng)目里一個簡化版的核心邏輯#![cfg_attr(not(feature std), no_std)] pub use pallet::*; #[frame_support::pallet] pub mod pallet { use frame_support::pallet_prelude::*; use frame_system::pallet_prelude::*; #[pallet::config] pub trait Config: frame_system::Config { type RuntimeEvent: IsTypeSelf as frame_system::Config::RuntimeEvent; } #[pallet::pallet] #[pallet::generate_store(pub(super) trait Store)] pub struct PalletT(_); #[pallet::storage] #[pallet::getter(fn evidence_digest)] pub type EvidenceStoreT: Config StorageMap_, Blake2_128Concat, Vecu8, (T::AccountId, BlockNumberForT); #[pallet::event] #[pallet::generate_deposit(pub(super) fn deposit_event)] pub enum EventT: Config { EvidenceStored { who: T::AccountId, digest: Vecu8, block: BlockNumberForT }, } #[pallet::error] pub enum ErrorT { ExistingEvidence, } #[pallet::call] implT: Config PalletT { #[pallet::weight(10_000)] pub fn store_evidence( origin: OriginForT, digest: Vecu8, ) - DispatchResult { let who ensure_signed(origin)?; ensure!(!EvidenceStore::T::contains_key(digest), Error::T::ExistingEvidence); let block frame_system::Pallet::T::block_number(); EvidenceStore::T::insert(digest, (who.clone(), block)); Self::deposit_event(Event::EvidenceStored { who, digest, block }); Ok(()) } } }這個調(diào)用的邏輯就是標(biāo)準(zhǔn)的三步確認(rèn)調(diào)用者身份、檢查數(shù)據(jù)是否重復(fù)、寫入存儲并發(fā)出事件。事件在Substrate里不只是日志它是客戶端追蹤鏈上變化的主要途徑所以業(yè)務(wù)上重要動作一定要發(fā)出事件方便前端和索引服務(wù)監(jiān)聽。有兩點(diǎn)是新手容易漏的。第一是ensure_signed如果沒有這一步任何人都能以無簽名方式調(diào)用這個函數(shù)安全模型直接崩掉。第二是存儲key的哈希方式我選的是Blake2_128Concat如果業(yè)務(wù)key本身有規(guī)律切忌用Twox64Concat那個哈希強(qiáng)度弱容易被人為制造碰撞。4.3 集成進(jìn)Runtime并跑通測試pallet寫好后要把它“插”進(jìn)runtime主要改兩個文件。一個是runtime/src/lib.rs需要在construct_runtime!宏里注冊模塊同時給pallet配置Config接口impl pallet_evidence::Config for Runtime { type RuntimeEvent RuntimeEvent; }然后是construct_runtime!宏中添加一行Evidence: pallet_evidence,編譯完成后用前面提到的前端模板就能看到新增的evidence.storeEvidence調(diào)用。首次集成時如果報錯多半是Config接口的類型沒對齊尤其是RuntimeEvent和RuntimeOrigin這兩個關(guān)聯(lián)類型很多新手在這里卡住。其實(shí)它們都是編譯期檢查只要根據(jù)編譯器提示逐項(xiàng)補(bǔ)齊就行。測試方面Substrate推薦在pallet內(nèi)建單元測試用sp_io::TestExternalities模擬運(yùn)行時環(huán)境。一個最簡單的測試是先創(chuàng)建測試外部環(huán)境用new_test_ext()初始化存儲然后調(diào)用store_evidence斷言事件是否正確發(fā)出。寫測試的過程本身也是在加深對pallet執(zhí)行流程的理解。這里我多說一句不要跳過測試就急著上鏈。鏈上邏輯一旦部署很難像傳統(tǒng)服務(wù)那樣隨便回滾。pallet級別的mock測試成本很低但能擋掉大部分低級錯誤比如存儲key寫錯、事件類型不匹配、權(quán)限校驗(yàn)缺失??蚣芗壍臏y試工具已經(jīng)給你準(zhǔn)備好了不用白不用。5. 鏈級定制與升級實(shí)操共識、創(chuàng)世配置和鏈上升級5.1 不同共識方案的取舍Aura、Babe與Grandpa怎么選Substrate的一個優(yōu)勢就是共識可插拔。實(shí)際開發(fā)中我遇到過三種情況正好對應(yīng)三種常見選擇。第一種是內(nèi)部開發(fā)鏈或測試鏈驗(yàn)證者少、可信度高直接用Aura最省事。Aura就是輪流出塊每個驗(yàn)證者按照名單順序依次生產(chǎn)區(qū)塊邏輯簡單延遲低調(diào)試也很直觀。第二種是公鏈或半去中心化鏈希望出塊更均勻、抗惡意驗(yàn)證者那就用Babe作為出塊引擎。Babe通過VRF隨機(jī)選擇出塊者每個slot可能有多個候選也可能一個都沒有所以通常還要配合延遲出塊機(jī)制來提高穩(wěn)定性。它的代碼復(fù)雜度比Aura高一截但更貼近真實(shí)公鏈的生態(tài)預(yù)期。第三種是所有鏈都必須搭配的確定性終結(jié)工具Substrate里常見的是Grandpa。Babe或Aura負(fù)責(zé)“出塊”Grandpa負(fù)責(zé)“最終確認(rèn)”。只有Grandpa確認(rèn)過的區(qū)塊才不可回滾。所以一般配置是“Aura/Babe Grandpa”組合單獨(dú)只跑Babe或Aura是不完整的因?yàn)闀媾R鏈分叉時無法確定哪條是規(guī)范鏈的問題。我在模板里看到默認(rèn)配置就是Aura Grandpa作為起步非常合理。如果團(tuán)隊(duì)目標(biāo)不是做公鏈完全可以只用Aura單節(jié)點(diǎn)甚至跑一個“許可網(wǎng)絡(luò)”——只有通過驗(yàn)證的節(jié)點(diǎn)才能參與共識這在企業(yè)場景里很常用。5.2 創(chuàng)世配置與本地多節(jié)點(diǎn)組網(wǎng)節(jié)點(diǎn)的創(chuàng)世配置位于chain_spec.rs文件中。模板默認(rèn)提供的是development_config()和local_testnet_config()兩個函數(shù)。我一開始以為多節(jié)點(diǎn)組網(wǎng)很復(fù)雜后來發(fā)現(xiàn)關(guān)鍵是改這幾項(xiàng)name和id鏈的名稱和標(biāo)識所有節(jié)點(diǎn)必須一致。chain_type設(shè)置為Local或Custom不能是Development否則驗(yàn)證者數(shù)量會被外部強(qiáng)行限制。session相關(guān)key為每個初始驗(yàn)證者生成Aura和Grandpa的key。endowed_accounts預(yù)置賬戶余額方便測試交易。用本地多節(jié)點(diǎn)測試時我一般先起第一個節(jié)點(diǎn)./target/release/node-template --chain local --validator --alice --tmp再起第二個節(jié)點(diǎn)并讓它連接到第一個節(jié)點(diǎn)的p2p地址./target/release/node-template --chain local --validator --bob --tmp \ --bootnodes /ip4/127.0.0.1/tcp/30333/p2p/alice-node-id這里需要從第一個節(jié)點(diǎn)日志里找到真實(shí)節(jié)點(diǎn)ID然后替換進(jìn)去。依賴操作時需要多嘗試幾次因?yàn)樗蕾嘝2P握手成功后驗(yàn)證者集合才真正開始協(xié)作。如果日志里出現(xiàn)“cannot finalize”之類的報錯八成是驗(yàn)證者key配置不全或者兩個節(jié)點(diǎn)用的chain_spec不一致。5.3 用sudo調(diào)set_code做運(yùn)行時升級這是Substrate最吸引人的能力。我用最原始的方式演示一遍先把新Runtime編譯成Wasm然后通過sudo pallet的setCode調(diào)用把新代碼上傳到鏈上。操作流程大概是這樣的修改pallet代碼更新RuntimeVersion里的specific_version。重新執(zhí)行cargo build --release生成新的Wasm二進(jìn)制。在前端模板里找到sudo.sudo調(diào)用填寫參數(shù)目標(biāo)方法為system.setCode代碼內(nèi)容選擇剛才生成的wasm文件通常是target/release/wbuild/node-template-runtime/node_template_runtime.compact.wasm。提交交易等待出塊之后鏈就會執(zhí)行新邏輯。我第一次做的時候提心吊膽擔(dān)心萬一新Runtime有bug就把鏈跑掛了。后來發(fā)現(xiàn)測試階段真的出現(xiàn)了類似情況我的處理方法是保持舊節(jié)點(diǎn)的數(shù)據(jù)庫備份必要時直接刪除本地數(shù)據(jù)重新同步。鏈上治理早期可以給sudo設(shè)置多簽任何人不能單獨(dú)升級。等業(yè)務(wù)成熟后再切換到民主投票這樣操作更穩(wěn)。這里必須提醒不要忽略RuntimeVersion更新。很多新手升級后鏈直接不認(rèn)賬就是因?yàn)樾屡f版本號一模一樣客戶端緩存了舊Wasm拒絕重新執(zhí)行。這個字段就是Substrate區(qū)分“是否更新”的關(guān)鍵標(biāo)記。6. 跑完一輪后我留下的幾條經(jīng)驗(yàn)與避坑總結(jié)6.1 編譯期最容易摔的跟頭第一次編譯Substrate項(xiàng)目我差點(diǎn)被自己逼瘋問題幾乎都集中在環(huán)境上。最大的坑是Rust nightly版本不對。Substrate的宏展開非常依賴rustc內(nèi)部行為版本差異可能導(dǎo)致宏直接展開失敗。所以一定要用倉庫里rust-toolchain.toml指定的版本不要自己隨手裝一個。我在三臺不同環(huán)境上測試過遵循指定版本是復(fù)現(xiàn)成功最關(guān)鍵的變量。第二個坑是Wasm目標(biāo)沒裝。Runtime編譯時要把Rust代碼編譯成Wasm這一步如果報錯target wasm32-unknown-unknown not found執(zhí)行rustup target add wasm32-unknown-unknown --toolchain nightly-version裝完后重新編譯。很多時候編譯失敗并不是代碼問題而是這個目標(biāo)缺失。第三個坑是磁盤空間。一個release構(gòu)建加緩存的依賴輕輕松松吃掉20GB以上。開發(fā)機(jī)至少預(yù)留50GB不然編譯到一半磁盤寫滿非常崩潰。6.2 運(yùn)行期存儲、Weight與調(diào)試手段運(yùn)行期最容易出問題的一個是存儲設(shè)計一個是Weight計算。存儲上我見過不少新人把很長的文本直接塞進(jìn)StorageValue完全不管鏈上存儲的膨脹。鏈上存儲的讀寫成本遠(yuǎn)高于內(nèi)存或磁盤設(shè)計時應(yīng)該盡量只存精簡狀態(tài)和哈希引用。大文件數(shù)據(jù)放到鏈下存儲鏈上只放哈希。Weight也就是手續(xù)費(fèi)和計算資源配額直接寫固定值是最省事的但不合理。如果調(diào)用函數(shù)邏輯變復(fù)雜固定的低Weight可能導(dǎo)致交易永遠(yuǎn)無法打包或者更糟被惡意用戶濫用。Substrate提供了#[pallet::weight]注解方式配合計算函數(shù)來進(jìn)行復(fù)雜估算。初期不追求精確但一定要給一個合理上限后續(xù)再通過基準(zhǔn)測試優(yōu)化。調(diào)試方面我強(qiáng)烈建議用substrate-contracts-node和前端模板而不是只靠終端日志。前端模板能直接看到鏈上狀態(tài)變化、事件日志、交易詳情還能直接調(diào)用最新加入的extrinsic調(diào)試效率高一個量級。如果要更底層的調(diào)試試試在runtime里加log輸出或用frame_support::debug打印信息。運(yùn)行期的另一個坑是區(qū)塊生成的“時區(qū)感”。默認(rèn)Aura出塊時間是6秒你跨地域跑多節(jié)點(diǎn)時網(wǎng)絡(luò)延遲可能導(dǎo)致出塊不穩(wěn)定。當(dāng)時我調(diào)整了MinimumPeriod和出塊slot時長讓鏈適應(yīng)跨機(jī)房部署。6.3 給計劃用Substrate團(tuán)隊(duì)的幾條建議回顧整個周期我認(rèn)為如果團(tuán)隊(duì)要正式用Substrate做業(yè)務(wù)鏈有幾件事最好在早期就想清楚。一是不要貪多。Substrate官方的pallet非常豐富但每引入一個pallet就會增加runtime體積和治理復(fù)雜度。初期能用最小集解決問題就盡量保持精簡Balances、Sudo、System加上你自己的業(yè)務(wù)pallet足夠了。二是升級設(shè)計要提前。既然Substrate支持無分叉升級那業(yè)務(wù)上就要設(shè)計好“舊數(shù)據(jù)兼容策略”比如存儲key變更時的遷移函數(shù)。不要等上線后再去想。三是多節(jié)點(diǎn)多環(huán)境測試一定要前置。我見過太多項(xiàng)目在開發(fā)機(jī)上跑得漂亮一上測試網(wǎng)就出各種共識問題。本地至少要從三節(jié)點(diǎn)起驗(yàn)證賬本一致性和重啟穩(wěn)定性。最后對團(tuán)隊(duì)現(xiàn)有的技術(shù)棧要做個判斷。Substrate開發(fā)依賴Rust和宏編程團(tuán)隊(duì)里至少要有兩位能看懂Rust宏的成員否則后期遇到宏報錯會很痛苦。如果團(tuán)隊(duì)是Java或Go背景也不是不能用只是要提前預(yù)留學(xué)習(xí)時間Rust的所有權(quán)模型和trait系統(tǒng)跟常見后端語言差異很大。如果用一句話總結(jié)我的體會就是Substrate不是一條鏈而是一套搭鏈的基礎(chǔ)設(shè)施它把“自定義區(qū)塊鏈”的門檻從底層協(xié)議拉低到了業(yè)務(wù)模塊層。只要你能設(shè)計好業(yè)務(wù)pallet剩下的大部分臟活累活框架已經(jīng)幫你扛了一半。那些在草稿里反復(fù)斟酌存儲字段的夜晚在編譯Wasm時等得發(fā)慌的幾分鐘以及終于看到自己寫的pallet在瀏覽器前端被調(diào)用成功那一刻都是這條技術(shù)路線上很真實(shí)的記憶。如果你也在評估Substrate我的建議是別只看文檔直接拿一個最小的業(yè)務(wù)場景從模板開始跑通一遍。跑通之后你自己就會知道它到底適不適合你的業(yè)務(wù)。