主要内容

0G Compute Network 介绍
0G Compute Network 架构以及可信执行环境
0G Compute Network 核心模块|Inference
0G Compute Network 核心模块|fine-tuning
0G Compute SDk 的集成方式

0G Compute Network 介绍

0G Compute 是一个去中心化的框架
——提供 AI 计算能力。

它是deAlOS 的一个重要组成部分。

0G Compute 是一个去中心化的市场，GPU 拥有者可以将计算能力出售给需要它的开发者，可以将其想象成 AI计算领域的 Uber。

0G deAl Service Marketplace

处理支付和验证账号Inference 服务注册以及验证Fine-tuning 服务注册以及验证
Provoder:运行计算服务的GPU拥有者
Customer:服务的使用者，通过SDK使用 provider 服务或者集成到自己的应用中

0G Compute Network 架构以及可信执行环境

首先介绍TEE

TEE在之前我有相关的学习笔记

在本课程中，主要是讲解三个属性：

数据机密性:未授权实体无法查看TEE内正在使用的数据
数据完整性:未授权实体无法添加、删除或更改TEE内正在使用的数据。
代码完整性:未授权实体无法添加、删除或更改在TEE中执行的代码。

如何构建一个信任链

流程图展现

图解：

基于Intel TDX（Trust Domain Extensions）技术的可信执行环境（TEE）架构及其远程认证（Remote Attestation, RA）流程。

分层结构解读（共四层，对应四个 RTMR）

Layer 0 (RTMR0): 硬件层

内容：CPU 微码、TDX模块、模块平台安全配置。
度量方式：由 TDX 硬件自动度量。
说明：这一层代表最底层的硬件信任根，确保 CPU 和硬件模块的配置是可信任的。

Layer 1 (RTMR1): VMM 层

内容：Hypervisor 代码、TDX 宿主环境。
度量方式：由 TDX 在 VMM（虚拟机监视器）中自动度量。
说明：确保 Hypervisor 和 TDX 运行环境未被篡改。

Layer 2 (RTMR2): Guest OS 层

内容：内核镜像，inltrd ,0g-TAPP
度量方式：由 TDX 在 Guest 启动时自动度量。
说明：确保 Guest 操作系统的启动过程可信。

Layer 3 (RTMR3): 应用层

内容：Docker Compose 文件、应用部署文件。
度量方式：通过0G-tapp主动度量
说明：确保应用程序及其部署配置的完整性。

Remote Attestation (RA) 流程

图中右侧展示了远程认证的过程：

生成 Quote：
- Quote 是由 Intel 签名的认证报告，包含所有层的度量值（RTMR0~RTMR3）。
- Signer（签名者）在 TEE 内部生成，且私钥不可更改、不可导出，确保其唯一性和可信性。
生成验证报告
Quote 验证（由 Intel 或验证服务完成）：
- 验证 Quote 的签名是否来自 Intel。
- 验证通过说明：
  - Signer 在 TEE 内部生成，私钥不可更改；
  - TEE 的内存和状态是可信的。
应用输出内容验证：
- 获取待验证的内容及其签名；
- 使用 Signer 的公钥验证签名；
- 确认内容确实来自该 TEE 环境，且未被篡改。

总结

这幅图描述了一个从硬件到应用的完整信任链：

通过硬件级度量（RTMR0~RTMR3）逐层建立信任；
通过 Intel 签发的 Quote 实现远程认证；
最终确保应用输出内容的可信性。

将验证报告转化为signer公钥直接验证

其中：

Signer:
在 TEE 内生成的密钥对

-公钥:通过 Tapp 暴露给外界

-私钥:仅在 TEE 内可用

硬件信息验证:RTMRO
程序验证(模型):RTMR3
消息返回的验证:signer 公钥对消息签名的验证

TDX 是 Intel 的一种硬件级安全技术，用于保护虚拟机（VM）的内存和状态不受其他软件（包括 VMM）的影响。

0G Compute Network核心模块|Inference

步骤

该流程完美融合了链下高性能计算与链上可信结算，确保只有在服务被正确提供后，支付才会被执行。

第一步：用户预存款

用户在区块链上的 智能合约 中预先存入一定数量的代币，作为后续支付服务费用的资金。
智能合约 会记录下该用户的地址和对应的余额。

第二步：用户签署并发送请求

用户构造一次服务请求（Request），其中包含元数据（Metadata），如：
- 用户地址（User Address）
- 单次序列号（Nonce，防重放）
- 服务类型（Service Type）
- 请求参数（Parameters）
用户使用自己的私钥对上述元数据进行签名，生成一个数字签名（Signature）。
用户将元数据和签名一同发送给链下的服务提供者（Provider）。

第三步：提供者验证并执行计算

服务提供者 收到请求后：
1. 验证签名：使用用户公钥验证签名是否有效，确保请求确实来自该用户且未被篡改。
2. 检查链上余额（可选）：查询智能合约，确认该用户的预存款余额足够支付本次服务。
验证通过后，服务提供者 在链下执行计算任务（如AI模型推理），并为用户生成结果。

