なぜ一部のブロックチェーンは「署名内容」を見せてくれるのか？その理由と違い

Tier 1：設計段階から「見える化」— 取引意図が読み取れる

クリアサイニングを「後付けの外部ツール」ではなく、プロトコル設計そのものに組み込んでいる4つのエコシステムが際立っています。

XRP Ledger

XRP Ledgerは、主要ブロックチェーンの中でもっともクリアサイニングに優れた設計です。約50種類以上の取引タイプ（Payment、OfferCreate、TrustSet、EscrowCreate、NFTokenMintなど）を持ち、それぞれが名前付き・型付きフィールドで完全に定義されています。

バイナリフォーマット自体が自己記述型で、TransactionTypeフィールドによって解析が完全に決定的となり、全フィールドのスキーマはrippledソースコードの定義ファイルで管理されています。

ハードウェアウォレットは、すべての既知取引タイプの全フィールド（送金先・金額・通貨・発行者・手数料・メモ・タイプ固有パラメータ）を表示できます。アカウントベースモデルなので金額は明示的（UTXOの複雑さなし）、手数料も単一フィールドで計算も明快です。

現行メインネット取引のほぼ100%が完全なクリアサイニングに対応。唯一のリスクは、新しい取引タイプ（VaultやLoanなど）がプロトコルアップデートで追加された場合、ウォレットアプリの更新が必要になる点で、未知タイプはブラインド署名となります。
 

Polkadot / Substrate

Polkadotは、業界でもっとも高度なクリアサイニングソリューションを開発しています。ランタイムメタデータ（MetadataV14/V15）により、すべてのパレット（モジュール）、コール、データ型の完全な型情報レジストリを提供します。

各取引（extrinsic）はpallet_index || call_index || encoded_argumentsという構造で、メタデータが各インデックスの意味や引数のデコード方法を示します。

課題は、完全なメタデータが200KB超と大きく、RAMが約64KBのハードウェアウォレットでは扱えないことでした。RFC-0078（Merkleized Metadata）によって、必要な型情報のみをMerkleツリーで分割・証明付きで送信することで解決しています。

メタデータハッシュはCheckMetadataHash署名拡張でオンチェーン検証され、信頼性が担保されます。これにより、すべてのPolkadotパラチェーン・リレーチェーンで単一のLedgerアプリが動作し、チェーンごとの更新も不要です。

この仕組みはランタイムアップグレード時も柔軟に対応し、コールインデックスが変わっても新しいメタデータと証明で正確な署名を維持します。

Cosmos / Tendermint

Cosmos/Tendermintチェーンは、各取引が1つ以上のsdk.Msgオブジェクト（Protobufのgoogle.protobuf.Anyでラップされ、type_urlでメッセージタイプを識別）を含む「型付きメッセージアーキテクチャ」を持つのが特徴です。
標準メッセージ（MsgSend、MsgDelegate、MsgVoteなど）はスキーマが明確です。

専用のクリアサイニング方式としてSIGN_MODE_TEXTUAL（ADR-050）がCosmos SDK v0.50から導入され、40文字程度の画面単位で取引内容を表示します。value renderersによって「2 ATOM」やbech32アドレス、RFC3339形式のタイムスタンプなど、人間に読みやすい形に変換されます。

開発者は独自メッセージ用にカスタムレンダラーも提供でき、（フォーマットとパースが完全に可逆であることが条件）署名ペイロードにはテキスト表現と生バイトのハッシュが含まれ、セキュリティも確保されます。

NEAR Protocol

NEAR Protocolは、人間の可読性を重視した設計でクリアサイニングを実現しています。アカウントIDは「alice.near」のような人間が読める名前で、16進アドレスではありません。

取引には型付きAction列挙型（Transfer、Stake、FunctionCall、AddKey等）が必ず含まれます。特にFunctionCallアクションは、メソッド名（例：「transfer」「set_greeting」）と引数（デフォルトでJSONシリアライズ）をプレーンテキストで持ちます。

ハードウェアウォレットは「app.defi.nearでswapメソッドを呼び出し、args: {amount: 1000, token: 'usdc.near'}」のように表示でき、セレクタ方式より圧倒的に分かりやすいです。唯一の制約は、一部コントラクトがガス効率のためBorshシリアライズ引数を使う場合、スキーマがなければ不透明になる点です。

Tier 2：条件付きクリアサイニング — 基本操作は見えるが、スマートコントラクトで不透明化

基盤レイヤーの操作はクリアサイニングが可能ですが、汎用プログラマビリティが加わると可視性が大きく低下します。

Bitcoin

Bitcoinは独特の位置づけで、スマートコントラクトがなくても取引モデル自体がクリアサイニングの課題を生みます。UTXOモデルでは、取引データに入力金額が含まれておらず、入力は過去の出力（トランザクションハッシュ＋インデックス）を参照するのみで、その価値は明示されません。

この情報がないと、ハードウェアウォレットは手数料（総入力−総出力）を計算できず、過払いリスクの検証もできません。PSBT（BIP 174）は、未署名取引にUTXOメタデータとBIP32派生パスを付与することでこの課題を解決します。

PSBTにより、標準的な送金では受取アドレス・金額・手数料を明確に表示でき、全体の約90%をカバーします。ただし、マルチシグやタイムロック、Taprootスクリプトパスなど複雑なケースでは、P2SH/P2WSHが任意スクリプトをハッシュ化し、TaprootのMAST構造で代替条件が見えなくなります。

Aptos

AptosはMoveの強力な型システムとオンチェーンABIにより恩恵を受けています。取引ペイロードには0x1::aptos_account::transferのような完全修飾関数ID、モジュールアドレス・モジュール名・関数名が明示されます。

