Tempo 区块链 — 技术内核 深度报告

调研日期：2026-05-13
调研对象：Tempo（github.com/tempoxyz）— Stripe × Paradigm 联合孵化的支付 L1
报告作者：Claude Code Research Agent
报告范围：仅技术内核（共识 / 执行 / precompile / MPP 协议 / Zones / Accounts / Wallet / 标准库 / 性能 / 安全 / 合约级集成）
报告与 v1 的关系：v1（overview.md）覆盖项目背景、商业逻辑、生态、投资逻辑、风险与判断；v2 不重复任何这些维度，完全聚焦代码与协议层。
主仓技术现状：tempo/repos/tempo 主仓共 337 个 Rust 源文件，161,352 行代码（截至 2026-05-13 git HEAD，version = "1.7.0"，edition = "2024"，rust-version = "1.93.0"）。
字符目标：≥ 35,000 中文字符（不含引用链接）。

0. 内核全景速览

Tempo 主仓是一份罕见地公开了所有”L1 内核细节”的 Rust monorepo：从共识 actor 模型、DKG 协议状态机、Reth 集成方式、precompile 内嵌储存布局、Fee AMM 数学公式、TIP-20 储存槽位、到 RLP 编码格式，全部对外可读。除了少数闭源企业链（Visa B2B Connect、Onyx），主流 L1（Solana / Aptos / Sui / Base）从未把”共识 + 执行 + 内嵌支付协议 + 内嵌 token 标准”四件套在同一仓库以接近生产的工程质量公开。

整个内核可以抽象为五层 + 一个跨链旁挂：

Tempo 的架构哲学可以用一句话概括：”把 Ethereum 已经被博弈过的执行层（Reth/REVM）当只读黑盒，把支付独有的复杂度全部塞进 precompile + 自定义 tx 类型 + 双 lane gas，不动 EVM 字节码、不发新 token“。这是一个非常工程主义的选择——Solana 选择重做执行层（Sealevel）以换取并行，Aptos 选择重做语言（Move）以换取资源模型，Sui 选择重做对象模型以换取 owned-object 并行；Tempo 选择不重做任何下层，所有差异化都用 precompile 这种”既兼容 EVM 调用语义、又可以用 Rust 写任意逻辑”的中间层实现，最大化复用 Ethereum 生态的工具链（Foundry / Hardhat / Solidity / 钱包 SDK）。

1. tempo 主仓 Rust 代码完整结构走读

1.1 workspace 概览

Cargo.toml 顶层声明的 workspace 成员，按职责分组如下（注意所有 tempo-* crate 不向 crates.io 发布，publish = false）：

[workspace]
members = [
  "bin/tempo",
  "bin/tempo-sidecar",
  "crates/alloy",
  "crates/chainspec",
  "crates/commonware-node",
  "crates/commonware-node-config",
  "crates/validator-config",
  "crates/dkg-onchain-artifacts",
  "crates/consensus",
  "crates/eyre",
  "crates/ext",
  "crates/evm",
  "crates/e2e",
  "crates/faucet",
  "crates/node",
  "crates/payload/builder",
  "crates/payload/types",
  "crates/precompiles",
  "crates/precompiles-macros",
  "crates/primitives",
  "crates/contracts",
  "crates/telemetry-util",
  "crates/transaction-pool",
  "crates/revm",
  "xtask",
]
resolver = "3"

引用：Cargo.toml L9-34。

总 26 个 workspace 成员中，按代码体量（基于 wc -l 实测）排前 10 的 crate：

1. crates/transaction-pool：16,039 行 — Tempo 私有 mempool 实现，含 2D nonce 池（tt_2d_pool.rs 单文件 6,030 行）、AMM 状态机（amm.rs 1,037 行）、维护逻辑（maintain.rs 1,167 行）、validator（validator.rs 2,867 行）
2. crates/commonware-node：12,072 行 — 共识层胶水代码，含 DKG manager（actor/mod.rs 1,613 行 + actor/state.rs 1,310 行）、application actor（1,070 行）、executor actor（659 行）、engine（540 行）、epoch manager（556 行）、feed state（498 行）
3. crates/primitives：862 + 8,061（transaction 子目录）= 8,923 行 — Tempo header、Tempo tx envelope、3 套签名编码、authorization 类型
4. crates/precompiles：约 6,500 行（不含 tests）— 12 个 precompile 的 Rust 实现，每个含 dispatch.rs 用于 ABI 调用分派
5. crates/evm：3,862 行 — Tempo EVM 配置、block 执行器、receipt builder
6. crates/contracts：2,216 行 — Solidity 接口的 Rust 镜像，含 tip20.rs（383 行）、stablecoin_dex.rs（199 行）、account_keychain.rs（313 行）、tip20_channel_escrow.rs（398 行）
7. crates/revm：未细统计，但是 Tempo 化的 REVM 包装层
8. crates/payload/builder：负责把 mempool 中的交易组装成 payload
9. crates/chainspec：链规、硬分叉、genesis（DEV/Moderato/Presto 三套 JSON）
10. crates/consensus：1,004 行 — Tempo 共识规则验证器（区别于上层 commonware 共识，这里是 Reth 风格 Consensus<Block> trait 实现）

1.2 共识层 crate 详细走读

1.2.1 crates/consensus（Reth 接口适配）

文件：src/lib.rs:1 (链接)

//! Tempo consensus implementation.
pub struct TempoConsensus {
    /// Inner Ethereum consensus.
    inner: EthBeaconConsensus<TempoChainSpec>,
}

pub const ALLOWED_FUTURE_BLOCK_TIME_MILLIS: u64 = 0;
pub const TEMPO_MAXIMUM_EXTRA_DATA_SIZE: usize = 10 * 1_024; // 10KiB

这个 crate 不是 commonware 共识，而是 Reth 内部 Consensus<Block> trait 的实现——它定义了”一个 sealed 区块在被加入主链前必须满足的同步规则”，类似 Geth/Reth 中的 engine_newPayload 验证：

• validate_header 校验时间戳的毫秒部分（Tempo 在 header 加了 timestamp_millis_part 字段，毫秒粒度）
• validate_header_against_parent 校验 parent 关系、4844 blob 参数、EIP-1559 base fee
• validate_block_pre_execution 校验区块尾部的 system transaction（系统交易必须出现且顺序正确）
• validate_block_post_execution 校验 receipt root、bloom

关键参数：ALLOWED_FUTURE_BLOCK_TIME_MILLIS = 0，意味着 Tempo 完全不允许”未来时间戳”的区块——crates/consensus/src/lib.rs:24 的注释解释：”We are setting this to 0 to not allow any drift of the block time in the future. We are considering this safe because with the way CL works currently block time would be consistent and thus an honest proposer should never produce a block that appears to be in the future even assuming 50-100ms clock drift.”

这是与 Ethereum 主网（ALLOWED_FUTURE_BLOCK_TIME = 15s）完全不同的设计——Tempo 的共识层负责绝对时钟一致性，所以执行层可以信任区块时间戳。

1.2.2 crates/commonware-node（核心共识胶水）

文件：src/lib.rs:1

//! A Tempo node using commonware's threshold simplex as consensus.

整个 commonware-node 通过 actor 模型组织共识，每个 actor 是一个独立的 tokio task，通过 mpsc mailbox 通信。src/consensus/engine.rs:259（链接）定义了 Engine 结构：

pub struct Engine<TContext, TBlocker, TPeerManager> {
    context: ContextCell<TContext>,
    /// broadcasts messages to and caches messages from untrusted peers.
    broadcast: buffered::Engine<TContext, PublicKey, Block, peer_manager::Mailbox>,
    dkg_manager: dkg::manager::Actor<TContext>,
    application: application::Actor<TContext>,
    /// Responsible for keeping the consensus layer state and execution layer
    /// states in sync. Drives the chain state of the execution layer by sending
    /// forkchoice-updates.
    executor: crate::executor::Actor<TContext>,
    /// Listens to consensus events and syncs blocks from the network to the
    /// local node.
    marshal: crate::alias::marshal::Actor<TContext>,
    epoch_manager: epoch::manager::Actor<TContext, TBlocker>,
    peer_manager: peer_manager::Actor<TContext, TPeerManager>,
    feed: crate::feed::Actor<TContext>,
    subblocks: Option<subblocks::Actor<TContext>>,
}

这 8 个 actor 各自的职责（直接来自代码注释 + grep）：

引用：src/consensus/engine.rs:259-285 (链接)。

1.2.3 关键共识参数（crates/commonware-node/src/args.rs）

完整的命令行参数列表（节选关键值，链接）：

#[arg(long = "consensus.wait-for-peer-response", default_value = "2s")]
pub wait_for_peer_response: PositiveDuration,

#[arg(long = "consensus.wait-for-notarizations", default_value = "2s")]
pub wait_for_notarizations: PositiveDuration,

#[arg(long = "consensus.wait-for-proposal", default_value = "1200ms")]
pub wait_for_proposal: PositiveDuration,

#[arg(long = "consensus.wait-to-rebroadcast-nullify", default_value = "10s")]
pub wait_to_rebroadcast_nullify: PositiveDuration,

#[arg(long = "consensus.views-to-track", default_value_t = 256)]
pub views_to_track: u64,

#[arg(long = "consensus.inactive-views-until-leader-skip", default_value_t = 32)]
pub inactive_views_until_leader_skip: u64,

#[arg(long = "consensus.time-to-prepare-proposal-transactions", default_value = "200ms")]
pub time_to_prepare_proposal_transactions: PositiveDuration,

#[arg(long = "consensus.minimum-time-before-propose", default_value = "450ms")]
pub minimum_time_before_propose: PositiveDuration,

#[arg(long = "consensus.time-to-build-subblock", default_value = "100ms")]
pub time_to_build_subblock: PositiveDuration,

#[arg(long = "consensus.synchrony-bound", default_value = "5s")]
pub synchrony_bound: PositiveDuration,

参数语义解读（推导自代码注释）：

• wait_for_proposal = 1200ms：当前 view 的 leader 必须在 1200ms 内发出 proposal，否则进入 nullify 流程
• minimum_time_before_propose = 450ms：proposer 必须等满 450ms 再广播 proposal（保证 block time 稳定 ≥ 450ms 即使空块）
• time_to_prepare_proposal_transactions = 200ms：payload builder 最多花 200ms 执行交易（剩下 250ms 给 state root + sealing）
• views_to_track = 256：activity timeout，超过这个数没新 view 就认为 peer 离线
• inactive_views_until_leader_skip = 32：leader 连续 32 个 view 无活动则被跳过
• synchrony_bound = 5s：允许的时钟漂移上限

由此可以计算出 Tempo 出块节奏：
- 正常情况：~500ms 出块（450ms minimum_time + 50ms 网络 + state root），与官方宣称的”sub-second finality”一致
- 上限情况：1200ms 内必须收到 proposal，否则 nullify 该 view，进入下一 view

1.2.4 crates/commonware-node/src/alias.rs：揭示底层共识方案

