Tempo コード分析レポート

調査日:2026-05-13
分析対象:github.com/tempoxyz 公開コードリポジトリ
結論:✅ コードは完全オープンソース、規模が大きい(コア Rust コード ~15 万行)、アーキテクチャが明確、エンタープライズ級のエンジニアリング品質

0. 概要

Tempo は珍しいフルスタックオープンソースエンタープライズ系パブリックチェーン。2026-05-13 時点で、tempoxyz GitHub 組織は 30+ の公開リポジトリを公開している。以下を含む:
- 完全な L1 ノード実装(Rust、Reth + Commonware ベース)
- 多言語 SDK(TypeScript、Go、Rust、Python)
- ドキュメントサイト(Vite + Vocs)
- MPP プロトコル仕様(IETF Internet-Draft 提出フォーマット)
- ツールチェーン(Foundry fork、コマンドラインウォレット、オンチェーンインデクサ tidx)
- プライバシー拡張(Zones repo)
- Account Abstraction SDK(accounts repo)

ライセンスは Apache 2.0 / MIT デュアルライセンスに統一(specs 部分は CC0 パブリックドメイン)。

1. リポジトリ一覧と役割

観察:
1. リポジトリは チェーンフルスタック + クロス言語 SDK + ドキュメント + インデクサ + ウォレット + ブラウザ fork をカバー、エンジニアリングの完全性は Solana / Cosmos と同等
2. ungoogled-chromium-mpp リポジトリの存在は、Tempo が MPP をブラウザ層に統合しようとしていることを示す(cookie / カード決済を直接バイパスし、ブラウザネイティブの 402 フロー)
3. tempoxyz/skills の存在は、Tempo が Claude Code / OpenClaw を社内 dev tool 標準として位置付けていることを示す

2. コアリポジトリ(tempoxyz/tempo)の深度分析

2.1 プロジェクトメタデータ

[workspace.package]
version = "1.7.0"
edition = "2024"          # 2024 edition を使用(最新)
rust-version = "1.93.0"   # Rust 最新安定版
license = "MIT OR Apache-2.0"
publish = false           # crates.io には publish しない

• Rust edition 2024 + resolver 3(極めて新しい)を使用
• 厳格な lint 設定:dbg! 禁止、manual-string-new 禁止、use-self 禁止(self 型の混乱回避)
• reproducible Dockerfile を含む(ビルド可再現性を保証、エンタープライズ級 supply chain security に合致)

2.2 Crate 構造(階層別)

crates/
├── 基礎層
│   ├── alloy/              # alloy ツール(Ethereum 型システム)
│   ├── primitives/         # Tempo カスタム型(TempoHeader, TempoTxEnvelope)
│   ├── eyre/               # エラーハンドリング wrapper
│   └── telemetry-util/     # 可観測性ツール
├── チェーン仕様層
│   ├── chainspec/          # チェーン仕様(mainnet/moderato bootnodes、hardforks T0-T6 を含む)
│   └── validator-config/   # validator 設定
├── コンセンサス層
│   ├── consensus/          # コンセンサスルール(timestamp_millis 検証、shared_gas_limit を含む)
│   └── commonware-node/    # Commonware Simplex BFT ノード統合
│       ├── consensus/      # Simplex コンセンサスアルゴリズム
│       ├── dkg/            # Distributed Key Generation(バリデータ鍵)
│       ├── executor/       # ブロック実行
│       ├── epoch/          # epoch 管理
│       ├── feed/           # データ feed
│       ├── peer_manager/   # peer ネットワーク管理
│       ├── subblocks/      # サブブロック(payment lanes 実装の可能性)
│       └── validators/     # バリデーター集合管理
├── 実行層
│   ├── evm/                # EVM 統合
│   ├── revm/               # revm カスタム
│   └── payload/            # ブロック payload 構築
├── プロトコル層(precompiles)
│   ├── precompiles/
│   │   ├── tip20/          # TIP-20 token 標準(コア革新)
│   │   ├── tip20_factory/  # TIP-20 ファクトリー
│   │   ├── tip20_channel_escrow/  # チャネルエスクロー
│   │   ├── tip403_registry/# TIP-403 コンプライアンスポリシー
│   │   ├── stablecoin_dex/ # 内蔵ステーブルコイン DEX(Fee AMM の基礎)
│   │   ├── tip_fee_manager/# 費用マネージャー
│   │   ├── account_keychain/  # スマートアカウント鍵管理
│   │   ├── address_registry/  # アドレスレジストリ
│   │   ├── nonce/          # 2D nonce システム
│   │   ├── signature_verifier/# 署名検証(P256 passkey を含む)
│   │   ├── validator_config/  # validator 設定
│   │   ├── validator_config_v2/
│   │   ├── ip_validation.rs# IP 検証
│   │   └── storage/        # 汎用ストレージ
│   ├── contracts/          # Solidity ABI バインディング
│   └── precompiles-macros/ # precompile 作成用 proc macros
├── トランザクション層
│   ├── transaction-pool/   # トランザクションプール(6030 行の tt_2d_pool —— 2D nonce プールを含む)
│   └── faucet/             # テストネット faucet
├── ノードエントリー
│   ├── node/               # ノードメインロジック
│   └── ext/                # 拡張ポイント
└── e2e/                    # エンドツーエンドテスト

