Tenzro Li.Fi MCP

Tenzro Network

Tenzro 是面向 AI 的开放式分布式执行层。 推理、Agent 和工作流运行在由独立节点组成的网络中，而非某一家公司的服务器上。任何机器都可以提供模型服务、出租闲置算力并存储数据——一份质押即可覆盖所有角色，TNZO 负责结算这一切：使用者从余额中付款，服务提供者则将收益存入余额。底层是实现开放执行的基底层：多虚拟机结算（EVM、SVM、Canton/DAML）、跨链互通、统一身份（TDIP）和统一结算资产（TNZO）。

Tenzro 是什么？

面向 AI 的开放式分布式执行层。 Tenzro 是推理发生、Agent 行动、工作流运行的地方——这一切都在由独立节点组成的网络中进行，而非某一家公司的服务器上。其核心理念很直接：AI 需要一个不受任何单一提供商控制的运行环境。这意味着任何人都能加入的节点、为所用付费并通过提供服务赚取收益的方式，以及任何人都能验证的证明。如今，推理和算力被封闭在不透明的中心化 API 之后；身份在每个协议边界处都要重新绑定；价值从 EVM 转移到 Canton 时也无法脱离托管。Tenzro 从协议层面解决了这些问题。

• 多角色节点：一个节点、一份质押、多种角色。节点可以同时为 AI 模型提供服务、出租闲置算力并存储数据——一份质押覆盖其承担的所有角色。算力租赁需通过可用性证明，并按周期计费；存储需通过可检索性证明，并按字节-周期计费。无论哪种情况，使用方都从自己的 TNZO 余额中付款，提供方则将收益存入自己的 TNZO 余额。
• 去中心化 AI + 算力编排：Agent 和人类可以通过单一协议层市场发现并访问 AI 推理（聊天、视觉、音频、预测、嵌入、分割、检测）、可租赁算力容量，以及由 TEE 支持的机密计算（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC），并享受按次计费、信誉评分和链上可验证性。提供方拥有自主权——任何人都可以运行模型、开放端点或贡献算力，并直接赚取 TNZO。推理路由器（价格／延迟／信誉／加权策略）以及 Agent 生成和蜂群编排原语，让 Agent 无需信任任何单一方即可组合多模型、多提供方工作流。
• 通用身份（TDIP）：人类、受委托的 Agent 和自主 Agent 共用一个 DID，并可在 EVM（通过 ERC-8004 镜像）、SVM、Canton（CIP-26 用户绑定）、AP2 mandates、x402 micropayments 和 OAuth/DPoP 上使用——身份相同、委托范围相同、撤销界面相同。
• 通用钱包（FROST-Ed25519 + ML-DSA-65 hybrid PQ）：通过阈值机制保障安全、可由硬件证明，并在三种 VM 视图间共享同一余额——EVM 上的 wTNZO ERC-20、SVM 上的 SPL 适配器、Canton 上的 CIP-56 持有记录。无桥接风险，无流动性碎片化。指针模型原生资产。
• 通用结算（TNZO）：桥接费用、推理费用、托管、微支付通道、训练运行资助，以及跨链目的地原生费用（通过 Chainlink 支持的桥接费用预言机），均以 TNZO 计价和核算。
• 将跨链触达作为线级原语：LayerZero V2、Chainlink CCIP、Chainlink CCT、Wormhole + NTT、deBridge DLN、LI.FI、Hyperlane V3、Axelar GMP、Babylon Bitcoin staking 和 Canton，全部封装在同一个带有 BridgeFeeHint 的 ERC-7683 信封后。用户只需签名一次，由求解器选择桥接方案。
• 多 VM 执行：EVM（revm + 9 个标准预编译 + 7 个 BLS12-381 EIP-2537 + 13 个 Tenzro 预编译）+ SVM（solana-svm，含 SPL Token Program 分发）+ Canton 3.5+ DAML——每份合约、每条指令、每个命令都使用相同的身份、钱包和 TNZO 余额运行。
• 将 AI 推理、生成和训练作为协议层经济活动：提供方通过提供模型服务（聊天、视觉、音频、预测、嵌入、分割、检测）、渲染扩散图像和视频任务（Tenzro Media Gen）、运行 TEE enclave，以及为可验证训练运行（Tenzro Train）贡献 GPU 算力来赚取 TNZO。推理结果、结算和身份声明可通过基于 KoalaBear 域的 Plonky3 STARKs（透明设置，具备后量子猜想安全性）在链上验证，也可由硬件 enclave（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC）证明——两种方式均通过 ZK_VERIFY 和 TEE_VERIFY 预编译锚定。
• 将人类作为对等身份类别：HITL 升级处理、监护人法定人数恢复、AP2 购物车／意图／支付 mandates 和委托范围，都是线级原语，而非适配器层功能。

Tenzro Network 也是 Open Agent Network（OAN） 的参考实现——这是一组面向人类与 Agent 共存的混合网络标准（TNIP-001..022）。OAN 提供治理框架；Tenzro Network 则是可运行的实现。该线级协议保持开放，供其他实现采用。

以算力为货币

Tenzro 将 AI 算力转化为一种经济交换单位，以 TNZO 计价、结算和验证。四类应用共用同一套身份、支付和结算底层：

• 代币化 AI 推理。 任何人都可以运行 AI 模型（聊天、视觉、音频、预测、嵌入、分割、检测），并将其提供到市场。用户和 Agent 按 token（或按次推理）付费；提供方直接赚取 TNZO。机密版本运行在 TEE 飞地（Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC）中。微支付通道让高频、低额计费更高效。
• 代币化 AI 训练（Tenzro Train）。 采用解耦外部同步的数据并行协议进行去中心化、可验证训练。GPU 提供方贡献算力并赚取 TNZO；赞助方从链上托管资金中为运行提供资金。每个被接受的外部梯度都会生成一份签名回执，每次运行都会在链上最终确定一个运行根承诺。第一阶段优先支持时间序列，采用简单的均值聚合、质押绑定和 Open 信任层级；拜占庭容错聚合、多区域扩展和驻留于 TEE 的数据则在路线图中。
• 代币化媒体生成（Tenzro Media Gen）。 扩散图像和视频任务会附带价格上限发布，由工作节点认领并渲染，随后根据一份关于生成内容的签名回执结算。工作单位为像素步（width × height × steps × frames）。对于 Transformer 拆分为高噪声和低噪声专家的模型，可由两台各自都无法容纳整个模型的加速器共同渲染：两个部分之间只传递一个中间 latent，支付金额则按每个部分签署的去噪进度占比拆分。
• Agentic 金融。 自主 Agent 使用同一套 TDIP 身份、FROST-Ed25519 阈值钱包和委托范围来发现提供方、协商、支付，并以 TNZO 结算。AP2 授权、x402 微支付、ERC-8004 免信任 Agent 注册表（通过单次 TDIP 写入同步映射至 EVM、SVM 和 DAML），以及 ERC-4337 v0.8 智能账户，均运行在 Tenzro 共识中。

可验证性不可或缺。推理结果、结算和身份声明可以通过 KoalaBear 域上的 Plonky3 STARK 证明（透明设置、具备后量子安全性的推测性健全性），或通过硬件飞地进行证明；两种方式都通过 ZK_VERIFY 和 TEE_VERIFY 预编译合约锚定在链上。Tenzro 在一个开放执行层中统一推理、算力租赁、存储、训练、Agent 结算、身份、验证和跨链覆盖范围——它既不是原始 GPU 租赁，也不是子网协调，而是 AI 运行所涉及的完整应用面。

组合优势

这些组成部分单独来看，在其他地方都能找到。Tenzro 将它们组合成一个网络，其优势在于：可验证的 AI 推理和训练、机密计算、多模态服务，以及 Agent 结算，全都基于同一身份、同一结算资产和同一共识层。

Tenzro 在一个网络中组合了 EVM + SVM + Canton/DAML，而 DAML 正是机构级 RWA 应用（受监管的代币化国债、银行存款代币、CIP-56 结算）正在汇聚的执行环境。这种广度构成了底层基质；运行其上的 AI 执行层则是关键所在。

在这一底层基质上，零售 Agent 轨道（AP2 授权、x402 微支付、ERC-8004 无需信任的 Agent、ERC-4337 v0.8 智能账户）与机构级 RWA 轨道（Canton DAML、CIP-56 代币、DvP 结算）共用同一身份（TDIP）、同一结算资产（TNZO）和同一共识层。

还有两项值得关注的架构决策：

• 机密 Agent 计算是共识原语，而非附属组件。 通过 TEE 证明的验证者在基于声誉权重的领导者选举抽选中获得 1.5× 倍数；TEE_VERIFY 预编译合约会在链上验证真实的 Intel TDX、AMD SEV-SNP、AWS Nitro 和 NVIDIA GPU CC 报告——经证明的执行直接内置于共识中，而非作为中间件附加在非 TEE 链上。Tenzro 共识采用两阶段 HotStuff-2，并结合基于声誉权重的提议者选举、用于抵御尾部分叉的无背书证书，以及用于每条安全关键消息的 Ed25519 + ML-DSA-65 混合后量子签名。
• TNZO 是原生指针模型资产。 一个余额，三种 VM 视图（EVM 上的 wTNZO ERC-20、SVM 上的 SPL 适配器、Canton 上的 CIP-56 持有凭证）——没有桥接风险，也没有流动性碎片化。已通过 CAIP-2（tenzro 命名空间）、SLIP-44（1414421071 / 0xd44e5a4f）和 W3C DID（did:tenzro）在上游注册。

完整架构请参阅 docs/WHITEPAPER.md 和 docs/SPECIFICATION.md。