pub(crate) mod marshal {
    use commonware_consensus::{
        marshal::{core, standard::Standard},
        simplex::{scheme::bls12381_threshold::vrf::Scheme, types::Finalization},
        types::FixedEpocher,
    };
    use commonware_cryptography::{bls12381::primitives::variant::MinSig, ed25519::PublicKey};
    ...
    pub(crate) type Actor<TContext> = core::Actor<
        TContext,
        Standard<Block>,
        crate::epoch::SchemeProvider,
        immutable::Archive<TContext, Digest, Finalization<Scheme<PublicKey, MinSig>, Digest>>,
        immutable::Archive<TContext, Digest, Block>,
        FixedEpocher,
        Sequential,
        Exact,
    >;
}

引用：crates/commonware-node/src/alias.rs:1-30。

这个 type alias 把 Tempo 用的共识方案明确暴露出来：

• 共识算法：commonware_consensus::simplex — Simplex BFT，特别使用了 bls12381_threshold::vrf::Scheme 变体，意味着 Tempo 使用的是 “Threshold Simplex”（带 BLS12-381 阈值签名 + VRF leader 选举），而不是基础的 Simplex
• 签名变体：bls12381::primitives::variant::MinSig — BLS12-381 的 G2 上短签名变体（96 字节签名，48 字节公钥）
• Peer 公钥：ed25519::PublicKey — peer 间 P2P 用 Ed25519
• Epoch 策略：FixedEpocher — 固定长度 epoch（不是动态调整）
• 存储后端：immutable::Archive<Digest, Finalization> + immutable::Archive<Digest, Block> — 分别归档 finalization 证明与区块

1.3 执行层 crate 详细走读

1.3.1 crates/evm（Tempo EVM 配置）

src/lib.rs:50 (链接)：

pub struct TempoEvmConfig {
    /// Inner evm config
    pub inner: EthEvmConfig<TempoChainSpec, TempoEvmFactory>,
    /// Block assembler
    pub block_assembler: TempoBlockAssembler,
}

impl BlockExecutorFactory for TempoEvmConfig {
    type EvmFactory = TempoEvmFactory;
    type ExecutionCtx<'a> = TempoBlockExecutionCtx<'a>;
    type Transaction = TempoTxEnvelope;
    type Receipt = TempoReceipt;
    type TxExecutionResult = TempoTxResult;
    type Executor<'a, DB: StateDB, I: Inspector<TempoContext<DB>>> = TempoBlockExecutor<'a, DB, I>;
    ...
}

crates/evm/src/block.rs 单文件 1,811 行，是 Tempo 区块执行的主逻辑——它实现 BlockExecutor trait，包装 Reth 原生的 block executor，但在以下几点插入 Tempo 专属逻辑：

1. 在执行第一笔交易前调用 system pre-block transactions（如 epoch 切换时的 validator 更新）
2. 区块结尾追加 end-of-block system transactions（计数由 SYSTEM_TX_COUNT = 1 决定，目前固定为单笔 Address::ZERO 的 system tx）
3. 区块内对每笔交易按 payment lane vs general lane 分别累加 payment_gas_used 和 general_gas_used，写入 header

1.3.2 crates/revm（Tempo REVM 包装）

REVM 是 Reth 用的 Rust EVM 解释器（由 Paradigm 维护）。Tempo 对它做了三件事：

1. 自定义 BlockEnv：扩展为 TempoBlockEnv，多带 shared_gas_limit、general_gas_limit、timestamp_millis_part 字段
2. 自定义 HaltReason：TempoHaltReason 增加 Tempo 专属错误（如 TIP403PolicyDenied、TIP20InvalidCurrency、NoncePolicyViolation）
3. Gas 参数表：tempo_gas_params_with_amsterdam 提供 Tempo 自己的 gas 计费（Amsterdam 是 Ethereum 的 Pectra 后续硬分叉，Tempo 跟随到 Osaka 但 EIP-7825 在 T1A 之后被覆盖为 30M tx gas cap，见 TempoHardfork::T1A 实现）

引用：crates/revm/ 暴露 TempoBlockEnv、TempoHaltReason、TempoStateAccess。

1.3.3 Reth 依赖锚定到具体 commit

Cargo.toml:100-180 范围内大量出现 reth-* = { git = "https://github.com/paradigmxyz/reth", rev = "8248a24" }，全部锁定到同一个 commit hash 8248a24。这是强工程信号——Tempo 不接 Reth 的滚动 main 分支，而是 freeze 到一个具体 commit，等团队评估升级影响后再 bump。这种做法在生产链上是必要的（Reth main 经常 break API），但也意味着 Tempo 维护者要主动跟踪 Reth 安全更新。

从依赖列表里看，至少 40+ 个 reth-* crate 被引用，涵盖：
- reth-engine-local、reth-engine-tree（engine API + 状态树）
- reth-rpc、reth-rpc-api、reth-rpc-builder、reth-rpc-eth-api（RPC 层）
- reth-trie、reth-trie-db、reth-trie-common（状态树）
- reth-network-api、reth-network-peers、reth-discv5（执行层 P2P，Tempo 关闭了执行层 P2P，全部走共识层 P2P）
- reth-payload-builder、reth-payload-primitives、reth-basic-payload-builder（payload 构建）
- reth-stages、reth-static-file、reth-prune-types（存储层）

引用：Cargo.toml 的 [workspace.dependencies] section。

revm = { version = "38.0.0", features = ["optional_fee_charge"], default-features = false } — REVM 38 是 2026 年初的版本，含 optional_fee_charge 特性，允许 EVM 在执行时不强制扣 gas（Tempo 用这个来支持 fee_payer 模式：让 payer 而不是 sender 付 gas）。

1.3.4 Commonware monorepo patch

Cargo.toml:170 的 [patch.crates-io] section：

commonware-broadcast = { git = "https://github.com/commonwarexyz/monorepo", rev = "2a7dd423f0a241276a5a38db8cc3d05f11de0c03" }
commonware-codec = { git = "...", rev = "2a7dd42..." }
commonware-consensus = { git = "...", rev = "2a7dd42..." }
commonware-cryptography = { git = "...", rev = "2a7dd42..." }
commonware-macros = { git = "...", rev = "2a7dd42..." }
commonware-math = { git = "...", rev = "2a7dd42..." }
commonware-p2p = { git = "...", rev = "2a7dd42..." }
commonware-parallel = { git = "...", rev = "2a7dd42..." }
commonware-resolver = { git = "...", rev = "2a7dd42..." }
commonware-runtime = { git = "...", rev = "2a7dd42..." }
commonware-storage = { git = "...", rev = "2a7dd42..." }
commonware-utils = { git = "...", rev = "2a7dd42..." }

注释明确写：”Commonware at HEAD after PR #3588 was merged”。这意味着 Tempo 没有等 Commonware 发版，而是 patch 到 HEAD 的特定 commit（PR #3588 含某个对 Tempo 关键的修复）。这种 patch 方式在工程上更紧密，但暴露了 Tempo 对 Commonware 的强依赖——Tempo 25M 战略投资 Commonware，既是商业绑定也是技术绑定。

12 个 commonware crate 各自的职责（推导自命名 + 实际 import 使用）：

• commonware-codec：通用编码（类似 SCALE 之于 Substrate，alloy_rlp 之于以太坊）
• commonware-consensus：含 simplex、threshold_simplex、marshal 子模块，是核心共识库
• commonware-cryptography：BLS12-381、Ed25519、DKG、VRF
• commonware-p2p：基于 authenticated::lookup 的 P2P 模块，支持 IP 黑名单（Blocker trait）
• commonware-broadcast：广播子模块（buffered）
• commonware-storage：含 archive::immutable 这种”按 height 索引的归档存储”
• commonware-runtime：tokio 上层抽象 + deterministic runtime（用于 e2e 测试的确定性时间）
• commonware-resolver：分布式资源解析（节点 lookup）
• commonware-parallel：并行调度策略（Sequential 是其中一种）
• commonware-math：BLS / 椭圆曲线代数
• commonware-macros：宏（如 select! 重新实现）
• commonware-utils：通用工具

1.4 编译与测试

Justfile 中定义的标准入口（推导自 README + tempo.nu Nushell 脚本）：

• just build-all — cargo build --release 全 workspace
• just localnet — 启动本地 4 节点网络
• just test 或 cargo nextest run — 运行所有测试
• bench-e2e.nu / bench-schelk.nu — Nushell 写的性能 benchmark 脚本

xtask/ 是 Tempo 的运维 CLI（cargo-xtask 风格）。从 README 看，最常用的子命令：

cargo x generate-genesis -o dev.json --accounts 10 --no-dkg-in-genesis

用于本地开发时生成自定义 genesis（带 funded 账户、可选跳过 DKG）。

1.5 构建保证：reproducible builds

Cargo.toml:75-89 定义了专门的 reproducible profile：

[profile.reproducible]
inherits = "release"
lto = "fat"
codegen-units = 1
strip = "none"
debug = "none"
panic = "abort"
incremental = false

注释指出：这个 profile 用于 Dockerfile.reproducible 生成 byte-deterministic Linux x86_64 binary，让外部 rebuilder 可以做 hash 比对验证发布二进制。panic = "abort" 是关键——unwind 会带来 stdlib 单态化的非确定性。

加上 SLSA build provenance + GPG 签名 + SHA-256 校验和 + tempoup installer 自动验证四件套（README 中 “Verifying release binaries” 一节），Tempo 在发布工程上达到的供应链安全级别超过几乎所有 L1——Ethereum 客户端（Geth、Nethermind、Besu）目前都没做到这种程度的 reproducible build。

2. 共识机制深挖

2.1 算法选择：Threshold Simplex

Tempo 不是 PBFT，不是 Tendermint，也不是基础 Simplex，而是 Threshold Simplex（commonware 的变体）。这是 Tempo 25M 战略投资 Commonware（Fortune 报道）后选定的共识方案。

Simplex 基础：由 Cornell/UC Berkeley 的 Benjamin Y. Chan 和 Rafael Pass 于 2023 年在 TCC（Theory of Cryptography Conference）发表的 partially-synchronous BFT 协议（简介）。每个 view 是一次”提案 + 投票”，正常路径下 2 轮通信完成 finalization。

Threshold Simplex 的差异（commonware blog）：

1. BLS12-381 阈值签名嵌入：每当 2f+1 个 validator 在某个 view 的某个阶段（vote/nullify/finalize）签名时，可以本地恢复出一个 threshold signature（约 240 字节），不需要把 2f+1 个签名打包传输
2. VRF Leader Election：用 BLS 阈值随机数作为 VRF 种子，下一个 view 的 leader 在当前 view 结束才能被算出来——攻击者无法提前 grinding
3. Bias-resistant beacon：每个 view 产出一个 unbiased randomness，可以被用于：随机 leader 选举、链上随机数（如 NFT mint）、threshold 加解密（防 MEV 抢跑）

引用：crates/commonware-node/src/alias.rs:6 中的 simplex::scheme::bls12381_threshold::vrf::Scheme 直接对应 commonware 文档的 threshold_simplex 模块。

2.2 BFT 容错参数

从 commonware_consensus 的设计来看（与 Simplex 论文一致）：

