Weiter zum Hauptinhalt
Change page

Blöcke

Letzte Änderung: @Sagitario(opens in a new tab), 27. Februar 2024

Blöcke sind Stapel von Transaktionen mit einem Hash des vorherigen Blocks in der Kette. Dies verbindet Blöcke (in einer Kette), weil Hashes kryptographisch aus den Blockdaten abgeleitet werden. Dies verhindert Betrug: Eine Änderung in irgendeiner Chronik würde alle nachfolgenden Blöcke ungültig machen, da sich alle nachfolgenden Hashes ändern und jeder, der die Blockchain ausführt, dies bemerken würde.

Voraussetzungen

Blöcke sind ein sehr anfängerfreundliches Thema. Um dir jedoch zu helfen, diese Seite besser zu verstehen, empfehlen wir, zuerst Konten, Transaktionen und unsere Einführung in Ethereum zu lesen.

Warum Blöcke?

Um sicherzustellen, dass alle Teilnehmer des Ethereum-Netzwerks einen synchronisierten Zustand beibehalten und sich über den genauen Verlauf der Transaktionen einig sind, fassen wir die Transaktionen in Blöcken zusammen. Das bedeutet, dass Dutzende (oder Hunderte) von Transaktionen in einem Durchgang übergeben, bestätigt und synchronisiert werden.

Ein Diagramm, das Transaktionen in einem Block zeigt, die Zustandsänderungen verursachen Diagramm angepasst von Ethereum EVM illustriert(opens in a new tab)

Durch die zeitliche Verteilung der Commits geben wir allen Netzwerkteilnehmern genügend Zeit, einen Konsens zu erzielen: Obwohl Transaktionsanfragen dutzende Male pro Sekunde erfolgen, werden Blöcke auf Ethereum nur alle zwölf Sekunden erstellt und festgeschrieben.

Wie Blöcke funktionieren

Um die Transaktionsgeschichte zu erhalten, sind Blöcke streng sortiert (jeder neu erstellte Block enthält einen Verweis auf den übergeordneten Block), und Transaktionen innerhalb von Blöcken sind ebenfalls streng geordnet. Außer in seltenen Fällen, zu einem bestimmten Zeitpunkt, sind sich alle Teilnehmer des Netzwerks über die genaue Anzahl und Geschichte der Blöcke einig und arbeiten daran, die aktuellen Live-Transaktionsanfragen in den nächsten Block zu integrieren.

Sobald ein Block von einem zufällig ausgewählten Validator im Netzwerk erstellt wird, wird er im gesamten Netzwerk verbreitet. Alle Knoten fügen diesen Block dann am Ende ihrer Blockchain hinzu und ein neuer Validator wird ausgewählt, um den nächsten Block zu erstellen. Der genaue Prozess der Blockzusammenstellung und Festlegung/Konsensbildung ist zurzeit in Ethereums Proof-of-Stake-Protokoll festgelegt.

Proof-of-Stake-Protokoll

Proof-of-Stake bedeutet Folgendes:

  • Validierende Nodes müssen 32 ETH als Sicherheit gegen Fehlverhalten in einen Einzahlungsvertrag einlagern. Das dient dem Schutz des Netzwerks, da nachweislich unehrliches Verhalten zum anteiligen oder vollständigen Verlust des Einsatzes führt.
  • In jedem Slot (zwölf Sekunden voneinander entfernt) wird zufällig ein Validator ausgewählt, um als Vorschlagender für einen Block zu agieren. Sie bündeln Transaktionen, führen sie aus und bestimmen einen neuen „Zustand“. Sie verpacken diese Informationen in einen Block und geben sie an andere Validatoren weiter.
  • Andere Validatoren, die von dem neuen Block erfahren, führen die Transaktionen erneut aus, um sicherzustellen, dass sie der vorgeschlagenen Änderung des globalen Zustands zustimmen. In der Annahme, dass der Block gültig ist, fügen sie ihn zu ihrer eigenen Datenbank hinzu.
  • Wenn ein Validator von zwei konkurrierenden Blöcken für denselben Slot erfährt, wählt er mit seinem Fork-Wahlalgorithmus den Block aus, der von den meisten eingesetzten ETH unterstützt wird.

