---
title: "EIP-712 型付き署名：ドメイン、ダイジェスト、安全な検証"
description: "EIP-712 は構造化 Ethereum メッセージを決定的かつ表示可能にしますが、安全な署名にはドメイン、型、値、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.
# EIP-712 型付き署名：ドメイン、ダイジェスト、安全な検証
> 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 直接の答え
EIP-712 は、Ethereum アプリケーションが型付き構造化データを記述し、ハッシュ化し、署名を要求する方法を標準化します。要求は `types`、`primaryType`、`domain`、`message` を含み、ダイジェストは `keccak256("\x19\x01" || domainSeparator || hashStruct(message))` です。これによりエンコードが決定的になり、対応ウォレットは不透明なハッシュより明確に各フィールドを表示できます。
ただし、メッセージが正しい、安全、取消可能、リプレイ不能になるわけでは**ありません**。アプリケーションは権限を正しいチェーンと検証者に結び付け、各フィールドを明確に定義し、Nonce と時間制限を強制し、正しい署名者を検証して、実行可能な処理を制約する必要があります。有効な署名が証明するのは、特定の検証規則において厳密なダイジェストが承認されたことだけであり、本人性、十分に理解した意思、ウェブサイトやコントラクトの安全性は証明しません。
## 仕組み
### 1. 操作と検証経路を特定する
要求がログイン、注文、投票、トークン allowance、送金、リレー呼び出し、その他のどの操作を許可するか確認します。ダイジェストを再構築し署名を消費するコードを特定します。外部所有アカウントでは ECDSA 署名からアドレスを復元する方法が一般的です。コントラクトアカウントでは ERC-1271 の `isValidSignature(hash, signature)` と成功値 `0x1626ba7e` が必要になる場合があります。
### 2. ドメインを固定する
厳密な `EIP712Domain` の型と値を確認します。標準フィールドは `name`、`version`、`chainId`、`verifyingContract`、`salt` ですが、実際に含まれるものだけがハッシュ化されます。現在のチェーン、デプロイ済みコード、意図した検証者を独立に確認してください。見覚えのある名前、トークン記号、プロキシのラベル、チェックサム付きアドレスだけでは不十分です。ERC-5267 の `eip712Domain()` はドメインを公開できますが、対応は任意であり、プロキシやアップグレードの挙動も調査が必要です。
### 3. 型グラフを再構築する
`primaryType` から開始し、メンバー順を維持して参照先の構造体を再帰的に集めます。`encodeType` は参照構造体の定義を型名順に並べて付加します。EIP-712 は固定幅整数、`address`、`bool`、`bytes1` から `bytes32`、動的な `bytes` と `string`、配列、構造体を扱います。`uint` や `int` という別名、固定小数点型、循環値は標準で定義されていません。
### 4. すべての値と単位を読み解く
各値を宣言型とアプリケーション上の意味に対応させます。完全なアドレス、生の整数単位、符号、配列順、受取人、spender、資産、数量、手数料、上限、送信先、calldata ハッシュ、人間向け文字列を確認します。動的な `bytes` と `string` は `encodeData` 内で内容の Keccak-256 ハッシュとして表現され、配列は連結した要素エンコードのハッシュ、入れ子構造体は自身の `hashStruct` を使います。
### 5. ダイジェストを独立に再計算する
`typeHash = keccak256(encodeType(primaryType))` を計算し、続いて `hashStruct(message) = keccak256(typeHash || encodeData(message))` を計算します。同じ方法でドメインセパレーターを算出し、ERC-191 のバージョンバイト `0x19 0x01` と組み合わせます。フロントエンド、署名ライブラリ、検証コントラクト、独立実装の結果を比較してください。JSON の見た目が同じでも型付きエンコードが同一とは限りません。
### 6. リプレイ、時間、実行制御を監査する
EIP-712 自体にリプレイ保護はありません。検証者が意図した署名者を確認し、正しい Nonce を消費または無効化し、`deadline` または有効期間を強制し、セキュリティ上重要な実行パラメーターをすべて拘束することを確認します。リレイヤーやフロントランナーが先に提出しても意図した結果になる必要があります。ドメイン分離が防ぐのは実際にエンコードされたドメイン間の衝突だけで、フィールドの欠落や誤りはコントラクト間・チェーン間の再利用経路を残します。
### 7. 権限を最小化して結果を照合する
隠れたフィールド、説明できない型、無制限値、遠い期限、不明なコントラクト、不一致のチェーン ID、ブラインド署名画面、不完全な実行情報は拒否します。正確な型付きデータ JSON とダイジェストを保存し、可能なら用途限定アカウントを使います。提出トランザクション、receipt、event、残高、allowance、Nonce、注文状態、finality を確認してください。サイトとの接続解除では、利用可能な署名や既に作られた権限は取り消されません。
## 計算例
### 例 1：型とダイジェストの構築
`Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline)` の `typeHash` は、フィールド順を含むこの厳密な文字列の Keccak-256 ハッシュです。メッセージハッシュは `keccak256(typeHash || maker || token || amount || nonce || deadline)` で、各メンバーは 32 バイトを占めます。最終ダイジェストは `0x1901`、ドメインセパレーター、メッセージハッシュを結合します。`amount` を `250000000` から `250000001` に変えるとダイジェストが変わり、以前の署名は無効になります。
### 例 2：単位と期限
小数点以下 6 桁のトークンの `250 USDC` は、生の値 `250000000` としてエンコードされ、`250` ではありません。現在のタイムスタンプが `1727000000`、期限が `1727000900` なら、署名可能時間は `900 seconds = 15 minutes` です。ウォレットの小数表示とローカル時計は補助にすぎず、検証者は生の整数と選択したオンチェーン時間規則を使います。
### 例 3：リプレイ制御
注文の Nonce が `41`、最大約定量が `5 ETH` だとします。検証者が Nonce 41 を消費済みにした後は、署名自体が正しくても 2 回目の提出は失敗しなければなりません。コントラクトが Nonce を消費せず、実行も冪等でなければ、同じ署名が別の `5 ETH` を許可し得ます。ドメインセパレーターだけではこのリプレイを防げません。
### 例 4：コントラクトウォレットの有効性
2-of-3 コントラクトウォレットに署名者 A、B、C が設定されている間、あるダイジェストを承認したとします。A と B の署名に対し、現在は ERC-1271 が `0x1626ba7e` を返す可能性があります。モジュールのアップグレードで B が D に置き換わると、同じ署名バイト列でも無効になり得ます。ERC-1271 の有効性は現在の状態、ポリシー、時間、外部呼び出しに依存できるため、アドレス復元だけでは判断できません。
## リスク
- `chainId` の誤りまたは欠落
- 偽造または想定外の `verifyingContract`
- 誤解を招くドメインの `name` または `version`
- アップグレード後に変わるプロキシ実装またはドメイン
- 誤った `primaryType` または似たラベルの影の型
- メンバー順、依存関係順、エンコーダーの不一致
- アドレスの省略、置換、誤ったラベル
- トークン小数桁または符号付き・符号なし整数の誤り
- 隠れた配列要素、入れ子構造体、任意の `bytes` ペイロード
- 無制限数量、広すぎる範囲、攻撃者が決める受取人
- 欠落、古い、共有、または誤って消費される Nonce
- 欠落、遠すぎる、オーバーフローした、または曖昧な期限
- チェーン間、コントラクト間、アカウント間、操作間のリプレイ
- リレイヤーによる保留、検閲、フロントラン、実行先変更
- 署名の可鍛性または緩すぎる ECDSA 復元
- ERC-1271 の署名者、モジュール、閾値、状態、コードの変更
- ウォレット表示、ブラインド署名、未対応型の不具合
- フロントエンド JSON と検証者のダイジェストの相違
- 取消またはキャンセルが順序競争に負けること
- 署名画面の結果を receipt、状態変更、finality と誤認すること
## よくある誤解
### 誤解 1：EIP-712 署名はトランザクションである
これはオフチェーンで署名されたメッセージです。後からリレイヤーなどがコントラクトへ提出でき、そのトランザクションは署名者が送信しなくても Gas を消費して状態を変更できます。
### 誤解 2：構造化表示なら要求は安全である
型付きフィールドは確認しやすさを改善しますが、悪意あるスキーマ、値、コントラクト、ラベル、隠れた入れ子、不完全なウォレット表示は署名者を誤認させ得ます。
### 誤解 3：ドメインセパレーターはすべてのリプレイを防ぐ
分離するのはエンコードされたドメインだけです。同一ドメインのリプレイには Nonce、期限、取消、約定管理、冪等性が必要で、含まれないドメインフィールドは境界になりません。
### 誤解 4：期待したアドレスを復元できれば権限が証明される
復元が証明するのは EOA がダイジェストへ署名したことだけです。アプリケーションの意味は検証せず、コントラクトアカウントには通常の復元ではなく ERC-1271 ポリシーが必要です。
### 誤解 5：ページを閉じるか接続解除すれば署名は取り消される
コピーされた署名は、検証者の Nonce、期限、取消状態、ポリシーによって無効になるまで利用可能です。セッション状態ではなく該当するオンチェーン状態を確認してください。
## 関連トピック
- [チェーン ID](/ja/crypto/chain-id/)
- [ERC-2612 Permit の Nonce と期限](/ja/crypto/erc2612-permit-nonce-deadline/)
- [Permit2 署名のリスク](/ja/crypto/permit2-signature-risk/)
- [ウォレット承認](/ja/crypto/wallet-approval/)
- [ウォレット署名](/ja/crypto/wallet-signature/)
## 出典
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [ERC-191: Signed Data Standard](https://eips.ethereum.org/EIPS/eip-191) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [ERC-1271: Standard Signature Validation Method for Contracts](https://eips.ethereum.org/EIPS/eip-1271) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [ERC-5267: Retrieval of EIP-712 domain](https://eips.ethereum.org/EIPS/eip-5267) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [EIP-2: Homestead Hard-fork Changes](https://eips.ethereum.org/EIPS/eip-2) - Ethereum Improvement Proposals（参照日：2026-08-19）
- [Contract ABI Specification](https://docs.soliditylang.org/en/latest/abi-spec.html) - Solidity Documentation（参照日：2026-08-19）
- [ERC-7730: Structured Data Clear Signing Format](https://eips.ethereum.org/EIPS/eip-7730) - Ethereum Improvement Proposals（参照日：2026-08-19）
Source: https://wiki.fcontext.com/ja/crypto/eip712-typed-signature/index.mdx