Nonce Replay Protection（ノンスによるリプレイ攻撃防止）

Nonce Replay Protectionとは？

Nonce Replay Protectionとは、有効な暗号資産トランザクション、メッセージ、Permit、承認、スマートコントラクトの操作が複数回再利用されるのを防ぐセキュリティ手法です。

Nonce（ノンス）は、特定のコンテキストで一度だけ使うことを意図した数値または一意の値です。

リプレイ攻撃防止とは、署名済みの操作が一度使われた後に、同じ操作が再送信されてもネットワーク、ウォレット、コントラクト、アプリケーションが拒否する仕組みです。

デジタル署名は完全にコピーできるため、暗号資産分野ではNonce Replay Protectionが不可欠です。

ユーザーがトランザクションやメッセージに署名した後、システムが使用済みかどうかを追跡しなければ、攻撃者が同じ署名を再送信し、同じ操作を繰り返せる可能性があります。

繰り返された操作により、資金の再送、トークン利用承認の再実行、スマートコントラクト呼び出しの再実行、投票の再実行、報酬の再請求、承認の再発動などが起こる可能性があります。

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

同じドキュメントによると、この仕組みは署名済みトランザクションが繰り返しブロードキャストされ、再実行されるリプレイ攻撃を防ぎます。

Nonce Replay Protectionは、ブロックチェーン上の署名を実際の価値の移転に利用するための基本的な安全対策の一つです。

Nonce Replay Protectionの主なポイント

• • Nonce Replay Protectionは、同じ署名済みの暗号資産操作が複数回受理されるのを防ぎます。
  • Nonceには、連番、乱数、ドメイン固有、アカウント固有、コントラクト固有、レーン別などの方式があります。
  • Ethereumの外部所有アカウントは、トランザクションの繰り返し実行を防ぐため、連番方式のNonceを使用します。
  • EIP-155は署名済みトランザクションデータにChain IDを加え、チェーン間のリプレイリスクを低減します。
  • EIP-712の型付きデータ署名にもアプリケーションレベルのリプレイ防止が必要です。コントラクトが再実行を拒否しなければ、型付き署名も複数回送信される可能性があります。
  • ERC-2612のPermitは、所有者Nonceと期限を使い、トークン承認署名が無期限に再利用されるのを防ぎます。
  • ERC-3009は32バイトのランダムNonceと承認状態を利用し、署名済み送金の再実行を防ぎます。
  • ERC-4337のスマートアカウントは、アカウント抽象化や並列ワークフローに対応する、より柔軟なNonce設計を採用します。
  • リプレイ防止では、署名を正しいチェーン、コントラクト、関数、ユーザー、期限、意図された操作に結びつける必要があります。
  • Nonce設計が不十分だと、二重支払い、承認の再実行、トランザクションの停滞、署名窃取による被害、メタトランザクションの失敗、クロスチェーンのリプレイ攻撃につながる可能性があります。

暗号資産でリプレイ攻撃が問題となる理由

リプレイ攻撃とは、有効な署名済み操作を取得し、その操作が引き続き受理される場所で再送信する攻撃です。

暗号資産の署名は、紙の手書き署名とは異なり、正確にコピーして再送信できます。

署名済みトランザクションが一度有効になった際、プロトコルが使用済みと記録しなければ、同じトランザクションが再び有効になる可能性があります。

ブロックチェーンでは、有効な署名が承認として扱われることが多いため危険です。

リプレイされた送金によって、資金が再び移動する可能性があります。

リプレイされた承認によって、支出権限が再び付与される可能性があります。

リプレイされた請求によって、報酬プールの資金が流出する可能性があります。

コントラクトが投票状態を追跡していないと、リプレイされたガバナンス投票が判断を歪める可能性があります。

リプレイされたブリッジメッセージによって、資産が誤ってミントまたは解放される可能性があります。

Nonce Replay Protectionは、再利用可能な署名を一度限りの承認にします。

Nonceがリプレイを防ぐ仕組み

Nonceは、署名済み操作をそれぞれ一意にし、追跡可能にすることでリプレイを防ぎます。

ユーザーが操作に署名する際、Nonceは署名対象データに含まれます。

操作を実行する際、プロトコルはNonceが有効で、まだ使用されていないことを確認します。

確認に成功すると操作が実行され、Nonceは消費、増加、または使用済みとして記録されます。

同じ署名済み操作を再送信すると、Nonceの確認に失敗します。

署名自体は数学的に有効なままでも、Nonceがすでに使用されているため、システムが拒否します。

この違いは重要です。

署名の有効性は、ユーザーがメッセージを承認したことを証明します。

Nonceの未使用状態は、その承認がまだ消費されていないことを示します。

安全なシステムには両方が必要です。

連番Nonce

連番Nonceは、承認された操作のたびに増加するカウンターです。

Ethereumの外部所有アカウントは、通常のトランザクションでこの方式を使用します。

アカウントのNonceが10なら、次の有効なトランザクションには通常Nonce 10が必要です。

トランザクションが取り込まれた後、次の有効なトランザクションにはNonce 11が必要です。

これにより、同じアカウントNonceを持つ異なるトランザクションが両方実行されるのを防ぎます。

後のNonceは通常、前のNonceが埋まるまで処理できないため、実行順序も定まります。

通常のアカウントトランザクションでは、連番Nonceはシンプルで効果的です。

メタトランザクション、一括処理、複数デバイス、自動化セッション、アカウント抽象化システムでは不便になる場合があります。

そのため、新しい設計の一部では、ランダムNonce、Nonceレーン、アプリケーション固有のNonceマッピングを採用しています。

ランダムNonce

ランダムNonceは、カウントアップではなく乱数によって生成する一意の値です。

厳密なトランザクション順序を必要としない署名済み承認やメタトランザクションシステムで、ランダムNonceがよく使われます。

ERC-3009は、承認者のアドレスに固有の、ランダムに生成された32バイトのNonceを使用します。

ERC-3009標準は、承認Nonceが使用済みかキャンセル済みかを記録する承認状態関数とイベントを定義しています。