Mehr über Proof-of-Stake

Was enthält ein Block?

Ein Block enthält viele verschiedene Informationen. Auf oberster Ebene enthält ein Block folgende Felder:

FeldBeschreibung
Zeitspanne (Slot)Der Slot, zu dem der Block gehört
proposer_indexDie ID des Validators, der den Block vorschlägt
parent_rootDer Hash des vorausgehenden Blocks
state_rootDer Stamm-Hash des Zustandsobjekts
hauptteilEin Objekt, das mehrere Felder enthält, wie unten definiert

Der Body eines Blocks enthält selbst mehrere Felder:

FeldBeschreibung
randao_revealEin Wert, der zur Auswahl des nächsten Block-Vorschlagenden verwendet wird
eth1_dataInformationen zum Einzahlungsvertrag
graffitiBeliebige Daten, die zum Markieren von Blöcken verwendet werden
proposer_slashingsListe der zu streichenden Validatoren
attester_slashingsListe der zu streichenden Validatoren
beglaubigungenListe der Bescheinigungen zugunsten des aktuellen Blocks
einzahlungenListe der neuen Einlagen zum Einzahlungsvertrag
voluntary_exitsListe der Validatoren, die das Netzwerk verlassen
sync_aggregateTeilmenge der Validatoren, die zur Bedienung von leichten Clients verwendet wird
execution_payloadVom Ausführungs-Client übergebene Transaktionen

Das Feld attestations enthält eine Liste aller Attestierungen im Block. Attestierungen haben ihren eigenen Datentyp der mehrere Datenteile enthält. Jede Attestierung enthält:

FeldBeschreibung
aggregation_bitsEine Liste der Validatoren, die an dieser Attestierung teilgenommen haben
datenEin Container mit mehreren Unterfeldern
signatureKollektivsignatur aller bescheinigenden Validatoren

Das Feld data in attestation enthält folgende Elemente:

FeldBeschreibung
Zeitspanne (Slot)Der Slot, auf den sich die Attestierung bezieht
IndexIndizes für die bescheinigenden Validatoren
beacon_block_rootDer Stamm-Hash des Beacon-Blocks, der dieses Objekt enthält
quelleDer letzte berechtigte Kontrollpunkt
targetDer Grenzblock der neuesten Epoche

Die Ausführung der Transaktionen in der execution_payload aktualisiert den globalen Zustand. Alle Clients führen die Transaktionen in der execution_payload erneut aus, um sicherzustellen, dass der neue Zustand dem Zustand im neuen Block im Feld state_root entspricht. Auf diese Weise stellen Clients sicher, dass ein neuer Block gültig und sicher ist, um ihn der Blockchain hinzuzufügen. Der execution payload selbst ist ein Objekt mit mehreren Feldern. Es gibt auch einen execution_payload_header, der wichtige zusammengefasste Informationen über die auszuführenden Daten enthält. Diese Datenstrukturen sind wie folgt organisiert:

Der execution_payload_header enthält die folgenden Felder:

FeldBeschreibung
übergeordneter_hashHash des übergeordneten Blocks
fee_recipientKontoadresse, an die die Transaktionsgebühren gezahlt werden
state_rootStamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block
receipts_rootHash des Transaktionsempfänger-Baums
logs_bloomDatenstruktur, die Ereignisprotokolle enthält
prev_randaoVerwendeter Wert in einer zufälligen Validatorauswahl
block_numberDie Nummer des aktuellen Blocks
gas_limitMaximales für diesen Block erlaubtes Gas
gas_usedDie eingesetzte Menge an Gas in diesem Block
ZeitstempelDie Blockzeit
extra_dataBeliebige zusätzliche Daten als rohe Bytes
base_fee_per_gasDer Basisgebührenwert
block_hashHash des ausführenden Blocks
transactions_rootStamm-Hash der Transaktionen in der Nutzlast
withdrawal_rootStamm-Hash der Abhebungen in der Nutzlast

