Ethereum 2.0 Beacon Chain erklärt für Techies

Hier erhältst du ein erfreuliches Verständnis für die Elemente und Mechanismen der Ethereum 2.0 Beacon Chain. Anhand von Beispielen werden die wichtigsten Details auf dem richtigen Niveau erklärt, damit du sie beherrschst und Zeit sparst. Wir gehen davon aus, dass du ein solides Fundament von Ethereum oder Bitcoin hast und mit Proof of Stake etwas vertraut bist.

Sharding: A Big Picture

Um die Beacon Chain zu verstehen, ist eine Einführung in das Sharding hilfreich. Das Hauptproblem der Skalierbarkeit, mit dem Blockchains, einschließlich Ethereum, derzeit konfrontiert sind, ist: Jeder Knoten muss jede Transaktion verifizieren und ausführen.

In der Informatik gibt es zwei Hauptansätze zur Skalierung:

1. Vertikale Skalierung: Grundsätzlich werden die Knoten immer leistungsfähiger.
2. Horizontale Skalierung: Grundsätzlich werden mehr Knoten hinzugefügt.

Für eine Dezentralisierung müssen  Blockchains horizontal skalieren. Ein Ziel von Ethereum 2.0, auch eth2 oder Serenity genannt, ist es, dass die Nodes auf Consumer-Hardware laufen können. Sharding ist der Begriff für die horizontale Partitionierung einer Datenbank.

Im Allgemeinen hat eine Shard-Kette eine Untergruppe von Knoten, die sie verarbeiten. Virtuelle Miner, Validatoren, werden den Shards zugewiesen und verarbeiten und validieren nur Transaktionen in diesem Shard (Kette).

Die Shards von Ethereum haben eine dynamische Untergruppe von Knoten, die sie Block für Block verarbeiten.

Die größte Herausforderung beim Sharding einer Blockchain ist die Sicherheit der Shards. Da die Prüfer über die Shards verteilt sind, könnten böswillige Prüfer einen einzelnen Shard übernehmen.

Ein wichtiger Teil einer Lösung:

• Zufallsmischung der Prüfer, wobei jeder Splitterblock ein (pseudo-)zufällig ausgewähltes Gremium von Prüfern hat, stellt sicher, dass es mathematisch unwahrscheinlich ist, dass ein Angreifer, der weniger als ⅓ aller Prüfer kontrolliert, einen einzelnen Splitter angreifen kann

Betrugsnachweise, Sorgerechtsnachweise und Datenverfügbarkeitsprüfungen sind ebenfalls wichtige Sicherheitskomponenten, bedürfen aber eigener Erklärungen.

Der aktuelle eth2-Plan ist für 64 Shards. Obwohl Shards von der Beacon Chain getrennt sind, werden wir einige Schlüsselelemente des Gesamtsystems beschreiben.

Sharding hat Aufschluss darüber gegeben, was die Ethereum Beacon Chain tut und braucht. Wir werden ein Gefühl dafür bekommen, warum es zusätzliche Komponenten zu klassischen Blockchains gibt. Das aufstrebende Feld der sharded Blockchains freut sich immer über Innovationen von inspirierten Lesern.

Ethereum 2.0 Phasen

Kurz gesagt, hat Ethereum 2.0 drei Phasen:

• Phase 0 – Beacon Chain
• Phase 1 – Shards
• Phase 2 – Ausführung

Eine Analogie zum menschlichen Körper:

Eine Analogie mit einem Orchester, das nur schwer zu schlagen ist:

• Phase 0 – Dirigent
• Phase 1 – Instrumente
• Phase 2 – Musiker

Alle Phasen sind Bestandteil des Systems und haben unterschiedliche Eigenschaften. Phase 0 ist Teil von Ethereum 2020. Phase 1 ist im Allgemeinen unbelebter und statischer als die anderen Phasen. In Phase 2 geht es im Allgemeinen um Aktion und Handeln.

Ebenen und Epochen

Die Beacon Chain ist der Herzschlag von Ethereum 2.0. Er gibt das Tempo und den Rhythmus für die Harmonie und den Konsens des Systems vor. Jeder Slot ist 12 Sekunden lang und eine Epoche besteht aus 32 Slots: 6,4 Minuten.

Ein Slot ist eine Möglichkeit für einen Block, der Beacon Chain und Shards hinzugefügt zu werden. Sie können sich vorstellen, dass die Beacon Chain und die Shard Chains im Gleichschritt choreographiert sind. Wenn das System optimal läuft, werden alle 12 Sekunden ein Beacon-Block (Kette) und 64 Shard-Blöcke hinzugefügt. Die Validatoren müssen ungefähr mit der Zeit synchronisiert werden.

