Weitere Blockchain-Designs, denen Analysten begegnen

Untersuchungen bleiben selten auf Bitcoin und Ethereum beschränkt: Gestohlene Gelder fließen durch Solana-Programme, Stablecoins werden in großem Umfang auf Tron bewegt, Token springen über IBC zwischen Cosmos-Blockchains hin und her, und manche Spuren verlieren sich in Monero oder einem abgeschirmten Zcash-Pool. Jedes Design speichert Werte anders. Daher erfordert dieselbe Frage („Wer hat was an wen gesendet?“) eine andere Abfrage und lässt sich manchmal überhaupt nicht on-chain beantworten. Diese Lektion vermittelt die Grundlagen der einzelnen Designs und macht deutlich, was nicht sichtbar ist.

Solana: Konten, Programme und Token-Konten

Solana verwendet ein Kontenmodell, allerdings wörtlicher als Ethereum: Alles ist ein Konto mit fünf Feldern: lamports (Guthaben; 1 SOL = 1.000.000.000 Lamports), data, owner, executable und rent_epoch. Adressen sind 32 Byte lange Ed25519-Public-Keys oder von Programmen abgeleitete Adressen und werden in Base58 dargestellt. Konten müssen ein Mindestguthaben an Lamports halten, das rückerstattet werden kann und sich nach der Größe ihrer Daten richtet.

Programme (Solanas Smart Contracts) sind ausführbare Konten, die selbst keinen Zustand speichern. Der Zustand liegt in separaten Datenkonten, deren owner das Programm ist. Nur das Eigentümerprogramm kann die Daten eines Kontos ändern oder dessen Lamports abbuchen.

Token folgen demselben Muster. Ein Mint-Konto definiert einen Token (Angebot, Dezimalstellen, Mint-Autorität, Einfrierungsautorität). Guthaben befinden sich in Token-Konten, die jeweils einen Mint, einen Eigentümer und einen Betrag erfassen. Ein Wallet kann mehrere Token-Konten für denselben Mint besitzen, üblich ist jedoch das zugehörige Token-Konto. Dessen Adresse wird aus der Adresse des Eigentümers, dem Token-Programm und dem Mint abgeleitet, sodass jedes Wallet für jeden Token ein vorhersehbares Konto hat. Es gibt zwei Token-Programme: das ursprüngliche Token Program und Token-2022 (Token Extensions), das Funktionen wie Transfergebühren ergänzt.

Die Konsequenz für Analysten: Token-Transfers erfolgen zwischen Token-Konten, nicht zwischen Wallets. Um sie zuzuordnen, ordnen Sie jedes Token-Konto seinem owner zu. Denken Sie daran, dass der Eigentümer eines Token-Kontos geändert werden kann; nehmen Sie die Zuordnung daher zum Zeitpunkt des Transfers vor. Die Transaktionsmetadaten übernehmen einen Großteil dieser Arbeit. Jede Transaktion listet vorab alle Konten auf, die sie berührt; der erste Signierer zahlt die Gebühr, und die erste Signatur ist die Kennung der Transaktion. getTransaction liefert die Guthaben vor und nach der Transaktion:

{
  "fee": 5000,
  "preTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "900000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "0", "decimals": 6 } }
  ],
  "postTokenBalances": [
    { "accountIndex": 1, "mint": "EPx7…t1v", "owner": "7Hq2…ZpA",
      "uiTokenAmount": { "amount": "650000000", "decimals": 6 } },
    { "accountIndex": 2, "mint": "EPx7…t1v", "owner": "9mLc…4Rd",
      "uiTokenAmount": { "amount": "250000000", "decimals": 6 } }
  ]
}

Der Vergleich der Guthaben vor und nach der Transaktion anhand des Kontoindex zeigt, dass Eigentümer 7Hq2…ZpA 250 Token verloren hat (von 900 auf 650 bei 6 Dezimalstellen) und Eigentümer 9mLc…4Rd 250 hinzugewonnen hat. Dieser Vergleich ist oft zuverlässiger als das Dekodieren jeder einzelnen Anweisung, insbesondere wenn ein Swap über mehrere Programme als innere Anweisungen ausgeführt wird. Änderungen an Lamports erscheinen auf dieselbe Weise in preBalances und postBalances.

Cardano: erweitertes UTXO-Modell

Cardano behält das UTXO-Modell bei und erweitert es (eUTXO). Outputs können mehrere Assets gleichzeitig enthalten: ADA (1 ADA = 1.000.000 Lovelace) sowie native Token, die durch eine Policy-ID und einen Asset-Namen identifiziert werden. Für eine einfache Übertragung ist kein Smart Contract erforderlich. Jeder Output muss eine Mindestmenge ADA enthalten, die mit der Größe der mitgeführten Token und Daten steigt. Durch Skripte gesperrte Outputs enthalten ein Datum (an den Output angehängte Daten); zum Ausgeben wird ein Redeemer (ein Argument) übergeben, und das Skript validiert die gesamte Transaktion (den Skriptkontext). Eine DEX-Order oder eine Kreditposition ist daher ein UTXO an einer Skriptadresse, und ihre Bedingungen sind im Datum enthalten.

