用于 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 论坛是技术性回复的官方渠道；我们会转发实质性反馈。
在文档中注明出处