この方式では、複数の独立した署名済み承認を同時に保持できます。

保留中の連番Nonceが後続の承認をブロックする問題を回避できます。

その代わり、同じ承認が繰り返されないよう、コントラクトが使用済みランダムNonceを保存または確認する必要があります。

ランダムNonceには、質の高い乱数が必要です。

Nonceが予測可能だったり、誤って再利用されたりすると、リプレイ防止が弱まる可能性があります。

アカウントNonce

アカウントNonceは、同じアカウントからのトランザクションを保護します。

外部所有アカウントでは、Nonceが各トランザクションの一意性を保ち、実行順序を管理します。

ユーザーが同じアカウントNonceで2件のトランザクションを送信した場合、通常のルールでは一方だけが取り込まれます。

ネットワークや手数料の状況に応じて、もう一方は拒否されたり、置き換えられたり、無効なまま残ったりする場合があります。

そのため、ウォレットは次に使うアカウントNonceを慎重に管理します。

ウォレットが低すぎるNonceを使うと、そのトランザクションはすでに使用済みで、失敗する可能性があります。

ウォレットが高すぎるNonceを使うと、先行するNonceが確認されるまでトランザクションが待機する可能性があります。

ユーザーがより高い手数料の置き換えトランザクションを同じNonceでブロードキャストすると、ノードのポリシーによっては、置き換え側が先の保留中トランザクションに取って代わります。

アカウントNonceはリプレイ攻撃を防ぎますが、実際のトランザクション管理上の問題も生みます。

ユーザーには、トランザクションの停滞、保留キュー、置き換えトランザクション、キャンセル操作として現れます。

Chain IDによるリプレイ防止

Chain IDによるリプレイ防止は、あるチェーン向けに署名されたトランザクションが、類似したトランザクション形式を使う別のチェーンで有効になるのを防ぎます。

チェーン分岐やEVM互換ネットワークの増加に伴い、この仕組みの重要性が高まりました。

EIP-155は、署名対象となるEthereumトランザクションデータにChain IDを追加しました。

これにより、あるチェーンでは有効でも、Chain IDの異なる別のチェーンでは無効なトランザクションにできます。

この仕組みがなければ、アカウント、Nonce、トランザクション形式が一致する場合、あるチェーンでブロードキャストされたトランザクションがコピーされ、別のチェーンで送信される可能性があります。

Chain IDによるリプレイ防止は、アカウントNonceによるリプレイ防止とは異なります。

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

Chain IDは、同じ署名済みトランザクションが別のチェーンで使われるのを防ぎます。

強固なリプレイ防止には通常、両方が必要です。

ドメイン分離

ドメイン分離とは、署名を特定の署名コンテキストに結びつけることです。

コンテキストには、Chain ID、コントラクトアドレス、プロトコル名、バージョン、関数の種類、ユーザーアドレス、Nonce、期限などを含められます。

EIP-712は、型付き構造化データへの署名を定義し、name、version、chainId、verifyingContractなどのドメインフィールドを含みます。

ドメイン分離は、あるアプリケーション向けの署名が別のアプリケーションで受理されるのを防ぐのに役立ちます。

たとえば、ユーザーは特定のチェーン上にある一つのコントラクト向けにメッセージへ署名する意図があります。

署名にチェーンと検証コントラクトが含まれていなければ、別のコントラクトやチェーンが有効な署名として解釈する可能性があります。

同じ署名が異なるコンテキストに持ち込まれるため、これはリプレイリスクとなります。

Nonceは一つのコンテキスト内での再利用を防ぎます。

ドメイン分離は、誤ったコンテキストでの利用を防ぎます。

安全なオフチェーン署名には両方が必要です。

EIP-712メッセージにおけるNonce Replay Protection

EIP-712はウォレットやユーザーがメッセージを理解しやすくしますが、すべての署名済みメッセージを自動的に一度限りにするものではありません。

EIP-712のセキュリティに関する項目では、同じ署名済みメッセージを2回受け取った場合に、アプリケーションが適切に処理する必要があると警告しています。

つまり、コントラクトまたはアプリケーションは、署名済みメッセージの再送を拒否するか、繰り返し実行されても影響がないようにしなければなりません。

型付きメッセージにNonceを含めることはできますが、受信側のコントラクトがそのNonceを確認し、消費する必要があります。

型付きメッセージに期限を含めることもできますが、その期限はオンチェーンで適用する必要があります。

型付きメッセージに検証コントラクトを含めることもできますが、コントラクトはドメインセパレーターを正しく検証しなければなりません。

型付きデータは明確さを高めますが、それだけでリプレイを防ぐものではありません。

リプレイ防止は、設計全体によって実現されます。

安全なEIP-712フローでは、ドメイン分離、Nonce追跡、署名検証、操作の明確な紐付け、期限の確認を組み合わせます。

いずれかを省くと、リプレイリスクが生じる可能性があります。

ERC-2612 PermitにおけるNonce Replay Protection

ERC-2612 Permitでは、トークン所有者がオンチェーンで承認トランザクションを直接送信する代わりに、署名済みメッセージでトークンの利用を承認できます。

所有者に代わって別の当事者が署名済みPermitを送信できるため、ユーザー体験が向上します。

ERC-2612標準はnonces関数を要求し、Permitが成功した場合、所有者のNonceを増加させる必要があると定めています。

また、同標準はリプレイ防止のためにnoncesマッピングを設けるとしています。

これにより、同じPermit署名を繰り返し使用できなくなります。

ERC-2612には期限パラメーターも含まれます。

期限によって、署名済みPermitが有効である期間を制限します。

Permitを受け取ったリレイヤーは、期限切れまでの間、送信時期を選べるため、この仕組みは重要です。

期限を短くすれば、古い署名が後から利用されるリスクを抑えられます。

Nonceや期限の処理が不適切なPermitは、重大なトークン承認リスクを招く可能性があります。

ERC-3009におけるNonce Replay Protection

ERC-3009は、トークン向けの署名済み送金承認方式です。

トークン保有者は、まず支出者を承認するのではなく、特定の送金に対する承認に署名します。

