2025年1月 - 区块链中文技术社区

您正在查看: 2025年1月

Intel® SGX 与 Intel® TDX

2025-01-03　 Surou　阅读　 Ethereum-新手教程　 0 评论

1. Intel 软件防护扩展技术 Intel® SGX

Intel® SGX 的设计主旨是为用户应用程序提供可信的执行环境，使得应用程序有能力在用户地址空间中开辟一段特别的，受保护的内存空间，并对这段受保护的内存空间实行严格的访问控制和加密操作来保障数据机密性和代码完整性，确保即使是 Hypervisor、BIOS，操作系统等特权应用都不能随意访问这段地址空间，这一段地址空间被称之为 Enclave（称之为飞地）。

按照文章的前部分介绍，把应用程序部署在云上，需要验证程序确实运行在 TEE 里，具体更多的 SGX 技术细节，请参见 Intel 官方的技术文档。以及 Intel 架构开发者手册。验证包括本地验证和远程验证。本地验证指在同一个平台上，让不同的 Enclave 互相验证 Trusted Computing Base（TCB）。远程验证是指让一个平台中运行的 Enclave 向远端的信赖凭证者 Relying Party 证明自己的 TCB，证明自己运行在 SGX TEE 中，并且没有被篡改，同时证明当前的 CPU SGX 安全版本信息。

SGX 应用程序涉及两部分：安全区和非安全区。开发者或者用户可以把涉及敏感数据的处理、Key 的保护等都放在 Enclave 里面，从而将应用程序的代码、数据划分为受信任和不受信任的组件，因此开发者或者用户需要决定哪些组件应该置于 Enclave 内部，哪些置于 Enclave 外部。

2. Intel 信任域扩展技术 Intel® TDX

Intel® TDX 旨在将虚拟机（VM）与平台上的虚拟机管理程序（VMM）和任何其他非信任域 Trust Domain (TD) 的软件隔离，以保护 TD VM 免受各种软件的安全威胁。

TDX 的设计思路是将整个虚拟机 VM 放在一个 TEE 可信执行环境里，这样不管应用在私有云还是公有云上，不需要再对应用程序和数据做受信任和不受信任的划分和修改，只要操作系统支持就行。

TDX 基本思路就是引入新的 CPU 工作模式，然后通过对内存加密技术，将两个虚拟机用不同的 key 加密，同时 key 由 CPU 来直接进行管理。本质上讲，TDX 是通过两种技术方式来配合实现，一种就是新的 CPU 模式，叫做安全仲裁模式 Secure Arbitration Mode（SEAM），第二种是多密钥内存加密技术方式 Multi-key Total-Memory-Encryption（MKTME）。SEAM 模式使用新的指令，例如 SEAMCALL, SEAMRET, SEAMOPS, TDCALL 等来实现和 TD OS，以及 Host/VMM 交互。同时，提供特定区域的物理内存来保护 Intel TDX Module 代码模块，通过 Intel Authenticated Code Module (SEAMLDR)来装载。多密钥内存加密 MKTME 技术中，MKTME engine 通过 PCONFIG 指令来分配和设置各个 TD VM 的内存加密 Keys。TDX 将内存分为两个部分，私有和共享内存。在 TDX 下还是需要在外部加固的，加固的时候需要共享内存，这部分内存外部是可以读取的，因为有些虚拟化或半虚拟化设备需要和外部通信时，是需要 host 操作系统有能力访问来提供网络等服务的。

对比

当前的 Intel® TDX 认证的本质原理和 SGX 认证类似，也需要提供远程证明来验证其运行在 TEE 环境里。更多详细的 TDX 技术说明，请参见 Intel 官方网站的 Intel® TDX 技术规范和白皮书。

Intel® TDX 和 Intel® SGX 是用来解决不同问题的。TDX 是把整个软件包不做修改直接放到虚拟机上就能实现安全，而 SGX 关注应用层面，通过对飞地 Enclave 来保障机密性和完整性，用户根据业务场景需求可以选择不同的技术。

参考文档

https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/overview.html
https://www.intel.com/content/www/us/en/products/docs/accelerator-engines/software-guard-extensions.html
https://cloud.tencent.com/developer/news/918918

可信执行环境 (TEE) - Automata Network 代码分析

2025-01-03　 Surou　阅读　 Ethereum-开源推荐　 0 评论

基础信息

官网：https://www.ata.network/
GitHub： https://github.com/automata-network
docs: https://docs.ata.network/

重点关注项目

文档关键信息

TEE 验证器的设计

带有 Scroll 的 TEE Prover 的架构有两个主要组件：

SGX 证明器。一种链下组件，用于检查安全区域内区块执行后状态根是否与现有状态根匹配，并将执行证明 (PoE) 提交给 SGX 验证器。
SGX 验证器。确认 SGX 证明器提出的状态转换正确性的 L1 合约。它还验证 Intel SGX 飞地提交的证明报告，以确保证明器的完整性。

Intel SGX 的链上验证

远程认证允许以编程方式验证英特尔 SGX 飞地的属性和完整性。这是建立并确保其执行的任何计算或数据处理都是值得信赖的关键过程。

https://docs.ata.network/tee-overview/tee-prover

多重证明器 AVS 的工作原理