第四步：提供者提交证明进行结算

服务提供者 将包含用户签名和请求执行轨迹（或结果承诺）的零知识证明（ZK-Proof） 提交到区块链上的智能合约。
此举的目的是向合约证明：“我已经为这个用户的这个请求完成了正确的计算工作”。

第五步：智能合约验证并支付

智能合约 自动验证提交的证明：
1. 验证签名：确认签名有效，且来自一个已存款的用户。
2. 检查Nonce：确保该请求是首次提交，防止重复支付。
3. 验证ZK证明（如果适用）：验证计算工作的正确性。
4. 检查余额：确认用户账户余额足够支付本次服务。
所有验证通过后，智能合约自动执行支付逻辑，将本次服务的费用从用户的预存款中划转给服务提供者。

流程总结图

1	用户预存款 → 用户签署请求 → 提供者计算（响应） → 提交证明（签名）至合约 → 合约验证并支付

这个流程的核心优势在于：

对用户而言：先服务，后付款。只有在提供者正确完成工作并通过链上验证后，钱才会被转走。
对提供者而言：无需担心用户赖账，支付由无法篡改的智能合约自动执行。
对网络而言：将复杂的计算放在链下，仅将关键的结算和验证放在链上，实现了高效与可信的平衡。

用时序图展现

0G Compute Network 核心模块|fine-tuning

数据(模型，数据集)的交换:0G Storage
执行环境的可验证性:部署在 TEE 中的broker + fine-tuning container
交易的原子性:交付物的通过 TEE内sealing key 加密。sealing key 和 fund 的交换由合约控制
整体架构解读
整个系统可以分为两大层面：
1. 链上（On-Chain）：基于 OG Blockchain，负责信任、结算和仲裁。
2. 链下（Off-Chain）：由 Serverless Engine 和各类 Containers 组成，负责高性能计算和实际的服务提供。
其核心工作流是：用户通过工具发起请求，由链下系统执行计算，最终通过链上系统达成可信的结算。

核心组件功能详解
1. 用户角色 (User Roles)
- Customer（客户）：需要使用AI微调服务的用户或开发者。他们支付费用以获得服务。
- Provider（提供者）：提供计算资源（如GPU）来运行微调容器的节点或组织。他们通过服务赚取收益。
- Broker（经纪人/协调者）：这是一个关键的中介组件。它负责接收任务，并在网络中寻找合适的Provider来执行任务，充当“任务调度者”的角色。它确保了系统的去中心化和效率。
2. 链下计算层 (Off-Chain Compute Layer)
这是实际工作进行的地方，是一个无服务器引擎，按需运行容器化任务。
- Serverless Engine（无服务器引擎）：整个链下计算集群的管理和调度核心。它自动处理资源的分配、扩展和容器的生命周期管理，用户无需关心背后的服务器。
- Containers（容器）：
  - Fine-tuning Container（微调容器）：这是执行具体AI模型（如LLaMA, Stable Diffusion等）微调任务的 Docker 容器。它接收客户数据和工作参数，输出微调后的模型或检查点。
  - 其他Containers：系统可能还支持推理容器、数据预处理容器等，构成一个完整的AI服务生态。
3. 接口与工具层 (Interface & Tooling Layer)
这是用户与系统交互的入口。
- CLI Tool（命令行工具）：为开发者提供的命令行界面，用于提交微调任务、管理任务状态和下载结果。
- API Server（API服务器）：提供一套标准的RESTful或GraphQL API，允许用户将自己的应用程序直接集成到0G的微调服务中，实现自动化工作流。
4. 链上核心层 (On-Chain Core Layer)
区块链负责建立信任和实现价值交换。
- OG Blockchain（0G区块链）：整个生态的信任基石。它可能是一条应用链或一条共享安全链。
- Fine-tuning Contract（微调智能合约）：部署在OG链上的核心合约。它负责：
  - 服务注册：Provider注册其服务信息和价格。
  - 任务管理：记录任务请求和分配结果。
  - 支付与结算：持有用户的预存款，并在Broker验证任务完成后，自动将费用从Customer支付给Provider。
  - 争议仲裁：验证提交的证明（如执行证明），处理可能出现的纠纷。
5. 数据存储层 (Data Storage Layer)
- OG Storage（0G存储）：这是一个去中心化的存储层，类似于Arweave或IPFS，但深度集成于0G生态。它用于持久化存储：
  - 微调数据集
  - 微调后的模型权重/检查点
  - 任务执行日志和证明
