devgo.cn钱包让你签一笔交易，屏幕上只有一串十六进制。点下确认，资产就没了——这不是用户粗心，而是结构性的盲签。Anchorage Digital 和 Turnkey 给出的解法，是把交易解析器放进 AWS Nitro Enclave，让钱包拿到一份能验证「这段代码确实跑过、结果没被改」的密码学证明。
一、盲签的根子：钱包看不见交易的完整语义
钱包本身算力有限，复杂交易通常交给第三方服务解析。问题是，钱包怎么知道那个服务跑的是审计过的代码？合同、网络边界、厂商声誉都答不了这个问题，它们给不出密码学答案。
攻击者正是利用这一点：构造表面人畜无害、内部却藏着「授权某地址动用你的代币」「调用一个没见过的合约」「把转账拆进多步操作」的交易。模拟服务和交易解码器能缓解，但钱包仍然要无条件相信那个服务。
所以一个可信的解析器必须同时满足两件事：
- 正确性：解析逻辑就是审计过、批准过的那份代码，一个字节都没改
- 完整性：解析结果从服务传回钱包的路上没被动过
二、VisualSign 的三段信任链
Anchorage Digital 开源的 VisualSign Parser 是一套 Rust 跨链交易解析器，把原始交易转成结构化 JSON。目前支持以太坊及其 L2（Arbitrum、Optimism、Base、Polygon），以及 Solana、Sui、Tron，更多链在开发中。
一个直观的例子：Uniswap Universal Router 的一笔交易，测试用例里是 2470 个字符的十六进制。VisualSign 把它拆成 Permit2 授权、V2 swap 的具体数量与最小输出、手续费支付、WETH 解包这几步，每一步都带明确的地址、金额和过期时间。用户看到的是「你在授权多少额度给谁」，而不是一串乱码。
整条链路的走法是这样的：
1. 钱包客户端把原始交易发给 Turnkey API
2. API 转发到一台支持 Nitro Enclave 的 EC2 实例，实例里跑 QuorumOS 和 VisualSign 二进制
3. Enclave 内完成解析，用一次性 P-256 密钥给结果签名，并向 Nitro Hypervisor 申请 attestation document
4. 钱包客户端验证 attestation 和签名，确认响应来自真 enclave 里预期的那份软件
关键在第四步：Anchorage 不需要信任 Turnkey。attestation document 里带 PCR（Platform Configuration Register），是对 enclave 镜像、内核、应用二进制的密码学度量。客户端拿 PCR 和「可复现构建」算出的期望值一比，就知道跑的是不是那份代码。
三、真正的支点不是 TEE，是可复现构建
很多团队上 TEE 会卡在同一个地方：每次重新构建，二进制哈希都变，PCR 跟着变，验证策略就得跟着改，最后维护成本高到放弃。
Turnkey 的解法是把可复现构建当成硬约束：同一份源码，不管谁在哪台机器上编译，产出的二进制必须逐字节相同。这样 PCR 就是确定值，验证策略一次写死，后续重建不用更新。
这一步听着像工程洁癖，实际是整个信任模型的地基——没有它，attestation 只能证明「某个 enclave 跑过」，证明不了「跑的是我们审计的那份代码」。
还有一个容易被忽略的细节：PCR 不是只有一个值，镜像、内核、应用各有一组度量。验证方通常会把「允许的 PCR 组合」写成一条策略，而不是逐个比对哈希。策略更新本身就是一次安全操作，得有审计、有回滚，否则谁都能往白名单里塞一个新版本。
顺带说，这套东西是 2025 年 1 月 Turnkey 白皮书里那套密钥管理架构的延伸。Anchorage 没有自建 enclave 集群，而是把 VisualSign 部署进 Turnkey Verifiable Cloud，等于把「可验证」这件事外包出去，自己只保留审计和验证的责任。
这也回答了一个常见的疑问：用了 enclave，是不是就等于把安全托付给了云厂商？恰恰相反。TEE 提供的只是隔离和度量，真正让人敢用的是「度量值可预期」加「谁都能复算」。云厂商能挡住物理攻击和宿主机上的其他租户，但挡不住它自己换一版镜像——PCR 会变，验证方就会拒绝。
四、这套模式能搬到链外吗
原文明确说可以，并列出三个方向：策略评估、合规检查、交易分类。共同点是「结果要被别人相信，但计算过程不能交给对方」。
对普通后端团队来说，这套思路可以抽象成三个判断条件：
- 这段逻辑的输出会被外部当作决策依据（放款、风控、扣款、内容审核）
- 对方没有能力或不愿意自己跑一遍
- 出错或篡改的代价，远大于多一层证明的成本
三条都成立，才值得上可验证执行。只满足一两条，普通的审计日志加签名就够了，硬上 TEE 属于过度设计。
判断时还要多问一句：验证方是谁，它有没有能力自己跑一遍策略？如果对方只是「懒得查」而不是「查不了」，那么把证明塞给他，他也不会验，最后还是回到看品牌、看合同。可验证基础设施的前提，是存在一个愿意并且能够做验证的对手方，这一点在选型时最容易被跳过。
五、落地前要算清的三笔账
- 构建账：可复现构建不是开关，是纪律。编译器版本、依赖锁、时间戳、路径都得钉死，团队要专门维护。
- 性能账：enclave 内的 CPU 和内存有上限，复杂解析要评估吞吐；每次跨 enclave 调用都有额外开销。
- 运维账：PCR 变更要走发布流程，验证方也要同步更新期望值。这条链路一旦不同步，用户看到的就是「验证失败」。
VisualSign 的价值不只是一个防钓鱼工具，它示范了一件事：在「必须相信第三方」的场景里，密码学证明可以替代合同和信誉。对做支付、风控、密钥管理的团队来说，这是一个值得抄的架构，而不是一个只能围观的案例。
原文：https://aws.amazon.com/blogs/architecture/how-anchorage-digital-and-turnkey-verify-code-with-aws-nitro-enclaves/
内容与图片版权归原作者所有 · 原文: https://aws.amazon.com/blogs/architecture/how-anchorage-digital-and-turnkey-verify-code-with-aws-nitro-enclaves/