以 TEE 作為 BitVM 類橋接器的驗證者：瓦解規範標籤分發問題

背景： 我們正在構建 Stax，一個具備 BitVM 等級橋接器的 BTC L2。自 2026-04-23 起，「僅限雙重簽署（Equivocation-only）」保護已在 signet 測試網上線，目前我們正在設計第三階段（Phase 3）的「固定謊言（Fixed-lie）」防禦。在進行設計審查時，我們得出了一個框架——如果該框架經得起推敲——它將消除一整類鏈上機制（強制揭露的 Taproot 葉子節點、Σ-響應、標籤分發通道）。在正式投入開發前，我們希望密碼學家能針對第 6 節中的七個問題提供審查意見。

本貼文總結了問題所在、框架的轉變，以及我們希望獲得第二意見的七個問題。完整設計文檔連結附於文末。

1. 標準 BitVM 等級橋接器模型下的問題

標準 BitVM 風格的提款流程：

1. 操作者（Operator） 發布 AssertTx，聲稱提款時的 L2 狀態，並逐位元（bit-by-bit）揭露 Lamport 原像（preimages）。
2. CSV 定時器。
3. 瞭望塔（Watchtowers） 在 CSV 窗口期間，可以發布 DisprovalTx 來罰沒保證金。這裡涉及兩類攻擊：
   • (a) 雙重簽署（Equivocation）：操作者在同一個 Lamport 位置發布兩個帶有衝突位元的 AssertTx。
   • (b) 固定謊言（Fixed lie）：操作者發布一個 AssertTx，其聲稱的狀態與規範的 L2 歷史不符。

雙重簽署處理起來很直接，也是 BitVM2 / Citrea / Bitlayer 目前採用的方案：在同一位置的任何兩個衝突揭露都會讓瞭望塔同時獲得兩個 Lamport 原像，從而罰沒保證金。

固定謊言則是尚未解決的問題。目前尚未有已部署的 BitVM 等級橋接器具備針對此問題的鏈上證明路徑——標準假設是「如果操作者只發布一個 AssertTx 且那是個謊言，則由鏈下機制（警報、社交）處理」。本貼文旨在填補這一空白。

一個天真的存款時金鑰對流程如下：
s_i^b = SHA256(“op-secret” || withdrawal_id || i || b)
即操作者自行生成 Lamport 原像。他們知道每個位元位置的兩個原像。因此，他們可以構造一個聲稱任何位元模式（無論真實或虛假）的 AssertTx，而腳本驗證器會接受它。鏈上機制沒有獨立的參考依據來判斷什麼才是規範的位元。

現有關於「強制葉子節點」（例如 Σ 協議風格的挑戰-響應葉子，將操作者綁定到公共規範線路標籤表）的文獻都假設規範標籤來自操作者之外的某處。標準建議是多方 DKG 儀式或可信設置。在我們的分析中，我們檢查的所有鏈上強制變體（擴展公鑰、獨立的 RevealTx、CSV 限制的相反原像）在沒有外部標籤生成器的情況下，都無法真正解決問題。我們在另一份設計文檔中記錄了這一點；參見 forcing_mechanism_design.md 的第 10.6 節。

因此問題變成了：規範標籤從何而來，誰能看到它們？

2. TEE 作為標籤生成器的兩種框架

出於單一團隊可行性的考慮，我們選擇了 TEE（預設平台為 AWS Nitro Enclaves）而非多方儀式。一旦決定使用 TEE，就有兩種可能的 API 設計。API 的選擇決定了整個鏈上足跡。

2.1 TEE 作為混淆者（TEE-as-Garbler，我們最初的框架）

• TEE.generate_circuit(vk) → (承諾 C, 標籤表 T = {(L_i^0, L_i^1)})
• TEE.attest() → 已認證的承諾 (C, code_hash, public_seed, …)

標籤隨後必須流向某處——流向瞭望塔，以便它們在檢測到虛假的 AssertTx 時能花費強制揭露的 Taproot 葉子。這引發了一個困難的子問題：如何在不洩露給操作者的情況下將標籤分發給瞭望塔？在一個無許可的瞭望塔集合中，任何人都可以運行瞭望塔，因此任何人都可以持有標籤——包括透過傀儡帳號操作的操作者。我們對此沒有完美的答案。

在「TEE 作為混淆者」模式下，你還需要：Taproot 樹中的強制揭露葉子、AssertTx 見證數據中的 Σ-響應生成、花費這些葉子的瞭望塔挑戰代碼、信標（beacon）機制，以及標籤分發通道本身。這是 forcing_mechanism_design.md 里里程碑 B 和 C 的主要內容。

2.2 TEE 作為驗證者（TEE-as-Verifier，我們提議的框架）

• TEE.generate_keypair_for_withdrawal(withdrawal_id) -> Lamport 公鑰 (47 KB), 認證
• TEE.release_preimages(withdrawal_id, 聲稱狀態 s, 聲稱證明 π)
  • → 如果 Groth16Verify(vk, ., π) 為 有效，則返回 { s_i^{bit_i(public_inputs(s))} }
  • → 否則返回錯誤 「INVALID」