架构

                    +-------------------------------------+
                    |         User Interfaces             |
                    |      CLI / SDKs / MCP / A2A         |
                    +--------------+----------------------+
                                   | JSON-RPC + HTTP
                    +--------------v----------------------+
                    |           tenzro-node               |
                    |   RPC (855) + MCP (526) + A2A (41)  |
                    +--------------+----------------------+
                                   |
        +----------+---------------+---------------+----------+
        |          |               |               |          |
   +----v---+ +---v----+ +-------v--------+ +---v---+ +---v----+
   |Network | |Consensus| |  Multi-VM      | |Storage| | Model  |
   |(libp2p)| |HotStuff2| | EVM+SVM+DAML  | |RocksDB| |Registry|
   +--------+ +--------+ +----------------+ +-------+ +--------+
        |          |               |               |          |
   +----v----+----v----+----------v-----+---------v-+--------v---+
   |  Crypto  |  TEE   |   ZK Proofs   | Identity  | Payments   |
   | Ed25519  | TDX    |  Plonky3 STARK| TDIP/DID  | MPP/x402   |
   | Secp256k1| SEV-SNP|  KoalaBear/FRI| W3C VC    | Tempo      |
   | BLS12-381| Nitro  |  Poseidon2    | KYC Tiers | Stripe/CB  |
   | AES-GCM  | GPU CC |  No setup, PQ | Delegation| EIP-155    |
   +----------+--------+---------------+-----------+------------+

工作区 — 32 个 Crate

Crate	描述
tenzro-types	核心类型、常量、原语（无内部依赖）
tenzro-crypto	Ed25519、Secp256k1、AES-256-GCM、X25519、BLS12-381、FROST-Ed25519 门限签名（RFC 9591）、VRF（RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI）
tenzro-tee	TEE 抽象：Intel TDX、AMD SEV-SNP、AWS Nitro、NVIDIA GPU CC、Intel Tiber Trust Authority，支持 X.509 证书链验证
tenzro-zk	基于 KoalaBear 域的 Plonky3 STARK（Poseidon2 + FRI）、四种预构建 AIR（推理／结算／身份／pq-qc——最后一种为仲裁证书提供简洁的后量子支路，因为 ML-DSA-65 签名无法像 BLS 那样聚合）、无需可信设置、后量子安全
tenzro-network	libp2p P2P 网络（控制平面）：gossipsub、Kademlia DHT、对等节点管理、速率限制、Identify + AutoNAT v2 + Circuit-Relay v2 + DCUtR，实现无需许可的 NAT 穿透
tenzro-iroh	iroh 数据平面（内容寻址传输）：基于 QUIC + iroh-blobs 的 IrohBackedResolver、DA 后端、梯度存储、密封分片存储、通过 tenzro/a2a ALPN 实现的 A2A-over-iroh。解析 tenzro://{blob,gradient,shard,manifest,memory}/...。由 TDIP 锚定的 Pkarr 发现（EndpointId 与 TDIP 密钥逐字节一致）
tenzro-storage	RocksDB，支持列族、Merkle Patricia Trie、快照和 fsync 持久性
tenzro-wallet	FROST-Ed25519（RFC 9591）2-of-3 门限钱包 + ML-DSA-65 混合后量子支路、Argon2id 密钥库、交易构建器、nonce 管理、密钥清零
tenzro-keystore-unlock	与平台无关的 KeystoreUnlocker trait，用于在重启后重现钱包密钥库密码（StaticUnlocker、EnvUnlocker）；无平台依赖，因此可纳入 wallet/node 的公共 API，而不会引入 OS crate
tenzro-device-key	硬件支持的不可导出 P-256 设备密钥（macOS/iOS Secure Enclave，由 Touch ID / Face ID 保护）：生物识别预哈希签名，以及用于派生持久密钥库密码的稳定机密封装／解封装
tenzro-auth	身份验证引擎：AAP（Agent 身份验证协议）、DPoP、RAR（丰富授权请求）和 WebAuthn 证明验证——验证设备实际证明了哪些关于持有密钥硬件的信息，并针对固定的供应商根证书进行校验，而非依赖平台账户
tenzro-consensus	HotStuff-2 BFT：三阶段 PREPARE → COMMIT → DECIDE、按质押权重计算的仲裁（每个验证者上限为 10%；共识投票仅供质押验证者参与，服务角色可获得服务证明奖励）、按 TEE 权重进行领导者选择（1.5×）、双重签名检测 + 罚没、批次可用性证书（提案排序的是证书哈希，而非交易正文）、由仲裁门控的 ZK 承诺证明（仅当 ZK_VERIFY 承诺带有基于独立重新验证生成的 2f+1 质押权重 BLS 证书时才予以接纳）
tenzro-vm	多 VM：EVM（revm）+ SVM（Anza solana-svm TransactionBatchProcessor，需启用 svm-full feature）+ DAML、Block-STM 并行执行、EIP-1559、ERC-4337 AA、ERC-7579 模块化验证器、EIP-7702 Type-4 委托注册表、Permit2 SignatureTransfer + witness（兼容 ERC-7683 的免 gas 流程）、Secure-Mint 预编译合约（代币化资产的 1:1 储备证明不变量）、标准 EVM + EIP-2537 BLS12-381 + Tenzro 预编译合约（TEE_VERIFY、ZK_VERIFY、VRF_VERIFY，位于 0x1007）
tenzro-token	TNZO 代币经济：金库、质押、治理、epoch 奖励、流动性质押（stTNZO）
tenzro-identity	TDIP：统一的人类／机器身份、W3C DID 文档、可验证凭证、委托范围、GDPR 第 17 条删除权（tenzro_forgetIdentity）
tenzro-payments	Agent 支付协议。加密货币通道（在链上结算）： AP2 v0.2（Google/FIDO）授权签名 + 验证 + 配对校验、MPP（Stripe + Tempo）会话、x402 v1（Coinbase）HTTP 402 及资源集市（注册／发现／注销付费资源、报价验证、幂等支付 id），支持 tenzro-hybrid、exact-eip3009、permit2 和 erc7710 方案；Stripe SPT（SharedPaymentToken）发行 + 验证，支持 TDIP cap-resolver + ERC-8004 ReputationRegistry 跨写入；Tempo（EIP-155 签名）；ERC-8004（2026 年 1 月修订版）无信任 Agent 注册表（Identity / Reputation / Validation，共 22 个接口）。银行卡通道（Tenzro 提供身份 + 委托 + 审计；银行卡网络结算法币）： Visa TAP（Trusted Agent Protocol）、Mastercard Agent Pay。HTTP 402 中间件、RFC 9421 HTTP 消息签名。
tenzro-agent	AI Agent 基础设施：A2A 协议、MCP 桥接、能力证明、持久化存储
tenzro-agent-kit	高级 Agent SDK：使用技能、工具和支付协议组合 Agent
tenzro-model	模型注册表、感知模态的推理路由（价格／延迟／信誉）、内容寻址、对等节点优先的模型分发（使用 BLAKE3 哈希的权重、tenzro://blob/<hash> URI，HfArtifactDownloader 通过 iroh blobs 从对等节点获取，并在必要时回退到 HuggingFace；ModelHashRegistry 采用先记录者优先 + 加载前验证）。已在磁盘上的多 GB 工件通过引用发布（publish_path / ImportMode::TryReference），因此提供服务的模型不会被重复复制到 blob 存储中。持久化目录。通过 llama.cpp 在所有 ggml 后端上进行本地推理（CUDA、ROCm、Metal、Vulkan、SYCL、OpenCL、WebGPU、MUSA、CANN、OpenVINO、zDNN、BLAS——每次构建使用一种，否则使用 CPU）。多模态 ONNX 运行时：预测（TimesFM 2.5）、视觉（CLIP、SigLIP2、DINOv3、DINOv2）、文本嵌入（Qwen3-Embedding、EmbeddingGemma、BGE-M3、Snowflake Arctic）、分割（SAM 3 / 3.1、SAM 2、EdgeSAM、MobileSAM）、检测（RF-DETR、D-FINE）、音频 ASR（Moonshine v2、Distil-Whisper、Whisper-v3-turbo、Parakeet-TDT、Canary-1B-Flash）、视频（编码器脚手架）。许可证层级门控：宽松／署名／自定义商业／非商业。
tenzro-cortex	循环深度推理工作器（RDT/MoE）：HTTP sidecar 架构、签名收据、证明套件、基于 gossip 的工作器发现、按推理深度定价的计费
tenzro-training	Tenzro Train 协议层（数据并行，外层同步解耦）：聚合规则（Mean、LoraAlternating、TrimmedMean、CoordinateMedian、Krum）、带自适应学习率的 Nesterov 外层优化器、分块 Int8/Int4 梯度量化、分块 top-k 稀疏化（使用 2 位编解码器和本地误差反馈累加器处理被丢弃的部分）、流式分片同步、流水线训练器组、同步器状态机、链上运行根承诺。与位于 integrations/trainer/ 的 Python 参考训练器配套。
tenzro-media-gen	Tenzro Media Gen 协议层：扩散任务队列、工作器注册表、按像素步骤定价、拆分专家声明与潜变量移交、按比例分配支付、三种签名承诺（任务 id／移交／收据）、内容寻址输出存储。与位于 integrations/media_gen/ 的 Python 参考工作器配套。
tenzro-settlement	托管、微支付通道、批次结算、争议解决和流式租赁托管：基于时间的容量租赁，包含租户押金 + 由签名可用性证明门控的逐 epoch 流式释放；提供方质押为活跃租赁提供跨期一个 epoch 风险敞口的抵押，并在未履约时从质押中补足损失
tenzro-storage-provider	基于 iroh 内容寻址传输的去中心化存储：提供方守护进程（接受／提供对象）、nonce 绑定的可检索性证明挑战、系统性 Reed-Solomon 擦除编码（复制是 k=1 的特例）、通过可检索性证明后按字节流式计量（ServiceType::Storage）、由能力门控的检索（AccessPolicy + 可选的机密密封）
tenzro-cluster	由模型、存储和数据库服务共享的、与引擎无关的本地网络集群基底：可达性层级、经探测的链路成本图、确定性的最近邻排序和 HRW 汇合放置——每个函数都基于测量输入确定，因此成员无需协调器往返即可收敛到相同计划
tenzro-database	托管数据库协议层（与引擎无关，无驱动程序）：DatabaseDescriptor、跨本地／LAN 集群／网络层级的放置、引擎目录（PostgreSQL、Qdrant、Milvus、Valkey、Dgraph、Lance、Tantivy）。五种引擎有驱动程序（PostgreSQL / Qdrant / Valkey 作为连接到由运维人员运行的引擎的轻量无状态客户端；Lance / Tantivy 嵌入进程运行）；Milvus 和 Dgraph 仅列入目录，尚未关联驱动程序。按引擎验证配置、AccessPolicy + 机密密封、托管连接凭据、tenzro/databases gossip
tenzro-bridge	跨链：Wormhole NTT（Guardian 仲裁验证器）、LayerZero V2、Chainlink CCIP + CCT、deBridge DLN、Li.Fi、Canton DAML、Hyperlane V3（主权 Tenzro-ISM）、Axelar GMP（连接 Cosmos / Move / Stellar）、Babylon Bitcoin 质押
tenzro-events	支持重放、webhook 和 websocket 的事件溯源与订阅系统
tenzro-workflow	多方工作流运行时：编排 Canton DAML 收据和链上交易选择器 0x01000040–0x0100004B
tenzro-wasm	用于沙箱化 Agent 技能和 MCP 工具的 WASI 0.2 组件主机：与语言无关、基于能力、确定性燃料计量、内容寻址组件身份
tenzro-node	完整节点二进制文件：JSON-RPC（932 个方法）、MCP（535 个工具）、A2A（40 项技能）、Web API
tenzro-cli	CLI 工具：108 个命令模块，支持交互模式和完整 RPC 覆盖

