なぜ一部のブロックチェーンは「何に署名するか」を隠すのか

ハードウェアウォレットで仮想通貨のトランザクションを承認するとき、実際には2つのうちどちらかを行っています。1つは「これから何が起きるか」を日本語でわかりやすく確認してから署名する場合、もう1つは16進数のコードの羅列に署名し、内容が分からないまま進める場合です。後者のように、内容を人間が読める形で確認できないままデジタル署名する行為は「ブラインドサイニング」と呼ばれます。
 

2025年2月、ブラインドサイニングが $1.5 billion Bybit hack（史上最大規模の暗号資産流出事件）を引き起こす一因となりました。攻撃者は暗号技術を破ったわけではなく、署名者が通常の送金と悪意あるコントラクトのアップグレードを見分けられない点を突きました。
 

ウォレットが署名前に分かりやすい日本語の要約を表示できるかどうかは、ソフトウェアの品質ではなく、各ブロックチェーンのプロトコル設計に依存します。トランザクション自体が内容を説明する設計のチェーンもあれば、重要な情報をバイナリデータとして隠し、外部情報がなければ解読できないチェーンもあります。本記事では、こうした設計の違いが主要ブロックチェーンでどのように現れ、ユーザーのセキュリティにどう影響するかを解説します。

三層フレームワークとは

クリアサイニングとは、デジタルトランザクションの全内容を人間が読める形で安全な画面に表示し、承認前に確認できるセキュリティ手法です。 

主要な13のブロックチェーンでは、クリアサイニング対応状況がプロトコル設計により3つの層（Tier）に分かれます。これは「どのチェーンが優れているか」ではなく、数年前に下された設計上のトレードオフが、セキュリティ面でどのように影響しているかを示しています。

Tier 1：透明性重視の設計

この層のブロックチェーンは、署名内容が分かりやすく表示できるよう最初から設計されています。理由は、各トランザクションが型付きで構造化されており、すべての項目に名前・型・スキーマが定義されているためです。ハードウェアウォレットは外部情報なしで内容を解析でき、何に署名しているかを明確に表示できます。

 XRP Ledgerは、主要チェーンの中でも最も明確なクリアサイニングを実現しています。バイナリ形式にTransactionTypeフィールドが含まれ、50種類以上のトランザクションタイプ（Payment、OfferCreate、TrustSet、EscrowCreateなど）を判別できます。すべての項目がスキーマで定義されており、受取人・金額・手数料・メモ・タイプ固有のパラメータまで、外部参照不要でウォレット画面に表示可能です。現在のメインネット取引のほぼ100%が完全なクリアサイニングに対応しています。

Polkadotは、 ランタイムメタデータシステム（MetadataV14/V15）によって業界で最も高度なクリアサイニングを実現しています。各トランザクションはpalletとcallのインデックスを参照し、メタデータがその意味と引数の解釈方法を示します。ただし、完全なメタデータは200KB以上となり、メモリ制限のあるハードウェアウォレットには大きすぎる課題がありました。 

この課題に対し、 RFC-0078（Merkleized Metadata）という解決策が登場しました。メタデータから暗号学的な木構造を作り、必要な部分だけを送信し、オンチェーンで証明を検証します。これにより、1つのLedgerアプリで全Polkadotパラチェーンに対応できるようになりました。
 

Cosmosは型付きメッセージアーキテクチャと、 SIGN_MODE_TEXTUAL標準（ADR-050）を採用。Cosmos SDK v0.50以降では、トランザクション内容を小型画面でも読みやすい日本語表示に変換します（例：「2 ATOM」など）。NEAR Protocolはさらに進んで、 人間が読めるアカウント名や、JSON形式の引数をウォレット画面にテキスト表示できる仕組みを持っています。
 

Tier 2：基本操作は明瞭、複雑化で不透明に

この層の6つのエコシステムは、ネイティブ操作ではクリアサイニングに対応していますが、スマートコントラクトが絡むと一気に不透明になります。典型例がBitcoinです。UTXOモデルでは、トランザクションに入力額が含まれず、ハードウェアウォレットは過去出力の追加情報がなければ手数料を計算できません。 PSBT（BIP 174）で標準送金の約90%は解決できますが、Taprootスクリプトや複雑なマルチシグでは依然として不透明さが残ります。
 

