为什么会有 Attestation Middleware

I’m happy to translate the article for you, but I need the full text of the post. Could you please paste the content you’d like translated (excluding the source line you’ve already provided)? Once I have the article text, I’ll translate it into Simplified Chinese while preserving all formatting, markdown, and code blocks.

Source: …

什么是证明中间件？

证明中间件是一层位于应用程序和基础设施之间的软件层，用于验证系统身份、完整性和安全姿态的可信声明。可以把它想象成门口的保镖——不过它不是检查身份证，而是通过密码学手段证明硬件、软件或执行环境正是它声称的那样，并且运行在已知且可信的状态下。

证明是证明系统未被篡改的过程。中间件负责完成这项验证，免去应用程序从头自行实现的需求。

核心功能

• 身份验证 – 确认设备或服务的合法性。
• 完整性度量 – 检查软件和固件是否未被修改（通过密码学哈希和签名）。
• 证据收集 – 从硬件根信任获取证明报告：TPM、Intel TDX、AMD SEV、ARM CCA。
• 策略强制 – 在授予访问权限之前验证系统是否满足所需的可信等级。
• 令牌签发 – 生成符合标准格式的签名证明，如 IETF EAT（实体证明令牌）、CWT，或平台特定格式（Intel Quote 用于 TDX、AWS Nitro 证明文档）。

典型使用场景

• 机密计算 – 在发送敏感数据前验证可信执行环境（TEE）或机密虚拟机。没有证明，就无法确认代码真的在受信任硬件的受保护环境中运行。
• 零信任网络 – 在授予网络访问之前检查设备姿态。证明中间件将设备状态作为策略强制的一部分进行验证。
• IoT 设备接入 – 在发放凭证之前确认设备身份和固件完整性。示例：FIDO Device Onboard（FDO）、基于 TPM 的 Azure DPS 或 AWS IoT 供应。
• 云基础设施 – 超大规模云服务商使用证明来大规模验证工作负载完整性。
  • Microsoft Azure Attestation (MAA) – 用于 TEE 证明的托管服务。
  • Veraison – 基于 IETF RATS 架构的开源证明验证器。
  • Google Confidential Space – 在释放机密之前进行工作负载验证的证明中间件。
  • SPIFFE/SPIRE – 工作负载身份框架，其中证明是获取身份（SVID）的机制，而非最终目标。

链上证明中间件：现实检视

在链上直接构建证明中间件在理论上听起来很干净，但在实践中它 成本高、速度慢，且往往会带来更多问题。

• 庞大的密码学负载 – Intel TDX 报文、TPM 证明报告、AMD SEV‑SNP 报文体积都很大。在通用链上验证这些数据既慢又贵。
• 新兴优化 – zkVM（如 RISC Zero、SP1）和基于 SNARK 的证明聚合已将链上验证成本降至约 250 k gas（TEE 证明）和约 300 k gas（压缩证明）。高吞吐链（Solana、某些 L2）或专为 ZK 证明设计的 L1 让直接验证更可行，但 Ethereum/EVM 在处理复杂硬件证明时仍依赖混合架构。
• 解析难题 – 证据格式（CBOR 编码、平台特定二进制）并非智能合约环境原生支持。要在链上解析 Intel Quote 或 AWS Nitro Enclaves 证明文档，需要自定义预编译或昂贵的合约内逻辑。
• 缺失硬件锚点 – 信任锚（TPM、TDX、SEV‑SNP）位于物理硬件中。智能合约无法直接查询或验证硬件状态，必须有链下组件将硬件证据桥接到链上，这意味着仍然需要中间件。
• 动态证书链 – 验证过程涉及厂商根证书（Intel PCS、AMD KDS 等），这些证书会更新、撤销和轮换。将这些链维护在链上会增加运维负担并导致中心化风险。

Source: …

vector.

