ナンス（Nonce）

ナンスとは？

ナンスとは、特定の暗号技術、ブロックチェーン、またはスマートコントラクトの文脈で一度だけ使用することを想定した、一意の値です。

暗号資産の分野では、「number used once（一度だけ使用する数値）」の略として一般に理解されています。

ナンスは、単純なトランザクションカウンター、マイニング用フィールド、ランダム値、署名の入力値、スマートコントラクトの認可ID、またはアクションの重複を防ぐシーケンス番号など、さまざまなものを指します。

ナンスの正確な意味は、どこで使われているかによって異なります。

Ethereumアカウントでは、ナンスはトランザクションの順序を管理し、同じ署名済みトランザクションが複数回実行されるのを防ぎます。

Bitcoinのブロックヘッダーでは、ナンスはマイナーが有効なProof of Workハッシュを探す際に変更するフィールドです。

トークンのPermitでは、同じ署名済み承認が再利用されるのをナンスによって防ぎます。

ECDSA署名では、ナンスは署名ごとに使われる秘密の値となる場合があり、ナンスの生成方法が不適切だと秘密鍵が漏えいする可能性があります。

同じ言葉が複数の暗号資産システムで使われるため、どの種類のナンスについて話しているのかを必ず確認してください。

共通する最も重要な考え方は、一意性です。

ナンスを使うと、アクション、ハッシュ計算、メッセージ、トランザクション、署名をそれぞれ異なるものにできます。

この一意性は、リプレイ攻撃の防止、順序管理、マイニング、暗号化の安全性、コントラクトのセキュリティ、ウォレットの使いやすさ、秘密鍵の保護を支えます。

ナンスに関する重要なポイント

• • ナンスとは、定められたコンテキスト内で一度だけ使うことを想定した値です。
  • Ethereumアカウントでは、ナンスを使ってトランザクションの順序を管理し、リプレイを防ぎます。
  • Bitcoinのマイナーは、Proof of Workの目標を満たすハッシュを探すため、ブロックヘッダーのナンスを変更します。
  • スマートコントラクトでは、署名済みのPermit、投票、請求、メタトランザクションの再利用を防ぐためにナンスがよく使われます。
  • ERC-2612 Permitでは、所有者のナンスを使い、同じトークン承認署名が繰り返し使われるのを防ぎます。
  • ERC-4337のスマートアカウントでは、アカウント抽象化のワークフローに対応する、より柔軟なナンスモデルが使われます。
  • EIP-155はチェーンIDによるリプレイ保護を追加し、トランザクションナンスと組み合わせて機能します。
  • EIP-712の構造化メッセージでも、型付きデータだけであらゆるリプレイ攻撃を自動的に防げるわけではないため、アプリケーションレベルでナンスの確認が必要です。
  • ECDSA署名のナンスは秘密に保ち、一意にする必要があります。再利用や予測可能なパターンによって秘密鍵が漏えいする可能性があるためです。
  • 保留中のトランザクションや置き換えの仕組みを理解していない場合、ユーザーはウォレットのナンスを手動で変更しないでください。

暗号資産でナンスが重要な理由

ブロックチェーンは署名、ハッシュ、決定論的なルールに依存しているため、ナンスは重要です。

有効なデジタル署名は、それを見た人なら誰でも完全にコピーできます。

トランザクションは多くのノードによって再ブロードキャストされる可能性があります。

スマートコントラクトがメッセージの使用済みかどうかを確認しなければ、同じ署名済みメッセージを再び受け入れる可能性があります。

マイナーは有効なブロックを探すため、さまざまなハッシュ入力を試します。

ウォレットは同じアドレスから複数のトランザクションを作成できるため、有効な順序を保つ必要があります。

ナンスは、こうしたシステムで混乱、重複、リプレイ、安全でない再利用を防ぐのに役立ちます。

ナンスがなければ、暗号資産システムは新しいアクションとコピーされた古いアクションを区別するのが難しくなります。

ユーザーがトークンの使用者を一度承認しただけなのに、同じ署名が再利用されてしまう可能性があります。

ブリッジが同じクロスチェーンメッセージを2回処理する可能性があります。

トランザクションが別のチェーンでリプレイされる可能性があります。

署名ウォレットが脆弱な暗号学的ナンスによって秘密鍵を漏えいする可能性があります。

ナンスは小さな値ですが、非常に大きなデジタル資産を保護します。

Ethereumアカウントのナンス

Ethereumアカウントのナンスは、アカウントに紐づくカウンターです。

Ethereumのアカウントに関するドキュメントでは、アカウントにナンスフィールドがあり、各アカウントでは特定のナンスを持つトランザクションを1つだけ実行できると説明されています。

外部所有アカウント（EOA）の場合、ナンスはそのアカウントから送信されたトランザクション数を数えます。

コントラクトアカウントの場合、ナンスはそのコントラクトアカウントが作成したコントラクトに関連します。

あるアドレスから25件のトランザクションが正常に送信されている場合、次の通常のトランザクションにはナンス25を使います。

そのトランザクションが実行された後、次のトランザクションにはナンス26を使います。

この単純なカウンターにより、同じトランザクションが2回実行されるのを防ぎます。

また、同じアドレスからのトランザクションに順序を付けます。

通常、ナンス27のトランザクションは、ナンス26のトランザクションが処理される前に処理できません。