工作流程（举例）
1. 任务提交：Customer 使用 CLI Tool 或通过 API Server 提交一个微调任务，指定模型、数据和参数。该操作会调用 Fine-tuning Contract 并存入资金。
2. 任务调度：Broker 监听到链上新任务，通过 Serverless Engine 将其调度到一个可用的 Provider 节点上。
3. 执行计算：该节点的 Serverless Engine 启动一个 Fine-tuning Container，加载数据和基础模型，开始计算。原始数据和结果模型可能存储在 OG Storage 中。
4. 验证与结算：任务完成后，Provider（或Broker）会向 Fine-tuning Contract 提交任务完成的证明（如ZK证明或乐观挑战机制下的断言）。
5. 支付触发：合约验证证明有效后，自动执行结算逻辑，将 Customer 预存的费用支付给 Provider 和 Broker。
6. 结果获取：Customer 收到通知，从 OG Storage 下载微调好的模型。

流程图

0G Compute SDk 的集成方式

如何成为 network 的 provider

前提条件:
支持 TDX的英特尔 CPU

兼容的 NVIDIA GPU(支持 TEE 的 H100/H200)

用于支付 gas 费用的 0G 代币钱包

公共可访问的服务器
步骤:
构建 TDX Guest 镜像

准备 docker compose文件和配置文件

运行 TDX Guest 镜像

如何使用SDK

TS SDK
CLI
Web dashboard

Quick start

pnpm install @Oglabs/0g-serving-broker -g

export ZG_PRIVATE_KEY=<YOUR_PRIVATE KEY>

0g-compute-cli start-web --auto-build

这里更多建议直接去官网看

主要命令

一些补充

config文件：官网下载example后修改使用

dataset： file上传完后的”root“

datasize是计算出来的

1. 获取任务命令

命令：

1	6g-compute-cti get-task --provider @xf07240Efa67755B5311bc75784a061eDB47165Dd

解释：

6g-compute-cti: 这是 0G Compute 网络的命令行工具（CLI）名称。
get-task: 这是 CLI 的一个子命令，功能是查询并获取一个分配给当前提供者的计算任务。
--provider: 这是一个标志，用于指定执行此操作的提供者身份。
@xf07240Efa67755B5311bc75784a061eDB47165Dd: 这是提供者的以太坊风格地址，是其身份的唯一标识符。它用于在区块链上识别谁在请求任务。

目的：
Provider 节点使用此命令向网络（或 Broker/智能合约）查询：“有没有分配给我的新任务？”。系统会返回任务的详细信息，如需要计算的数据、模型ID等。

2. 对执行情况的追踪

命令：

1	0g-compute-cli get log -provider 0xf07240Efa67755B5311bc75784a061eDB47165Dd

3. 确认模型命令

命令：

1	0g-compute-cti acknowledge-model --provider @xf07240Efa67755B5311bc75784a061eDB47165Dd --data-path /tmp/output -dis

解释：

acknowledge-model: 这是另一个子命令，功能是确认模型任务已完成或就绪。可以理解为“提交任务完成证明”或“确认任务已接收并处理”。
--provider: 同样用于指定提供者身份。
--data-path: 这是一个非常重要的标志，用于指定已完成计算的任务结果在本地存储的路径。例如，微调好的新模型权重文件所在的目录路径。这个路径下的内容很可能随后会被上传到 OG Storage 以供验证和交付。
这步之后会得到一个压缩包

4. 解压（解密）

命令：

1	0g-compute-cti decrypt-model --provider @xf07240Efa67755B5311bc75784a061eDB47165Dd --data-path /tmp/output -dis --output /tmp/output2.zip

注意这里的output2是自己给压缩文件存放文件夹起的名

目的：
在 Provider 完成计算任务（如模型微调）后，使用此命令向网络声明：“你交给我的任务已经完成了，结果文件在这里（--data-path）”。这是触发后续链上验证和结算流程的关键一步。

主要内容

0G Compute Network 介绍

0G Compute Network 架构以及可信执行环境

如何构建一个信任链

流程图展现

分层结构解读（共四层，对应四个 RTMR）

Layer 0 (RTMR0): 硬件层

Layer 1 (RTMR1): VMM 层

Layer 2 (RTMR2): Guest OS 层

Layer 3 (RTMR3): 应用层

Remote Attestation (RA) 流程

总结

0G Compute Network核心模块|Inference

步骤

第一步：用户预存款

第二步：用户签署并发送请求

第三步：提供者验证并执行计算

第四步：提供者提交证明进行结算

第五步：智能合约验证并支付

流程总结图

用时序图展现

0G Compute Network 核心模块|fine-tuning

整体架构解读

核心组件功能详解

1. 用户角色 (User Roles)

2. 链下计算层 (Off-Chain Compute Layer)

3. 接口与工具层 (Interface & Tooling Layer)

4. 链上核心层 (On-Chain Core Layer)

5. 数据存储层 (Data Storage Layer)

工作流程（举例）

流程图

0G Compute SDk 的集成方式

如何成为 network 的 provider

如何使用SDK

主要命令

1. 获取任务命令

2. 对执行情况的追踪

3. 确认模型命令

4. 解压（解密）