EIP-712――署名ボタンの前に、読める内容を
ウォレットが秘密鍵を守っていても、持ち主が署名の意味を理解できるとは限らない。EIP-712はメッセージに確認可能な構造を与えた。その署名で何を許可するかは、アプリの側に残る。
3点クイック要約
- 発端 / 逆説2017年9月に作成されたEIP-712は、構造化メッセージのハッシュ計算と署名を標準化した。
- 決定的瞬間ドメイン情報は署名の文脈を分ける。同じ署名の再利用はアプリが別途処理する必要がある。
- 歴史的結末ERC-2612のpermitでは、所有者が承認トランザクションを直接送らずにトークンの利用枠を設定できる。
出来事のタイムライン
名前と型を持つ項目、ドメイン分離を備えたEIP-712が作成された。
ERC-2612がnonceと提出期限を含むpermitを規定した。
鍵は署名できても、人には読めなかった
2017年9月12日、Remco Bloemen、Leonid Logvinov、Jacob EvansはEIP-712を提案した。出発点は身近な不便だった。ウォレットは長い16進数の文字列を表示して署名を求めることができる。暗号技術が正しく働いても、持ち主には内容がわかりにくい。提案はデータに名前と型を与え、ウォレットが依頼の中身を表示できるようにした。[1]
見た目だけの変更ではない。送り手、受け手、数量を、意味の見えないバイト列ではなく別々の項目として扱える。仕様はアプリ名、バージョン、チェーン識別子、検証コントラクトのアドレスなど、必要な項目で署名ドメインも定義する。同じように見えるメッセージでも、使う文脈が違えば署名結果を区別できる。ただし、この情報は事業者の誠実さを認証するものではない。[1]
項目名も判断材料になる
MetaMaskの開発者向け文書は、画面上の意味を明確にしている。eth_signTypedData_v4は構造化データを確認できる形で表示し、最上位の型名、ドメイン名、項目名をセキュリティ上のインターフェースとして扱うよう開発者に求める。技術的に正しい依頼でも、名前が曖昧なら人には判断しづらい。構造が説明の場を用意し、その場を活かすのはウォレットとアプリだ。[2]
読みやすさがまず答えるのは、何のデータに署名するかという問いだ。それがログイン、注文、トークンの利用許可のどれになるかは、受け取るアプリによる。これはメッセージの表現とアプリの動作を分けて考えた設計上の解釈である。整った確認画面そのものが、承認してよいという推薦になるわけではない。[1][2]
権限はトランザクションより先に届く
2020年4月13日に作成されたERC-2612は具体例を示す。permitメッセージには所有者、利用を許可するアドレス、上限値、nonce、提出期限が含まれる。有効な提出により、そのアドレスの利用枠が指定値に設定され、nonceが増える。提出は誰でもでき、所有者が承認トランザクションを直接送る必要はない。署名自体はトークンを送らないが、設定された枠は後のtransferFromによる移動を可能にし得る。[3]
nonceは使用済みのpermitが再び成功することを防ぐ。期限が制限するのは提出できる時刻であり、設定済みの利用枠を自動的に失効させるものではない。permitが効力を持つには誰かがオンチェーンのトランザクションを提出する必要がある。EIP-712は再利用への対処をアプリの責任として明記している。署名依頼を読むとは、項目に加えて受け取るコントラクトの動作まで考えることだ。ボタンは小さいままでも、その前の判断は見えやすくなった。[1][3]
この人物・事件と繋がる関連ストーリー
歴史のバタフライ効果で結びついた、もう一つのドラマを探求する。
出典・参考文献
- [1]出典 1: EIP-712：動機、ドメイン分離、再利用対策の範囲Ethereum Improvement Proposals · 2017-09-12確認 2026-09-24
- [2]出典 2: MetaMask：構造化署名と利用者向けのセキュリティ画面MetaMask確認 2026-09-24
- [3]出典 3: ERC-2612：利用枠、nonce、期限、提出条件Ethereum Improvement Proposals · 2020-04-13確認 2026-09-24