そのため、1件のトランザクションが詰まると、同じウォレットからの後続のトランザクションがブロックされることがあります。

Ethereumトランザクションのナンス

Ethereumトランザクションのナンスは、ウォレットが署名するトランザクションデータの一部です。

Ethereumのトランザクションに関するドキュメントでは、ナンスをアカウントからのトランザクション番号を示す、順次増加するカウンターと説明しています。

トランザクションナンスは、一意のトランザクションハッシュの生成に役立ちます。

また、送信者のトランザクション順序のどこにそのトランザクションが位置するかをネットワークに示します。

同じアカウントからの保留中の2件のトランザクションが同じナンスを使う場合、同じ枠をめぐって競合します。

実行できるのはそのうち1件だけです。

Ethereumトランザクションのスピードアップやキャンセルは、基本的にこの仕組みを利用します。

ユーザーは同じナンスを使い、より高い手数料を設定した置き換えトランザクションを送信できます。

置き換えトランザクションがネットワークに受け入れられ、先に取り込まれると、そのナンスが使用され、先のトランザクションは実行されません。

この仕組みは便利ですが、保留中のキューを理解せずにナンスを手動で編集すると混乱する場合があります。

Bitcoinマイニングのナンス

Bitcoinマイニングのナンスは、Ethereumアカウントのナンスとは異なります。

Bitcoinのブロックチェーンのリファレンスでは、ブロックヘッダーのナンスを、マイナーがブロックヘッダーのハッシュを変えるために変更する32ビットの任意の数値と説明しています。

マイナーはナンスやその他の調整可能なフィールドを変更しながら、ブロックヘッダーのデータを繰り返しハッシュ化します。

目標は、現在のターゲット閾値以下のハッシュを見つけることです。

マイナーがすべての32ビットのナンス値を試しても有効なブロックを見つけられない場合、時刻を更新するか、コインベーストランザクションを変更できます。これによりMerkleルートが変わります。

こうすることで、マイナーはさらに多くのハッシュ入力を試せます。

マイニングナンスは、ユーザートランザクションの順序を管理しません。

ウォレットのリプレイ攻撃を防ぐものでもありません。

これはProof of Workにおける探索変数です。

同じ「ナンス」という言葉でも、チェーンや文脈によって意味が大きく異なるのはこのためです。

Proof of Workにおけるナンス

Proof of Workのマイニングでは、ナンスによってマイナーがさまざまなハッシュ計算を行えます。

暗号学的ハッシュ関数は、入力がわずかに変わるだけでも大きく異なる出力を生成します。

ナンスを変更すると、ブロックヘッダーの入力が変わります。

入力が変われば、ハッシュも変わります。

マイナーは、ネットワークの難易度ターゲットを満たすハッシュが見つかるまで、異なるナンス値を試し続けます。

この文脈でナンスは秘密ではありません。

ブロックが見つかると、誰でもナンスを確認し、ハッシュを検証できます。

セキュリティはナンスを隠すことではなく、有効なハッシュを見つけるために必要な膨大な作業によって成り立っています。

これは通常秘密にしておく必要がある署名ナンスとは異なります。

マイニングナンスは、公開されたProof of Workの探索ツールです。

リプレイ保護におけるナンス

リプレイ保護は、暗号資産におけるナンスの最も重要な用途の一つです。

リプレイ攻撃とは、有効な署名済みアクションを誰かがコピーし、再度送信することです。

ナンスによって各署名済みアクションを一度限りにすることで、これを防ぎます。

アクションが実行されると、ナンスは消費、増加、または使用済みとして記録されます。

同じ署名済みアクションを再送しようとしても、ナンスの確認に失敗します。

これは、トランザクション、トークン承認、スマートコントラクトでの請求、ガバナンス投票、ブリッジメッセージ、ウォレットログイン、メタトランザクションで重要です。

有効な署名は、鍵の所有者が何かを承認したことを証明します。

有効なナンスは、その承認が同じコンテキストですでに使われていないことを示します。

暗号資産の認可を安全に行うには、両方の確認が必要です。

リプレイ保護により、コピーされた署名が深刻な脅威になるのではなく、重複として拒否されます。

ナンスとEIP-155のチェーンID

EIP-155は、署名済みEthereumトランザクションデータにチェーンIDを含めることで、リプレイ保護をさらに強化します。

EIP-155の仕様では、この変更により、あるチェーンで有効なトランザクションが、異なるチェーンIDを使う別のチェーンでは機能しないようにできると説明しています。

多くのEVM互換チェーンでは、似たアドレス形式やトランザクション構造が使われるため、これは重要です。

トランザクションナンスは、同じチェーン上で同じアカウントのトランザクションが2回実行されるのを防ぎます。

チェーンIDは、同じ署名済みトランザクションが別のチェーンでリプレイされるのを防ぐのに役立ちます。

どちらの仕組みも重要です。

あるチェーン上で一意のトランザクションでも、別のチェーン上で有効なら危険な場合があります。

チェーンを認識する署名は、そのリスクを軽減します。

チェーンが重要な場合、アプリケーションレベルの署名にもチェーンのコンテキストを含める必要があります。

適切なドメインが設定されていないナンスは、異なるコンテキストに持ち出されやすい場合があります。

EIP-712の型付きデータにおけるナンス

EIP-712は、型付き構造化データに署名するための標準です。

EIP-712の仕様では、この標準自体にはリプレイ保護が含まれていないとされています。

