Im Ethereum-Blockproduktions- und Validierungsprozess sind die Builder dafür verantwortlich, Transaktionen zu ordnen und Blöcke über einen Auktionsmechanismus an die Vorschlägegeber zu übermitteln. Die Vorschlägegeber wählen dann einen Block aus, um ihn zu unterzeichnen und der Blockchain vorzuschlagen. Da die Vorschlägegeber als einzelne Einheit das letzte Wort haben, besteht das Risiko einer Kollusion zwischen Vorschlägegebern und Buildern, um Transaktionen zu zensieren.

Eine der Kernwerte von Blockchain ist ihre Zensurresistenz, was bedeutet, dass Transaktionen ohne Einmischung zentraler Behörden durchgeführt werden können. Wenn Antragsteller jedoch die Kontrolle darüber haben, welche Transaktionen in einem Block enthalten sind, wird diese Funktion bedroht, was Fairness und Transparenz beeinträchtigt. Darüber hinaus kann diese Macht genutzt werden, um die Reihenfolge der Transaktionen in einem Block zu manipulieren, was zu zusätzlichen wirtschaftlichen Gewinnen und Problemen im Zusammenhang mit dem Miner Extractable Value (MEV) führt.

Bestehende zensurresistente Lösungen

Um diese Herausforderung anzugehen, hat die Gemeinschaft mehrere Lösungen gegen Zensur vorgeschlagen, wie z.B. Forced Inclusion Lists (FOCIL). Im FOCIL-Mechanismus wird für jeden Slot eine Gruppe von Validatoren zufällig ausgewählt, um ein Inklusionslisten-Komitee zu bilden. Diese Komiteemitglieder generieren lokale Inklusionslisten auf Basis ihrer subjektiven Ansicht der Mempool und senden sie aus. Anschließend sind die Proposer dafür verantwortlich, diese lokalen Listen zu sammeln und zu aggregieren, um eine einzige aggregierte Liste zu erstellen, die in den Block aufgenommen werden soll. Dieser Mechanismus gewährleistet Fairness bei der Blockaufnahme, da Validatoren die aggregierte Liste gegen die zuvor gesendeten lokalen Listen verifizieren und nur Blöcke akzeptieren, die den Konsensregeln entsprechen und zur Blockchain hinzugefügt werden.

Neben FOCIL hat die Community auch über das Multiple Concurrent Proposers (MCP)-Schema diskutiert. Dieses Konzept wurde ursprünglich von vorgeschlagen.Max Resnickin theVielfaltMechanismus, der darauf abzielt, die Macht zu verteilen, indem er mehrere parallele Block-Proposer einführt und die Fähigkeit eines einzelnen Knotens verringert, Transaktionen zu zensieren. Im Multiplicity-Mechanismus wählt jeder Validator einen Teil der Transaktionen aus seinem eigenen Mempool aus, um ein „spezielles Transaktionspaket“ zu bilden. Diese Validator signieren ihre ausgewählten Transaktionspakete und senden sie an den Vorschlagenden der aktuellen Runde. Der Vorschlagende muss mindestens 2/3 dieser Transaktionspakete in den von ihm vorgeschlagenen Block aufnehmen, damit er als gültig angesehen wird. Dieser Mechanismus stellt sicher, dass Vorschlagende nicht einseitig über den Inhalt des Blocks entscheiden können, wodurch die Möglichkeit der Zensur verringert wird. Um Vorschlagende weiterhin dazu zu incentivieren, Transaktionen fair einzubeziehen, implementiert dieser Mechanismus eine „bedingte Tipp“-Regelung, bei der nur Vorschlagende, die die Transaktion einschließen, die Transaktionsgebühren erhalten. Die Transaktionsgebühren werden nicht automatisch dem ersten Vorschlagenden gegeben, der die Transaktion einschließt, sondern werden an alle Vorschlagenden verteilt, die die Transaktion tatsächlich basierend auf spezifischen Bedingungen einschließen. Dies erhöht die Kosten für Zensur, da es notwendig wäre, alle Vorschlagenden zu bestechen, die die Transaktion einschließen.

BRAID: Eine verbesserte MCP-Implementierung