TEE 既是混淆者也是驗證者。操作者唯一的 API 是「驗證此證明並給我其公共輸入的原像」。
關鍵點在於：

1. TEE 每個位元位置僅釋放一個原像——即與聲稱狀態的公共輸入位元值匹配的那一個。
2. TEE 永遠不會導出任何位置的另一個原像。
3. TEE 永遠不會導出與未經斷言狀態相關聯的原像。

固定謊言攻擊簡化為：

路徑	發生了什麼
A: 操作者提交 (虛假狀態, 垃圾證明)	TEE Groth16Verify → INVALID → 拒絕 → 操作者沒有原像
B: 操作者提交 (真實狀態, 有效證明)	TEE 返回真實原像 → AssertTx 斷言事實，未發生謊言
C: 操作者為虛假狀態偽造 Groth16 證明	歸約為 Groth16 的健全性（soundness）——這與 L2 已經信任的假設相同

謊言根本無法到達比特幣鏈。鏈上沒有任何東西需要透過強制葉子來捕捉和罰沒。

2.3 鏈上部分的簡化

組件	TEE 作為混淆者	TEE 作為驗證者
強制揭露 Taproot 葉子	需要	移除
AssertTx Σ-響應	需要	移除
瞭望塔強制揭露挑戰器	需要	移除
規範標籤分發通道	需要（開放性問題）	移除
Σ 協議變體的信標機制	需要	移除
雙重簽署 Lamport 葉子	不變	不變
TEE 認證基礎設施	需要	需要
橋接合約上的混淆者認證註冊	需要	需要

在「TEE 作為驗證者」模式下，瞭望塔僅需：TEE 認證摘要匹配、AssertTx 檢測、雙重簽署檢測（現有），以及針對殘餘的「TEE 被破解但未雙重簽署」場景的鏈下警報路徑。

3. 為什麼我們認為在 TEE 作為驗證者模式下，強制揭露葉子是多餘的

即使你保留了原始 Σ 協議設計中的強制揭露葉子（根據 phase3_tee_secrecy.md §3.1），在 TEE 被破解但未雙重簽署的場景中，瞭望塔仍然無法花費它們。葉子腳本是：
OP_SHA256 <expected_hash[i]> OP_EQUALVERIFY OP_TRUE

要花費它，瞭望塔需要 expected_hash[i] 的原像。在 TEE 模型中，原像存於 TEE 內部。瞭望塔從未擁有過它們。除了 TEE 以及 TEE 向其釋放原像的人（操作者）之外，任何人都無法花費該葉子。

這與 forcing_mechanism_design.md §10.6 中記錄的推遲理由結果相同，只是參與者不同。保留葉子作為「深度防禦」的論點站不住腳，因為在兩種場景中，持有原像的參與者是同一個（向 TEE 提交請求的人）。

4. 誠實的信任聲明

採用「TEE 作為驗證者」混淆器的第三階段 Stax 橋接器信任：
(a) 比特幣誠實大多數，(b) Celestia DA（自 2026-04-22 起已解決操作者扣留問題），(c) 至少 1 個誠實的瞭望塔用於雙重簽署檢測，(d) 用於固定謊言防禦的 Groth16 健全性，(e) TEE 廠商認證鏈（預設為 AWS Nitro；多廠商交叉認證推遲至 Phase 3.2c）。

假設 (e) 嚴格來說比 BitVM2 的 N-of-N 儀式更弱。為了單一團隊主網落地的可行性，我們接受這一點，並明確打算在儀式變得可行後（主網上線後）將其替換。

5. 深度防禦回退方案（如果你反對第 3 節）

如果評審者認為「構造時防禦固定謊言」不足夠，回退方案是保留強制揭露葉子，並透過認證的側向通道（在每個瞭望塔金鑰下進行 TEE 加密，透過 Celestia DA 發布）向瞭望塔分發規範標籤。

代價： 約 85 KB 公鑰，AssertTx 見證數據中增加 Σ-響應（約 3-5 KB），每個「切換與選擇（cut-and-choose）」挑戰位置增加一個額外的 Taproot 葉子（選擇 c=64 使得未檢測到謊言的機率約為 1/2^64），完整的 Σ 協議挑戰器 + 標籤分發通道實現，以及瞭望塔金鑰註冊表。

我們認為這無法乾淨地組合，因為「任何人都可以運行瞭望塔」意味著「任何人都可以持有標籤」，這又回到了「操作者透過傀儡帳號擁有標籤」的情況——但我們希望這個反對意見能受到挑戰。

6. 希望密碼學家關注的開放性問題

這些是提交實現前的阻礙性問題。除了認證基礎設施（在任一框架下都是正確的）外，我們尚未開始 Phase 3.2b 的代碼編寫。

Q1 — 將 Groth16 健全性作為唯一的固定謊言防禦。 在 TEE 模式下將固定謊言防禦簡化為「Groth16 健全性 + TEE 認證完整性」對於主網橋接器是否可接受？Zcash Sapling 和 Filecoin 的生產部署都依賴 Groth16 的健全性來承載數十億美元的價值，且該假設在持續審查下依然成立。我們並未引入新的密碼學假設——我們希望在橋接器背景下確認這一點，即斷言是在比特幣鏈上，而非以太坊鏈上。