• n = 3f + 1 validator 总数
• f = (n-1) / 3 可容忍的拜占庭节点数（标准 PBFT 限制）
• 2f + 1 quorum size，每个 view 必须收到 2f+1 vote 才能 notarize
• 2f + 1 finalize quorum，必须收到 2f+1 finalize 才视为 finalized

Tempo 测试网（Moderato）validator 数量 4 个（来自 Tempo Docs Performance 页面：docs.tempo.xyz/learn/tempo/performance 的 “Byzantine-fault tolerant consensus with four validators on testnet”）。这意味着 f = 1，测试网最多容忍 1 个拜占庭节点。当主网 Visa、Stripe、Zodia Custody 加入后预期会增长到 7-10 个 validator。

2.3 出块时间与最终性

直接从代码常量推导：

Tempo 是“absolute finality”（绝对最终性）链——一旦区块被 finalize 就不会被回滚，这与 Ethereum L1 的”probabilistic finality”（12-15 分钟才达到 Casper 的 supermajority finalization）有本质区别。对支付链来说这是关键属性：500ms 之后商户就可以发货，不用等 6 个块确认。

2.4 Validator 集合管理：链上化

最关键的发现是 Tempo 的 validator 集合不是写死在 chainspec 里，而是动态从链上读取——通过 validator_config_v2 precompile（地址 0xCcCCCCcC00000000000000000000000000000001）查询。

crates/commonware-node/src/dkg/manager/actor/mod.rs:48：

use tempo_precompiles::validator_config_v2::ValidatorConfigV2;

use crate::{
    consensus::{Digest, block::Block},
    validators::{read_active_and_known_peers_at_block_hash, read_validator_config_at_block_hash},
};

crates/commonware-node/src/validators.rs 实现了一个 reader，在每个区块结束时从 ValidatorConfigV2 合约读取当前的 active + known peer 集合。这意味着：

1. 加入 validator：向 ValidatorConfigV2 合约发送 addValidator(...) 调用（需要治理权限或多签授权）
2. 退出 validator：调用 removeValidator 同时启动 DKG 重分配
3. Validator 元数据：包括 Ed25519 公钥（用于 P2P）+ BLS12-381 公钥（用于阈值签名）+ IP/端点 + 偏好的 fee token

引用：crates/contracts/src/precompiles/validator_config_v2.rs（245 行）定义了完整的 Solidity 接口。

2.5 DKG（分布式密钥生成）状态机

crates/commonware-node/src/dkg/manager/actor/mod.rs（1,613 行）和 actor/state.rs（1,310 行）实现了 Tempo 的 DKG。从代码看：

use commonware_cryptography::{
    Signer as _,
    bls12381::{
        dkg::{
            self, DealerLog, DealerPrivMsg, DealerPubMsg, Logs, PlayerAck, SignedDealerLog, observe,
        },
        primitives::{group::Share, variant::MinSig},
    },
    ed25519::{self, PrivateKey, PublicKey},
    transcript::Summary,
};

DKG 的关键消息类型：

• DealerPubMsg<MinSig> — Dealer 广播给所有 player 的公开多项式承诺
• DealerPrivMsg — Dealer 给每个 player 的私有 share（加密）
• PlayerAck<PublicKey> — Player 对 dealer 消息的 ack
• SignedDealerLog — Dealer 完成自己的角色后签名的日志，链上验证用

DKG 在每个 epoch 切换前完成一次，新 epoch 启动时所有 validator 已经拿到自己的 BLS share。tempo-dkg-onchain-artifacts crate 把 DKG 的 outcome 序列化到链上（写入 extra_data 字段或专门的 system tx），让 light client / non-validator 节点也能验证。

引用：crates/commonware-node/src/consensus/application/actor.rs:512-540 显示在 epoch boundary 时如何把 OnchainDkgOutcome 编码进 payload attributes：

let extra_data = if parent_epoch_info.last == parent.height.next
    && parent_epoch_info.epoch == round.epoch
{
    // At epoch boundary: include public ceremony outcome
    let outcome = self.state.dkg_manager
        .get_dkg_outcome(parent_digest, parent.height)
        .await
        .wrap_err("failed getting public dkg ceremony outcome")?;
    outcome.encode.into
}

2.6 Slashing：当前状态

没有发现链上 slashing 实现。grep 整个仓库的 slash 关键字没有匹配（只在 license / 文档里出现）。这与 Tempo 的 validator 模型一致：

• 当前 validator 是许可制（permissioned）的——Visa、Stripe、Zodia 等机构客户
• Slashing 通常用于无许可链（Ethereum、Cosmos）作为经济惩罚
• 许可链可以用法律合同 + 服务等级协议替代 slashing
• Tempo 的双签名行为可以通过 BLS 阈值签名的可验证性 detect，但 enforcement 是链下的（取消 validator 资格）

未来如果 Tempo 走向更开放的 validator 集合（roadmap 上有 “permissionless validation” 提及），可能会引入 slashing 机制——但需要先有 staking 模型，而 Tempo 目前没有原生 token 可质押。

2.7 与其他共识算法的对比

Tempo 选 Threshold Simplex 的根本原因（从 commonware 博客 + 代码注释推导）：

1. 机构客户友好：threshold signature 让链外验证非常简单——任何持有共享公钥的人都可以一行代码验证 finalization 证明，无需重新组装多签
2. 可移植到桥：240 字节证书对桥来说成本极低，桥合约只需验证一个 BLS 签名而不是 ⌈n/3⌉ 个签名
3. MEV 抗性：VRF leader + threshold encryption 让 mempool 暴露给 leader 之前可以被加密（虽然 Tempo 目前没启用）
4. 未来 sharding 友好：threshold 共识天然支持把同一个共识委员会复用到多个分片（commonware blog 的 “Many-to-Many Interoperability” 文章 链接）

3. 执行层与 Reth 的关系

3.1 依赖结构：完全拥抱 Reth SDK

Tempo 不是”基于 Reth 的 fork”，而是”基于 Reth SDK 的下游集成”。区别在于：

• fork 模式（如 Optimism 早期 op-reth、Berachain 早期版本）：把 Reth 源码 fork 到自己仓库，可以任意改动，但需要长期维护 merge
• SDK 模式（Tempo 采用）：把 Reth 当依赖引入，只在自己的 trait 实现里 override 必要部分，不改 Reth 源码

从 Cargo.toml 中 40+ reth-* = { git = ".../reth", rev = "8248a24" } 来看，Tempo 引用的全部是上游 Reth crate，没有任何 fork。Cargo.toml:117-167 有一大段被注释掉的 path 引用：

# [patch."https://github.com/paradigmxyz/reth"]
# reth-basic-payload-builder = { path = "../reth/crates/payload/basic" }
# reth-chain-state = { path = "../reth/crates/chain-state" }
# ...

这些 path 引用用于本地开发——开发者把 Reth clone 到 sibling 目录，启用 path 覆盖，可以本地修改 Reth 看效果，但不会 commit 到主分支。

3.2 哪些 Reth 模块被复用

直接从 workspace.dependencies 列出 + 推断职责：

完全复用（黑盒，不 override）：
- reth-db、reth-db-api、reth-codecs — MDBX 数据库后端
- reth-trie、reth-trie-common、reth-trie-db — Merkle Patricia Trie 状态树
- reth-stages、reth-static-file、reth-prune-types — Sync stages、静态文件存档、修剪
- reth-rpc、reth-rpc-api、reth-rpc-builder、reth-rpc-eth-api、reth-rpc-eth-types、reth-rpc-server-types、reth-rpc-convert — JSON-RPC 服务器（直接复用全套 eth_* 方法）
- reth-payload-builder、reth-payload-primitives、reth-basic-payload-builder — Payload 构建框架
- reth-network-api、reth-network-peers、reth-discv5 — 网络栈接口（但 Tempo 不启用执行层 P2P——共识层用 commonware-p2p）
- reth-tracing — Tracing 日志

部分 override（实现 Tempo 自己的 trait）：
- reth-consensus → Tempo 实现 Consensus<Block> trait（见 crates/consensus/src/lib.rs），主要 override validate_header 加入毫秒时间戳和 gas limit 校验
- reth-evm、reth-evm-ethereum → Tempo 实现 BlockExecutorFactory、ConfigureEvm trait（见 crates/evm/src/lib.rs）
- reth-revm、底层 revm = "38.0.0" → Tempo 在 crates/revm 中提供 TempoBlockEnv、TempoContext，把 precompile dispatch 接入 REVM
- reth-transaction-pool → 完全替换为 crates/transaction-pool 的 TempoTransactionPool，因为 Tempo 的 2D nonce + AMM 维护逻辑无法在标准 reth pool 里表达
- reth-engine-local、reth-engine-tree → Tempo 通过 executor::Actor（共识层 actor）向 engine 发送 forkchoice_updated 调用

3.3 EVM 兼容性级别

目标硬分叉：Ethereum Osaka（README 明确: “Fully compatible with the Ethereum Virtual Machine (EVM), targeting the Osaka hardfork”）

Osaka 是 Ethereum 的第 16 个硬分叉（按 Genesis 起算），引入：
- EIP-7825（per-transaction gas limit cap）
- EIP-7840（blob params per fork）
- EIP-7702（EOA delegation —— Tempo 的 aa_authorization_list 字段就是支持这个）

crates/chainspec/src/genesis/moderato.json 显示 Moderato testnet 在 genesis 就激活了所有 Ethereum 硬分叉：

"homesteadBlock": 0, "eip150Block": 0, "eip155Block": 0, "byzantiumBlock": 0,
"constantinopleBlock": 0, "petersburgBlock": 0, "istanbulBlock": 0,
"berlinBlock": 0, "londonBlock": 0, "mergeNetsplitBlock": 0,
"shanghaiTime": 0, "cancunTime": 0, "pragueTime": 0, "osakaTime": 0

Tempo 自己的硬分叉叠加在 Osaka 之上：T0 → T1 → T1A → T1B → T1C → T2 → T3 → T4 → T5 → T6（crates/chainspec/src/hardfork.rs:283 的 tempo_hardfork! 宏定义）。

EVM 字节码层面：100% 兼容。Tempo 没有引入新 opcode，没有改 EVM gas 表的底层（只是包了一层 Tempo gas params）。Solidity 0.8.20+ 编译的合约可以未修改部署。Foundry、Hardhat、Remix 都直接工作。

RPC 层面：100% 兼容 + Tempo 扩展。
- 所有 eth_* 方法直接可用（来自 Reth）
- tempo_fundAddress — testnet faucet 方法（文档）
- tempo_estimateFee — Tempo tx 的费用估算（与 eth_estimateGas 不同，因为 Tempo tx 是 0x76 类型）
- tempo_sendTransaction — 提交 0x76 Tempo tx

与标准 EVM 的真正差异（docs.tempo.xyz/quickstart/evm-compatibility）：
1. 不支持 native ETH：所有”value”操作必须通过 TIP-20 token，没有 address.balance 概念（账户没有 native balance 字段，从 crates/chainspec/src/genesis/moderato.json 看 alloc 里所有 balance: "0x0"）
2. Gas 用 stablecoin 付：通过 fee manager precompile + Fee AMM，转换为 TIP-20 转账
3. 支持 P256 / WebAuthn 签名：除 secp256k1 外，原生支持 P256（secp256r1）和 WebAuthn
4. 毫秒级时间戳：block.timestamp 仍然是秒，但 header 多带 timestamp_millis_part