つまり、開発者は署名を検証するアプリケーションやスマートコントラクトに、リプレイ保護を追加する必要があります。

型付きメッセージにはナンスを含めることができます。

コントラクトはそのナンスを確認する必要があります。

さらに、正常に実行された後にナンスを使用済みとして記録するか、増加させなければなりません。

コントラクトが署名を検証しても、ナンスの状態更新を忘れると、同じ署名が再利用される可能性があります。

EIP-712は可読性とドメイン分離を改善しますが、慎重なナンス設計の代わりにはなりません。

安全な型付きデータ署名には、ナンス、期限、チェーンID、検証コントラクト、承認対象の正確なアクションを含める必要があります。

ユーザーは、型付き署名を無害なログイン画面ではなく、実際の権限付与として扱ってください。

ERC-2612 Permitにおけるナンス

ERC-2612 Permitを使うと、トークン所有者はオンチェーンで直接承認トランザクションを行う代わりに、署名済みメッセージで支出を承認できます。

ERC-2612標準にはnonces関数が含まれており、ナンスのマッピングはリプレイ保護のために設けられていると説明されています。

Permitが成功すると、所有者のナンスが増加します。

これにより、同じPermit署名を後で再利用できなくなります。

ERC-2612には期限も含まれており、署名済み承認を失効させることができます。

リレイヤーがPermitを受け取った後、いつ送信するかを選べる場合があるため、これは重要です。

期限がなければ、ユーザーの想定より長く古い署名が有効なままになる可能性があります。

ナンスがなければ、同じ承認署名を繰り返し送信できる可能性があります。

Permitのナンスは、ガスレス承認をより安全で実用的にする重要な要素です。

また、通常のアカウントトランザクションナンスに加えて、スマートコントラクト独自のナンスシステムが必要な理由も示しています。

ERC-4337のアカウント抽象化におけるナンス

ERC-4337のアカウント抽象化では、外部所有アカウントからの通常のEthereumトランザクションではなく、UserOperationを使用します。

ERC-4337の仕様では、UserOperationのナンスをリプレイ防止パラメーターと定義しています。

また、クロスチェーンまたは複数のEntryPointをまたぐリプレイを防ぐため、署名はチェーンIDとEntryPointアドレスに依存する必要があるとしています。

ERC-4337は、部分的に抽象化されたナンスモデルに対応しています。

ナンスはキーとシーケンスに分割できます。

これにより、スマートアカウントで複数のナンスレーンを使用できます。

ウォレットは、通常のトランザクション用レーンと、管理やリカバリー用アクションのレーンを分けられます。

これは、単一の単純なシーケンシャルカウンターより柔軟です。

その一方で、ウォレットの開発者やユーザーにとっては複雑になります。

アカウント抽象化によってナンス設計の自由度は高まりますが、ウォレットのインターフェースをより分かりやすくする必要もあります。

ナンスレーン

ナンスレーンとは、アカウントやスマートアカウントの設計における、独立したナンスのシーケンスです。

ナンスレーンを使うと、異なる種類のアクションを並行して進められます。

たとえば、ウォレットで日常的な支出用のレーンと、リカバリー操作用のレーンを分けることができます。

ゲーム用ウォレットでは、頻繁な少額取引用のレーンと、高額資産の送金用レーンを使い分けられます。

サブスクリプション用ウォレットでは、定期支払い用のレーンと、ユーザーが管理するトランザクション用のレーンを分けられます。

この仕組みの利点は、1つの詰まったアクションが他のすべてのアクションをブロックしないことです。

一方で、ユーザーがどのレーンに対して承認しているのか理解できない可能性があります。

開発者は、各レーンで強固なリプレイ保護が維持されるようにしなければなりません。

ウォレットは、ユーザーが知る必要がある場合に限り、ナンスレーンを説明するのが望ましいでしょう。

優れた設計は、分かりにくい技術的詳細をユーザーに見せずに柔軟性を提供します。

シーケンシャルナンス

シーケンシャルナンスとは、有効なアクションごとに1ずつ増えるカウンターです。

通常のアカウントトランザクションで最も一般的なモデルです。

シーケンシャルナンスは明確な順序を作るため、監査しやすい仕組みです。

また、同じアカウントから同じナンスを使う2件のトランザクションが両方とも実行されるのを防ぎます。

欠点は、先行する保留中のトランザクションによって後続のトランザクションがブロックされる可能性があることです。

その結果、トランザクションが詰まることがあります。

後続のトランザクションを進めるには、先行するトランザクションをスピードアップまたはキャンセルする必要がある場合があります。

シーケンシャルナンスは信頼性が高く、単純で、広く使われています。

多くの独立したアクションを同時に実行する必要があるシステムには、柔軟性が低い面があります。

そのため、スマートコントラクトアカウントや認可システムでは、別のナンスパターンが使われることがあります。

ランダムナンス

ランダムナンスとは、単純なカウンターではなく、ランダム性から生成される一意の値です。

厳密な順序付けが必要ないアクションでは、ランダムナンスが役立ちます。

スマートコントラクトは、使用済みのランダムナンスをマッピングとして保存できます。

署名済みの認可が使われると、コントラクトはそのランダムナンスを消費済みとして記録します。

同じ認可が再び使われた場合、コントラクトは拒否します。

ランダムナンスを使うと、互いにブロックし合うことなく、複数の署名済みアクションを同時に存在させられます。

