Circle Arc コード分析

調査日: 2026-05-13
主な出典: GitHub circlefin/ org(公開オープンソース Apache-2.0)
クローン位置: ark/repos/


1. リポジトリマップ

Circle は Arc を完全に circlefin/ GitHub org 配下にオープンソース化している。合計 87+ 公開リポジトリ、Arc に直接関連するコアリポジトリ:

リポジトリ 役割 ステータス
circlefin/arc-node L1 ノード本体(コアリポジトリ) alpha、監査中
circlefin/malachite コンセンサスエンジン(Tendermint BFT in Rust) alpha
circlefin/malachite-mempool Mempool 実装 active
circlefin/malaketh-turbo Malachite + 強化 ETH 実行クライアント active
circlefin/malaketh-layered Malachite を ETH 実行クライアントのコンセンサスとして使用(Engine API 経由) active
circlefin/arc-remote-signer AWS Nitro Enclaves 署名サービス active
circlefin/arc-nanopayments gas なし USDC マイクロペイメント sample sample
circlefin/arc-p2p-payments P2P 決済 sample sample
circlefin/arc-fintech マルチチェーントレジャリー sample sample
circlefin/arc-multichain-wallet USDC クロスチェーンウォレット sample sample
circlefin/arc-commerce USDC 商業決済 sample sample
circlefin/arc-defi-lending-and-borrowing DeFi 貸借 sample(cirBTC 担保で USDC 借入) sample
circlefin/arc-stablecoin-fx StableFX swap sample sample
circlefin/arc-prediction-markets UMA プロトコル予測市場 sample sample
circlefin/arc-escrow AI 検証エスクローワークフロー sample sample
circlefin/skills Circle オープンソースの AI 補助開発 skills active

傍流だが関連する Circle エコシステムリポジトリ:
- circlefin/evm-cctp-contractscirclefin/aptos-cctpcirclefin/sui-cctpcirclefin/stellar-cctpcirclefin/solana-cctp-contractscirclefin/starknet-cctpcirclefin/cctp-go
- circlefin/stablecoin-evmcirclefin/stablecoin-nearcirclefin/stablecoin-xlmcirclefin/noble-fiattokenfactory
- circlefin/evm-gateway-contractscirclefin/solana-gateway-contracts
- circlefin/evm-xreserve-contractscirclefin/evm-cpn-contracts(Circle Payments Network)
- circlefin/hyperevm-circle-contractscirclefin/buidl-wallet-contractscirclefin/modularwallets-web-sdk
- circlefin/circle-bridge-kit-transfercirclefin/circle-cctp-crosschain-transfer
- circlefin/refund-protocol(オンチェーン決済紛争コントラクト)
- circlefin/chainmail(オンチェーン認証メール —— 興味深い実験)


2. arc-node 詳細構造

2.1 トップレベルレイアウト

arc-node/
├── Cargo.toml          # Workspace root (resolver = "2", edition 2024, Rust 1.91+)
├── Makefile
├── README.md
├── arcup               # ツールスクリプト
├── assets/             # Genesis ファイル等
├── buf.yaml            # Protobuf 設定
├── contracts/          # Solidity コントラクト(システムレベル)
│   ├── src/
│   │   ├── Denylist.sol
│   │   ├── Precompiles.sol
│   │   ├── batch/Multicall3From.sol
│   │   ├── call-from/ICallFrom.sol
│   │   ├── memo/Memo.sol
│   │   ├── pq/IPQ.sol
│   │   ├── protocol-config/ProtocolConfig.sol
│   │   ├── proxy/AdminUpgradeableProxy.sol
│   │   └── validator-manager/
│   │       ├── PermissionedValidatorManager.sol
│   │       └── ValidatorRegistry.sol
│   └── lib/{forge-std, openzeppelin-contracts, openzeppelin-contracts-upgradeable}
├── crates/             # Rust workspace (25 crates)
├── deployments/
├── docker-bake.hcl
├── docs/
│   ├── ARCHITECTURE.md
│   ├── installation.md
│   ├── running-an-arc-node.md
│   ├── monitoring.md
│   └── PROFILING.md
├── foundry.toml
├── hardhat.config.ts
├── package.json        # Node.js dependencies for contracts
├── rust-toolchain.toml
├── scripts/
└── tests/