Ein Slot ist wie der Block Zeit, aber Slots können leer sein. Genesis-Blöcke für die Beacon Chain und Shards befinden sich auf Slot 0. Scherben beginnen zu einer späteren Epoche als die Epoche 0 der Bakenkette, haben aber ihre eigene Epoche 0, die ihre Entstehungsblöcke einschließt.

Einführung in Validatoren, Attestierungen und die Beacon Chain

Während Proof of Work (PoW) mit Minern assoziiert wird, sind Validatoren in Ethereum 2.0 Proof of Stake  „virtuelle Miner“. Validatoren nehmen aktiv am Konsens des Ethereum 2.0-Protokolls teil. Ihre Anreize werden später in Beacon Chain Validator Rewards and Penalties diskutiert.

Ein Block Vorschläger ist ein Validator, der pseudozufällig ausgewählt wurde, um einen Block zu bilden.

Die meiste Zeit sind Validatoren Tester , die über Beacon-Blöcke und Shard-Blöcke abstimmen. Diese Stimmen werden in der Beacon Chain aufgezeichnet. Die Stimmen bestimmen den Kopf der Beacon Chain und die Köpfe der Shards.

In jeder Epoche wird ein Prüfer pseudozufällig einem Slot und Shard zugewiesen. Der Prüfer nimmt am Konsens des zugewiesenen Scherbens teil, so dass er für den Kopf des Scherbens stimmen kann. Der Validator verknüpft den Scherbenkopf mit dem Beacon-Block für einen Slot.

Eine Attestation ist die Stimme eines Validierers, gewichtet mit dem Saldo des Validierers. Bestätigungen werden von Prüfern zusätzlich zu den Blöcken gesendet.

Gutachter überwachen sich auch gegenseitig und werden belohnt, wenn sie andere Gutachter melden, die widersprüchlich abstimmen oder mehrere Blöcke vorschlagen.

Der Inhalt der Beacon Chain ist in erster Linie ein Verzeichnis von Prüferadressen, dem Status der einzelnen Prüfer, Bescheinigungen und Links zu Shards. Validatoren werden von der Beacon Chain aktiviert und können in Zustände übergehen, die später in Beacon Chain Validator Activation and Lifecycle kurz beschrieben werden.

Validatoren abstecken: Semantik

Validatoren sind virtuell und werden durch Staker aktiviert. In PoW kaufen die Nutzer Hardware, um Miner zu werden. In Ethereum 2.0 setzen die Nutzer ETH ein, um Validatoren zu aktivieren und zu kontrollieren.

Verwandtes:Lesen Sie den Ethereum 2.0 Staking Report

Validatoren werden von Validator-Clients ausgeführt, die einen Beacon (Ketten)-Knoten nutzen. Ein Beacon-Knoten hat die Funktionalität des Verfolgens und Lesens der Beacon-Kette. Ein Validator-Client kann die Funktionalität eines Beacon-Knotens implementieren oder einen Beacon-Knoten aufrufen. Ein Validator-Client kann einen oder mehrere Validatoren ausführen.

Crosslinks: Die Verwurzelung von Scherben in der Bakenkette

Ein Crosslink ist ein Verweis in einem Beacon-Block auf einen Shard-Block. Ein Querverweis ist die Art und Weise, wie die Beacon-Kette dem Kopf einer Splitterkette folgt. Da es 64 Scherben gibt, kann jeder Beacon-Block bis zu 64 Querverweise enthalten. Ein Beacon-Block kann nur einen Crosslink enthalten, wenn an diesem Slot keine Blöcke für 63 der Shards vorgeschlagen wurden. Crosslinks sind für eth2 Phase 1 geplant, um die Shard-Ketten in der Beacon-Kette zu verwurzeln, die als Grundlage für die Wahl der Shard-Fork, die Finalität der Shard-Kette und für die Shard-übergreifende Kommunikation dient. Alle Shard Chains folgen zu jeder Zeit der Beacon Chain.

Komitees: Einführung

Ein Ausschuss ist eine Gruppe von Prüfern. Aus Sicherheitsgründen hat jeder Slot (in der Beacon Chain und jeder Shard) Komitees von mindestens 128 Validierern. Ein Angreifer hat weniger als eine eine in einer Billion Wahrscheinlichkeit, ⅔ eines Komitees zu kontrollieren.

Das Konzept eines Zufallsbeacons, der Zufallszahlen für die Öffentlichkeit aussendet, ist namensgebend für die Ethereum Beacon Chain. Die Beacon Chain erzwingt einen Konsens über einen pseudozufälligen Prozess namens RANDAO.