欠点は、ストレージとランダム性の品質です。

コントラクトは、多数の使用済みナンスを保存する必要がある場合があります。

ウォレットやアプリケーションは、同じコンテキストで同じランダムナンスを2回生成しないようにする必要があります。

ランダムナンスは柔軟ですが、慎重な管理が必要です。

スマートコントラクトのナンス

スマートコントラクトのナンスとは、スマートコントラクトが定義し、保存するナンスシステム全般を指します。

ユーザーごとのカウンターの場合があります。

使用済みメッセージIDのマッピングの場合もあります。

エアドロップの請求インデックスの場合もあります。

ガバナンスにおける提案への投票状態の場合もあります。

マーケットプレイスの注文ハッシュの場合もあります。

ブリッジメッセージのシーケンス番号の場合もあります。

通常のアカウントナンスだけでは、すべてのオフチェーン署名やコントラクトレベルのアクションを保護できないため、スマートコントラクトのナンスが必要です。

コントラクトが署名を受け入れる場合、その署名がすでに使われているかどうかを判断しなければなりません。

適切に設計されたスマートコントラクトのナンスは、ユーザー体験を損なわずに繰り返し実行を防ぎます。

ウォレットログインメッセージのナンス

オンチェーントランザクションが発生しない場合でも、ウォレットのログインメッセージではナンスがよく使われます。

ウェブサイトは、ユーザーがウォレットアドレスを管理していることを証明するため、メッセージへの署名を求める場合があります。

ウェブサイトは、そのログイン試行ごとに新しいチャレンジナンスを生成する必要があります。

署名するメッセージには、ドメイン、ナンス、発行時刻、有効期限、目的を含める必要があります。

ログインが成功したら、サーバーはそのナンスを使用済みとして記録してください。

攻撃者が古いログイン署名を盗んだ場合でも、使用済みナンスによってリプレイを防ぐことができます。

新しいナンスがなければ、ログイン署名が再利用可能なパスワードのように機能する可能性があります。

ユーザーはメッセージ署名をトランザクションほど深刻なものと考えないことが多いため、これは危険です。

ウォレットログインのナンスはアカウントセキュリティの一部です。

適切なログイン署名は、用途が明確で、新しく、範囲が限定され、読みやすい必要があります。

ECDSA署名のナンス

ECDSA署名では、メッセージごとに使う秘密の値を使用し、これをナンスまたは署名ナンスと呼ぶことがあります。

この種のナンスは、アカウントトランザクションナンスとは異なります。

署名ごとに秘密に保ち、一意にする必要があります。

RFC 6979は、署名ごとに新たなランダム値を生成することに依存しない、DSAおよびECDSA署名生成の決定論的手法を定めています。

NISTのFIPS 186-5 Digital Signature Standardでは、ECDSAが署名生成時にメッセージごとの秘密の数値を使用するとされています。

ECDSAのナンスが再利用されたり、予測可能だったりすると、攻撃者が秘密鍵を復元できる可能性があります。

本番環境のブロックチェーン活動におけるECDSAナンス衝突のリスクに関する最近の研究は、不適切なナンス生成が深刻な事態につながり得ることを示しています。

これは、暗号資産のセキュリティにおけるナンスの意味の中でも、特に重大なものです。

アカウントナンスに問題があると、トランザクションが失敗したり、詰まったりする可能性があります。

ECDSA署名ナンスに問題があると、ウォレット全体が危険にさらされる可能性があります。

暗号化におけるナンス

一部の暗号化システムでもナンスが使われます。

認証付き暗号化では、同じ鍵を複数のメッセージに使う場合でも、ナンスによって暗号化結果を一意にできます。

RFC 5116は、関連データ付き認証暗号化のインターフェースを定義し、ナンスを使うAEADアルゴリズムについて説明しています。

暗号資産ウォレット、暗号化バックアップ、安全なメッセージングシステム、カストディソフトウェアでは、内部的に暗号化ナンスを使う場合があります。

こうした暗号化ナンスは、ブロックチェーントランザクションのナンスとは異なります。

暗号化されたメッセージを保護するためのものです。

多くの暗号化方式では、同じ鍵でナンスを再利用すると危険な場合があります。

通常、ユーザーがこうしたナンスを手動で管理することはありません。

開発者やウォレットライブラリが正しく処理する必要があります。

安全な暗号資産ソフトウェアでは、ナンスの生成をセキュリティ上重要な要素として扱います。

ナンスとソルトの違い

ナンスとソルトは関連する概念ですが、同じものではありません。

ナンスは通常、プロトコルや署名のコンテキストで一度だけ使う、一意の値を指します。

ソルトは通常、ハッシュ、パスワード処理、コミットメント、アドレス計算などに加えるランダムまたは一意のデータで、出力を区別するために使います。

暗号資産の分野では、コントラクトの決定論的なデプロイやコミットメントの導出にソルトを使う場合があります。

トランザクションの順序管理やリプレイ防止には、ナンスを使う場合があります。

どちらの値も一意性をもたらします。

違いは、セキュリティ上の役割です。

ソルトは事前計算を防いだり、導出される値に一意性を持たせたりすることが多くあります。

ナンスは、再利用を防いだり、プロトコルアクションの新しさを担保したりすることが多くあります。

セキュリティ上のミスを避けるため、開発者はこれらの値に明確な名前を付け、用途を文書化する必要があります。

