如何快速分析新加密項目的白皮書？

理解核心問題陳述

1. 確定項目聲稱要解決的具體痛點——尋找具體的例子，而不是模糊地提及“效率低下”或“缺乏信任”。

2. 交叉檢查現實世界基礎設施中是否大規模存在問題，例如跨境結算延遲、DeFi 預言機失敗率高或遺留鏈上反復出現的智能合約漏洞。

3. 評估白皮書是否區分了真正的技術差距和營銷驅動的敘述——諸如“革命性金融”之類沒有架構細節的短語是危險信號。

4. 注意現有解決方案是否得到認可和公平評估——省略 Chainlink、Celestia 或 EigenLayer 等競爭對手錶明市場意識不完整。

評估技術架構

1. 找到共識機制描述——驗證它是否是一種新穎的改編（例如，具有可驗證延遲函數的權益證明）或已知模型的重新命名版本。

2. 檢查分層結構：執行層是否與數據可用性分離？它是否與以太坊的匯總堆棧集成或提出一個孤立的整體鏈？

3. 檢查引用的密碼原語 — Merkle Patricia Tries、KZG 承諾或 STARK 友好的算術電路表明更深層次的工程嚴謹性。

4. 仔細審查可擴展性聲明：規定的 100,000 TPS 必須附有硬件假設、網絡延遲容差和驗證器硬件要求，而不僅僅是理論基準。

代幣經濟學和經濟設計

1. 映射所有代幣效用功能——治理權、費用捕獲、質押處罰、MEV 再分配——並驗證每個功能是否可以通過智能合約在鏈上強制執行。

2. 分析發行時間表：超過 36 個月的線性歸屬曲線與創世時解鎖 40% 的前置分配有很大不同。

3. 審查財政分配——指定用於“生態系統贈款”的資金要求支付標準和過去贈款績效指標的透明度。

4. 確定通脹機制：供應擴張是否與驗證器正常運行時間、交易量或任意基於時間的觸發器相關？

團隊和開發透明度

1. 確認 GitHub 活動 - 查找合併的拉取請求、問題解決速度和測試網部署時間戳 - 而不僅僅是存儲庫創建日期。

2. 通過 LinkedIn、之前的開源貢獻或已發表的研究論文來驗證團隊成員的資歷，而不僅僅是顧問委員會的隸屬關係。

3. 檢查來自 CertiK 或 OpenZeppelin 等公司的第三方審計報告，注意調查結果是否在發布前得到解決或推遲到主網發布後。

4. 檢查文檔完整性：RPC 端點、ABI 定義和水龍頭指令是否在令牌生成事件之前公開可用？

安全假設和信任邊界

1. 查明信任的假設位置——集中排序器、多重簽名可升級性或鏈下數據預言機引入了關鍵依賴性。

2. 確定後備機制：系統在驗證者削減期間是否會正常降級，還是完全停止？

3. 驗證形式驗證狀態：核心共識邏輯是否已在 TLA+ 中建模或使用 Coq 進行驗證？

4. 評估活躍度保證：是否有最低驗證者閾值、最低股權要求或地理分佈要求來防止審查？

常見問題解答

問：如果白皮書缺少 GitHub 鏈接怎麼辦？這表明工程可見性極低。公共存儲庫充當開發速度和代碼衛生的實時代理——缺乏公共存儲庫表明早期推測而不是實施。

問：如何驗證共識主張是否現實？將吞吐量數據與硬件限制進行比較：消費級節點上的 50,000 TPS 與 Solana 的 Firedancer 或以太坊的 Dencun 升級測試的經驗基準相矛盾。

問：長白皮書本身就更可信嗎？不會。像原始 Bitcoin 白皮書（9 頁）這樣簡潔、精確的文檔通常反映了更強的概念清晰度。長度與技術可靠性的相關性較差。

問：我應該相信顯示“去中心化架構”的圖表嗎？僅在驗證標籤後：標記為“驗證者”的節點必須具有相同的權限和職責。帶有“協調員”或“協調員”角色標記的圖表意味著集中控制點。