Tempo 代码分析报告

调研日期：2026-05-13
分析对象：github.com/tempoxyz 公开代码仓库
结论：✅ 代码完全开源，规模庞大（核心 Rust 代码 ~15 万行），架构清晰，企业级工程质量

0. 概述

Tempo 是少有的全栈开源企业系公链。截至 2026-05-13，tempoxyz GitHub 组织已发布 30+ 公开仓库，涵盖：
- 完整 L1 节点实现（Rust，基于 Reth + Commonware）
- 多语言 SDK（TypeScript、Go、Rust、Python）
- 文档站（Vite + Vocs）
- MPP 协议规范（IETF Internet-Draft 提交格式）
- 工具链（Foundry fork、命令行钱包、链上索引器 tidx）
- 隐私扩展（Zones repo）
- Account Abstraction SDK（accounts repo）

许可证统一为 Apache 2.0 / MIT 双许可（specs 部分 CC0 公共领域）。

1. 仓库清单与角色

观察：
1. 仓库覆盖链全栈 + 跨语言 SDK + 文档 + 索引器 + 钱包 + 浏览器 fork，工程完整度堪比 Solana / Cosmos
2. 出现 ungoogled-chromium-mpp 仓库说明 Tempo 在尝试把 MPP 集成进浏览器层（直接绕过 cookie / 卡片支付，浏览器原生 402 流程）
3. 出现 tempoxyz/skills 说明 Tempo 把 Claude Code / OpenClaw 作为内部 dev tool 标准化

2. 核心仓库（tempoxyz/tempo）深度分析

2.1 项目元数据

[workspace.package]
version = "1.7.0"
edition = "2024"          # 用 2024 edition（最新）
rust-version = "1.93.0"   # Rust 最新稳定版
license = "MIT OR Apache-2.0"
publish = false           # 不发布到 crates.io

• 使用 Rust edition 2024 + resolver 3（极新）
• 严格 lint 配置：禁止 dbg!、禁止 manual-string-new、禁止 use-self（避免 self 类型混淆）
• 含 reproducible Dockerfile（保证构建可复现，符合企业级 supply chain security）

2.2 Crate 结构（按层次）

crates/
├── 基础层
│   ├── alloy/              # alloy 工具（Ethereum 类型系统）
│   ├── primitives/         # Tempo 自定义类型（TempoHeader, TempoTxEnvelope）
│   ├── eyre/               # 错误处理 wrapper
│   └── telemetry-util/     # 可观测性工具
├── 链规格层
│   ├── chainspec/          # 链规格（含 mainnet/moderato bootnodes、hardforks T0-T6）
│   └── validator-config/   # validator 配置
├── 共识层
│   ├── consensus/          # 共识规则（含 timestamp_millis 验证、shared_gas_limit）
│   └── commonware-node/    # Commonware Simplex BFT 节点集成
│       ├── consensus/      # Simplex 共识算法
│       ├── dkg/            # Distributed Key Generation（验证者密钥）
│       ├── executor/       # 区块执行
│       ├── epoch/          # epoch 管理
│       ├── feed/           # 数据 feed
│       ├── peer_manager/   # peer 网络管理
│       ├── subblocks/      # 子块（payment lanes 实现可能在此）
│       └── validators/     # 验证者集合管理
├── 执行层
│   ├── evm/                # EVM 集成
│   ├── revm/               # revm 定制
│   └── payload/            # 区块负载构造
├── 协议层（precompiles）
│   ├── precompiles/
│   │   ├── tip20/          # TIP-20 token 标准（核心创新）
│   │   ├── tip20_factory/  # TIP-20 工厂
│   │   ├── tip20_channel_escrow/  # 通道托管
│   │   ├── tip403_registry/# TIP-403 合规策略
│   │   ├── stablecoin_dex/ # 内置稳定币 DEX（Fee AMM 基础）
│   │   ├── tip_fee_manager/# 费用管理器
│   │   ├── account_keychain/  # 智能账户密钥管理
│   │   ├── address_registry/  # 地址注册表
│   │   ├── nonce/          # 2D nonce 系统
│   │   ├── signature_verifier/# 签名验证（含 P256 passkey）
│   │   ├── validator_config/  # validator 配置
│   │   ├── validator_config_v2/
│   │   ├── ip_validation.rs# IP 校验
│   │   └── storage/        # 通用存储
│   ├── contracts/          # Solidity ABI 绑定
│   └── precompiles-macros/ # 写 precompile 的 proc macros
├── 交易层
│   ├── transaction-pool/   # 交易池（含 6030 行的 tt_2d_pool —— 2D nonce 池）
│   └── faucet/             # 测试网水龙头
├── 节点入口
│   ├── node/               # 节点主逻辑
│   └── ext/                # 扩展点
└── e2e/                    # 端到端测试

