Tempo ブロックチェーン — 技術内核 v2 深層レポート

調査日：2026-05-13
調査対象：Tempo（github.com/tempoxyz）— Stripe × Paradigm が共同インキュベートした決済 L1
レポート範囲：技術内核のみ（コンセンサス／実行／precompile／MPP プロトコル／Zones／Accounts／Wallet／標準ライブラリ／性能／セキュリティ／コントラクトレベル統合）
との関係：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"）。

0. 内核全景クイックビュー

Tempo のメインリポジトリは、「L1 内核の詳細をすべて公開している、極めて稀な Rust monorepo」である。コンセンサスアクターモデル、DKG プロトコルステートマシン、Reth 統合方式、precompile 埋め込みストレージレイアウト、Fee AMM 数式、TIP-20 ストレージスロット、RLP エンコード形式に至るまで、すべて外部から閲覧可能である。少数のクローズドソース企業チェーン（Visa B2B Connect、Onyx）を除き、主流の L1（Solana / Aptos / Sui / Base）は、「コンセンサス + 実行 + 組込み決済プロトコル + 組込みトークン標準」の 4 点セットを、同じリポジトリで本番に近い工学品質で公開したことは一度もない。

内核全体は 5 層 + 1 つのクロスチェーン補助層に抽象化できる：

Tempo のアーキテクチャ哲学は一文で要約できる：「Ethereum によってすでにゲーム理論的に検証された実行層（Reth/REVM）を読み取り専用のブラックボックスとして扱い、決済固有の複雑さを precompile + カスタム tx タイプ + デュアル lane gas にすべて押し込み、EVM バイトコードには手を加えず、新しいトークンも発行しない」。これは非常に工学主義的な選択である。Solana は並列化のために実行層（Sealevel）を作り直すことを選び、Aptos はリソースモデルのために言語（Move）を作り直すことを選び、Sui は owned-object 並列性のためにオブジェクトモデルを作り直すことを選んだ。Tempo は下層を何も作り直さないことを選び、すべての差別化を「EVM 呼び出しセマンティクスと互換でありながら、Rust で任意のロジックを書ける」中間層である precompile で実現し、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 行（テストを除く）— 12 個の precompile の Rust 実装。各々に ABI 呼び出しディスパッチ用の dispatch.rs を含む
5. crates/evm：3,862 行 — Tempo EVM 設定、ブロック実行器、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：詳細統計はしていないが、REVM の Tempo 化ラッピング層
8. crates/payload/builder：mempool 内のトランザクションを payload に組み立てる責務
9. crates/chainspec：チェーン規則、ハードフォーク、genesis（DEV/Moderato/Presto の 3 種類の 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 はブロック末尾のシステムトランザクションを検証する（システムトランザクションは必ず現れ、順序が正しくなければならない）
• 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 全体はアクターモデルによってコンセンサスを編成する。各アクターは独立した tokio タスクであり、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 つのアクターそれぞれの責務（コードコメント + 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 のリーダーは 1200ms 以内に proposal を発出する必要があり、さもなければ nullify フローに入る
• minimum_time_before_propose = 450ms：proposer は 450ms 経過した後でなければ proposal をブロードキャストできない（ブロックタイムが空ブロックでも ≥ 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：リーダーが連続 32 view 無活動だとスキップされる
• synchrony_bound = 5s：許容される時計ドリフトの上限

これらから Tempo のブロック生成リズムが計算できる：
- 通常時：~500ms ごとにブロック生成（450ms minimum_time + 50ms ネットワーク + state root）。公式が宣言する「sub-second finality」と一致
- 上限時：1200ms 以内に proposal を受信しなければならず、さもなければその view を nullify し、次の 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。

この型エイリアスは Tempo が使うコンセンサススキームを明確に露出する：

• コンセンサスアルゴリズム：commonware_consensus::simplex — Simplex BFT。特に bls12381_threshold::vrf::Scheme バリアントを使用しており、これは Tempo が使っているのが「Threshold Simplex」（BLS12-381 閾値署名 + VRF リーダー選出付き）であり、基本的な 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 ネイティブのブロック実行器をラップするが、以下の点で Tempo 固有のロジックを挿入する：