3.4 Gas Pricing 机制（attodollars）

crates/chainspec/src/constants.rs:9-29：

/// 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;

/// [TIP-1010] general (non-payment) gas limit: 30 million gas per block.
pub const TEMPO_T1_GENERAL_GAS_LIMIT: u64 = 30_000_000;

/// TIP-1010 per-transaction gas limit cap: 30 million gas.
pub const TEMPO_T1_TX_GAS_LIMIT_CAP: u64 = 30_000_000;

单位语义：
- attodollar = 10^-18 USD（与 ETH 的 wei 类比：wei = 10^-18 ETH）
- microdollar = 10^-6 USD（与 TIP-20 token 的 6 decimals 对齐）
- 换算因子 = 10^12（crates/primitives/src/transaction/mod.rs:38）：

pub const TEMPO_GAS_PRICE_SCALING_FACTOR: U256 = uint!(1_000_000_000_000_U256);

pub fn calc_gas_balance_spending(gas_limit: u64, gas_price: u128) -> U256 {
    U256::from(gas_limit)
        .saturating_mul(U256::from(gas_price))
        .div_ceil(TEMPO_GAS_PRICE_SCALING_FACTOR)
}

TIP-20 转账成本计算（T1+）：
- gas_used ≈ 50,000
- gas_price = 20×10^9 attodollar = TEMPO_T1_BASE_FEE
- spending = 50,000 × 20×10^9 = 1×10^15 attodollar = 1×10^15 / 10^12 = 1,000 microdollar = 0.001 USD = 0.1 美分

这就是 README “TIP-20 transfers target sub-millidollar costs (<$0.001)” 的来源。

双 lane gas 限制（T1+，T4 之前）：

T4 之后（crates/chainspec/src/hardfork.rs 中 shared_gas_limit_at 实现）：

pub const fn shared_gas_limit(&self, block_gas_limit: u64) -> u64 {
    if self.is_t4 {
        0  // T4+: subblocks dead, shared lane = 0
    } else {
        block_gas_limit / 10
    }
}

T4 后取消 subblocks（”subblocks are currently dead” 注释见 crates/commonware-node/src/consensus/engine.rs:220），所有 470M（500M - 30M）gas 都给到 payment + general lane。

3.5 状态存储：Trie 实现

Tempo 直接复用 Reth 的 reth-trie-db、reth-trie-common，采用与 Ethereum mainnet 完全相同的：
- Modified Merkle Patricia Trie（MPT）
- Keccak256 哈希
- MDBX（B+ tree 嵌入式 DB）作为底层 KV store
- 16 进制 nibble 化的 path

precompile 的状态存储也通过这套 MPT ——tempo-precompiles-macros 通过 Rust 宏把 Solidity-like 的 struct field 映射到具体的 storage slot。例如 account_keychain 的 keys: Mapping<Address, Mapping<Address, AuthorizedKey>> 实际就是嵌套 keccak256(...) 计算的两层 slot。

crates/precompiles/src/storage/ 子模块（含 evm.rs、thread_local.rs、hashmap.rs、packing.rs、types/ 等）实现了完整的 storage 抽象层——precompile 可以直接读写 EVM 存储 slot，使得 precompile 的状态可以被 Solidity 合约通过 vm.load(precompile_addr, slot) 读取（虽然实际上 precompile 提供了 view 函数）。

3.6 与 Reth 共建的潜在协同

Paradigm 同时是 Reth 的主开发方（Reth 介绍）和 Tempo 的孵化方，这构成了独特的”工具厂 + 应用方”组合：

1. Tempo 是 Reth SDK 最大、最复杂的下游应用——验证 Reth 模块化设计的工程可用性
2. Tempo 团队（Georgios Konstantopoulos = Paradigm CTO 同时是 Reth 主开发者，从 mpp-specs/specs/methods/tempo/draft-tempo-session-00.md 看他是 MPP session 草案的 co-author）可以直接 push 修复到上游 Reth
3. Reth 的 Execution Extensions（ExEx）框架可以让 Tempo precompile 在 future 升级成”sidecar process”——precompile 运行在独立进程，通过 IPC 与 Reth 通信，避免单进程崩溃影响共识

工程信号最强的一点：Tempo Cargo.toml 中 commonware 用了 git patch（HEAD 后 PR #3588），但 Reth 用了 明确的 commit rev 8248a24——说明 Reth 已经稳定到了”按 release 节奏跟随”的程度，而 commonware 还在快速迭代。

4. MPP（Machine Payments Protocol）协议完整解剖

4.1 问题背景与定位

MPP 解决的是“AI agent 经济”中的根本性 missing piece：当 AI agent 需要为 API、内容、MCP 服务付费时，目前的支付链路全部是为”人类用户”设计的——Stripe Checkout、PayPal、信用卡都需要表单填写、3DS 验证、cookies 会话——这些假设对 agent 不成立。

MPP 把 HTTP 长期保留但未标准化的 402 Payment Required 状态码激活，定义了一套完整的”挑战-应答”协议，让 server 可以在响应中嵌入”你需要付 X 才能拿到这份资源”的结构化挑战，让 client（agent / app / human）按规定方式付款后用一行 HTTP 头重试请求。

引用：mpp.dev、IETF draft、Stripe blog。

4.2 协议核心流程

来自 mpp-specs/specs/core/draft-httpauth-payment-00.md（提交到 IETF 的标准草案，完整草案 PDF）：

Client                                            Server
   |                                                 |
   |  (1) GET /resource                              |
   |---------------------------------------------->  |
   |                                                 |
   |  (2) 402 Payment Required                       |
   |      WWW-Authenticate: Payment                  |
   |         method="tempo"                          |
   |         intent="charge"                         |
   |         request="<base64url(JCS(json))>"        |
   |         realm="api.example.com"                 |
   |         expires="2026-05-13T14:00:00Z"          |
   |<----------------------------------------------  |
   |                                                 |
   |  (3) Client fulfills payment                    |
   |      (signs Tempo tx OR completes Stripe card)  |
   |                                                 |
   |  (4) GET /resource                              |
   |      Authorization: Payment                     |
   |         method="tempo"                          |
   |         type="transaction"                      |
   |         payload="<base64url(signed_tx)>"        |
   |---------------------------------------------->  |
   |                                                 |
   |  (5) Server verifies + (optionally) broadcasts  |
   |                                                 |
   |  (6) 200 OK                                     |
   |      Payment-Receipt: <txhash / receipt-id>     |
   |<----------------------------------------------  |

4.3 协议消息格式

WWW-Authenticate: Payment header 必填参数（来自 mpp-specs/specs/core/draft-httpauth-payment-00.md）：

Authorization: Payment header 必填参数：

JCS 规范：JSON Canonicalization Scheme（RFC 8785）规定了 JSON 的确定性序列化——object key 字典序排列、字符串 UTF-8 NFC、number 表达规范化。MPP 使用 JCS 确保同一份逻辑请求在不同 client 之间产生 byte-identical 的序列化，这是签名必备条件（否则签名会因 key 顺序不同而失败）。

4.4 Tempo charge intent 细节

来自 mpp-specs/specs/methods/tempo/draft-tempo-charge-00.md：

• 作者：Jake Moxey（Tempo Labs）、Brendan Ryan（Tempo Labs）、Tom Meagher（Tempo Labs）
• 定义了 Tempo 链上”一次性转账付费”的具体编码
• 支持 pull / push 两种模式：
• pull：client 签 tx 给 server，server 自己 broadcast（server 可以决定何时上链，可以批量打包）
• push：client 自己 broadcast 后只给 server 返回 tx hash

JSON 请求 schema 示例（基于草案的描述构造）：

{
  "version": "0",
  "chainId": "0xa57f",
  "to": "0x...",
  "value": "5000",
  "token": "0x20c0000000000000000000000000000000000000",
  "memo": "0x...",
  "expires": "2026-05-13T14:00:00Z"
}

chainId 是 16 进制；value 是 microdollar 字符串；token 是 TIP-20 合约地址；memo 是可选的 32 字节备注。

4.5 Tempo session intent 细节

来自 mpp-specs/specs/methods/tempo/draft-tempo-session-00.md：

• 作者：Liam Horne、Georgios Konstantopoulos、Dan Robinson、Brendan Ryan、Jake Moxey（全部 Tempo Labs）
• 定义”开通道支付”——agent 一次开 channel 存入 escrow，后续每次请求只签 voucher 不上链
• 通过 TIP-1028 escrow precompile 实现（crates/contracts/src/precompiles/tip20_channel_escrow.rs 398 行）

Session 流程：

1. Client 调用 escrow precompile openChannel(server, token, amount)，funds 进入 escrow
2. 每次请求 client 签一个 voucher（off-chain，仅 server 验证）：(channel_id, cumulative_amount, signature)
3. Server 累积接收 voucher，cumulative_amount 单调递增
4. Channel 结束时 server 调用 redeemChannel(channel_id, last_voucher) 取走 cumulative_amount，剩余退还 client

这是 Lightning Network 概念在 EVM 上的”简化版”——单方向、不需 HTLC、不需 routing，因为 Tempo 已经是 sub-second finality。

实际成本（README 描述）：voucher 交换 < 100ms 延迟，单条 voucher 成本 = $0.0001 级别（远低于一次链上 tx）。

4.6 与 ISO 20022 / SWIFT 的关系

MPP 完全不与传统支付报文格式（ISO 20022 pacs.008 等）兼容。Tempo 没有声称要替代 SWIFT，但 Patrick Collison 在 X 上把 Tempo 描述为”decentralized, internet-scale SWIFT”。从协议层面看：

• SWIFT 是银行间 message bus（B2B），不直接处理消费者
• MPP 是HTTP-level machine-to-machine 协议（包括消费者）
• 二者面对的”信任假设”不同：SWIFT 假设 message 经过银行 KYC，MPP 假设付款方是 cryptographically authenticated wallet

MPP 与 ISO 20022 的潜在重叠在”payment intent”语义上——pacs.008 也有 charge/credit/debit 等概念，但 MPP 选择完全用 HTTP 原生的 401/402/403 状态码 + WWW-Authenticate scheme，不引入 XML / SWIFT-specific encoding。

4.7 Cloudflare Agents 集成

Cloudflare Agents 文档 显示 Cloudflare 在 2026-03 Tempo 主网上线同周内发布了 MPP 支持，含：

• mpp-proxy：开源 Cloudflare Worker，把任何 origin API 包装成 MPP-gated 端点，自动返回 402 + WWW-Authenticate（GitHub 链接）
• Sidebar 集成：Cloudflare Agents SDK 自动处理 Authorization: Payment 头的生成
• 支持 method：tempo、stripe（card）、lightning、solana

API 例子（推导自 Cloudflare 文档）：

import { mppFetch } from "@cloudflare/agents";

const response = await mppFetch("https://api.example.com/data", {
  wallet: tempoWallet,
  maxSpend: "0.10 USD"
});

