@Hemi $HEMI #Hemi


在把關鍵歷史錨定到比特幣之後,仍有一個經常被忽略卻至關重要的問題:歷史究竟靠什麼被重放與複覈。外部終局解決的是“不可抵賴”,而不是“全部細節可取回”;錨定承諾告訴我們哪段區間、哪一棵樹根已經寫進了 BTC,卻不可能把所有原始交易與事件逐字節放到 L1。於是,數據可用性(DA)便成了 Hemi 的第二條生命線:如果細節在任何時候都可以被任何一方重取、重放、重算,那麼外部終局才真正有了“肉身”,審計、合規、爭議裁決與歷史回放纔不至於停留在口號。編號 20 的重點,就是把 Hemi 的 DA 打造成一種“人人可複覈、按層次取用、遇故障可降級”的公共品,讓可審計歷史不再仰賴內部好意,而是落實在結構化的存取路徑上。


Hemi 將 DA 設計爲熱存取、溫存取與冷歸檔三層協同的體系。最靠近出塊的一層,是與排序和執行並行的熱層:節點通過點對點網絡廣播完整交易、事件日誌與執行見證,形成對“剛出塊數據”的第一性供給;這層的目標不是永久保存,而是確保任何希望參與共識或快速復演的節點都能“立刻拿到最新材料”。第二層是溫層,以“內容尋址的塊/片”爲單位存放經過分片與校驗的數據片段,節點可在較長時間窗口內穩定拉取;它既接住了熱層的溢出,也爲冷層補檔提供持續來源。第三層是冷層歸檔,面向長期可追溯與法規留存,以壓縮與冗餘並舉的方式進行多年尺度的保存;冷層不是某個機房,而是一組可替換的運營者與公共存儲接口,按標準化索引對外暴露取證路徑。三層之間通過明確的“承諾—映射—校驗”關係銜接:區塊頭/狀態根承諾→內容尋址索引→分片校驗與重構,使得“我想重放這 500 個高度的某套路由”有清晰的座標系與最短路徑。


爲了把“可用性”從主觀陳述改成客觀事實,Hemi 在溫層採用基於內容的切片存儲與糾刪機制:原始區塊數據按固定規則分塊,再在塊級別施加糾刪碼,形成 N 份分片與校驗片;只要取回其中 K 份即可完整還原。每一塊都有獨立的內容哈希,分片也各自擁有地址與校驗標記,任何節點收到某個分片,都能在本地獨立驗證其正確性。這樣的好處是顯而易見的:一方面,運營者不必“承諾我有全量”,而是以片段的“在/不在”接受可量化問責;另一方面,請求方無需信任某個特定源,只要從不同對等端取齊 K 片,合成即可。如果片源質量下降,系統會把“難以取齊”的事實立刻顯性化——這不會被語言粉飾,因爲重構要麼成功要麼失敗,中間態只會以“重構失敗率”這樣的指標呈現。


DA 的另一根筋是索引。僅有分片還不夠,還要讓“我關心的是什麼”快速映射到“我去哪裏取”。Hemi 把索引做成三維座標:時間軸上的高度/批次標識、承諾樹上的路徑與位置、業務語義上的賬戶/合約/主題。時間維度解決“這是什麼時候的哪一段”;承諾維度解決“它在樹裏被誰包含”;語義維度解決“我應該訂閱誰的歷史”。這三維交織出一個可被自動化工具消費的查詢語言:例如“拉取高度區間 a–b 內,所有與合約 X 的事件主題 Y 相關、且在承諾樹路徑 P 下的片段”,SDK 會把這條查詢拆解爲若干內容哈希請求,分發到溫層與冷層的不同源頭,再把取回的片段按順序重拼並校驗。在這個過程中,任何一步都不要求相信運營者“說對了”,而是以哈希與校驗把對錯轉換爲比特級事實。


可用性不是靜態承諾,而是運營 SLO。Hemi 把 DA 的可取回時間定義爲可觀測目標:在穩態下、以 P 百分比的置信度,在 T 秒內取齊某高度的 K 份分片;在擁堵或災備狀態,進入“保守模式”,將關鍵路徑(橋、清算、賬期結轉)的片段優先級前置、複製數提升、分發路徑加厚,同時對非關鍵片段降速限流。每一次偏離 SLO 的事件都以 T+1 的方式覆盤歸檔:給出請求拓撲、失敗分片的源分佈、重傳次數與實際恢復時間,連同當期的錨定覆蓋率、確認延遲一起成爲治理調參的依據。這樣,DA 不再是“應該夠用”,而變成“可觀察、可調參、可問責”的運行目標。


DA 的存在並不否認外部終局,恰恰相反,兩者互爲支撐。PoP 把“這一段歷史是真的”寫進 BTC,而 DA 確保“這段歷史的細節隨時可用”。當重放者沿着錨定公告給出的 BTC 交易指紋與承諾樹路徑找到某個區間後,接下來的步驟就是在 DA 網絡裏抓取該區間的原始數據與見證,校驗無誤後,再在本地重放執行以得到目標狀態;一旦任何步驟失敗,問題在座標層面立刻顯性化:要麼是 DA 片段不可用、要麼是承諾路徑有誤、要麼是執行與狀態根不一致。這種“層層可複覈”的設計,使得爭議不會停在“各執一詞”,而會以“請沿這條公共路徑逐步驗證”的方式快速歸因。