1. 最初のトランザクションを実行する前にシステム pre-block トランザクションを呼び出す（epoch 切り替え時の validator 更新など）
2. ブロック末尾にend-of-block システムトランザクションを追加する（カウント数は SYSTEM_TX_COUNT = 1 で決定され、現在は固定で Address::ZERO への単一システム 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 はそれに対して 3 つのことをしている：

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 ブランチを追従せず、具体的な commit に freeze し、チームがアップグレード影響を評価した後に bump する。このやり方は本番チェーンでは必須である（Reth main は頻繁に API を break する）が、Tempo メンテナーが Reth のセキュリティ更新を能動的に追跡する必要があることも意味する。

依存リストから見ると、少なくとも 40+ 個の reth-* crate が引用されている。カバー範囲：
- reth-engine-local、reth-engine-tree（engine API + state tree）
- reth-rpc、reth-rpc-api、reth-rpc-builder、reth-rpc-eth-api（RPC 層）
- reth-trie、reth-trie-db、reth-trie-common（state tree）
- 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] セクション。

revm = { version = "38.0.0", features = ["optional_fee_charge"], default-features = false } — REVM 38 は 2026 年初頭のバージョンで、optional_fee_charge 特性を含む。これは EVM が実行時に gas を強制的に差し引かないことを許可する（Tempo はこれを利用して fee_payer モードをサポートする：sender ではなく payer が gas を支払う）。

1.3.4 Commonware monorepo patch

Cargo.toml:170 の [patch.crates-io] セクション：

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 のリリースを待たず、HEAD の特定 commit に patch していることを意味する（PR #3588 には Tempo にとって重要な修正が含まれる）。この patch 方式は工学的により密結合だが、Tempo の Commonware への強い依存を露出する。Tempo は Commonware に 25M を戦略投資しており、これはビジネス的拘束であると同時に技術的拘束でもある。

12 個の commonware crate それぞれの責務（命名 + 実際の import 使用から推導）：

• commonware-codec：汎用エンコーディング（Substrate に対する SCALE、Ethereum に対する 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 ランタイム（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 で書かれたパフォーマンスベンチマークスクリプト

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 バイナリ を生成し、外部 rebuilder が hash 比較によってリリースバイナリを検証できるようにするためのものである。panic = "abort" が鍵である。unwind は stdlib の単態化に非決定性をもたらす。

加えて SLSA build provenance + GPG 署名 + SHA-256 チェックサム + tempoup インストーラの自動検証の 4 点セット（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 が Commonware に 25M を戦略投資（Fortune 報道）した後に選定されたコンセンサススキームである。

Simplex の基礎：Cornell/UC Berkeley の Benjamin Y. Chan と Rafael Pass が 2023 年に TCC（Theory of Cryptography Conference）で発表した partially-synchronous BFT プロトコル（概要）。各 view は 1 回の「提案 + 投票」であり、通常パスでは 2 ラウンドの通信で finalization が完了する。

Threshold Simplex の差異（commonware ブログ）：

1. BLS12-381 閾値署名の組込み：ある view のあるステージ（vote/nullify/finalize）で 2f+1 個の validator が署名するたびに、ローカルで 閾値署名 (threshold signature)（約 240 バイト）を復元でき、2f+1 個の署名をパッケージ化して伝送する必要がない
2. VRF Leader Election：BLS 閾値ランダム数を VRF シードとして使用する。次の view のリーダーは現在の view が終わるまで算出できないため、攻撃者は事前に grinding できない
3. Bias-resistant beacon：各 view は 1 つの unbiased ランダム性を生成し、以下の用途に使える：ランダムリーダー選出、オンチェーンランダム数（NFT mint など）、閾値暗号化（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 バリデーター集合管理：オンチェーン化

