Das Ethereum-Whitepaper und die EVM

Neugier

1. Warum muss ein auf Tausenden von Maschinen replizierter Computer für jede einzelne Anweisung eine Gebühr verlangen?
2. Was geht kaputt, wenn der auf diesen Maschinen laufende Code ohne Strafe endlos in einer Schleife laufen kann?
3. Wie können zwei verschiedene Kontomodelle – UTXOs und direkt aktualisierte Guthaben – dasselbe Vermögen unterschiedlich darstellen?

Erkunden

1. Vitalik Buterin, damals neunzehn, entwarf Ende 2013 das Ethereum-Whitepaper und schlug darin statt einer bestimmten Währung eine universell einsetzbare Rechenplattform vor. Das im Januar 2014 öffentlich angekündigte Projekt versammelte Mitgründer wie Gavin Wood, Joseph Lubin, Charles Hoskinson, Anthony Di Iorio und Mihai Alisie. Von Juli bis August 2014 lief ein Crowdsale, der etwa 31.500 BTC für das Vorhaben einbrachte. Das Netzwerk startete offiziell am 30. Juli 2015 und markierte den Wandel von Bitcoins begrenzter Skriptfähigkeit zu einer vollständig programmierbaren Umgebung, in der Entwickler komplexe Anwendungen direkt on-chain bauen konnten.
2. Der Kern dieser Architektur ist die Ethereum Virtual Machine (EVM), eine Turing-vollständige Zustandsmaschine, die auf jedem Full Node repliziert wird. Im Gegensatz zum UTXO-Modell von Bitcoin, das einzelne nicht ausgegebene Outputs erfasst, verwendet Ethereum ein Kontomodell, bei dem Guthaben direkt aktualisiert werden. Jedes Konto – ob durch einen privaten Schlüssel oder durch Code gesteuert – führt eine Nonce und ein Guthaben. Wenn eine Transaktion ausgeführt wird, verarbeitet die EVM sie deterministisch; jeder Node berechnet eigenständig dasselbe Ergebnis, wodurch Konsens entsteht, ohne dass die Teilnehmer einander vertrauen müssen.
3. Smart Contracts sind Programme, die in Hochsprachen wie Solidity geschrieben und zu Low-Level-Opcodes kompiliert werden, die die EVM ausführt. Diese Contracts vereinen Wert und Logik zugleich. Ein Contract kann Ether halten, bedingte Trades ausführen oder Governance-Abstimmungen auf Grundlage von Eingaben anderer Konten verwalten. Da die Ausführung deterministisch ist und viele Contracts ihren Quellcode veröffentlichen, kann jeder die Logik prüfen, bevor er mit ihnen interagiert. Diese Transparenz macht in vielen Finanzanwendungen vertrauenswürdige Vermittler überflüssig, da die Regeln durch Software und nicht durch menschliches Ermessen durchgesetzt werden.
4. Um Endlosschleifen und Denial-of-Service-Angriffe zu verhindern, verbraucht jede EVM-Operation „Gas“ – eine Recheneinheit, die in Ether bezahlt wird. Der Absender legt im Voraus ein Gaslimit fest; wenn die Ausführung diesen Treibstoff aufbraucht, werden die Zustandsänderungen rückgängig gemacht, das verbrauchte Gas wird aber dennoch abgezogen. Diese wirtschaftliche Beschränkung zwingt Entwickler, effizienten Code zu schreiben, und schützt das Netzwerk vor bösartigen oder fehlerhaften Contracts, die sonst die Chain lahmlegen könnten. Die Gaspreise steigen und fallen mit der Nachfrage; ursprünglich gaben die Nutzer einfach Gebote ab, seit 2021 passt sich eine vom Protokoll festgelegte Grundgebühr automatisch an, zuzüglich Tips (eine spätere Lektion).
5. Die Designentscheidungen der EVM spiegeln einen Zielkonflikt zwischen Ausdrucksstärke und Sicherheit wider. Turing-Vollständigkeit ermöglicht beliebige Berechnungen, bringt aber Komplexität mit sich, in der sich Schwachstellen verbergen können. Das Kontomodell macht manche Programme einfacher als UTXOs, doch Contracts, die einander aufrufen, müssen sorgfältig geschrieben werden, um Fehler wie Reentrancy zu vermeiden – die Schwachstelle hinter dem Hack von The DAO (eine spätere Lektion). Die Standardisierung der EVM ermöglicht ein riesiges Ökosystem an Tools und Auditoren, die mit genau diesem Befehlssatz vertraut sind.
6. Öffnen Sie einen Block-Explorer wie Etherscan und sehen Sie sich eine beliebige aktuelle Transaktion an, mit der ein Smart Contract deployt wurde. Achten Sie auf den Status „Contract Creation“ und auf das verbrauchte Gas im Vergleich zum Gaslimit. Beachten Sie, dass die Eingabedaten der Transaktion den kompilierten Bytecode enthalten, der an der neuen Adresse gespeichert wird. Dieser konkrete Schritt zeigt die mechanische Realität eines Deployments: Der Code wird hochgeladen, von jedem Node verifiziert und in der Zustandsmaschine der Chain verankert – bereit zur Ausführung bei künftigen Interaktionen.

Kernfakten

Übung neun, sechs, drei, eins

Faktcheck

Datumsangaben, Zahlen und Behauptungen wurden mit den unten aufgeführten veröffentlichten Quellen abgeglichen.

• V. Buterin, 'Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform' (2013/2014)
• G. Wood, 'Ethereum: A Secure Decentralised Generalised Transaction Ledger' (Yellow Paper, 2014)
• ethereum.org, 'History of Ethereum'