ナンスとトランザクションハッシュの違い

ナンスはトランザクションハッシュと同じではありません。

ナンスは、トランザクションまたはプロトコルメッセージに含まれる入力値です。

トランザクションハッシュは、署名済みトランザクションデータをハッシュ化して生成される識別子です。

ナンスを変更すると、署名済みトランザクションが変わるため、トランザクションハッシュも変わります。

トランザクションがマイニングされる前でも、ウォレットはナンスを使用できます。

ブロックチェーンエクスプローラーには通常、トランザクションがブロードキャストされた後、または取り込まれた後にトランザクションハッシュが表示されます。

ナンスは、送信者のシーケンス内でのトランザクションの位置をネットワークに示します。

トランザクションハッシュは、ユーザーがトランザクション記録を検索・検証するために役立ちます。

どちらも重要ですが、役割は異なります。

両者を混同すると、トランザクションのトラブルシューティングが難しくなる場合があります。

ナンスとガスの違い

ナンスはガスではありません。

ガスは、計算作業とトランザクション実行コストを測るものです。

ナンスは、トランザクションの順序や一意性を示します。

トランザクションのナンスが正しくても、ガスが不足していたり、手数料が低すぎたりすることがあります。

逆に、ガスが十分でもナンスが間違っている場合があります。

これらの問題は、それぞれ異なる失敗につながります。

ガスの問題は、実行失敗や取り込み優先度の低下を引き起こす可能性があります。

ナンスの問題は、トランザクションが拒否、置き換え、遅延される原因になったり、先行する保留中トランザクションによってブロックされたりする可能性があります。

高度なウォレットツールでは、両方の設定が表示されることがあります。

どちらの設定も安易に変更しないでください。

ナンスとコントラクトアドレスの生成

ナンスはコントラクトアドレスにも影響する場合があります。

Ethereum形式のシステムでは、従来のcreate操作で作成されたコントラクトのアドレスは、作成者のアドレスとナンスから導出されます。

つまり、同じアカウントでも、ナンスが変わると異なるコントラクトアドレスを作成できます。

開発者は、コントラクトのデプロイ、デプロイのテスト、アドレスの予測を行う際に、この点を理解しておく必要があります。

想定されるナンスと実際のアカウントナンスが異なると、コントラクトのデプロイスクリプトが失敗する可能性があります。

保留中のトランザクションによって、デプロイの順序が変わる場合があります。

ナンスを手動で誤って設定すると、想定外のアドレスにコントラクトがデプロイされる可能性があります。

決定論的なデプロイ方法では別の仕組みを使う場合がありますが、通常のデプロイではナンス管理が重要です。

重要なデプロイでは、チームは管理されたデプロイスクリプトを使い、アドレスを公表する前に確認する必要があります。

デプロイ先アドレスが誤っていると、ユーザーが混乱し、連携機能が使えなくなる可能性があります。

ナンスと詰まったトランザクション

手数料の低いトランザクションが保留状態のまま残ると、トランザクションが詰まることがあります。

そのトランザクションがアカウントの次のナンスを使っている場合、後続のトランザクションはその後ろで待機する可能性があります。

シーケンシャルナンスでは、先行するナンスの枠を先に処理する必要があるためです。

手数料が高い後続のトランザクションも、ウォレット上では保留中と表示される場合があります。

実際の問題は、ナンスの低い古いトランザクションにある可能性があります。

多くの場合、同じナンスでより高い手数料を設定した置き換えトランザクションを送信すれば、詰まったトランザクションをスピードアップできます。

同じナンスで手数料の高い、実質的に何も行わない置き換えトランザクションを送信すれば、詰まったトランザクションをキャンセルできる場合があります。

こうした操作は慎重に行う必要があります。

誤ったナンスを置き換えると、まだ実行したいアクションをキャンセルまたは上書きする可能性があります。

ナンスのトラブルシューティングは、初心者にとって高度なウォレット設定が危険になり得る理由の一つです。

ナンスとトランザクションの置き換え

トランザクションの置き換えでは、同じナンスを使って保留中のトランザクションを置き換えます。

置き換えトランザクションは、元のトランザクションと同じナンス枠をめぐって競合します。

置き換えトランザクションが受け入れられ、先に承認されると、ナンスがすでに使用されているため、元のトランザクションは無効になります。

遅いトランザクションの手数料を引き上げたい場合に便利です。

承認前の保留中トランザクションをキャンセルしたい場合にも役立ちます。

置き換えによって、承認済みのトランザクションがブロックチェーンから削除されるわけではありません。

置き換えができるのは、先行するトランザクションがまだ保留中の場合だけです。

トランザクションが承認されると、ナンスは消費されます。

その後は、同じナンスを別のトランザクションに再利用できません。

保留中のトランザクションを管理する際にタイミングが重要なのはこのためです。

ナンスとブリッジ

ブリッジでは、同じクロスチェーンメッセージが2回処理されるのを防ぐため、ナンスやメッセージIDを使います。

ブリッジメッセージは、トークンの入金、出金、ミント、バーン、コントラクト呼び出しなどを表す場合があります。

宛先チェーンが同じメッセージを複数回受け入れると、資産が誤ってリリースまたはミントされる可能性があります。

安全なブリッジメッセージには、送信元チェーン、宛先チェーン、送信元コントラクト、宛先コントラクト、送信者、受取人、金額、一意のナンスまたはメッセージIDを含める必要があります。