2.3 Hardfork 时间线（T0 → T6）

Tempo 用 音乐速度术语 命名 hardfork（与 Moderato/Presto 测试网/主网命名一致）：
- Genesis → T0 → T1 → T1.A → T1.B → T1.C → T2 → T3 → T4 → T5 → T6

每个 hardfork 由 genesis 配置的 *_time: Option<u64>（timestamp）激活。代码包含详细 macros 自动生成 fork 检查函数（is_t1_active_at_timestamp 等）。

目标硬分叉：Ethereum Osaka 硬分叉（最新）。

2.4 Gas 模型（从代码确认）

/// T0 base fee: 10 billion attodollars (1×10^10).
pub const TEMPO_T0_BASE_FEE: u64 = 10_000_000_000;

/// T1 base fee: 20 billion attodollars (2×10^10).
pub const TEMPO_T1_BASE_FEE: u64 = 20_000_000_000;

// 计算：50,000 gas × 20B attodollars/gas = 1 quadrillion attodollars
// = 1 quadrillion / 10^12 microdollars
// = 1,000 microdollars = 0.001 USD = 0.1 cents

关键单位：attodollar = 10⁻¹⁸ USD（与 wei 的精度相同，但锚定美元）。
TIP-20 转账目标成本：1000 microdollars = $0.001 = 0.1 美分。

2.5 共识时序（从代码确认）

/// 允许的区块时间未来漂移：0（不允许任何未来漂移）
pub const ALLOWED_FUTURE_BLOCK_TIME_MILLIS: u64 = 0;

/// 区块头额外数据最大 10KiB
pub const TEMPO_MAXIMUM_EXTRA_DATA_SIZE: usize = 10 * 1_024;

强制规则：
- 区块时间戳不允许任何未来漂移（与 Ethereum 的 ~15s 容忍完全不同）
- 这是 Simplex BFT 同步假设的强保证 —— 所有 validator 时钟必须高度同步
- extra_data 限 10KiB（vs Ethereum 32 字节）—— 给 commitment metadata 留空间

2.6 共享 Gas 限制 vs 通用 Gas 限制

代码暗示 payment lanes 的实现机制：

shared_gas_limit          // 共享 gas 配额（所有交易竞争）
general_gas_limit         // 通用（非支付）交易 gas 配额
TEMPO_T1_GENERAL_GAS_LIMIT = 30_000_000  // 30M gas/block 上限给非支付交易

→ 每个区块的 gas 被分成两部分：专用支付通道 + 通用通道。即使非支付应用（DeFi、NFT 等）拥堵，也不影响 TIP-20 转账。

2.7 Bootnodes（从代码确认）

Moderato 测试网（7 个 bootnodes）：
- 148.113.x.x (Canada / Vultr) — 5 个
- 40.160.x.x (US Azure) — 2 个

Presto 主网（9 个 bootnodes）：
- 40.160.x.x (US Azure) — 5 个
- 148.113.x.x (Canada / Vultr) — 3 个
- 15.204.x.x (US OVHcloud) — 2 个

观察：主网 bootnodes 在 3 个不同云厂商（Azure / Vultr / OVH），有意做地理 / 厂商冗余。但所有都在北美 → 亚洲 / 欧洲延迟可能 100ms+，需要后续扩展 PoP。

2.8 2D Transaction Pool（创新点）

crates/transaction-pool/src/tt_2d_pool.rs 是单文件 6030 行（项目最大文件）。