快速开始

从 Homebrew 安装

brew tap tenzro/tap
brew install tenzro

从源代码构建

# Requires Rust 1.85+
cargo build --release -p tenzro-node -p tenzro-cli

# Binaries at:
# ./target/release/tenzro-node
# ./target/release/tenzro

加入网络

# Guided setup — join the public network (consume, provide, or validate),
# create a local or sovereign network, or join an existing private network
tenzro setup

# Join — provisions identity + FROST-Ed25519 threshold wallet + hardware profile
tenzro join --name "Your Name"

# Mint a DPoP-bound bearer JWT for authenticated RPC/MCP access
tenzro auth onboard-human --display-name "Your Name"

# Request testnet TNZO
tenzro faucet

# Check balance
tenzro wallet balance

# Send tokens
tenzro wallet send --to <address> --amount 10

# Interactive mode
tenzro interactive

运行节点

# Validator node
./target/release/tenzro-node --roles validator --data-dir ./data

# Light client
./target/release/tenzro-node --roles light --data-dir ./data

# One node serving inference and holding storage under one stake
./target/release/tenzro-node --roles ai,storage --data-dir ./data

运行自己的网络

# Bootstrap a self-contained network: validator keyset, schema-v1 genesis,
# service unit, and the exact join command for each peer
tenzro setup --path local --network-name lab

# Join an existing private network
tenzro setup --path private --genesis ./genesis.toml --bootstrap <multiaddr>

成为提供方

接入你的 GPU、集群或数据中心，从网络需求中获利。节点运行后（tenzro-node --roles ai），只需一条命令即可完成所有操作：

tenzro join --provider

硬件检测、钱包配置、水龙头注资、模型提供方层级要求的 1,000 TNZO 算力保证金、提供方注册、默认定价，以及拉取并提供适合你机器的最大目录模型，全部自动完成。你的算力会发布到提供方 Gossip 主题，推理需求会路由到你，并按每次调用以 TNZO 结算。

AI 推理

# List available models
tenzro model list

# Serve a model as a provider
tenzro model serve --model gemma3-270m

# Start an interactive chat session
tenzro chat

协议服务

节点会公开 4 个协议服务，另有 6 个生态 MCP 服务：

核心服务