最も重要な発見は、Tempo の バリデーター集合が 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 コントラクトから現在のアクティブ + 既知 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 の結果をオンチェーンにシリアライズする（extra_data フィールドまたは専用のシステム tx に書き込む）ことで、ライトクライアント / 非 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 実装は発見されない。リポジトリ全体で slash キーワードを grep してもマッチしない（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. 機関顧客フレンドリー：閾値署名によりオフチェーン検証が極めて簡単になる。共有公開鍵を持つ者なら誰でも一行のコードで finalization 証明を検証でき、多重署名を再組み立てる必要がない
2. ブリッジへの可搬性：240 バイトの証明書はブリッジにとって極めて低コスト。ブリッジコントラクトは ⌈n/3⌉ 個の署名ではなく、1 つの BLS 署名を検証するだけで済む
3. MEV 抗性：VRF リーダー + 閾値暗号化により、メンプールがリーダーに露出する前に暗号化できる（ただし Tempo は現在有効化していない）
4. 将来のシャーディング親和性：閾値コンセンサスは同じコンセンサス委員会を複数のシャードで再利用することを自然にサポートする（commonware ブログの「Many-to-Many Interoperability」記事 リンク）

3. 実行層と Reth の関係

3.1 依存構造：Reth SDK の完全な抱擁

Tempo は「Reth ベースの fork」ではなく、「Reth SDK ベースの下流統合」である。違いは：

• fork モード（初期の 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 を sibling ディレクトリに clone し、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 — Modified 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 参照）。主に validate_header を override してミリ秒タイムスタンプと 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 ディスパッチを 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. ネイティブ ETH をサポートしない：すべての「value」操作は TIP-20 トークンを介する必要があり、address.balance の概念はない（アカウントにはネイティブ 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 トークンの 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 が廃止され（crates/commonware-node/src/consensus/engine.rs:220 のコメント「subblocks are currently dead」参照）、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 を具体的なストレージスロットにマッピングする。例えば account_keychain の keys: Mapping<Address, Mapping<Address, AuthorizedKey>> は実際には入れ子の keccak256(...) 計算による 2 層のスロットである。

crates/precompiles/src/storage/ サブモジュール（evm.rs、thread_local.rs、hashmap.rs、packing.rs、types/ などを含む）は完全なストレージ抽象層を実装する。precompile は EVM ストレージスロットを直接読み書きでき、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 セッションドラフトの共著者）は修正を直接上流 Reth に push できる
3. Reth の Execution Extensions（ExEx）フレームワークにより、Tempo precompile は将来「サイドカープロセス」にアップグレードできる可能性がある。precompile は独立プロセスで実行され、IPC を通じて Reth と通信する。これによって単一プロセスのクラッシュがコンセンサスに影響することを回避できる

工学的シグナルが最強なポイント：Tempo の Cargo.toml で commonware は git patch（HEAD 以降の PR #3588）を使用するが、Reth は明示的な commit rev 8248a24を使用する。これは Reth がすでに「リリースリズムに従って追従する」段階に安定したことを示し、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 ステータスコードを活性化させ、完全な「チャレンジ-レスポンス」プロトコルを定義する。サーバはレスポンスに「このリソースを取得するには X を支払う必要がある」という構造化されたチャレンジを埋め込むことができ、クライアント（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 ヘッダの必須パラメータ（mpp-specs/specs/core/draft-httpauth-payment-00.md 由来）：

Authorization: Payment ヘッダの必須パラメータ：

JCS 仕様：JSON Canonicalization Scheme（RFC 8785）は JSON の決定的シリアライゼーションを規定する。オブジェクトキーの辞書順整列、文字列の UTF-8 NFC、数値表現の規範化。MPP は JCS を使って同じ論理リクエストが異なるクライアント間で byte-identical なシリアライゼーションを生成することを保証する。これは署名に必須の条件である（さもなければ署名がキー順序の違いで失敗する）。

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 2 モードをサポート：
• pull：client が tx に署名してサーバに渡し、サーバ自身がブロードキャストする（サーバはいつオンチェーン化するかを決定でき、バッチパッケージ化が可能）
• push：client が自分でブロードキャストし、サーバには 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 が一度だけチャネルを開設して escrow に資金を預け、その後の各リクエストは voucher に署名するだけでオンチェーン化しない
• TIP-1028 escrow precompile（crates/contracts/src/precompiles/tip20_channel_escrow.rs 398 行）によって実装される