Aufbauend auf dem Multiplicity-Konzept stellte Max Resnick BRAID vor, eine komplexere und raffiniertere Implementierung von MCP. Max präsentierte BRAIDbeim Seminar "DeFi in der MEV-Ära", das von Paradigm abgehalten wurde. BRAID erreicht MCP, indem es mehreren Antragstellern ermöglicht, Blöcke auf verschiedenen parallelen Ketten vorzuschlagen und einen Synchronisations-Konsensmechanismus verwendet, um die Konsistenz zwischen diesen Ketten aufrechtzuerhalten. Jede Kette hat ihren eigenen Antragsteller, und alle Antragsteller veröffentlichen ihre Blöcke gleichzeitig innerhalb des gleichen Slots. Die Ethereum-Ausführungsschicht aggregiert die von allen Unter-Ketten innerhalb dieses Slots generierten Blöcke und bildet einen Ausführungsblock. Dann werden diese Transaktionen gemäß vordefinierter Regeln dedupliziert, sortiert und ausgeführt, wodurch die Fähigkeit einer einzelnen Entität zur Manipulation von Transaktionsaufzeichnungen reduziert wird.

Das Design von BRAID vermeidet die Einführung zusätzlicher Rollen und vermeidet so die mit Anreiz-/Bestrafungsmechanismen verbundenen Komplexitäten. Allerdings ist die Umsetzung relativ komplex und erfordert die Koordination der Synchronisation und Datenverarbeitung mehrerer Unterstränge.

Probleme mit dem BRAID-Mechanismus

Jonahbvom Blockchain Capital Team hingewiesenProblemmit dem BRAID-Mechanismus: Das Modell des „bedingten Trinkgelds“ stellt Liquiditätsanforderungen auf und beeinflusst die Benutzererfahrung. Dieses Modell ist eine dynamische Preisstrategie, die von Benutzern eine bestimmte Menge an Liquidität erfordert, um die Zensurresistenz von Transaktionen zu gewährleisten. Beim Einreichen einer Transaktion müssen Benutzer zwei Trinkgeldwerte (T und t) festlegen. Das tatsächlich gezahlte Trinkgeld hängt von der Anzahl der Vorschlagenden ab, die die Transaktion einschließen.

1. Ein höherer Trinkgeldwert, T, repräsentiert die maximale Gebühr, die ein Benutzer bereit ist zu zahlen, um sicherzustellen, dass seine Transaktion nicht zensiert wird. Ziel ist es, Anbieter zu incentivieren, die Transaktion einzubeziehen, auch wenn kein anderer Anbieter bereit ist, dies zu tun. Wenn nur ein Anbieter die Transaktion enthält, erhält er den vollen Betrag, T.
2. Ein niedrigerer Trinkgeldwert, t, ist der vom Benutzer festgelegte Mindestbetrag. Wenn die Transaktion gleichzeitig von mehreren Vorschlagenden einbezogen wird, muss der Benutzer nur t zahlen, das unter den Vorschlagenden aufgeteilt wird. Wenn der Benutzer weniger besorgt über die Zensurbeständigkeit ist, kann er T gleich t setzen und seine Transaktion nur an einen Vorschlagenden senden.

Allerdings erhöht diese zusätzliche Liquiditätsanforderung die Komplexität und die Kosten der Teilnahme an Blockchain-Transaktionen. Benutzer müssen zum Zeitpunkt der Transaktion zusätzliche Mittel reservieren, um allein die Zensurbeständigkeit zu gewährleisten. Diese reservierten Mittel bleiben eingefroren, bis sie tatsächlich verwendet werden.

Um dieses Problem zu lösen, schlug Jonahb zwei Lösungen vor:

• Beweis für die Liquidität nach dem Postzustand: Benutzer erbringen einen Nachweis zum Zeitpunkt der Transaktionseinreichung, der darauf hinweist, dass sie nach Ausführung der Transaktion über ausreichende Liquidität verfügen werden, um T zu zahlen (z. B. der Benutzer wird nach der Transaktion über 1 Mio. USD an Liquidität verfügen). Mit dieser Methode können Benutzer fortfahren, auch wenn sie nicht genügend Mittel haben, um T vor der Transaktion zu zahlen. Die Herausforderung bei diesem Ansatz besteht darin, dass die Antragsteller den endgültigen Zustand der Transaktion vor der Ausführung kennen müssen. Viele Finanztransaktionen beinhalten jedoch gemeinsame Zustände (z. B. mehrere Transaktionen, die den gleichen Kontostand beeinflussen), was es für Antragsteller schwierig macht, den Post-Transaktionszustand genau zu bestimmen, bevor die Transaktionsreihenfolge festgelegt ist. Dieser Ansatz erfordert maßgeschneiderte Nachweise für jeden Transaktionstyp, was ihn weniger praktisch macht.
• Zensurversicherung: Einführung von Drittanbieter-Zensurversicherungsanbietern (CI-Anbietern), um die T des Benutzers zu garantieren. Benutzer zahlen eine Versicherungsprämie, rT, wobei r auf der Wahrscheinlichkeit basiert, dass die Transaktion zensiert wird. Dieser Ansatz reduziert die Notwendigkeit für Benutzer, sofort eine große Menge an Liquidität vorzubereiten, und kann Benutzer warnen, wenn ihre T zu niedrig ist und ein hohes Risiko einer Zensur besteht. Die Etablierung eines Marktes zwischen Benutzern und CI-Anbietern dauert jedoch seine Zeit.

Gemeinschaftsgedanken zu FOCIL vs. BRAID

Ethereum-Client Prysm-Entwickler Terence NotizenEin wesentlicher Vorteil von BRAID besteht darin, dass keine zusätzlichen Teilnehmer erforderlich sind. Die meisten Inclusion List (IL)-Designs, einschließlich FOCIL, erfordern einen zusätzlichen Teilnehmer, was Zeitbeschränkungen innerhalb von Ethereum-Slots mit sich bringt, wie z.B. die Zeit für die Einreichung der IL, die Aktualisierung von Geboten und die Überprüfung der IL durch Validatoren. FOCIL ist jedoch im Vergleich zu BRAID einfacher und flexibler umzusetzen.

Paradigm-ForscherDan Robinson schätztBRAIDs Design zur Priorisierung von Transaktionen, die nicht von einem einzigen Anführer (Vorschlagenden) bestimmt wird, um MEV effektiv zu mildern. Darüber hinaus fördert BRAIDs bedingter Trinkgeldmechanismus nicht zensierendes Verhalten, das in FOCIL nicht vorhanden ist.

Entwickler Dev bevorzugtFOCIL über MCP, da er glaubt, dass FOCIL einen stärkeren Widerstand gegen Zensur bietet und einfacher zu implementieren ist. Er schlägt auch einige Verbesserungen vor, um FOCIL leichter bereitzustellen.

Ethereum-Forscherabe.eth AnsichtenFOCIL ist ein ziemlich allgemeiner und skalierbarer Mechanismus. Er erkennt an, dass BRAID einige der Garantien verbessern könnte, die von FOCIL bereitgestellt werden, ist aber vorsichtig, das Führungsmodell vollständig aufzugeben. Er glaubt, dass mehr Arbeit benötigt wird, um die Machbarkeit von BRAID zu beweisen.

Erklärung:

1. Dieser Artikel stammt aus [ChainFeeds Forschung], der Originaltitel lautet "Ethereum's road to censorship resistance: Who is better, BRAID or FOCIL?", das Urheberrecht liegt beim ursprünglichen Autor [0XNATALIE], wenn Sie Einwände gegen den Nachdruck haben, wenden Sie sich bitte an Gate Learn-Team , das Team wird es so bald wie möglich gemäß den relevanten Verfahren bearbeiten.

2. Haftungsausschluss: Die in diesem Artikel geäußerten Ansichten und Meinungen stellen ausschließlich die persönlichen Ansichten des Autors dar und stellen keine Anlageberatung dar.

3. Andere Sprachversionen des Artikels werden vom Gate Learn-Team übersetzt, nicht erwähnt in Gate.io, der übersetzte Artikel darf nicht reproduziert, verteilt oder plagiiert werden.