2.2 25 個の Rust Crates 完全リスト

Crate 役割
node メイン実行ノード(arc-node-execution
malachite-app コンセンサスアプリ(arc-node-consensus
malachite-cli コンセンサス CLI
eth-engine Engine API クライアント(コンセンサス ↔ 実行通信)
evm EVM カスタム層(base fee、precompile 統合)
evm-node EVM ノードラッパー
evm-specs-tests EVM 仕様テスト
precompiles 5 つのカスタム precompiles
execution-config 実行層設定(hardforks 含む)
execution-payload Payload ビルダー
execution-txpool トランザクションプール(カスタム検証)
execution-validation ブロック検証
execution-e2e エンドツーエンド実行テスト
consensus-db コンセンサスデータベース
types 共有タイプ
shared 共有ツール
signer ローカル署名者
remote-signer リモート署名者(AWS Nitro)
snapshots チェーンスナップショットツール
engine-bench エンジンベンチマーク
mesh-analysis ネットワークトポロジー分析
quake 内部ツール(test framework macro?)
spammer ストレステストツール
version バージョン情報
test/framework + test/checks テストフレームワーク

2.3 エンジニアリングプラクティスのハイライト

Cargo.toml トップレベルの lints:

[workspace.lints.clippy]
arithmetic_side_effects = "deny"  # 全ての可能性のある整数オーバーフロー/アンダーフローを拒否
cast_possible_truncation = "deny" # 切り捨ての可能性がある型変換を拒否
unwrap_used = "deny"              # .unwrap(panic)を禁止

→ これは 金融グレード Rust コーディング規範。Circle が Arc を本番クリティカルインフラとして扱っており、PoC おもちゃではないことを意味する。

ツールチェーン:
- Rust 1.91+
- Rust 2024 edition
- Foundry + Hardhat デュアル Solidity ツール
- Protocol Buffers (buf)
- TypeScript + Node.js (Hardhat 用)
- Yarn


3. 5 つの Precompiles の詳細

3.1 NATIVE_COIN_AUTHORITY (0x1800...0000)

ソースファイル:crates/precompiles/src/native_coin_authority.rs

機能:
- mint(to, amount) — ネイティブ通貨を発行(USDC のオンチェーン表現)
- burn(from, amount) — 焼却
- transfer(from, to, amount) — 転送
- totalSupply — 総供給量

Gas コスト(ソースコメントより):
- Mint: 15,581 gas(pre-Zero5 hardfork)
- 各操作は内部で SSTORE/SLOAD 2100/2900 gas 価格を使用

呼び出し元制限:ALLOWED_CALLER_ADDRESS = NATIVE_FIAT_TOKEN_ADDRESS
→ Native Fiat Token コントラクト(USDC on Arc)のみがこの precompile の mint/burn を呼び出せる

イベント:
- NativeCoinMinted(to, amount) — 2 topics, 32 bytes data
- NativeCoinBurned(from, amount) — 2 topics
- NativeCoinTransferred(from, to, amount) — 3 topics

ストレージ:ERC-7201 storage slots を使用、ハードコーディングされた storage keys(1, 2 等)

設計の意味:USDC は通常の ERC-20 ではなく、precompile と深く結合した「ネイティブ通貨」(native coin)。これが他のすべての EVM チェーン(Plasma、Tempo を含む)との根本的差異——他のチェーンのステーブルコインは通常のコントラクト token、Arc 上の USDC はプロトコルレベルの一級市民。

3.2 NATIVE_COIN_CONTROL (0x1800...0001)

ソースファイル:crates/precompiles/src/native_coin_control.rs

機能:
- チェーンレベル denylisted[address] マッピングを維持
- addToBlocklist(address)
- removeFromBlocklist(address)
- isBlocklisted(address)

エラーメッセージ定数:BLOCKLISTED_ERROR_MESSAGE = "address is blocklisted"

設計の意味:合規レベルのオンチェーン OFAC/AML ブラックリスト。deny されたアドレスは USDC mint を受け取れず、NATIVE_COIN_AUTHORITY の transfer 経由でも受け取れない。

3.3 SYSTEM_ACCOUNTING (0x1800...0002)

ソースファイル:crates/precompiles/src/system_accounting.rs

機能:
- Gas 手数料の ring buffer 累積
- 手数料収集→ARC 変換のオンチェーン会計用

ストレージ:カスタム GAS_VALUES_STORAGE_KEY

設計の意味:これは USDC→ARC 経済モデルのオンチェーン会計開始点。手数料はまずここで集約され、その後何らかのメカニズムで ARC に変換され分配される。

3.4 CALL_FROM (0x1800...0003)

ソースファイル:crates/precompiles/src/call_from.rs + contracts/src/call-from/ICallFrom.sol

機能:
- ネイティブ batch トランザクションサポート
- Memo フィールド付加
- 配套コントラクト Multicall3From.sol(Multicall3 標準互換)

設計の意味:チェーンネイティブのバッチ実行(multicall コントラクトをデプロイする必要なし)、gas と UX を最適化。これは Agent Stack / Nanopayments の基礎。

3.5 PQ (0x1800...0004)

ソースファイル:crates/precompiles/src/pq.rs + contracts/src/pq/IPQ.sol

完全インターフェイス:

interface IPQ {
    function verifySlhDsaSha2128s(bytes calldata vk, bytes calldata msg, bytes calldata sig)
        external returns (bool isValid);
}

Rust 実装の重要部分:

use slh_dsa::{signature::Verifier, Sha2_128s, Signature, VerifyingKey as SlhDsaVerifyingKey};

pub const PQ_ADDRESS: Address = address!("1800000000000000000000000000000000000004");

const VERIFY_BASE_GAS: u64 = 230_000;          // ベース 230k gas
const GAS_PER_MSG_WORD: u64 = KECCAK256WORD;   // 32 bytes 毎の追加 gas

// SLH-DSA-SHA2-128s hashes the message once via H_msg (SHA-256 + MGF1).
// This is comparable to KECCAK256, so we use the same per-word rate.

依存:slh_dsa Rust crate(RustCrypto プロジェクトメンテナンス)

署名仕様:FIPS 205 標準の SLH-DSA-SHA2-128s
- VerifyingKey: 32 bytes
- Signature: 7,856 bytes(gas が高い理由——署名が超大きい)

コメント内の重要な警告:

“Post-quantum signature schemes and their underlying libraries are relatively new. Algorithm parameters, gas costs, and the precompile interface may change in future hardforks as the ecosystem matures.”

設計の意味:Arc メインネット起動後、ユーザーはオプションで PQ 署名を使用してアカウントレベルの耐量子保護を行える。230k gas は一度きりの高コスト(約 $0.046 @ 200 gwei 相当の USDC)、Q-day リスクヘッジと交換。


4. ProtocolConfig コントラクト(手数料 + コンセンサスパラメータガバナンス)

ソースファイル:contracts/src/protocol-config/ProtocolConfig.sol

4.1 FeeParams 構造

struct FeeParams {
    uint256 alpha;                       // ≤ 100  (base fee 平滑化係数)
    uint256 kRate;                       // ≤ 10000 (base fee 調整速度)
    uint256 minBaseFee;
    uint256 maxBaseFee;
    uint256 blockGasLimit;
    uint256 inverseElasticityMultiplier; // ≤ 10000
}

→ EIP-1559 との差異:
- EIP-1559:完全弾性、base fee は target gas usage で自動調整
- Arc:min/max 境界 + 平滑化係数あり、機関に「予測可能な手数料上限」を保証
- これは「dollar-denominated budgets」コミットメントを支える具体的技術メカニズム

4.2 ConsensusParams 構造(コメントから推測)

struct ConsensusParams {
    uint256 timeoutProposeMs;
    uint256 timeoutProposeDeltaMs;
    uint256 timeoutPrevoteMs;
    uint256 timeoutPrevoteDeltaMs;
    uint256 timeoutPrecommitMs;
    uint256 timeoutPrecommitDeltaMs;
    uint256 timeoutRebroadcastMs;
}

→ Tendermint 三段階投票タイムアウトのミリ秒精度ガバナンスパラメータ。Controller 役割はネットワーク条件の変化に対応するために調整可能。

4.3 ガバナンス権限


5. Validator Manager コントラクト

ソースファイル:contracts/src/validator-manager/PermissionedValidatorManager.sol

5.1 三層アーキテクチャ

Owner (Circle 法人)
   ↓
Controllers (制限された「validator 承認」役割)
   ↓
ValidatorRegisterers (制限された「validator 登録」役割)
   ↓
Validators (ノード運営者)

5.2 重要な関数

function registerValidator(bytes memory publicKey)
    external onlyValidatorRegisterer whenNotPaused
    returns (uint256);
// デフォルト votingPower = 0

function activateValidator external onlyController whenNotPaused;
// 既登録の validator を有効化

function removeValidator external onlyController whenNotPaused;

function updateValidatorVotingPower(uint64 newVotingPower)
    external onlyController whenNotPaused;
// votingPowerLimit に制限される

各 controller は votingPowerLimitOf[msg.sender] を持つ —— 単一の controller は validator に無制限の投票権を与えられない。

5.3 ストレージ

mapping(address => uint256) registrationOf;        // controller → validator registration ID
mapping(address => uint64) votingPowerLimitOf;     // controller → max voting power

設計の意味:これは PoA 段階の完全なオンチェーン validator ガバナンス。各 controller は特定の validator のみを管理(オープン参入ではない)、PermissionedValidatorManager の命名と一致。

5.4 Pausable

Pausable を継承 —— 緊急時には validator manager 全体を一時停止可能。これは機関合規チェーンの標準能力だが、暗号ネイティブユーザーは「中央集権的失敗モード」と見なす。


6. Denylist コントラクト

ソースファイル:contracts/src/Denylist.sol

contract Denylist is Initializable, Ownable2StepUpgradeable {
    mapping(address => bool) denylisted;
    mapping(address => bool) denylisters;

    error CannotDenylistOwner;   // 重要:owner 自身は denylist できない

    modifier onlyDenylister {
        if (!$.denylisters[msg.sender]) revert CallerIsNotDenylister;
        _;
    }
}

アップグレードメカニズム:Ownable2StepUpgradeable —— OpenZeppelin 標準の 2 段階所有権譲渡 + アップグレード可能プロキシ。

設計の意味:denylist 役割は owner と分離、合規チーム / 規制対応担当者に割り当て可能。2 段階所有権譲渡で誤って制御権を失うことを防ぐ。


7. ノード実行モード(crates/node/README.md より)

7.1 Validator モード

arc-node-consensus start \
   --home=~/.arc/consensus \
   --moniker=validator-1 \
   --validator \
   --suggested-fee-recipient=0x... \
   --eth-socket=/tmp/reth.ipc \
   --execution-socket=/tmp/auth.ipc

arc-node-execution node \
   --chain=assets/localdev/genesis.json \
   --http --http.port=8545 \
   --ipcpath=/tmp/reth.ipc \
   --full

7.2 Full Node(非 validator)

validator に類似だが --validator フラグなし。

7.3 Unsafe RPC Node(軽量、コンセンサスに参加せず)

arc-node-execution download   # スナップショットダウンロード
arc-node-execution node \
   --unsafe-follow \
   --http \
   --minimal

コンセンサス層を実行する必要はなく、信頼ノードに従って同期。純粋な API 提供者に適する。

7.4 RPC Node with consensus verification

完全に execution + consensus を実行するが、consensus は --follow モードに設定。


8. Remote Signer(circlefin/arc-remote-signer

機関 validator 向けハードウェアレベル署名サービス:
- AWS Nitro Enclaves(独立した信頼実行環境)ベース
- 秘密鍵は Nitro Enclave から離れない
- Validator はリモート署名 API を呼び出してコンセンサス署名を完了
- これが BlackRock、Visa、Goldman 等の機関が validator になる意欲のある重要なインフラ


9. Malachite コンセンサスエンジン構造(circlefin/malachite

9.1 crate 分割

Core アルゴリズム
- core-consensus — Tendermint コア
- core-driver — ステートマシンドライバ
- core-state-machine — ステートマシン
- core-types — コアタイプ
- core-votekeeper — 投票管理

Engine(アプリケーション層接続)
- app-channel — channel ベース API
- app — アプリケーションフレームワーク
- codec — エンコーディング
- config — 設定
- discovery — ノード発見
- engine — エンジン
- metrics — メトリクス
- 等

9.2 形式検証

specs/ ディレクトリには:
- 英文 specification
- Quint specification(Apalache ツールチェーンで検証可能な形式仕様)

→ これは Tendermint 実装の最高品質基準で、CometBFT Go 版を上回る。

9.3 ネームスペース

# Cargo workspace 内のすべての crate の実際の発行名にはプレフィックス
arc-malachitebft-core-consensus
arc-malachitebft-core-driver
...

→ Circle が Malachite を “arc-malachitebft-*” として再ブランディング —— これは Arc 専用版であることを示唆、上流 Malachite との Arc-specific patches が存在する可能性。


10. Sample Apps が示す dApp パターン

10.1 arc-nanopayments —— Agent Stack コア

gas なしの USDC マイクロペイメント(< $0.01)。paymaster または事前支払い gas を利用する可能性。Agent 経済の重要インフラ。

10.2 arc-defi-lending-and-borrowing

cirBTC(Circle wrap した BTC?)を担保に USDC を借りる。Arc が wrapped BTC + Aave/Compound スタイルの貸借をサポートすることを意味。

10.3 arc-prediction-markets (UMA プロトコル)

Arc は UMA Protocol と統合されており、OO(Optimistic Oracle) が Arc で利用可能であることを意味、これは予測市場と保険コントラクトの基礎。

10.4 arc-escrow (AI-validated)

「AI 検証の納品物 → 資金リリースまたは返金」ワークフロー。これは Agent Stack のフリーランス/サービス市場における応用。

10.5 arc-fintech

マルチチェーントレジャリー管理(multi-chain treasury)、CCTP/Gateway 経由で cross-chain 統合。機関トレジャリーの主要ユースケース。


11. コードレベルのセキュリティ/監査状況

複数の README からの明示的警告:

“Arc is currently in testnet, and this is alpha software currently undergoing audits.”

“Malachite is alpha software and under heavy development. The software is provided ‘as is’ and has not been externally audited; use at your own risk.”

具体的な監査会社は未公開(2026-05-13 時点)。


12. Reth / Paradigm との関係

観察:Reth は新世代金融 L1 の事実上の標準となり、Geth/Erigon を超えた。


13. コード評価(研究員主観)

次元 評点 (1-10) 備考
エンジニアリング品質 9 Rust 2024 edition + 厳格な lints + 形式検証
ドキュメント完全度 8 ARCHITECTURE.md + 各 crate README
モジュラリティ 9 25 crates の明確な分割
セキュリティ意識 8 deny unwrap、deny arithmetic overflow、OZ 2-step
合規設備 10 Denylist + Permissioned Validator + KYB
耐量子 8 Day-1 SLH-DSA、ロードマップ Dilithium/Falcon
オープンソース透明度 9 Apache-2.0、完全な CI/test
監査状態 4 “undergoing audits” だが具体的監査者未公開
総合点 8.1/10 エンジニアリングレベル L1 インフラ、メインネット実戦検証が必要

14. 研究員の観察

  1. Arc は「VC 思いつき」プロジェクトではない:コードからツールチェーン、コントラクト設計まで、Circle 自身と Informal Systems チームの長年の経験を体現する。
  2. PermissionedValidatorManager は「合規チェーン」の誠実な公開:Circle は「decentralization theater」で PoA 段階の中央集権を隠蔽せず、権限階層をコントラクトに直接書いている。
  3. NATIVE_COIN_AUTHORITY が USDC をプロトコルレベルの一級市民に昇格:これが Arc を真に他と差別化する設計 —— 他のチェーン上の USDC はコントラクト、Arc 上の USDC は precompile。USDC コントラクトに将来バグが発生してもチェーンレイヤーがユーザーを保護できることを意味する。
  4. PQ precompile 230k gas は合理的な備え:高 gas だが実際の使用頻度は低く、支払う意思のある機関ユーザーに q-day 保険を提供。
  5. 欠落しているがあるべきもの:Slashing コントラクト(PoS 移行前)、Staking コントラクト、Cross-chain bridge contracts(別のリポジトリにあるはず)、StableFX オンチェーンコントラクト(別のリポジトリにあるはず)。

関連ドキュメント
- 身分曖昧性解消:IDENTITY-RESOLUTION.md
- メインレポート:overview.md
- Circle 会社全景:circle-context.md
- ニュースタイムライン:news-multilingual.md
- 候補プロジェクト:alternatives.md
- 全 URL ソース:sources.md