その後、コントラクトは署名、有効期間、Nonceを確認してから処理を実行します。

ERC-3009はauthorizationStateマッピングを使い、Nonceが使用済みかどうかを追跡します。

送金承認が成功すると、Nonceは使用済みとして記録されます。

これにより、同じ署名済み送金が再び実行されるのを防ぎます。

一部の実装では、ERC-3009は承認のキャンセルにも対応します。

validAfterフィールドとvalidBeforeフィールドを使って、承認の有効期間を定めます。

この設計は、ガス代をユーザーが直接支払わない送金や、リレー経由のトークン送金に役立ちます。

また、リプレイ防止が単なるカウンター以上のものであることも示しています。

安全な承認には、一意のNonce、有効期間、明確な受取人、正確な金額、正しいドメインが必要です。

ERC-4337スマートアカウントにおけるNonce Replay Protection

ERC-4337は、UserOperationとスマートコントラクトアカウントを通じてアカウント抽象化を実現します。

ERC-4337標準は、UserOperationのNonceをリプレイ防止パラメーターとして定義しています。

また、チェーン間や複数のEntryPoint間でのリプレイを防ぐため、署名がChain IDとEntryPointアドレスに依存することを要求します。

ERC-4337は、半抽象化されたNonceモデルを採用しています。

Nonceはキーと連番の組み合わせとして扱うことができます。

これにより、スマートアカウントは複数のNonceレーンに対応できます。

たとえば、ウォレットは通常のトランザクション用と管理操作用に、それぞれ別のレーンを使えます。

リプレイ防止を維持しながら、アカウント抽象化で並列ワークフローを支えられます。

この設計は、単一の連番Nonceより柔軟です。

柔軟性が増す分、ウォレット開発者はNonceレーンを慎重に管理する必要があります。

Nonceレーン

Nonceレーンとは、独立したNonce値のストリームです。

アカウント上のすべての操作を一つの順序にまとめる代わりに、Nonceレーンを使うと、異なる操作カテゴリを別々に進められます。

スマートアカウント、セッションキー、自動決済、サブスクリプション、復旧操作、ゲーム内操作、プラグイン型ウォレットなどで役立ちます。

たとえば、ユーザーは日常の支出用と復旧操作用に別々のレーンを設定できます。

復旧用レーンのトランザクションによって、日常支出用レーンのトランザクションがブロックされるべきではありません。

Nonceレーンは柔軟性とユーザー体験を向上させる可能性があります。

ウォレット上で明確に表示されなければ、複雑さを招くこともあります。

ウォレットが誤ったレーンで署名すると、操作が失敗したり、予期しない順序になったりする場合があります。

コントラクトがレーンを正しく検証しなければ、リプレイ防止が不完全になる可能性があります。

Nonceレーンが有効に機能するのは、ルールを容易に理解できる場合に限られます。

スマートコントラクトのリプレイ防止

通常のアカウントNonceでは、コントラクトレベルの承認すべてを保護できないため、スマートコントラクトには独自のNonceによるリプレイ防止が必要となることがよくあります。

コントラクトが署名を受け付ける場合、その署名がすでに使われたかどうかを判定する必要があります。

たとえば、エアドロップ請求コントラクトは、ユーザーが請求済みかどうかを示すマッピングを利用できます。

ガバナンスコントラクトは、提案に対してアドレスが投票済みかどうかを記録できます。

Permitコントラクトは、所有者ごとのNonceを保存できます。

ブリッジコントラクトは、処理済みメッセージIDを保存できます。

マーケットプレイス型エスクローは、約定またはキャンセル済みの注文ハッシュを保存できます。

これらはすべてリプレイ防止の一種です。

具体的なデータ構造は異なっても、目的は同じです。

同じ承認によって状態変更が繰り返されるのを防ぐ必要があります。

ブリッジのリプレイ防止

ブリッジはチェーン間で価値やメッセージを移動させるため、強固なリプレイ防止が必要です。

ブリッジメッセージは、一方のチェーンで資産がロックされたため、別のチェーンでミントまたは解放するよう指示する場合があります。

同じブリッジメッセージが2回処理できると、送信先チェーンが過剰な資産を解放する可能性があります。

ブリッジのリプレイ防止では、メッセージID、送信元Chain ID、送信先Chain ID、送信元コントラクトアドレス、連番、処理済みメッセージのマッピングがよく使われます。

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

同じメッセージが再送信された場合は拒否する必要があります。

チェーン間でアドレス形式、トークンシンボル、スマートコントラクトのインターフェースが共通する場合があるため、クロスチェーンのリプレイリスクは高くなります。

ブリッジはすべてのメッセージを、意図された送信元チェーン、送信先チェーン、ブリッジコントラクト、送信者、受取人、金額、Nonceに結びつける必要があります。

ブリッジのリプレイ防止が弱いと、ミントの誤り、資金の損失、システム全体の流動性リスクが生じる可能性があります。

メタトランザクションのリプレイ防止

メタトランザクションとは、別の当事者が送信する、ユーザー署名済みの指示です。

ユーザーがオフチェーンで署名し、リレイヤーがオンチェーンでトランザクションを送信します。

ユーザーがネイティブ資産でガス代を直接支払わずに済む場合があるため、アプリケーションを使いやすくできます。

メタトランザクションには、慎重なNonceによるリプレイ防止が必要です。

署名済み指示が複数回送信できる場合、リレイヤーや攻撃者が操作を繰り返す可能性があります。

異なるアプリケーションで複数のメタトランザクションに同時に署名すると、連番Nonceが問題を引き起こすことがあります。

ランダムNonceやアプリケーション別のNonce領域を使うと、Nonceの衝突を減らせます。

期限を設ければ、古い署名済み指示の危険性を減らせます。

ドメイン分離により、あるアプリケーション向けのメタトランザクション署名が、別のアプリケーションで使われるのを防げます。

メタトランザクションのセキュリティは、署名検証と同じくらいリプレイ防止に依存します。

ウォレットのログインメッセージにおけるリプレイ防止

多くの暗号資産アプリケーションでは、ウォレットの所有権を証明するため、ユーザーにメッセージへの署名を求めます。