2.3 Hardfork タイムライン(T0 → T6)

Tempo は 音楽のテンポ用語 で hardfork を命名(Moderato/Presto テストネット/メインネット命名と一致):
- Genesis → T0 → T1 → T1.A → T1.B → T1.C → T2 → T3 → T4 → T5 → T6

各 hardfork は genesis 設定の *_time: Option<u64>(timestamp)によりアクティベートされる。コードには fork チェック関数(is_t1_active_at_timestamp 等)を自動生成する詳細な macros が含まれる。

目標ハードフォーク:Ethereum Osaka ハードフォーク(最新)。

2.4 Gas モデル(コードで確認済み)

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

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

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

重要単位:attodollar = 10⁻¹⁸ USD(wei と同精度、ただし米ドルアンカー)。
TIP-20 transfer 目標コスト:1000 microdollars = $0.001 = 0.1 セント。

2.5 コンセンサスタイミング(コードで確認済み)

/// 許容ブロックタイム未来ドリフト:0(未来ドリフトを一切許容しない)
pub const ALLOWED_FUTURE_BLOCK_TIME_MILLIS: u64 = 0;

/// ブロックヘッダ追加データ最大 10KiB
pub const TEMPO_MAXIMUM_EXTRA_DATA_SIZE: usize = 10 * 1_024;

強制ルール:
- ブロックタイムスタンプはあらゆる未来ドリフトを許容しない(Ethereum の ~15s 許容とは全く異なる)
- これは Simplex BFT の同期仮定の強い保証 —— すべてのバリデーターのクロックが高度に同期している必要がある
- extra_data は 10KiB 制限(vs Ethereum 32 byte)—— commitment metadata 用にスペースを確保

2.6 共有 Gas Limit vs 汎用 Gas Limit

コードは payment lanes の実装メカニズムを示唆:

shared_gas_limit          // 共有 gas 枠(すべてのトランザクションが競合)
general_gas_limit         // 汎用(非決済)トランザクションの gas 枠
TEMPO_T1_GENERAL_GAS_LIMIT = 30_000_000  // 30M gas/block を非決済トランザクション上限とする

→ 各ブロックの gas は二部分に分けられる:専用決済チャネル + 汎用チャネル。非決済アプリ(DeFi、NFT 等)が混雑しても、TIP-20 転送には影響しない。

2.7 Bootnodes(コードで確認済み)

Moderato テストネット(7 個 bootnodes):
- 148.113.x.x (Canada / Vultr) — 5 個
- 40.160.x.x (US Azure) — 2 個

Presto メインネット(9 個 bootnodes):
- 40.160.x.x (US Azure) — 5 個
- 148.113.x.x (Canada / Vultr) — 3 個
- 15.204.x.x (US OVHcloud) — 2 個

観察:メインネット bootnodes は 3 つの異なるクラウドベンダー(Azure / Vultr / OVH)に分散、意図的に地理 / ベンダー冗長性を確保。ただしすべて北米 → アジア / 欧州のレイテンシは 100ms+ の可能性、後続で PoP 拡張が必要。

2.8 2D Transaction Pool(イノベーションポイント)

crates/transaction-pool/src/tt_2d_pool.rs は単一ファイル 6030 行(プロジェクトの最大ファイル)。