Hemi 在 DA 的故障學上格外剋制。系統的默認動作不是“儘快把所有東西永遠可用”,而是“把關鍵動作的輸入永遠可用,把非關鍵動作的輸入以經濟可承受的方式長久可用”。當溫層局部失敗、冷層回源速度不足時,橋與清算一類高價值路徑的片段會通過額外複製與更激進的調度策略被優先保障;與此同時,一般片段可能進入“延期服務”的隊列,界面上以“預計可取回時間”向外披露。治理根據失敗的粒度、持續時長與受影響業務的權重,決定是否觸發懲戒、是否增加預算、是否擴容某類節點的最低供給。當 DA 的故障無法在合理時間內被修復,系統會將依賴該片段的高價值動作切換到“安全熔斷”狀態,直到取回 SLO 恢復;這樣的犧牲不是“不作爲”,而是把系統性風險控制在透明邊界內。


在激勵上,Hemi 傾向於將 DA 服務做成“薄利但穩健”的公共市場。存取節點按片段的持有與成功服務量獲得補償,補償由兩部分構成:協議側的基礎補貼與請求側的微支付;對關鍵片段額外設定服務質量獎勵與延遲懲罰。爲了避免無謂複製與“刷量”,系統對同一區段的供給做去重計量,對同一請求的重複服務按一次計價;對惡意提供錯誤分片或長期失約的節點,實行押金扣減與黑名單處理。激勵的目的不是“讓人暴富”,而是“讓人在任何市場週期都有動力維持可用性”,確保“取得到”這件事不被利潤波動左右。


開發者體驗決定了 DA 是否會成爲默認能力。Hemi 的 SDK 把“索引—取回—校驗—重放”做成一條流水線式接口,應用只需聲明“我需要某段區間的哪些語義片段”,SDK 便會在後臺完成片段定位與取回,並把結果以可流式消費的形式提供給執行環境;對調試與回放,SDK 支持“一鍵重演某高度”的快捷方式,以及“對比兩個高度之間某賬戶/合約狀態差異”的差分接口。這樣,開發者不需要編寫大量底層存儲代碼,不需要關心分片的布點與糾刪的細節,就能享有“任何時候、任何地點、任何人都能復放”的能力。


在輕客戶端與錢包一側,DA 的整合把“可證明”延伸到“可取回”。錢包除了驗證 BTC 錨定與 Hemi 的包含證明之外,還可以在本地按需抓取某筆交易的原始輸入與事件日誌,複覈它是否真的與當前狀態根一致;對敏感操作,錢包可以要求“先取回—後執行”的策略,即只有當相關片段在可接受時間內成功取回並校驗,才放行高價值指令。對機構與做市,DA 的可取回時間直接映射爲風控參數:未錨定窗口×不可用片段比率共同決定保證金與額度,SLO 的趨勢決定資金的時間半徑;當 DA 偏離穩態,閾值自動收緊,直至恢復。


Hemi 也爲 DA 的“社會層問責”留出接口。公共看板不僅展示錨定覆蓋率與確認延遲,也展示分片可取回比率、平均取回時間、失敗分佈熱力圖與關鍵片段的優先保障狀態;異常事件在 T+1 歸檔時,附帶“如何獨立複覈”的指引,列出涉及區間、片段內容哈希、承諾路徑與推薦的取回源。這樣,任何人都能對一場 DA 事件進行獨立覆盤,而不必請求內部權限或依賴某個私有數據庫;當運營者聲稱“已恢復”,觀察者可以用同一套座標親自驗證,而不是被動接受結論。


與其說 DA 是“技術模塊”,不如說它是一種承諾的履約方式:承諾不僅告訴世界“我不會篡改”,還告訴世界“你隨時能拿到重放所需的全部材料”;承諾不僅寫在白皮書裏,還寫在哈希、索引與片段的可用性上。Hemi 用分層存取、內容尋址、糾刪重構與公共索引把這份承諾掰開揉碎、落到工程;用 SLO、覆盤與激勵把這份承諾裝進運營;再用錢包與 SDK 把這份承諾交到用戶與開發者的手裏。外部終局讓歷史“不可抵賴”,DA 讓歷史“隨時可再現”,兩者相扣,才能讓“真 BTC × 可編程性”的敘事從理念走到日常。


邊界依舊存在:極端擁堵會讓片段分發變慢,法域政策可能影響某些源的可達性,長期歸檔需要持續的治理預算與運營紀律;但邊界被顯性化,就意味着可治理。當 DA 偏離目標,系統有降級、有熔斷、有優先級切換、有公開證據與覆盤;當 DA 迴歸穩態,系統也有擴容與回補的節奏,會把歷史缺口逐步填平。重要的不是“永不出錯”,而是“任何重要的發生都能被任何人親自再現”。在這條“可複覈公共品”的道路上,Hemi 爲未來的每一次合作、審計與創新都預先寫好了共同語言:給我座標,我自己去驗證。