Zum Inhalt springen
Financial Context Wiki

Calldata-Decodierung in einer Wallet

Ein verifikationsorientierter Leitfaden zu Transaktions-Calldata, ABI-Wörtern und Offsets, Selektorkollisionen, Proxys, Batches, Freigaben, Typed-Data-Permits, Simulation und nachgelagerter Abstimmung.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

Calldata ist die unveränderliche Bytefolge, die einer Ethereum-Transaktion auf oberster Ebene oder einem internen Message Call als Eingabe übergeben wird. Ein herkömmlicher Solidity-Funktionsaufruf beginnt mit einem 4-byte-Selektor, gefolgt von ABI-codierten Argumenten. Calldata ist jedoch nicht selbstbeschreibend: Dieselben Bytes können für unterschiedlichen Laufzeitcode, verschiedene Proxy-Implementierungen oder Schemata etwas anderes bedeuten. Fallback-Funktionen, Raw Assembly und Nicht-Solidity-Protokolle müssen die herkömmliche Funktions-ABI überhaupt nicht befolgen.

Eine Wallet sollte daher mehr als einen möglichen Funktionsnamen anzeigen. Eine sichere Prüfung bindet die Bytes an chainId, einen Block, from, to, den nativen value, den Laufzeit-codeHash, die aktive Implementierung und eine vertrauenswürdige ABI; decodiert jeden verschachtelten Aufruf strikt; trennt On-Chain-Calldata von EIP-712-Signaturen; simuliert in einem expliziten Zustand; und stimmt nach der Aufnahme den tatsächlichen Beleg und die Zustandsänderungen ab.

Calldata-Decodierung
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

  1. Legen Sie Signatur-Envelope und Beobachtungspunkt fest: chainId, Blocknummer und -hash, from, to, nativer value, Eingabebytes, Nonce und Gebührenfelder. Bewahren Sie die Wallet- oder RPC-Quelle auf; eine auf einer anderen Chain oder in einem anderen Block decodierte Nutzlast ist nicht dieselbe Aussage.
  2. Klassifizieren Sie das Objekt vor dem Decodieren. Transaktion, EIP-712-Typed-Data-Anfrage, ERC-2612-Permit, ERC-4337-UserOperation und rohe Personal-Sign-Nachricht verwenden unterschiedliche Domänen und Schemata; zwängen Sie sie nicht alle in die Transaktions-ABI.
  3. Ermitteln Sie das Ziel im festgelegten Block. Lesen Sie Laufzeit-Bytecode und codeHash; identifizieren Sie gegebenenfalls Proxy, Beacon oder Implementierung; erfassen Sie Implementierungs- und Admin-Slots; und beschaffen Sie eine ABI, die exakt zu dieser Codeversion passt. Ein Selektorregister liefert Kandidaten, keine maßgebliche Zuordnung.
  4. Decodieren Sie strikt. Der Selektor besteht aus den ersten 4 bytes des Keccak-256-Hashs der kanonischen Funktionssignatur ohne Rückgabetypen. Statische Werte belegen 32-byte-Wörter; dynamische Heads enthalten Offsets vom Argumentblock nach dem Selektor. Verwerfen Sie abgeschnittene Daten, Offsets außerhalb der Grenzen, unmögliche Längen, ungültiges Padding und unerklärte abschließende Bytes.
  5. Entfalten Sie Multicalls, verschachtelte Calldata und delegierte Ausführung rekursiv. Führen Sie für jeden Unteraufruf Ziel, nativen Wert, Selektor, Argumente, Aufruftyp und etwaiges allowFailure-Flag auf. Bei delegatecall läuft der Implementierungscode im Adress-, Saldo- und Speicherkontext des Aufrufenden, während msg.sender und msg.value erhalten bleiben.
  6. Erstellen Sie getrennte Berechtigungs- und Wertkonten und simulieren Sie anschließend. Erfassen Sie Empfänger, Spender, NFT-Operatoren, Token-Roheinheiten, Dezimalstellen, Fristen, Slippage-Grenzen und nativen Wert. Simulieren Sie mit exaktem Block, Absender und Wert, behandeln Sie das Ergebnis aber als bedingte Momentaufnahme, da sich Zustand, Preise, Zeit, Code und Transaktionsreihenfolge ändern können.
  7. Bestätigen Sie vor der Signatur jedes wesentliche Feld. Prüfen Sie nach der Aufnahme Belegstatus, Logs, verfügbare Traces sowie Änderungen an Salden, Allowances und Operatorstatus; unterscheiden Sie abgefangene Fehler von Unteraufrufen vom Erfolg auf oberster Ebene; erfassen Sie Gas auch bei einem Revert; warten Sie die erforderliche Finalität ab; und stoppen Sie, statt einen unerklärten Fehler blind erneut zu signieren.