2D nonce 設計:
- 伝統的 Ethereum nonce は 1D シーケンシャル(n、n+1、n+2…)—— 厳格に直列
- Tempo 2D nonce = (key, sequence) → 同一アカウントが異なる key で並行トランザクション送信可能
- 決済シナリオでは、企業 batch payout が複数 key で並行実行可能(10 workers が同時に 100 transactions を送信、相互ブロックなし)
- これは Solana の transaction-level parallelism に類似、ただし EVM 互換性を保持

3. MPP プロトコル仕様コード分析

3.1 リポジトリ構造(tempoxyz/mpp-specs)

specs/
├── core/
│   └── draft-httpauth-payment-00.md     # IETF ドラフト:HTTP "Payment" 認証 scheme
├── intents/
│   └── draft-payment-intent-charge-00.md # 支払いインテント:charge(単発引き落とし)
├── methods/                              # 各種決済方法
│   ├── card/                            # カード決済(Visa/Mastercard via Stripe)
│   ├── evm/                             # 汎用 EVM チェーン(Tempo + ETH + others 含む)
│   ├── lightning/                       # Bitcoin Lightning Network
│   ├── solana/                          # Solana
│   ├── stellar/                         # Stellar
│   ├── stripe/                          # Stripe 直接チャネル
│   └── tempo/                           # Tempo チェーン native(最適パス)
└── extensions/
    ├── draft-payment-discovery-00.md    # 発見メカニズム
    └── transports/                      # 伝送層(HTTP / WebSocket / その他)

重要観察:
- メソッドのサポート範囲は Tempo をはるかに超える:Solana、Stellar、Lightning を含む。これは MPP が chain-agnostic 標準であることを意味し、Tempo は MPP の唯一のフロントエンドではない —— Stripe は MPP を HTTP のような汎用プロトコルにしたい
- IETF 提出フォーマット(draft-*-00.md)= すでに標準化プロセスを進行中
- Maintained by Tempo Labs + Stripe → 二重署名(両方の法的エンティティが共同責任)

3.2 プロトコルコアフロー(README ベース)

1. Client → GET /resource
2. Server → 402 Payment Required
            WWW-Authenticate: Payment <challenge>
3. Client → 支払いを履行(オフバンド、challenge が指定する方法に従う)
4. Client → GET /resource
            Authorization: Payment <credential>
5. Server → 200 OK
            Payment-Receipt: <receipt>

これは HTTP 401(認証失敗)の設計を 402(支払い失敗)にそのままレプリケートしたもの —— これは 30 年前に HTTP プロトコル設計者が予約していたステータスコードであり、MPP がついに実用的な意義を持たせた。

3.3 設計原則

• Extensible core:コアは最小化、拡張ポイントを残す
• Network agnostic:いかなるチェーンにも偏らない
• Currency agnostic:USD やいかなる資産にも偏らない
• Durable by design:web standards ベース、リプレイ保護とセキュリティが first-class

4. Accounts SDK(スマートアカウント)

リポジトリ tempoxyz/accounts、TypeScript / pnpm monorepo。

特徴:
- npm i accounts でインストール可能(accounts という短い npm 名前を占有!Tempo は npm 上で特殊な権限または早期登録を持っていることを示唆)
- ref-impls/ 参照実装 + playgrounds/ サンドボックスを提供
- README には “Quick Prompt” が含まれる:AI agent に直接「Read docs.tempo.xyz/accounts and integrate Tempo Wallet」と一文 —— 明らかに LLM-driven 統合に最適化されている
- Telegram dev グループ:@mpp_devs(公開)

→ Tempo は SDK の DX を「LLM-first」レベルまで最適化(human dev-first ではない)。これは OpenAI/Anthropic を design partner とすることと一致 —— Tempo は将来の開発者の大部分が AI agent になると仮定している。

5. Reth との関係

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

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

→ Tempo コンセンサス層は EthBeaconConsensus の wrapper + extensions(millisecond timestamp、shared/general gas limit 検証を追加)で、主体は Reth を再利用。

Tempo チームは同時に Reth をメンテナンス → Reth 2.0 がリリースされたとき(2026-04)、Tempo メインネットは即座に state root 計算 2ms の最適化の恩恵を受ける。Tempo は Reth の最強の本番環境検証場。

6. 周辺コード(Bridge / Privy / Stripe)

6.1 Privy

github.com/privy-io 公開 SDK リポジトリ:node-sdk、ruby-sdk、go-sdk、unity-sdk、rust-sdk、aws-agentcore-sdk、privy-ios(XCFramework バイナリ配布)