2D nonce 设计：
- 传统 Ethereum nonce 是 1D 顺序（n、n+1、n+2…）—— 严格串行
- Tempo 2D nonce = (key, sequence) → 允许同一账户在不同 key 下并行发交易
- 支付场景下，企业 batch payout 可以多 key 并行执行（10 个 worker 同时发 100 笔，不互相阻塞）
- 这与 Solana 的 transaction-level parallelism 类似，但保留 EVM 兼容性

3. MPP 协议规范代码分析

3.1 仓库结构（tempoxyz/mpp-specs）

specs/
├── core/
│   └── draft-httpauth-payment-00.md     # IETF 草案：HTTP "Payment" 认证 scheme
├── intents/
│   └── draft-payment-intent-charge-00.md # 支付意图：charge（单次扣款）
├── methods/                              # 各种支付方法
│   ├── card/                            # 卡支付（Visa/Mastercard via Stripe）
│   ├── evm/                             # 通用 EVM 链（含 Tempo + ETH + others）
│   ├── lightning/                       # Bitcoin Lightning Network
│   ├── solana/                          # Solana
│   ├── stellar/                         # Stellar
│   ├── stripe/                          # Stripe 直接通道
│   └── tempo/                           # Tempo 链 native（最优路径）
└── extensions/
    ├── draft-payment-discovery-00.md    # 发现机制
    └── transports/                      # 传输层（HTTP / WebSocket / 其他）

关键观察：
- 方法支持范围远超 Tempo：包含 Solana、Stellar、Lightning。这意味着 MPP 是 chain-agnostic 标准，Tempo 不是 MPP 的唯一前端 —— Stripe 想让 MPP 成为类似 HTTP 的通用协议
- IETF 提交格式（draft-*-00.md）= 已经走标准化流程
- Maintained by Tempo Labs + Stripe → 双签（双方法律实体共同负责）

3.2 协议核心流程（基于 README）

1. Client → GET /resource
2. Server → 402 Payment Required
            WWW-Authenticate: Payment <challenge>
3. Client → 履行支付（off-band，按 challenge 指定的方法）
4. Client → GET /resource
            Authorization: Payment <credential>
5. Server → 200 OK
            Payment-Receipt: <receipt>

这是把 HTTP 401（认证失败）的设计直接复刻到 402（支付失败）—— 这是 HTTP 协议设计者 30 年前就预留的状态码，MPP 终于让它有了实际意义。

3.3 设计原则

• Extensible core：核心最小化，留扩展点
• Network agnostic：不偏向任何一条链
• Currency agnostic：不偏向 USD 或任何资产
• Durable by design：基于 web standards，重放保护和安全性是 first-class

4. Accounts SDK（智能账户）

仓库 tempoxyz/accounts，TypeScript / pnpm monorepo。

特色：
- 通过 npm i accounts 安装（占用了 accounts 这个简短 npm 名字！说明 Tempo 在 npm 上有特殊权限或早期注册）
- 提供 ref-impls/ 参考实现 + playgrounds/ 沙盒
- README 包含 “Quick Prompt”：直接给 AI agent 一句话 → “Read docs.tempo.xyz/accounts and integrate Tempo Wallet” —— 显然是为 LLM-driven 集成优化的
- Telegram dev 群：@mpp_devs（公开）

→ Tempo 把 SDK 的 DX 优化到了 “LLM-first” 的程度（不是 human dev-first）。这与 OpenAI/Anthropic 作为 design partner 相吻合 —— Tempo 假设未来的开发者大部分是 AI agent。

5. 与 Reth 的关系

Tempo crates/consensus/src/lib.rs 中：

use reth_chainspec::EthChainSpec;
use reth_consensus::{Consensus, ConsensusError, FullConsensus, ...};
use reth_consensus_common::validation::{
    validate_against_parent_4844,
    validate_against_parent_eip1559_base_fee,
    validate_against_parent_gas_limit,
    validate_against_parent_hash_number,
};
use reth_ethereum_consensus::EthBeaconConsensus;

→ Tempo 共识层是 EthBeaconConsensus 的 wrapper + extensions（添加 millisecond timestamp、shared/general gas limit 验证），主体复用 Reth。

Tempo 团队同时维护 Reth → 当 Reth 2.0 发布时（2026-04），Tempo 主网立即受益 state root 计算 2ms 的优化。Tempo 是 Reth 的最强生产环境验证场。

6. 周边代码（Bridge / Privy / Stripe）