Cloudflare 同时支持 x402（Coinbase 的竞争协议，AWS Bedrock AgentCore 集成的版本）和 MPP（Tempo / Stripe 的版本）。但 MPP 的优势是：走 IETF 标准化路径，长期会进入 W3C Payment Request API / fetch 浏览器原生支持。

4.8 AWS Bedrock AgentCore 集成

AWS 官方 blog 显示：

• AWS Bedrock AgentCore Payments 在 2026-05-07 上线 preview
• 集成两个 wallet：Coinbase（用 x402 协议，USDC）+ Stripe（用 Privy SDK，可以 issue Tempo wallet）
• AWS 同时上 x402 和 MPP，但 AWS 自己的 first-party 集成是 x402——MPP 通过 Stripe 间接进入

这意味着 MPP 在 AWS 上”借道 Stripe”——AWS 不直接背书 MPP，但 Stripe 作为 AWS 的支付伙伴会把 MPP 自然带入 AWS 客户。

4.9 MPP vs ERC-4337 vs ERC-7677

MPP 与 ERC-4337 是正交而非竞争：MPP 处理”server 如何让 client 知道要付费”，ERC-4337 处理”用户钱包如何在 EVM 上签名复杂交易”。一个具体 agent 完全可以同时用——MPP 触发协议，ERC-4337 钱包签发 user operation。

4.10 MPP 标准化路径

当前状态（截至 2026-05-13）：
- draft-ryan-httpauth-payment-01 — 已提交 IETF datatracker，2026-03-18 published，category = Standards Track（完整链接）
- draft-tempo-charge-00、draft-tempo-session-00 — Tempo method 草案，category = info
- draft-card-charge-00、draft-stripe-charge-00 — Stripe / 信用卡 method 草案
- draft-evm-charge-00 — 通用 EVM method（Ethereum、Base、Arbitrum、Optimism）
- draft-lightning-charge-00、draft-lightning-session-00 — Bitcoin Lightning
- draft-solana-charge-00、draft-stellar-charge-00 — Solana、Stellar
- draft-payment-discovery-00 — 服务发现扩展（让 agent 知道哪些 URL 支持 MPP）
- draft-payment-transport-mcp-00 — MCP（Model Context Protocol）transport 扩展

IETF working group 当前是 httpauth WG（HTTP Authentication 工作组）的提案，主要 contributor 来自 Tempo Labs 和 Stripe（Brendan Ryan、Jake Moxey、Tom Meagher、Jeff Weinstein、Steve Kaliski 五位是 core 草案 author）。

下一步预期路径：
1. WG adoption（让 httpauth WG 正式接受为 working draft）—— 估计 2026 年底前
2. Last Call → IESG review → RFC publication —— 估计 2027-2028
3. 与此同时，浏览器实现（Chrome、Safari）会先实验性支持

5. accounts 仓库深挖

5.1 仓库定位

accounts 是 Tempo 官方的 Account SDK，目标是让 Web / 移动 App 开发者用 npm 包就能集成 Tempo 钱包，类似 Privy SDK 之于 Ethereum 应用。

GitHub 链接。技术栈：TypeScript + pnpm monorepo + Vite + Wagmi（EVM React 钱包库）。

5.2 目录结构（推导自 find ... -type d）

accounts/
├── src/
│   ├── core/        # 核心账户抽象
│   │   ├── adapters/   # 适配不同钱包后端
│   │   ├── internal/
│   │   └── zod/        # 类型 schema (Zod)
│   ├── server/      # Node.js server 端 SDK
│   │   └── internal/handlers/
│   ├── react/       # React hooks
│   ├── react-native/ # React Native 适配
│   ├── wagmi/       # Wagmi connector
│   ├── cli/         # CLI 工具
│   └── internal/
├── playgrounds/
│   ├── web/
│   ├── wagmi/
│   ├── cli/
│   └── react-native/
├── examples/        # 7 个示例项目
└── ref-impls/
    ├── dialog/      # 自定义 embed dialog 参考实现
    └── cli-auth/    # CLI device-code 认证参考实现

5.3 账户抽象设计

从 README 看，Tempo Account SDK 不是 ERC-4337——它是协议级账户抽象（baked into TempoTransaction 0x76 type），但暴露给开发者的 API 风格类似 ERC-4337：

// 来自 README + examples
import { createTempoWallet } from "accounts";

const wallet = createTempoWallet({
  account: "0x...",
  signWith: "passkey",   // or "secp256k1" / "p256"
});

await wallet.sendTransaction({
  calls: [
    { to: "0x...", data: "0x...", value: 0n },
    { to: "0x...", data: "0x..." }
  ],  // batch calls
  feePayer: "0x...",    // sponsored gas
  feeToken: "0x20c0000000000000000000000000000000000000",  // pathUSD
});

底层这些 SDK 调用会被翻译成单一 0x76 Tempo Transaction（在执行层走标准 EIP-2718 typed transaction 路径）。

5.4 与 ERC-4337 的关系

Tempo Account SDK 完全不依赖 ERC-4337 bundler 基础设施。原因：

1. Tempo Transaction 0x76 类型协议级支持 batch calls（不需要中介合约）
2. Tempo Transaction 协议级支持 fee payer（不需要 paymaster 合约）
3. Tempo 的 2D nonce 让用户可以协议级并行提交多笔交易（不需要 ERC-4337 的 multi-dimensional nonce hack）
4. Account Keychain precompile（地址 0xaAAAaaAA00000000000000000000000000000000）提供”会话密钥 + 花费上限 + 调用范围”管理（不需要 ERC-4337 的 wallet modules）

但 Tempo 仍支持 ERC-4337：
- 因为它兼容 EVM，所以 EntryPoint 0.7 合约可以被部署到 Tempo
- 任何使用 ERC-4337 的应用（Safe、Coinbase Smart Wallet）可以无修改运行在 Tempo
- 不过这条路径经济上不划算——Tempo 原生 0x76 tx 的 gas 成本远低于 ERC-4337 bundler 的开销

5.5 与 Privy（Stripe 子公司）的集成

Stripe 2025-06 收购 Privy，Privy 已经支持 Tempo（Privy docs “Ethereum, Solana, Base, Tempo, and more”）。

集成方式（推导自 accounts 仓库的 examples）：

1. WebAuthn passkey 签名：浏览器调用 navigator.credentials.create({...}) 创建 passkey，public key 是 P256（secp256r1）
2. derive_p256_address：Tempo crates/primitives/src/transaction/tt_signature.rs 中的 derive_p256_address 函数把 P256 公钥转换为 Tempo 地址
3. TempoTransaction 用 P256 签名：SignatureType = P256 (= 1) 标志位 + 129 字节签名（64 字节 ECDSA + 1 字节 v + 64 字节 r/s）

// from crates/primitives/src/transaction/tempo_transaction.rs:21
pub const P256_SIGNATURE_LENGTH: usize = 129;
pub const MAX_WEBAUTHN_SIGNATURE_LENGTH: usize = 2048; // 2KB max

WebAuthn 签名比 P256 大一个量级（最多 2KB），因为它包含完整的 WebAuthn 断言（authenticator data + clientDataJSON + signature），需要链上验证 origin、user presence、anti-replay counter。这是 ERC-4337 / 普通 EVM 链无法做到的——它们只验证签名 hash，不验证 WebAuthn 上下文。

5.6 Account Keychain precompile

crates/precompiles/src/account_keychain/mod.rs:54-118 (链接)：

#[derive(Debug, Clone, Default, PartialEq, Eq, Storable)]
pub struct AuthorizedKey {
    /// Signature type: 0 = secp256k1, 1 = P256, 2 = WebAuthn
    pub signature_type: u8,
    /// Block timestamp when key expires
    pub expiry: u64,
    /// Whether to enforce spending limits for this key
    pub enforce_limits: bool,
    /// Whether this key has been revoked. Once revoked, a key cannot be re-authorized
    /// with the same key_id. This prevents replay attacks.
    pub is_revoked: bool,
}

#[contract(addr = ACCOUNT_KEYCHAIN_ADDRESS)]
pub struct AccountKeychain {
    keys: Mapping<Address, Mapping<Address, AuthorizedKey>>,
    spending_limits: Mapping<B256, Mapping<Address, SpendingLimitState>>,
    key_scopes: Mapping<B256, KeyScope>,
    key_authorization_witnesses: Mapping<Address, Mapping<B256, bool>>,
    transaction_key: Address,
    tx_origin: Address,
}

这是 Tempo 的”原生 session key + spending cap”实现。功能：

1. 会话密钥：用户主密钥（passkey）授权一个临时密钥（如 CLI 工具的本地密钥），临时密钥可以在 expiry 之前签名交易
2. 花费上限：临时密钥每个 token 有 remaining / max / period / period_end 四元组——比如”24 小时内最多花 100 USD pathUSD”
3. 调用范围（key scopes）：T3+ 新增，临时密钥可以被限制为只能调用特定合约的特定 selector（如只能调 TIP20.transfer，不能调任意合约）
4. 撤销：调用 revokeKey 把 is_revoked = true，永久失效（不能 re-authorize 同一 keyId，防 replay）

这等价于 Coinbase Smart Wallet / Safe 的 “Session Key” 模块，但 协议级原生支持——一次 RPC 调用授权，CLI 工具就能签 24 小时内的所有交易而不用每次唤起 passkey。

5.7 Wallet Connect / Dialog 模式

accounts/ref-impls/dialog/ 提供一个 minimal 自定义 embed dialog——开发者可以完全控制弹窗 UI，而不依赖 Privy 的默认 modal。这对企业客户（如希望品牌一致性的银行 / fintech）至关重要。

accounts/ref-impls/cli-auth/ 实现 device-code 流程：CLI 工具在浏览器上展示一个 6 位代码，用户在手机上 visit URL 输入代码 + 完成 passkey 认证——非常类似 GitHub CLI 的设备流。

6. zones 仓库深挖

6.1 概念定位

Zone 是 anchored 到 Tempo mainnet 的私有 / 半私有链。比 Polygon CDK / Optimism Superchain / Arbitrum Orbit 都更紧密的耦合——Zone 不是独立链，它继承 Tempo 的 TIP-403 合规策略，并通过 portal 合约做存提款。

来自 README（GitHub）：

Zones are private blockchains anchored to Tempo (currently available in testnet only), with native support for confidential balances and transactions.

“Zone” 的语义：不是分片（sharding），不是子网（subnet），不是地理区域——而是专用的”私有执行环境”（私有指数据访问权限，而非加密学私有）：
- State access requires account authentication at the RPC layer
- Zone operator maintains full visibility for compliance
- Individual users only see their own balances and transactions

6.2 代码量级

zones/crates/tempo-zone/src/（查看）：

zones/crates/rpc/src/ws.rs 577 行实现 带认证的 WebSocket RPC —— Zone 的核心隐私机制：

• 每个 RPC 请求必须带签名的 auth token
• Auth token 证明请求者控制某个 Zone 账户
• Zone RPC server 过滤返回数据：只返回该账户能看到的状态

6.3 设计意图（通过代码推导）

Zone 解决的核心问题：机构客户需要私密的稳定币结算环境，但又要 Tempo 主网的合规框架（TIP-403）。

工作流：