StellarはこのTier2の特徴が最も顕著です。従来型の26種類のオペレーション（Payment、ManageSellOffer、ChangeTrustなど）は固定スキーマで、美しくウォレット画面に表示されます。しかし、2024年導入のSorobanスマートコントラクトではEVM型の不透明性が再登場し、パラメータがバイナリ型でエンコードされるため、コントラクトごとの知識がなければ解読できません。従来操作の約95%はクリアサイニング対応ですが、Sorobanではほぼ対応不可となります。Algorand、Cardano、Aptos、Tezosも同様で、ネイティブ操作は強力ですが、複雑なプログラマブルロジックでは大きなギャップが生じます。
 

Tier 3：不透明さが設計に組み込まれている

この層の3つのエコシステムは、どれだけウォレットソフトが優秀でもクリアサイニングが困難な設計上の特徴を持っています。この理由を理解することは、多くのDeFiインターフェースでブラインドサイニング警告が表示される背景でもあります。
 

Ethereumおよび全EVM互換チェーンは、ABIエンコーディングが自己記述型でないという根本的な課題を共有しています。スマートコントラクトとやり取りする際、トランザクションデータフィールドには4バイトの関数セレクタ（関数名のハッシュ先頭4バイト）と、32バイト単位でエンコードされたパラメータが格納されます。コントラクトのABI（JSON）がなければ、これは単なる16進数のノイズです。しかもABIはオンチェーン保存されません。ウォレットは外部メタデータがなければ「0xa9059cbb...」が「1,000 USDCを0xABC...へ送金」という意味だと判別できません。
さらに、プロキシコントラクト（実装コントラクトへの実行委託でアドレスが変わる）が問題を複雑化させ、Bybitハッキングもまさにこの仕組みが悪用されました。
 

業界がこれに対して進めているのが、 ERC-7730という2024年制定のメタデータ標準です。これは、各コントラクトの関数を人間が読めるラベルや形式にマッピングするJSONファイルを定義し、ウォレットが内容を判別できるようにします。ただし、すべてのコントラクトごとにこのメタデータを作成・維持する必要があり、根本的には透明性のための「後付けパッチ」に過ぎません。
 

Solanaはさらに難易度が高い例です。トランザクション命令にはプログラムIDと命令データ（バイト配列）が含まれますが、標準化されたABIがなく、各プログラムが独自のシリアライズ形式を定義します。Anchorフレームワークは8バイトのディスクリミネータによる準標準的な手法を提供しますが、すべてのプログラムがAnchorを採用しているわけではなく、インターフェース定義も公開されていません。DeFi関連ではSolanaトランザクションの大半がブラインドサイニングとなります。

TONは非同期実行という複雑さも加わります。署名時点では最初のメッセージしか確認できず、その後のブロックで何が起きるかは見えません。

 まとめと注意点

実用的なポイントは、「自分が使うチェーンがどのTierか」を理解したうえでDeFi利用時にハードウェアウォレットを使うことです。Tier 1チェーンならクリアサイニングが期待通りに機能します。Tier 2では単純な送金は安心して署名できますが、複雑なスマートコントラクト操作は必ず事前に調べてください。Tier 3では、DeFiプロトコル上のすべてのトランザクションに追加の警戒心を持ち、dAppとウォレットがERC-7730メタデータに対応しているか確認してから重要な操作を承認しましょう。
 

ハードウェアウォレットメーカーもこの課題に積極的に取り組んでいます。LedgerのGeneric ParserはERC-7730メタデータファイルを読み取り、安全な画面でトランザクション詳細を表示します。

PolkadotのMerkleized Metadata方式は、業界で最も洗練されたソリューションの1つであり、信頼不要・暗号学的検証・プロトコルネイティブです。業界全体がより良い標準化に進んでいますが、Tier 3チェーンの設計上の制約はすぐには解消されません。
 

シンプルなルールとして、「ウォレット画面にハッシュや16進数の羅列しか表示されない場合は、必ず警戒してください。」

参考リンク・追加リソース

本記事で取り上げたプロトコルや標準仕様について、より詳しく知りたい方は以下をご参照ください。