Session フロー：

1. Client が escrow precompile openChannel(server, token, amount) を呼び出すと、資金が escrow に入る
2. リクエストごとに client は voucher に署名する（オフチェーン、サーバのみが検証）：(channel_id, cumulative_amount, signature)
3. サーバは voucher を累積受信する。cumulative_amount は単調に増加する
4. Channel 終了時、サーバが redeemChannel(channel_id, last_voucher) を呼び出して cumulative_amount を引き出し、残額は client に返却される

これは Lightning Network 概念の EVM 上の「簡易版」である。単方向であり、HTLC 不要、routing 不要。なぜなら Tempo はすでに sub-second finality だからである。

実際のコスト（README 記述）：voucher 交換のレイテンシは < 100ms、voucher 1 通あたりのコストは $0.0001 レベル（オンチェーン tx 1 回をはるかに下回る）。

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 レベル machine-to-machine プロトコル（消費者を含む）
• 両者が直面する「信頼仮定」は異なる：SWIFT はメッセージが銀行 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 固有のエンコーディングを導入しない。

4.7 Cloudflare Agents 統合

Cloudflare Agents ドキュメント によると、Cloudflare は 2026-03 Tempo メインネット稼働と同じ週に MPP サポートをリリースした。内容：

• mpp-proxy：オープンソースの Cloudflare Worker。任意の origin API を MPP ゲート付きエンドポイントにラップし、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 にプレビュー版がローンチ
• 2 つのウォレットを統合する：Coinbase（x402 プロトコル、USDC を使用） + Stripe（Privy SDK 使用、Tempo wallet を発行可能）
• AWS は x402 と MPP の両方を載せているが、AWS 自体の first-party 統合は x402である。MPP は Stripe を通じて間接的に入る

これは MPP が AWS で「Stripe 経由」であることを意味する。AWS は MPP を直接エンドースしないが、AWS の支払いパートナーである Stripe が MPP を AWS の顧客に自然に持ち込む。

4.9 MPP vs ERC-4337 vs ERC-7677

MPP と ERC-4337 は競合ではなく直交関係である。MPP は「server がクライアントに支払いが必要であることをどう知らせるか」を扱い、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 公開、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）トランスポート拡張

IETF working group は現在 httpauth WG（HTTP Authentication 作業部会）の提案であり、主な貢献者は Tempo Labs と Stripe 由来（Brendan Ryan、Jake Moxey、Tom Meagher、Jeff Weinstein、Steve Kaliski の 5 名がコアドラフト著者）。

次のステップの予想パス：
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 wallet を統合できるようにすることである。Ethereum 応用に対する Privy SDK に類似する。

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 ではない。プロトコルレベルのアカウント抽象（TempoTransaction 0x76 タイプに組込み）であるが、開発者に露出される API スタイルは ERC-4337 に類似する：

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

