Ethereum-Ausführung und Finalität

EN-Quellmaster · P02-L02 · 30 Minuten geschätzte Dauer · needs_review

Studium mit reinem Lesezugriff. Keine Wallet-Verbindung, echtes Geld, Seed-Phrase, privater Schlüssel, Signatur oder Live-Transaktion. Dauer ist eine redaktionelle Schätzung; visuelle Elemente sind Spezifikationen, keine bereitgestellten Komponenten.

Erfolg und Finalität beantworten unterschiedliche Fragen. Ihre Vermischung kann eine fehlgeschlagene Transaktion erfolgreich oder eine aufgenommene Transaktion endgültiger abgewickelt erscheinen lassen, als die Evidenz stützt.

Zwei Achsen, keine einzelne Statusleiter

Ein Beleg beschreibt Ausführung. Ethereum-Ausführung läuft auf der Ethereum Virtual Machine (EVM), der Umgebung, die ihre Ausführungsregeln anwendet. Konsensinformation beschreibt, ob der Block, der die Transaktion enthält, zu einem Verlauf mit einem bestimmten Abwicklungsstatus gehört. Ethereum Proof of Stake verwendet Checkpoints und Validatorstimmen für Finalität; ein Validator ist ein Protokollteilnehmer, dessen Abstimmungsrolle durch gestaktes ETH unterlegt ist [POS]. Eine erfolgreiche Ausführung in einem jüngeren Block muss noch nicht finalisiert sein.

Umgekehrt kann eine fehlgeschlagene Ausführung in einem finalisierten Verlauf enthalten sein. Finalität schreibt ihr Ergebnis nicht um. Ein aufgenommener Fehlschlag kann weiterhin Gebühren verbrauchen [GAS]. Die beiden Achsen nicht als ein einziges grünes «erledigt»-Badge zusammenfassen.

Den Beleg mit dem Block verbinden

Transaktionshash und Blockhash zusammenhalten. Ein finalisierter Checkpoint auf späterer Höhe genügt für sich genommen nicht, sofern der Belegblock nicht als sein Vorgänger in derselben Chain nachgewiesen ist. Der Übungsdatensatz gibt diese Vorgängerbeziehung bei Bedarf ausdrücklich vor; sie in einem realen Bericht nicht erfinden.

Ein Belegstatus von null stützt einen Fehlschlag in diesem Ausführungskontext [RPC]. Ohne weitere Daten identifiziert er die Ursache nicht. Eine fehlende Fehlererklärung bleibt UNKNOWN; keinen Gasmangel diagnostizieren, nur weil dieser Fehler vertraut ist.

Messung und Interpretation trennen

Der bereitgestellte Statuswert ist innerhalb des Pakets OBSERVED. Die vorgegebene Vorgängerbeziehung zur Abwicklungsklassifikation anzuwenden ist eine INFERRED-Schlussfolgerung unter dieser Annahme. Der aktuelle Live-Zustand wird nicht allein dadurch beobachtet, dass das Paket heute gelesen wurde.

Eine Ergebnismatrix verwenden

Zeilen für aufgenommenen Erfolg/nicht finalisiert, aufgenommenen Fehlschlag/finalisiert und nicht verfügbaren Datensatz erstellen. Dies verhindert, dass eine einzige Statussprache fehlende Daten verdeckt. Auch ein finalisiertes Ergebnis belegt weder Tokenlegitimität noch informierte Einwilligung einer Person oder Sicherheit einer anderen Interaktion.

Klassifikation der Evidenzzustände

OBSERVED im Übungsdatensatz: Belegstatuswerte, bereitgestellte Gebühr und vorgegebene Checkpoint-Vorgängerbeziehung. INFERRED: Die fehlgeschlagene Ausführung von A liegt in der angegebenen finalisierten Vorgängerkette. UNKNOWN: Finalität von B und Fehlerursache von A. INSUFFICIENT EVIDENCE: Ausführungserfolg allein belegt Konsensfinalität oder Tokensicherheit.