Vorschlagende werden von RANDAO mit einer Gewichtung auf die Bilanz des Validators ausgewählt. Es ist möglich, dass ein Prüfer gleichzeitig Antragsteller und Ausschussmitglied ist, aber das ist nicht die Regel. Die Wahrscheinlichkeit, dass dies geschieht, ist 1/32, also werden wir es etwa einmal pro Epoche sehen. Die Skizze zeigt ein Szenario mit weniger als 8.192 Validierern, sonst gäbe es mindestens zwei Ausschüsse pro Slot.

Dieser Beacon-Chain-Erklärer konzentriert sich auf Beacon-Komitees: die Validierer, die die Beacon-Chain bedienen. Einem (Beacon)-Komitee wird pseudozufällig ein Shard zugewiesen, der mit einem Beacon-Block vernetzt wird. Es gibt keine dauerhaften Komitees. Das Komitee, das für die Vernetzung eines Splitterblocks verantwortlich ist, wechselt von Block zu Block.

Scherbenkomitees, die ausschließlich Scherbenkettenblöcke bauen, sind ein Zukunftsthema. Es ist möglich, dass viele Scherbenblöcke von Scherbenketten-Validatoren erstellt werden, die nicht mit der Beacon Chain interagieren. Damit ein Shard jedoch mit anderen Shards kommunizieren kann, benötigt er ein Beacon-Komitee, das ihn mit einem Beacon-Block vernetzt.

Das Diagramm ist eine kombinierte Darstellung der Vorgänge in drei Slots. In Slot 1 wird ein Block vorgeschlagen und dann von zwei Prüfern bescheinigt; ein Prüfer im Ausschuss A war offline. Die Bescheinigungen und der Block in Slot 1 verbreiten sich im Netz und erreichen viele Prüfer. In Slot 2 wird ein Block vorgeschlagen und ein Prüfer im Ausschuss B sieht ihn nicht, daher bescheinigt er, dass der Kopf der Beacon Chain der Block in Slot 1 ist. Beachten Sie, dass sich dieser Prüfer von dem Offline-Prüfer aus Slot 1 unterscheidet.

Ein Prüfer kann nur in einem Ausschuss pro Epoche sein. In der Regel gibt es mehr als 8.192 Prüfer, d.h. mehr als einen Ausschuss pro Slot. Alle Ausschüsse sind gleich groß und haben mindestens 128 Prüfer. Die Sicherheitswahrscheinlichkeit sinkt, wenn es weniger als 4.096 Prüfer gibt, da die Ausschüsse weniger als 128 Prüfer haben.

Ausschüsse: Crux

In jeder Epoche werden die Prüfer gleichmäßig auf die Slots verteilt und dann in Ausschüsse von angemessener Größe unterteilt. Alle Prüfer aus diesem Slot bescheinigen dem Kopf der Beacon Chain. Jeder der Ausschüsse in diesem Slot versucht, einen bestimmten Splitter zu vernetzen. Ein Shuffling-Algorithmus erhöht oder verringert die Anzahl der Komitees pro Slot, um mindestens 128 Validierer pro Komitee zu erhalten.

Nehmen wir als Beispiel 16.384 Prüfer an. 512 Prüfer werden pseudozufällig Slot 1 zugewiesen, weitere 512 Slot 2, und so weiter. Die 512 Prüfer für Slot 1 werden dann in vier Ausschüsse unterteilt und pseudozufällig Scherben zugewiesen. Nehmen wir an, dass die Scherben 33, 55, 22, 11 die Scherbenzuweisungen sind. Alle 512 Wahlberechtigten geben eine LMD-GHOST-Stimme für Slot 1 ab. 128 Prüfer in einem der vier Ausschüsse versuchen, den Splitter 33 zu vernetzen. In einem anderen Ausschuss versuchen 128 Wahlberechtigte, den Splitter 55 zu kreuzen. 128 Prüfer in einem anderen Ausschuss versuchen, Scherbe 22 zu kreuzen. Weitere 128 Prüfer versuchen, Scherbe 11 zu vernetzen.

Für Slot 2 wiederholt sich der Vorgang. Die 512 Prüfer für Slot 2 werden in vier Ausschüsse aufgeteilt und pseudozufällig den Scherben zugewiesen. Nehmen wir an, dass die Scherben 41, 20, 17, 15 die Scherbenzuweisungen sind. Alle 512 Validierer für Slot 2 bescheinigen ihre Ansichten über den Kopf der Beacon Chain in Slot 2. Die Ausschüsse versuchen, die Scherben 41, 20, 17, 15 zu vernetzen.