ログイン、アカウント連携、プロフィールの更新、オフチェーン認証などでよく使われます。

ログイン署名には、サーバーが生成したNonceまたはチャレンジを含める必要があります。

ログイン成功後、サーバーはそのチャレンジを使用済みとして記録する必要があります。

可能な場合は、メッセージにドメイン、チェーン、発行時刻、有効期限、意図する操作も含める必要があります。

ログインメッセージに新しいチャレンジが含まれていないと、攻撃者は古い署名を再送信してユーザーになりすます可能性があります。

ログインメッセージに正しいドメインが含まれていないと、あるウェブサイトの署名が別のウェブサイトで利用される可能性があります。

ウォレットログインはオフチェーンで行われることが多いものの、リプレイ防止は依然として重要です。

ウォレットの所有権を証明する署名が、いつまでも使えるパスワードになってはなりません。

安全性の高いログイン署名は、用途が具体的で、新しく、範囲が限定され、人が読める形式になっています。

ガバナンスのリプレイ防止

投票や委任が意図した回数を超えて数えられないよう、ガバナンスシステムにもリプレイ防止が必要です。

投票コントラクトは、提案に対してアドレスが投票済みかどうかを保存できます。

署名による委任コントラクトでは、同じ委任署名が何度も使われないようNonceを利用できます。

提案の実行システムは、実行成功後に提案を実行済みとして記録できます。

ガバナンスの判断が複数のネットワークに反映される場合、チェーン間のリプレイ防止も重要です。

あるチェーン向けの署名済みガバナンスメッセージは、明示的に意図されていない限り、別のチェーンで自動的に実行されるべきではありません。

ガバナンスのリプレイ防止に失敗すると、プロトコルのパラメーター変更、トレジャリー資金の移動、コントラクトのアップグレード、リスク管理の変更につながる可能性があり、深刻な問題となります。

優れたガバナンスコントラクトは、提案ID、Chain ID、コントラクトアドレス、投票期間、Nonce、実行状態を慎重に管理します。

システムが期限前の投票変更を意図的に認める場合に限り、投票を再利用可能にする必要があります。

その場合でも、最終的な集計ルールを明確にする必要があります。

エアドロップと請求のリプレイ防止

エアドロップや報酬請求のコントラクトでは、ユーザーが複数回請求するのを防ぐため、リプレイ防止がよく使われます。

単純な請求システムでは、対象アドレスごとに請求済みかどうかを保存できます。

Merkleエアドロップでは、ユーザーの証明を検証し、その後アドレスまたは請求インデックスを使用済みとして記録できます。

署名ベースの報酬請求には、Nonce、請求ID、キャンペーンID、期限、ユーザーアドレスを含めることができます。

リプレイ防止がなければ、有効な請求証明がプールの資金を使い切るまで再利用される可能性があります。

キャンペーンごとの分離も、リプレイ防止で考慮する必要があります。

キャンペーンAの請求署名をキャンペーンBで使えるべきではありません。

明示的に設計されていない限り、あるチェーンでの請求を別のチェーンで使えるべきではありません。

あるトークンの請求によって、別のトークンの請求が承認されるべきではありません。

優れた請求設計では、証明を正しいユーザー、キャンペーン、チェーン、トークン、金額、Nonceに結びつけます。

リプレイ防止と期限

期限とは、署名済み承認に設ける有効期間です。

期限はNonceの代わりにはなりませんが、盗まれた署名や遅延した署名が利用可能な期間を短縮します。

ERC-2612 Permitは期限フィールドを使用します。

ERC-3009はvalidAfterフィールドとvalidBeforeフィールドを使用します。

ERC-4337のUserOperationには、検証データを通じて有効期間を含められます。

ユーザーがリレイヤーやアプリケーションに署名を渡し、相手が送信時期を選べる場合、期限が特に役立ちます。

期限がなければ、ユーザーの想定よりはるかに長い期間、古い署名済み承認が利用できる可能性があります。

期限を設けると、指定時刻の後に署名が無効になります。

期限が短いと安全性が高まる一方、ネットワーク混雑時にトランザクションが失敗しやすくなる可能性があります。

適切な期限は、操作の価値、リスク、緊急性、予想される決済時間によって異なります。

リプレイ防止と冪等性

冪等性とは、同じ操作を繰り返しても、1回実行した場合と最終結果が変わらない性質です。

EIP-712は、アプリケーションが署名済みメッセージの再送を拒否するか、承認された操作を冪等にするべきだとしています。

たとえば、ユーザーのプロフィール名を同じ値に2回設定しても、問題がない場合があります。

100トークンを2回送金するのは問題です。

支出者を2回承認することが有害かどうかは、金額や現在の利用枠によって異なります。

投票が2回集計されるなら、ガバナンス投票の繰り返しは問題です。

ユーザーが報酬を二重に受け取るなら、報酬請求の繰り返しは問題です。

設計者は、繰り返し実行を拒否するのか、影響のない操作にするのか決める必要があります。

価値を移動させる操作の多くは、繰り返し実行を拒否するべきです。

低リスクの状態更新には冪等性が役立つ場合がありますが、金融操作に不用意に適用すべきではありません。

リプレイ防止と署名の操作対象への紐付け

署名は、ユーザーが意図した正確な操作に結びついている必要があります。

そのため、署名するメッセージには、受取人、金額、トークン、コントラクト、Chain ID、関数の目的、Nonce、期限、重要なパラメーターを含める必要があります。

署名対象が曖昧な承認だけの場合、攻撃者がより広い範囲で再利用する可能性があります。

トークンアドレスを含めずに数値だけに署名すると、誤ったトークンに対する承認として解釈される可能性があります。

Chain IDを含めずに宛先だけに署名すると、別のチェーンでリプレイされる可能性があります。

コントラクトアドレスを含めずにユーザーアドレスだけに署名すると、別のコントラクトが受理する可能性があります。

署名の範囲を限定するほど、リプレイ防止は強化されます。

範囲が限定された署名は、許可する操作だけを正確に指定します。

