跳至正文返回首页Anchorage 与 Turnkey 把交易解析放进 Nitro Enclaves：证明“跑的是哪份代码”
- 要解决的问题：钱包无法原生解析复杂交易语义，用户只能对一串十六进制盲签，攻击者借此把代币授权、异常合约调用或转账藏进多步操作。已有的模拟服务与解码器要求钱包信任第三方，却无法验证对方实际运行了哪份代码、返回结果是否被改动——这需要“正确性”与“完整性”两项保证。
- 产品与部署：Anchorage Digital 开发的 Rust 解析器 VisualSign 把原始交易转为结构化 JSON，已支持以太坊及其 L2（Arbitrum、Optimism、Base、Polygon）以及 Solana、Sui、Tron；它被部署在 Turnkey 运营的 Nitro Enclaves 内，Anchorage 自身不运行解析逻辑。示例中一段 2,470 字符的 Uniswap Universal Router 交易被拆成 Permit2 授权、V2 兑换、费用支付与 WETH 解包，逐步列出地址、数量与到期时间。
- 验证链路：钱包把原始交易发给 Turnkey API，转发至运行 QuorumOS 与解析器的 enclave；enclave 用临时 P-256 密钥签名响应，并向 Nitro Hypervisor 申请证明文档；钱包端校验证明与签名，将文档中的 PCR 与可复现构建推导出的值比对。可复现构建保证同一源码每次编译出字节一致的二进制，PCR 因此确定，验证策略无需随重建更新。
- 隔离属性：Nitro Enclaves 复用 Nitro Hypervisor 隔离 vCPU 与内存，父实例无法访问；无持久存储、无网络接口、无 DNS、无元数据服务，仅通过本地 vsock 与父实例通信；AWS、Turnkey、Anchorage 任一方的运维都无法进入 enclave 读取客户数据。
- 开源工具：Anchorage 开源了 Go 库 awsnitroverifier，完成 CBOR 解析、COSE 签名校验、证书链回溯至 AWS Nitro 根证书，并把“格式错误”与“验证失败”分成两层错误，失败时给出 PCR 不匹配、证书过期、链校验失败等具体原因；其上的 visualsign-turnkeyclient 提供三级递进的验证（P-256 签名、启动证明、完整 manifest）。
- 可迁移的模式：核心是“证明即访问凭证”——HSM 依据已验证的证明放行密钥，而非依据网络身份、API Key 或运维信任。文章给出非区块链场景：金融机构在 enclave 内跑制裁筛查，产出“确为受审计软件处理过该数据”的密码学证据；医疗机构在无网络、无持久存储的 enclave 内跑诊断模型。这种拆分也让区块链专家与安全团队各自负责其领域，无需互相开放权限。
- 边界：Turnkey Verifiable Cloud 目前为私有测试，公开材料未披露延迟、吞吐与大规模策略下的性能数据；该模式解决的是“哪份代码处理了数据”，不覆盖业务逻辑本身的正确性。
🔗 AWS Architecture Blog | VisualSign Parser | awsnitroverifier
