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

ハードウェアウォレットで仮想通貨のトランザクションを承認する際、実際には2つのうちどちらかの行為をしています。ひとつは、これから実行される内容がわかる日本語の要約を読み、内容を確認して承認する場合。もうひとつは、16進数のコードが並ぶ画面を見て、内容が分からないまま承認する場合です。後者のように、内容を人間が読める形で確認できないままデジタル署名を承認する行為を「ブラインド署名」と呼びます。
 

  In February 2025, blind signing contributed to the  $1.5 billion Bybit hack , the largest crypto theft in history. The attackers didn't break any cryptography. They exploited the fact that human signers couldn't distinguish a routine transfer from a malicious contract upgrade.   Whether your wallet can show you a clear, readable summary before you sign isn't a question of software quality. It comes down to how each blockchain was designed at the protocol level. Some chains were built so that transactions describe themselves. Others hide critical details inside binary blobs that require external information to decode. This article explains how those design decisions break down across the major blockchains and what it means for your security.   The Three-Tier Framework Clear Signing is a security process that lets you verify the full details of a digital transaction in a human-readable format on a secure screen before approving it.  Across 13 major blockchain ecosystems, clear signing support falls into three distinct tiers based on protocol architecture. This isn't about which chains are good or bad, it's about design tradeoffs made years ago, often before the security implications were fully understood.     Tier 1: Built for Transparency These blockchains make clear that signing is a natural outcome of their design. The core reason: they use a finite set of typed transaction structures where every field has a name, a type, and a defined schema. A hardware wallet doesn't need any external information to parse them, the transaction tells you what it is.   The

三層構造のフレームワーク

クリア署名とは、トランザクションの詳細を人間が読める形式で安全な画面に表示し、内容を確認してから承認できるセキュリティプロセスです。 

主要な13のブロックチェーンエコシステムでは、クリア署名の対応状況はプロトコル設計に基づき3つの層（ティア）に分かれます。どのチェーンが優れている・劣っているという話ではなく、数年前に行われた設計上のトレードオフ（多くは当時、セキュリティへの影響が十分に理解されていなかった）によるものです。

Tier 1：透明性重視の設計

この層のブロックチェーンは、署名内容が明確に分かる設計になっています。主な理由は、各トランザクションが型付き構造体として定義され、すべてのフィールドに名前・型・スキーマが設定されているためです。ハードウェアウォレットは外部情報なしで内容を解析でき、トランザクション自体が「何をするのか」を明示します。

The XRP Ledger は、主要チェーンの中でも最もクリア署名の実現度が高い例です。独自のバイナリフォーマットにはTransactionTypeフィールドがあり、50種類以上のトランザクションタイプ（Payment、OfferCreate、TrustSet、EscrowCreateなど）を決定論的に解析できます。すべてのフィールドがスキーマ化されており、ハードウェアウォレットは宛先、金額、手数料、メモ、タイプ固有のパラメータも外部参照なしで表示可能です。現行メインネットのほぼ100%のトランザクションが完全にクリア署名できます。

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

この課題を解決するのが、RFC-0078（Merkleized Metadata）です。メタデータから暗号ツリーを構築し、必要な部分だけを転送してオンチェーンで検証します。これにより、Polkadotの全パラチェーンで単一のLedgerアプリが利用でき、チェーンごとの個別アップデートが不要になりました。
 

Cosmosは型付きメッセージ構造とSIGN_MODE_TEXTUAL標準（ADR-050）を採用し、トランザクション内容を小型画面でも読みやすい日本語表示に変換します。コイン数量も「2 ATOM」のように表示され、「2000000uatom」のような難解な単位は使いません。NEAR Protocolはさらに進んで、人間が読めるアカウント名や、JSON形式でシリアライズされた関数引数をそのままウォレット画面に表示できる仕組みも導入しています。
 

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

この層の6つのエコシステムは、ネイティブ操作に関してはクリア署名が可能ですが、スマートコントラクトが絡むと一気に不透明性が増します。代表例がBitcoinです。UTXOモデルでは生のトランザクションに「入力額」が含まれず、ハードウェアウォレットは手数料計算のために過去出力の追加情報が必要です。PSBT（BIP 174）によって標準的な送金の約90%はカバーされますが、Taprootのscript-path支払いや複雑なマルチシグ構成では依然として不透明さが残ります。
 

StellarはこのTier 2の特徴が最も顕著です。従来型の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...へ送金」という意味だと、外部メタデータがなければハードウェアウォレットには分かりません。
Proxy contracts, which route execution to implementation contracts whose addresses can change, compound the problem, which is exactly how the Bybit hack was executed.
 

業界の対応策がERC-7730です。2024年に策定されたこのメタデータ標準は、スマートコントラクトのやり取りをハードウェアウォレットで人間が読める形に変換するためのJSONファイル仕様です。ただし、すべてのコントラクトごとにこのメタデータを用意・保守する必要があり、根本的には「透明性を前提としない設計」へのパッチ的な対応に過ぎません。
 

Solanaはさらに難易度が高いと言えます。トランザクション命令にはプログラムIDと不透明なバイト配列が含まれ、標準化されたABIが存在しません。各プログラムが独自のシリアライズ形式を持ち、Anchorフレームワークは8バイトの識別子を使う半標準的な手法ですが、Anchor非対応やインターフェース未公開のプログラムも多いです。DeFi利用時、Solanaの大半のトランザクションはブラインド署名が必要となります。

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

 まとめと注意点

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

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

PolkadotのMerkleized Metadata方式は、業界でも最も洗練されたソリューションの一つです。信頼不要かつ暗号的に検証可能、プロトコルネイティブな仕組みです。業界全体として標準化は進んでいますが、Tier 3チェーンのプロトコル制約自体は今後も残り続けるでしょう。
 

シンプルなルールとして、「ウォレット画面にハッシュや16進数の羅列しか表示されず、内容が分からないまま署名を求められた場合は、必ず注意信号と考えてください」。

参考リンク・追加資料

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