Zum Inhalt springen
Financial Context Wiki

Trennung von Proposer und Builder (PBS)

PBS trennt Blockbau und Konsensvorschlag. Der Artikel erklärt Ethereums MEV-Boost-Markt, den Unterschied zu protokollinterner PBS sowie Relay-, Zensur-, Konzentrations- und Slot-Ausfallrisiken.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Validator-Betriebsberatung. PBS beseitigt keine MEV-, Zensur-, Slot-Ausfall-, Relay-, Builder-Konzentrations- oder Protokolldesignrisiken.

Direkte Antwort

Die Trennung von Proposer und Builder (PBS) teilt zwei Aufgaben der Blockproduktion. Ein Builder wählt und ordnet Transaktionen und baut eine Ausführungsnutzlast; der per Konsens für den Slot gewählte Proposer wählt eine Nutzlastzusage, signiert den Blockvorschlag und verbreitet den vollständigen Block oder veranlasst dessen Veröffentlichung. Der Proposer bleibt ein Validator mit Konsenspflichten. Der Builder ist eine eigene Marktrolle und muss im heutigen externen Markt nicht der Validator des Slots sein.

Bei Ethereum ist das heutige System von vorgeschlagenen Protokolländerungen zu trennen. MEV-Boost ist PBS außerhalb des Protokolls: Validator-Middleware fragt Relays ab, die eine Auktion zwischen Buildern und Proposern vermitteln. Protokollinterne PBS (ePBS) würde Austausch und Durchsetzung in Ethereums Konsensregeln verankern. Zum Prüfdatum beschreibt Ethereum dies als Forschung ohne endgültige Spezifikation; EIP-7732 bleibt ein Entwurf.

PBS soll Validatoren wettbewerbsfähigen Blockwert erschließen, ohne dass jeder eine anspruchsvolle MEV-Suche und Blockbau-Infrastruktur betreibt. Das kann einen Zentralisierungsvorteil unter Proposern mindern, beseitigt MEV aber nicht. Spezialisierter Blockbau wandert in einen Markt; zugleich entstehen Fragen zu Relay-Vertrauen, Konzentration von Buildern und Orderflow, Zensur, Timing und Nutzlastverfügbarkeit.

Funktionsweise

  1. Builder bauen und bieten. Sie erhalten öffentliche Transaktionen und oft privaten Orderflow oder Searcher-Bundles, simulieren Blöcke, ordnen Transaktionen, erstellen eine gültige Nutzlast und fügen ein Gebot als angebotene Zahlung an den Proposer an.
  2. Relays vermitteln den heutigen Markt. Bei MEV-Boost erhält das Relay die vollständige Nutzlast, prüft sie nach eigenen Regeln und zeigt dem Proposer zunächst nur signierten Header und Gebot. MEV-Boost kann mehrere konfigurierte Relays abfragen und nutzbare Antworten vergleichen.
  3. Der Proposer wählt eine Zusage. Er kann externe Gebote mit lokaler Nutzlast vergleichen und etwa ein Mindestgebot anwenden. Akzeptiert er extern, signiert er einen verblindeten Beacon-Block mit Bindung an den Header und kann danach keine anderen Transaktionen einsetzen.
  4. Die Nutzlast wird offengelegt und geprüft. Nach dem signierten verblindeten Block liefert oder veröffentlicht das Relay die vollständige Nutzlast. Konsens- und Ausführungsclients prüfen den Block. Verspätete, fehlende oder ungültige Nutzlast kann die Veröffentlichung verhindern und einen Slot-Ausfall verursachen.
  5. Zahlung und Konsens bleiben getrennt. Das Gebot ist die versprochene Ausführungsebenen-Zahlung an den konfigurierten Gebührenempfänger. Konsensbelohnungen und Strafen folgen eigenen Regeln. Die Builder-Wahl überträgt keine Finalitäts- oder Fork-Choice-Befugnis.

Die Builder API standardisiert Validator-Registrierung, Header-Abruf und Einreichung signierter verblindeter Blöcke. Eine API ist keine Vertrauensgarantie: Zulassung, Prüfung, Datenverarbeitung und Fehlerverhalten des Relays hängen von Implementierung und Betrieb ab.