6.1 Privy

github.com/privy-io 公开 SDK 仓库：node-sdk、ruby-sdk、go-sdk、unity-sdk、rust-sdk、aws-agentcore-sdk、privy-ios（XCFramework 二进制分发）

重点观察：
- privy-io/aws-agentcore-sdk 是 2026-05-07 发布的 → 紧跟 AWS Bedrock AgentCore 集成
- privy-io/privy-agentic-wallets-skill 是 OpenClaw skill，让 AI agent 自主创建钱包
- privy-io/privy-mcp-server 是 MCP server → Claude / Cursor / Cline 等 IDE 可以原生调用 Privy

→ Privy 完整地融入了 Tempo + AI agent 工作流，不是孤立的钱包。

6.2 Bridge

Bridge 仓库未在 bridge-xyz org 公开，被 Stripe 整合后可能转入私仓。但 Bridge API（已 GA）作为 Tempo 的 TIP-20 部署伙伴出现在生态页面。

6.3 Paradigm Reth 系列

github.com/paradigmxyz：
- reth: Ethereum 执行客户端（Tempo 直接依赖）
- reth-core: 核心库（Reth 2.0 之后的模块化产物）
- revm: EVM 解释器
- revmc: JIT/AOT 编译器（实验性，给 EVM 字节码做 native code 编译）
- solar: Rust 写的 Solidity 编译器
- stateless: 无状态以太坊验证
- ress: 无状态客户端

Paradigm 在 EVM 工具链上的布局是 全栈（编译器、解释器、JIT、客户端、stateless）。Tempo 是这套工具链的”用户”也是”金主”。

7. 代码质量观察

7.1 工程实践（高分）

✅ Rust edition 2024（最新）
✅ 严格 clippy lints（禁止 dbg!、warn manual-string-new）
✅ reproducible builds（Dockerfile.reproducible）
✅ 统一的 CI/lints/changelogs 仓库（DRY 原则）
✅ 完整 e2e tests（crates/e2e/）
✅ typos.toml 拼写检查
✅ deny.toml 依赖审计
✅ flake.nix Nix 可重现开发环境
✅ xtask 模式（项目自动化任务）

7.2 安全性观察

✅ 签名验证 precompile 独立 crate（signature_verifier），含 P256（passkey）支持 → 减少 signature confusion 风险
✅ TIP-403 合规框架 内置 → 不依赖 dApp 自实现 KYC
✅ 2D nonce 既提性能也减 replay 风险
✅ timestamp 严格化（不允许未来漂移）→ 防止时钟攻击
⚠️ DKG 模块（分布式密钥生成）在 commonware-node/dkg/ —— 复杂代码区，需第三方审计
⚠️ bootnodes 全在北美 —— 地理集中风险

7.3 创新点（代码层面的真实创新）

1. 2D nonce pool（6030 行）—— 业界少见的并行 nonce 设计
2. attodollar gas accounting —— 直接以美元 1e-18 为单位记账
3. payment lanes（shared/general gas limit 双轨制）
4. enshrined stablecoin DEX（precompile 级别）
5. millisecond timestamp（亚秒级 finality 必备）
6. 音乐速度术语 hardfork 命名（Moderato/Presto/T1.A…T6）—— 创新性的 versioning 哲学

8. 代码完整度评估

9. 结论：代码层判断

1. Tempo 不是 vaporware。代码规模 15 万行 Rust + 多语言 SDK，工程完整度堪比 Solana / Optimism。
2. 不是 fork-and-rename 项目。虽然依赖 Reth，但 consensus、precompiles、transaction pool 都是大量自有实现。
3. AI-first 取向明显。从 “Quick Prompt” 到 MPP 标准到 ungoogled-chromium-mpp 浏览器集成，到处可见为 AI agent 优化的痕迹。
4. 企业级工程文化。reproducible builds、Nix、xtask、lints 标准化、CI/changelogs 单独仓库 → 这是 Stripe 工程文化的渗透。
5. 真正的护城河在协议层创新（TIP-20、2D nonce、payment lanes、MPP 标准），不在共识层（Simplex BFT 是别人造的）。

这套代码上来就是奔着取代 SWIFT 去的，不是另一个 DeFi 链。