基础信息

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

重点关注项目

文档关键信息

TEE 验证器的设计

https://docs.ata.network/~gitbook/image?url=https%3A%2F%2F1690124894-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtYKuUrKWPlgYjy0suCeT%252Fuploads%252FynRN9jA9wkhKAL4nk9x1%252Fimage1.png%3Falt%3Dmedia%26token%3D48037549-4a1e-41d6-97df-9879c0053d95&width=768&dpr=4&quality=100&sign=3f2e5c96&sv=2

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

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

Intel SGX 的链上验证

远程认证允许以编程方式验证英特尔 SGX 飞地的属性和完整性。这是建立并确保其执行的任何计算或数据处理都是值得信赖的关键过程。
https://docs.ata.network/~gitbook/image?url=https%3A%2F%2F1690124894-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FtYKuUrKWPlgYjy0suCeT%252Fuploads%252FkELAGSfLK5H2Emk3Dxwh%252Fimage3.png%3Falt%3Dmedia%26token%3Dc19926a0-31b7-46fb-9bdb-0cab3e1d42c0&width=768&dpr=4&quality=100&sign=d3a64264&sv=2

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 工作流程

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

成分:

工作流程分为两部分:

  1. 设置

    • 按照Eigenlayer 的文档进行质押并注册成为 Multi-prover AVS 的运营商
    • 生成证明并注册为 TEE 证明者,不同的 TEE 技术,证明及其生成过程不同。例如,dcap-v3-attestation是验证 Intel SGX Dcap 证明的合约
  2. 在职的

    • 除了操作员处理任务之外,他们必须定期完成活性挑战,否则将被视为无效,其提交将被聚合器拒绝
    • 算子获取新任务并在 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

相关文档

https://scroll.io/blog/scaling-security
https://blog.ata.network/verifiability-as-the-missing-piece-for-ai-agents-in-web3-504839dca893
https://blog.ata.network/towards-a-common-tee-stack-71a7812a4bf9
https://blog.ata.network/automata-joins-the-superchain-ecosystem-launching-on-optimisms-op-stack-da25840cc658
https://atanetwork.notion.site/Multi-Prover-AVS-with-TEE-545319c42885489196142d966f0ede86