Beispiel

Ein lokaler Client könne eine Nutzlast im Wert von 0.03 ETH bauen; nutzbare Relay-Gebote seien 0.05 ETH, 0.08 ETH und 0.07 ETH. Ohne Latenz- und Ausfallkosten bietet das höchste externe Gebot einen Bruttovorteil von 0.05 ETH:

Bruttovorteil = Builder-Gebot - lokaler Nutzlastwert = 0.08 ETH - 0.03 ETH = 0.05 ETH

Der Proposer wählt den Header zu 0.08 ETH und signiert ohne vollständige Transaktionsliste. Das Relay liefert oder veröffentlicht die gebundene Nutzlast. Ist der Block gültig und rechtzeitig, verarbeitet ihn das Netzwerk und der Gebührenempfänger erhält die Zahlung. Der Proposer erfüllt weiter seine Konsensrolle; der Builder bestimmt nicht Kanonizität oder Finalität.

Der Vergleich garantiert keinen Nettoertrag. Relay-Latenz, fehlende Offenlegung, Softwareverhalten, Zahlungsprüfung sowie Wahrscheinlichkeit und Kosten eines Slot-Ausfalls zählen. Erfüllt kein Gebot rechtzeitig die Richtlinie, kann ein korrekt konfigurierter Client lokal bauen.

Risiken

  • Relay-Vertrauen und Verfügbarkeit: Heutige MEV-Boost-Relays vermitteln den Austausch, sehen Nutzlasten, wenden Richtlinien an und liegen auf einem zeitkritischen Pfad. Vielfalt senkt Einzelabhängigkeit, garantiert aber keine Ehrlichkeit oder Verfügbarkeit jedes Relays.
  • Builder- und Orderflow-Konzentration: Besserer privater Orderflow, Latenz, Kapital oder Simulation kann mehr Blockgewinne ermöglichen. Eine Auktion garantiert weder dezentralen Bau noch neutrale Aufnahme.
  • Zensur und Datenschutz: Builder oder Relays können Transaktionen weglassen; Intermediäre können privaten Orderflow sehen. Vorgeschlagene Inklusionslisten sind eigenständige Designs; heutige PBS erzwingt nicht jede gültige Transaktion.
  • Timing, Zurückhalten und Slot-Ausfälle: Ein hohes Gebot nutzt nur bei gültiger, rechtzeitiger Nutzlast. Zurückhalten, Relay-Ausfall, Netzverzögerung oder Fehlkonfiguration können Belohnungen mindern oder den Slot kosten.
  • Veränderliche Annahmen: ePBS-Entwürfe wie EIP-7732 ändern Zahlung, Offenlegung, Prüfung und Fork Choice. Maßgeblich ist die Spezifikation des bereitgestellten Forks, nicht eine Roadmap als aktuelle Garantie.

Häufige Irrtümer

Irrtum 1: PBS beseitigt MEV

PBS trennt Blockbau und Vorschlag. Builder konkurrieren weiter um MEV; das Design soll dessen zentralisierende Wirkung auf Validatoren mindern und Blockwert über Gebote verteilen.

Irrtum 2: Der Builder schlägt den Block vor oder finalisiert ihn

Der Builder baut die Nutzlast. Der Proposer signiert, andere Validatoren attestieren, und Fork-Choice- sowie Finalitätsregeln bestimmen die kanonische Kette.

Irrtum 3: MEV-Boost ist bereits vertrauenslose, protokollerzwungene PBS

MEV-Boost ist externe Middleware mit Relays. Sie nähert PBS ohne Konsensänderung an; ihre Vertrauens- und Fehlerannahmen unterscheiden sich von künftigem ePBS.

Irrtum 4: Das höchste angezeigte Gebot ist immer optimal

Der Betrag ist nur ein Faktor. Gültigkeit, Lieferzeit, Relay-Verhalten, lokaler Fallback, Gebührenempfänger und Slot-Ausfallrisiko beeinflussen das Ergebnis.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...