SDKはオンチェーンABIを参照してBCSエンコード引数をデシリアライズでき、ウォレットは「0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000)」のように表示可能です。

ただし、BCS（Binary Canonical Serialization）は自己記述型ではなく、ABIスキーマがなければ生バイトは解読不能です。スクリプトペイロード（任意Moveバイトコード）は構造化エントリ関数形式を完全にバイパスします。Ledger Aptosアプリには複雑取引用の「Enable Blind Signing」設定があり、単純操作と複雑操作のギャップを示しています。

Stellar

Tier-2の典型例です。26種類のクラシック操作（Payment、ChangeTrust、ManageSellOffer等）は固定スキーマで完全に解析可能。Ledgerアプリでは操作タイプ・金額・送金先・資産・メモ・手数料をステップごとに表示し、クラシック操作の約95%をカバーします。

• Sorobanスマートコントラクト（2024年開始）は、Ethereum同様の不透明性を再導入します。InvokeHostFunction操作でコントラクトアドレスやパラメータがScVal型でエンコードされ、コントラクト固有知識がなければ解読できません。外部メタデータなしではクリアサイニングはほぼ不可能です。

Algorand

7種類の型付き取引（Payment、Asset Transfer、Asset Configuration、Key Registration、Application Call、Asset Freeze、State Proof）はすべてMessagePackエンコードで解析可能。ARC-4 ABI標準に準拠したスマートコントラクトはメソッド署名・パラメータ名・説明も提供されます。

• 非ARC-4コントラクトは引数が不透明です。
• すべてのスマートコントラクトは最大256個の内部取引（8階層までのネスト）を生成可能で、署名時には完全に不可視です。

Cardano & Tezos

CardanoのeUTXOモデルは、単純取引で入力・出力・手数料・マルチアセット値を明示表示できますが、Plutusスクリプトは任意のCBORエンコードデータ（datum/redeemer）を扱い、標準的な人間向けスキーマが存在しません。CIP-21でも「最大限の柔軟性と引き換えに、ユーザーが誤認するリスクがある」と明記されています。

Tezosは構造的に優位で、コントラクトパラメータ型がオンチェーン保存され、エントリポイントもハッシュではなく文字列名を使うため、セレクタ衝突問題がありません。ただし、Michelineバイナリエンコードは型スキーマがなければ完全解析できず、Ledger Tezosアプリも複雑パラメータの表示は限定的です。

❌ 設計上「不透明」— クリアサイニングは困難

根本的な設計選択（ツールの問題ではない）が、クリアサイニングを本質的に難しくしています。外部メタデータ層は一部助けになりますが、設計自体の壁は越えられません。

Ethereum / EVMチェーン

もっとも有名かつ研究されている例です。ユーザーがスマートコントラクトとやり取りする際、取引データフィールドには4バイトのファンクションセレクタ（関数シグネチャのkeccak256先頭4バイト）＋32バイト単位のABIエンコードパラメータが格納されます。コントラクトのABI JSONがオンチェーンに保存されていないため、これは純粋な16進数ノイズです。ハードウェアウォレットが0xa9059cbb000...03e8を見ても「0xABC...へ1000トークン送金」とは分かりません。

さらにEVM特有の課題が重なります：

• ファンクションセレクタ衝突： 4byte.directoryには約100万件のシグネチャが登録されており、32ビット空間のバースデー問題を超えています。異なる関数が同じセレクタになることも。
• プロキシコントラクト： delegatecallによる実装コントラクトへのルーティングで、アドレスがいつでも変更可能。Bybitハックもこのギャップを突かれました。
• マルチコールパターン： ABIエンコードデータをパラメータにネストし、再帰的デコードが必要。
• EIP-712： オフチェーンメッセージ（許可、注文等）の可読性は向上しますが、オンチェーン取引の不透明性は解消しません。

Solana

クリアサイニングが最も難しい設計の一つです。取引命令はprogram_id・アカウントリスト・命令データ（不透明なバイト配列）で構成され、標準ABIは存在しません。AnchorフレームワークはSHA-256で8バイト識別子を生成する半標準方式を提供しますが、あくまで慣習でありプロトコル要件ではありません。多くのプログラムはAnchor非対応・IDL未公開です。

• バージョン付き取引のアドレスルックアップテーブルは、32バイトアドレスを1バイトインデックスに圧縮しますが、ウォレットはオンチェーンアクセスがないため内容を検証できません。Solana公式ドキュメントでもこの点を明記しています。
• クロスプログラム呼び出し（CPI）チェーンは署名時に不可視です。
• 単純なSOL送金やSPLトークン操作はLedgerで解析可能ですが、DeFi取引など大半の取引はブラインド署名が事実上必須です。

TON

複数の設計要素が独立してクリアサイニングを妨げており、組み合わせるとさらに困難です：

• Cellベースデータ構造： すべてのデータがセル（最大1023ビット＋4参照）でツリー状に表現され、単一セルを超えるメッセージは再帰的なツリー走査が必要です。
• TL-Bエンコード： ビット単位で複雑なコンストラクタ・再帰参照を扱い、バイトアライン形式よりもハードウェアでの解析が難しいです。
• 標準ABIなし： 32ビットopcodeは慣習であり、プロトコル強制ではありません。
• 非同期実行： 1回のユーザー操作で複数コントラクト・シャードに連鎖的な内部メッセージが発生します。ユーザーは最初の外部メッセージしか署名せず、その先は不可視・予測不能です。

Sui（番外）

Aptos同様Moveの型システムを持ち、命令レベルでは助けになりますが、SuiのProgrammable Transaction Blocks（PTB）は最大1,024コマンドを含み、コマンド間でデータ依存関係が生じます。複数ステップのPTB全体をウォレット画面で意味ある形で表示するのは極めて困難で、全コマンド列の解析が必要です。