Der Prozess wiederholt sich für die verbleibenden Slots in der Epoche. Jeder Prüfer hat ein Zeitfenster, in dem er sich äußern, bescheinigen und vernetzen kann. Am Ende der Epoche haben alle 16.384 Prüfer die Möglichkeit gehabt, sich zu äußern und zu vernetzen. Aber bisher waren die Stimmen der Prüfer eher slot-spezifisch als epochenspezifisch. Es ist so, als würde man für seine lokale Regierung stimmen, anstatt an einer allgemeinen nationalen Wahl teilzunehmen. Nicht alle 16.384 Prüfer haben über dieselbe Sache abgestimmt. In den folgenden Abschnitten über Kontrollpunkte und Endgültigkeit wird die epochenspezifische Abstimmung beschrieben, die die Prüfer abgeben, wenn sie an der Reihe sind, sich zu äußern. In der ihnen zugewiesenen Zeit stimmen alle 16.384 Prüfer auch über den Prüfpunkt der Epoche ab.

Baken-Kettenprüfpunkte

Ein Checkpoint ist ein Block im ersten Slot einer Epoche. Wenn es keinen solchen Block gibt, ist der Checkpoint der vorhergehende, jüngste Block. Es gibt immer einen Kontrollpunktblock pro Epoche. Ein Block kann der Prüfpunkt für mehrere Epochen sein.

Beachten Sie, dass Slot 65 bis Slot 128 leer sind. Der Epoche-2-Kontrollpunkt wäre der Block auf Slot 128 gewesen. Da der Slot fehlt, ist der Epoche-2-Kontrollpunkt der vorherige Block auf Slot 64. Bei Epoche 3 verhält es sich ähnlich: Slot 192 ist leer, also ist der vorherige Block auf Slot 180 der Epoche-3-Kontrollpunkt.

Epoch Boundary Blocks (EBB) sind ein Begriff in einiger Literatur (wie z.B. dem Gasper paper, der Quelle des obigen Diagramms), und sie können als Synonym für Checkpoints betrachtet werden.

Bei einer LMD-GHOST-Abstimmung stimmt ein Prüfer auch für den Prüfpunkt in seiner aktuellen Epoche, dem Target. Diese Abstimmung wird als Casper FFG-Abstimmung bezeichnet und umfasst auch einen früheren Prüfpunkt, die Quelle. Im Diagramm hat ein Prüfer in Epoche 1 für einen Quellprüfpunkt des Genesis-Blocks und einen Zielprüfpunkt des Blocks auf Slot 64 gestimmt. In Epoche 2 stimmte derselbe Prüfer für die gleichen Prüfpunkte. Nur Prüfer, die einem Slot zugewiesen sind, gaben eine LMD-GHOST-Stimme für diesen Slot ab. Alle Prüfer gaben jedoch FFG-Stimmen für jeden Epochenprüfpunkt ab.

Supermajorität

Eine Stimme, die von ⅔ der Gesamtheit aller aktiven Validierer abgegeben wird, gilt als Supermajorität. Nehmen wir an, es gibt drei aktive Bewerter: zwei haben einen Saldo von 8 ETH, und ein einziger Bewerter hat einen Saldo von 32 ETH. Die Mehrheitsentscheidung muss die Stimme des einzigen Bewerters enthalten: Die beiden anderen Bewerter können zwar anders stimmen als der einzige Bewerter, haben aber nicht genug Gleichgewicht, um die Mehrheitsentscheidung zu bilden.

Finalität

Wenn eine Epoche endet und ihr Kontrollpunkt eine ⅔-Supermehrheit erlangt hat, wird der Kontrollpunkt gerechtfertigt.

Wenn ein Kontrollpunkt B gerechtfertigt ist und der Kontrollpunkt in der unmittelbar folgenden Epoche gerechtfertigt wird, dann wird B finalisiert. Normalerweise wird ein Kontrollpunkt in zwei Epochen, also 12,8 Minuten, abgeschlossen.

Im Durchschnitt befindet sich eine Benutzertransaktion in einem Block in der Mitte einer Epoche. Bis zum nächsten Checkpoint ist es eine halbe Epoche, was auf eine Transaktionsdauer von 2,5 Epochen schließen lässt: 16 Minuten. Im Idealfall sind mehr als ⅔ der Bescheinigungen bis zum 22. Slot einer Epoche enthalten. Somit beträgt die Finalität einer Transaktion durchschnittlich 14 Minuten (16+32+22 Slots). Blockbestätigungen gehen von den Bescheinigungen eines Blocks über seine Begründung bis hin zu seiner Finalität. Anwendungsfälle können entscheiden, ob sie eine Finalität benötigen oder ob eine frühere Sicherheitsschwelle ausreicht.