1. 企业部署 Zone：调用 L1 上的 ZoneFactory 部署 Zone Portal 合约
2. 入金：企业用户调 Portal.deposit(amount) 锁定 TIP-20 到 L1 Portal，Zone sequencer 在 Zone 内 mint 等价资产
3. Zone 内交易：Zone 内每 250ms 出块，所有交易私有（只有 sequencer 和参与方可见）
4. 批量锚定：Zone sequencer 把多个 Zone 块的 state root 打包成 batch 提交到 L1 Portal（每 500ms）
5. TIP-403 同步：Zone 在每块开始时读取 L1 上 TIP-403 策略，如果某地址被加入黑名单，Zone 在下一块就 enforce
6. 出金：用户在 Zone 内调 Outbox.withdraw 销毁资产，证明被打包到下一个 batch，L1 Portal 验证证明后释放 escrow 资金

6.4 跨 Zone 通信

来自 README：

Zone to Zone transfers. Zones interoperate with Tempo via withdrawals with optional calldata.
Withdrawal calldata can execute on Tempo and deposit into another Zone, enabling flows like
Zone to Zone transfers or executing a swap between sending amounts to another Zone.

机制：从 Zone A 提款时附加 calldata，calldata 在 L1 上执行——执行内容可以是”swap + 存到 Zone B”。L1 充当 zone 间的清算层。

这是 超圆滑的设计——它把 LayerZero / Wormhole / Axelar 这种跨链桥的复杂度全部省略：所有 zone 都共享同一个 L1（Tempo mainnet），所以没有跨链通信，只有”提款 + 重新存款”。

6.5 加密存提款

When depositing into a Zone, users can encrypt the recipient to not reveal who receives funds inside the Zone.
Encrypted withdrawals are also possible, allowing the sender to be replaced with a commitment.

实现机制（推断自 zone-precompiles crate）：

• 加密存款：用户在 L1 上调 Portal.depositEncrypted(encryptedRecipient, amount)，链下用 zone operator 公钥加密 recipient
• 加密提款：sender 字段替换为 commitment（Pedersen / kzg 承诺），破坏链上 sender → recipient 的关联性

这给 Zone 提供了 “金额公开 + sender/recipient 私有” 的中间隐私模型（类似 Aztec 但更简化）。完全的金额隐私需要 zk-proofs，Tempo 没有在 Zone 中默认部署 zk verifier。

6.6 部署速度

README 中的快速部署命令：

just deploy-zone my-zone
# 自动：生成 sequencer keypair → 在 L1 funded → 部署 portal → 生成 genesis → 启动节点

这是 5 分钟级别的部署速度——比 Polygon CDK（需要 testnet token）、Arbitrum Orbit（需要 RaaS 服务）都快。

7. tempo-wallet 仓库深挖

7.1 仓库定位

tempo-wallet 是 Tempo 的 CLI 钱包 + HTTP client，含 4 个 binary：

• tempo-wallet — 主 CLI，管理 passkey 登录、access key、session
• tempo-request — MPP-enabled HTTP client，自动处理 402 → sign → retry
• tempo-sign — 离线签名工具
• tempo-test — 测试工具

GitHub 链接。

7.2 架构（custodial / non-custodial / hybrid）

Hybrid 混合托管模型：

• Passkey 存在用户设备的 secure enclave（Touch ID / Face ID / hardware key）—— non-custodial
• Access Key（session 密钥）由 CLI 本地持有 —— non-custodial 但有限权限
• Tempo Wallet 浏览器端（wallet.tempo.xyz）—— Stripe 持有 Privy 基础设施，可能包含 MPC 拆分密钥 —— hybrid

从 README 描述：

1. Run tempo wallet login — the CLI opens your browser to wallet.tempo.xyz
2. Authenticate with your passkey (Touch ID, Face ID, or hardware key)
3. The browser authorizes a session key for the CLI and redirects back
4. The CLI stores the authorized key locally. All subsequent signing happens locally —
   no browser needed.

意味着：
- 用户控制 passkey（不可被 Stripe 替代）
- Passkey 授权一个有限权限的 session key（有 expiry + spending cap）
- Session key 存本地，离线可签
- 如果 session key 被盗，最多损失 spending cap 内的金额（如 $100/day）

7.3 私钥管理

tempo-sign crate 文件结构（推断自 ls 输出）：

crates/tempo-sign/src/
├── key.rs        # 密钥结构
├── error.rs
├── manifest.rs   # 签名 manifest
├── sign.rs       # 签名逻辑
├── main.rs
└── args.rs

从 Cargo.toml 中的依赖（zeroize = "1"、rusqlite = "0.39"、sha2 = "0.11"）推断：

• 私钥用 zeroize crate 保证内存清零（防止 memory dump 泄露）
• 本地存储用 SQLite（rusqlite）+ 文件加密
• 没有 HSM / MPC 集成（这部分由 Privy 后端处理）

7.4 与 Privy / Stripe SDK 的集成

Cargo.toml 关键依赖：

mpp = { version = "0.9.3", features = ["tempo", "evm", "utils", "client", "server"] }
tempo-primitives = { git = "https://github.com/tempoxyz/tempo.git", rev = "7d809cf350e35c92b420a18672222b710f86f77a" }

mpp 是 Rust MPP SDK（crates.io 上的版本 0.9.3），所以 tempo-wallet 是首个原生支持 MPP 的 CLI 钱包。

特性 flag ["tempo", "evm", "utils", "client", "server"] 显示 mpp crate 是模块化的——可以选择只支持 tempo method、或加上 evm method 等。

tempo-request 用例（来自 README）：

# One-shot 付费 charge intent
tempo request https://aviationstack.mpp.tempo.xyz/v1/flights?flight_iata=AA100

# Session 模式（OpenRouter LLM 流式输出）
tempo request -X POST \
  --json '{"model":"openai/gpt-4o-mini","messages":[...]}' \
  https://openrouter.mpp.tempo.xyz/v1/chat/completions

# 关闭 session，结算上链
tempo wallet sessions close https://openrouter.mpp.tempo.xyz

7.5 SLSA 安全发布

README 提到：

SLSA provenance, SBOM, Sigstore signatures, and SHA-256 checksums

完整的供应链安全：
- SLSA Level 3+：build provenance attestation 通过 GitHub Actions OIDC + Sigstore 签名
- SBOM：Software Bill of Materials（CycloneDX 或 SPDX 格式）
- Sigstore：cosign 签名，公开可验证

这套体系比 Geth / Reth / Solana 都完整——很多 L1 客户端只提供 SHA256 checksum，没有 SLSA provenance。

8. tempo-std 标准库深挖

8.1 仓库定位

tempo-std 是 Tempo 的官方 Solidity 标准库，等价于 OpenZeppelin Contracts 之于 Ethereum。

GitHub 链接。安装：forge install tempoxyz/tempo-std。

8.2 设计哲学

tempo-std/src/StdPrecompiles.sol（链接）暴露所有 Tempo precompile 的稳定地址常量：

library StdPrecompiles {
    address internal constant TIP_FEE_MANAGER_ADDRESS = 0xfeEC000000000000000000000000000000000000;
    address internal constant TIP403_REGISTRY_ADDRESS = 0x403c000000000000000000000000000000000000;
    address internal constant TIP20_FACTORY_ADDRESS  = 0x20Fc000000000000000000000000000000000000;
    address internal constant STABLECOIN_DEX_ADDRESS = 0xDEc0000000000000000000000000000000000000;
    address internal constant NONCE_ADDRESS          = 0x4e4F4E4345000000000000000000000000000000;
    address internal constant VALIDATOR_CONFIG_ADDRESS    = 0xCccCcCCC00000000000000000000000000000000;
    address internal constant ACCOUNT_KEYCHAIN_ADDRESS    = 0xaAAAaaAA00000000000000000000000000000000;
    address internal constant VALIDATOR_CONFIG_V2_ADDRESS = 0xCcCCCCcC00000000000000000000000000000001;
    address internal constant ADDRESS_REGISTRY_ADDRESS    = 0xfDC0000000000000000000000000000000000000;
    address internal constant SIGNATURE_VERIFIER_ADDRESS  = 0x5165300000000000000000000000000000000000;
    address internal constant ESCROW_ADDRESS              = 0xE5c0000000000000000000000000000000000000;
}

注意 地址助记：feEC = “fee EC（economic）”、403c = “TIP-403 c”、20Fc = “TIP-20 F factory”、DEc0 = “DEX”、E5c0 = “ESCrow”、5165 = “5IG”（signature）—— 全部是工程师友好的 vanity address。

8.3 标准 Token 列表

tempo-std/src/StdTokens.sol：

library StdTokens {
    address internal constant PATH_USD_ADDRESS  = 0x20C0000000000000000000000000000000000000;
    address internal constant ALPHA_USD_ADDRESS = 0x20C0000000000000000000000000000000000001;
    address internal constant BETA_USD_ADDRESS  = 0x20C0000000000000000000000000000000000002;
    address internal constant THETA_USD_ADDRESS = 0x20C0000000000000000000000000000000000003;
}

测试网 4 套 USD 稳定币全部用 0x20C0... 前缀（TIP-20 标识前缀）。每套之间通过 Stablecoin DEX 互换。

主网（Presto）将添加 USDC、USDT、PYUSD、USD1、KlarnaUSD 等真实稳定币——它们仍然使用 0x20C0... 前缀（前缀是 TIP-20 protocol 强制要求的）。

8.4 交易构建库

tempo-std/src/tx/TempoTransactionLib.sol（链接）—— Solidity 中构建 0x76 Tempo Transaction的 helper 库，用于 Foundry 测试时模拟用户提交 Tempo tx。

支持的字段：
- batch calls（数组）
- 2D nonces（key + value）
- fee_payer + fee_payer_signature
- aa_authorization_list（EIP-7702 风格）
- key_authorization（让 access key 签名生效）

8.5 签名工具库

tempo-std/src/sig/SignatureLib.sol 实现：
- secp256k1 签名 / 低 S 规范化（防 malleability）
- P-256 签名（用于 passkey）
- WebAuthn 断言构造（包含 clientDataJSON 模拟）
- base64url 编解码（WebAuthn 用）
- P-256 公钥 → Tempo 地址 derivation

这套库让单元测试可以完整模拟 passkey 签名流程，无需依赖浏览器环境。

8.6 与 OpenZeppelin 的对比

Tempo 的设计是 协议提供 token / DEX / 合规 / signature 的基础实现，开发者只需要”调用”，不需要”重新实现”——这大幅降低应用合约的攻击面（应用不持有 token 状态，只发起 transfer 调用）。

9. 性能数据与 Benchmarks

9.1 官方宣称指标

9.2 区块浏览器实测

explore.tempo.xyz 是 Moderato 测试网区块浏览器。代码层面的实测特征：

• 区块号：截至 2026-05-13，主网 Presto 已运行 ~6-7M 块（按 500ms/块、3 月主网启动估算）
• 测试网 Moderato：T1B 激活在区块 6,033,587（2026-02-23），T1C 在 7,768,256（2026-03-09），T2 在 10,072,242（2026-03-26）—— 这些区块号直接来自 crates/chainspec/src/constants.rs:96-130
• 平均 block time：从 T1B → T1C 区块差 = 1,734,669，时间差 = 14 天 = 1,209,600 秒，平均出块 0.697 秒 / 块 —— 略高于 500ms 目标，但仍然 sub-second