const wallet = createTempoWallet({
  account: "0x...",
  signWith: "passkey",   // または "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 ハックは不要）
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 を作成。公開鍵は 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 の「ネイティブセッションキー + spending cap」実装である。機能：

1. セッションキー：ユーザのマスターキー（passkey）が一時キー（CLI ツールのローカルキーなど）を認可し、一時キーは expiry までトランザクションに署名できる
2. 支出上限：一時キーは各 token に対して remaining / max / period / period_end の 4 つ組を持つ。例えば「24 時間以内に最大 100 USD pathUSD を消費」
3. 呼び出し範囲（key scopes）：T3+ で新規追加。一時キーを特定のコントラクトの特定の selector のみ呼び出せるよう制限できる（TIP20.transfer のみ呼び出し可能で、任意のコントラクトは呼び出し不可など）
4. 取り消し：revokeKey を呼び出して is_revoked = true にし、永久に失効させる（同じ keyId で re-authorize できず、replay 防止）

これは Coinbase Smart Wallet / Safe の「Session Key」モジュールと等価だが、プロトコルレベルでネイティブサポートである。一回の RPC 呼び出しで認可すれば、CLI ツールは 24 時間以内のすべてのトランザクションに署名でき、毎回 passkey を呼び出す必要がない。

5.7 Wallet Connect / Dialog モード

accounts/ref-impls/dialog/ は最小限のカスタム embed dialog を提供する。開発者はポップアップ UI を完全にコントロールでき、Privy のデフォルトモーダルに依存しない。これはブランドの一貫性を求める企業顧客（銀行 / fintech など）にとって極めて重要である。

accounts/ref-impls/cli-auth/ は device-code フローを実装する。CLI ツールはブラウザに 6 桁のコードを表示し、ユーザは携帯電話で URL を訪問してコード入力 + passkey 認証を完了する。GitHub CLI のデバイスフローに非常に類似している。

6. zones リポジトリ深掘り

6.1 概念の位置付け

Zone は Tempo メインネットにアンカリングされたプライベート / セミプライベートチェーンである。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 サーバが返却データをフィルタリングする。アカウントが見られる状態のみを返す

6.3 設計意図（コードから推導）

Zone が解決するコア問題：機関顧客はプライベートな stablecoin 決済環境を必要とするが、同時に 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 をバッチとしてパッケージ化し、L1 Portal に送信する（500ms ごと）
5. TIP-403 同期：Zone は各ブロック開始時にL1 上の TIP-403 ポリシーを読み取る。あるアドレスがブラックリストに入れられた場合、Zone は次のブロックで enforce する
6. 出金：ユーザが Zone 内で Outbox.withdraw を呼び出して資産を破棄。証明が次のバッチにパッケージ化され、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 メインネット）を共有するため、クロスチェーン通信はなく、「出金 + 再入金」のみがある。

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 クライアントであり、4 つのバイナリを含む：

• tempo-wallet — メイン CLI。passkey ログイン、access key、session を管理
• tempo-request — MPP 対応 HTTP クライアント。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 を使用してメモリゼロ化を保証する（メモリダンプによる漏洩を防止）
• ローカルストレージは 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 ウォレットである。

特性フラグ ["tempo", "evm", "utils", "client", "server"] は mpp crate がモジュラーであることを示す。tempo method のみのサポート、または evm method 等を追加するなど、選択できる。

tempo-request の使用例（README より）：

# 一回限りの 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 標準ライブラリであり、Ethereum に対する OpenZeppelin Contracts に等価である。

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 アドレス。

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 stablecoin はすべて 0x20C0... プレフィックスを使用する（TIP-20 識別プレフィックス）。それぞれ Stablecoin DEX を経由して相互交換する。

メインネット（Presto）は USDC、USDT、PYUSD、USD1、KlarnaUSD 等の本物の stablecoin を追加する。それらも依然として 0x20C0... プレフィックスを使用する（プレフィックスは TIP-20 プロトコルが強制的に要求する）。

8.4 トランザクション構築ライブラリ

tempo-std/src/tx/TempoTransactionLib.sol（リンク）— Solidity 内で 0x76 Tempo Transaction を構築するヘルパーライブラリ。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. 性能データとベンチマーク

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 に直接由来する
• 平均ブロックタイム：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 はこの部分を完全継承する。Tempo 固有の最適化（mempool メンテナンス、precompile）では追加オーバーヘッドがあるが、実行層のボトルネックは依然として Reth が決定する。

9.4 性能ボトルネック分析

コードから見て、Tempo の現在のボトルネック：

1. state root 計算（time_to_prepare_proposal_transactions = 200ms の後に残る ~250ms が state root + sealing 用）：
   - 大量の storage write がある場合、state root 計算は高コスト
   - Reth の parallel trie はすでに 8248a24 commit に存在する（有効化されているかは不明）
   - 将来の最適化：state root 計算をクリティカルパスから除去する（async commit）

2. コンセンサスメッセージブロードキャスト：現在は commonware-p2p の lookup::Network を使用し、各メッセージに ed25519 検証を行う。20+ validator では per-message 検証オーバーヘッドが線形に増加する

3. mempool メンテナンス：crates/transaction-pool/src/maintain.rs 1,167 行が「各新ブロックが到達した後に mempool 状態を更新する」を実装する。この部分は大量のハッシュ計算 + 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 プールを巡って競合する場合、contention が生じる可能性がある

9.5 Solana / Aptos / Sui / Base との比較

Tempo の「20,000 TPS」は支払いシナリオでの TIP-20 転送 TPS であり、1 件あたり ~50,000 gas。Aptos の「10,000 TPS」は通常 token transfer の TPS で、1 件あたり ~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 インストーラが自動検証）
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 あっただけで、誠実な proposer のブロックが拒否される。コメントは「with the way CL works currently」と言う。これは CL が絶対的な時間同期を提供することを意味するが、CL のバグで時間ドリフトが発生した場合、チェーン全体が停止する可能性がある

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 ストレージスロットを読み書きする。スロット計算に衝突がある場合、precompile 間の状態汚染を引き起こす可能性がある

11. stablecoin とのコントラクトレベル統合

11.1 テストネット stablecoin デプロイアドレス

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 メインネット stablecoin（Presto、2026-05-13 時点）

• USD1（World Liberty Financial / Trump 系）— 2026-05-08 に Tempo 上の最初のネイティブデプロイを発表
• USDC（Circle）— Alchemy 記事 でメインネット上の USDC デプロイに言及
• USDT（Tether）— 計画中
• PYUSD（PayPal）— 計画中
• KlarnaUSD（Klarna 自社）— メインネット稼働計画

メインネットの具体的なアドレスは explore.tempo.xyz でブロックエクスプローラを通じてリアルタイムで確認する必要がある。

11.3 stablecoin で 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+ フロントランニング防止
    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% の安定した裁定ウィンドウを生み出す — どの裁定者でもプールリザーブをバランスに保つことができる

これは非常に賢明な設計である。Tempo は oracle を使わない（LUNA/UST のような oracle 攻撃を回避）。代わりに2 つの固定レートでリスクフリーの裁定機会を作り、市場が自ら 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) プールの流動性が不足する場合、T5+ は自動的に2 ホップルーティングを選択する：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 は直接 stablecoin で fee を決済する：

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

各ブロック実行終了時：

1. ユーザが fee を支払う（payment_gas_used * gas_price として計上）
2. FeeManager が fee を userToken から validatorToken に swap する（異なる場合）
3. collected_fees[validator][validatorToken] に累積する
4. Validator が distributeFees を呼び出して引き出す（任意の時間、ロックアップなし）

staking なし、slash なし、token unlock schedule なし — validator はちょうど「ネットワーク空間の貸主」のようなもので、使用量に応じて stablecoin の料金を徴収する。

これは 伝統的な SaaS 経済モデルをブロックチェーンに移植したもの：
- AWS = EC2 時間数に応じて USD を徴収
- Tempo validator = gas 使用量に応じて USD を徴収（直接 stablecoin で決済）

11.7 伝統的 stablecoin とのコントラクトレベル統合モデル

USDC、USDT 等の外部 stablecoin はどのように 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 ↔ USD の link を自分で運用する（Ethereum 上の USDC と同じモデル）

これは Tempo 上の USDC と Ethereum 上の USDC が2 つの独立したデプロイであることを意味する。両者の間に直接的なブリッジはなく、Circle 自身がクロスチェーンを運用する必要がある。Tempo はネイティブブリッジを提供しない（これも Polygon CDK / Optimism Superchain との違い — Tempo はクロスチェーンを市場に任せる）。

12. 5 つの最も深い技術的発見

12.1 発見 1：Tempo はアクターモデルで完全にコンセンサス層を編成する

crates/commonware-node の 8 つのアクターは mpsc mailbox を通じて協調し、各アクターは独立した tokio タスクである。この設計は Erlang BEAM から借用したもので、Rust ブロックチェーンプロジェクトでは非常に稀である。ほとんどのチェーンは単一スレッドのイベントループまたは channel ベースのパイプラインを使う。アクターモデルにより Tempo は以下を実現できる：
1. 各アクターを独立してテストする
2. deterministic ランタイム下でコンセンサスフローを完全にリプレイする（commonware-runtime の deterministic モード）
3. 障害分離をより細粒度に行う（あるアクターのパニックが他に影響しない）

代償は zero-cost abstraction よりオーバーヘッドが若干高いこと（メッセージ 1 件ごとに 1 回の mpsc send/recv）だが、500ms ブロックタイムには完全に許容できる。

12.2 発見 2：バリデーター集合が完全にオンチェーン化されており、creation での hardcode はない

validator_config_v2 precompile（アドレス 0xCcCCCCcC...01）を通じてバリデーター集合を動的に読み取る。これは Tempo に稀有な属性を与える：フォークなしでバリデーター設定をアップグレードでき、ガバナンスフローを通じてトランザクションを発信するだけでよい。Solana のバリデーターリストもオンチェーンだが stake が必要で、Ethereum のバリデーター集合は beacon chain にある。Tempo は直接バリデーター設定を通常の precompile state として管理し、より企業のディレクトリサービスモデルに近い。

企業顧客（Visa、Stripe）にフレンドリーである：バリデーターの追加はコンプライアンス判断であり、法的承認 + 多重署名承認のフローを通せる。プロトコルレベルのハードフォークは不要。

12.3 発見 3：閾値 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 イベント + 閾値署名を直接ターゲットチェーンに送信する
- ターゲットチェーンが署名を検証する（一回の BLS pairing）だけで、Tempo がそのブロックを finalized したことを確認できる

vs. Ethereum ブリッジ（light client が epoch を検証する必要があり、Casper finality が 12 分、署名集合が複雑）— Tempo のブリッジコストはひと桁低い可能性がある。

12.4 発見 4：Precompile が直接 EVM ストレージスロットを読み書きし、「プロトコルレベルコントラクト」の極致を達成する

crates/precompiles/src/storage/ モジュールは Rust precompile が EVM ストレージスロットを直接読み書きする能力を実装する（Mapping<K, V> 抽象を通じて keccak256 計算によるスロットにマッピング）。これにより：

1. Precompile 状態が Solidity コントラクトから可視：view 関数（getBalance(account) 等）を通じて露出
2. プロトコルアップグレード時に状態が自然継承される：precompile Rust コードのアップグレードはストレージレイアウトに影響しない（明示的な migration を除く）
3. Foundry / Hardhat が precompile 呼び出しをシミュレート可能：底層が EVM ストレージ操作なので、標準ツールが直接動作する

「完全な storage を持つプロトコルレベルコントラクト」というこの種の precompile は Substrate / Cosmos には完全に存在しない。後者のモジュール状態は EVM 状態と隔離されている。Solana には precompile 概念がない。Tempo のこの設計は「プロトコル変更」のハードルを「コントラクトアップグレード」と同じにまで下げる。

12.5 発見 5：MPP は web 全体の支払い体験を HTTP プロトコルとして再定義する

mpp-specs/specs/ 下の 10+ 個の IETF Internet Draft は、Tempo チームの真の野心が「チェーンを 1 本作る」ではなく、「web 支払いの wire protocol を再定義する」ことであることを示す。draft-httpauth-payment-00（コアスキーム）から 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 はすべての主流の支払いレールをカバーする。

もし MPP が IETF RFC になり、fetch ブラウザでネイティブ実装されると、Tempo チェーン自体は最も重要ではなくなる可能性がある — MPP が標準になれば、任意のチェーン / 任意の 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 ベンチマーク（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 ブログ）
51. Once a Validator, Not Always a Validator（commonware reshare ブログ）
52. commonware-cryptography ブログ
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 解説

レポート完。