Was am Kopf der Bakenkette geschah

Der Epochengrenzblock auf Slot 96 wird vorgeschlagen und enthält Bescheinigungen für den Kontrollpunkt der Epoche 2. Die Zahl der Bescheinigungen für den Epoche-2-Kontrollpunkt erreicht nun die ⅔-Mehrheit. Dies führt zur Rechtfertigung des Prüfpunktes Epoche 2 und damit zur Finalität des zuvor gerechtfertigten Prüfpunktes Epoche 1. Die Endgültigkeit von Slot 32 bewirkt unmittelbar die Endgültigkeit aller ihm vorangehenden Blöcke. Bei der Finalisierung eines Prüfpunkts gibt es keine Begrenzung der Anzahl der Blöcke, die finalisiert werden können. Obwohl die Finalität nur an den Epochengrenzen berechnet wird, werden die Bescheinigungen bei jedem Block akkumuliert, wie in den alternativen Erzählungen „Was von der Entstehung bis zum Kopf hätte passieren können“ unten beschrieben.

Alle Querverbindungen, die in den Bakenblöcken von Slot 1 bis Slot 32 enthalten sind, würden zur Endgültigkeit der Scherbenketten führen. Mit anderen Worten, ein Splitterblock ist abgeschlossen, wenn er mit einem abgeschlossenen Bakenblock vernetzt ist. Ein Crosslink allein reicht nicht aus, um einen Shard-Block zu finalisieren, sondern trägt zur Fork-Wahl der Shard-Kette bei.

Was von der Genesis bis zum Kopf passiert sein könnte

Mit der gleichen Illustration, hier ist eine Geschichte, die von der Genesis an hätte beobachtet werden können. Alle Antragsteller von Slot 1 bis Slot 63 schlagen einen Block vor, und diese erscheinen auf der Kette. Mit jedem Block in Epoche 1 sammelt sein Kontrollpunkt (Block auf Slot 32) Bescheinigungen von 55% der Validierer. Der Block auf Slot 64 wird vorgeschlagen, und er enthält Bescheinigungen für den Prüfpunkt von Epoche 1. Jetzt haben 70 % der Prüfer den Epoche-1-Kontrollpunkt bestätigt: Dies führt zu seiner Rechtfertigung. Der Epoche-2-Kontrollpunkt (Slot 64) sammelt Bescheinigungen während der gesamten Epoche 2, erreicht aber nicht die ⅔-Supermehrheit. Der Block auf Slot 96 wird vorgeschlagen und enthält Bescheinigungen für den Epoche-2-Kontrollpunkt. Dies führt zum Erreichen der ⅔-Supermehrheit und der Rechtfertigung des Epoche-2-Kontrollpunkts. Mit der Rechtfertigung des Epoche-2-Kontrollpunkts werden der Epoche-1-Kontrollpunkt und alle vorherigen Blöcke abgeschlossen.

Hier ist ein weiteres mögliches Szenario. Betrachten Sie nur bis Epoche 1. Der Kontrollpunkt in Epoche 1 könnte eine ⅔-Supermehrheit erhalten haben, bevor der Kontrollpunkt in Epoche 2 vorgeschlagen wird. Wenn zum Beispiel die Blöcke in Slot 32 bis Slot 54 vorgeschlagen werden, könnten die Bescheinigungen zur Rechtfertigung des Kontrollpunkts (Slot 32) bereits die ⅔-Supermehrheit erreicht haben. In diesem Fall wäre der Kontrollpunkt vor Epoche 2 gerechtfertigt gewesen. Ein Kontrollpunkt kann in seiner aktuellen Epoche gerechtfertigt werden, aber seine Finalisierung erfordert mindestens die Epoche danach.

Die Rechtfertigung eines Blocks kann manchmal einen Block abschließen, der zwei oder mehr Epochen zurückliegt. Im Gasper-Papier werden diese Fälle diskutiert. Sie werden nur in Ausnahmefällen bei hohen Latenzzeiten, Netzabtrennungen oder starken Angriffen erwartet.

Finalität ist für Shards und Parteien der Ethereum-Blockchain unerlässlich, um Garantien für Transaktionen zu haben. Finalität reduziert die Komplexität bei der Shard-übergreifenden Kommunikation. Ohne Finalität wären kaskadierende Rollbacks von Transaktionen innerhalb und zwischen Shards störend und könnten die Vorteile von Sharding zunichte machen.