範囲の広い署名は、リプレイ、悪用、ユーザーの混乱につながる余地を生みます。

ウォレットは、ユーザーが署名する前に詳細を明確に表示する必要があります。

リプレイ防止とフィッシング

Nonce Replay Protectionだけでフィッシングからユーザーを完全に守ることはできません。

ユーザーが悪意のあるメッセージに有効なNonceで署名した場合、攻撃者はその署名を一度利用できる可能性があります。

Nonceは再利用を防ぐかもしれませんが、最初の利用が有害である可能性は残ります。

たとえば、フィッシングサイトがトークン支出を承認するPermitへの署名を求める場合があります。

Permitに有効なNonceと期限が含まれている場合もあります。

送信されると、攻撃者はその有効な承認を一度利用できます。

リプレイ防止は重複利用を防ぐものであり、悪意そのものを防ぐものではありません。

ユーザーは、署名する内容を引き続き確認する必要があります。

ウォレットは、人が理解できる明確な警告を表示する必要があります。

コントラクトは、署名の権限を特定の操作に限定する必要があります。

リプレイ防止とフロントランニング

フロントランニングとは、別の当事者がトランザクションや署名を見て、先に自身のトランザクションを送信することです。

Nonce Replay Protectionにより、署名を一度しか使えなくすることで被害を限定できる場合があります。

ただし、フロントランナーが最初に署名を使うことまで常に防げるわけではありません。

ERC-2612は、意図された当事者が送信する前に、別の当事者がPermit呼び出しをフロントランニングできるとしています。ただし、署名者にとって最終的な承認の結果は同じになる場合があります。

ERC-3009のreceiveWithAuthorizationは、受取人と呼び出し元を一致させ、特定のフロントランニング問題を減らします。

これは、リプレイ防止とフロントランニング防止が関連しているものの、別の仕組みであることを示しています。

Nonceは実行の繰り返しを防ぎます。

フロントランニング対策は、最初の実行を誰が送信でき、その利益を誰が得るかを制御します。

高額な価値を伴う署名には、受取人の紐付け、期限、関数固有の意図を含める必要があります。

Nonceの確認だけで、メンプール攻撃をすべて防げると考えてはいけません。

コントラクト間の再利用とリプレイ防止

コントラクト間のリプレイは、あるコントラクト向けの署名が別のコントラクトで受理される場合に発生します。

署名データに検証コントラクトのアドレスが含まれていないと、起こる可能性があります。

EIP-712のドメイン分離は、ドメインにverifyingContractを含めることで、このリスクを低減します。

ERC-2612は、コントラクトとチェーンに固有のドメインセパレーターを推奨しています。

同じ署名スキーマを使う複数のコントラクトが、コントラクト固有のドメインを含めていない場合にも、コントラクト間のリプレイが起こる可能性があります。

たとえば、署名データが一般的すぎると、2つのトークンコントラクトがどちらもPermit形式のメッセージを受理する場合があります。

ユーザーは一方のトークンを承認するつもりでも、同じ署名が別のトークンによって解釈される可能性があります。

このため、コントラクトアドレスとの紐付けが不可欠です。

有効な署名がコントラクト間を自由に移動できてはなりません。

署名は、厳密に定められた一つの検証ドメインに属する必要があります。

チェーン間の再利用とリプレイ防止

クロスチェーンリプレイは、あるチェーン向けの署名済みトランザクションやメッセージが別のチェーンで受理されることです。

EIP-155は、署名対象のトランザクションハッシュにChain IDを加えることで、Ethereum形式のトランザクションにおけるこのリスクを低減します。

EIP-712の型付きデータも、署名ドメインにchainIdを含められます。

署名データからChain IDが省かれると、アプリケーションレベルのメッセージでクロスチェーンリプレイが起こる可能性があります。

たとえば、ブリッジ、DAO、トークンPermit、ログイン署名では、チェーンの指定が必要な場合、対象チェーンを明記する必要があります。

アドレスやコントラクトのバイトコードが似ていることがあるため、Chain IDは特にEVM互換ネットワークで重要です。

同じアドレスを複数のチェーンで管理することもできます。

決定論的デプロイにより、同じアドレスにコントラクトが複数のチェーンで展開される場合もあります。

チェーンとの紐付けがなければ、署名が危険なほど多くの環境で使える可能性があります。

安全な設計では、チェーンを明示します。

リプレイ防止とトランザクションの置き換え

トランザクションの置き換えとは、保留中のトランザクションに代えて、より高い手数料を設定した新しいトランザクションを同じアカウントNonceでブロードキャストすることです。

それ自体はリプレイ攻撃ではありません。

Ethereum形式の多くのワークフローで使われる、通常のトランザクション管理方法です。

重要なのは、そのNonceで最終的に実行できるトランザクションは一つだけという点です。

ユーザーは、遅いトランザクションをより速いトランザクションに置き換えることができます。

保留中のトランザクションをキャンセルするため、同じNonceで自分自身にゼロ価値のトランザクションを送ることもできます。

ノードに受理されるには、置き換えトランザクションがネットワークの手数料引き上げルールに従う必要があります。

Nonce Replay Protectionがあるからこそ、置き換えが可能になります。

Nonceによって、ネットワークはその枠で実行するトランザクションを一つに絞ります。

誤ったNonceを置き換えると、必要な操作をキャンセルまたは上書きする可能性があるため、注意してください。

リプレイ防止と停滞したトランザクション

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

そのトランザクションが次に必要なNonceを使用している場合、同じアカウントからの後続トランザクションも待機する可能性があります。

これは連番Nonceの副作用です。

通常のトランザクション順序では、アカウントは不足しているNonceを飛ばせません。

停滞したトランザクションをスピードアップまたはキャンセルするには、同じNonceの置き換えトランザクションを送信する必要がある場合があります。

通常、ウォレットが自動的に管理しますが、手動でNonceを設定すると混乱することがあります。

Nonceを高く設定しすぎると、先行するNonceが埋まるまで確認されない可能性があります。

Nonceを低く設定しすぎると、そのNonceがすでに使われているため、トランザクションが失敗する可能性があります。

