なぜ一部のブロックチェーンは署名内容を隠すのか

ハードウェアウォレットで暗号資産の取引を承認するとき、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）により、業界でも最先端のクリアサイニングを実現しています。各取引はパレットとコールインデックスを参照し、メタデータがその意味や引数の解読方法を示します。ただし、完全なメタデータは200KBを超え、メモリの限られたハードウェアウォレットでは扱いが難しいのが課題です。 

この課題に対し、RFC-0078（Merkleized Metadata）という解決策が導入されました。メタデータから暗号学的な木構造を生成し、必要な部分だけを送信、インクルージョン証明をオンチェーンで検証します。これにより、Polkadotのパラチェーン全体で単一のLedgerアプリが利用でき、チェーンごとの個別更新が不要になりました。
 

Cosmosは型付きメッセージ構造と、SIGN_MODE_TEXTUAL標準（ADR-050）を採用。Cosmos SDK v0.50以降、取引内容を小型画面向けに人間が読める形で表示できます。コイン数量も「2 ATOM」のように分かりやすく表示されます。NEAR Protocolはさらに進んで、人間が読めるアカウント名（例：alice.near）や、JSON形式の関数引数をそのままウォレット画面に表示できる仕組みを備えています。
 

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

この層の6つのエコシステムは、ネイティブ操作に関してはクリアサイニングが可能ですが、スマートコントラクトなど複雑な取引になると一気に不透明になります。代表例がBitcoinです。UTXOモデルでは、元々の取引データに入力額が含まれず、手数料計算には過去の出力情報が必要です。PSBT（BIP 174）で標準支払いの約90%は解決できますが、Taprootスクリプトや複雑なマルチシグでは依然として不透明な部分が残ります。
 

StellarはこのTier 2の特徴が顕著です。26種類のクラシック操作（Payment, ManageSellOffer, ChangeTrustなど）はスキーマが固定され、ハードウェアウォレットでも美しく表示されます。しかし2024年開始のSorobanスマートコントラクトでは、EVM型の不透明さが再び登場し、パラメータがバイナリでエンコードされ、コントラクト固有の知識がないと解読できません。そのため、クラシック操作では約95%がクリアサイニング対応でも、Sorobanではほぼゼロに落ちます。Algorand、Cardano、Aptos、Tezosも同様で、ネイティブ操作は強いものの、複雑なロジックではギャップがあります。
 

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

この層の3つのエコシステムは、設計上クリアサイニングが非常に困難です。どれだけウォレットソフトが優秀でも限界があります。なぜDeFiの多くで「ブラインドサイニング注意」の警告が表示されるか、その理由がここにあります。
 

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

業界の対応策としてERC-7730というメタデータ標準（2024年策定）が登場しました。これは各コントラクト操作の解読・表示方法をJSONファイルで定義し、ウォレットが人間向けに内容を表示できるようにするものです。ただし、すべてのコントラクトごとに誰かがこのメタデータを作成・維持する必要があり、根本的には「透明性を前提としない設計」への後付けパッチです。
 

Solanaはさらに難易度が高いと言えます。取引命令にはプログラムIDとバイト配列が含まれますが、標準化されたABIがなく、各プログラムが独自のシリアライズ形式を採用しています。Anchorフレームワークは8バイトの識別子を使う半標準方式を提供しますが、多くのプログラムはAnchorを使わず、インターフェース定義も公開されていません。DeFi操作の大半でブラインドサイニングが必要です。

TONは非同期実行によりさらに複雑です。署名は最初のメッセージだけで、後続ブロックで何が起きるかは署名時点では見えません。

 まとめ

実用的なポイントは、「自分が使うチェーンがどのTierか」を理解した上でDeFi用途にハードウェアウォレットを使うことです。Tier 1のチェーンならクリアサイニングが機能します。Tier 2はシンプルな送金なら安心して署名できますが、複雑なスマートコントラクト操作は事前に調べるべきです。Tier 3では、DeFiプロトコル上の全取引を慎重に扱い、dAppとウォレットの組み合わせがERC-7730メタデータ対応か必ず確認しましょう。
 

ハードウェアウォレット各社もこの課題に積極的に取り組んでいます。LedgerのGeneric ParserはERC-7730メタデータを読み取り、取引内容を安全な画面に表示します。

PolkadotのMerkleized Metadata方式は、業界でも最も洗練された解決策といえます。信頼不要・暗号学的検証・プロトコルネイティブで実現されています。業界全体がより良い標準化へ進んでいますが、Tier 3チェーンの根本的な制約はすぐには解消されません。
 

シンプルなルールとして、「ウォレット画面にハッシュや16進数の文字列しか出ない場合は、危険信号」と考えてください。

参考・関連リンク

本記事で紹介したプロトコルや標準仕様の詳細は、以下の公式リソースをご参照ください。