Ethereums Weg zum Widerstand gegen die Zensur: BRAID vs. FOCIL

In der sich entwickelnden Ethereum-Landschaft hat der Kampf gegen Zensur mehrere innovative Mechanismen eingeführt. Unter diesen sind BRAID und FOCIL zwei vielversprechende Ansätze, die die Integrität des Netzwerks schützen sollen, indem sie das Risiko der Transaktionszensur minimieren.

Beide Lösungen befassen sich mit kritischen Fragen im Blockantragsverfahren, verfolgen aber grundlegend unterschiedliche Ansätze, um ihre Ziele zu erreichen. Dieser Artikel befasst sich mit den Nuancen dieser beiden Mechanismen und geht der Frage nach, welcher sich letztlich als effektiver erweisen könnte.

Die Bedrohung durch Zensur in Ethereum verstehen

Im Mittelpunkt des Blockerzeugungs- und -validierungsprozesses von Ethereum stehen zwei Hauptakteure: Builder und Proposer. Builder sind für die Sortierung von Transaktionen und die Übermittlung eines Blocks an Proposer zuständig, die dann einen Block auswählen, der signiert und der Blockchain.

Dieses Verfahren birgt jedoch eine potenzielle Schwachstelle. Da die Antragsteller das letzte Wort darüber haben, welcher Block vorgeschlagen wird, besteht das Risiko einer geheimen Absprache zwischen Antragstellern und Erbauern, um bestimmte Transaktionen zu zensieren, wodurch Ethereums Prinzip der Zensurresistenz gefährdet wird.

Der Widerstand gegen Zensur ist entscheidend für die Aufrechterhaltung der Fairness und Transparenz der Blockchain. Wenn Antragsteller selektiv Transaktionen ein- oder ausschließen können, untergräbt dies den dezentralen Charakter des Netzwerks und kann zur Ausnutzung der Transaktionsreihenfolge führen, was zu Problemen wie Miner Extractable Value (MEV) führt.

Bestehende Lösungen: MCP und FOCIL

Zur Bewältigung dieser Herausforderung wurden mehrere zensurresistente Lösungen vorgeschlagen, von denen zwei der meistdiskutierten die Force Inclusion List (FOCIL) und die Multi-Concurrent Proposer (MCP)-Mechanismen sind.

Force Inclusion List (FOCIL)

FOCIL ist so konzipiert, dass Fairness gewährleistet ist, indem ein zufällig ausgewählter Ausschuss von Prüfern während jedes Zeitfensters einbezogen wird.

Diese Prüfer erstellen auf der Grundlage ihrer Ansichten über den Mempool lokale Aufnahmelisten und verbreiten diese Listen.

Der Vorschlagende fasst dann diese lokalen Listen zu einer endgültigen Aufnahmeliste zusammen, die dem Block hinzugefügt wird.

Dieser Mechanismus stellt sicher, dass kein einzelner Antragsteller die vollständige Kontrolle über die in einem Block enthaltenen Transaktionen hat, wodurch das Risiko einer Zensur verringert wird.

Die Validatoren überprüfen, ob der Block den Konsensregeln entspricht, bevor sie ihn in die Blockchain aufnehmen.

Multi-Concurrent Proposer (MCP)

MCP führt das Konzept mehrerer gleichzeitiger Antragsteller ein, wie es erstmals von Max Resnick im Rahmen des Multiplicity-Mechanismus vorgeschlagen wurde.

In diesem System arbeiten mehrere Proposer parallel und wählen jeweils einen Teil der Transaktionen aus dem Mempool aus.

Diese Transaktionen werden in „spezielle Transaktionsbündel“ verpackt und von den Antragstellern unterzeichnet. Der federführende Antragsteller muss mindestens zwei Drittel dieser Pakete in den vorgeschlagenen Block aufnehmen, damit dieser als gültig betrachtet wird.

Diese Methode dezentralisiert die Macht eines einzelnen Antragstellers und senkt die Wahrscheinlichkeit einer Transaktionszensur erheblich.

BRAID: Eine erweiterte MCP-Implementierung

Aufbauend auf dem MCP-Konzept entwickelte Max Resnick BRAID weiter, eine anspruchsvollere und vollständigere MCP-Implementierung.

BRAID, das während des von Paradigm veranstalteten Seminars „DeFi in MEV Era“ vorgestellt wurde, ermöglicht es mehreren Antragstellern, gleichzeitig Blöcke auf verschiedenen parallelen Ketten vorzuschlagen.

Diese Blöcke werden dann über einen Konsensmechanismus synchronisiert, um die Konsistenz zwischen den Ketten zu gewährleisten.

Die Ausführungsschicht von Ethereum fasst alle Blöcke, die innerhalb des Slots generiert werden, in einem einzigen Ausführungsblock zusammen, in dem die Transaktionen dedupliziert, geordnet und nach vordefinierten Regeln ausgeführt werden.

Durch diesen Ansatz wird die Macht einer einzelnen Stelle, Transaktionsdatensätze zu manipulieren, erheblich eingeschränkt.

Ein wesentlicher Vorteil von BRAID ist die Vermeidung zusätzlicher Rollen oder komplexer Anreizstrukturen, die die Komplexität erhöhen können.