Cardano-Adressen (Bech32, im Mainnet beginnend mit addr1) bestehen üblicherweise aus zwei Teilen: einem Zahlungsteil, der die Ausgabeberechtigung steuert, und einem Delegationsteil, der die Staking-Rechte steuert. Reward-Konten haben eigene Adressen, die mit stake1 beginnen. Viele Zahlungsadressen mit denselben Delegationsdaten gehören in den meisten Fällen zu demselben Wallet: ein starkes Clustering-Signal, das es bei Bitcoin nicht gibt. Es ist kein Beweis, denn der Standard erlaubt, dass die beiden Teile verschiedenen Parteien gehören, und manche Adressen haben überhaupt keinen Delegationsteil.

Tron

Tron ist eine Blockchain mit Kontenmodell und einer EVM-kompatiblen virtuellen Maschine. Daher geben TRC-20-Token dieselben Transfer-Ereignisse aus wie ERC-20-Token, und dieselbe Dekodierung ist anwendbar (siehe die Lektion Token-Transfers lesen). Tron ist eines der wichtigsten Netzwerke für Stablecoin-Transfers und taucht häufig bei Untersuchungen von Betrug und Abzocke auf.

Adressen sind Base58Check-Zeichenfolgen, die mit T beginnen: ein Präfixbyte 0x41, gefolgt von einem 20 Byte langen, wie bei Ethereum aus dem Public Key abgeleiteten Teil. Durch die Umwandlung von T…-Adressen in ihr Hexadezimalformat können Analysten EVM-ähnliche Tools verwenden und sie mit EVM-Datensätzen verknüpfen. Dabei muss die Blockchain-Kennung in jeder Zeile erhalten bleiben.

Gebühren basieren auf einem Ressourcenmodell statt auf Gaspreisen. Einfache Transfers verbrauchen Bandbreite (jedes Konto erhält ein kleines kostenloses Tageskontingent), und Vertragsaufrufe wie TRC-20-Transfers verbrauchen Energie. Ressourcen stammen aus dem Staking von TRX, von einem anderen Konto, das sie delegiert, oder aus dem Verbrennen von TRX, wenn keine Ressourcen verfügbar sind. Delegation und Energiemiete bedeuten, dass das Konto, dessen Ressourcen für eine Transaktion bezahlt haben, ein Dienstleister und nicht der Sender sein kann – ähnlich wie bei einer Gas-Sponsorship (siehe die Lektion Das Kontenmodell für Analysten). Eine neue Adresse wird on-chain normalerweise aktiv, wenn sie zum ersten Mal TRX erhält. Der Sender, der sie aktiviert, ist daher ein nützlicher Hinweis.

Cosmos und IBC

Das Cosmos-Ökosystem ist eine Familie unabhängiger, anwendungsspezifischer Blockchains, von denen die meisten mit dem Cosmos SDK und dem CometBFT-Konsens aufgebaut sind. Dieser gewährleistet Finalität, sobald ein Block festgeschrieben ist. Adressen verwenden Bech32 mit einem chain-spezifischen Präfix (cosmos1…, osmo1…). Bei Blockchains, die dieselbe Schlüsselableitung verwenden, erzeugt ein Schlüssel auf vielen Blockchains Adressen mit denselben Nutzdaten und unterschiedlichen Präfixen und Prüfsummen. Eine Adresse mit einem anderen Präfix neu zu kodieren, ist daher eine schnelle Möglichkeit, denselben Schlüsselinhaber auf anderen Blockchains zu finden.

Blockchains tauschen Token und Nachrichten über IBC (Inter-Blockchain Communication) aus. Dabei betreibt jede Blockchain einen Light Client der anderen, und Off-chain-Relayer übertragen Pakete. Bei einem fungiblen ICS-20-Token-Transfer sperrt die Quell-Blockchain die Token und die Ziel-Blockchain erzeugt einen Voucher, dessen Denomination aus ibc/ gefolgt vom SHA-256-Hash des Pfads und der Basisdenomination besteht. ATOM, das über transfer/channel-0 bei Osmosis eingeht, erscheint als ibc/2739…5EB2. Jedes Paket wird durch seinen Quellport, Quellkanal und seine Sequenznummer identifiziert. Diese erscheinen im send_packet-Ereignis auf einer Blockchain und in den Ereignissen recv_packet und acknowledge_packet auf der anderen: ein exakter Verknüpfungsschlüssel zwischen Blockchains, anders als bei den meisten Bridges. Lösen Sie jeden ibc/-Hash über die Abfrage der Denomination-Traces der Blockchain zu seinem Pfad auf, und beachten Sie, dass derselbe über zwei verschiedene Pfade eingehende Asset zwei verschiedene, nicht austauschbare Denominationen ergibt.