宛先コントラクトは、メッセージを処理済みとして記録する必要があります。

同じメッセージが再送された場合、コントラクトは拒否する必要があります。

ブリッジは異なるコンセンサスシステムを接続するため、ナンス設計が特に重要です。

ブリッジでリプレイが発生すると、複数のチェーンにまたがるシステミックリスクが生じる可能性があります。

ブリッジのセキュリティは、トークン自体のセキュリティとは別に考えてください。

トークン自体に問題がなくても、ブリッジメッセージの仕組みが安全とは限りません。

ナンスとガバナンス

ガバナンスシステムでは、投票、委任、提案の実行が繰り返されるのを防ぐため、ナンスに類する状態管理を使います。

投票は通常、投票権のスナップショットごと、または明確に定められた投票ルールに従って1回だけ集計される必要があります。

署名済みの委任は、設計上明確に許可されていない限り、永久に再利用できる状態にすべきではありません。

コントラクトが意図的に複数回の実行に対応していない限り、提案の実行は1回に制限する必要があります。

ガバナンスメッセージには、提案ID、投票者ナンス、チェーンID、期限、実行状態の確認が必要な場合があります。

ガバナンスがトレジャリー、アップグレード、手数料、リスクパラメーター、ブリッジ接続を管理する場合、これは特に重要です。

ガバナンスアクションのリプレイは、支払いの失敗よりも大きな危険をもたらす可能性があります。

プロトコル全体のルールを変えてしまう可能性があるためです。

適切なガバナンスコントラクトでは、リプレイ保護を中核的な安全機能として扱います。

投票者も、承認する前に署名対象のアクションを確認してください。

ナンスとエアドロップの請求

エアドロップや報酬システムでは、請求の繰り返しを防ぐためにナンスに類する保護機能が使われることがあります。

コントラクトが、あるアドレスがすでに請求したかどうかを保存する場合があります。

Merkleの請求インデックスがすでに使われているかを保存する場合もあります。

ナンス、キャンペーンID、トークン数量、期限、受取人アドレスを含む署名済み請求メッセージを使うこともあります。

こうした保護がなければ、有効な請求が報酬を使い切るまで繰り返し使われる可能性があります。

適切な請求システムでは、請求を正しいユーザー、キャンペーン、チェーン、トークン、金額、期間に紐づけます。

ユーザーは、見慣れないサイトからの請求メッセージに署名する際は注意してください。

請求署名が、誤解を招く内容によって単なる報酬請求以上の権限を与える場合があります。

ナンス保護は繰り返し利用を防ぎますが、悪意のある最初の利用を安全にするものではありません。

ウォレット上での分かりやすい表示も重要です。

ナンスとDeFi

DeFiでは、さまざまな場面でナンスが使われています。

トークンのPermitでは、署名済み承認にナンスを使います。

メタトランザクションでは、ガスレスのアクションにナンスを使います。

レンディングプロトコルでは、署名済みの委任や与信承認にナンスを使う場合があります。

分散型注文システムでは、約定済みの注文が再度約定されないよう、ナンスや注文ハッシュを使う場合があります。

オプション、ボルト、ストラクチャード商品では、オフチェーンの見積もりや決済メッセージにナンスを使う場合があります。

清算ボットや取引システムも、アカウントナンスを慎重に管理する必要があります。トランザクションが詰まると、時間的制約のあるアクションがブロックされる可能性があるためです。

DeFiでは、ナンスのミスがすぐに金銭的損失につながることがあります。

古い承認署名がウォレット資産を抜き取るリスクになる場合があります。

ナンスの更新漏れによって、コントラクトがリプレイ可能になることがあります。

トランザクションナンスを間違えると、利益が見込まれる取引が失敗する可能性があります。

ナンスとNFT

NFTシステムでも、マーケットプレイスの出品、入札、Permit、請求、署名による移転などにナンスが使われます。

売り手がNFTを売却するオフチェーン注文に署名する場合があります。

マーケットプレイスのコントラクトは、同じ署名済み注文が許容回数を超えて約定しないようにする必要があります。

注文ナンス、注文ハッシュ、キャンセルカウンター、約定状態のマッピングなどを使って防止できます。

NFT注文が売却後やキャンセル後もリプレイできる場合、売り手が意図せず資産を失う可能性があります。

条件変更後も入札署名がリプレイできると、入札者が意図しないNFTを購入する可能性があります。

NFTの署名には、コレクションアドレス、トークンID、価格、通貨、買い手または売り手の条件、有効期限、チェーンID、ナンスを含める必要があります。

ユーザーは、内容が曖昧なNFT出品メッセージに署名しないでください。

必要に応じて、古い出品もキャンセルしてください。

ナンスの安全性は、マーケットプレイスの安全性の一部です。

ナンスと秘密鍵の安全性

署名アルゴリズムでは、ナンスの品質が秘密鍵の安全性に直接影響する場合があります。

特にECDSAベースのシステムで重要です。

異なるメッセージの署名に同じECDSA署名ナンスを使うと、秘密鍵を復元される可能性があります。

署名ナンスが予測可能なパターンに従う場合も、特定の条件下で攻撃者に鍵を復元される可能性があります。

そのため、ウォレット開発者はレビュー済みの暗号ライブラリを利用します。

