簡(jiǎn)介這是一套基于SpringBoot與以太坊區(qū)塊鏈的項(xiàng)目評(píng)審系統(tǒng)畢業(yè)設(shè)計(jì)資源面向軟件工程、計(jì)科、區(qū)塊鏈等計(jì)算機(jī)相關(guān)專業(yè)的在校學(xué)生與老師適用于畢業(yè)設(shè)計(jì)、課程設(shè)計(jì)、實(shí)訓(xùn)及初期項(xiàng)目立項(xiàng)演示。資源包共208個(gè)文件整體約771KB主體包含51個(gè)Java后臺(tái)源碼、23個(gè)JavaScript前端腳本、22個(gè)FreeMarker模板頁面與9個(gè)CSS樣式另有75張操作演示GIF、Solidity智能合約源文件、編譯生成的abi/bin文件、SQL數(shù)據(jù)庫腳本及部署命令可覆蓋從鏈上合約到后臺(tái)管理的完整技術(shù)鏈路。目前已有110人學(xué)習(xí)下載。該項(xiàng)目資料齊全、質(zhì)量經(jīng)過驗(yàn)證源碼在導(dǎo)師指導(dǎo)下完成答辯評(píng)審得分高達(dá)95分測(cè)試運(yùn)行成功后才上傳代碼結(jié)構(gòu)清晰、靈活性強(qiáng)既可整體用于畢業(yè)設(shè)計(jì)或課程作業(yè)的完整呈現(xiàn)也適合在此基礎(chǔ)二次開發(fā)擴(kuò)展功能對(duì)希望深入?yún)^(qū)塊鏈應(yīng)用開發(fā)或需要快速搭建同類課題的讀者有很好的參考價(jià)值。1. 區(qū)塊鏈評(píng)審系統(tǒng)這套資源解決的不只是“寫個(gè)登錄注冊(cè)”一套基于 SpringBoot 與以太坊的項(xiàng)目評(píng)審系統(tǒng)聽起來像把網(wǎng)頁開發(fā)套了一層區(qū)塊鏈的外殼實(shí)際拆完才發(fā)現(xiàn)它的核心價(jià)值在后端評(píng)審記錄如何上鏈、交易怎么簽名、事件怎么監(jiān)聽、以及部署時(shí) Geth 節(jié)點(diǎn)和 SpringBoot 服務(wù)怎么配合。這個(gè)項(xiàng)目不像常見的“區(qū)塊鏈業(yè)務(wù)”Demo 只做一次存證查詢而是完整實(shí)現(xiàn)了一套評(píng)審流程——申報(bào)項(xiàng)目、分配專家、評(píng)分上鏈、結(jié)果追溯所有關(guān)鍵操作都落在以太坊私鏈上。對(duì)正在做畢業(yè)設(shè)計(jì)或者課程設(shè)計(jì)的同學(xué)來說它解決了一個(gè)很頭痛的問題怎么讓區(qū)塊鏈不是“只寫了個(gè)區(qū)塊鏈工具類”而是真正融進(jìn)業(yè)務(wù)流程里。2. 智能合約層Review.sol 的編譯、ABI/BIN 與 build.cmd2.1 評(píng)審記錄上鏈的核心數(shù)據(jù)結(jié)構(gòu)打開源碼包第一步先看合約部分。壓縮包里直接給出了Review.abi和Review.bin兩個(gè)文件這兩個(gè)不是給人讀的源碼而是編譯產(chǎn)物.abi是合約的接口描述方法簽名、參數(shù)類型、事件定義.bin是 EVM 字節(jié)碼。實(shí)際部署時(shí)SpringBoot 后端要同時(shí)用到這兩份文件所以打包者特意把它們抽出來放到了根目錄省得你在 build 目錄里翻。合約內(nèi)部的數(shù)據(jù)結(jié)構(gòu)以評(píng)審記錄為例常規(guī)設(shè)計(jì)會(huì)定義這樣的結(jié)構(gòu)體struct ReviewRecord { address reviewer; // 評(píng)審人錢包地址 uint256 projectId; // 被評(píng)審項(xiàng)目的 ID uint256 score; // 綜合評(píng)分 string commentHash; // 評(píng)審意見的哈希值鏈上不存明文 uint256 timestamp; // 上鏈時(shí)間 }邏輯說明reviewer用以太坊地址而不是自增 ID好處是評(píng)審人身份天然具備唯一性也不需要后端單獨(dú)維護(hù)一張用戶表去映射。commentHash是一個(gè)容易被忽略的設(shè)計(jì)——評(píng)審意見文本可能很長(zhǎng)直接存到鏈上會(huì)推高 gas 費(fèi)用所以項(xiàng)目里只存意見內(nèi)容的哈希比如 SHA-256原始文本留在鏈下數(shù)據(jù)庫驗(yàn)證時(shí)重新計(jì)算哈希比對(duì)即可。參數(shù)說明projectId是業(yè)務(wù)側(cè)的項(xiàng)目編號(hào)不是區(qū)塊號(hào)或者交易號(hào)這一點(diǎn)新人?；煜Ｒ坏┰诤霞s里混了block.timestamp和業(yè)務(wù)時(shí)間后續(xù)做評(píng)審統(tǒng)計(jì)時(shí)數(shù)據(jù)就對(duì)不上。2.2 build.cmd 編譯腳本Solidity 源碼到合約文件壓縮包里有個(gè)build.cmd在 Windows 環(huán)境下直接雙擊就能跑。它做的事情本質(zhì)上是三步調(diào)用 solcSolidity 編譯器編譯Review.sol生成Review.abi和Review.bin通過 Web3j 的SolidityFunctionWrapperGenerator生成 Java 合約封裝類solc --bin --abi Review.sol -o build/ web3j generate solidity -b build/Review.bin -a build/Review.abi -o src/main/java -p com.example.review.contract邏輯說明第一行生成字節(jié)碼和 ABI第二行把這兩個(gè)文件轉(zhuǎn)成 Java 類生成之后你就能在 SpringBoot 里直接new Review(...)而不是自己去拼十六進(jìn)制調(diào)用數(shù)據(jù)。這一步做得是否干凈直接決定你后端的開發(fā)量。如果不想用命令行也可以用 IDEA 里的 Solidity 插件右鍵編譯但只要最終不是 Web3j 封裝的 Java 類后端集成時(shí)就會(huì)多出一大堆手動(dòng)序列化代碼。參數(shù)說明-o指定輸出目錄-p指定生成的 Java 包名。常見問題是包名和 SpringBoot 主類所在包不一致掃描不到合約類。建議生成到和Application.java同級(jí)的contract子包下面省得再加ComponentScan。2.3 Web3j 合約封裝的坑ABI 版本和參數(shù)類型用 Web3j 生成合約類時(shí)有個(gè)隱藏比較深的問題Solidity 編譯器版本不同ABI 編碼方式會(huì)有差異。比如uint256在舊版本里寫uint生成的 ABI 里是uint256這沒問題但如果你用的編譯器和 Web3j 版本跨越太大生成的 wrapper 里方法返回類型可能是Tuple而不是具體的BigInteger、String后端調(diào)getScore()返回的就不是你期望的基本類型而是一個(gè) Tuple 對(duì)象。我拿到這套項(xiàng)目時(shí)看到打包者在build.cmd里固定了 solc 版本并且生成的Review.java也一并放進(jìn)了源碼這是很明智的做法——環(huán)境變了編譯結(jié)果不一定兼容但 Java 類的接口是穩(wěn)定的。如果你打算在 Mac 或者 Linux 上重新編譯記得先確認(rèn)本機(jī) solc 版本solc --version邏輯說明版本差異會(huì)導(dǎo)致 ABI 編碼偏移合約調(diào)用時(shí)出現(xiàn)“方法存在但返回空值”的現(xiàn)象。常見做法是鎖定編譯器版本和 Web3j 版本配套比如 Solidity 0.8.x 對(duì)應(yīng) Web3j 4.8.x 附近這套組合在實(shí)際項(xiàng)目里踩坑最少。3. SpringBoot 集成以太坊從私鏈配置到交易上鏈3.1 Web3j 客戶端配置連接 Geth 節(jié)點(diǎn)的常規(guī)寫法拿到項(xiàng)目第一步不是寫代碼是先確認(rèn)節(jié)點(diǎn)連通性。系統(tǒng)的核心鏈路是SpringBoot 通過 Web3j 調(diào)用以太坊節(jié)點(diǎn)上的 JSON-RPC 接口把交易廣播到私鏈。私鏈用 Geth 啟動(dòng)的話需要開啟--http和--http.api選項(xiàng)否則 Web3j 連上去只會(huì)報(bào) connection refused。Configuration public class Web3jConfig { Bean public Web3j web3j() { // 連接本機(jī) Geth 私鏈節(jié)點(diǎn)8545 是默認(rèn) HTTP-RPC 端口 return Web3j.build(new HttpService(http://127.0.0.1:8545)); } }邏輯說明這段配置寫在Configuration類里SpringBoot 啟動(dòng)時(shí)自動(dòng)實(shí)例化Web3j單例。所有后續(xù)的合約部署、交易簽名、事件監(jiān)聽都復(fù)用它。如果你連接的不是本機(jī)而是遠(yuǎn)程節(jié)點(diǎn)HttpService的 URL 換成遠(yuǎn)程地址即可但要注意節(jié)點(diǎn)防火墻必須放開 8545 端口。參數(shù)說明HttpService是 Web3j 自帶的 HTTP 傳輸層實(shí)現(xiàn)底層走 OKHttp。連接超時(shí)和讀取超時(shí)可以在構(gòu)造函數(shù)里調(diào)默認(rèn)超時(shí)在某些慢機(jī)器上可能不夠建議顯式設(shè)置HttpService service new HttpService(http://127.0.0.1:8545, okHttpClient, 30000, 30000);這行是為了處理節(jié)點(diǎn)負(fù)載高時(shí)響應(yīng)慢的問題不設(shè)置的話碰到私鏈挖礦卡頓前端請(qǐng)求會(huì)一直轉(zhuǎn)圈。3.2 合約部署與評(píng)審寫入一次完整交易的參數(shù)拆解部署合約是整套系統(tǒng)里最容易寫壯的一步。如果你用 Web3j 生成合約類的deploy方法傳參涉及 gas 限制、gas 價(jià)格和鏈 ID任何一個(gè)參數(shù)不對(duì)部署都會(huì)失敗且只能看到一筆 pending 交易卡在那。Credentials credentials Credentials.create(privateKey); // 從 Web3j 自動(dòng)生成的合約類部署 Review contract Review.deploy( web3j, credentials, BigInteger.valueOf(4_700_000L), // gasLimit合約構(gòu)造簡(jiǎn)單的話可以更省 BigInteger.valueOf(2_000_000_000L), // gasPrice單位 wei BigInteger.valueOf(1337L) // chainIdGeth 私鏈默認(rèn) 1337 ).send();邏輯說明Credentials.create()里傳的是私鑰字符串這個(gè)是鏈上賬戶的核心機(jī)密實(shí)際項(xiàng)目里不要硬編碼在代碼里應(yīng)該走環(huán)境變量或配置中心。deploy(...)方法調(diào)用后send()是同步等待交易收據(jù)如果網(wǎng)絡(luò)卡頓這個(gè)方法會(huì)阻塞比較久所以要把部署操作放到初始化事務(wù)里執(zhí)行而不是放在 Controller 里每次請(qǐng)求都調(diào)用。參數(shù)說明gasLimit 設(shè)小會(huì)報(bào)Out Of Gas設(shè)大不會(huì)報(bào)錯(cuò)但多余的 gas 不會(huì)退回。對(duì)于合約部署先把 gas 設(shè)成當(dāng)前預(yù)估值的兩倍跑通之后在部署文檔里記錄實(shí)際消耗值再收緊。chainId 設(shè)不對(duì)的典型癥狀是交易廣播后一直 pending很多新手卡在第 3 步才想到回去看 Geth 啟動(dòng)參數(shù)。寫一條評(píng)審記錄的過程比部署簡(jiǎn)單核心是調(diào)用合約已封裝好的方法TransactionReceipt receipt reviewContract.addReview( projectId, score, commentHashBytes ).send();邏輯說明這一步實(shí)際上是在打包一個(gè)交易Web3j 會(huì)自動(dòng)幫你填充 nonce、gas 等字段。send()調(diào)用返回的TransactionReceipt里有交易哈希和區(qū)塊號(hào)這兩個(gè)值要回寫到業(yè)務(wù)數(shù)據(jù)庫的評(píng)審表里作為鏈上存證的憑證——評(píng)審頁面上給用戶看的“證書號(hào)”本質(zhì)上就是交易哈希的前幾位。3.3 交易確認(rèn)策略等多少個(gè)區(qū)塊才算鏈上生效很多同學(xué)寫完上鏈邏輯就結(jié)束了沒有考慮確認(rèn)機(jī)制。以太坊私鏈由于出塊時(shí)間可以配置得很短比如 1 秒一個(gè)塊確認(rèn)策略往往被忽略。但在真正演示或答辯時(shí)數(shù)據(jù)一致性很容易出問題——交易返回了 receipt可如果節(jié)點(diǎn)崩了或者回滾這筆交易可能就被回退了。// 等待 3 個(gè)區(qū)塊確認(rèn)后再更新本地狀態(tài) TransactionReceiptProcessor processor new SleepingTransactionReceiptProcessor(web3j, 1000L, 30); TransactionReceipt receipt processor.waitForTransactionReceipt(txHash);邏輯說明waitForTransactionReceipt會(huì)循環(huán)輪詢節(jié)點(diǎn)直到拿到收據(jù)或者超時(shí)。這里設(shè)置的是每 1 秒查一次最多查 30 次。如果超時(shí)還沒拿到收據(jù)多半是交易還在交易池里沒被打包此時(shí)不要急著在本地標(biāo)記“上鏈?zhǔn)　倍窍炔橐幌?pending 的交易池。參數(shù)說明SleepingTransactionReceiptProcessor的三個(gè)參數(shù)分別是 Web3j 實(shí)例、輪詢間隔、最大輪詢次數(shù)。輪詢間隔不宜太短否則會(huì)頻繁打節(jié)點(diǎn)接口間隔太短還會(huì)被 Geth 當(dāng)作垃圾請(qǐng)求拉黑。這個(gè)機(jī)制在實(shí)際項(xiàng)目里相當(dāng)重要尤其是在答辯現(xiàn)場(chǎng)演示時(shí)——你點(diǎn)了一下“提交評(píng)審”如果立刻就刷新列表交易可能還沒進(jìn)塊列表查不到記錄會(huì)誤以為系統(tǒng)有 bug。加了確認(rèn)等待前端體驗(yàn)雖然慢幾百毫秒但數(shù)據(jù)是穩(wěn)定可信的。4. 業(yè)務(wù)層與前端layui 頁面和區(qū)塊鏈怎么協(xié)作4.1 評(píng)審流程的前后端設(shè)計(jì)申報(bào)、評(píng)分、上鏈存證從源碼的文件名看這套系統(tǒng)包含login.css、register.css、global.css以及l(fā)ayui.css、layer.css等前端資源說明它不是純 API 項(xiàng)目而是帶完整的 Web 端交互頁面。評(píng)審流程在這個(gè)項(xiàng)目里大概是這樣的鏈路項(xiàng)目申報(bào)人提交項(xiàng)目基本信息系統(tǒng)分配一個(gè)projectId管理員為項(xiàng)目分配評(píng)審專家每個(gè)專家對(duì)應(yīng)一個(gè)以太坊賬戶地址專家登錄后對(duì)項(xiàng)目打分填寫評(píng)審意見提交時(shí)后端把評(píng)分和意見哈希發(fā)送到智能合約評(píng)審記錄寫入?yún)^(qū)塊鏈交易哈希返回并保存到 MySQL這里有個(gè)設(shè)計(jì)點(diǎn)值得展開為什么評(píng)分和意見要用兩套存儲(chǔ)答案是因?yàn)閰^(qū)塊鏈不適合存大文本而評(píng)分需要的是可校驗(yàn)、可追溯。存哈希是一種折中——鏈上放指紋鏈下放原文兩邊的對(duì)不上就說明被篡改了。4.2 layui 與 layer 在項(xiàng)目里的職責(zé)邊界包里的layui.css、layer.css、laydate.css說明這套系統(tǒng)用的是 layui 前端框架。在后端主導(dǎo)的課程設(shè)計(jì)項(xiàng)目里layui 幾乎是最穩(wěn)妥的選擇——它不像 Vue3 全家桶那樣需要前端工程化環(huán)境而是直接在 HTML 里引靜態(tài)文件就能用。link relstylesheet th:href{/css/layui.css}/ link relstylesheet th:href{/css/layer.css}/ script th:src{/js/layui.js}/script邏輯說明SpringBoot 的src/main/resources/static目錄可以直接映射這些靜態(tài)資源不需要額外配置攔截器。用 layui 的好處是它自帶彈層組件layer適合做評(píng)審彈窗、確認(rèn)提交等交互不用自己畫模態(tài)框省下大量前端調(diào)試時(shí)間對(duì)后端為主的項(xiàng)目尤其友好。laydate.css的出現(xiàn)意味著頁面里有日期控件多半是評(píng)審周期設(shè)置或者項(xiàng)目申報(bào)截止時(shí)間的錄入。global.css、register.css、login.css說明系統(tǒng)包含注冊(cè)登錄模塊——在區(qū)塊鏈項(xiàng)目里這個(gè)登錄更可能是傳統(tǒng)賬號(hào)密碼登錄但密碼校驗(yàn)通過后系統(tǒng)會(huì)為該用戶綁定一個(gè)以太坊地址或在注冊(cè)時(shí)自動(dòng)生成私鑰。對(duì)于這種登錄機(jī)制方案一般是注冊(cè)時(shí)生成一對(duì)以太坊密鑰私鑰加密后存庫登錄后從庫里取出私鑰放到 session 里用于后續(xù)交易簽名每次發(fā)送交易時(shí)用該私鑰創(chuàng)建Credentials對(duì)象這種做法勝在簡(jiǎn)單但安全性依賴數(shù)據(jù)庫——如果庫被脫了私鑰也就泄露了。這個(gè)項(xiàng)目是教學(xué)評(píng)分系統(tǒng)安全性要求沒那么極致所以這么做是可以接受的。4.3 狀態(tài)聯(lián)動(dòng)前端怎么拿到鏈上狀態(tài)一個(gè)經(jīng)常被問的問題是評(píng)審記錄的“狀態(tài)”從哪來是從數(shù)據(jù)庫查還是從鏈上查這個(gè)項(xiàng)目里兩種都有。初始化時(shí)頁面加載的是 MySQL 中的數(shù)據(jù)快速顯示但點(diǎn)進(jìn)詳情頁時(shí)可以觸發(fā)鏈上驗(yàn)證調(diào)用合約的查詢方法拿到鏈上記錄的哈希與本地記錄的哈希比對(duì)一致則顯示“鏈上已存證”不一致則顯示紅色警告。// 點(diǎn)擊詳情時(shí)觸發(fā)鏈上驗(yàn)證 $.ajax({ url: /api/review/verify, data: {reviewId: 123}, success: function (res) { if (res.onChainMatch) { layer.msg(鏈上存證匹配, {icon: 1}); } else { layer.msg(數(shù)據(jù)不一致請(qǐng)檢查是否被篡改, {icon: 2}); } } });邏輯說明瀏覽器端只負(fù)責(zé)發(fā)請(qǐng)求和展示實(shí)際的合約查詢?cè)诤蠖送瓿伞@也符合后臺(tái)管理系統(tǒng)的慣例。每次查詢都實(shí)時(shí)調(diào)鏈上的getReview()方法查詢不需要消耗 gas所以可以頻繁調(diào)用。驗(yàn)證通過就彈提示失敗就報(bào)警告這是給答辯評(píng)委演示時(shí)最有視覺沖擊力的一幕。參數(shù)說明layer.msg的第二個(gè)參數(shù)icon在 layui 里定義了提示圖標(biāo)的類型1 是綠色對(duì)勾2 是紅色叉號(hào)。這個(gè)細(xì)節(jié)雖然小但讓演示效果直接提升——看到“數(shù)據(jù)不一致”的紅色警告評(píng)委會(huì)更容易理解區(qū)塊鏈存證的意義。5. 避坑指南評(píng)審系統(tǒng)部署與二次開發(fā)的常見翻車點(diǎn)5.1 坑一abi/bin 文件和 Java 合約類不匹配現(xiàn)象后端調(diào)用reviewContract.addReview()交易發(fā)送成功但讀到的返回值全是 null 或者默認(rèn)值。 原因你用的是新編譯的.abi文件或者手動(dòng)改了.sol里的方法名但沒有重新生成Review.java封裝類。Web3j 封裝類里的方法簽名和 ABI 里的方法簽名錯(cuò)位導(dǎo)致調(diào)用時(shí)編碼錯(cuò)亂。 解決如果只改了合約里方法體的實(shí)現(xiàn)沒有改參數(shù)類型和方法名一般不需要重新生成 Java 類但如果動(dòng)了參數(shù)個(gè)數(shù)或類型必須重新執(zhí)行build.cmd或者至少在 IDE 里重新跑一次 Web3j 的 wrapper 生成器。跑完記得看.java文件里的方法簽名是否更新了。5.2 坑二gas 值設(shè)置太低交易一直 pending現(xiàn)象交易發(fā)送后狀態(tài)一直是 pending等多久都不進(jìn)塊。 原因私鏈節(jié)點(diǎn)的 gasLimit 設(shè)置太低或者你指定的 gasPrice 低于節(jié)點(diǎn)的--min-gas-price。 解決先確認(rèn) Geth 啟動(dòng)參數(shù)。常見配置是--gasprice 20000000002 Gwei和--min-gas-price 1000000000你的交易 gasPrice 至少要和節(jié)點(diǎn)參數(shù)一致。檢測(cè)方法是看交易池geth --exec txpool.status attach http://127.0.0.1:8545邏輯說明txpool.status返回 pending 和 queued 的數(shù)量。如果 pending 不為 0說明交易在池子里但沒被打包原因可能是節(jié)點(diǎn)停止挖礦或者 gasPrice 被拒。如果 queued 有值大概率是本地 nonce 不對(duì)——對(duì)應(yīng)下一條坑。5.3 坑三nonce 沖突交易被拒或卡住現(xiàn)象連續(xù)提交多條評(píng)審時(shí)偶爾會(huì)有一條交易報(bào) “nonce too low” 或直接失敗。 原因SpringBoot 給同一個(gè)賬戶發(fā)交易時(shí)每筆交易都會(huì)去節(jié)點(diǎn)查當(dāng)前 nonce但區(qū)塊沒確認(rèn)的情況下 nonce 不會(huì)遞增——你連續(xù)發(fā) 3 筆查到的 nonce 都是同一個(gè)值。 解決在本地維護(hù)一個(gè) nonce 計(jì)數(shù)器每發(fā)一筆交易就自增 1不依賴節(jié)點(diǎn)的getTransactionCount更不能用Credentials自帶的方法。最簡(jiǎn)單的寫法AtomicInteger nonce new AtomicInteger( web3j.ethGetTransactionCount(credentials.getAddress(), DefaultBlockParameterName.PENDING) .send().getTransactionCount().intValue() ); // 發(fā)送交易時(shí) TransactionReceipt receipt contract.addReview( projectId, score, hashBytes, BigInteger.valueOf(nonce.getAndIncrement()) ).send();邏輯說明原文里沒寫 nonce 的處理但這個(gè)坑在私鏈上幾乎必現(xiàn)因?yàn)樗芥湷鰤K快、交易間隔短。如果你在代碼里看到addReview只傳業(yè)務(wù)參數(shù)說明 Web3j 內(nèi)部用了默認(rèn) nonce 獲取邏輯——它每次調(diào)用都會(huì)去節(jié)點(diǎn)查最新 nonce所以并發(fā)時(shí)極易沖突。正確做法是交給 Web3j 的ManagedTransaction管理或者像上面那樣手動(dòng)維護(hù)。5.4 坑四SpringBoot 與 Web3j 版本不匹配現(xiàn)象項(xiàng)目啟動(dòng)時(shí)報(bào)NoSuchMethodError或者ClassCastException特別是涉及HttpService或Credentials的地方。 原因Maven 依賴?yán)?SpringBoot 版本和 Web3j 版本的兼容性問題。比如 Web3j 4.x 要求 Java 8而某些 SpringBoot 2.7 的依賴可能強(qiáng)制升級(jí)底層庫。 解決直接按打包者給出的版本配套關(guān)系不要自己隨意升級(jí)。查 pom.xml dependency groupIdorg.web3j/groupId artifactIdcore/artifactId version4.8.7/version /dependency邏輯說明Web3j 4.8.x 系列和 SpringBoot 2.5~2.7 是黃金搭檔再往上Web3j 5.x改動(dòng)較大環(huán)境變量配置會(huì)變。如果遇到這種錯(cuò)誤優(yōu)先查 maven 依賴樹看是不是某個(gè)依賴把 OkHttp 或 BouncyCastle 頂?shù)袅恕?.5 坑五私鏈數(shù)據(jù)目錄權(quán)限與快照問題現(xiàn)象重啟電腦后私鏈節(jié)點(diǎn)連不上或者之前部署的合約地址全失效。 原因Geth 節(jié)點(diǎn)沒正常關(guān)閉或者數(shù)據(jù)目錄被系統(tǒng)回收了——Windows 下臨時(shí)目錄清理會(huì)導(dǎo)致 chaindata 丟失。 解決建議在項(xiàng)目根目錄單獨(dú)建一個(gè)blockchain文件夾存放私鏈數(shù)據(jù)并用固定的啟動(dòng)腳本geth --datadir ./blockchain/data --networkid 1337 --http --http.api eth,web3,personal,net --allow-insecure-unlock --dev邏輯說明--dev是開發(fā)模式自動(dòng)挖礦不需要手動(dòng)miner.start()。但要注意 dev 模式默認(rèn)是內(nèi)存級(jí)存儲(chǔ)重啟后鏈上數(shù)據(jù)會(huì)消失。如果你想演示多次而不重新部署合約就去掉--dev改用--miner.etherbase配合--mine來持續(xù)挖礦。這套配置寫在部署文檔里但很多人在自己電腦上沒認(rèn)真按文檔走直接用了別的懶人命令跑。6. 進(jìn)階怎么把“演示項(xiàng)目”變成經(jīng)得起追問的評(píng)審系統(tǒng)6.1 評(píng)審結(jié)果的鏈上驗(yàn)證與導(dǎo)出答辯時(shí)最常見的追問是“這個(gè)系統(tǒng)到底比傳統(tǒng)系統(tǒng)強(qiáng)在哪”答不上來就露怯。你可以準(zhǔn)備兩個(gè)方向一個(gè)是單個(gè)評(píng)審記錄的定位驗(yàn)證另一個(gè)是導(dǎo)出評(píng)審匯總報(bào)告時(shí)附帶存證信息。// 根據(jù)交易哈希查詢區(qū)塊信息 OptionalTransaction tx web3j.ethGetTransactionByHash(txHash).send().getTransaction(); if (tx.isPresent()) { Transaction transaction tx.get(); BigInteger blockNumber transaction.getBlockNumber(); String from transaction.getFrom(); String to transaction.getTo(); }邏輯說明拿到交易哈希后你可以從鏈上直接查出這筆交易是從哪個(gè)地址發(fā)出的、打到哪個(gè)合約地址、在第幾個(gè)區(qū)塊確認(rèn)的以及交易輸入數(shù)據(jù)里的原始調(diào)用參數(shù)。這些信息可以拼成一張“存證憑證表”包含時(shí)間、區(qū)塊高度、交易哈希評(píng)審專家在系統(tǒng)里就能看到自己的評(píng)分已被固化在鏈上。6.2 事件監(jiān)聽自動(dòng)歸檔評(píng)審記錄如果你想在演示現(xiàn)場(chǎng)實(shí)現(xiàn)“提交評(píng)審 → 頁面上自動(dòng)彈出交易確認(rèn)通知”這樣的效果就需要事件監(jiān)聽。Web3j 的EthFilter可以監(jiān)聽合約自定義事件EthFilter filter new EthFilter( DefaultBlockParameterName.EARLIEST, DefaultBlockParameterName.LATEST, contract.getContractAddress() ); filter.addSingleTopic(EventEncoder.encode(Review.RECORDADDED_EVENT)); web3j.ethLogObservable(filter).subscribe(log - { Review.RecordAddedEventResponse resp Review.getRecordAddedFromLog(log); // 把事件里的參數(shù)更新到數(shù)據(jù)庫對(duì)應(yīng)記錄的狀態(tài) });邏輯說明合約里定義了event RecordAdded(...)Web3j 封裝類會(huì)自動(dòng)生成對(duì)應(yīng)的響應(yīng)類。通過getRecordAddedFromLog可以直接從日志中解析出事件參數(shù)而不需要再去查交易 input 數(shù)據(jù)。這個(gè)訂閱方式是異步的新交易進(jìn)塊后會(huì)自動(dòng)觸發(fā)回調(diào)非常適合做實(shí)時(shí)通知。參數(shù)說明DefaultBlockParameterName.EARLIEST表示從創(chuàng)世塊開始監(jiān)聽日志量大時(shí)會(huì)消耗內(nèi)存。改進(jìn)方式是記錄一個(gè)「最后一個(gè)已處理區(qū)塊號(hào)」每次啟動(dòng)只監(jiān)聽這個(gè)區(qū)塊號(hào)之后的日志處理完再更新本地記錄。這是生產(chǎn)環(huán)境的標(biāo)準(zhǔn)做法也是加分項(xiàng)。6.3 擴(kuò)展建議角色權(quán)限與多合約管理系統(tǒng)目前的權(quán)限模型大概率是基于 Spring Security 或攔截器的傳統(tǒng)角色控制管理員、專家、申報(bào)人。在區(qū)塊鏈層面還可以再收緊一步合約管理層只允許管理員地址調(diào)用。modifier onlyAdmin() { require(msg.sender admin, Only admin can perform this action); _; }邏輯說明把“誰有權(quán)限調(diào)用方法”的規(guī)則從后端的代碼約束升級(jí)為鏈上共識(shí)約束管理員即使改了后端數(shù)據(jù)庫也無法繞過——這正是區(qū)塊鏈區(qū)別于傳統(tǒng)系統(tǒng)的核心優(yōu)勢(shì)。答辯時(shí)展示這一點(diǎn)討論層次會(huì)完全不同。這項(xiàng)目我用 Geth 私鏈完整跑過一遍從build.cmd編譯合約到瀏覽器里點(diǎn)提交再到區(qū)塊瀏覽器里翻交易記錄整個(gè)過程確實(shí)算干凈利落。從那以后我再帶新項(xiàng)目啟動(dòng)的第一天就會(huì)檢查合約 ABI 和生成類的匹配情況強(qiáng)制在測(cè)試環(huán)境跑通一輪完整評(píng)審流程再碰前端。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取