Die Koordinierung der Synchronisierung über mehrere Unterketten hinweg und die Verarbeitung der Daten stellt jedoch eine eigene Herausforderung dar.

Herausforderungen und Überlegungen bei BRAID

Trotz seiner Stärken ist BRAID nicht unproblematisch. Eine bemerkenswerte Herausforderung ist das „bedingte Trinkgeld“-Modell, das von den Nutzern verlangt, dass sie über Liquidität verfügen, um sicherzustellen, dass ihre Transaktionen zensurresistent sind. Die Nutzer müssen zwei Trinkgeldwerte festlegen, wenn sie Transaktionen einreichen:

1. Höhere Spitze (T): Der Höchstbetrag, den ein Nutzer zu zahlen bereit ist, um sicherzustellen, dass seine Transaktion auch bei einem Zensurversuch berücksichtigt wird. Wenn nur ein Antragsteller die Transaktion aufnimmt, erhält er den vollen Betrag von T.
2. Untere Spitze (t): Ein kleineres Trinkgeld, das gezahlt wird, wenn mehrere Antragsteller die Transaktion angeben. In diesem Fall wird das Trinkgeld auf die Antragsteller verteilt, die die Transaktion aufnehmen.

Dieses Modell ist zwar ein wirksames Mittel gegen Zensur, bringt aber zusätzliche Komplexität und Kosten für die Nutzer mit sich. Sie müssen zum Zeitpunkt der Transaktion zusätzliche Liquidität reservieren, die eingefroren werden kann, bis festgestellt wird, ob sie benötigt wird.

Um diese Probleme anzugehen, schlägt Jonahb von Blockchain Capital zwei mögliche Lösungen vor:

• Nachweis der poststaatlichen Liquidität: Bei diesem Ansatz können die Nutzer nachweisen, dass sie nach Ausführung der Transaktion über genügend Liquidität verfügen, um das höhere Trinkgeld zu zahlen. Dies setzt jedoch voraus, dass die Antragsteller den Zustand nach der Transaktion verstehen, was bei Transaktionen, die einen gemeinsamen Zustand oder komplexe Finanzoperationen beinhalten, eine Herausforderung darstellt.
• Versicherung gegen Zensur: Dieses Konzept sieht die Einführung von Drittanbietern von Zensurversicherungen vor, die gegen eine Gebühr für den Tipp des Nutzers garantieren. Dies verringert die unmittelbare Liquiditätsbelastung der Nutzer, erfordert aber die Entwicklung eines Marktes zwischen Nutzern und KI-Anbietern.

Perspektiven der Gemeinschaft: FOCIL vs. BRAID

Die Ethereum-Community ist geteilter Meinung über die relativen Vorzüge von FOCIL und BRAID. Terence, ein Entwickler des Ethereum-Clients Prysm, schätzt, dass BRAID keine zusätzlichen Teilnehmer erfordert, was den Prozess im Vergleich zu FOCIL vereinfacht, das zusätzliche zeitliche Einschränkungen für die Einreichung und Überprüfung von Einschlusslisten mit sich bringt. FOCIL wird jedoch allgemein als einfacher zu implementieren und flexibler angesehen.

Dan Robinson, ein Forscher bei Paradigm, lobt BRAID für seinen Ansatz zur Priorisierung von Transaktionen, der die MEV-Risiken effektiv reduziert. Er hebt auch den bedingten Kippmechanismus als starken Anreiz gegen Zensur hervor – ein Aspekt, der bei FOCIL fehlt.

Umgekehrt bevorzugt der Entwickler Dev FOCIL wegen seiner Einfachheit und robusten Zensurresistenz, was darauf hindeutet, dass FOCIL eine einfachere Implementierung mit weniger Komplikationen bietet.

Der Ethereum-Forscher barnabe.eth räumt ein, dass BRAID zwar in bestimmten Bereichen Verbesserungen bieten kann, ist jedoch vorsichtig, das Leader-basierte Modell, auf dem FOCIL und andere IL-Designs aufbauen, vollständig aufzugeben, und verweist auf die Notwendigkeit weiterer Forschung und Beweise, um die Machbarkeit von BRAID zu validieren.

Schlussfolgerung: Welcher Mechanismus ist der bessere?

Die Debatte zwischen BRAID und FOCIL unterstreicht die Komplexität der Erreichung von Zensurresistenz in Ethereum. BRAIDs innovativer Ansatz zur Dezentralisierung der Proposer-Macht und zur Verringerung des MEV-Risikos ist überzeugend, bringt jedoch erhebliche Herausforderungen bei der Implementierung mit sich und erfordert weitere Entwicklung.

FOCIL ist zwar einfacher und flexibler, bietet aber möglicherweise nicht den gleichen Grad an Robustheit gegenüber ausgeklügelten Zensurversuchen.

Letztendlich kann die Wahl zwischen BRAID und FOCIL von den spezifischen Prioritäten des Ethereum-Netzwerks zu einem bestimmten Zeitpunkt abhängen. Während sich das Ökosystem weiterentwickelt, könnten beide Mechanismen eine Rolle bei der Stärkung von Ethereums Widerstand gegen Zensur spielen und sicherstellen, dass das Netzwerk seinen dezentralen Prinzipien treu bleibt.