Tests: Ein genauerer Blick

Eine Bescheinigung enthält sowohl ein LMD-GHOST-Votum als auch ein FFG-Votum. Optimal ist es, wenn alle Prüfer eine Bescheinigung pro Epoche einreichen. Eine Bescheinigung hat 32 Slot-Chancen für die Aufnahme in die Kette. Das bedeutet, dass ein Validierer in einer einzigen Epoche zwei Bescheinigungen in die Kette aufnehmen kann. Die Prüfer werden am meisten belohnt, wenn ihre Bescheinigung an dem ihnen zugewiesenen Slot in die Kette aufgenommen wird; eine spätere Aufnahme ist eine abnehmende Belohnung. Um den Validierern Zeit zur Vorbereitung zu geben, werden sie den Ausschüssen eine Epoche im Voraus zugewiesen. Die Antragsteller werden den Slots erst zugewiesen, wenn die Epoche beginnt. Nichtsdestotrotz zielt die geheime Wahl des Leiters Forschung darauf ab, Angriffe oder Bestechung von Antragstellern zu entschärfen.

Ausschüsse ermöglichen die technische Optimierung der Kombination von Unterschriften der einzelnen Prüfer zu einer einzigen Gesamtsignatur. Wenn Prüfer im selben Ausschuss die gleichen LMD GHOST- und FFG-Stimmen abgeben, können ihre Unterschriften zusammengefasst werden.

Beacon Chain Validator Belohnungen und Strafen

Ohne zu sehr in die Tiefe zu gehen, werden wir sechs Themen in Bezug auf Validator-Anreize diskutieren:

1. Bewerter-Belohnungen
2. Bewerter-Strafen
3. Typisches Abwärtsrisiko für Bewerter
4. Zuschläge und Whistleblower-Belohnungen
5. Antragsteller-Belohnungen
6. Inaktivitätsstrafe

Validierer werden belohnt, wenn sie Bescheinigungen (LMD GHOST und FFG Votes) abgeben, denen die Mehrheit der anderen Validierer zustimmt. In der eth2-Phase 1 werden die Validatoren auch für Querverbindungen belohnt. Die Belohnungen werden festgeschrieben, wenn die Blöcke fertiggestellt sind.

Auf der anderen Seite werden die Prüfer bestraft, wenn sie nicht prüfen oder wenn sie einen Block prüfen, der nicht abgeschlossen wird.

Bevor wir die weniger häufigen Strafen und Belohnungen erläutern, möchten Sie vielleicht wissen, welches Risiko Sie eingehen, wenn Sie Staker werden. Wenn Sie sich als Staker Gedanken darüber machen, wie viel ETH Sie verlieren können, ist dies ein Spiegelbild dessen, wie viel Sie verdienen können. Wenn ein Validator in einem Jahr 10 % an Rewards verdienen kann, kann ein (ehrlicher) Validator 10 % verlieren, wenn er die schlechteste Arbeit leistet. Ein Prüfer, der zum Beispiel ständig offline ist oder immer für Blöcke stimmt, die nicht abgeschlossen werden, wird um den Betrag bestraft, den ein Prüfer für pünktliche Bescheinigungen, die abgeschlossen werden, erhalten würde.

Slashings sind Strafen, die von über 0,5 ETH bis zum gesamten Einsatz eines Validators reichen. Für das Begehen eines Slashings verliert ein Validator mindestens 1/32 seines Guthabens und wird deaktiviert. Der Prüfer wird so bestraft, als wäre er 8.192 Epochen lang offline gewesen. Das Protokoll erhebt außerdem eine zusätzliche Strafe, die davon abhängt, wie viele andere Prüfer in der gleichen Zeit abgeschaltet wurden. Die Grundformel für die zusätzliche Strafe lautet: Validator_balance*3*fraction_of_validators_slashed. Eine Auswirkung ist, dass wenn ⅓ aller Prüfer ein „Slash“-Vergehen begehen, sie alle ihr gesamtes Guthaben verlieren. Der Prüfer, der ein „slashable offence“ meldet, erhält eine „Whistleblower“-Belohnung.

Vorschläger von Blöcken, die zum Abschluss gebracht werden, erhalten eine beträchtliche Belohnung. Prüfer, die ständig online sind und gute Arbeit leisten, erhalten einen ~1/8-Anstieg ihrer Gesamtbelohnung für das Vorschlagen von Blöcken. Wenn es zu einem Slashing kommt, erhalten die Antragsteller auch eine kleine Belohnung für die Aufnahme des Slashing-Beweises in einen Block. In eth2 Phase 0 geht die gesamte Belohnung des Whistleblowers an den Vorschlagenden.