Nonce Replay Protectionはアカウントを保護しますが、慎重な順序管理も必要です。

上級ユーザーがトランザクションNonceを手動で変更する場合は、Nonceの状態を理解しておく必要があります。

リプレイ防止とセッションキー

セッションキーは、一定期間、特定の操作を承認できる限定利用のキーです。

ゲーム、サブスクリプション、自動化戦略、アカウント抽象化ウォレットなどで役立ちます。

セッションキーは多くの小規模な操作に署名する場合があるため、強固なNonceによるリプレイ防止が必要です。

セッションキーの承認には、許可される関数、支出上限、宛先コントラクト、有効期限、Chain ID、Nonceルールなどの制限を含める必要があります。

Nonceによる保護がなければ、セッションキーの署名を取得した攻撃者が何度も再送信する可能性があります。

操作の制限がなければ、セッションキーに過剰な権限が付与される可能性があります。

Nonceレーンを使うと、セッションキーの操作をメインウォレットの操作から分離できます。

これにより、リプレイ安全性を維持しながら、ユーザー体験を向上できる場合があります。

セッションキーは簡単に失効できる必要があります。

また、リプレイによる被害を限定できるよう、権限の範囲を十分に狭くする必要があります。

リプレイ防止とマルチシグウォレット

マルチシグウォレットにもリプレイ防止が必要です。

マルチシグトランザクションには、実行済みのウォレット操作を追跡する内部Nonceが使われることがよくあります。

署名者は、ウォレットNonceと操作の詳細を含む特定のトランザクションハッシュを承認します。

マルチシグがトランザクションを実行すると、Nonceが増加するか、トランザクションハッシュが実行済みとして記録されます。

これにより、同じ署名グループを使って同一操作が2回実行されるのを防ぎます。

マルチシグのリプレイ防止では、署名をウォレットアドレス、Chain ID、宛先アドレス、価値、データ、操作タイプ、Nonceに結びつける必要があります。

マルチシグウォレットが複数のチェーンに展開されている場合、クロスチェーンのリプレイ防止は特に重要です。

署名者は承認前に、チェーンとウォレットアドレスを確認してください。

複数人が署名したというだけで、マルチシグ署名が安全になるわけではありません。

署名対象のデータは、明確でリプレイ耐性を備えている必要があります。

リプレイ防止とオラクル

オラクルシステムは、価格更新、データ証明、準備金報告、乱数出力、クロスチェーンメッセージなどに署名する場合があります。

こうした署名済みデータにもリプレイ防止が必要です。

古い価格更新をいつまでも受け入れてはいけません。

あるゲームラウンドの乱数結果を別のラウンドで再利用してはいけません。

期限切れの後に準備金証明を再送信してはいけません。

オラクルメッセージには、必要に応じてフィードID、ラウンドID、タイムスタンプ、連番、Chain ID、送信先コントラクトを含める必要があります。

コントラクトは、古いオラクルメッセージや使用済みのメッセージを拒否する必要があります。

スマートコントラクトがオラクルデータに基づき自動的に動作することがあるため、リプレイ防止は不可欠です。

古いデータが再利用できると、強制決済、決済、ミント、償還、支払いが誤ったものになる可能性があります。

オラクルデータの鮮度とNonce管理は、どちらもスマートコントラクトの安全性を支えます。

署名が正しくても、データが古い、または再利用されたものであれば十分ではありません。

リプレイ防止とトークン承認

トークン承認は、リプレイ防止が特に重要な分野の一つです。

通常のオンチェーン承認では、トランザクションのアカウントNonceを使い、利用許可の状態を更新します。

署名によるPermitでは、所有者が直接トランザクションを送信しなくても承認できるよう、コントラクトレベルのNonceと期限を使います。

Permit署名を再利用できると、ユーザーが承認を解除したと思った後に、支出者が再び利用枠を得る可能性があります。

Permitから支出者、トークン、金額、Nonce、期限、ドメインが欠けていると、署名が悪用される可能性があります。

ユーザーは、署名による承認を重要な金融上の承認として扱う必要があります。

ウォレットは、支出者、トークン、金額、期限、アプリケーションを明確に表示する必要があります。

コントラクトは、使用済みのPermit Nonceを直ちに拒否する必要があります。

絶対に必要な場合を除き、アプリケーションは無制限の承認を求めないようにする必要があります。

リプレイ耐性のある承認設計は、ウォレット資産を抜き取る攻撃経路としてよくあるものの一つを減らします。

リプレイ防止とスマートコントラクトのアップグレード

アップグレード可能なコントラクトでは、リプレイに関する追加の検討が必要です。

コントラクトをアップグレードしても、ドメインバージョン、Nonceロジック、検証ルールを変更しなければ、古い署名が有効なままになる場合があります。

EIP-712が署名ドメインにバージョンフィールドを含めているのはこのためです。

大規模なコントラクトアップグレードでは、古い承認が引き続き安全かどうかを検討する必要があります。

アップグレード後に古い署名を無効にする場合は、新しいドメインバージョンやNonce無効化方法が必要となることがあります。

古い署名を引き続き有効にする場合は、アップグレード後もNonce状態を正しく維持する必要があります。

Nonce状態の移行に失敗すると、古い署名がリプレイ可能になったり、有効な署名が使えなくなったりする可能性があります。

アップグレード計画には、署名の移行、ドメインの変更、Nonceの保存領域、ユーザーへの案内を含める必要があります。

リプレイ防止はデプロイ時だけの課題ではありません。

アップグレードや移行後も機能する必要があります。

リプレイ防止とフォーク

チェーン分岐の両側が同じトランザクション形式と状態を受け入れると、リプレイリスクが生じる可能性があります。

両方のチェーンで同じ秘密鍵とアカウント状態を使っている場合、保護方法に差がなければ、一方のフォーク上のトランザクションがもう一方でもリプレイされる可能性があります。

EIP-155のChain ID保護は、Ethereumトランザクションにおけるこのリスクを軽減するために設計されました。

ただし、アプリケーションレベルの署名にもチェーンとの紐付けが必要です。