暗号技術の専門家によるレビューを受けていない限り、ユーザーは高額資産を管理するための独自の署名ソフトウェアを作成しないでください。

トランザクションナンスの誤りは、目に見えて修正できる場合があります。

署名ナンスの誤りは、気付かれないまま秘密鍵を漏えいする可能性があります。

ハードウェアウォレットや成熟したソフトウェアライブラリは、このリスクの低減に役立ちます。

暗号学的ナンスの生成に近道を使うべきではありません。

暗号資産で使われる主なナンスの種類

• • アカウントナンスは、ブロックチェーンアカウントからのトランザクションの順序を管理します。
  • トランザクションナンスは、トランザクションを一意にするために署名済みトランザクションデータに含まれます。
  • マイニングナンスは、Proof of Workのマイナーが有効なブロックハッシュを探すために調整します。
  • Permitナンスは、署名済みトークン承認が複数回使われるのを防ぎます。
  • スマートコントラクトナンスは、コントラクトレベルの認可が繰り返し実行されるのを防ぎます。
  • ブリッジメッセージナンスは、同じクロスチェーンメッセージが2回処理されるのを防ぎます。
  • ログインナンスは、新しいウォレット認証チャレンジを生成します。
  • 署名ナンスは、一部のデジタル署名アルゴリズムで使われる、メッセージごとの秘密の値です。
  • 暗号化ナンスは、同じ鍵を使う暗号化メッセージをそれぞれ異なるものにするのに役立ちます。
  • ナンスレーンは、一部のスマートアカウント設計で使われる独立したナンスシーケンスです。

ナンスに関するよくある間違い

よくある間違いの一つは、すべてのナンスが同じ意味だと考えることです。

もう一つは、保留中のトランザクションを確認せずに、トランザクションナンスを手動で編集することです。

3つ目は、ナンスが含まれていない型付きデータに署名することです。

4つ目は、スマートコントラクトの署名を検証しても、ナンスを使用済みとして記録し忘れることです。

5つ目は、チェーンIDや検証コントラクトのドメイン分離なしでナンスを使うことです。

6つ目は、EIP-712が自動的にリプレイを防ぐと考えることです。

7つ目は、ランダムナンスに脆弱な乱数を使うことです。

8つ目は、ECDSA署名ナンスを再利用したり、漏えいさせたりすることです。

9つ目は、ナンスによってフィッシングも防げると思い込むことです。

10個目は、コントラクトのアップグレード時にナンスの状態を移行し忘れることです。

開発者向けのベストプラクティス

コードを書く前に、ナンスの目的を定義してください。

厳密な順序が必要な場合は、シーケンシャルナンスを使ってください。

独立した認可を並行して実行する必要がある場合は、ランダムナンスやマッピング形式のナンスを使ってください。

コンテキストが重要な署名済みデータには、チェーンIDと検証コントラクトアドレスを含めてください。

オフチェーン署名には、期限または有効期間を設定してください。

実行に成功した際にナンスを使用済みとして記録してください。

ユニットテストと統合テストでリプレイを試してください。

署名や暗号化のナンスには、レビュー済みの暗号ライブラリを使用してください。

十分にレビューされた標準に基づいていない限り、独自のECDSAナンス生成を避けてください。

ウォレット、インデクサー、監査担当者、ユーザーが理解できるよう、ナンスの動作を明確に文書化してください。

ユーザー向けのベストプラクティス

保留中のトランザクションの順序を理解していない限り、通常のトランザクションナンスはウォレットに管理させてください。

同じウォレットから新しいトランザクションを何件も送る前に、トランザクションが詰まっていないか確認してください。

トランザクションを置き換える際は、スピードアップやキャンセル機能を慎重に使ってください。

トークンのPermitメッセージを読んでから署名してください。

署名を承認する前に、使用者、金額、チェーン、期限、アプリケーションを確認してください。

不審なドメインからのウォレットログインメッセージに署名しないでください。

すぐに資金が移動しないという理由だけで、メッセージ署名が安全だと思い込まないでください。

信頼できるウォレットソフトウェアを使い、見知らぬ署名ツールは避けてください。

高額資産を保有する場合は、ハードウェアウォレットとリカバリー方法を安全に管理してください。

ナンス保護は繰り返し利用を防げても、不適切な署名を無害にすることはできません。

ナンスが特に重要となる場面

署名によって資産を移動したり重要な状態を変更したりできる場合、ナンスは特に重要です。

通常のブロックチェーントランザクションを送信する際に重要です。

Permitでトークンの支出を承認する際に重要です。

マーケットプレイスの注文に署名する際に重要です。

ブリッジメッセージを送信する際に重要です。

投票やガバナンス委任に署名する際に重要です。

エアドロップや報酬を請求する際に重要です。

ウォレット署名でログインする際に重要です。

ECDSA署名を生成する際に重要です。

再利用、リプレイ、予測可能性が金銭的損失につながる可能性がある場面では、いずれも重要です。

ナンスを一言で説明すると

ナンスとは、トランザクションの順序管理、Proof of Workのマイニング、リプレイ保護、安全な署名、暗号化の安全性、安定したウォレット動作を支えるため、ブロックチェーン、暗号技術、スマートコントラクトの文脈で一度だけ使う一意の値です。

よくある質問

暗号資産におけるナンスとは何ですか？

