Der Blockaufbau ist ein entscheidender Aspekt des Ethereum-Lebenszyklus und besteht aus verschiedenen beweglichen Teilen. Er bestimmt, welche Transaktionen in welcher Reihenfolge in einen Block aufgenommen werden, was sich direkt auf die Netzwerkeffizienz, Dezentralisierung und Fairness auswirkt. Im Laufe der Zeit hat sich der Blockproduktionsprozess von Ethereum weiterentwickelt, insbesondere durch die wachsende Rolle von MEV und den Übergang von der validatorgesteuerten Auswahl zu spezialisierten Blockaufbauern. In diesem Beitrag wird erläutert, wie sich der Ethereum-Blockaufbau im Zuge der Einführung der Proposer Builder Separation und zukünftiger Forschung weiterentwickelt hat. Einführung in die Komponenten des Ethereum-Blockbaus Slots und Epochen Ethereum organisiert die Zeit in diskrete Einheiten: Ein Slot ist ein 12-sekündiger Zeitraum, in dem ein einzelner Block vorgeschlagen werden kann. Wenn innerhalb eines Slots kein Validator einen Block einreicht, wird dieser übersprungen. Slot: Eine Epoche besteht aus 32 Slots mit einer Gesamtlänge von . Epoche: 6,4 Minuten Am Ende jeder Epoche werden die Validierer-Aufgaben neu verteilt, um Dezentralisierung und Sicherheit zu gewährleisten. Ethereum erreicht nach wirtschaftliche Endgültigkeit. Danach ist es nahezu unmöglich, die Blöcke rückgängig zu machen. zwei Epochen (~12,8 Min.) Ausschüsse verfügt über eine große Anzahl von Validatoren im Netzwerk. Laut sind zum Zeitpunkt des Schreibens 1.051.349 Validatoren aktiv. Es wäre nicht praktikabel, wenn so viele Validatoren jeden Block alle 12 Sekunden verifizieren müssten. Daher sind die Validatoren in aufgeteilt, um Transaktionen effizient zu validieren und die Blockgültigkeit zu bestätigen. Ethereum beaconcha.in Komitees Jeder Ausschuss: Besteht aus einer Teilmenge von Validierern, die zu Beginn einer Epoche mithilfe von RANDAO zufällig zugewiesen werden. Stellt sicher, dass kein einzelner Prüfer unverhältnismäßigen Einfluss hat. Nimmt an der Abstimmung (Bestätigung) über Blöcke teil und bestätigt deren Gültigkeit. Die Größe eines Komitees hängt von der Gesamtzahl der aktiven Validierer im Netzwerk ab, aber im Allgemeinen hat jedes Komitee mindestens 128 Validierer. In jedem Steckplatz: Pro Slot sind beispielsweise Komitees zugewiesen, und jedes Komitee verfügt über Validierer (wobei > 128). Das bedeutet, dass es für jeden Slot Bestätigungen gibt. Wie Sie verstehen, kann es für das Netzwerk schnell zu viel werden, so viele Bestätigungen zu verarbeiten. N M M NxM Die Aggregatoren in jedem Ausschuss sind damit beauftragt, die Bestätigungen ihres jeweiligen Ausschusses zu aggregieren. Das bedeutet, dass es aus einem Ausschuss von Validierern nur eine endgültige anstelle von gibt. M Aggregated Attestation M In jedem Slot werden also insgesamt Attestierungen (1 für jedes Komitee dieses Slots) zum globalen Thema übermittelt. Der Antragsteller des nächsten Slots übernimmt diese Attestierungen. N N Einige Punkte, die Sie beachten sollten Während einer Epoche ist jeder aktive Validierer Mitglied genau eines Komitees, sodass alle Komitees der Epoche disjunkt sind. Das Protokoll passt die Gesamtzahl der Ausschüsse in jeder Epoche entsprechend der Anzahl der aktiven Validierer an. Der aktuelle Entwurf sieht Ausschüsse pro Slot vor, d. 64 N=64 Vorausschau des Antragstellers Das Shuffling der Beacon-Chain ist so konzipiert, dass mindestens eine Vorausschau auf die bevorstehenden Ausschusszuweisungen des Validators zur Bestätigung der durch Shuffling und Slot vorgegebenen Bestätigungen möglich ist. , dass diese Vorausschau nicht für Vorschläge gilt, die während der betreffenden Epoche überprüft werden müssen. Epoche (32 Slots) Beachten Sie kann zu Beginn jeder Epoche aufgerufen werden, um die Zuweisung für die nächste Epoche abzurufen ( ). Dies ermöglicht es Validierern auch, die Subnetz-ID zu berechnen, dem jeweiligen Komitee beizutreten und sich auf ihre Aufgaben vorzubereiten. get_committee_assignment current_epoch + 1 Zusätzlich kann ein Validator als eines bestimmten Komitees zugewiesen werden. In diesem Fall muss er das entsprechende Thema ebenfalls abonnieren. Aggregator Pflichten des Antragstellers Innerhalb jedes Slots wird ein als für die Erstellung und Übermittlung eines Blocks ausgewählt. einzelner Validierer aus dem jeweiligen Komitee Antragsteller Die Rolle des Antragstellers ist von entscheidender Bedeutung, da er: Erstellen Sie einen Block, indem Sie ausstehende Transaktionen und Bestätigungen einschließen. Signieren und senden Sie den an das Netzwerk. SignedBeaconBlock Verdienen Sie Belohnungen für das erfolgreiche Vorschlagen gültiger Blöcke. Kurze Einführung in MEV MEV ist der zusätzliche Gewinn, den Validierer (früher Miner) durch Neuanordnung, Einbeziehung oder Zensur der Transaktionen innerhalb eines Blocks erzielen. Einige gängige MEV-Strategien sind: : Platzieren eines Handels kurz vor einer bekanntermaßen profitablen Transaktion. Frontrunning gilt auch als toxisches MEV, da es den Benutzer mit einem negativen Effekt überrascht. Frontrunning : Ausführen einer Transaktion direkt nach einem bestimmten Ereignis (z. B. Arbitrage-Bots). Back-Running : Eine Kombination aus Front-Running und Back-Running, insbesondere bei DeFi-Trades. Sandwich-Angriffe Wer extrahiert MEV? : Als Validatoren die Blockproduktion kontrollierten, hatten sie die volle Entscheidungsfreiheit über die Reihenfolge der Transaktionen und konnten MEV direkt extrahieren. Validatoren (vor PBS) : Unabhängige Akteure, die den Mempool nach MEV-Gelegenheiten durchsuchen und entsprechende Transaktionen übermitteln. Sucher : Nach PBS übernehmen Blockbuilder die Aufgabe, MEV-optimierte Blöcke zu konstruieren, während Validatoren einfach Blöcke vom Höchstbietenden auswählen. Builder (nach PBS) Blockaufbau vor PBS: Validator-zentriertes MEV Bevor Ethereum zu PBS wechselte, hatte der Antragsteller (früher Miner in PoW) . Dadurch entstand ein Ökosystem, in dem MEV direkt von Validierern extrahiert oder an spezialisierte Sucher ausgelagert wurde. die volle Kontrolle über die Transaktionsreihenfolge So funktionierte es vor PBS: : Transaktionen werden wie gewohnt gesendet und gelangen in den Mempool. Transaktionspool Validatoren wählen Transaktionen aus dem Mempool aus. Diese könnten nach der sogenannten sortiert werden. Dabei handelt es sich um die Gebühren, die der Benutzer bereit ist zu zahlen, um zuerst aufgenommen zu werden. Die Sortierung könnte auch so erfolgen, dass der Validator mehr Umsatz erzielt (durch Sandwich/Frontrunning). priority_fee Der Validator erstellt den Block auf Grundlage der von ihm ausgewählten Transaktionen. : Der signierte Block wird an das Netzwerk gesendet. Blockausbreitung Dies ist zur Vereinfachung etwas locker abstrahiert. Aber das war der allgemeine Ablauf. Dies kann als bezeichnet werden. Vanilla Block Building Probleme mit dem Blockaufbau vor PBS : Große Validierer hatten gegenüber kleineren einen wirtschaftlichen Vorteil, da sie MEV effizienter extrahieren konnten. Zentralisierung der MEV-Leistung : Prüfer könnten Transaktionen ausschließen, die nicht mit ihren finanziellen Anreizen übereinstimmen. Erhöhtes Zensurrisiko : Die Bieterkriege um MEV-Transaktionen führten zu einer ineffizienten Blockplatznutzung und erhöhten die Kosten für normale Benutzer. Netzwerküberlastung und hohe Gasgebühren Block Building Post-PBS: Trennung von Antragstellern und Erbauern Um den Zentralisierungsrisiken und Ineffizienzen der validatorgesteuerten Blockkonstruktion zu begegnen, wurde eingeführt. PBS teilt die Verantwortung für die Blockproduktion auf zwei separate Einheiten auf: die Proposer-Builder-Separation (PBS) : Unternehmen, die auf die Konstruktion optimierter Blöcke spezialisiert sind und dabei häufig MEV-Strategien einbeziehen. Block Builders : Validatoren erstellen die Blöcke nicht mehr selbst, sondern wählen einfach den profitabelsten Block aus, der von den Erstellern angeboten wird. Block-Vorschläger (Validatoren) So funktioniert es nach PBS: : Blockbauer konkurrieren darum, den profitabelsten Block zu errichten und berücksichtigen dabei die Möglichkeiten zur MEV-Gewinnung. Bauherren errichten Blöcke : Ersteller bieten, um ihren Block den Prüfern vorzuschlagen und stellen so sicher, dass die Prüfer die profitabelste Option erhalten. Bieten auf Blockaufnahme : Anstatt einzelne Transaktionen auszuwählen, wählen Validatoren einfach den Builder-Block mit dem höchsten Gebot aus und maximieren so ihre Belohnungen. Validatoren wählen das höchste Gebot aus So funktioniert der Ethereum-Blockaufbau jetzt Der Benutzer übermittelt die Transaktion über eine per JSON-RPC verbundene Brieftasche. Diese Transaktion wird in den öffentlichen Mempool übertragen. Alle Transaktionen werden hier abgelegt, bevor sie abgerufen und validiert werden. haben in letzter Zeit an Bedeutung gewonnen, da die meisten großen Akteure sich dafür entscheiden, da sie die öffentliche Übertragung Ihrer Transaktionen über autorisierte/private Kanäle umgehen. Weitere Informationen finden Sie im Dashboard von . Private Orderflows Dune → externe Einheiten, die den Mempool kontinuierlich nach MEV-Möglichkeiten durchsuchen ( ). Sie holen die entsprechenden Transaktionen ab und fügen bei Bedarf eigene ein, um Gewinn zu erzielen. Anschließend erstellen sie ein Bündel dieser Transaktionen, dessen Reihenfolge durchgehend beibehalten werden muss, damit der Sucher Gewinn erzielen kann. Bündel sind geordnete Transaktionen, die atomar ausgeführt werden müssen. Zusätzlich zu diesem Bündel können sie am Ende des Bündels eine Transaktion hinzufügen, die eine Bestechung des Builders darstellt. Dieses Bündel wird über den Aufruf an den Builder gesendet. Sucher mehr dazu weiter unten eth_sendBundle : Sucher sind externe Einheiten und beeinflussen die Reihenfolge der Transaktionen, nehmen jedoch nicht an der Blockvalidierung oder Konsensentscheidungen teil. Hinweis → Die nächste Entität ist der Builder, der den Block tatsächlich erstellt. Er versucht, sowohl die Gebühreneinnahmen als auch die MEV-Einnahmen zu maximieren. Er integriert die von den Suchern gesendeten gebündelten Transaktionen (hoffentlich in der richtigen Reihenfolge) und akzeptiert die von den Suchern gesendete Zahlung (Bestechungsgeld). Builder konstruieren Ausführungsnutzlasten aus empfangenen Transaktionen. Builder Sie füllen die Blöcke mit: Von den Suchern gesendete Bündel. Transaktionen mit hoher Priorität. Bestellen Sie allgemeine Transaktionen und achten Sie dabei auf die Umsatzmaximierung. Sie setzen außerdem das Feld auf ihre eigene Adresse, um anzuzeigen, dass sie sowohl die Bestechungsgelder des Suchers als auch alle Gebühren aus den Transaktionen in ihrem eingereichten Block erhalten. Die Ersteller reichen am Ende ihres Blocks eine Transaktion ein, die als Bestechungsgeld für den Antragsteller dient, ähnlich wie der Sucher für den Ersteller. feeRecipient : Builder sind externe Einheiten und interagieren nicht direkt mit der Blockchain. Hinweis → Der Builder-Markt ist ein wettbewerbsintensiver Markt mit verschiedenen Buildern, die ihre Payloads finalisieren möchten, um Gebühren zu verdienen. Die meisten Blöcke werden jedoch von einigen wenigen bekannten Block Buildern, nämlich und Um diesen Prozess für den eigentlichen Anbieter zu vereinfachen, fungieren Relays als Zwischeninstanzen, die die von den verschiedenen Buildern gesendeten Payloads validieren und diejenige mit dem höchsten Gewinn/Gebot auswählen. Die Kommunikation zwischen Relay und Anbieter nutzt einen cleveren Trick, ähnlich einem Commit and Reveal, um sicherzustellen, dass der Anbieter bis dahin nicht alle Einheiten betrügt. Mehr dazu . Relays BeaverBuild Titan, erstellt. hier Zusammenfügen Relay-Proposer-Kommunikation Es ist durchaus möglich, dass der Antragsteller nach Erhalt der Blocknutzlast den Block entpackt, seine Transaktionen einfügt, die Reihenfolge nach Belieben ändert und den auf seine eigene Adresse setzt. Dies würde bedeuten, dass jede einzelne Entität, die bisher am Blockaufbauprozess beteiligt war (Sucher → Ersteller → Relais), betrogen wird oder „MEV-Diebstahl“ begeht. Um dies zu verhindern, sendet das Relais nur den Header der ausgewählten Blocknutzlast. Dies geschieht, wenn der Antragsteller den Aufruf startet. Das Relais sendet nun einen , der den Hash des Blocks, das Gebot und die Signatur des Erstellers enthält. feeRecipient eth_getPaylaodHeader PayloadHeader Der Antragsteller hat an dieser Stelle zwei Möglichkeiten: Um den vom Relay bereitgestellten (auch genannt) auszuwählen, muss der Antragsteller den Header mit seinem Schlüssel signieren, an das Relay zurücksenden und anschließend den mit dem Aufruf anfordern. Anschließend führt das Relay den Aufruf aus, der die gesamte an den Antragsteller zurückgibt. Dieser schlägt diesen Block dann dem Ethereum-Validator-Netzwerk bzw. dem ihm zugewiesenen Komitee vor. PayloadHeader Blinded Block PayloadBody eth_returnSignedHeader eth_sendPayload ExecutionPayload Der Antragsteller kann den vom Relay gesendeten ablehnen und muss den Block dann selbst erstellen. Dazu gehört das Auffinden von MEV-Gelegenheiten und die entsprechende Anordnung der Transaktionen. In diesem Fall behält der Antragsteller natürlich die gesamten Einnahmen aus den Gebühren + MEV. Dies ist jedoch nicht so einfach, wie es scheint. Das Auffinden von MEV und die Optimierung der Einnahmen ist eine rechenintensive Aufgabe, und es besteht die Möglichkeit, dass der Antragsteller den Block nicht rechtzeitig (12 Sekunden) erstellen kann, wodurch ein Slot verpasst wird. In diesem Fall kann der Antragsteller vom Netzwerk ausgeschlossen werden. PayloadHeader Aber was passiert im Fall 1, wenn der Antragsteller den vom Relay gesendeten Block nicht sendet? Genau aus diesem Grund muss der Antragsteller den signieren. Vor dem Senden des Headers übergibt das Relay den zur sicheren Aufbewahrung an einen . Sobald das Relay den signierten vom Antragsteller erhält, überprüft es die Signatur und sendet den im Treuhänder gespeicherten an den Antragsteller. Nehmen wir nun an, der Antragsteller schließt diesen Block nicht ein. Er erstellt einen eigenen Block und ignoriert dabei die bisherige Reihenfolge. In diesem Fall stimmt die Signatur nicht überein, da sich die Header geändert haben. PayloadHeader PayloadBody Escrow PayloadHeader PayloadBody : Hinweis Das Unterzeichnen von zwei verschiedenen Headern für denselben Vorschlagsplatz stellt eine Straftat dar. Der Builder kann diese widersprüchlichen signierten Header jetzt an das Netzwerk senden und der Proposer kann aus dem Netzwerk entfernt werden. Was hindert Builders daran, Transaktionen zu zensieren? Nun, nichts. Der häufigste Grund, warum Builder eine Transaktion zensieren, ist die Interaktion mit . OFAC-Adressen Vereinfacht gesagt: OFAC befasst sich mit Transaktionen, die rechtliche Konsequenzen haben können, die natürlich niemand auf dem Gewissen haben möchte. Laut enthalten die von Builders erstellten Blöcke nur 0–7 % der vom OFAC genehmigten Transaktionen. Censorship.pics Wie lösen wir das? Eine der zum Zeitpunkt des Schreibens dieses Artikels bekanntesten Lösungen zur Transaktionszensur sind . Inclusion Lists sind eine Liste von Transaktionen (zusammen mit einer sogenannten Zusammenfassung), die vom Antragsteller des Slots N zusammen mit dem Vorschlag für den Block von Slot N veröffentlicht werden. Einschlusslisten Inklusionslisten erzwingen, dass die Transaktionen in der Liste entweder in Block N oder Block N+1 enthalten sein müssen, andernfalls ist der N+1-Block ungültig. Diese Listen werden als Forward Inclusion Lists bezeichnet. : Es gibt auch ein Konzept für , das IL für den aktuellen Block N selbst durchführt. Dieses Design hatte jedoch wirtschaftliche Mängel, die zu Hinweis Spot Inclusion Lists Forward Inclusion Lists führten. Natürlich wird dieses IL-Design keine hundertprozentige Zensurresistenz ermöglichen, aber es wird aktiv daran geforscht, diese Vorschläge zu konkretisieren, und es gibt viele nette Optimierungen, die zur Verbesserung der Anreizstruktur angewendet werden können. FOCIL ist ein neues Design, das 2024 vorgeschlagen wurde und auf Inklusionslisten aufbaut und diese verbessert, um die glaubwürdige Neutralität zu erhöhen. Fork Choice Forced Inclusion Lists (FOCIL) FOCIL ermöglicht es mehreren Validatoren, Vorschläge für die Aufnahmeliste für einen bestimmten Slot zu machen. Genauer gesagt werden für jeden Slot 16 Validatoren zufällig ausgewählt, um ein Aufnahmelistenkomitee zu bilden. Diese Mitglieder bilden jeweils ihre eigene lokale IL und geben diese im Netzwerk weiter. Der Antragsteller sammelt und aggregiert verfügbare lokale Aufnahmelisten zu einer finalen IL. Die IL-Designs sind leichtgewichtig, da der Block nicht neu aufgebaut werden muss, um diese Transaktionen einzuschließen; sie können einfach an den Block angehängt werden. Die Bedingung für einen Block, um die IL-Validierungsanforderung zu erfüllen, lautet: „Ein Block ist gültig, wenn er alle Transaktionen aller ILs enthält, bis der Block voll ist.“ : Die Mitglieder des IL-Komitees können keine Garantie für die Reihenfolge der Transaktionen geben, da die IL-Transaktionen in beliebiger Reihenfolge erfolgen können. Sie garantieren lediglich die Einbeziehung der Transaktionen. Hinweis Vorteile von PBS für das MEV-Management : Blockbuilder und nicht einige wenige große Validierer übernehmen die MEV-Extraktion, wodurch die Risiken der Validiererzentralisierung reduziert werden. Dies ist jedoch ein zweischneidiges Schwert, da wir im Zuge der Abschwächung der Validiererzentralisierung eine Builderzentralisierung eingeführt haben, bei der nur wenige Builder einen großen Anteil der Blöcke erstellen. Dezentralisierung der MEV-Extraktion : Validierer profitieren weiterhin von MEV, ohne sich direkt an der Extraktion zu beteiligen, was die Blockproduktion gerechter macht. Gerechtere Umsatzverteilung : Der Wettbewerb unter den Bauherren führt zu optimierten Blöcken mit besserer Gaseffizienz. Effizientere Blockraumnutzung Herausforderungen von PBS : Während die Validierer dezentralisiert sind, könnten einige wenige dominante Ersteller die MEV-Extraktion dennoch zentralisieren. Zentralisierungsrisiko unter den Erstellern : PBS verlässt sich derzeit auf MEV-Boost-Relais, die Off-Chain betrieben werden und als Fehlerquelle potenzielle Sicherheitsrisiken darstellen. Vertrauen in Off-Chain-MEV-Relais Quellen: Ethereums Trennung von Antragsteller und Ersteller: Versprechen und Realität Stand der Forschung: Zensurresistenz unter PBS Builder-Zensur: Der verrottete Kern von Ethereum EPF Wiki - PBS Hinweise zu PBS Vorwärtseinschlussliste Wer gewinnt Ethereum-Blockbuilding-Auktionen und warum? FOCIL Danksagung Vielen Dank an , und für die Überprüfung und die Vorschläge. @mteam @Gajpower @unnawut
