Eine Contract Address ist die feste Adresse, unter der ein Smart Contract auf einer Blockchain liegt. Sie wird aus der Adresse des Erstellers sowie Nonce oder Salt berechnet und gehört keinem privaten Schlüssel, sondern dem Programmcode. Wer Token an sie sendet, spricht damit direkt das Programm an.
Ethereum kennt zwei Kontotypen: Konten unter der Kontrolle eines privaten Schlüssels und Contract-Konten, hinter denen ein Smart Contract auf der EVM läuft. Beide tragen dieselbe Adressform, weshalb Nutzer eine Contract Address regelmässig für eine Wallet-Adresse halten. Der Unterschied liegt in der Herkunft. Eine Wallet-Adresse leitet sich aus einem öffentlichen Schlüssel nach secp256k1 ab, eine Contract Address hingegen aus den Daten der Deployment-Transaktion. Zu ihr gehört folglich kein Schlüsselpaar.
Wie CREATE und CREATE2 die Adresse berechnen
Eine Contract Address entsteht zunächst aus einer Transaktion ohne Empfänger im to-Feld, deren Datenfeld den Init-Code trägt. Der Opcode CREATE bildet daraus den Hash keccak256(rlp([sender, nonce])). Dessen letzte 20 Byte ergeben die Adresse, in Hex-Schreibweise mit 0x-Prefix 42 Zeichen lang. Der Nonce zählt die ausgehenden Transaktionen des Erstellers und steigt mit jeder davon. Wer denselben Code zweimal deployt, erhält deshalb zwei verschiedene Adressen.
CREATE2 ersetzt den Nonce hingegen durch ein frei wählbares Salt und bezieht den Init-Code in den Hash ein. EIP-1014 beschreibt die Formel, der Constantinople-Hard-Fork aktivierte den Opcode am 28.02.2019 auf der Hauptkette. Weil der Ersteller das Salt selbst wählt, kontrolliert er die Adresse und kann sie somit veröffentlichen, bevor der Contract existiert. Entwickler nennen das counterfactual deployment. Die Adresse selbst bleibt in beiden Fällen dauerhaft. Erhält der Contract über ein Proxy-Muster neuen Code, ändert das an ihr nichts.
| Merkmal | CREATE | CREATE2 |
|---|---|---|
| Formel | keccak256(rlp([sender, nonce]))[12:] | keccak256(0xff ++ sender ++ salt ++ keccak256(init_code))[12:] |
| Abhängig von | Nonce des Erstellers | frei wählbares Salt |
| Adresse vor Deployment berechenbar | Nein | Ja |
| Eingeführt | ursprünglicher EVM-Opcode | EIP-1014, Constantinople-Hard-Fork 28.02.2019 |
Andere Ketten leiten Adressen ebenfalls ab, rechnen dabei aber anders. Solana-Adressen sind gewöhnlich Ed25519-Public-Keys, Program Derived Addresses entstehen jedoch deterministisch aus Seeds und Programm-ID per SHA-256. Solche Adressen liegen garantiert ausserhalb der Ed25519-Kurve, ein privater Schlüssel existiert zu ihnen daher nicht.
Woran erkennt man eine echte Contract Address?
Ein Block-Explorer zeigt eine Contract Address wie jede Ethereum-Adresse in gemischter Gross- und Kleinschreibung. Diese Schreibweise kodiert eine Prüfsumme nach EIP-55. Ein Hex-Buchstabe steht gross, wenn das zugehörige Nibble im keccak256-Hash der kleingeschriebenen Adresse mindestens 8 beträgt. Die Vorlage stammt also nicht aus der Adresse als Text, sondern aus deren Hash. Ein einziges falsches Zeichen verändert diesen Hash vollständig und damit in aller Regel auch das Muster aus Gross- und Kleinbuchstaben. Passt die Schreibweise nicht zum Hash, ist die Adresse fehlerhaft.
EIP-55 legt durchschnittlich 15 Prüfbits in eine Adresse. Eine zufällig erzeugte Adresse, die jemand vertippt, besteht die Prüfsumme trotzdem mit einer Wahrscheinlichkeit von 0.0247%. Rechnerisch geht somit etwa eine von 4'049 vertippten Adressen unbemerkt durch. Die Prüfbits belegen dabei kein zusätzliches Zeichen, sie stecken allein in der Gross- und Kleinschreibung der Buchstaben.
Zwingend ist die Prüfsumme allerdings nicht, eine durchgehend kleingeschriebene Adresse bleibt gültig. Eine vollständig gültige Fremdadresse hält sie ebenso wenig auf, denn sie prüft die Zeichenfolge und nicht die Absicht dahinter. Ob hinter einer Adresse ein Programm oder ein Schlüsselpaar steht, zeigt sie ebenfalls nicht.
Wenn eine gefälschte Adresse der echten gleicht
Der Block-Explorer Etherscan beschreibt unter dem Namen Address Poisoning, wie Angreifer fremde Adressen nachbilden. Beim Address Spoofing erzeugt ein Angreifer zunächst eine Vanity-Adresse, deren erste und letzte Zeichen mit denen der echten Adresse übereinstimmen. Anschliessend schickt er dem Opfer eine wertlose Transaktion, die in dessen Verlauf auftaucht. Wer dort nur Anfang und Ende vergleicht, sieht keinen Unterschied. Zudem kursieren gefälschte ERC-20-Contracts, die Namen und Symbole bekannter Token nachahmen. Beim Event Spoofing täuscht ein gefälschtes Transfer-Event über transferFrom eine Bewegung vor, die so nie stattgefunden hat.
Ein dokumentierter Fall traf im Mai 2024 eine einzelne Wallet. Der Angreifer hatte zuvor die ersten und letzten Zeichen der Zieladresse nachgebildet, die Überweisung ging über rund 68 Mio. USD. Später gab er die Mittel zurück.
Nulltransfers sind ein Kanal, über den eine gefälschte Adresse überhaupt erst in den Transaktionsverlauf gelangt. Etherscan blendet Token-Transfers ohne Wert deshalb seit April 2023 standardmässig aus. Die belastbare Quelle für eine Contract Address bleibt trotzdem die Projektseite, nicht der Transaktionsverlauf.