Die execution_payload selbst enthält Folgendes (das ist identisch zum Header, außer dass es anstatt des Stamm-Hash der Transaktionen die Liste der Transaktions- und Abhebungsinformationen enthält) :

FeldBeschreibung
übergeordneter_hashHash des übergeordneten Blocks
fee_recipientKontoadresse, an die die Transaktionsgebühren gezahlt werden
state_rootStamm-Hash für den globalen Zustand nach der Anwendung der Änderungen in diesem Block
receipts_rootHash des Transaktionsempfänger-Baums
logs_bloomDatenstruktur, die Ereignisprotokolle enthält
prev_randaoVerwendeter Wert in einer zufälligen Validatorauswahl
block_numberDie Nummer des aktuellen Blocks
gas_limitMaximales für diesen Block erlaubtes Gas
gas_usedDie eingesetzte Menge an Gas in diesem Block
ZeitstempelDie Blockzeit
extra_dataBeliebige zusätzliche Daten als rohe Bytes
base_fee_per_gasDer Basisgebührenwert
block_hashHash des ausführenden Blocks
TransaktionenListe der Transaktionen, die ausgeführt werden sollen
abhebungenListe der Abhebungsobjekte

Die Liste withdrawals enthält withdrawal-Objekte, die wie folgt strukturiert sind:

FeldBeschreibung
addressKontoadresse, für die die Abhebung erfolgt ist
amountAbgehobener Betrag
IndexAbhebungsindexwert
validatorIndexValidatorindexwert

Blockzeit

Die Blockzeit bezieht sich auf die Zeit zwischen Blöcken. In Ethereum wird Zeit in Einheiten zu je zwölf Sekunden aufgeteilt. Diese heißen "Slots". In jedem Slot wird ein Validator ausgewählt, der einen Block vorschlägt. Geht man davon aus, dass alle Validatoren online und voll funktionsfähig sind, wird es in jedem Slot einen Block gegen. Die zugehörige Blockzeit beträgt dann 12 Sekunden. Es kann jedoch vorkommen, dass Validatoren offline sind, wenn sie dazu aufgerufen werden einen Block vorzuschlagen. Der zugehörige Slot bleibt dann leer.

Diese Implementierung unterscheidet sich von PoW-basierten Blockchain-Systemen, in denen die Erzeugung eines Blocks zu den probabilistischen Verfahren gehört, wodurch die Mining-Schwierigkeit des Protokolls ausgeglichen wird. Die durchschnittliche Blockverbreitungszeit(opens in a new tab) von Ethereum ist ein perfektes Beispiel für die Implementierung von Proof of Stake und damit für den Wechsel von Proof of Work (PoW) zu Proof of Stake (PoS), der durch eine weitere Anpassung der Blockverbreitungszeit auf 12 Sekunden ermöglicht wurde.

Blockgröße

Ein finaler, wichtiger Hinweis ist, dass Blöcke selbst in ihrer Größe begrenzt sind. Jeder Block hat eine Zielgröße von 15 Millionen Gas, aber die Größe der Blöcke wird entsprechend der Netznachfrage erhöht oder verringert, bis zur Blockgrenze von 30 Millionen Gas (doppelte Zielblockgröße). Die Gesamtmenge des von allen Transaktionen im Block verbrauchten Gases muss unter dem Blockgaslimit liegen. Das ist wichtig, weil dadurch sichergestellt wird, dass Blöcke nicht willkürlich groß sein können. Wenn Blöcke beliebig groß sein könnten, würden weniger leistungsstarke Knoten aufgrund von Platz- und Geschwindigkeitsanforderungen allmählich nicht mehr mit dem Netzwerk Schritt halten können. Je größer der Block, desto höher ist die erforderliche Verarbeitungsleistung, um den Block rechtzeitig für das nächste Zeitintervall zu berechnen. Das ist ein ganz zentraler Aspekt, der durch die Begrenzung der Blockgröße umgangen wird.

Weiterführende Informationen

Sie kennen Community-Resourcen die Ihnen geholfen haben? Bearbeiten Sie diese Seite und fügen Sie sie hinzu!

War dieser Artikel hilfreich?