9.3 Reth 上游性能数据

Reth 本身的性能（来自 Paradigm benchmarks）：
- 16,000 req/sec 单节点 RPS
- 1ms 延迟（cache hit）
- MDBX 持久化：write-ahead log + B+ tree，~100GB 状态比 Geth 占用少 40%

Tempo 把 Reth 这部分完整继承。在 Tempo specific 优化上（mempool 维护、precompile）有额外开销，但执行层瓶颈仍是 Reth 决定的。

9.4 性能瓶颈分析

从代码看，Tempo 当前的瓶颈：

1. state root 计算（time_to_prepare_proposal_transactions = 200ms 后剩下 ~250ms 给 state root + sealing）：
   - state root 在大量 storage write 时计算昂贵
   - Reth 的 parallel trie 已经在 8248a24 commit 中（不确定是否启用）
   - Future 优化：把 state root 计算从 critical path 移除（async commit）

2. 共识消息广播：当前用 commonware-p2p 的 lookup::Network，对每个 message 做 ed25519 验证。在 20+ validator 时，per-message 验证开销线性增长

3. mempool 维护：crates/transaction-pool/src/maintain.rs 1,167 行实现了”在每个新块到达后更新 mempool 状态”——这部分是大量 hash 计算 + storage diff 应用，可能成为 chain reorg（虽然 Tempo finalize 后不 reorg，但 view 切换时有”近 finalize 但未 final”区块）瓶颈

4. AMM 状态机（crates/transaction-pool/src/amm.rs 1,037 行）：每笔交易模拟执行前需要查 Fee AMM 计算 fee swap，如果 mempool 中大量交易竞争同一 AMM pool，可能产生 contention

9.5 与 Solana / Aptos / Sui / Base 的对比

Tempo 的”20,000 TPS”是支付场景下的 TIP-20 转账 TPS，每笔 ~50,000 gas。对比 Aptos 的”10,000 TPS”通常是 token transfer 的 TPS，每笔 ~1,000 gas（Move 资源模型更轻）。单笔交易复杂度上 Tempo > Aptos。

10. 安全审计 + 漏洞历史

10.1 公开审计状态

截至 2026-05-13，Tempo 官方 README 明确声明（README L116）：

Note: Tempo is still undergoing audit and does not have an active bug bounty.
Submissions will not be eligible for a bounty until audits have concluded.

这意味着：
- 没有公开的最终审计报告（截至本报告日期）
- 没有 active bug bounty（Immunefi / HackerOne 上未找到 Tempo bounty 项目）
- 审计正在进行中，未结束

10.2 推测审计方

从 Stripe + Paradigm + Visa 的客户阵容看，可能的审计方：

1. Trail of Bits — Paradigm 投资组合公司常用审计方（Uniswap V4 等）
2. OpenZeppelin — Stripe 加密生态可能复用
3. Halborn — 企业级审计偏好
4. Spearbit — Paradigm 内部审计能力，可能首先 internal review
5. Cantina / Code4rena — 公开 bounty 平台

但这些没有任何一家公开声明审计 Tempo——审计方通常等项目方公布后才在 LinkedIn / 自家博客提及。

10.3 工程信号：内部安全实践

虽然没有公开审计报告，但代码层面的安全实践非常完整：

1. Reproducible builds（详见第 1.5 节）—— 业内仅有少数项目做到
2. SLSA + Sigstore 全套发布签名（tempoup installer 自动验证）
3. deny.toml —— cargo-deny 配置文件，强制依赖审计（禁止已知漏洞 crate）
4. typos.toml —— 拼写检查（防止”reverbed”等拼错的安全函数）
5. rustfmt.toml + clippy.toml（workspace.lints 中 dbg-macro = "warn"、uninlined-format-args = "warn"）—— 静态代码风格强制
6. workspace.lints.rust —— unreachable-pub = "warn"、unused-must-use = "warn"、redundant-lifetimes = "warn" 全开
7. workspace.lints.rustdoc —— all = "warn" 强制文档完整

Cargo.toml:42-56 显示 lint 规则比 Reth 自身更严：

[workspace.lints.clippy]
dbg-macro = "warn"
manual-string-new = "warn"
uninlined-format-args = "warn"
use-self = "warn"
redundant-clone = "warn"

[workspace.lints.rust]
rust-2018-idioms = "warn"
unreachable-pub = "warn"
unused-must-use = "warn"
redundant-lifetimes = "warn"
unnameable-types = "warn"

10.4 已知 issue 历史

从 GitHub issues + commits 看（按 grep 关键字）：

• Issue #1996 “Feat: New cheatcodes for better fuzz testing” —— 显示 Tempo 在做 Foundry fuzz testing（已存在但需扩展）
• 452f4a4 “Add T1C timestamps” commit —— T1C 硬分叉是个配置升级（不是漏洞修复），但说明硬分叉流程在持续运行

没有公开的 critical vulnerability 披露。如果存在漏洞，按 90 天 responsible disclosure 周期，可能在 2026 H2 才会公开。

10.5 Tempo 风险点（代码级别）

通过代码审视识别的潜在风险点：

1. ALLOWED_FUTURE_BLOCK_TIME_MILLIS = 0（crates/consensus/src/lib.rs:24）—— 时钟漂移 50ms 都会让 honest proposer 的区块被拒绝。注释说”with the way CL works currently”——意味着 CL 提供绝对时间同步，但如果 CL bug 导致时间漂移，整个链可能 halt

2. DKG 重做时的 share 重分配（crates/commonware-node/src/dkg/manager/actor/mod.rs）—— 当 validator set 变化时需要重新 DKG。如果重做过程中有 validator 离线，可能产生死锁或多签集合冲突

3. 2D nonce 池（tt_2d_pool.rs 6,030 行）—— 实现复杂度极高。DEFAULT_MAX_TXS_PER_SENDER 是关键参数。如果某 sender 提交大量并行 nonce，可能引发 memory exhaustion

4. Fee AMM 价格不变性（crates/transaction-pool/src/amm.rs 1,037 行）—— AMM 状态在 mempool 模拟时与执行时可能不一致，引发交易意外失败或 fee 计算错误

5. Precompile 状态污染（crates/precompiles/src/storage/）—— precompile 直接读写 EVM storage slot。如果 slot 计算有 collision，可能跨 precompile 状态污染

11. 与稳定币的合约级集成

11.1 测试网稳定币部署地址

来自 crates/chainspec/src/genesis/moderato.json 的 alloc 字段 + tempo-std/src/StdTokens.sol：

所有 token 共用前缀 0x20C0（TIP-20 标识符）。crates/primitives/src/address.rs:1-95 的 is_tip20_prefix 函数：

pub fn is_tip20_prefix(address: Address) -> bool { ... }

被 precompile 严格 enforce ——任何 TIP-20 操作前都会调 validate_usd_currency(address) 检查前缀。

11.2 主网稳定币（Presto，截至 2026-05-13）

• USD1（World Liberty Financial / Trump 系）—— 2026-05-08 宣布首个 native 部署在 Tempo
• USDC（Circle）—— Alchemy 文章 提到 USDC 在主网部署
• USDT（Tether）—— 计划中
• PYUSD（PayPal）—— 计划中
• KlarnaUSD（Klarna 自营）—— 计划主网上线

主网具体地址需查 explore.tempo.xyz 上线浏览器实时确认。

11.3 稳定币付 gas 的合约实现

核心机制：所有 gas 必须用 TIP-20 token 支付。precompile FeeManager（地址 0xfeEC000000000000000000000000000000000000）处理整个流程。

crates/precompiles/src/tip_fee_manager/mod.rs:36-50：

#[contract(addr = TIP_FEE_MANAGER_ADDRESS)]
pub struct TipFeeManager {
    validator_tokens: Mapping<Address, Address>,   // validator → 偏好的 token
    user_tokens: Mapping<Address, Address>,         // user → 偏好的 token
    collected_fees: Mapping<Address, Mapping<Address, U256>>,  // validator → token → amount
    pools: Mapping<B256, Pool>,                      // pool_id → Pool reserves
    total_supply: Mapping<B256, U256>,               // pool_id → LP supply
    liquidity_balances: Mapping<B256, Mapping<Address, U256>>,
    pending_fee_swap_reservation: Mapping<B256, u128>,  // T1C+ 防 frontrun
    two_hop_intermediate: Address,                    // T5+ two-hop routing
}

impl TipFeeManager {
    pub const FEE_BPS: u64 = 25;   // 0.25%
    pub const BASIS_POINTS: u64 = 10000;
    pub const MINIMUM_BALANCE: U256 = uint!(1_000_000_000_U256);
}

11.4 Fee AMM 数学

crates/precompiles/src/tip_fee_manager/amm.rs:14-30：

/// Fee multiplier for fee swaps: 0.9970 scaled by 10000 (30 bps fee).
pub const M: U256 = uint!(9970_U256);
/// Fee multiplier for rebalance swaps: 0.9985 scaled by 10000.
pub const N: U256 = uint!(9985_U256);
/// Scale factor for fixed-point AMM arithmetic (10000).
pub const SCALE: U256 = uint!(10000_U256);
/// Minimum liquidity locked permanently when initializing a pool.
pub const MIN_LIQUIDITY: U256 = uint!(1000_U256);

pub fn compute_amount_out(amount_in: U256) -> Result<U256> {
    amount_in.checked_mul(M).map(|product| product / SCALE).ok_or(...)
}

Fee AMM 不是 Uniswap V2 风格的 xy=k！而是固定汇率 swap：

• 用户付 amount_in userToken，得到 amount_in * 0.9970 validatorToken（30 bps fee）
• 套利者反向 swap 时：用 amount_in * 0.9985 validatorToken 换回 amount_in userToken（15 bps spread）
• 这创造了 0.15% 的稳定套利窗口——任何套利者都可以 keep pool reserves balanced

这是非常聪明的设计——Tempo 不用 oracle（避免 LUNA/UST 那种 oracle 攻击），而是用两个固定汇率创造无风险套利让市场自己 rebalance。前提是 TIP-20 stablecoin 锚定 USD 的假设是 “approximately 1:1”（USDC ≈ USDT ≈ pathUSD ≈ 1 USD），偏离很小。

11.5 Two-hop routing（T5+）

crates/precompiles/src/tip_fee_manager/amm.rs:106-117：

pub enum FeeRoute {
    /// User and validator share the same fee token; no swap is performed.
    SameToken,
    /// Direct pool `(user_token, validator_token)` swap.
    Direct,
    /// Two-hop swap (T5+): routes through `intermediate = userToken.quoteToken`.
    /// Each hop applies the standard `M = 9970/10000` rate sequentially.
    TwoHop(Address),
}

如果 (user_token, validator_token) pool 流动性不足，T5+ 会自动选择两跳路由：user_token → intermediate → validator_token。每跳收 30 bps，总 fee = 60 bps（0.6%）。

