Jedes Konto ist ein Vertrag
Auf Ethereum gibt es zwei Kontoarten: extern verwaltete Konten, kontrolliert durch einen privaten Schlüssel, und Vertragskonten, kontrolliert durch Code. Starknet hat nur die zweite Art.
Ihre Starknet-Wallet ist ein Smart Contract. Sie definiert ihre eigene Signaturprüfung, kann also Signaturschemata nutzen, die Ethereum nicht kann, mehrere Signierende unterstützen, Session Keys implementieren, oder jemand anderem erlauben, Ihre Gebühren zu zahlen.
Das ist native Account Abstraction, eine echte Verbesserung gegenüber dem EVM-Modell, wo dieselben Fähigkeiten angeflanschte Standards erfordern. Es bedeutet auch, jede Transaktion ist ein Vertragsaufruf, ohne Sonderfall für einfache Transfers.
Starkscan stellt das korrekt dar: Kontoseiten zeigen den Kontovertrag und seine Klasse, kein vorgetäuschtes extern verwaltetes Konto. Kennt man das Modell, ergibt der Explorer Sinn; vorher ist er auf eine Weise verwirrend, die am Modell liegt, nicht am Explorer.
Klassen und Instanzen
Starknet trennt Vertragscode von Vertragsbereitstellung. Code wird als Klasse deklariert, identifiziert durch einen Class Hash. Instanzen werden dann aus dieser Klasse bereitgestellt, jede mit eigener Adresse und eigenem Speicher.
Viele Wallets teilen sich eine Kontoklasse. Viele Token können sich eine Token-Klasse teilen. Der Code existiert einmal auf der Chain; die Instanzen sind billig.
Das ist effizienter als der EVM-Ansatz, identischen Bytecode wiederholt bereitzustellen, und verändert, was Verifizierung bedeutet. Eine Klasse zu verifizieren verifiziert jede Instanz davon — eine deutlich stärkere Eigenschaft als die EVM-Verifizierung pro Adresse.
Starkscan zeigt beide Dimensionen: die Klasse mit ihrem deklarierten Code, und die daraus bereitgestellten Instanzen. Bei der Beurteilung eines unbekannten Vertrags ist die Prüfung, ob seine Klasse eine weit verbreitete verifizierte ist, eine schnelle und wirklich aufschlussreiche Prüfung ohne EVM-Entsprechung.
Cairo und Calldata
Cairo ist Starknets Sprache, so entworfen, dass sich Ausführung mit STARK-Nachweisen beweisen lässt. Es ist nicht Solidity und kompiliert nicht zu EVM-Bytecode; die Semantik unterscheidet sich wirklich.
Die praktische Folge fürs Transaktionslesen ist Calldata. Starknet-Calldata ist ein Array von Field Elements — rohe Zahlen —, ohne Kenntnis der Zielfunktionssignatur bedeutungslos. Starkscan dekodiert sie gegen das ABI des Vertrags und macht aus einer Liste von Ganzzahlen benannte typisierte Argumente.
Kann es nicht dekodieren, zeigt es das rohe Array. Das ist korrektes Verhalten, und es lohnt sich, die rohe Form zu prüfen, wenn etwas merkwürdig wirkt, denn ein Dekoder, der von einem falschen ABI ausgeht, erzeugt selbstsicher falsche Ausgabe.
Voyager ist hier die zweite Meinung, und bei einem so jungen Ökosystem ist es wertvoller als bei Ethereum, zwei unabhängige Dekoder zu haben.
Validitätsnachweise, keine Einspruchsfenster
Starknet ist ein Validity-Rollup. Statt anzunehmen, Transaktionen seien korrekt, und eine Einspruchsfrist zu erlauben, erzeugt es einen kryptografischen Nachweis, dass ein Batch korrekt ausgeführt wurde, und verifiziert diesen Nachweis auf Ethereum.
Der Unterschied zu Arbitrum und Base ist erheblich. Es gibt kein siebentägiges Einspruchsfenster, denn es gibt nichts anzufechten — der Nachweis verifiziert sich entweder oder nicht. Auszahlungen sind durch Proof-Erzeugung und -Verifizierung begrenzt, nicht durch eine feste Einspruchsfrist.
Proof-Erzeugung ist rechenaufwendig, Batches sind also nicht sofort da, und Starkscan zeigt, in welchem Batch eine Transaktion steckt und ob ihr Nachweis auf Ethereum verifiziert wurde. Das ist das Feld, das im stärksten Sinn sagt, ob eine Transaktion abgewickelt ist.
Dieselbe Unterscheidung gilt für Linea und Scroll. Beim Vergleich von Rollups beantwortet „wie lange dauert die Auszahlung“ das Proof-System, nicht das Marketing.
Was unsere Referenztests zeigten
Starknet brauchte einen angepassten Referenzsatz, denn die Hälfte unserer üblichen EVM-Objekte existiert hier nicht — es gibt keine extern verwalteten Konten und keine einfachen Transfers, die keine Vertragsaufrufe sind.
Was wir stattdessen testeten: eine Kontobereitstellung, einen Token-Transfer über einen Kontovertrag, einen Aufruf einer weit verbreiteten verifizierten Klasse, einen Aufruf eines unverifizierten Vertrags, und einen Multicall, der mehrere Operationen bündelt.
Die Kontobereitstellung rendere korrekt, mit identifiziertem Class Hash, verlinkt zu anderen Instanzen derselben Klasse — eine Ansicht ohne EVM-Entsprechung und wirklich aufschlussreich. Zu sehen, dass ein unbekanntes Konto dieselbe weit verbreitete Wallet-Klasse nutzt wie Tausende andere, ist ein bedeutsames Signal, das ein Verifizierungs-Badge pro Adresse nicht liefert.
Die Calldata-Dekodierung funktionierte bei jeder von uns getesteten verifizierten Klasse und erzeugte benannte typisierte Argumente statt Field-Element-Arrays. Beim unverifizierten Vertrag fiel sie klar als undekodiert markiert auf das rohe Array zurück, statt als beste Vermutung präsentiert zu werden. Das ist korrektes Verhalten, und wir haben speziell danach gesucht, denn ein Dekoder, der still rät, ist schlimmer als einer, der zugibt, es nicht zu können.
Der Multicall wurde als seine Komponentenaufrufe dargestellt — genau das, was Account Abstraction ermöglicht und was Starknet-Transaktionen überhaupt lesbar macht.
Wir haben drei der fünf gegen Voyager gegengeprüft. Alle drei stimmten überein. Bei einem so jungen Ökosystem lohnt sich der gelegentliche Vergleich die dreißig Sekunden, denn eine Dekodierungsabweichung zwischen zwei unabhängigen Implementierungen ist der schnellste Weg zu entdecken, dass eine von beiden ein falsches ABI hat.