重点観察:
- privy-io/aws-agentcore-sdk は 2026-05-07 にリリース → AWS Bedrock AgentCore 統合にぴったり追従
- privy-io/privy-agentic-wallets-skill は OpenClaw skill で、AI agent が自律的にウォレットを作成可能
- privy-io/privy-mcp-server は MCP server → Claude / Cursor / Cline 等の IDE がネイティブで Privy を呼び出せる

→ Privy は Tempo + AI agent ワークフローに完全に溶け込んでいる、孤立したウォレットではない。

6.2 Bridge

Bridge リポジトリは bridge-xyz org で公開されていない、Stripe に統合された後 private repo に移った可能性がある。ただし Bridge API(既に GA)は Tempo の TIP-20 デプロイパートナーとしてエコシステムページに登場。

6.3 Paradigm Reth シリーズ

github.com/paradigmxyz:
- reth: Ethereum 実行クライアント(Tempo が直接依存)
- reth-core: コアライブラリ(Reth 2.0 以降のモジュール化産物)
- revm: EVM インタプリタ
- revmc: JIT/AOT コンパイラ(実験的、EVM バイトコードを native code にコンパイル)
- solar: Rust で書かれた Solidity コンパイラ
- stateless: ステートレス Ethereum 検証
- ress: ステートレスクライアント

Paradigm の EVM ツールチェーンにおける配置は フルスタック(コンパイラ、インタプリタ、JIT、クライアント、stateless)。Tempo はこのツールチェーンの「ユーザー」でもあり「金主」でもある。

7. コード品質観察

7.1 エンジニアリング実践(高評価)

✅ Rust edition 2024(最新)
✅ 厳格な clippy lints(dbg! 禁止、manual-string-new を warn)
✅ reproducible builds(Dockerfile.reproducible)
✅ 統一の CI/lints/changelogs リポジトリ(DRY 原則)
✅ 完全な e2e tests(crates/e2e/)
✅ typos.toml スペルチェック
✅ deny.toml 依存性監査
✅ flake.nix Nix 可再現開発環境
✅ xtask パターン(プロジェクト自動化タスク)

7.2 セキュリティ観察

✅ 署名検証 precompile が独立した crate(signature_verifier)、P256(passkey)サポートを含む → signature confusion リスクを低減
✅ TIP-403 コンプライアンスフレームワーク内蔵 → dApp 自己実装 KYC に依存しない
✅ 2D nonce はパフォーマンス向上と replay リスク低減の両方
✅ timestamp 厳格化(未来ドリフトを許容しない)→ クロック攻撃を防止
⚠️ DKG モジュール(分散鍵生成)は commonware-node/dkg/ 内 —— 複雑なコードエリア、サードパーティ監査が必要
⚠️ bootnodes がすべて北米にある —— 地理集中リスク

7.3 イノベーションポイント(コードレベルでの真のイノベーション)

1. 2D nonce pool(6030 行)—— 業界では珍しい並行 nonce 設計
2. attodollar gas accounting —— 米ドル 1e-18 を単位として直接記帳
3. payment lanes(shared/general gas limit 二重トラック制)
4. enshrined stablecoin DEX(precompile レベル)
5. millisecond timestamp(サブセコンドファイナリティに必須)
6. 音楽テンポ用語の hardfork 命名(Moderato/Presto/T1.A…T6)—— 革新的な versioning 哲学

8. コード完全性評価

9. 結論:コードレベルでの判断

1. Tempo は vaporware ではない。コード規模 15 万行 Rust + 多言語 SDK、エンジニアリングの完全性は Solana / Optimism と同等。
2. fork-and-rename プロジェクトではない。Reth に依存しているが、consensus、precompiles、transaction pool は大量の独自実装。
3. AI-first 志向が明確。”Quick Prompt” から MPP 標準、ungoogled-chromium-mpp ブラウザ統合に至るまで、AI agent に最適化された痕跡が至る所に見える。
4. エンタープライズ級エンジニアリング文化。reproducible builds、Nix、xtask、lints 標準化、CI/changelogs 単独リポジトリ → これは Stripe エンジニアリング文化の浸透。
5. 真の moat はプロトコル層のイノベーションにある(TIP-20、2D nonce、payment lanes、MPP 標準)、コンセンサス層ではない(Simplex BFT は他人が作ったもの)。

このコードベースは最初から SWIFT を置き換えに行くものであり、別の DeFi チェーンではない。