ナンスとは、トランザクションカウンター、マイニング用フィールド、署名済みメッセージID、暗号学的署名値など、特定の暗号資産の文脈で一度だけ使う一意の値です。

Ethereumのナンスとは何ですか？

Ethereumのナンスとは、アカウントからのトランザクションの順序を管理し、同じトランザクションナンスを持つトランザクションが2回実行されるのを防ぐカウンターです。

Bitcoinのナンスとは何ですか？

Bitcoinのナンスとは、ネットワークのターゲットを満たすProof of Workハッシュを探すためにマイナーが変更する、ブロックヘッダー内のフィールドです。

ウォレットでナンスが使われるのはなぜですか？

ウォレットでは、有効なトランザクションの順序を作り、リプレイを防ぎ、保留中のトランザクションを置き換え、次に実行すべきトランザクションを管理するためにナンスを使います。

ナンスを手動で変更できますか？

一部のウォレットではナンスを手動で編集できますが、保留中のトランザクションと置き換えルールを理解している場合に限って行ってください。

2件のトランザクションが同じナンスを使うとどうなりますか？

同じ送信者とナンスを持つトランザクションのうち、実行できるのは1件だけです。そのため、同じ枠をめぐって競合します。

ナンスが原因でトランザクションが詰まるのはなぜですか？

ナンスの低い先行トランザクションが保留中のままだと、後続のトランザクションがブロックされることがあります。

ナンスはどのようにリプレイ攻撃を防ぎますか？

ナンスによって署名済みアクションを一度限りにし、ナンスが消費された後に同じナンスが使われた場合、システムが拒否できるようにします。

EIP-712はナンスを自動的に処理しますか？

いいえ。EIP-712は型付きデータを構造化しますが、開発者はコントラクトやアプリケーションにナンスを含め、検証する必要があります。

Permitナンスとは何ですか？

Permitナンスとは、同じ署名済みトークン承認が複数回送信されるのを防ぐために使われる、トークン所有者のナンスです。

署名ナンスとは何ですか？

署名ナンスとは、一部の署名アルゴリズムで使われるメッセージごとの秘密の値です。適切に扱わないと秘密鍵が漏えいする可能性があります。

ナンスは常に秘密ですか？

いいえ。アカウントナンスやマイニングナンスは通常公開されますが、暗号学的署名ナンスの中には秘密に保つ必要があるものもあります。

まとめ

ナンスは、暗号資産においていくつもの重要な意味を持つ短い言葉です。

その核心にあるのは、一意性です。

この一意性により、暗号資産システムはトランザクション、メッセージ、署名、ハッシュ計算、コントラクトアクションを区別できます。

Ethereumでは、アカウントナンスがトランザクションの順序を管理し、同じトランザクションが2回実行されるのを防ぎます。

Bitcoinのマイニングでは、ブロックヘッダーのナンスを変更しながら、マイナーが有効なProof of Workハッシュを探します。

スマートコントラクトでは、ナンスがPermit、請求、投票、注文、ブリッジメッセージのリプレイを防ぎます。

アカウント抽象化では、より柔軟なナンスモデルにより、スマートウォレットで並列ワークフローや高度な認可ロジックを利用できます。

ECDSA署名では、ナンスの品質によって秘密鍵の安全性が保たれるか、攻撃者に復元されるかが左右される場合があります。

これらの意味は同じ原則で結びついていますが、仕組みは同じではありません。

マイニングナンスは公開され、繰り返し試されます。

アカウントナンスは公開され、順次増加します。

コントラクトナンスは、保存されたカウンターや使用済みメッセージのマッピングの場合があります。

Permitナンスは、署名済み承認を保護します。

署名ナンスは秘密にし、安全に生成する必要があります。

ナンスという言葉が使われているときは、文脈が重要です。

ユーザーにとって実用上最も重要なのは、手動操作が本当に必要な場合を除き、通常のトランザクションの順序管理をウォレットに任せることです。

詰まったトランザクション、スピードアップ、キャンセルの試行、ナンスの手動設定には注意してください。

また、オフチェーンメッセージにもナンスが含まれ、有害なアクションを許可する可能性があるため、署名要求をよく確認してください。

開発者にとって最も重要なのは、リプレイ保護を明示的に設計することです。

資産を移動したり重要な状態を変更したりできる署名には、ナンス、ドメイン、必要に応じた期限、アクションの明確な詳細を含める必要があります。

コントラクトはナンスを確認し、正しく消費しなければなりません。

ウォレットは、ユーザーが何を承認しているのかを分かりやすい言葉で表示する必要があります。

暗号コードでは、レビュー済みのライブラリと安全なナンス生成方法を使用してください。

開発中は小さなミスに見えても、デプロイ後には深刻な問題になる場合があります。

ナンス確認が欠けていると、請求や承認が繰り返し行われる可能性があります。

アカウントナンスを間違えると、トランザクションがブロックされる場合があります。

脆弱なECDSAナンスは、秘密鍵を漏えいさせる可能性があります。

チェーンIDがないと、クロスチェーンリプレイが可能になる場合があります。

ナンスの適切な追跡がないブリッジメッセージは、2回処理される可能性があります。

したがって、ナンスの安全性は、任意に付け加える技術的な装飾ではありません。

暗号資産の移動、コントラクトの実行、マイナーの探索、ウォレットの署名を可能にし、1つの承認が意図した1つのアクションだけを意味するという信頼を支える基盤の一部です。