intermediate = userToken.quoteToken —— 每个 TIP-20 token 在创建时设定 quoteToken（通常是 pathUSD 作为枢纽），所以 pathUSD 自然成为所有 token 的中心枢纽。

11.6 Validator 收益分配

Validator 直接以稳定币结算 fee：

collected_fees: Mapping<Address, Mapping<Address, U256>>,
// validator address → token address → accumulated amount

每个 block 执行结束时：

1. 用户付 fee（计入 payment_gas_used * gas_price）
2. FeeManager 把 fee 从 userToken swap 成 validatorToken（如果不同）
3. 累加到 collected_fees[validator][validatorToken]
4. Validator 调 distributeFees 提取（任何时间，没有 lockup）

没有 staking、没有 slash、没有 token unlock schedule——validator 就像”网络空间出租方”，按使用量收稳定币费用。

这是 传统 SaaS 经济模型 移植到区块链：
- AWS = 按 EC2 小时数收 USD
- Tempo validator = 按 gas 使用量收 USD（直接以稳定币结算）

11.7 与传统稳定币的合约级集成模式

USDC、USDT 等外部稳定币如何上 Tempo？

不是 bridge——而是直接以 TIP-20 实例发行：
- Circle 部署一个 TIP-20 token，metadata.currency = “USD”，prefix = 0x20C0...
- Circle 用 ISSUER_ROLE 控制 mint/burn（来自 crates/precompiles/src/tip20/roles.rs）
- Circle 在 USDC ↔ 美元的 link 上自己负责（与 Ethereum 上的 USDC 同样模型）

这意味着 Tempo 上的 USDC 与以太坊上的 USDC 是两个独立部署——它们之间没有直接桥接，需要 Circle 自己运营跨链。Tempo 没提供 native bridge（这也是它与 Polygon CDK / Optimism Superchain 的差异——Tempo 把 cross-chain 留给市场）。

12. 5 个最深的技术发现

12.1 发现 1：Tempo 完全用 actor 模型组织共识层

crates/commonware-node 的 8 个 actor 通过 mpsc mailbox 协作，每个 actor 是独立 tokio task。这种设计借鉴自 Erlang BEAM，在 Rust 区块链项目中非常罕见——大多数链用单线程 event loop 或 channel-based pipeline。Actor 模型让 Tempo 可以：
1. 独立测试每个 actor
2. 在 deterministic runtime 下完整重放共识流程（commonware-runtime 的 deterministic 模式）
3. 故障隔离更细粒度（一个 actor panic 不影响其他）

代价是开销略高于 zero-cost abstraction（每条消息一次 mpsc send/recv），但对 500ms block time 完全可接受。

12.2 发现 2：Validator 集合完全链上化，无创世写死

通过 validator_config_v2 precompile（地址 0xCcCCCCcC...01）动态读取 validator 集合。这给 Tempo 一个罕见的属性：可以不分叉升级 validator 配置，只需要走治理流程发交易。Solana validator 列表也在链上但需要 stake，Ethereum validator 集合在 beacon chain；Tempo 直接把 validator config 当 normal precompile state 管，更接近企业目录服务模型。

对企业客户（Visa、Stripe）友好：加 validator 是合规决策，可以走法律审批 + 多签批准，不需要协议级硬分叉。

12.3 发现 3：Threshold BLS 阈值签名让所有共识证书可桥接

来自 commonware-node/src/alias.rs:6 的 simplex::scheme::bls12381_threshold::vrf::Scheme。每个 finalized 区块都附带一个 ~240 字节的 BLS 阈值签名证书，任何持有共享公钥的人都可以验证这个证书——不需要看链上 2f+1 个签名。

这意味着 Tempo 的桥接极其简单：
- 目标链上部署一个 BLS verifier 合约（已有现成实现，gas ~600k）
- Tempo 上的 finalization 事件 + threshold signature 直接发到目标链
- 目标链验证签名（一次 BLS pairing），即可确认 Tempo finalized 这个区块

vs. Ethereum 桥（需要 light client 验证 epoch、Casper finality 12 分钟、签名集合复杂）—— Tempo 的桥成本可能低一个数量级。

12.4 发现 4：Precompile 直接读写 EVM storage slot，达成”协议级合约”的极致

crates/precompiles/src/storage/ 模块实现了让 Rust precompile 直接读写 EVM storage slot 的能力（通过 Mapping<K, V> 抽象映射到 keccak256 计算的 slot）。这让：

1. Precompile 状态对 Solidity 合约可见：通过 view function（getBalance(account) 等）暴露
2. 协议升级时状态自然继承：升级 precompile Rust 代码不影响 storage layout（除非显式 migration）
3. Foundry / Hardhat 可以模拟 precompile 调用：因为底层是 EVM storage 操作，标准工具直接工作

这种”precompile 拥有完整 storage 的协议级合约”在 Substrate / Cosmos 上完全没有——后者的 module 状态与 EVM 状态隔离。Solana 没有 precompile 概念。Tempo 这种设计把”协议改动”的门槛降到与”合约升级”相同。

12.5 发现 5：MPP 把整个 web 的支付体验重新定义为 HTTP 协议

mpp-specs/specs/ 下的 10+ IETF Internet Draft 显示，Tempo 团队的真实野心不是”造一条链”，而是”重新定义 web 支付的 wire protocol”。从 draft-httpauth-payment-00（核心 scheme）到 draft-tempo-charge-00、draft-stripe-charge-00、draft-card-charge-00、draft-evm-charge-00、draft-lightning-charge-00、draft-solana-charge-00、draft-stellar-charge-00、draft-payment-discovery-00、draft-payment-transport-mcp-00，MPP 覆盖了所有主流支付 rail。

如果 MPP 成为 IETF RFC 并被 fetch 浏览器原生实现，Tempo 链本身可能不再是最重要的——MPP 成为标准后，任何 chain / 任何 payment processor 都可以 plug in。Tempo 链只是 MPP 的”首发参考实现”，类比 HTTP/2 与 nghttp2、QUIC 与 lsquic。

这是 Stripe 的经典 platform play：先用自己的链跑通体验，再把协议标准化让其他人可以接入。Stripe 不在乎 Tempo 链是不是垄断——它在乎自己是 MPP 的标准制定者，抽取整个 machine economy 的”协议税”（payment routing、settlement、reconciliation 的服务费）。

13. 数据完整度评分

总体加权平均：8.7 / 10

主要数据空白：
1. 未结束的审计报告（项目方未公开）
2. 实测 third-party benchmark（如 Chainstack、Alchemy 内部数据）
3. Privy 内部 MPC 拆分细节（闭源）
4. v1.7.0 之后的 release notes（T5 / T6 硬分叉时间）

14. 引用源清单（含完整 URL）

GitHub 主仓 + 文件级链接

1. tempoxyz/tempo 主仓
2. tempoxyz/tempo Cargo.toml workspace 配置
3. crates/consensus/src/lib.rs
4. crates/commonware-node/src/consensus/engine.rs
5. crates/commonware-node/src/args.rs（共识参数）
6. crates/commonware-node/src/alias.rs（Threshold Simplex 类型别名）
7. crates/chainspec/src/constants.rs（硬分叉时间戳）
8. crates/chainspec/src/hardfork.rs（hardfork 宏）
9. crates/chainspec/src/genesis/moderato.json
10. crates/contracts/src/lib.rs（precompile 地址）
11. crates/precompiles/src/tip_fee_manager/mod.rs
12. crates/precompiles/src/tip_fee_manager/amm.rs（Fee AMM 数学）
13. crates/precompiles/src/account_keychain/mod.rs
14. crates/precompiles/src/tip20/mod.rs
15. crates/precompiles/src/tip403_registry/mod.rs
16. crates/primitives/src/transaction/mod.rs（gas 换算）
17. crates/primitives/src/transaction/tempo_transaction.rs
18. crates/primitives/src/header.rs（TempoHeader）
19. crates/evm/src/lib.rs（Tempo EVM Config）
20. tempoxyz/tempo issue #1996（fuzz testing cheatcodes）
21. tempoxyz/tempo release v1.6.0（T3 Network Upgrade）
22. tempoxyz/mpp 仓库
23. tempoxyz/mpp-specs 仓库
24. tempoxyz/accounts 仓库
25. tempoxyz/zones 仓库
26. tempoxyz/tempo-wallet 仓库
27. tempoxyz/tempo-std 仓库 + StdPrecompiles.sol
28. tempoxyz/tempo-foundry 仓库（Foundry 扩展）
29. paradigmxyz/reth（执行层依赖）
30. commonwarexyz/monorepo（共识层依赖）
31. cloudflare/mpp-proxy

官方文档

32. docs.tempo.xyz 文档主站
33. Tempo Performance docs
34. EVM Differences
35. Tempo Transaction spec
36. TIP-20 标准
37. TIP-403 Policy Registry
38. TIP-1010 Mainnet Gas Parameters
39. Fee AMM Specification
40. Tempo Faucet
41. WebAuthn & P256 Signatures
42. Account Keychain
43. Tempo Improvement Proposals (TIPs)

IETF / 标准化路径

44. IETF draft-ryan-httpauth-payment-01（核心 MPP scheme）
45. paymentauth.org（MPP 完整 rendered spec）
46. Service Discovery for HTTP Payment Authentication
47. RFC 8785 JSON Canonicalization Scheme

Commonware 文档

48. commonware-consensus simplex docs
49. commonware-consensus threshold_simplex docs
50. Many-to-Many Interoperability with Threshold Simplex（commonware blog）
51. Once a Validator, Not Always a Validator（commonware reshare blog）
52. commonware-cryptography blog
53. Minimmit 2-round BFT
54. Simplex Consensus 论文主页（Ben Chan / Rafael Pass）
55. Patrick O’Grady 个人主页

媒体与第三方分析

56. Stripe blog: Introducing the Machine Payments Protocol
57. Fortune: Stripe-backed Tempo leads $25M for Commonware
58. Cloudflare Agents - MPP docs
59. AWS Bedrock AgentCore Payments blog
60. Tempo Architecture Analysis 1 - Account Abstraction (Seungmin Jeon)
61. Tempo Architecture Analysis 2 - Stablecoin Gas (Seungmin Jeon)
62. Inside Commonware (Decipher Media)
63. Jesus Rodriguez: Fine-Tuning the World Computer on Payments
64. Jesus Rodriguez: Architecture of Autonomous Wealth
65. Visa: Visa Launches Validator Node on Tempo Blockchain
66. The Block: Stripe-led Tempo goes live with AI agent protocol
67. Tempo blog - Introducing Tempo Zones
68. Tempo blog - Stablecoin Fees
69. Tempo blog - TIP-20 token standard for payments
70. Privy docs - Wallet overview (含 Tempo 支持)
71. Chainlist - Tempo Testnet Moderato (chain id 42431)
72. explore.tempo.xyz（Moderato 区块浏览器）
73. Bankless podcast: Tempo Mainnet (Brendan Ryan)
74. Indexing a Blockchain With No Gas Token (8.4M blocks analysis)
75. Paradigm - Introducing Reth
76. Paradigm - Reth Execution Extensions
77. Georgios Konstantopoulos on X - Tempo + Threshold Simplex 解释

报告完。