Ethereum 2.0 ist ein System mit vielen Mechanismen, von denen einige eher durch ihre Gesamtwirkung zu würdigen sind. Die entworfenen Belohnungen und Bestrafungen gipfeln in einer Inaktivitätsstrafe. Wenn mehr als vier Epochen seit dem Abschluss vergangen sind, erleiden alle Prüfer eine Inaktivitätsstrafe, die quadratisch ansteigt, bis ein Kontrollpunkt abgeschlossen ist. Die Inaktivitätsstrafe garantiert diese Art von Ergebnis: Wenn 50 % der Prüfer offline gehen, werden die Blöcke nach 21 Tagen wieder finalisiert.

Strafbare Vergehen

Es gibt drei Slash-Bedingungen für Validierer. Sie können als Doppelvorschlag, FFG-Doppelvotum und FFG-Surround-Votum bezeichnet werden. Eine LMD-GHOST-Stimme ist nicht streichbar.

Ein Doppelvorschlag ist ein Antragsteller, der mehr als einen Block für den ihm zugewiesenen Slot vorschlägt.

Eine Doppelstimme ist ein Prüfer, der 2 FFG-Stimmen für dasselbe Ziel, aber eine unterschiedliche Quelle abgibt.

Eine Umringungsstimme ist eine FFG-Stimme, die umringt oder umringt von einer früheren FFG-Stimme, die er abgegeben hat. Hier sind zwei Beispiele, die auf dem Szenario basieren, dass ein Prüfer eine FFG-Abstimmung in Epoche 5 mit einer Quelle von Slot 32 und einem Ziel von Slot 128 vorgenommen hat:

• Eine FFG-Stimme in Epoche 6 mit einer Quelle von Slot 64 und einem Ziel von Slot 96 wäre eine FFG-Stimme, die umringt von ihrer Epoche 5-Stimme.
• Eine FFG-Stimme in Epoche 6 mit einer Quelle von Slot 0 und einem Ziel von Slot 160 wäre umringt ihre FFG-Stimme in Epoche 5.

Eine FFG-Stimme in Epoche 6, die ein Ziel von Slot 128 hat, wäre eine doppelte Stimme und ist slashbar, es sei denn, die Quelle war Slot 32. Identische FFG-Stimmen sind nicht schrägstrichfähig.

Zwei FFG-Stimmen mit der gleichen Quelle sind niemals mit einem Schrägstrich bewertbar. Dies ist wichtig für die Lebendigkeit. Wenn es z.B. zwei Forks gibt, hinter denen jeweils 50% der Prüfer stehen, muss das Protokoll die Prüfer ermutigen (nicht bestrafen), den Fork zu wechseln, indem sie mit der gleichen Quelle und einem anderen Ziel abstimmen. Anstatt einer Pattsituation, könnten die Prüfer sicher zwischen den Forks wechseln, um zu versuchen eine ⅔ Supermajorität zu erreichen.

Ein Prüfer, der einen Hinweis gibt, muss die widersprüchlichen Stimmen einbeziehen, um zu beweisen, dass ein anderer Prüfer gestrichen werden sollte. Das effiziente Auffinden einer widersprüchlichen Stimme in einer großen Geschichte ist eine Herausforderung für Algorithmen und Datenstrukturen. Die slashing detector open engineering challenge sucht Mitwirkende.

Ein Prüfer hat die totale Kontrolle, um zu vermeiden, dass er überlistet wird: Er muss sich nur daran erinnern, was er signiert hat. Ein ehrlicher Prüfer kann nicht durch die Handlungen anderer Prüfer zu Fall gebracht werden. Solange ein Prüfer keine widersprüchliche Bescheinigung oder einen widersprüchlichen Vorschlag unterschreibt, kann der Prüfer nicht zerschlagen werden.

Ein Validator-Client kann aus Gründen der besseren Betriebszeit, des Vertrauens und des Denial-of-Service-Schutzes mehrere Beacon-Knoten verwenden. In diesen Konstellationen oder wenn ein Backup-Validator-Client verwendet wird, müssen die Benutzer darauf achten, dass der Validator keine widersprüchlichen Nachrichten signiert.

Beacon Chain Validator Aktivierung und Lebenszyklus

Jeder Validator benötigt ein Guthaben von 32 ETH, um aktiviert zu werden. Ein Nutzer, der 32 ETH in einen Deposit-Vertrag im Ethereum-Mainnet einzahlt, aktiviert einen Validator.

