盲目署名とは、取引に署名する際、ハードウェアウォレットのデバイスが受け取るのが解析されていない生の16進数データやハッシュ値の文字列だけであり、デバイス自体には「誰に、いくら、何を承認しようとしているのか」といった人間が理解できる情報にそのデータを復号する能力がない状態を指す。イーサリアム初期のeth_signメソッドはまさにこのパターンの原型だった——ユーザーが最初から最後まで目にするのは意味を検証できない文字列だけであり、ハードウェアデバイスはその文字列に忠実に署名するだけで、その背後にある実際の取引内容が何であるかはまったく把握していなかった。ユーザーにはソフトウェアインターフェースが伝える内容を信じる以外の選択肢がなかった。
盲目署名が危険なのは、根本的には「ユーザーが読めない」という事実そのものではなく、取引内容を判読する作業全体がハードウェアデバイスの外にあるソフトウェア層に丸ごと外部委託されてしまっており、その層こそが攻撃者が最も好んで改ざんの標的にする場所だという点にある。そのソフトウェアが一度侵害されれば、ユーザーが実際に署名している内容と、署名していると思い込んでいる内容は、まったく別物になりうる。
盲目署名が存在する根本的な理由は、ハードウェアウォレットのデバイス自体が設計上、計算能力と表示能力が極めて限られていることにある。これらのデバイスは、秘密鍵をオフライン環境に安全に隔離しておくことを主眼として設計されており、画面もプロセッサも通常非常に簡素で、複雑なデータ解析作業を担うには不十分だ。イーサリアム初期のエコシステムにおける署名の仕組みが設計された当時も、開発者が取引データをデバイスが解析しやすい形式でタグ付けする標準化された方法はまだ存在しておらず、その結果ほとんどの取引はデバイス側では最も生のハッシュ値の形でしか提示できず、デバイスはそのハッシュ値に忠実に署名する以外の選択肢がなかった。
2017年に登場したEIP-712規格は、この問題を解決しようと試み、開発者が取引データにフィールド名と型を固定フォーマットでタグ付けできる「構造化データ署名」の規格を定義した。しかしこの規格が実際に機能するには、デバイスが特定のコントラクトや取引種別のデータを正しく解析するための対応する「ディスクリプタ」をあらかじめ持っている必要がある。これは、新しくデプロイされたコントラクトや規格がまだカバーしていない取引構造に直面した場合、デバイスは依然として盲目署名モードに戻らざるを得ないことを意味する。これこそが、EIP-712が登場してから何年も経った今でも、実際の利用シーンの多くで盲目署名が本当の意味で姿を消していない理由だ。
ハードウェアウォレットのベンダーは、取引内容を解析できるかどうかに応じて3つの署名レベルを構築した——盲目署名（まったく解析できず、生のハッシュ値や16進数文字列のみを表示）、透過署名（完全な技術フィールドは表示されるが、コントラクトアドレスや関数セレクタなどユーザーには理解しづらい技術的詳細で埋め尽くされている）、そして明瞭署名（クリアサイニング、デバイスが取引の実際の意図を正しく解析し明確に表示する——例えば「0x1234...へ100 USDCを送金」と直接表示する）。この3つのレベルの違いは、本質的にデバイス側が対応するディスクリプタのデータベースを持っているかどうかに帰着する。
特筆すべきは、デバイスが明瞭署名に対応し画面が明確でわかりやすい内容を表示していたとしても、それがユーザーの目にする内容が真実であることを保証するわけではないという点だ。デバイスが表示する「解析結果」は何らかのソフトウェアによって計算されており、その表示内容を生成する責任を負うソフトウェア自体が侵害されていれば（例えば改ざんされたウォレット管理インターフェース）、デバイスが忠実に表示するのは改ざんされた偽りの姿になる。一方でオンチェーンで見える署名自体は完全に有効なものとして扱われる。これこそが、近年業界がERC-7730のような「構造化データ明瞭署名フォーマット」規格の推進を始めた理由だ。ディスクリプタの生成と検証プロセスを非中央集権化・標準化することで、より多くのコントラクト種別をより早く明瞭署名の対象範囲に含めようとしているが、これは依然として進行中の業界全体の課題である。
ハードウェアウォレットで取引に署名する際、画面に理解できない16進数データの文字列が表示されたら、それは明確な盲目署名の警告サインであり、特に金額が大きい場合や不慣れなコントラクトの場合には、操作を一時停止し、まず取引シミュレーションツール（主流のソフトウェアウォレットの多くにすでに内蔵されている）で「この取引に署名すると実際に自分の資産に何が起きるか」を確認してから、署名するかどうかを判断する価値がある。しかしそれ以上に重要なのは、たとえ画面が明確で読みやすい明瞭署名の内容を表示していたとしても、それだけで万全とは言えないということを覚えておくことだ——その「明確で読みやすい」結果自体も、改ざんされうる何らかのソフトウェアによって計算されたものだからだ。
特に金額の大きな操作については、主要な署名インターフェースとは完全に独立した情報源（ブロックチェーンエクスプローラーのデコードツールなど）を使って取引の生の呼び出しデータを追加で確認する習慣をつける価値がある。単一の画面に表示された内容だけを見て確認ボタンを押すのではなく。この習慣さえ身につければ、盲目署名のリスク（生データが読めない）と、より高度なインターフェース偽装のリスク（読めるが内容が偽物）の両方を同時に防ぐことができ、現在業界で比較的現実的な自己防衛策として認識されている。
2025年2月のBybit事件は、盲目署名リスクの最も代表的な事例だ。マルチシグウォレットの取引承認を担当する3人の署名者は、インターフェースに表示された内容が3万ETHの日常的な送金であるように見え、送金先アドレスと取引の説明も一見まったく正常で、技術的には有効な「明瞭」な表示だった。署名者は会社の規定に従い画面の内容を確認し署名を完了させた。しかしこの表示インターフェース自体は、攻撃者によるサプライチェーン攻撃を通じてすでに悪意あるコードが注入され改ざんされていた。3人の署名者が実際にオンチェーンで署名していた内容は、マルチシグウォレット全体のロジックコントラクトを攻撃者がデプロイした悪意あるコントラクトに置き換えるものであり、最終的に15億ドルを超える資産が盗まれ、仮想通貨史上最大の単独窃盗事件となった。この事件は、デバイスやインターフェースが明瞭署名に対応していたとしても、表示内容を生成する責任を負うソフトウェア自体が侵害されている限り、「明確で読みやすい」こと自体が周到に偽造された幻影でありうることを証明した。