Durchgerechnete Beispiele

  • Statischer ERC-20-Transfer. transfer(address,uint256) verwendet häufig den Selektor 0xa9059cbb. Ein Selektor plus zwei ABI-Wörter ergibt 4 + 2 * 32 = 68 bytes. Ein Rohbetrag von 1,500,000 bei einem unabhängig auf 6 decimals geprüften Token wird als 1.5 tokens angezeigt. Dezimalstellen sind externe Vertragsmetadaten und nicht in diesen Argumenten codiert; außerdem identifiziert der Selektor allein Vertrag oder Funktion nicht eindeutig.
  • Offset dynamischer Bytes. Bei f(address,bytes) mit einer 3-byte-Nutzlast belegt der Zwei-Wort-Head 64 bytes. Der dynamische Offset lautet 0x40 und wird ab dem Beginn des Argumentblocks ohne Selektor gemessen. Sein Tail enthält ein 32-byte-Längenwort und ein auf 32-byte aufgefülltes Datenwort, sodass die gesamte Calldata 4 + 64 + 32 + 32 = 132 bytes umfasst. Wird der Offset absolut ab Byte null interpretiert, liegt das Ziel vier Bytes zu spät.
  • Der Wert eines Batchs ist implementierungsspezifisch. Ein äußerer Aufruf führt 1.00 ETH mit; drei decodierte Unteraufrufe fordern ausdrücklich 0.20 ETH, 0.30 ETH und 0.10 ETH, insgesamt 0.60 ETH. Die verbleibenden 0.40 ETH könnten je nach Batch-Code zurückerstattet, einbehalten, weitergeleitet oder Ursache eines Reverts sein. Scheitert der dritte Unteraufruf mit allowFailure=true, können frühere Aufrufe bestehen bleiben; eine atomare Implementierung kann stattdessen alles zurücksetzen.
  • Ein Permit ist beim Signieren nicht die Calldata des Relayers. Ein Owner mit 1,000 USDC signiert einen ERC-2612-Permit über 300 USDC bei Nonce 41. Die Signatur allein ändert weder Saldo noch Allowance. Nach erfolgreicher Einreichung durch einen Relayer steigt die Nonce auf 42 und die Allowance auf 300; nachdem der Spender 180 nutzt, betragen Saldo 820 und Rest-Allowance 120. Das Trennen der Website widerruft die Berechtigung nicht.

Risiken

  • Decodierung anhand der falschen Chain, des falschen Forks, Block-Tags oder Transaktions-Envelopes.
  • Signatur für eine gefälschte Domäne, Zieladresse oder einen gefälschten Empfänger.
  • Behandlung eines 4-byte-Selektors als eindeutig trotz möglicher Kollisionen.
  • Verwendung einer vermuteten, veralteten oder falsch verifizierten ABI.
  • Vertrauen auf eine Verifizierungskennzeichnung ohne Abgleich mit dem aktuellen codeHash.
  • Übersehen eines Implementierungs-, Beacon- oder Admin-Upgrades zwischen Prüfung und Ausführung.
  • Übersehen einer Proxy-Funktion, deren Selektor mit der Implementierung kollidiert.
  • Vergessen, dass delegatecall in den Speicherkontext des Aufrufenden schreibt.
  • Akzeptieren fehlerhafter dynamischer Offsets, Längen, Padding-Bytes oder abschließender Bytes.
  • Nichtentfalten eines verschachtelten Batchs, der Ziele, Werte oder Berechtigungen verbirgt.
  • Annahme von Atomarität, obwohl die Implementierung Fehler von Unteraufrufen abfängt oder zulässt.
  • Ignorieren des nativen value auf oberster Ebene, weil Token-Argumente harmlos erscheinen.
  • Anwendung falscher Dezimalstellen oder Annahme, Fee-on-Transfer- und Rebasing-Token seien Standard-ERC-20.
  • Erteilung einer unbegrenzten ERC-20-Allowance oder falsche Handhabung des Wettlaufs bei Allowance-Änderungen.
  • Übersehen des kollektionsweiten Umfangs von NFT-setApprovalForAll.
  • Verwechslung von EIP-712-Typed-Data oder einem ERC-2612-Permit mit Transaktions-Calldata.
  • Übersehen von Nonce, Frist, Verifizierungsvertrag, Chain-Domäne oder Replay-Grenzen.
  • Behandlung einer Simulation als stabil trotz Änderungen an Orakel, Timestamp, Pending State, MEV oder Code.
  • Behandlung von Belegstatus, Logs oder Provider-Traces als vollständigen wirtschaftlichen Zustandsbeweis.
  • Blindes erneutes Signieren über eine kompromittierte UI oder Missachtung von Aufnahme-, Reorg- und Finalitätsrisiken.

Häufige Fehlannahmen

  • Ein Funktionsselektor identifiziert eindeutig, was der Vertrag ausführen wird.
  • Eine verifizierte Frontend-Zusammenfassung entspricht exakt den signierten Bytes und der aktuellen Implementierung.
  • Eine Transaktion mit value=0 kann keine Token, NFTs oder delegierten Vermögenswerte bewegen.
  • Eine erfolgreiche Simulation oder ein erfolgreicher Beleg beweist Sicherheit und das beabsichtigte wirtschaftliche Ergebnis.
  • Das Trennen einer dapp widerruft Freigaben, Permits und NFT-Operatorberechtigungen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...