---
title: "暗号資産における Nonce の名前空間"
description: "Ethereum のアカウント Nonce、アプリケーション層のリプレイ防止 Nonce、ERC-4337 のキーとシーケンスのレーン、PoW ブロックヘッダーの探索 Nonce を解説します。"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 暗号資産における Nonce の名前空間
> 教育目的の情報であり、取引や署名に関する助言ではありません。Nonce という語は互いに無関係な複数のフィールドを指します。割り当て、置換、再利用の前に、対象のチェーン、アカウント、コントラクト、ドメイン、EntryPoint またはブロックヘッダーの仕様と canonical state を確認してください。
## 端的な答え
Nonce は、特定のプロトコル名前空間によって意味が決まる値です。必ずしも乱数でも、汎用的な「一度だけ使う値」でもありません。Ethereum では、外部所有アカウントの state nonce が、その送信者のトランザクションを順序付けて検証します。コントラクトは permit や署名済みインテントのために、別のアプリケーション Nonce をストレージで管理できます。ERC-4337 のスマートアカウントは、キーとシーケンスを並列レーンに分けた構造化 `UserOperation` Nonce を使用できます。Bitcoin のプルーフ・オブ・ワークでは、ブロックヘッダー Nonce は候補ハッシュを試すための有限な探索フィールドです。
これらの値に互換性はありません。アプリケーションが独自のドメインとリプレイ防止フィールドを検証しなければ、Ethereum のアカウント Nonce は任意の型付きデータ署名を保護しません。PoW ヘッダー Nonce はアカウントのトランザクションを順序付けません。送信者、コントラクト、チェーン、レーンが異なれば、同じ数値の Nonce も異なる状態を表します。
## 仕組み
1. 数値を読む前に、EOA トランザクション、コントラクトアカウントの状態、アプリケーションストレージ、ERC-4337 `UserOperation`、特定の PoW ブロックヘッダーのどの名前空間かを特定します。必要に応じて、チェーン ID、フォークとプロトコルのバージョン、アカウントまたは所有者、検証コントラクトとドメイン、EntryPoint、ヘッダー形式を固定します。
2. 明示したブロックタグで正規の状態を読みます。canonical な EOA アカウント Nonce、プロバイダーの pending count、アプリケーションの `nonces(owner)` ストレージ値、ERC-4337 のキーとシーケンス、マイナーのローカルなヘッダー探索カウンターを区別します。複数の RPC が一致しても、canonical receipt と state の検証には代わりません。
3. 署名の履歴を構築します。送信者または所有者、チェーンとドメイン、Nonce、ペイロード、期限、検証コントラクト、トランザクションまたはメッセージのハッシュ、すべての置換を記録します。Ethereum トランザクションでは、EIP-155 などのチェーンドメイン規則がアカウント Nonce を補完します。Nonce だけでは完全なクロスチェーン・リプレイ防止になりません。
4. 正しいレーンで割り当てます。同時に動く EOA 署名者を調整し、canonical な各シーケンスを一度だけ割り当て、ギャップと同一 Nonce の置換履歴を保持します。アプリケーションやスマートアカウントでは、単一のグローバルカウンターを仮定せず、そのコントラクトの原子的な検査・増分とレーン規則に従います。
5. 正しい受入規則の下で送信します。実行クライアントの pending と置換の方針はローカルです。ERC-4337 bundler は EntryPoint とアカウント規則に基づき `UserOperation` オブジェクトを検証します。EIP-712 または permit 署名は他者のトランザクション内でリレーされることがあります。いずれのローカル受入経路も canonical inclusion を証明しません。
6. 結果を最後まで追跡します。拒否、pending、queued、置換済み、正常に取り込まれた状態、`status = 0` で取り込まれた状態、reorg による除外、finalized を区別します。Ethereum トランザクションが取り込まれると、EVM 実行が revert しても送信者のアカウント Nonce は進みます。一方、revert した呼び出し内で更新されたアプリケーションストレージの Nonce はロールバックします。
7. 再試行前に照合します。canonical receipt、ブロックハッシュ、送信者 Nonce、アプリケーションストレージ、ERC-4337 のイベントまたは receipt、finality を確認します。PoW では Nonce だけでなく、ヘッダー全体とターゲットを検証します。有限な Nonce フィールドを使い切ると、マイナーはヘッダーに影響する別のデータを変更して新しい探索空間を作ります。
## 計算例
- **revert しても EOA Nonce は消費される。** canonical な送信者 Nonce は `12` です。Nonce `12` のトランザクションが `status = 0` で取り込まれ、`50,000` gas を `30 gwei` で使用すると、コストは `50,000 * 30 gwei = 0.0015 ETH` です。コントラクトの変更は revert しますが、canonical な送信者 Nonce は `13` になります。reorg でそのブロックが除外されると Nonce は `12` に戻る可能性があり、ウォレットはトランザクション履歴全体を再確認する必要があります。
- **アプリケーション Nonce とリレイヤー Nonce は別物。** 所有者の EOA アカウント Nonce は `18`、ERC-2612 トークンの値は `nonces(owner) = 7`、リレイヤーの EOA Nonce は `42` です。permit が成功するとアプリケーション Nonce `7` を消費して `8` になり、取り込みによりリレイヤー Nonce は `43` になりますが、所有者の EOA Nonce は `18` のままです。呼び出し全体が revert した場合もリレイヤー Nonce は `43` になりますが、トークンのストレージ更新は `7` に戻ります。
- **ERC-4337 のレーン。** 説明用のパック式 `nonce = (key << 64) | sequence` では、キー `5`、シーケンス `9` から `5 * 2^64 + 9 = 92,233,720,368,547,758,089` を得ます。シーケンス `10` なら `92,233,720,368,547,758,090` です。独立したキー `6`、シーケンス `0` は `110,680,464,442,257,309,696` です。並列利用の可否はスマートアカウントの検証ロジック次第であり、bundler の EOA トランザクション Nonce とも別です。
- **PoW の探索 Nonce。** Bitcoin のヘッダー Nonce は `32 bits` なので、数値候補は `2^32 = 4,294,967,296` 個です。仮に `100 TH/s` なら、この数値空間の走査時間は `4,294,967,296 / 100,000,000,000,000 = 0.00004294967296 seconds = 42.94967296 microseconds` です。マイナーは coinbase extraNonce、時刻、トランザクション集合を変えて Merkle root を変更し、新しいヘッダーを得ます。このフィールドはアカウントのリプレイ防止状態ではありません。
## リスク
- EOA、コントラクト、アプリケーション、ERC-4337、PoW の Nonce 名前空間を混同する。
- 誤ったチェーン、フォーク、コントラクト、EntryPoint から Nonce を読む。
- 古い、不整合な、または悪意ある RPC 応答を使う。
- 複数の署名者が同じ EOA トランザクション Nonce を割り当てる。
- Nonce のギャップにより後続のローカルトランザクション候補が止まる。
- プロバイダーの pending Nonce を canonical state とみなす。
- 取り込まれて revert したトランザクションも EOA Nonce と gas を消費することを忘れる。
- reorg 後に Nonce と候補トランザクションの履歴を復元しない。
- 同一 Nonce の置換が対象ノードの手数料ポリシーを満たさない。
- 置換により古い署名済みトランザクションが全世界から削除されたと考える。
- 異なる送信者やドメインの同じ数値の Nonce を関連付ける。
- チェーン ID など必要な署名ドメイン区切りを省略する。
- アプリケーション Nonce の検査と増分を原子的に行わない。
- ERC-2612 の所有者、期限、domain separator、トークンコントラクトを誤る。
- アプリケーション署名がチェーン、コントラクト、バージョンをまたいでリプレイされる。
- コントラクトアカウントの state nonce を汎用の呼出回数と誤解する。
- ERC-4337 Nonce のキーまたはシーケンスのビット幅を誤ってパックする。
- bundler の EOA Nonce とスマートアカウントの `UserOperation` Nonce を混同する。
- プロキシのアップグレードやストレージ衝突によりアプリケーション Nonce の挙動が変わる。
- 有限な PoW 探索 Nonce 自体を認可、リプレイ状態、または証明とみなす。
## よくある誤解
- Nonce と呼ばれるフィールドはすべて同じ意味で、世界全体で一度だけ使われる。
- Nonce が大きいほど、トランザクションは安全、高速、または final に近い。
- revert した Ethereum トランザクションは送信者 Nonce を消費しない。
- Nonce だけですべてのクロスチェーン、クロスコントラクト、型付きメッセージのリプレイを防げる。
- ERC-4337 スマートアカウントはすべて、EOA トランザクション Nonce と同じ単一の線形カウンターを持つ。
## 関連トピック
- [アカウントベースモデル](/ja/crypto/account-based-model/)
- [Mempool でのトランザクション置換](/ja/crypto/mempool-replacement/)
- [アカウント抽象化](/ja/crypto/account-abstraction/)
## 出典
- [Ethereum accounts](https://ethereum.org/developers/docs/accounts/) - Ethereum.org（参照日：2026-08-13）
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org（参照日：2026-08-13）
- [EIP-2681: Limit account nonce to 2^64-1](https://eips.ethereum.org/EIPS/eip-2681) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [ERC-4337: Account Abstraction Using Alt Mempool](https://eips.ethereum.org/EIPS/eip-4337) - Ethereum Improvement Proposals（参照日：2026-08-13）
- [Block Chain](https://developer.bitcoin.org/reference/block_chain.html) - Bitcoin Developer Documentation（参照日：2026-08-13）
Source: https://wiki.fcontext.com/ja/crypto/nonce-crypto/index.mdx