フォークの前後に署名されたPermit、ガバナンス投票、ブリッジメッセージ、オフチェーン注文は、チェーンのコンテキストが明確でないと予期しない動作をする可能性があります。

フォークやチェーン分岐の際は注意が必要です。

ウォレットとアプリケーションは、Chain IDとドメインセパレーターを正しく更新する必要があります。

チェーン分岐後のリプレイリスクに安全に対応する設計でない限り、コントラクトはリスクが生じるような形でChain IDをキャッシュしないようにする必要があります。

フォーク時のリプレイ防止は、プロトコルとアプリケーションの両方に関わる課題です。

両方のレイヤーで対策が必要です。

Nonce Replay Protectionのメリット

第一のメリットは、一度限りの承認です。

署名済み操作を一度消費し、その後は拒否できます。

第二のメリットは、トランザクションの一意性です。

同じアカウントからのトランザクションを、Nonce値によって区別できます。

第三のメリットは、順序付けです。

連番Nonceは、アカウントのトランザクションが有効となる順序を定めるのに役立ちます。

第四のメリットは、Chain IDと組み合わせた場合のクロスチェーン安全性です。

署名を意図されたネットワークに結びつけられます。

第五のメリットは、スマートコントラクトのセキュリティ向上です。

コントラクトは、Permit、請求、投票、送金、ブリッジメッセージの繰り返しを防げます。

第六のメリットは、ユーザー体験の安全性向上です。

ウォレットは、保留中の操作、停滞したトランザクション、置き換えトランザクションをより確実に検出できます。

Nonce Replay Protectionのリスクと制約

第一の制約は、Nonceによる保護では署名済みメッセージの最初の悪用を防げないことです。

ユーザーが有害な承認に署名した場合、Nonceが防ぐのは最初の実行後の再利用だけです。

第二の制約は、トランザクション管理が複雑になることです。

連番Nonceは、トランザクションの停滞やキューのブロックを招く可能性があります。

第三の制約は、ストレージコストです。

使用済みランダムNonceを保存するコントラクトでは、オンチェーンのストレージ使用量が増える可能性があります。

第四の制約は、実装上のリスクです。

Nonceの確認が欠けていると、署名がリプレイ可能になります。

第五の制約は、ドメイン間の複雑性です。

Nonceが一つのコントラクトを保護しても、別のコントラクトやチェーンまでは保護しない場合があります。

第六の制約は、アップグレードリスクです。

慎重に処理しなければ、コントラクト移行時にNonce状態が損なわれる可能性があります。

Nonce Replay Protectionでよくある誤り

よくある誤りの一つは、署名を検証してもNonceを確認しないことです。

Nonceを確認しても、増加させたり使用済みとして記録したりしないことも誤りです。

3つ目の誤りは、ユーザーごとのNonceではなく、すべてのユーザーで一つの共通Nonceを使うことです。

署名データからChain IDを省くことも誤りです。

型付きデータから検証コントラクトのアドレスを省くことも誤りです。

期限のない署名を受け入れることも誤りです。

異なる操作タイプ間で同じNonceを使えるようにすることも誤りです。

アップグレード時にNonceの保存領域を移行しないことも誤りです。

予測可能なランダムNonceを使うことも誤りです。

EIP-712がすべてのリプレイ攻撃を自動的に防ぐと考えることも誤りです。

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

価値や状態を変更できるオフチェーン承認には、必ずNonceを含めてください。

設計上、グローバルな順序が明確に必要な場合を除き、Nonceは全体で一つではなく署名者ごとに管理してください。

回避されることのない方法で、実行前または実行中にNonceを増加させるか、使用済みとして記録してください。

チェーンのコンテキストが重要な場合は、署名ドメインにChain IDを含めてください。

署名ドメインに検証コントラクトのアドレスを含めてください。

署名メッセージには、関数の意図、受取人、金額、トークン、期限、関連パラメーターを正確に含めてください。

リレー経由の署名には、期限または有効期間を設定してください。

並列実行が必要な場合は、関係のないワークフローのNonce領域を分けてください。

承認が使用またはキャンセルされた際にイベントを発行してください。

デプロイ前に、リプレイ攻撃、クロスチェーン署名、コントラクトのアップグレード、キャンセル、実行失敗の各ケースをテストしてください。

ウォレットとアプリケーション向けのベストプラクティス

ユーザーが署名する前に、チェーン、コントラクト、支出者、金額、期限、Nonceのコンテキスト、操作タイプを表示してください。

署名が支出権限や長期間有効な承認を与える場合、ユーザーに警告してください。

ウォレット認証には、新しいログインチャレンジを使用してください。

ログイン後、認証チャレンジを使用済みとして記録してください。

曖昧で読みにくいメッセージへの署名をユーザーに求めないでください。

可能な場合は、構造化署名にEIP-712の型付きデータを使用してください。

明確なスピードアップとキャンセルの選択肢を提示し、停滞したトランザクションNonceに対処してください。

トランザクションの置き換え動作をユーザーに隠さないでください。

安全に説明できるインターフェースがある場合に限り、アカウント抽象化のNonceレーンに対応してください。

古い、期限切れ、または誤ったチェーン向けのリクエストに署名しないよう、ユーザーを保護してください。

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

メッセージやトランザクションに署名する前に、ウォレットの確認画面を読んでください。

署名前にチェーンを確認してください。

署名を要求しているコントラクトまたはアプリケーションを確認してください。

Permit形式の承認では、トークン、支出者、金額、期限を確認してください。

曖昧、無制限、または実行中の操作と関係のない署名は拒否してください。

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

Nonceがあるからといって、悪意のある署名が安全になるとは考えないでください。

実用上可能であれば、大きな残高にはハードウェアウォレットやマルチシグを使用してください。

適切な場合は、不要なトークン承認を取り消してください。

保留中のトランザクション状態を理解していない場合は、Nonceを手動で設定する際に注意してください。

Nonce Replay Protectionが特に重要な場合

署名が価値の移動を承認する場合、Nonce Replay Protectionが特に重要です。

