Was ist die Ausführungsschicht in Ethereum?

Definition und Kernfunktionalität

1. Die Ausführungsschicht in Ethereum bezieht sich auf die Komponente, die für die Verarbeitung von Transaktionen, die Ausführung intelligenter Verträge und die Aufrechterhaltung des Konto- und Saldenstatus verantwortlich ist.

2. Es handelt sich um eine deterministische virtuelle Maschinenumgebung, in der jeder Knoten unabhängig denselben Code ausführt und bei identischen Eingaben zu identischen Ergebnissen kommt.

3. Diese Schicht verarbeitet vom Benutzer initiierte Aktionen wie das Senden von ETH, die Bereitstellung von Verträgen und die Interaktion mit dezentralen Anwendungen.

4. Vor der Zusammenführung lief die Ausführungsebene auf dem Proof-of-Work-Konsens; Nach der Fusion verarbeitet es weiterhin Zustandsübergänge und verlässt sich bei der Endgültigkeit und Blockproduktion auf die Konsensschicht.

5. Ausführungsclients – darunter Geth, Nethermind, Besu und Erigon – implementieren die Ethereum Virtual Machine (EVM) und verwalten lokale Statusdatenbanken, Transaktionspools und Peer-to-Peer-Netzwerklogik.

Interaktion mit der Konsensebene

1. Die Ausführungsschicht kommuniziert mit der Konsensschicht über eine standardisierte Schnittstelle, die als Engine API bekannt ist.

2. Wenn von der Konsensschicht ein neuer Block vorgeschlagen wird, validiert die Ausführungsschicht seine Nutzlast – einschließlich aller Transaktionen – und überprüft, ob der resultierende Zustandsstamm den Erwartungen entspricht.

3. Wenn die Validierung fehlschlägt, lehnt die Ausführungsschicht den Block ab, was Fork-Choice-Regeln auslöst und möglicherweise zu Neuorganisationen oder verpassten Slots führt.

4. Die Konsensschicht interpretiert keine Transaktionssemantik; Es delegiert alle Rechen- und Statusmutationsaufgaben ausschließlich an die Ausführungsschicht.

5. Diese Trennung ermöglicht unabhängige Upgrades: Verbesserungen auf Konsensebene wie PBS oder DAS erfordern keine Änderungen an EVM-Opcodes oder Gaspreismodellen.

Transaktionslebenszyklus und Statusmanagement

1. Eine Transaktion gelangt über einen JSON-RPC-Endpunkt oder einen direkten P2P-Broadcast in die Ausführungsschicht und landet im lokalen Mempool.

2. Validatoren wählen Transaktionen basierend auf dem Gaspreis oder der Prioritätsgebühr aus und ordnen sie in Kandidatenblöcke ein, bevor sie Nutzlasten an die Konsensschicht übermitteln.

3. Jede Transaktion löst die Ausführung des EVM-Bytecodes aus und ändert Kontospeicher, Kontostand und Nonce gemäß der definierten Logik.

4. Nach der Ausführung berechnet die Ebene mithilfe eines Merkle-Patricia-Trie eine neue Weltzustandswurzel, die in den Blockheader eingebettet ist.

5. Historische Zustandsdaten können je nach Client-Konfiguration bereinigt werden, vollständige Archivierungsknoten behalten jedoch alle Zwischenzustände zu Überprüfungs- und Indexierungszwecken bei.

Auswirkungen auf die Sicherheit und Angriffsvektoren

1. Wiedereintrittsschwachstellen bestehen auf der Ausführungsebene aufgrund externer Aufrufmuster, die es böswilligen Verträgen ermöglichen, die Funktionslogik zu unterbrechen und wiederzuverwenden.

2. Gas-Erschöpfungs-Angriffe können die Vertragsausführung mitten im Prozess blockieren und einen inkonsistenten Zustand hinterlassen, wenn Entwickler es versäumen, ordnungsgemäße Prüfungen und Effektmuster zu implementieren.

3. Front-Running bleibt in nicht vertrauenswürdigen Mempools möglich, insbesondere wenn die Transaktionsreihenfolge durch MEV-Extraktoren und nicht durch faire Sequenzierungsmechanismen beeinflusst wird.

4. Ungültige Zustandsübergänge, die durch fehlerhafte Client-Implementierungen verursacht werden – wie z. B. eine falsche EVM-Opcode-Verarbeitung – können zu Konsensverzweigungen führen, wenn sie beim Testen nicht erkannt werden.

5. Fehler auf der Ausführungsebene haben in der Vergangenheit direkt Not-Hard-Forks ausgelöst, darunter den DAO-Fork und die Istanbul-DoS-Korrekturen.

Häufig gestellte Fragen

F: Kann ein Ausführungs-Client ausgeführt werden, ohne eine Verbindung zu einem Konsens-Client herzustellen? A: Ja – es kann im Entwicklungsmodus arbeiten oder Blöcke lokal simulieren, aber es kann nicht am Mainnet-Konsens teilnehmen oder einen gültigen Kettenstatus ohne Koordination über die Engine-API erzeugen.

F: Hat die Änderung des Ausführungsclients Auswirkungen auf meine eingesetzte ETH? A: Nein – Absteckschlüssel und Validator-Einzahlungen befinden sich in der Kette und sind unabhängig von der Wahl des Ausführungsclients, vorausgesetzt, der Client validiert die Nutzlasten korrekt und hält die Synchronisierung aufrecht.

F: Warum brechen einige dApps nach bestimmten Hard Forks ab? A: Weil Hard Forks häufig neue Opcodes einführen, Gaskosten anpassen oder Vorkompilierungen ändern, was dazu führt, dass sich zuvor bereitgestellte Verträge anders verhalten oder unerwartet zurückgesetzt werden.

F: Ist die EVM die einzige von Ethereum unterstützte Ausführungsumgebung? A: Ab sofort ja – das Kernprotokoll schreibt EVM-Kompatibilität vor, obwohl Vorschläge wie EIP-4844 Proto-Danksharding für Rollup-Datenverfügbarkeit ermöglichen, ohne die Ausführungssemantik zu ändern.