任务提交：协议构建者参与 AVS 并提交多重证明任务。在汇总场景中，这包括对 L2 向 L1 提交的批量交易进行采样和证明。
验证器注册：独立操作员注册以承担这些任务。操作员利用可重现的构建来运行 TEE 验证器，并通过 Automata 的TEE Compile进行验证，以确保构建过程的完整性。
执行和证明：每个操作员（证明者）在其选择的 TEE 平台上执行任务。生成证明以验证执行的正确性和完整性。
链上验证：将证明提交至区块链，智能合约充当证明人的角色并在链上进行验证。
奖励发放：成功完成任务后，向操作员发放奖励。

https://docs.ata.network/tee-overview/multi-prover-avs-eigenlayer

multi-prover-avs 代码分析

GitHub： https://github.com/automata-network/multi-prover-avs/tree/main

目录结构

═── contract：Solidity合约，包括AVS合约和证明层合约。
│ │ │ ── dcap-v3-attestation：英特尔 SGX 的 Dcap 认证链上验证库。
│ │ ── src：AVS 合约的源文件。
│ └── test：智能合约的测试。
═── operator：运算符实现。
═── aggregator：聚合器实现。
═── sgx-prover：TEE 证明器的 sgx 版本。

AVS任务描述

任务定义：寻求利用可信执行环境 (TEE) 内的独立执行来确定其正确性的状态转换或计算过程。

struct StateHeader {
    uint256 identifier;
    bytes metadata;
    bytes state;
}

这是提交给证明者的状态头结构，下面是详细解释：

identifier：处理任务的标识符，用于区分不同类型的任务，并用于计算各个算子的贡献
metadata：描述特定任务的元数据，例如keccak256(abi.encodePacked(chainID, blockNumber))用于证明特定区块高度的区块链状态的任务的元数据
state：TEE 证明器产生的最终状态，可以是区块链的根状态，也可以是 zk 电路证明的语句

AVS 架构

AVS 的架构包含：

Eigenlayer 核心合约
AVS 合同
- 未来将添加 ServiceManager，允许操作员提交任务、奖励和削减逻辑
鉴证合约
- 管理各种 TEE 证明器的注册/注销和活跃性，它将验证不同 TEE 平台的认证，例如 Intel SGX、AMD SEV、ARM TrustZone 等
- TEEProverRegister 是运营商和聚合器使用的认证层的接口
聚合器
- 汇总来自操作员的 BLS 签名并将汇总状态提交给 AVS
- 与自动机证明层交互，检查每个证明者（操作员）的有效性，未能通过证明验证或活性挑战的将被拒绝处理任务，直到其再次有效。
操作员
- 从 TEE 证明者处获取状态证明并将其提交给聚合器
TEE 证明器
- TEE 证明器可以证明给定任务的最终状态，例如 zk-rollup L2 的证明器将在 TEE 内部执行区块并在特定区块处生成根状态

AVS 工作流程

以下是工作流程的详细图表

成分：

工作流程分为两部分：

设置
- 按照Eigenlayer 的文档进行质押并注册成为 Multi-prover AVS 的运营商
- 生成证明并注册为 TEE 证明者，不同的 TEE 技术，证明及其生成过程不同。例如，dcap-v3-attestation是验证 Intel SGX Dcap 证明的合约
在职的
- 除了操作员处理任务之外，他们必须定期完成活性挑战，否则将被视为无效，其提交将被聚合器拒绝
- 算子获取新任务并在 TEE 内部完成计算
- 操作员签署最终状态并将其与签名一起发送给聚合器
- 聚合器将在接受运营商的提交之前获取其有效性
- 聚合器聚合所有 BLS 签名并提交给 AVS 服务管理器

TEE 委员会和法定人数

TEE 委员会是一组负责处理特定类型任务的法定人数。例如，在特定区块高度证明 Zk-Rollup 的根状态。操作员无需主动选择委员会，而是通过加入法定人数自动属于委员会。引入有利于TEE Committee操作员和任务更有组织的结构化。并为未来的增强奠定了基础，包括奖励机制和法定人数之间权益分配的约束。

TEE Quorum的概念与 Eigenlayer 使用的 Quorum 定义一致，但每个 Quorum 都与一个 TEE 平台相关联，例如 Intel SGX。每个 Quorum 都属于一个委员会，操作员可以选择加入任何 Quorum，但只有拥有必要证明的操作员的投票才会被聚合器接受。

如果您有兴趣加入以太坊主网上的 Multi-Prover AVS，请访问Operator 设置存储库。入职指南可在此处获取。

从源代码编译

操作员

go build -o out/operator ./cmd/operator

聚合器

go build -o out/aggregator ./cmd/aggregator

方案组成调研

zk: OP Succinct
- 文章介绍：https://blog.succinct.xyz/op-succinct/
- github: GitHub - succinctlabs/op-succinct: OP Succinct turns any OP stack rollup into a full type-1 zkEVM Ro
- docs: https://succinctlabs.github.io/op-succinct/introduction.html
- SP1介绍：https://blog.succinct.xyz/introducing-sp1/
- 客户用例：https://blog.conduit.xyz/op-succinct-zk-rollups/
DA: 使用EigenDA私有化部署
- GitHub - mantlenetworkio/mantle-v2
- mantleDA-datalayr/.github/developers.md at cfad73e881391bc50abae0815490fb7beabc32bf · mantle-xyz/man

TODO

op-succinct的部署，prover 实际机器成本，产出性能
EigenDA私有化部署