• Ausführungsstatus: Erfolg/Fehlschlag der Ausführung einer Transaktion.
• Finalität: Konsenseigenschaft der Abwicklung eines Blockverlaufs.
• Vorgängerbeziehung: Blockbeziehung innerhalb einer Chain.
• Belegkontext: Transaktion plus Block, der sie enthält.

ILLUSTRATIVE. R-A: SIM-TX-A, BLOCK-100, status0, Gasgebühr 0.001 simulierte ETH. R-B: SIM-TX-B, BLOCK-103, status1. Checkpoint BLOCK-102 ist laut Vorgabe finalisiert und folgt in der Vorgängerkette auf BLOCK-100. Keine Finalitätsbehauptung für 103 vorgegeben.

Evidenzpanel mit zwei Achsen: A Fehlschlag/finalisiert unter Annahme; B Erfolg/Finalität unbekannt. Alternativtext: Finalität verwandelt eine fehlgeschlagene Ausführung nicht in Erfolg.

Die Klassifikationen auf zwei Achsen unter ausdrücklich vorgegebener Vorgängerbeziehung.

Unabhängige Konsensvalidierung, eine Fehlerdiagnose, Sicherheit oder aktuellen Netzwerkstatus.

• Finalisiert mit erfolgreich gleichsetzen.
• Status1 bedeutet finalisiert.
• Vorgängerbeziehung allein aus Höhe erraten.

Jede Transaktion auf beiden Achsen klassifizieren. Verschwindet die Gebühr von A? Welcher fehlende Datensatz würde den Abwicklungskontext von B klären?

Reichen Sie eine kurze Evidenztabelle und Begründung nur mit bereitgestelltem Material ein. Empfohlene Zeit: Studium 12 min, Prüfung/Berechnung 8 min, Korrektur/Quiz 10 min.

• Belegergebnis.
• Blockhash.
• Konsens-/Vorgängerbelege.
• Gebühr getrennt.
• Unbekannte Fehlerursachen bleiben unbekannt.

Erfolg und Finalität beantworten unterschiedliche Fragen. Ihre Vermischung kann eine fehlgeschlagene Transaktion erfolgreich oder eine aufgenommene Transaktion endgültiger abgewickelt erscheinen lassen, als die Evidenz stützt. Das bereitgestellte Material stützt die Klassifikationen auf zwei Achsen unter ausdrücklich vorgegebener Vorgängerbeziehung. Es belegt keine unabhängige Konsensvalidierung, Fehlerdiagnose, Sicherheit oder aktuellen Netzwerkstatus.

• Ausführungsergebnis von Konsenskontext trennen.
• Eine finalisierte fehlgeschlagene Ausführung erklären.
• Annahmen über Blockvorgänger lesen.

P02-L03 nach Prüfung dieser Übung und ihrer Voraussetzungen.

NONE. Der maßgebliche Katalog verlangt keinen Produktzugang. Verwenden Sie eingefrorenes Material ohne Netzwerkverbindung.

• [RPC] Ethereum JSON-RPC — Belegstatus, Blockkontext und netzwerkbezogene API-Ergebnisse. Geprüft 2026-10-01.
• [POS] Ethereum Proof of Stake — Konsens-Checkpoints und Trennung von Ausführung/Konsens. Geprüft 2026-10-01.
• [GAS] Ethereum-Gas und Gebühren — Verbrauchtes Gas mal effektiver Preis sowie Kosten aufgenommener fehlgeschlagener Ausführungen. Geprüft 2026-10-01.

Synthetische Werte sind vom Autor erstellte Übungseingaben. Historische Werte verwenden gegebenenfalls den verknüpften Datensatz und dessen enger begrenzte Herkunft. Quellenprüfung ist keine unabhängige redaktionelle Abnahme.