Datenschutzorientierte Blockchains: Monero und Zcash

Monero verbirgt standardmäßig alle drei Parteien. Jede Zahlung geht an eine einmalige Stealth-Adresse, sodass die öffentliche Adresse des Empfängers nie auf der Blockchain erscheint. Jede Eingabe wird mit einer Ringsignatur signiert, die den tatsächlichen Output mit Täuschungs-Outputs mischt (Ringgröße 16 seit dem Upgrade im August 2022). Ein Key Image verhindert Doppelausgaben, ohne offenzulegen, welches Mitglied des Rings ausgegeben wurde. Beträge werden durch RingCT-Commitments mit Range-Proofs verborgen (Bulletproofs+ seit 2022). Sichtbar bleiben: die Transaktion, ihre Zeit, ihre Gebühr, die Anzahl ihrer Eingaben und Outputs, die Ringmitglieder und zusätzliche Daten. Eine Studie von Möser und Kollegen („Eine empirische Analyse der Rückverfolgbarkeit in der Monero-Blockchain“, 2018) zeigte, dass viele frühe Transaktionen zurückverfolgbar waren. Dies lag hauptsächlich an Eingaben ohne Täuschungs-Outputs und einer Auswahl der Täuschungs-Outputs, durch die das neueste Ringmitglied am häufigsten das tatsächliche war. Das Protokoll hat seitdem Ringgrößen verpflichtend gemacht und die Auswahl der Täuschungs-Outputs verbessert. Ein geplantes Upgrade (FCMP++) würde Ringe durch Beweise über die gesamte Menge der Outputs ersetzen und damit die durch die Auswahl der Täuschungs-Outputs entstehenden Informationslecks beseitigen. Prüfen Sie, ob es aktiviert ist, bevor Sie sich auf Schlussfolgerungen aus Ringstrukturen verlassen. Inhaber können eingehende Zahlungen mit einem View Key offenlegen. In der Praxis konzentriert sich die Monero-Analyse auf Ein- und Ausstiegspunkte (Börsen und Swap-Dienste) sowie deren Off-chain-Aufzeichnungen, die über ein rechtliches Verfahren eingeholt werden.

Zcash ist eine Mischung. Transparente Adressen (t1…, t3… für Multisig) funktionieren wie bei Bitcoin und sind vollständig sichtbar. Abgeschirmte Pools (Sprout mit zc…-Adressen, Sapling mit zs… und Orchard seit dem NU5-Upgrade vom 31. Mai 2022, das über Unified Addresses mit dem Präfix u1 genutzt wird) verbergen Sender, Empfänger, Betrag und Memo innerhalb des Pools; die Gebühr bleibt sichtbar. An den Grenzen werden Informationen offengelegt: Beim Abschirmen werden der transparente Sender und der Betrag sichtbar, beim Verlassen des abgeschirmten Bereichs der Betrag und der transparente Empfänger, und der Gesamtwert jedes Pools ist über getblockchaininfo öffentlich. Eine empirische Studie von Kappos und Kollegen („Eine empirische Analyse der Anonymität in Zcash“, 2018) ergab, dass die meisten Aktivitäten transparent waren und dass der Abgleich von Beträgen und Zeitpunkten zwischen Abschirmen und Verlassen des abgeschirmten Bereichs viele Transaktionen miteinander verknüpfte. View Keys ermöglichen eine freiwillige Offenlegung.

Prüfungsschwerpunkt: Solanas Kontofelder, zustandslose Programme, Mint-Konten, Token-Konten und zugehörige Token-Konten sowie die Gründe, warum Transfers den Eigentümern der Token-Konten zugeordnet werden müssen; das Lesen von preTokenBalances und postTokenBalances; Cardanos eUTXO (Datum, Redeemer, Multi-Asset-Outputs) sowie Zahlungs- und Delegationsteile als Clustering-Signal; Trons T-Adressen, Hexadezimalumwandlung und Bandbreiten- und Energiemodell; Cosmos-Bech32-Präfixe, IBC-Transfers mit Escrow und Voucher, ibc/-Denominationen und Paketsequenz als Verknüpfungsschlüssel; Moneros Stealth-Adressen, Ringgröße 16, Key Images und RingCT; transparente und abgeschirmte Zcash-Pools sowie die Informationslecks an den Poolgrenzen.