通常のブロックチェーントランザクションで重要です。

Permitによる承認で重要です。

ガス代をユーザーが直接支払わないトークン送金で重要です。

ブリッジメッセージで重要です。

ガバナンス投票と委任で重要です。

エアドロップや報酬の請求で重要です。

ウォレットのログインチャレンジで重要です。

マルチシグトランザクションとアカウント抽象化のUserOperationで重要です。

コピーされた署名が操作の繰り返しや意図しない結果を招く可能性がある、あらゆる場面で重要です。

一文でわかるNonce Replay Protection

Nonce Replay Protectionとは、一意で追跡可能な、コンテキストに紐付いたNonce値を使い、署名済みの暗号資産トランザクション、メッセージ、承認が、意図されたチェーン、コントラクト、アプリケーションのコンテキストで一度だけ実行されるようにする仕組みです。

よくある質問

Nonce Replay Protectionとは何ですか？

Nonce Replay Protectionとは、一意のNonceを確認して消費することで、同じ署名済みの暗号資産操作が複数回受理されるのを防ぐ仕組みです。

暗号資産におけるNonceとは何ですか？

Nonceとは、トランザクション、メッセージ、承認を一意にするため、特定のコンテキストで一度だけ使う数値または一意の値です。

リプレイ攻撃とは何ですか？

リプレイ攻撃とは、有効な署名済み操作をコピーして再送信し、承認を繰り返し実行または悪用する攻撃です。

EthereumはNonceをどのように使いますか？

EthereumアカウントはNonceカウンターを使い、各アカウントについて同じNonceのトランザクションが一つだけ実行されるようにします。

Chain IDによるリプレイ防止とは何ですか？

Chain IDによるリプレイ防止は、トランザクションまたはメッセージを特定のブロックチェーンに結びつけ、別のチェーンで再利用されにくくする仕組みです。

EIP-712はリプレイ攻撃を自動的に防ぎますか？

いいえ。EIP-712は署名対象データを構造化しますが、アプリケーションにはNonce確認、期限、適切なドメイン分離が引き続き必要です。

PermitにNonceが必要なのはなぜですか？

同じ署名済みトークン承認が繰り返し送信されるのを防ぐためです。

Nonceと期限の違いは何ですか？

Nonceは署名を一度限りにし、期限は署名が有効である期間を制限します。

リプレイ防止でフィッシングを防げますか？

いいえ。リプレイ防止は繰り返しの利用を防げますが、ユーザーが悪意のある承認に署名した場合、最初の悪用を防ぐことはできません。

Nonceが再利用されるとどうなりますか？

Nonceが正しく処理されていれば、2回目の利用は失敗するはずです。ただし、システムの設計が不十分であれば、Nonceの再利用はリプレイやトランザクション失敗につながる可能性があります。

スマートコントラクトが独自にNonceを確認する必要があるのはなぜですか？

通常のアカウントNonceでは、オフチェーン署名、Permit、請求、投票、ブリッジメッセージが自動的に保護されないためです。

最も安全なリプレイ防止設計とは何ですか？

署名者ごとのNonce、Chain ID、検証コントラクト、正確な操作詳細、期限、使用済み状態の追跡、慎重な署名検証を組み合わせた設計です。

まとめ

Nonce Replay Protectionは、暗号資産の基盤を支える目立たないセキュリティ要素の一つです。

有効な署名が何度でも使える白紙委任状にならないようにします。

ブロックチェーン署名は、秘密鍵がメッセージを承認したことを証明しますが、その承認が新しく、未使用で、一度の実行に限られていることまでは自動的に証明しません。

Nonceは、その新しさを確認するレイヤーを加えます。

Nonceを正しく確認して消費すれば、同じ署名済み操作は再び実行できません。

これにより、通常のトランザクション、トークンPermit、ガス代不要の送金、スマートアカウントの操作、マルチシグ承認、ブリッジメッセージ、ガバナンス投票、ログインチャレンジ、報酬請求など、さまざまな暗号資産の操作を保護できます。

現代のリプレイ防止は、単一のカウンターだけではありません。

アカウントNonce、コントラクトレベルのNonce、ランダムな承認ID、Chain ID、検証コントラクトアドレス、期限、有効期間、Nonceレーン、処理済みメッセージのマッピングを組み合わせることがよくあります。

各レイヤーは、それぞれ異なるリプレイの問題を解決します。

アカウントNonceは、同一チェーン上で同じアカウントから送信されるトランザクションの繰り返しを防ぎます。

Chain IDは、トランザクションが別のチェーンにコピーされるのを防ぎます。

コントラクトNonceは、アプリケーション内で署名済みメッセージが再利用されるのを防ぎます。

期限は、古い署名がいつまでも有効であり続けるのを防ぎます。

ドメイン分離は、署名が誤ったコントラクトやアプリケーションで使われるのを防ぎます。

Nonceレーンは、リプレイ防止を維持しながら、スマートアカウントで並列ワークフローを実現します。

こうした対策が欠けている場合、深刻なリスクが生じます。

リプレイ可能な署名は、資金の流出、承認の再実行、請求の重複、ブリッジメッセージの二重実行、ガバナンスの歪曲につながる可能性があります。

Nonceによる保護があっても、ユーザーが悪意のある承認に一度署名すれば、フィッシングの被害に遭う可能性があります。

そのため、リプレイ防止には、わかりやすいウォレット画面、範囲を限定した署名、堅牢なコントラクト設計、慎重なユーザー行動を組み合わせる必要があります。

開発者向けのルールは明確です。

価値の移動や重要な状態の変更を可能にするすべての署名には、Nonce、ドメイン、明確な消費ルールが必要です。

ウォレットには、署名前にユーザーが承認する内容を正確に示すことが求められます。

ユーザーは、すべての署名を無害な確認ではなく、実際の操作として扱う必要があります。

Nonce Replay Protectionによって、暗号資産がリスクのないものになるわけではありません。

一つの承認が、意図された一つのコンテキストで、意図された用途に一度だけ使われ、将来にわたって何度もリプレイされないようにすることで、署名による承認を実用的なものにします。