用於 BitVM 風格橋接的 TEE 作為驗證器：簡化規範
標籤分佈問題
背景：我們正在構建 Stax，一個帶有 BitVM 級橋接的BTC L2 服務。自那時起，Signet 就已啟用僅含歧義保護。
2026年4月23日，我們正在為第三階段設計固定陣地防禦方案。在設計過程中，我們最終確定了一個框架結構。
如果它經得起推敲，就能徹底消除一整類鏈上機制（強制揭示的Taproot葉子、Σ響應、標籤）。
分發渠道）。我們希望在最終確定方案之前，先請密碼學家對第 6 節中的七個問題進行審核。
本文總結了問題、框架轉變以及我們希望徵求第二意見的七個問題。完整的文檔是：
鏈接在文末。
- 標準 BitVM 類橋接模型下的問題
標準BitVM式提款流程：
操作員發佈 AssertTx，聲稱在提款時 L2 狀態，逐位揭示 Lamport 原像。
CSV計時器。
在 CSV 窗口期內，守望者可以發佈 DisprovalTx 來削減債券。這裡有兩種攻擊類型比較重要：
（a）歧義 — 操作員發佈兩個 AssertTx，其在同一個 Lamport 位置具有衝突的位。
（b）固定謊言——操作員發佈一個 AssertTx，其聲稱的狀態與規範的 L2 歷史記錄不匹配。
模稜兩可的做法很簡單，也是 BitVM2 / Citrea / Bitlayer 目前提供的：任何兩個相互矛盾的顯示都會產生歧義。
瞭望塔是蘭波特的預兆，這削弱了債券。
固定謊言是尚未解決的問題。目前沒有任何已部署的 BitVM 級橋接程序提供鏈上反駁路徑——標準假設是“如果
該運營者只發布了一條 AssertTx，而且這是個謊言，鏈下機制（警報、社交媒體）會處理它。這篇文章旨在揭露真相。
差距。一個簡單的存款時密鑰對流程存在
s_i^b = SHA256(“op-secret” || withdraw_id || i || b)
也就是說，算子生成自己的 Lamport 原像。他們知道每個比特位置上的兩個原像。因此，他們可以
構建一個 AssertTx，聲稱任何比特模式（無論真假），腳本驗證器都會接受它。鏈上機制沒有
為規範部分提供獨立的參考依據。
現有文獻探討了強制葉子節點（例如，Σ協議風格的挑戰-響應葉子節點將操作員綁定到公共規範線路）。
標籤表）都假定規範標籤來自操作符外部。標準建議是採用多方參與的方式。
DKG 儀式或可信設置。在我們的分析中，我們考察的所有鏈上強制變體（擴展公鑰、單獨）均未發現任何問題。
RevealTx（CSV門控相反原像）實際上無需外部標籤生成器即可解決問題。我們已在文檔中記錄了這一點。
單獨的設計文檔；請參閱forced_mechanism_design.md 的第 10.6 節。
因此問題就變成了：規範標籤從何而來，誰可以看到它們？
2. TEE 作為標籤生成器的兩種框架
我們選擇 TEE（默認平臺為 AWS Nitro Enclaves）而不是多方參與的儀式，是出於單人團隊可行性的考慮。一旦你
對於TEE，有兩種API設計方案可供選擇。API的選擇決定了整個鏈上架構。
2.1 TEE 作為垃圾處理器（我們最初的框架）
TEE.generate_circuit(vk) → (commitment_C, label_table T = {(L_i^0, L_i^1)})
TEE.attest() → AttestedCommitment(C, code_hash, public_seed, …)
標籤必須流向某個地方——瞭望塔，這樣當它們檢測到謊言時，就可以用強制揭露的根鬚葉片來揭露真相。
AssertTx。這引出了一個棘手的子問題：如何在不洩露標籤給操作員的情況下將標籤分發給監視塔？
無需許可的瞭望塔設置，任何人都可以運行瞭望塔，因此任何人都可以持有標籤——包括操作員本人通過襪子持有。
傀儡瞭望塔。我們沒有明確的答案。
在 TEE 作為 Garbler 的情況下，您還需要：Taproot 樹中的強制顯示葉子節點、AssertTx 見證中的 Σ 響應生成以及 Watchtower。
爭議處理代碼會消耗這些資源，包括信標管道和標籤分發渠道本身。這就是大部分內容。
forced_mechanism_design.md里程碑 B 和 C。
2.2 TEE 作為驗證器（我們提出的框架）
TEE.generate_keypair_for_withdrawal(withdrawal_id)-> Lamport 公鑰 (47 KB)，證明
TEE.release_preimages(withdrawal_id, claims_state s, claims_proof π)
→ { s_i^{bit_i(public_inputs(s))} } 如果 Groth16Verify(vk, ., π) 有效
→ 否則報錯“無效”。
TEE既是混淆器又是驗證器。該運算符唯一的API是“驗證此證明並給出其公共輸入的原像”。
至關重要的是：
TEE 只會為每個比特位置釋放一個原像——與所聲明狀態的公共輸入的比特值相匹配的原像。
TEE 從不在任何位置導出其他原像。
TEE 從不導出與從未斷言的狀態相關的原像。
固定謊言攻擊可簡化為：路徑 發生情況 A：算子提交 (state_lie, garbage_proof) TEE Groth16 驗證 → 無效 → 拒絕 → 算子沒有原像 B：算子提交 (state_truthful, valid_proof) TEE 返回真原像 → AssertTx 斷言真值，未發生謊言 C：算子偽造 state_lie 的 Groth16 證明 簡化為 Groth16 可靠性——與 L2 已信任的假設相同
謊言根本無法觸及比特幣。鏈上沒有任何東西可以通過強制刪除來捕捉和清除。
2.3 這將導致鏈上組件 TEE 作為 Garbler、TEE 作為驗證器、強制揭示 Taproot 留存項（需要）、移除 AssertTx Σ 響應（需要）、移除 Watchtower 強制揭示爭議器（需要）、移除 Canonical 標籤分發通道（需要，未解決）、移除 Beacon 管道（用於我們的 Σ 協議變體）、移除 Equivocation Lamport 留存項（未改變）、未改變、TEE 證明基礎設施（需要）、在橋接合約上註冊 Garbler 證明（需要）。
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向其發佈原像的對象（即操作員）之外，任何一方都無法使用這張葉子。
與forcefing_mechanism_design.md §10.6中記錄的延期理由相同的結果，但行為主體不同。防禦機制
保留葉子的深度論證站不住腳，因為在兩種情況下，擁有原像的行動者是同一個行動者（
（接受TEE測試的人）。
4. 信任聲明，坦誠相待
第三階段的Stax橋接器採用TEE作為驗證器，並啟用混淆器信託：
(a) 比特幣誠實多數，(b) Celestia DA（運營商限制自 2026 年 4 月 22 日起關閉），(c) ≥1 個誠實守望塔
歧義檢測；（d）Groth16 固定謊言辯護的可靠性；（e）TEE 供應商認證鏈（AWS Nitro by
默認；多供應商交叉認證推遲到第 3.2c 階段）。
假設 (e) 嚴格弱於 BitVM2 的 N-of-N 儀式。我們接受它以證明單人團隊主網的可行性，並明確指出
計劃在主網上線後，待儀式條件允許時將其退役。
5. 縱深防禦後備方案（如果您對第3節提出異議）
如果審查員認為“施工時的固定謊言”不足以構成充分的抗辯理由，則退而求其次是保留強制披露的條款並進行分發。
通過經證實的側信道（使用每個瞭望塔密鑰進行 TEE 加密，並通過 Celestia DA 發佈）將規範標籤發送到瞭望塔。
成本：約 85 KB 公鑰，AssertTx 見證中的 +Σ 響應（約 3-5 KB），每個 cut-and-choose 挑戰位置增加一個 Taproot 葉節點（c 的選擇取決於所需的可靠性；c=64 意味著存在約 1/264 的未被檢測到的謊言），完整的 Σ 協議爭議器 + 標籤分發
通道實現，以及瞭望塔密鑰註冊表。
我們認為這種寫法無法清晰地組合，因為任何人都可以運營瞭望塔，這意味著任何人都可以持有標籤，這會導致代碼崩潰。
向通過傀儡賬號擁有標籤的操作員發出拒絕通知——但我們希望這種拒絕受到質疑。
6. 我們需要密碼學家關注的未決問題
這些是提交實施前的障礙。除了認證基礎設施之外，我們尚未開始編寫 3.2b 階段的代碼。
（無論從哪個角度來看都是正確的）。
問題1——Groth16 規則是唯一的固定球位防守規則。將 TEE 規則下的固定球位防守規則簡化為“Groth16 規則 + TEE 規則”是否可行？
對於主網網橋來說，“證明完整性”是否可以接受？ Zcash Sapling 和Filecoin 的生產環境都依賴於 Groth16 的可靠性。
這些部署項目價值數十億美元，而且這一假設經受住了持續的審查。我們並沒有引入新的……
密碼學假設——我們希望在橋接上下文中確認這一點，其中斷言是鏈上比特幣，而不是鏈上
以太坊。
Q2 — TEE 的狀態保持機制，以防止歧義。TEE 是否應該在內部跟蹤“我已經發布了原像”之類的信息？
是否允許使用“partnership_id X under bit pattern P”並拒絕發佈同一提款的第二個模式？如果是，這是否屬於預防
與其說是檢測，不如說是含糊其辭，而蘭波特留下的含糊其辭完全可以棄用——將第三階段簡化為“TEE”。
僅此而已。成本：TEE 必須持久保持狀態（Nitro KMS 或 AMD SEV-SNP 等效項）。多個方面的競爭條件
TEE 實例需要處理（參見 Q4）。
Q3 — TEE 到操作員的信道加密。當 TEE 返回原像時，到操作員的信道必須加密。
（否則，被動竊聽者將能夠發佈 AssertTx）。標準答案：經過安全區認證的 TLS — 臨時密鑰對
在安全區內部生成的證明文檔將 TLS 公鑰綁定到 code_hash，操作員對證明進行身份驗證。
在發送證明之前，是否存在我們忽略的BitVM特有的細節——例如，TEE重啟後的會話重放？
TEE升級下的關鍵輪換，操作員謊稱哪個會話接收到了哪些原像？
第四季度——TEE 複製用於保證活性。單個 TEE 是橋接活性的一個單點故障。多個 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 的橋接設計的標準模式是什麼？是 (a)
6-12 個月的押金期限可以接受嗎？(b) 的機制是否比“車主觸發的遷移窗口”更清晰？
Q6 — 單筆提現與批量認證節奏。鏈上認證摘要涵蓋（代碼哈希、公鑰種子、
output_hash）。如果 output_hash 是單次提現的公鑰承諾，則每次提現都需要其自身的鏈上摘要。
註冊——規模化後成本會很高。按批次註冊可以聚合數據，但會損失一些粒度。按週期註冊成本最低，但會增加成本。
關於哪些提款屬於哪項證明的問題。這裡合適的細化程度是多少？失效模式是什麼？
搞錯了嗎？
問題7——強制顯示標籤的樹葉會有什麼用處嗎？本文第3節認為不會，因為帶有標籤的瞭望塔意味著
通過傀儡操作者擁有標籤（在一個無需許可的瞭望塔集合中）。如果您可以構建一個強制威脅模型。
如果揭示機制能夠提供鏈下警報+證明撤銷所不具備的、非同尋常的縱深防禦，我們很想聽聽這樣的說法——
這將迫使我們採取第 5 條的退而求其次的措施。
7. 我們提出的要求
並非全面審計（那是稍後的第四級支出）。目前我們想要的是：
對問題 1 進行現實檢驗——第 4 節中的信任聲明是誠實的，還是我們忽略了某些事情？
關於問題 2 的第二個意見——TEE 狀態性是否真正包含了歧義檢測，還是說 TEE 的特殊情況包含了歧義檢測？
國家腐敗/政策倒退是否會重開大門？
有第四季度/第五季度 AWS Nitro Enclaves 實際操作經驗的人——生產環境中存在哪些設計階段沒有體現的問題？
文檔？
如果所有回覆都一致認為“沒問題”，我們將在大約一週內發佈 3.2b 階段版本。如果他們提出以下問題之一，我們將另行通知。
如果發現漏洞，我們將執行第 5 節中的回退措施或重新架構。
8. 鏈接
本文總結的完整設計文檔位於： docs/phase3_tee_secrecy.md （約530行）
相關文檔： docs/phase3_tee_design.md （TEE平臺選擇、威脅模型）
原始問題描述： docs/forcing_mechanism_design.md第 10.6 節
Bridge 運行在比特幣簽名幣上（自 2026 年 4 月 22 日起上線） 。TESTNET.md記錄了模稜兩可 + DisprovalTx 流程，以及 Celestia。
DA 嚴格模式拒絕，以及誠實的存款/鑄幣，每個存款/鑄幣都有具體的簽名交易哈希。
歡迎留言和私信。Ethresearch 論壇是技術性回覆的官方渠道；我們會轉發實質性反饋。
在文檔中註明出處