Die Beacon Chain beendet (deaktiviert) alle Validatoren, deren Guthaben 16 ETH erreicht; die Staker können das verbleibende Guthaben der Validatoren abheben, jedoch nicht in eth2 Phase 0.

Validatoren können auch freiwillig ausscheiden, nachdem sie 2.048 Epochen, also etwa 9 Tage, im Dienst waren. Beim Ausscheiden gibt es eine Verzögerung von vier Epochen, bevor die Staker ihren Einsatz zurückziehen können. Innerhalb dieser vier Epochen kann ein Validator immer noch erwischt und ausgemerzt werden. Das Guthaben eines ehrlichen Validators kann dann innerhalb von 27 Stunden abgehoben werden. Wenn aber ein Validator erwischt wird, muss der Staker 8.192 Epochen (etwa 36 Tage) warten, bevor er seinen Einsatz abheben kann.

Weitere technische Details sind in A note on Ethereum 2.0 phase 0 validator lifecycle einschließlich dieses Flussdiagramms beschrieben:

Um große Änderungen im Validatorenset in kurzer Zeit zu vermeiden, gibt es Mechanismen, die begrenzen, wie viele Validatoren innerhalb einer Epoche aktiviert oder verlassen werden können. Diese erschweren es zum Beispiel, viele Validatoren schnell zu aktivieren, um das System anzugreifen.

Die Beacon Chain verwendet ein tiefergehendes Konzept von effektiven Salden die sich seltener ändern als Validator-Salden und technische Optimierungen ermöglichen.

Zusammenfassung

In jeder Epoche werden die Prüfer gleichmäßig auf die Slots verteilt und dann in Ausschüsse geeigneter Größe unterteilt. Prüfer können nur in einem Slot und in einem Ausschuss sein. Zusammengenommen:

• alle Validierer in einer Epoche versuchen, denselben Prüfpunkt abzuschließen: FFG vote
• alle Prüfer, die einem Slot zugewiesen sind, versuchen, über denselben Beacon Chain Head abzustimmen: LMD GHOST vote
• alle Prüfer, die einem Ausschuss zugeordnet sind, versuchen, einen bestimmten Splitter zu vernetzen

Optimales Verhalten belohnt die Prüfer am meisten.

Die Aktivierung der Beacon Chain erfordert mindestens 16.384 Validierer bei der Entstehung. Die Anzahl der Validatoren kann durch Slashings oder freiwillige Austritte sinken, oder die Staker können mehr aktivieren. Es wird erwartet, dass mit dem Hochfahren des Systems auf eth2 Phase 1 und darüber hinaus viel mehr Validierer zur Verfügung stehen werden. Die Beacon Chain benötigt mindestens 262.144 Validierer (über acht Millionen ETH), um Blöcke mit 64 Crosslinks zu haben.

Die Welt hatte noch nie eine skalierbare Plattform für dezentrale Systeme und Anwendungen. Wenn Sie Lust haben, tiefer einzutauchen, finden Sie maßgebliche Referenzen in Ethereum 2.0 Specifications. Sie enthält die Beacon Chain Spezifikation, Links zu anderen wichtigen Ressourcen und Probleme mit Bounties. Derzeit ist der dringendste Bedarf Peer-to-Peer Networking. Tragen Sie dazu bei oder verweisen Sie andere auf Challenges, ethresear.ch oder das Ethereum Magician’s Forum, und seien Sie ein Teil der Geschichte!

Quelle

C. (2020, May 26). The Ethereum 2.0 Beacon Chain Explained – ConsenSys Media. Medium. https://media.consensys.net/the-ethereum-2-0-beacon-chain-explained-9fa1666bbb21

Über Consensys

Consensys ist das führende Blockchain- und web3-Softwareunternehmen. Seit 2014 steht Consensys an der Spitze der Innovation und leistet Pionierarbeit bei technologischen Entwicklungen innerhalb des web3-Ökosystems. Durch unsere Produktpalette, einschliesslich der MetaMask-Plattform, Infura, Linea, Diligence und unserer NFT-Plattform, sind wir zu einem vertrauenswürdigen Partner für Nutzer, Schöpfer und Entwickler geworden. Ob es um den Aufbau einer App, einer NFT-Sammlung, eines Portfolios oder einer besseren Zukunft geht – der Instinkt, etwas aufzubauen, ist universell. Unsere Mission ist es, den Erbauer in jedem zu inspirieren und zu befähigen, indem wir web3 universell einfach zu nutzen und zu entwickeln machen. Lasst uns die Welt bauen, die wir sehen wollen. Weietere Informationen findest du hier.