原創主題配圖: 鏈觀 BTC866 原創主題圖解 · ChainView BTC866 Editorial · CC BY 4.0
白皮書要提出可檢驗目標
閱讀白皮書時先找明確問題、目標用戶和衡量成功的指標。吞吐量、成本或隱私改進應有條件與基準，不能只依賴“下一代”“無限擴展”等宣傳。把已實現功能、研究設想和商業計劃分開標注，記錄文檔版本與發佈日期。白皮書是一份主張集合，是否落地仍需代碼、測試和真實運行證據相互印證。
安全假設寫在哪
檢查系統依賴哪些誠實參與者、管理員、硬件、預言機和外部服務。若關鍵假設只藏在腳注或未明確披露，應列為待確認問題。攻擊者能力、失敗情景和恢復方式比正常流程圖更能反映邊界。不要把數學證明的某個組件安全，直接推廣成整個錢包、網站與業務模式都安全，證明只在其模型和前提內成立。
倉庫身份與許可
從項目官方渠道進入代碼倉庫，檢查組織身份、許可證、主要目錄與構建說明。相似名稱的倉庫可能是分叉、鏡像或仿冒，星標數量也不證明質量。許可條款決定複製、修改和分發的條件，源碼可見不必然意味著符合所有開源定義。對未公開部分，要明確其與宣傳中“完全開源”的關係。
提交活動和真實進展
提交數量容易受到自動格式化、依賴更新或歷史導入影響，不能作為開發速度的唯一指標。抽樣閱讀功能合併、問題討論、發佈標籤和測試變化，觀察是否解決白皮書中的具體目標。長期活躍也可能只是維護，短期安靜也可能有未公開開發；結論應描述觀察到的證據，而不是憑頻次判斷團隊能力或誠信。
測試、審計與已知問題
測試通過只說明既定樣本下滿足斷言，遺漏場景仍可能出錯。檢查測試類型、覆蓋邊界、可復現構建和公開漏洞流程，核對審計報告對應的提交哈希。報告中的未修復項、範圍排除和管理員假設都應記錄。不要為了檢查項目而在個人主力設備執行不理解的腳本，可優先閱讀公開持續集成結果與文檔。
製作主張與證據矩陣
每行寫一項白皮書主張，對應規範位置、代碼模塊、測試、發佈版本和未解決限制。標明證據是項目自述、第三方檢查還是實際運行觀察，給未知項保留空間。定期根據新發佈更新，而不是只在首次接觸時評分。技術進展與代幣權利、企業財務和價格風險仍是不同問題，不能用一張技術矩陣推導投資回報。
具體核驗案例
假設白皮書承諾每秒一萬筆交易，倉庫卻只有單機基準測試。證據矩陣應列出硬件、交易類型、持續時間和是否完成最終結算，並標注公開網絡尚未驗證。若發佈說明後來加入多人測試，也只更新相應證據，不直接改寫成所有場景都已達標。把主張拆成可檢驗條件，可以減少對營銷用語的依賴，同時保留項目實際進展而不誇大結論。