Q2 — 用於防止雙重簽署的 TEE 狀態化。 TEE 是否應該在內部追蹤「我是否已為提款 ID X 釋放了位元模式 P 的原像」，並拒絕為同一提款釋放第二個模式？如果是，這就是對雙重簽署的預防而非檢測，雙重簽署 Lamport 葉子可以完全棄用——將第三階段簡化為「TEE 認證，別無其他」。代價：TEE 必須持久化存儲狀態（Nitro KMS 或 AMD SEV-SNP 等效方案）。多個 TEE 實例之間的競態條件需要處理（見 Q4）。

Q3 — TEE 到操作者的通道加密。 當 TEE 返回原像時，與操作者的通道必須加密（否則被動監聽者將獲得發布 AssertTx 的能力）。標準答案：飛地認證的 TLS（Enclave-attested TLS）——在飛地內生成臨時金鑰對，認證文件將 TLS 公鑰綁定到 code_hash，操作者在發送證明前驗證認證。是否有我們遺漏的 BitVM 特定細節——例如 TEE 重啟間的會話重放、TEE 升級時的金鑰輪換、操作者對哪個會話接收了哪些原像撒謊？

Q4 — 用於可用性的 TEE 複製。 單個 TEE 是橋接器可用性的單點故障（SPOF）。多個 TEE 實例（相同的 code_hash，相同的 master_seed）需要協調協議，以免為衝突的狀態釋放原像。使用「跨 N 個 TEE 的確定性主種子 + 逐實例狀態日誌 + 採納首個回應者」是否安全，還是會開啟攻擊者可以利用的競態？具體來說：如果實例 A 在時間 t 釋放了狀態 P 的原像，而實例 B 在 A 的狀態日誌同步前，於時間 t+ε 釋放了狀態 P' (P' ≠ P) 的原像，操作者是否剛好拿到了某些位元位置的兩半原像？

Q5 — 帶有活動存款的 TEE 升級。 如果我們發布新的混淆器二進制文件（不同的 code_hash），承諾給舊公鑰的現有存款將被卡住，除非 (a) 舊的 TEE 二進制文件無限期保持運行可用，或 (b) 我們提供遷移路徑（例如協作退款流程，然後在新的 code_hash 下重新存款）。在使用 TEE 的橋接器設計中，標準模式是什麼？對於 6-12 個月的存款壽命，(a) 是否可接受？(b) 是否有比「所有者觸發的遷移窗口」更簡潔的機制？

Q6 — 逐次提款 vs 批量認證的頻率。 鏈上認證摘要涵蓋了 (code_hash, public_seed, output_hash)。如果 output_hash 是單次提款的公鑰承諾，那麼每次提款都需要自己的鏈上摘要註冊——在大規模情況下這會變得很昂貴。逐批（Per-batch）認證可以聚合，但會失去一些粒度。按週期（Per-epoch）認證最便宜，但會引發哪些提款屬於哪次認證的問題。這裡正確的粒度是什麼，出錯時的失效模式又是什麼？

Q7 — 強制揭露葉子是否曾有用過？ 本文第 3 節認為沒有，因為在無許可的瞭望塔集合中，瞭望塔持有標籤意味著操作者（透過傀儡）也持有標籤。如果你能構建一個威脅模型，證明強制揭露葉子能提供鏈下警報 + 認證撤銷所無法提供的實質性深度防禦，我們很樂意傾聽——這將推動我們採用第 5 節的回退方案。

7. 我們的訴求

目前不需要完整的審計（那是稍後第四階段的支出）。現在我們希望：

• 對 Q1 進行現實檢查——第 4 節中的信任聲明是否誠實，還是我們迴避了某些問題？
• 對 Q2 提供第二意見——TEE 狀態化是否真的能取代雙重簽署檢測，還是 TEE 狀態損壞/回滾的極端情況會重新開啟漏洞？
• 歡迎任何具備 AWS Nitro Enclaves 實戰經驗的人針對 Q4 / Q5 提供意見——在生產環境中，有哪些設計文檔中沒提到的坑？

如果得到的答案一致認為「這沒問題」，我們將在大約 1 週內發布 Phase 3.2b。如果問題中暴露出漏洞，我們將採用第 5 節的回退方案或重新架構。

8. 連結

• 本貼文總結的完整設計文檔：docs/phase3_tee_secrecy.md（約 530 行）
• 相關文檔：docs/phase3_tee_design.md（TEE 平台選擇、威脅模型）
• 原始問題陳述：docs/forcing_mechanism_design.md §10.6
• 橋接器運行於比特幣 signet（自 2026-04-22 起上線）。TESTNET.md 記錄了雙重簽署 + DisprovalTx 流程、Celestia DA 嚴格模式拒絕，以及誠實的存款/鑄幣過程，並附有具體的 signet 交易哈希。

歡迎評論和私訊。Ethresearch 討論串是技術回覆的規範場所；我們將把實質性的反饋同步到文檔中並註明出處。