服务	端口	协议	端点
JSON-RPC	8545	HTTP	31 个以上命名空间中的 932 个方法（兼容 EVM + Tenzro 扩展，包括多模态 AI：预测、视觉、文本嵌入、分割、检测、音频、视频；生成式媒体；MoE 分片服务；LAN 集群；托管数据库；应用托管：站点、函数、机器、租约；CAIP 发现；EIP-7702 委托；Permit2；Secure-Mint；Capital Intent；工作流）。同一监听器还提供兼容 OpenAI 的 HTTP 路由 /v1/chat/completions、/v1/responses，以及受 HTTP 402 门控的 /api/paid/chat/completions
Web API	8080	REST	验证（/verify/*）、/status、/faucet、/health、/chat、/providers、/discovery/resources、OAuth 令牌/内省/撤销、通行密钥钱包
MCP	3001	Streamable HTTP	535 个工具 + OAuth 2.1
A2A	3002	JSON-RPC + SSE	包含 40 项技能的 Agent Card、任务流式传输

生态系统 MCP 服务

服务	端口	工具数	覆盖范围
Solana	3003	14	Jupiter 兑换、SPL 代币、Metaplex NFT、Bonfida SNS
Ethereum	3004	17	Chainlink 数据源、ENS、ERC-8004 Agent、EAS 证明
Canton	3005	23	DAML 合约、CIP-56 代币、DvP 结算、用户/参与方管理、IDP 管理
LayerZero	3006	21	V2 消息传递、OFT、Stargate、Value Transfer API
Chainlink	3007	21	CCIP、数据源/数据流、VRF v2.5、自动化、函数
LI.FI	3008	9	跨链聚合、路由、Gas 估算

身份验证（分级）

• 公共工具（无需身份验证）：get_node_status、list_models、get_balance、resolve_did、debridge_search_tokens 等。
• 写入工具（需要身份验证）：send_transaction、create_wallet、stake_tokens、register_identity 等。
• 身份验证方式：OAuth 2.1 + DPoP (RFC 9449) — 通过 tenzro_onboardHuman / tenzro_onboardDelegatedAgent / tenzro_onboardAutonomousAgent 签发 bearer JWT。每个请求都携带 Authorization: DPoP <jwt>，并附上新鲜的 DPoP: <proof> 标头（每个请求使用 JWS-compact，依照 RFC 7638 绑定到 JWT 的 cnf.jkt 指纹）。RAR 范围 (RFC 9396) 会将 JWT 限定为特定工具和金额。
• API 密钥（由运营方签发）：RPC 运营方通过 tenzro_createApiKey（需管理员令牌）签发 tnz_... 密钥，并通过 X-Tenzro-Api-Key 提交。范围控制会调用第三方付费资源的方法：canton（Canton JSON Ledger API）、chainlink（Chainlink Data Feeds 的 Ethereum 主网 RPC 配额 + 桥接费用预言机 + 各适配器赞助），以及供将这些服务变现的运营方使用的 evm / svm / inference / tee / bridge。CF_CANTON_ANALYTICS + CF_BRIDGE_ANALYTICS 中的每租户计数器。对 chainlink 范围的方法实施 GCRA 速率限制。
• 撤销：tenzro_revokeJwt（通过 jti 撤销单个令牌）或 tenzro_revokeDid（沿操作链级联撤销）。
• 配置：TENZRO_MCP_AUTH=tiered（默认）| false（开发）| full（所有工具都需要身份验证）

主要功能

多虚拟机执行——三个 VM，一个状态机

只选择一个 VM 的链会迫使所有工作负载适配该 VM。Tenzro 运行三个 VM，并按交易类型进行路由。三者共享同一状态、同一种 Gas 代币（TNZO）、同一 TDIP 身份和同一共识机制。

• EVM——流动性与可组合性。 以太坊接口面向最广泛的现有合约和工具生态。Tenzro 集成了 revm，并按规范 EIP 支持所有标准预编译（ecRecover、SHA-256、RIPEMD-160、Identity、ModExp、EC_ADD、EC_MUL、EC_PAIRING、BLAKE2F），以及全部七个 BLS12-381 预编译（EIP-2537），用于原生的、符合共识要求的签名聚合。Block-STM 通过 MVCC 并发控制实现并行交易执行，并在出现争用时自动回退为顺序执行。EIP-1559 动态费用市场会销毁基础费用。原生原语通过协议感知型预编译扩展 EVM：TEE_VERIFY（硬件证明及供应商证书链验证）、ZK_VERIFY（对链上 Plonky3 注册表进行 O(1) 承诺查询）、VRF_VERIFY（RFC 9381 ECVRF）、IBC_VERIFY（IBC-Eureka 轻客户端查询）、Tenzro 预编译集（TNZO_BRIDGE、TOKEN_FACTORY、CROSS_VM_BRIDGE、STAKING、GOVERNANCE、NFT_FACTORY、MODEL_INFERENCE、SETTLEMENT、位于 0x1021 的全局供应量核算、位于 0x1022 的模块注册表）、ERC-4337 v0.8 账户抽象、EIP-7702 Type-4 委托、带见证绑定的 Permit2 SignatureTransfer，以及 ERC-7579 模块化验证器模块（社交恢复 / 会话密钥 / 支出限额 / WebAuthn 通行密钥 / 绑定 TEE）。
• SVM——吞吐量与延迟。 Solana 接口面向需要亚秒级最终确定性和高吞吐量的工作负载——DEX 路由、Agent 间微支付、实时链上结算。Tenzro 集成 Anza 的 solana-svm TransactionBatchProcessor（需启用 cargo 功能 svm-full），让 Solana SBF 程序无需修改即可运行；未启用该功能时，SPL Token 适配器、跨 VM 原生程序和 PDA 派生仍可正常工作，而 SBF 路径会返回 VmError::SvmFullFeatureRequired。SPL Token 程序映射到原生统一代币注册表——SVM 上的兑换与 EVM 上的转账在同一余额空间中结算。这两个 VM 之间无需桥接。
• Canton DAML——隐私与机构级结算。 机构金融体系已在 Canton 上结算代币化现金、货币市场基金、债券、股票、国债和场外衍生品。Tenzro 直接支持 Canton 3.5+ JSON Ledger API v2。CIP-56 Canton Coin 持仓可与 TNZO 双向转换；CIP-26 用户管理会将每个租户绑定到各自的 party，并由服务端强制执行 CanActAs 权限；DAR 上传、party 分配、命令提交和活跃合约查询，都可通过与 EVM 和 SVM 调用相同的节点 API 接口完成。Canton 的隐私模型意味着只有交易签署方能看到交易正文；Tenzro 则提供跨 VM 编排和公开承诺。
• 跨 VM 代币模型——Sei V2 指针。 TNZO 只有一个规范的原生余额。EVM 侧的 wTNZO ERC-20 指针和 SVM 侧的 wTNZO SPL 适配器共享同一底层余额——两者之间无需桥接，也没有包装 / 解包装之分或流动性碎片化。Canton CIP-56 持仓可通过 Canton 桥接适配器双向转换。从应用的角度来看，无论钱包上次使用的是哪个 VM，它都只有一个 TNZO 余额。
• 组合效果。 Agent 在代币化国债（Canton）和稳定币付款（EVM）之间结算 DvP 时，可通过一个身份将整个流程作为一项工作流执行。Agent 为 Solana DEX 兑换付款并在 Tenzro 共识上提交凭证时，使用的也是同一个 TNZO 余额。跨 VM 协调是工作流原语，而非应用代码。

去中心化 AI 基础设施

协议层将 AI 算力视为协同调度的资源，而非中心化服务。 Tenzro 不提供自有模型。 本 README 中提及的所有模型——Qwen、DeepSeek、GLM、Kimi、Gemma、MiniMax、FLUX、Wan、LTX、SAM、CLIP、Whisper 等——都是网络_支持_的第三方检查点，并非第一方或专有模型。服务路径与模型无关：load_model 接受 GGUF 路径，llama.cpp 会根据文件自身的元数据推导架构，因此 ModelArchitecture 枚举仅用于提供信息（显示和筛选），而非允许列表。没有目录条目的模型会使用文档所述的默认值进行服务。

精选目录为你提供的是元数据和便利性，而非使用权限。目录中的每个条目都经过挑选，确保无需门控——无需登录 HuggingFace 即可下载——因此新节点无需运营者持有账户，也能获取并提供模型服务。

模型配置可插拔，而非强制使用统一架构。 不同模型确实有不同需求，而采用最低公分母配置，要么无法满足需求较高的模型，要么给简单模型增加负担。因此，目录条目由一组可选且带默认值的配置项组成，每个模型只声明实际适用的配置：仅在模型有多模态投影器时才配置 mmproj；仅在模型支持推测解码时才配置配对的草稿模型和 MTP 类型；仅在模型为稀疏模型时才配置 MoeShape；仅在该模型系列不适用默认值时才配置采样用的 ServingProfile；仅在模型具有思考模式时才配置 ReasoningPolicy。如果模型自身的聊天模板在上游存在问题，TemplateFix 会指定一个随附的替代版本——目录声明_使用哪项_修正，推理客户端提供文件——而不是由运行时针对该模型进行特殊处理。任何未设置的配置项都会回退到文档所述的默认值，因此未纳入目录的 GGUF 仍可提供服务。生成式媒体也采用同样的结构，条目会针对每条流水线记录像素步数定价、专家拆分边界和帧数限制；有些模型通过专门编写并固定到特定上游版本的配置提供服务，而非使用通用路径。

模型列入目录，并不意味着它已通过端到端验证。 注册表的范围比已在真实硬件上实际运行过的模型更广，我们不会暗示情况并非如此。测试仍在进行：如果发现某个模型需要通用路径未提供的配置——例如修正后的聊天模板、不同的采样默认值、帧数限制或固定的上游版本——我们就会按需为该条目添加一个新的可选配置项，以运行_该_模型；不需要此配置的模型则保持未设置。这就是为什么配置接口采用按模型逐项扩展的方式，而非预先固定架构：它会根据真实检查点实际需要的配置逐步扩展。如果你遇到行为异常的模型，这是一个值得报告的缺口，而非设计本身的限制。

支持门控模型；但需要使用各自的凭证。 一些最强大的开源检查点设有门控：可以免费了解，但获取前需要通过账户审批（FLUX.2-dev 和 klein-base-9B 系列在 Hub 上设置为 gated: auto，Llama 的 GGUF 同样如此——这也是 Llama 未列为默认目录条目的唯一原因）。要使用这类模型，请在 HuggingFace 上接受其条款，并向节点提供你自己的令牌：HF_TOKEN、HUGGING_FACE_HUB_TOKEN，或 huggingface-cli login 已写入 ~/.cache/huggingface/token 的文件——这三种方式都会读取，因此以常规方式登录过的运营者无需进行其他操作。令牌是运营者本人账户的凭证：只会发送至 huggingface.co，不会由节点持久保存，并会从日志中脱敏。若未提供令牌，获取门控模型时会失败并返回 401/403 错误，同时错误信息会指出仓库及需要接受条款的具体页面。tenzro status 会报告是否存在令牌，否则凭证缺失只会表现为原因不明的下载失败。

• 分布式混合专家（MoE）服务。 MoE 模型（Qwen 3.5 122B-A10B / 397B-A17B、DeepSeek V3 / V4 Pro 1.6T-A49B / V4 Flash、GLM 5.1 / 5.2、Kimi K2 / K2.6 / K3 2.8T-A104B、MiniMax M3、Gemma 4 26B-A4B）以两种模式提供服务。如果单个提供方的硬件能容纳模型，则采用完整副本模式；如果不能，则采用去中心化专家分片模式——提供方通过 ProviderCapacity.moe_holdings 声明自己持有的专家，调度规划器将每个 token 的 top-k 路由决策汇总为按持有方分组的批次，并通过持有方的 iroh QUIC 端点直接分发。分片视图是现有提供方注册表的派生视图——MoE 提供方与提供稠密模型服务的网络提供方相同。副本数量可通过治理调整（默认每个专家至少由 2 个持有方持有，热门专家最多由 8 个持有方持有）。类型化流水线角色：Replica、Router、ExpertHolder、PrefillDecode、Prefill、Decode。执行在节点中运行：MoeExpertRuntime 托管每个专家的 FFN 权重（ExpertFfn）和门控网络（GatingNetwork），并从 safetensors 加载（本地文件或通过 iroh-blobs 访问的 tenzro://blob URI）；前向传播在本地执行门控，将专家子批次通过 tenzro/moe iroh ALPN（支持 HTTP 回退）分发给持有方，并合并加权后的专家输出。持有方可以通告多于内存可容纳数量的专家：运行时使用按字节限额的内存层 LRU 缓存专家（预算自动设为 MemAvailable 的 60%，否则为 4 GiB），并由磁盘层提供支持，将原始 safetensors 换出至磁盘并按需解码；预读会在批次到达前，将前向传播即将访问的磁盘层专家提升到内存层。驻留状态（内存中的 Warm / 磁盘中的 Cold）从实时层状态读取，因此分片映射反映的是实际已加载的内容。专家投影计算（Y = X·Wᵀ）通过 ExpertCompute 接口层执行，因此同一前向传播路径可使用持有方拥有的任何硬件：始终提供 CPU ndarray 路径（在支持的 x86 上还会在运行时检测并启用 AVX-512-VNNI Q8_0 点积路径）；GPU 后端仅在 cargo 特性下编译（NVIDIA 上的 cuBLAS 分组 GEMM 使用 moe-cuda，跨厂商 WGSL 内核使用 moe-wgpu；moe-gpu 可同时启用两者），且绝不会进入默认构建——持有方通过 moe_gpu 通告 GPU 能力，使路由器优先将专家分配给 GPU 持有方。专家可进行块量化，以缩小存储的 blob 以及持有方之间传输的字节量——Q8_0（约 1 字节/权重）、Q4_K（约 4.5 bpw）、Q6_K（约 6.6 bpw）；其中 ExpertQuantPlan::q4_k_m（gate/up 使用 Q4_K，down 使用 Q6_K）是平衡型默认设置，并逐行反量化。跨持有方分发会在隐藏维度为 32 的倍数时，将激活压缩为 Q8_0 块；当某个持有方速度较慢或不可用时，会重新分发给预热的备用持有方；并将持有方响应流式传入合并器，如果预期贡献未全部到达，合并器会明确报错。规划 RPC：tenzro_moeShardMap、tenzro_moePlanDispatch、tenzro_moeReplicationPolicy、tenzro_moeCatalogShape。执行 RPC：tenzro_moeExpertLoad、tenzro_moeGateLoad、tenzro_moeExpertUnload、tenzro_moeGateUnload、tenzro_moeExpertStatus、tenzro_moePrepareExperts、tenzro_moeRoute、tenzro_moeExecute、tenzro_moeForward。CLI：tenzro moe {shard-map, plan-dispatch, replication-policy, catalog-shape, load-expert, load-gate, unload-expert, unload-gate, prepare-experts, status, forward}。
• LAN 集群——逐层流水线并行。 当单个成员无法容纳模型时，同一 LAN 上的一组机器可作为流水线共同提供服务：模型的层被划分为连续阶段，每个成员负责一个阶段，只有边界激活（每个 token 为 hidden_dim × dtype_bytes，fp16）会在相邻阶段之间通过网络传输。放置方案确定性生成——按 VRAM 加权的最大余数层分配、贪心最近邻阶段排序，以及排除无法建立数据平面链路成员的可达性门控；热路径中不涉及模型。成员必须使用相同的运行时构建提交版本（不进行链路版本协商）；成员使用不同后端不受影响。RPC tenzro_clusterPlan 返回适配决策；如果形成集群，还会返回按顺序排列的各成员层阶段。服务会自动触发流水线：tenzro_serveModel 读取模型的 GGUF 标头以获取模型形状，从 gossip 通告的 ClusterProfile 中发现成员，并在单台主机无法容纳模型时运行集群——传入 force_single 可将模型固定在一台主机上，或传入 cluster_members 覆盖发现结果。
• 本地优先发现与路由。 节点通过 mDNS 发现自身 LAN 网段上的对等节点（tenzro_localPeers），并发布持续更新的连接性等级——direct / relay_only / unreachable（tenzro_nodeReachability）。执行解析器优先选择本地提供方，仅在没有任何可达提供方时才回退到更广的网络（本地优先，无法连接时回退），因此由同一 LAN 上的机器处理的请求绝不会离开该 LAN。每个节点还会公开硬件自描述信息——运行时构建提交版本、CPU 架构、OS、检测到的计算设备，以及推导出的服务容量 / 后端 / 能力键（tenzro_nodeProfile）——这些信息会用于单机适配与集群规划。
• 多令牌预测（MTP）推测解码。 进程内运行时执行推测解码：草稿模型提出一组候选 token，目标模型通过一次批量解码进行验证，并由已接受的前缀推进流。为模型提供服务时会自动加载其草稿模型——tenzro_serveModel 读取目录中的 drafter_id，从磁盘加载或在后台下载，并在服务响应的 mtp 字段中报告结果。模型的候选 token 来源有两种：小型配对草稿模型检查点，或根据目标模型自身隐藏状态自行生成草稿的原生嵌入式 MTP 头（未设置 drafter_id，mtp_kind: DraftMtp）——无需获取第二个检查点。已声明支持的模型包括 DeepSeek V3（原生，接受率约 80%，解码速度约 1.8×）、DeepSeek V4 Pro / Flash、GLM 5.2、Gemma 4（所有尺寸）、Qwen 3.5（0.8B/2B/4B/9B/27B/35B-A3B/122B-A10B/397B-A17B）、Qwen 3.6 27B + 35B-A3B，以及 Qwen 3.8 27B（原生嵌入式头）。提供方通过 ProviderCapacity.mtp_enabled 通告可同时加载草稿模型；设置 draft_n 时，推理路由器会将需要 MTP 的请求筛选到支持 MTP 的提供方。
• 进程内支持视觉的语言模型。 若 GGUF 携带多模态投影器（mmproj），则会与语言模型权重一同加载投影器，使图像附件在同一运行时中编码并交错插入提示词，而不是路由至独立的视觉服务。目录条目通过 MmprojSpec 声明投影器；该路径在 mtmd cargo 特性下编译。
• 难度感知路由。 根据声明的元数据（参数量、上下文窗口、能力标签）选择模型，并不能说明某个具体提示词是否需要昂贵的模型。提示词会被嵌入，并通过按需扩展的在线顺序 k-means 映射进行分组——无需训练语料，也无需离线拟合；每个模型都会根据真实服务结果累计各聚类的结果计数器，因此其能力强弱是针对每个提示词邻域测得的属性。新注册的模型从中性先验开始，并带有乐观奖励，使其仍有机会被探索。聚类映射和计数器会持久化到 CF_MODELS，并在启动时加载。
• 网络模型目录。 提供方在 tenzro/models 上广播签名模型报价，其中包含模态、能力、上下文长度、提供方自己的价格、服务计划、TTL 和服务地址。节点验证每条通告，并按 (model_id, provider) 对固定签名密钥，然后将未过期的报价集交给意图路由——因此路由会为网络上的所有有效报价评分，而不只是本地运营方注册的报价；结算分账也会支付给获胜报价中指定的收款方。
• 去中心化训练——Tenzro Train。 一种采用解耦式外层同步的数据并行协议。Rust 协议层（tenzro-training）负责同步器状态机、五种聚合规则（Mean / LoraAlternating / TrimmedMean / CoordinateMedian / Krum）、Nesterov 外层优化器、分片提交、训练回执，以及链上运行根提交。Python 参考训练器通过 PyTorch FSDP2 + Hivemind + safetensors 封装各模态的内层循环（transformers、native PyTorch、gluonts、timm）。k-of-N 见证委员会通过幂等终结和无背书证书，处理跨区域的多同步器协调。通信效率优化包括：分块对称梯度量化（Int8 比 f32 小 4×，Int4 比 f32 小约 8×，Rust / Python 编解码器逐字节一致）、流式同步（每轮仅同步一个参数分片，active_shard = round % num_shards）、延迟应用（第 r 轮的外层更新在第 r+1 轮期间应用，使通信与计算重叠）、根据成对余弦梯度一致性缩放的自适应外层学习率，以及用于无法由单个训练器容纳的大模型的流水线并行训练器组。可按任务选择内层优化器（inner_optimizer：muon / adamw / sgd）——Muon 通过 Newton-Schulz 迭代对二维权重更新进行正交化。机密层级使用 HPKE RFC 9180 基础模式，将每个分片的数据密钥封装给驻留在 enclave 中的训练器（数据仅在训练器的 TEE 内解封）。三个信任层级：Open（Mean 和 LoraAlternating）、Verified、Confidential。
• 扩散媒体生成——Tenzro Media Gen。 将图像和视频生成为网络资源，支持四种任务类型（text2image、image2image、text2video、image2video）。Rust 协议层（tenzro-media-gen）负责任务队列、工作器注册表、像素步数定价、支付分配、三个签名原文以及内容寻址载荷存储；Python 参考工作器（integrations/media_gen/，HuggingFace diffusers）只负责去噪循环。预配置目录条目均为第三方检查点——Qwen-Image 及其四步蒸馏版、Qwen-Image-Edit、Z-Image-Turbo、FLUX.2-klein、Wan 2.2 视频系列、LTX，均非 Tenzro 自有模型。这些是随附元数据（像素步数定价形式、分离专家边界、帧数限制）均已填好的流水线；工作器会通告其实际持有的流水线，因此这些内容只是起点，而非限制。若运营方尚未接受模型的许可等级，则拒绝注册该模型；受限权重需要运营方提供自己的 HuggingFace 令牌，如上所述。分离专家渲染适用于 Transformer 由高噪声 / 低噪声专家对组成的模型——固定噪声阈值（t ≥ boundary_ratio × num_train_timesteps）决定某一步由哪个专家处理，因此一个专家可装入 48 GB 内存，而完整模型需要 80 GB；两个部分之间恰好只传输一个中间 latent；支付则根据签名交接记录中的 steps_completed / total_steps 分配，而非依据任何一方工作器事后的说法。输出、latent 和条件图像均通过 tenzro://blob/ 寻址，并在读取时验证。RPC 位于 tenzro_mediaGen_* 下；CLI：tenzro media-gen {catalog, quote, post-job, get-job, get-receipt, fetch-output, enroll-worker, claim-job, publish-output, record-handoff, submit-receipt, fetch-latent}。
• Cortex。 将循环深度 Transformer 推理工作器作为独立计算通道公开——采用 HTTP sidecar 架构、签名回执、证明套件、基于 gossip 的工作器发现，以及按深度计价。
• 机密推理。 模型提供方可将推理封装在 Intel TDX / AMD SEV-SNP / AWS Nitro / NVIDIA GPU CC enclave 中；结果哈希由 enclave 绑定密钥签名，证明链通过链上的 TEE_VERIFY 进行验证。

去中心化应用托管

将静态站点、服务端函数或未经修改的长驻服务发布到 Tenzro 节点，并通过公共互联网提供服务——无需手动配置 TLS、DNS、Caddy 或端口。三类运行时共用同一套部署 → 发现 → 放置 → 服务流程：

• 静态站点和单页应用。 站点是一个带签名的路由清单，将请求路径映射到节点 iroh 存储中的内容寻址 Blob（tenzro://blob/<hash>）。内容不会接触文件系统；请求路径仅用于索引路由映射。对于非资源路径，SPA 回退会以 200 状态码提供 index；资源未命中则直接返回 404，因此缺失的 bundle 分块不会被掩盖。响应会携带 ETag（Blob 哈希），并支持 If-None-Match 304。RPC tenzro_siteDeploy / CLI tenzro site deploy。
• 函数。 wasi:http 组件（WASI 0.2，在 wasi-skills 功能下托管于 wasmtime）可在沙箱中直接响应请求，并采用能力门控权限、确定性燃料计量以及每个请求的挂钟截止时间。RPC tenzro_functionDeploy / CLI tenzro function deploy。
• 机器。 Firecracker 微型虚拟机中的常驻进程（在 firecracker 功能下运行于具备 KVM + 嵌套虚拟化的运营者节点），用于运行未经修改的 Node / Python / Rust 服务。RPC tenzro_machineDeploy / CLI tenzro machine deploy。
• 放置与经济机制。 提供方公布的每小时价格即为其报价；部署会发现具备相应能力的节点，根据运行时类别 / CPU / RAM / 磁盘 / TEE / 价格上限进行硬性筛选，优先按区域排序，再按价格从低到高排序，并租用排名靠前的 N 个不同节点——租约会记录为链上 LeaseRecord，可通过 tenzro_listLeases / tenzro_getLeasesForApp 查询（CLI tenzro lease list / tenzro lease get）。放置尽力而为：如果没有具备相应能力的远程节点，应用会在本地提供服务，因此部署不会失败。每隔 30 秒执行一次协调任务，清理过期租约（提供方公告 TTL 过期是判断存活状态的信号），并将无响应节点上的副本重新放置到其他正常节点，维持副本数量稳定。部署标志：--replicas、--region-hint、--max-price-per-hour。
• 由运营者配置的边缘节点。 每位运营者都要配置其边缘节点为应用提供服务所使用的域名——网络中没有统一的规范主机名。主机名别名会将传入请求重写为应用的服务路径；边缘节点通过 tenzro/http 传输（每个 HTTP 请求使用一个 QUIC 双向流）将请求转发到已放置应用的节点，并将响应流式传回。边缘节点的 TLS 采用 PQ 混合方案，并自动配置。命名、放置和变更都需要提供签名信封，以证明对所有者 DID 的控制权。

完整的 RPC 和 CLI 功能请参阅 docs/HOSTING.md。

租户文件存储

/v1/files 后面的多租户对象存储，构建在内容寻址存储提供程序之上，而非取而代之。提供程序通过调用方分配的 ID 识别对象，并能从分片重建其字节；但它刻意不知道某个对象是_周二上传的、属于 Alice 的 notes.txt_。这是应用元数据，若将其下放到分片层，就意味着每个持有分片的提供程序也会持有文件名，以及该分片所属文件的所有者。因此，命名层仍保留在租户上传所经由的节点本地，存储层只保存字节。

上传会进行纠删编码，生成 4 个数据分片和 2 个校验分片——可承受两个提供程序同时丢失——并分发到相互独立的提供程序，由流式存储交易为其付费。上传结果中的 null deal_id 表示字节已存储，但没有任何付费机制确保其留存。

每项操作都会执行隔离，而列举是关键路径：检索、内容读取和删除各自只针对一个已知 ID，因此若缺少所有权检查，可能会将一个文件泄露给已经猜到其 ID 的人；而 list 会_列举_文件。查询另一个租户的文件 ID 时，返回结果与查询不存在的文件完全相同。删除会解除引用并停止交易；它不会擦除分片，只有在交易停止为其付费后，分片才会过期——因此不得将其视为数据删改。RPC：tenzro_uploadFile / tenzro_listFiles / tenzro_getFile / tenzro_deleteFile；CLI：tenzro files {upload, list, get, download, delete, usage}。

租用硬件会话

当运营方出租节点时，租用方应能直接使用硬件，而不只是通过节点的 RPC 使用。其模式类似 GCP OS Login + IAP 和 AWS SSM Session Manager——身份范围限定、时效短、无需开放入站端口、可从源头撤销并且经过审计——而不是直接交出 root SSH 密钥。授权和限制由节点负责；传输协议为 tenzro/shell iroh ALPN。

会话由三个因素共同控制，每个因素解决的问题各不相同。服务密钥由运营方配置，或在租赁押金到账时自动生成，用于确定当前使用的是_哪份租约_——它本身只能证明有人拿到了一个字符串。针对调用方 Tenzro 钱包的通行密钥验证流程（钱包已有的浏览器启动流程：CLI 打印链接，用户在浏览器中验证，CLI 轮询）使会话可归属到_某人的钱包_，而不只是持有密钥的人。属于租约授权钱包列表中的成员这一条件，则确保仅凭泄露的密钥无法使用会话。

租约也限定了使用范围：可用哪些加速器、核心数、内存量、是否允许出站流量（默认关闭——租用的 shell 用于计算，无论如何都无法访问运营方的本地网络）、每个会话的最长时限（上限为 12 小时）以及租约期限。省略加速器列表会生成仅限 CPU 的租约，因为“所有 GPU”并不是任何人实际选择的范围。撤销租约会终止针对该租约的所有未过期会话授权。CLI：tenzro shell login 和 tenzro shell lease {open, revoke, list}。

3D 资产生成

图像转 3D 与图像和视频处于同一作业队列，而非与它们并列。周边机制——提交、认领、内容寻址输出、签名收据、按像素步结算——完全相同；不同的只有加载器和产物，而这正是目录条目所包含的内容。

• 类型。 MediaGenKind 新增 image23d 和 text23d。输出是带 PBR 材质的 GLB 网格，而非帧，因此下游不会尝试将其解码为视频。
• 可插拔后端，不强行统一。 媒体生成条目声明其 backend，默认为 diffusers。这个默认值确保所有现有管线逐字节保持不变。trellis2-4b 通过 Microsoft 自己的 trellis2 包加载，它根本不是 diffusers 管线——用兼容层强行适配它，或将 diffusers 模型塞进新的抽象层，都是用可用的路径换取统一的路径。缺少某个后端所需包的工作节点会拒绝加入该条目，而不是先接受作业、等到认领时才失败。
• 按产出计价。 3D 作业按体素网格报价，而非按条件图像：width/height 描述的是_输入照片_，若按它们计价，就会对输入收费而忽略资产——同一张照片生成 512³ 和 1536³ 的两个作业，成本会相同，但工作量相差 27 倍。计费基于网格边长（r²），因为生成成本取决于稀疏的占用表面，而非空心内部；并使用相同的 per_pixel_step 费率，以便通过同一条路径结算。

tenzro model serve 和所有像素管线均不受这些改动影响。

节点能力界面

两项功能弥补了节点能做什么与调用方能发现什么之间的差距。

• 通用 RPC 网关。 节点提供约 900 个 JSON-RPC 方法，每个版本还会增加更多，因此任何手动维护的客户端列表都会一直落后——开发者恰好会在需要某个方法时发现这一缺口。tenzro_listRpcMethods 从节点本身返回目录，每个条目都注明其门控类别（管理员令牌或开放）以及所需的 API 密钥范围，让调用方无需先触发错误，就能区分“我需要范围不同的密钥”和“我需要运营方的令牌”；可按命名空间或子字符串筛选，因为不加筛选时结果约有 900 行。找到的方法随后可按名称调用。授权方式不变：网关调用仍会通过相同的管理员令牌门控、API 密钥范围门控和默认拒绝分类，只能访问当前凭据本来就允许访问的内容。CLI（tenzro rpc {methods, call}）、两个 SDK、MCP 和 A2A 均已开放此功能。
• 模型可见性——三个层级。 谁可以调用某个模型，是模型本身的属性。network（默认值）会在 tenzro/models 上公布该模型，并让任何愿意付费的调用方都能访问——无需服务密钥或预先建立关系，即使节点已启用服务密钥门控也是如此。gated 会向持有 API 密钥的调用方提供模型，这些密钥的策略已由运营方预先约定；它刻意不公布模型：相关方已经知道它存在，向外传播只会向无法使用它的调用方宣传可用容量。private 则绝不会离开本机。CLI：tenzro model serve [--gated | --private]。已发布模型的例外范围很窄——仅允许对当前以 network 方式提供的模型使用推理方法白名单；对于 gated、private 或未知模型，以及任何其他方法，仍需要密钥。
• 能力可见性。 节点公布的内容与它能执行的能力可以分开控制。运营方可以停止公布单项能力——ai、storage、database、hosting、rpc、tee、compute——而无需卸载或禁用这些能力，并可稍后恢复公布。共识功能不可隐藏：如果验证者的对等节点无法连接到它，它就无法投票。CLI：tenzro visibility {show, hide, publish}。

多模态推理

目录涵盖七种 ONNX 运行时，以及 llama.cpp 语言路径。它们均由模态感知型 InferenceRouter::route() 根据类型化的 InferencePayload（Chat / Forecast / VisionEmbed / VisionSimilarity / TextEmbed / Segment / Detect / Transcribe / VideoEmbed）进行调度。许可证级别——宽松许可（Apache/MIT/BSD）、署名许可（CC-BY-4.0）、商业定制许可（DINOv3、SAM、Gemma——需要 --accept-license）、非商业许可（未指定 --accept-non-commercial 时拒绝）——控制注册。预测（TimesFM 2.5）、视觉嵌入（CLIP、SigLIP2、DINOv3、DINOv2）、文本嵌入（Qwen3-Embedding、EmbeddingGemma Matryoshka、BGE-M3、Snowflake Arctic）、分割（SAM 3 / 3.1、SAM 2、EdgeSAM、MobileSAM）、检测（RF-DETR、D-FINE）、音频 ASR（Moonshine v2、Distil-Whisper、Whisper v3 turbo、Parakeet-TDT、Canary-1B-Flash）、视频（对均匀采样帧使用视觉回退编码器）。每种模态均通过 JSON-RPC、MCP、A2A 和 CLI 子命令提供。所有 ONNX 运行时共用一个会话构建器：先注册硬件执行提供程序，再回退到 CPU——onnx-tensorrt / onnx-cuda / onnx-coreml cargo 特性会编译相应的提供程序（默认优先级为 TensorRT → CUDA → CoreML）；TENZRO_ONNX_EP 环境变量可覆盖优先级；如果提供程序注册失败，则会继续尝试，而不会报错。容器映像变体将经 LLM 加速的二进制文件与匹配的运行时打包在一起：Dockerfile.cuda（NVIDIA CUDA——多架构，支持 x86_64 和 arm64 主机，例如 Grace-Blackwell）、Dockerfile.rocm（AMD ROCm）和 Dockerfile.vulkan（跨厂商 Vulkan）。ONNX GPU 执行提供程序仅随 x86_64 CUDA 映像提供；在 arm64 CUDA 以及 ROCm 和 Vulkan 映像中，ONNX 模态会回退到 CPU，而 llama.cpp 语言路径仍由 GPU 加速。完整的后端／映像矩阵请参阅 docs/AI.md §2.7。

身份（TDIP）——四种类别

• did:tenzro:human:{uuid} — KYC 级别，受控机器，以及任意数量委托 Agent 的控制者。
• did:tenzro:machine:{controller}:{uuid} — 代表人类、机构或上游机器行事的委托 Agent。携带委托范围（每笔交易上限、每日上限、允许的操作／链／支付协议／交易对手、时间限制）。
• did:tenzro:machine:{uuid} — 自主 Agent。钱包和 A2A 接口相同，无控制者。协议资助的引导 Agent 会标记 is_seed_agent。
• did:tenzro:institution:{lei}:{uuid} — 锚定到其 20 位 GLEIF 法律实体标识符（ISO 17442）的法律实体；注册时会验证 ISO 7064 Mod 97-10 校验位。可选绑定 vLEI ACDC 凭证 ID、ISO 3166-1 alpha-2 国家代码和 KYB 级别。一个法律实体可持有多个机构身份（每个交易台／基金／子公司一个），无需重新签发 LEI。

W3C DID 文档。W3C 可验证凭证支持递归信任链验证（循环检测、深度限制，并锚定到配置的信任根）。通过凭证升级 KYC/KYB 级别。级联撤销。符合标准的任意客户端均可使用 /1.0/identifiers/{did} 上的 Universal Resolver（DIF 规范）。针对长期自主机器身份的 KERI 密钥事件日志（创建、轮换、带预轮换承诺的交互事件；用于 SHA-256 的 SAID 前缀 S）。Sign-In With Tenzro（SIWT）——采用 EIP-4361 形式的消息，用于离线服务身份验证。

支付

加密货币支付通道 — 使用 TNZO 或稳定币进行链上结算：

• AP2（Agent Payments Protocol）：Google/FIDO 协议，通过意图／购物车／支付 VDC 实现可验证的 Agent 支付；通过 tenzro_validateMandatePair 验证授权配对
• MPP（Machine Payments Protocol）：基于会话的流式支付，由 Stripe 和 Tempo 共同编写
• x402（Coinbase）：使用 EIP-3009 授权的无状态 HTTP 402 支付。默认的协调服务为自托管服务 — 运营方运行该方案的准入检查，并通过自己的 EVM 签名者完成结算，而不是将签名授权路由到远程协调服务
• Tempo：使用 EIP-155 交易签名直接结算稳定币
• 应用注册表 + 开发者签名结算：开发者使用自己的 DID 注册应用，并针对仅由自己控制的支付提供商账户结算已授权的扣款。开发者为每项结算授权签名；节点负责路由扣款并记录结果，但绝不持有支付提供商的密钥。RPC：tenzro_registerApp / setAppStatus / getApp / listApps / settleAuthorized / getSettleAuthorizedOutcome；SDK：AppClient（Rust + TypeScript）；CLI：tenzro app
• 用于自动发起支付质询／验证的 HTTP 中间件

银行卡支付通道 — Visa/Mastercard 结算法币；Tenzro 提供身份、委托和审计：

• Visa TAP（Trusted Agent Protocol）：Agent 提交由 Tenzro 签发的授权信封（DID + 已签名的委托范围 + AP2 授权验证）；Visa 授权并结算银行卡交易；Tenzro 记录链上审计凭证
• Mastercard Agent Pay：采用相同的身份／委托／审计基础设施；Mastercard 结算银行卡交易

这意味着，单个 Agent 身份可在一项任务中，通过一个授权信封和一条审计轨迹，组合使用银行卡支付通道 TAP 支付、x402 USDC 小额支付和 Canton DvP 环节 — 即使这些支付通道原本无法互操作。

安全性

• 真实 TEE 集成：Intel TDX（/dev/tdx-guest）、AMD SEV-SNP（/dev/sev-guest）、AWS Nitro（/dev/nsm）、NVIDIA GPU CC（NRAS API）
• 使用固定的供应商根 CA 验证 X.509 证书链
• 使用 HKDF 密钥派生的 AES-256-GCM enclave 加密
• 基于 KoalaBear 的 Plonky3 STARK 证明（无需可信设置，具备后量子可靠性），以及用于 O(1) EVM 验证的链上 ZkCommitmentRegistry
• 使用 Argon2id 密钥派生的 FROST-Ed25519（RFC 9591）2-of-3 阈值钱包，并搭配强制要求的 ML-DSA-65 后量子签名
• VRF（RFC 9381 ECVRF-EDWARDS25519-SHA512-TAI）用于可证明公平的随机数 — 预编译合约 0x1007、NFT mintRandom（0x52517e21）

跨链桥（16 个生产级适配器）

• LayerZero V2：EndpointV2 消息传递、采用共享小数位的 OFT
• Stargate V2 Hydra：原生 USDC / USDT / WETH OFT 跨链桥接（独立适配器；底层使用 LayerZero V2）
• Chainlink CCIP：基于 Router 的跨链消息传递，支持代币池
• Chainlink CCT：Cross-Chain Token v1.6+ 自助式代币池注册表（LockRelease + BurnMint）
• Wormhole：19 个 guardian 的 VAA 证明，支持 30 多条链，包括 Solana / Aptos / Sui
• Wormhole NTT：原生代币转账，采用 NttManager 注册表和多中继器链目录（Wormhole / Axelar / LayerZero / 自定义）
• deBridge DLN：基于意图的跨链兑换（官方 MCP 代理）
• LI.FI：聚合 66 条链并优化路由
• Hyperlane V3：使用主权 Tenzro 验证器集 ISM 进行消息传递（list_chains、quote_dispatch、dispatch）
• Axelar GMP：覆盖 Cosmos / Move / Stellar / XRPL
• Babylon：比特币质押最终性提供者 + EOTS 委托
• IBC-Eureka：将 Tendermint 轻客户端压缩为 SP1 plonk 证明，适用于每条 Cosmos SDK 链。EVM 上的 IBC_VERIFY 预编译合约（地址为 0x1020）通过链下承诺注册表进行 O(1) 查找。
• BitVM2 / Clementine：信任最小化的比特币双向锚定，采用乐观挑战协议。锚定转入 / 转出生命周期在链上跟踪；默认结算窗口为 7 天。
• Hyperbridge ISMP：通过类似 HTTP 的 POST / GET 消息与 Polkadot 通信。在消息接收路径强制执行铸币控制和每种资产的滚动窗口流动性上限。
• NEAR Chain Signatures：NEAR MPC 从 Tenzro 账户为 Bitcoin、Ethereum、Solana、TON、Stellar、Sui、Aptos、Dogecoin 生成 secp256k1 / Ed25519 签名。
• Canton：企业级 DAML 互操作性

统一的 BridgeRouter 会查询实时报价，并按成本、速度或可靠性返回排序后的路由。每个适配器在验证入站消息时均采用失败关闭策略（Wormhole 使用 Guardian 法定人数，Hyperlane + Axelar 使用阈值验证器集，Hyperbridge 使用 ISMP 证明，Clementine 使用 BitVM2 挑战协议）。每个适配器的 nonce 跟踪器都会持久化，因此重启后仍会丢弃重放消息。位于预编译合约 0x1021 的全局供应量核算注册表是 Tenzro 发行代币跨轨道流转时唯一的完整性日志——它强制执行每个（资产、轨道）序列单调递增（防重放）、Σ mints − Σ burns ≤ max_supply，并确保销毁时不会下溢。

以 TNZO 支付桥接费 + Chainlink 支持的费用预言机

• 单代币体验：用户在源链上支付以 TNZO 计价的单笔费用；目标链的原生费用由每个适配器的赞助池预先垫付。
• 两种预言机支持方式：GovernanceSetFeeOracle（手动费率表，通过 tenzro_setBridgeFeeRate 由管理员令牌门控）和 ChainlinkFeedFeeOracle（通过 eth_call 实时调用 AggregatorV3Interface.latestRoundData()，采用 30 秒内存缓存，并拒绝过期或无效答案）。
• 每个适配器的赞助池：8 个确定性金库地址（对 "tenzro/bridge/sponsorship-vault" || adapter 计算 SHA-256，取前 20 个字节），可通过 tenzro_listBridgeSponsorshipPools 枚举。
• ERC-7683 封装统一：TenzroOrderData.bridge_fee_hint 使任何已注册适配器集中的桥都能填充同一笔用户签名订单——由 solver 选择适配器，TNZO 上限约束目标链原生费用承诺。
• 由运营方承担的上游成本：Chainlink 读取所用的 Ethereum 主网 RPC 配额由运营方付费；方法通过带 chainlink 作用域的 API 密钥进行门控（与 Canton 使用相同模式）。在 CF_BRIDGE_ANALYTICS 中按租户归属 Compute Unit。GCRA 速率限制器（持续速率为每秒 10 个请求，突发上限为 100），并提供 -32005 重试封装。

代币化与合规

• ERC-7943 (uRWA)：现实世界资产合规接口面 — 代币紧急停止开关（tenzro_urwaTriggerKillSwitch）、冻结代币（tenzro_urwaSetFrozenTokens）、强制转账（受管理员代币门控）。
• IVMS101 v1.1.0：为跨境转账中的 KYC 载荷绑定 FATF Travel Rule 标准信封。
• Secure-Mint：代币化 RWA 的逐代币 1:1 储备证明不变量。
• TEE 证明的时间戳：Saga 步骤截止时间和义务到期时间带有 TEE 证明的 wall_ms + monotonic_ns + tee_vendor 信封，漂移容差为 30s。

Agent 互操作性

• ERC-8004：Ethereum 上的无信任 Agents Registry — 将 Tenzro 机器 DID 镜像到 registerAgent/getAgent/submitFeedback/validationRequest/validationResponse 接口，实现跨生态系统的 Agent 声誉管理。CLI 同时提供 tenzro erc8004 和规范的 EIP-8004 短名称别名 tenzro 8004。
• AP2：Agent Payments Protocol，支持 intent/cart/payment VDC mandates、会话生命周期和 mandate 配对验证。
• AAP（Agent Access Protocol）：为 Agent 签发的 bearer token 提供 OAuth 2.1 + DPoP + RAR 分层。CLI 同时提供 tenzro auth 和别名 tenzro aap — 两个名称调用相同的 tenzro_*Token* 和钱包链接 RPC。

多方工作流（与 VM 无关；Canton 镜像为可选项）

工作流运行时拥有独立的状态机。它与 VM 并行运行（而非在 VM 内部运行），并拥有自己的类型化生命周期、每个步骤的 execute / verify / compensate 处理程序、由特权 VM 事务选择器管理的链上收据、费用路由、紧急停止开关和隐私域。Canton 镜像是可选投影 — 工作流可以声明 canton_mirror: Some(...)，工作流分发器便会通过同置 Canton participant 为每个步骤写入一行 Tenzro.Workflow.Receipt；使用 canton_mirror: None 的工作流则不与 Canton 交互。EVM 合约通过标准事件接口订阅工作流事件。SVM 程序通过统一代币注册表的事件日志读取收据。

• 生命周期：类型化状态机（Draft → Active → AwaitingSignatures → Executing → Completed，终态为 Cancelled / Disputed / Failed / Suspended），每次状态变更都使用特权 VM 选择器 0x01000040–0x0100004B。
• 收据：每次状态转换都会生成一个 WorkflowReceipt，并将其关联到每个工作流的哈希链中，持久化到 wf_receipt:<id>，并可选择通过同置 Canton participant 镜像到 Tenzro.Workflow.Receipt Daml 模板。
• 隐私域：由 TDIP DID 构成的命名 ACL，用于控制 AES-256-GCM 密封载荷的访问，并支持审计员直接读取和由治理驱动的冻结。
• 费用路由：基点接收方表通过 tenzro_computeFeeRoutePayouts 提供只读预览；实际结算通过共识中介的托管原语执行。
• 紧急停止开关：KillSwitchSuspend / KillSwitchCancel 选择器为发起方提供明确的紧急停止路径，确保自主 Agent 绝不会被困在自己发起但无法响应的多方流程中。
• 接口：通过 JSON-RPC（tenzro_*）、MCP（端口 3001）和 A2A（Tenzro Agent Card 上的 workflow 技能）提供只读访问。/metrics 提供运维指标快照，并附带 Grafana 仪表板（UID tenzro-workflow）。
• 参考模板：crates/tenzro-workflow/reference_workflows/ 下有 5 个可用模板（自主采购、自主管理资金、DvP 结算、环境 MRV、供应链 DPP），每个模板都配有一个 **_daml_map.json`，用于描述可选的 Canton DAML 投影。

合规与披露（欧盟《人工智能法案》第 50 条）

• §50(1) 聊天机器人披露：每条 CLI / MCP / A2A AI 文本响应都会以 [AI] 为前缀。唯一事实来源是 tenzro_node::eu_ai_disclosure。
• §50(2) 合成内容标记：每条推理输出都附带一个采用 C2PA 风格的 ContentProvenanceManifest，并以 SHA-256 内容哈希为键。验证者使用其 Ed25519 区块签名密钥为清单签名。RPC tenzro_getContentProvenance 和 CLI tenzro provenance get <content_hash> 可查询缓存的清单。
• §50(4) 深度伪造声明标签：模仿真实主体的输出使用 deepfake 声明，而非 ai-generated。
• 审批流程：超出范围的 Agent 操作会暂存，等待控制器审核。通过 tenzro approval list/get 查看，并通过 tenzro approval decide 决定。
• 通道争议：可通过 tenzro dispute status 和 tenzro dispute list-by-channel 查看持久化的生命周期记录。
• 提供商信誉：tenzro reputation get <provider> 可读取持久化评分（0–1000，成功 +1 / 失败 −5），该评分供推理路由器使用。

节点将数据存放在哪里

Tenzro 在计算机上写入的所有内容都存放在一个根目录下：$TENZRO_HOME；若未设置，则使用 ~/.tenzro。模型权重、HuggingFace 缓存和数据集分片由计算机上的所有 Tenzro 进程共享；这些内容以内容寻址方式存储，写入后只读，因此两个节点不会分别保存相同的 权重。链状态按实例存放在 instances/<name>/ 下，因为 RocksDB 无法共享：第二个打开相同目录的进程会因锁文件而失败。

$TENZRO_HOME
├── models/          shared — GGUF weights, ONNX bundles
├── hf/              shared — HuggingFace cache (exported to child processes)
├── trainer-cache/   shared — dataset shards, keyed by digest
└── instances/
    └── default/     RocksDB, keys, wallets, snapshots, iroh blobs

对于需要将大型数据存放在独立卷上的运维人员，--data-dir 仍可覆盖每实例目录，models_dir 则可覆盖共享存储。容器镜像会设置 TENZRO_HOME=/data/tenzro，使模型存储 位于挂载卷上，而非临时层中。

授权模型

分为三层，各自回答不同的问题：

• 准入（admission.rs）——由运维人员设置的可选服务密钥，用于控制服务接口。它没有共识或 Gossip 变体，因此，从结构上说，通过准入控制的节点无法停止验证。服务密钥是这台机器原始资源的租用凭证——受限 Shell、存储、内存和计算资源——其中包含一个 ServiceKeyGrant，记录它准入的接口以及过期时间，并绑定到为其签发的 AccessLease。它并不表示节点提供什么服务：**模型服务是否可用，取决于模型自身的可见性，而不是这道准入控制。**在通过准入控制的节点上，仅凭付款即可访问可见性设为 network 的模型，因为通过 Gossip 找到该服务的对等节点无法获取密钥。请参阅docs/ACCESS.md。
• 分类（rpc_gates.rs）——每个已分发的方法都恰好列在 ADMIN_METHODS（109 个）或 OPEN_METHODS（823 个）之一；未列入其中任何一项的方法，会在处理程序运行前遭到拒绝。测试会读取分发器自身的源码，因此，添加 RPC 时若未确定其准入控制方式，构建就会失败，而不是留下待审计的问题。
• 所有权——操作租户资源的方法，必须提供由该资源所有者签名的 DID 信封，并将其绑定到方法名和调用参数。运维人员的管理令牌用于验证运行这台机器的人；它不适用于属于这台机器使用者的资源，因为接受该令牌会允许共享节点的主机修改租户资源。

submitBlock、offerSnapshot 和 applySnapshotChunk 不属于 JSON-RPC 接口。它们原本是可通过面向用户的端口访问的对等节点流量——submitBlock 会将调用方提供的区块推送到最终确认路径，而根据约定，进入该路径的区块已经经过共识处理，因此不会进行任何验证。区块通过经过对等节点身份验证的 Gossip 和区块同步抵达；状态同步的入站部分由进程内部驱动。读取部分（listSnapshots、getSnapshotManifest、getSnapshotChunk）供正在同步的节点向提供服务的节点调用，保持不变。

生态系统

组件	仓库	描述
MCP 服务（Python）	tenzro/tenzro-mcp-server	360 个工具，FastMCP 3.x
A2A 服务（Python）	tenzro/tenzro-a2a-server	75 项技能，FastAPI
TenzroClaw（Python）	tenzro/TenzroClaw	685 条命令，OpenClaw 技能
Rust SDK	tenzro/tenzro-sdk-rust	85 个模块
TypeScript SDK	tenzro/tenzro-sdk-typescript	92 个模块
浏览器扩展提供方	sdk/tenzro-inject	为 dApp 提供 window.tenzro — EIP-1193 / EIP-6963 / Wallet Standard / CAIP-25
Homebrew	tenzro/homebrew-tap	brew install tenzro
示例指南	tenzro/tenzro-cookbook	34 个可运行示例
桌面应用	tenzro/tenzro-desktop	Tauri + React

实时测试网

服务	URL
JSON-RPC	https://rpc.tenzro.xyz
Web API	https://api.tenzro.xyz
MCP 服务	https://mcp.tenzro.xyz/mcp
A2A 服务	https://a2a.tenzro.xyz
水龙头	https://api.tenzro.xyz/faucet
Solana MCP	https://solana-mcp.tenzro.xyz/mcp
Ethereum MCP	https://ethereum-mcp.tenzro.xyz/mcp
Canton MCP	https://canton-mcp.tenzro.xyz/mcp
LayerZero MCP	https://layerzero-mcp.tenzro.xyz/mcp
Chainlink MCP	https://chainlink-mcp.tenzro.xyz/mcp
LI.FI MCP	https://lifi-mcp.tenzro.xyz/mcp
文档	https://tenzro.com/docs

基础设施：tenzro.xyz 上的公共端点由 Tenzro Labs 运营，它是网络上首个参考 RPC 提供方。RPC 提供方角色开放——任何满足验证者债券要求的运营方都可以注册自己的端点，并提供相同的协议服务。边缘 TLS 使用 PQ 混合 X25519MLKEM768。此仓库是参考实现，任何人都可以运行节点并加入网络。

创世配置：TNZO 总供应量为 1,000,000,000。水龙头：每次请求最多可领取 1,010 TNZO，冷却时间为 24 小时。上限为 1,000 TNZO 的模型提供方债券加上支付提交债券所需 Gas 的余量——等同于债券金额的赠款无法支付提交该债券的交易费用。

开发

# Build all crates
cargo build

# Run all tests
cargo test --workspace

# Run clippy
cargo clippy --workspace

# Run node locally
cargo run --bin tenzro-node -- --roles validator --data-dir ./data

# Run CLI
cargo run --bin tenzro -- --help

要求

• Rust 1.85+（参见 rust-toolchain.toml）
• C/C++ 编译器（用于 RocksDB、libp2p）
• cmake（用于 llama-cpp-sys-2）
• protoc — Protocol Buffers 编译器 ≥ 3.12（lance-encoding 所需，该依赖由 agent-memory 向量层间接引入）
• pkg-config、libssl-dev（Linux）

安装 protoc：

# macOS
brew install protobuf

# Debian / Ubuntu
sudo apt-get install -y protobuf-compiler

# Fedora / RHEL
sudo dnf install -y protobuf-compiler

# Arch
sudo pacman -S --needed protobuf

# Rust-only (no system package manager)
cargo install protoc-bin-vendored-cli

使用 protoc --version 验证（必须输出 libprotoc 3.12 或更高版本）。完整的平台工具链说明请参见 docs/GUIDE.md。

Docker

# Build image
docker build -t tenzro-node .

# Run node
docker run -p 8545:8545 -p 8080:8080 -p 3001:3001 -p 3002:3002 \
  -v tenzro-data:/data/tenzro \
  tenzro-node --roles validator --data-dir /data/tenzro

部署

标准部署方式是在安装了 systemd 的主机上使用 Docker。请参见 deploy/validator-deployment.md，其中包含与基础设施无关的运维指南，涵盖密钥管理、网络配置和升级流程。

Proto 定义

proto/tenzro/v1/ 下有 13 个 proto3 文件，定义了 120 多种消息类型。这些文件用作 API 文档——Rust 类型采用手动实现，以确保灵活性。

文档

文档	用途
docs/WHITEPAPER.md	Tenzro Network 白皮书——愿景、架构、Agent 经济和结算层
docs/SPECIFICATION.md	协议规范——架构、共识、多 VM 执行、身份、支付、结算、Agent、训练，以及具体的 Rust 实现
docs/ECONOMICS.md	权威版本：谁付费、谁收款、金额多少。节点经济模式、收入分成、访问层级、结算、来源证明、机器身份
docs/TOKENOMICS.md	TNZO 代币经济学：供应量、费用模型、质押、奖励（测试网阶段）
docs/TDIP.md	Tenzro 去中心化身份协议——基于 W3C DID 的身份体系，涵盖人类、委托 Agent、自主 Agent 和机构；机器锚点、设备绑定和硬件绑定通行密钥、会话、钱包第二设备规则，以及机器所有权转移
docs/AI.md	Tenzro AI——去中心化推理（单副本 + 分片 MoE + MTP + 多模态）、Cortex 推理、机密推理、Tenzro Train（数据并行、解耦外层同步）训练，以及 Tenzro Media Gen（扩散图像和视频、专家拆分渲染）
docs/COMPUTE.md	Tenzro Compute——可租用的计算容量：按纪元预订、可用性证明门控、流式托管、固定或随网络动态变化的定价，以及与存储共享覆盖范围
docs/STORAGE.md	Tenzro Storage——去中心化内容寻址存储：按字节纪元计费、可检索性证明、冗余，以及与计算共享质押
docs/DATABASE.md	Tenzro Database——托管数据库协议层：引擎目录（PostgreSQL、Qdrant、Milvus、Valkey、Dgraph、Lance、Tantivy）、在本地 / LAN 集群 / 网络层级之间进行部署，以及访问策略 + 机密封印
docs/HOSTING.md	Tenzro Hosting——在 Tenzro 节点上托管静态站点、函数和机器：内容寻址服务、wasi:http 沙箱、Firecracker microVM、竞价 / 租约部署，以及运营者配置并自动启用 TLS 的边缘节点
docs/ORCHESTRATION.md	意图编排——在具备确定性防护措施的 LLM 规划器后组合模型、技能、工具和 Agent
docs/NETWORK.md	Tenzro Network——去中心化网络：libp2p 控制平面（gossipsub 主题、NAT 穿透、仅限验证者的主题认证、请求 / 响应协议）+ iroh QUIC 数据平面（DA、模型权重、梯度、密封分片、Agent 记忆、A2A + MCP ALPN）
docs/GUIDE.md	运营者和开发者指南：构建、运行、部署、故障排查
docs/did-method-tenzro.md	did:tenzro DID 方法规范（W3C 注册提交）
deploy/validator-deployment.md	与基础设施无关的验证者和节点运营者指南
docs/security/	安全模型、抗量子计划、审计说明

贡献

请参阅 CONTRIBUTING.md 了解指南。所有贡献均须遵守 Apache-2.0 许可证并完成签署。

许可证

Apache License 2.0。详情请参阅 LICENSE。

版权所有 2024-2026 Tenzro Foundation。