Warum manche Blockchains zeigen, was du signierst (und andere nicht)
Warum dir deine Wallet nicht immer zeigt, was du signierst – und welche Blockchains daran schuld sind.
Dieser Artikel ist in folgenden Sprachen verfügbar:
Zentrale Erkenntnisse
Clear Signing beschreibt die Fähigkeit von Hardware-Wallets, alle relevanten Transaktionsdetails – wie Empfänger, Betrag, Gebühr und Vertragsfunktion – vor der Freigabe anzuzeigen. Das funktioniert nur, wenn das Blockchain-Protokoll Transaktionen als selbsterklärende, menschenlesbare Strukturen codiert. Blockchains mit begrenzten, typisierten Transaktionsmodellen (wie XRP Ledger, Polkadot, Cosmos und NEAR) ermöglichen Clear Signing von Grund auf, während Blockchains mit undurchsichtigen, binär codierten Smart-Contract-Daten (wie Ethereum, Solana und TON) dies erschweren oder unmöglich machen. Oft sind dann externe Metadaten-Lösungen nötig. Das Fazit: Nicht die Wallet-Software, sondern die Protokollarchitektur entscheidet über Clear Signing – mit echten Sicherheitsfolgen, wie große Hacks durch undurchsichtige Transaktionen zeigen.
Was ist Clear Signing?
Clear Signing bedeutet, dass dir das vertrauenswürdige Display deiner Hardware-Wallet die tatsächlichen Details einer Transaktion anzeigt, bevor du sie freigibst – Empfänger, Betrag, Gebühr und die aufgerufene Vertragsfunktion. Entscheidend ist dabei nicht die Qualität der Wallet-Software, sondern ob das Protokoll der Blockchain Transaktionen als selbsterklärende, typisierte Strukturen oder als undurchsichtige, binäre Datenblöcke codiert, die externe Metadaten zur Interpretation benötigen. Diese Architektur-Entscheidung wird auf Protokollebene getroffen – mit echten Auswirkungen auf die Sicherheit.
⚠️ February 2025: Der 1,5-Milliarden-Dollar-Bybit-Hack – der größte Krypto-Diebstahl aller Zeiten – gelang genau deshalb, weil Hardware-Wallets einen normalen Transfer nicht von einem bösartigen Proxy-Contract-Upgrade unterscheiden konnten. Das Protokoll lieferte keine verwertbaren Informationen.
Warum ermöglichen manche Blockchains Clear Signing leichter?
Um zu verstehen, warum einige Blockchains Clear Signing einfach machen und andere es nahezu unmöglich machen, muss man analysieren, wie jede Blockchain Transaktionen codiert, Smart-Contract-Funktionen identifiziert und programmierbare Logik abbildet.
Die 13 wichtigsten Blockchain-Ökosysteme lassen sich in drei Stufen einteilen, je nachdem, wie ihre Architektur Clear Signing unterstützt. Blockchains mit begrenzten, typisierten Transaktionsmodellen dominieren die oberste Stufe. Blockchains mit universellen Smart Contracts tun sich schwer – je flexibler die Programmierbarkeit, desto schwieriger wird Clear Signing.
- Wie Transaktionen codiert sind: Enthält das Format genug Typinformationen, um sich selbst zu erklären, oder handelt es sich um rohe Binärdaten, die externen Kontext zum Dekodieren benötigen?
- Wie programmierbare Logik funktioniert: Begrenzte, typisierte Operationen sind per Definition lesbar; universelle Smart Contracts mit beliebigen Instruktionsdaten sind es nicht.
Stufe 1: Architektonisch transparent – Transaktionsabsicht ist von Haus aus lesbar
Vier Ökosysteme stechen hervor, weil sie Clear Signing als natürliche Folge ihres Protokolldesigns ermöglichen – und nicht als nachträglichen Zusatz über externe Tools.
XRP Ledger
Der XRP Ledger bietet das klarste Clear-Signing-Konzept unter den großen Blockchains. Die Architektur nutzt einen festen Satz von über 50 benannten Transaktionstypen (Payment, OfferCreate, TrustSet, EscrowCreate, NFTokenMint usw.), jeweils mit vollständig definiertem Schema aus benannten, typisierten Feldern.
Das binäre Format ist selbsterklärend – ein TransactionType-Feld macht das Parsen komplett deterministisch, und das vollständige Feldschema ist in der Definitionsdatei des rippled-Quellcodes gepflegt.
Eine Hardware-Wallet kann jedes Feld jedes bekannten Transaktionstyps anzeigen: Empfänger, Betrag (mit Währung und Herausgeber bei Tokens), Gebühr, Memos und typspezifische Parameter. Das Konto-Modell bedeutet, dass Beträge explizit sind (keine UTXO-Komplexität), und Gebühren sind ein einfaches Feld statt einer impliziten Berechnung.
Nahezu 100 % aller aktuellen Mainnet-Transaktionen können vollständig klar signiert werden. Das einzige Risiko: Neue Transaktionstypen, die per Protokoll-Upgrade hinzugefügt werden (wie Vault- und Loan-Operationen), erfordern Updates der Hardware-Wallet-App; unbekannte Typen führen zu Blind Signing.
Polkadot / Substrate
Polkadot hat die technisch fortschrittlichste Clear-Signing-Lösung der Branche entwickelt. Das Runtime-Metadaten-System (MetadataV14/V15) stellt ein vollständiges, selbsterklärendes Typ-Register für jedes Pallet (Modul), jeden Call und jeden Datentyp zur Verfügung.
Jede Transaktion (Extrinsic) ist als pallet_index || call_index || encoded_arguments strukturiert, und die Metadaten geben exakt an, was diese Indizes bedeuten und wie die Argumente zu dekodieren sind.
Die größte Herausforderung: Die vollständigen Metadaten sind über 200 KB groß – zu viel für Hardware-Wallets mit rund 64 KB RAM. Die Lösung, RFC-0078 (Merkleized Metadata), baut daraus einen Merkle-Baum und überträgt nur den relevanten Ausschnitt (die für die jeweilige Transaktion benötigten Typen) plus einen kryptografischen Nachweis.
Der Metadaten-Hash wird on-chain über die CheckMetadataHash-Signed-Extension verifiziert, wodurch das System vertrauenslos funktioniert. Dadurch kann eine einzige generische Ledger-App auf allen Polkadot-Parachains und Relay Chains laufen – ohne Updates für jede einzelne Chain.
Das System verarbeitet Runtime-Upgrades elegant: Selbst wenn Call-Indizes sich ändern, sorgen frische Metadaten und Nachweise für weiterhin korrekte Signaturen.
Cosmos / Tendermint
Cosmos/Tendermint-Chains profitieren von einer typisierten Nachrichtenarchitektur, bei der jede Transaktion ein oder mehrere sdk.Msg-Objekte enthält, eingebettet in Protobufs google.protobuf.Any, das über das Feld type_url den Nachrichtentyp identifiziert.
Standardnachrichten wie MsgSend, MsgDelegate und MsgVote haben bekannte Schemata.
Die dedizierte Clear-Signing-Lösung des Ökosystems ist SIGN_MODE_TEXTUAL (ADR-050), eingeführt im Cosmos SDK v0.50. Transaktionen werden als Folge von Bildschirmen für kleine Geräte (ca. 40 Zeichen) dargestellt, mit Value Renderers, die Rohdaten in menschenlesbare Formate umwandeln: Coins erscheinen als „2 ATOM“ statt „2000000uatom“, Adressen im bech32-Format, Zeitstempel nach RFC3339.
Entwickler können eigene Renderer für ihre Nachrichtentypen bereitstellen (wobei Format- und Parse-Funktion exakt umkehrbar sein müssen). Die signierte Nutzlast enthält sowohl die Textdarstellung als auch einen Hash der Rohdaten – so bleiben die Sicherheitsgarantien erhalten.
NEAR Protocol
NEAR Protocol erreicht Clear Signing durch mehrere Architekturentscheidungen, die auf Lesbarkeit für Menschen setzen. Konten sind menschenlesbare Namen wie „alice.near“ statt Hex-Adressen.
Transaktionen enthalten typisierte Action-Enums (Transfer, Stake, FunctionCall, AddKey usw.), die immer eindeutig sind. Besonders wichtig: Die FunctionCall-Aktion enthält einen method_name als Klartext (z. B. „transfer“, „set_greeting“) und Argumente, die standardmäßig als JSON serialisiert werden.
Eine Hardware-Wallet kann anzeigen: „Rufe Methode 'swap' auf app.defi.near mit args: {amount: 1000, token: 'usdc.near'} auf.“ Das ist deutlich lesbarer als jedes selector-basierte System. Einzige Einschränkung: Manche Verträge nutzen aus Effizienzgründen Borsh-codierte Argumente, die ohne Schema undurchsichtig sind.
Stufe 2: Bedingt klar – native Operationen funktionieren, Smart Contracts machen Probleme
Gutes Clear Signing für Basis-Transaktionen. Sobald universelle Programmierbarkeit ins Spiel kommt, nimmt die Transparenz deutlich ab.
Bitcoin
Bitcoin nimmt eine Sonderstellung ein: Das Transaktionsmodell erschwert Clear Signing selbst ohne Smart Contracts. Das UTXO-Modell bedeutet, dass Rohtransaktionen keine Input-Beträge enthalten – Inputs verweisen auf frühere Outputs per Transaktions-Hash und Index, aber nicht auf deren Wert.
Ohne diese Information kann eine Hardware-Wallet die Gebühr (Gesamteingänge minus Gesamtausgänge) nicht berechnen oder prüfen, ob sie nicht getäuscht wird. PSBT (BIP 174) löst das Problem, indem unsigned Transactions mit UTXO-Metadaten und BIP32-Derivation für Change-Adressen ergänzt werden.
Mit PSBT können Hardware-Wallets Empfängeradressen, Beträge und Gebühren für Standardzahlungen klar anzeigen – das deckt etwa 90 % der typischen Transaktionen ab. Komplexer wird es bei Multisig-Setups, timelocked Scripts und Taproot Script-Path-Spends – P2SH und P2WSH verstecken beliebige Scripts hinter Hashes, Taproots MAST-Struktur macht alternative Ausgabebedingungen unsichtbar, bis sie genutzt werden.
Aptos
Aptos profitiert vom starken Typsystem von Move und von Onchain-ABIs. Transaktionsdaten enthalten vollqualifizierte Funktionsbezeichner wie 0x1::aptos_account::transfer; Moduladresse, Modulname und Funktionsname sind sichtbar.
Das SDK kann Onchain-ABIs abfragen, um BCS-codierte Argumente zu dekodieren. Eine Hardware-Wallet mit ABI-Zugriff könnte anzeigen: „Rufe 0x1::aptos_account::transfer(recipient: 0xABC..., amount: 1000) auf.“
Allerdings ist BCS (Binary Canonical Serialization) nicht selbsterklärend – ohne das ABI-Schema sind rohe BCS-Bytes nicht interpretierbar. Script-Payloads (beliebiger Move-Bytecode) umgehen das strukturierte Entry-Function-Format komplett. Die Ledger-Aptos-App bietet explizit die Option „Enable Blind Signing“ für komplexe Transaktionen – das bestätigt die Lücke zwischen einfachen und komplexen Vorgängen.
Stellar
Das Muster der zweiten Stufe in Reinform: 26 klassische Operationstypen (Payment, ChangeTrust, ManageSellOffer usw.) haben feste Schemata und sind vollständig auslesbar – die Ledger-App zeigt Operationstyp, Betrag, Ziel, Asset, Memo und Gebühr Schritt für Schritt an. ~95 % Abdeckung für klassische Operationen.
- Soroban-Smart-Contracts (seit 2024) bringen das gleiche Transparenzproblem wie bei Ethereum zurück: Aufrufe kommen als InvokeHostFunction-Operationen mit Vertragsadressen in undurchsichtigem Format und Parametern als ScVal-Typen, die spezifisches Vertragswissen erfordern. Für rohe Soroban-Interaktionen ohne externe Metadaten ist Clear Signing praktisch nicht möglich.
Algorand
Sieben typisierte Transaktionstypen (Payment, Asset Transfer, Asset Configuration, Key Registration, Application Call, Asset Freeze, State Proof) – alle vollständig aus MessagePack codiert auslesbar. Der ARC-4-ABI-Standard liefert Methodensignaturen, Parameternamen und Beschreibungen für kompatible Smart Contracts.
- Nicht-ARC-4-Verträge haben undurchsichtige Argumente.
- Alle Smart Contracts können bis zu 256 innere Transaktionen erzeugen – inklusive verschachtelter Aufrufe bis zu 8 Ebenen tief – die beim Signieren komplett unsichtbar bleiben.
Cardano & Tezos
Das eUTXO-Modell von Cardano erlaubt bei einfachen Transaktionen die klare Anzeige von Inputs, Outputs, Gebühren und Multi-Asset-Werten. Plutus-Script-Interaktionen hingegen nutzen Datums und Redeemers, die als beliebige CBOR-codierte Datenstrukturen ohne Standard-Schema vorliegen – menschliche Interpretation ist nicht möglich. CIP-21 betont explizit, dass der Plutus-Modus „maximale Flexibilität auf Kosten der Nutzertransparenz“ anstrebt.
Tezos hat einen strukturellen Vorteil: Vertragstypen werden on-chain gespeichert, und Entry-Points nutzen String-Namen statt hashbasierter Selektoren – das eliminiert das Kollisionsproblem. Aber auch hier erfordert die binäre Micheline-Codierung das Vertragsschema für vollständiges Decoding, und die Ledger-Tezos-App zeigt komplexe Parameter nur eingeschränkt an.
❌ Architektonisch undurchsichtig – Clear Signing bleibt eine Herausforderung
Grundlegende Architekturentscheidungen – nicht fehlende Tools – machen Clear Signing hier von Haus aus schwierig. Externe Metadaten-Layer helfen am Rand, beheben aber nicht das Grundproblem.
Ethereum / EVM-Chains
Das prominenteste und am meisten untersuchte Beispiel: Interagiert ein Nutzer mit einem Smart Contract, enthält das Datenfeld der Transaktion einen 4-Byte-Function-Selector (die ersten 4 Bytes von keccak256 der Funktionssignatur), gefolgt von ABI-codierten Parametern in 32-Byte-Blöcken. Ohne das ABI-JSON des Vertrags – das nicht on-chain gespeichert wird – ist das reine Hex-Zeichenkette. Eine Hardware-Wallet, die 0xa9059cbb000...03e8 sieht, kann ohne externe Metadaten nicht erkennen, dass das „Transfer 1000 Tokens an 0xABC...“ bedeutet.
Die Herausforderungen werden durch typische EVM-Muster noch verschärft:
- Function Selector Collisions: Die 4byte.directory-Datenbank enthält fast eine Million Signaturen – weit über der Kollisionsschwelle für einen 32-Bit-Raum. Unterschiedliche Funktionen können identische Selector erzeugen.
- Proxy Contracts: Die Ausführung wird per delegatecall an Implementierungsverträge weitergeleitet, deren Adressen sich jederzeit ändern können. Genau diese Lücke wurde beim Bybit-Hack ausgenutzt.
- Multicall Patterns: ABI-codierte Calldata wird in Parametern verschachtelt, was rekursives Decoding erfordert.
- EIP-712: Verbessert die Lesbarkeit für Off-Chain-Nachrichten (Permits, Orders), ändert aber nichts an der On-Chain-Transparenz.
Solana
Vermutlich die herausforderndste Architektur für Clear Signing. Transaktionsanweisungen enthalten eine program_id, eine Kontenliste und ein undurchsichtiges Byte-Array mit Instruktionsdaten. Es gibt kein standardisiertes ABI – jedes Programm definiert sein eigenes Serialisierungsformat. Das Anchor-Framework bietet einen halbstandardisierten Ansatz (8-Byte-Discriminators aus SHA-256 des Instruktionsnamens), aber das ist eine Framework-Konvention, keine Protokollvorgabe. Viele Programme nutzen kein Anchor und veröffentlichen keine IDLs.
- Address Lookup Tables in versionierten Transaktionen komprimieren 32-Byte-Adressen auf 1-Byte-Indizes – Hardware-Wallets können die Lookup-Tabellen nicht verifizieren, da sie keinen On-Chain-Zugriff haben. Solanas eigene Dokumentation weist explizit darauf hin.
- Cross-Program-Invocation-Ketten sind beim Signieren unsichtbar.
- Einfache SOL-Transfers und SPL-Token-Operationen – Ledger kann diese parsen. DeFi-Interaktionen, die den Großteil des Solana-Transaktionsvolumens ausmachen – hier ist Blind Signing praktisch immer nötig.
TON
Kombiniert mehrere Architekturmerkmale, die Clear Signing jeweils schon einzeln erschweren – und in Kombination erst recht:
- Cell-basierte Datenstruktur: Alle Daten werden als Baum aus Zellen dargestellt (jede hält bis zu 1023 Bits mit bis zu 4 Referenzen), was rekursive Baumdurchläufe erfordert, um Nachrichten zu parsen, die mehr als eine Zelle umfassen.
- TL-B-Codierung: Arbeitet auf Bit-Ebene mit komplexen Konstruktoren und rekursiven Referenzen – deutlich schwerer auf Hardware mit begrenzten Ressourcen zu parsen als byte-ausgerichtete Formate.
- Kein universelles ABI: 32-Bit-Op-Codes sind Konvention, aber nicht Protokollpflicht.
- Asynchrone Ausführung: Eine einzelne Nutzeraktion kann kaskadierende interne Nachrichten über mehrere Verträge und Shards in nachfolgenden Blöcken auslösen. Der Nutzer signiert nur die initiale externe Nachricht – alles danach bleibt beim Signieren unsichtbar und unvorhersehbar.
Sui (Honourable Mention)
Teilt das starke Typsystem von Move mit Aptos, was auf Instruktionsebene hilft. Aber Sui's Programmable Transaction Blocks können bis zu 1.024 Kommandos enthalten, deren Ergebnisse zwischen Operationen weitergereicht werden – Coin splitten, in ein DeFi-Protokoll einzahlen, gegen Sicherheiten leihen, Erlös transferieren, alles in einer einzigen atomaren Transaktion. Einzelne Kommandos sind gut typisiert, aber die Anzeige eines mehrstufigen PTB auf einem Hardware-Wallet-Display wirklich verständlich darzustellen, ist eine extreme UX-Herausforderung. Um die gesamte Transaktion zu verstehen, muss die gesamte Befehlssequenz mit ihren Datenabhängigkeiten analysiert werden.
Schnellübersicht
| Chain | Zentrale Herausforderung | Clear Signing |
|---|---|---|
| XRP Ledger | Neue Tx-Typen erfordern Wallet-Updates | Gut |
| Polkadot | 200KB+ Metadaten – gelöst mit Merkle-Proofs | Gut |
| Cosmos | Eigene Nachrichtentypen brauchen eigene Renderer | Gut |
| NEAR | Borsh-codierte Argumente ohne Schema undurchsichtig | Gut |
| Bitcoin | UTXO-Modell versteckt Input-Beträge; komplexe Scripts | Mittel |
| Aptos | BCS-Argumente brauchen externes ABI; Script-Payloads umgehen Struktur | Mittel |
| Stellar | Klassische Ops okay; Soroban fast keine Abdeckung | Mittel |
| Algorand | Nicht-ARC-4-Verträge undurchsichtig; 256 unsichtbare innere Transaktionen | Mittel |
| Cardano | Plutus-Datums/Redeemers ohne Standardanzeige | Mittel |
| Tezos | Komplexe Parameter erfordern Vertragsschema | Mittel |
| Ethereum / EVM | Kein On-Chain-ABI; Proxies; Selector-Kollisionen; Multicall | Schwierig |
| Solana | Kein Standard-ABI; unsichtbare CPI-Ketten; Lookup-Tabellen undurchsichtig | Schwierig |
| TON | Bit-Level-Codierung; asynchrone Nachrichten; kein universelles ABI | Schwierig |
| Sui | 1.024-Kommandos-PTBs mit Abhängigkeiten | Schwierig |
Was sagt wirklich etwas über Clear-Signing-Qualität aus?
Drei Architektur-Muster sind die besten Prädiktoren:
- Begrenzte, typisierte Transaktionsmodelle (XRP, Stellar classic, Algorand-Basislayer): Jede mögliche Operation hat ein bekanntes Schema. Am einfachsten anzuzeigen.
- Selbsterklärende Metadaten-Systeme (Polkadots Runtime-Metadaten, Cosmos' typisierte Nachrichten): Transaktionen sind nicht von sich aus lesbar, tragen aber genug Typinformationen, um ohne externe Register dekodiert zu werden.
- Undurchsichtige Instruktionsdaten (Solana, Ethereum, TON): Das Protokoll behandelt Smart-Contract-Parameter als beliebige Byte-Arrays. Kein externes Tool kann das vollständig ausgleichen.
Die Reaktion der Branche
Das Ökosystem setzt bei Chains der Stufe 3 auf externe Metadaten-Layer als pragmatische Lösung. ERC-7730, Ledgers Generic Parser und die MetaMask-Partnerschaft sind die ausgereiftesten Implementierungen. Polkadots Merkleized Metadata ist vermutlich die eleganteste Lösung – vertrauenslos, funktioniert auf allen Parachains, braucht kein externes Register. Cosmos' SIGN_MODE_TEXTUAL ist direkt im SDK integriert. Für Solana und TON gibt es noch keinen einheitlichen Clear-Signing-Standard.
Wichtig zu verstehen: Externe Metadaten funktionieren, sind notwendig, erreichen aber nie die gleiche Abdeckung wie ein von Grund auf transparentes Protokoll. Sie erfordern laufende Community-Pflege, hinken neuen Vertrags-Deployments hinterher und bringen Vertrauensannahmen mit, die native Lösungen nicht brauchen.
Der Preis für Fehler geht in die Milliarden: Der Bybit-Hack hat gezeigt: Blind Signing ist kein UX-Problem – es ist ein systemischer Infrastrukturfehler. Für neue Blockchain-Designs ist die Lehre eindeutig: Lesbarkeit auf Protokollebene einzubauen ist um ein Vielfaches effektiver, als sie nachträglich über externe Standards zu erzwingen.