• 隐私关注 – 证明证据通常包含敏感的平台元数据（固件版本、微码、配置）。将这些数据上链后会永久且公开可见，可能帮助针对性的攻击。即使是证据的哈希值，如果攻击者了解平台配置，也可能被指纹化。

结果： 将证明上链的项目（例如用于可验证计算或 zkTLS）不可避免地采用 混合架构：

1. 链下中间件 收集并验证原始证据。
2. 它在链上发布 紧凑的证明或签名结果。
3. 链上只接收承诺，而不是完整的证据。

示例包括 Automata Network 和 EigenLayer 的 AVS‑基于方法，尽管该领域仍处于早期阶段，尚未出现统一的标准方案。

典型四层架构

证明中间件通常遵循一种实用的四层模型（不是正式标准，但被广泛观察到）：

1. 数据层 – 收集并传输原始证明证据（硬件报价、TPM 事件日志、固件测量、平台证书）。
2. 证明层 – 对数据生成加密证明或签名。
3. 身份层 – 将证明绑定到身份（例如 SVID、JWT、EAT）。
4. 发行层 – 发放令牌或凭证，供应用程序使用。

每一层都隔离了不同的问题，共同抽象出硬件复杂性、加密验证和身份绑定，使得消费证明的应用程序无需直接处理这些细节。

重要提示： 在实际系统中，数据层 通常 不 持久化证据。证据往往是瞬时传输的——在一次握手或 TLS 会话内完成，并且从不存储。需求是验证期间的完整性和可用性，而非长期归档。

Attestation & Identity Flow (Early 2026)

1. Evidence Collection

Goal: Capture the integrity of evidence at the moment of verification, not long‑term retention.

2. Verification

Takes the evidence and checks its semantic validity:

• Signatures back to vendor roots (e.g., Intel PCS, AMD KDS)
• Measurements against reference values
• Structural correctness of the quote

Note: The output is not an identity assertion—it merely confirms that the evidence is semantically valid (the quote was genuinely issued by this hardware, measurements match expectations, and the platform passed policy).

Generating SNARK/zkVM proofs for cheaper downstream verification or privacy‑preserving checks conceptually belongs here, but in production systems as of early 2026 this remains an exception rather than the norm.

3. Identity Translation

Translating verified proofs into identity assertions:

• A valid TEE quote becomes “this workload is running on genuine TDX hardware with these measurements.”
• At this layer, SPIFFE SVIDs, DID documents, or platform‑specific identity tokens are issued.

Critical point: Binding measurements to a specific workload identity is not a technical operation—it is a policy. The mapping between a set of measurements and a workload identifier must be defined somewhere, and that mapping itself is a trust anchor in the architecture.

4. Credential Issuance

Policy‑aware surface that produces consumable credentials such as:

• EAT tokens
• X.509 certificates
• JWT‑wrapped attestation claims

Responsibilities:

• Apply issuance policy (what claims are allowed, under what conditions, with what TTL)
• Manage revocation
• Serve as the only layer relying parties interact with—receiving a credential without needing to understand the underlying attestation mechanics.

5. Middleware Role

Attestation middleware abstracts the complexity of hardware roots of trust and protocol differences, making it easier for applications to rely on cryptographic proof instead of blind trust.

6. Architectural Pattern

The layered architecture — data → proof → identity → issuance — isn’t rigid dogma. It’s a practical pattern that emerged from real systems solving real problems: cost, performance, privacy, and operational complexity.

• Hybrid approaches dominate because they work:

  • Off‑chain handles the heavy lifting (evidence collection, cryptographic verification)
  • On‑chain serves as a transparent, tamper‑evident registry for attestation outcomes and policies.

• Fully on‑chain solutions are elegant in theory, but in practice they’re expensive, slow, and often introduce privacy risks that undermine the trust they’re meant to establish.

7. Practical Guidance

• If you’re building identity systems, confidential compute infrastructure, or zero‑trust networks—start with middleware.
• Use the chain where it adds value (commitments, revocation, settlement), not as the primary verification engine.