Anti-Zensur in Protokollen: Wer entscheidet, ob eine Ethereum-Transaktion in die Blockchain aufgenommen wird?

Protokollbasierte Anti-Zensur ermöglicht es, dass keine Transaktion, die den Regeln entspricht, langfristig nur aufgrund der Vorlieben weniger Blockproduzenten ausgeschlossen wird.

In der Welt der Blockchain hören wir oft das Wort: „Anti-Zensur“.

Viele Menschen denken zunächst, dass es sich um einen politisierten, sogar anarchistischen Slogan handelt. Doch für ein global offenes Abrechnungssystem wie Ethereum ist Anti-Zensur zunächst keine politische Haltung, sondern eine sehr spezifische technische Fähigkeit.

Stellen Sie sich vor, Sie initiieren eine Transaktion in Ihrer imToken-Wallet.

Die Signatur ist korrekt, das Kontoguthaben ausreichend und die Gasgebühren sind ebenfalls nicht niedrig, aber die Transaktion wird nicht in einen Block geschrieben, der Status in der Wallet bleibt auf „Ausstehend“, während andere Transaktionen mit ähnlichen oder sogar niedrigeren Gebühren ständig in die Blockchain aufgenommen werden.

Die Frage ist nun, wer das Recht hat zu entscheiden, ob eine Transaktion in einen Block aufgenommen werden kann? Schließlich wenn Ethereum letztlich weiterhin auf einige zentralisierte Akteure angewiesen ist, um zu entscheiden, welche Transaktionen in die Blockchain aufgenommen werden können, dann gibt es keinen wesentlichen Unterschied zu traditionellen Finanzsystemen.

Daher erforscht Ethereum in den letzten Jahren eine Reihe von Anti-Zensur-Mechanismen wie FOCIL und FairFIL, um eine scheinbar einfache, aber tatsächlich sehr wichtige Frage zu beantworten: Wie kann sichergestellt werden, dass jede Transaktion, die den Protokollregeln entspricht, eine faire Chance hat, in einen Block aufgenommen zu werden?

I. Woher kommt die „Zensur“?

---

Um zu verstehen, warum Ethereum diese Mechanismen benötigt, müssen wir zunächst klären, was mit einer Transaktion passiert, nachdem sie aus der Wallet gesendet wurde.

Wenn ein Benutzer eine Transaktion in der Wallet signiert und sendet, gelangt diese Transaktion normalerweise zuerst in den öffentlichen Transaktionspool von Ethereum, auch bekannt als Mempool. Dies ist eher wie ein Wartebereich, in dem viele Transaktionen gespeichert sind, die noch nicht in einen Block geschrieben wurden.

Aber in den Wartebereich zu gelangen, bedeutet nicht, dass die Transaktion bereits in die Blockchain aufgenommen wurde. Es muss jemand die Transaktionen auswählen, um ihre Reihenfolge zu bestimmen, einen vollständigen Block zu bilden und diesen dann zur Bestätigung an das Netzwerk zu übergeben.

Das Problem entsteht genau in diesem Schritt.

Nach dem Upgrade von Ethereum auf das PoS (Proof of Stake)-System wurde, um zu verhindern, dass große Staking-Pools MEV (Maximum Extractable Value) nutzen, um wirtschaftliche Monopole zu bilden, das PBS (Proposer-Builder Separation)-System eingeführt. In diesem Rahmen wird der Verarbeitungsprozess jeder Ethereum-Transaktion in zwei Rollen aufgeteilt:

• Builder: Verantwortlich für das Sammeln von Transaktionen, das Anordnen der Transaktionsreihenfolge, das Suchen nach Arbitrage- und Abwicklungsmöglichkeiten und das Erstellen eines Blocks mit möglichst hohen Erträgen;
• Proposer: Verantwortlich für die Auswahl eines der vom Builder eingereichten Kandidatenblöcke und dessen Einreichung an das Netzwerk;

Diese Aufteilung hat sehr praktische Vorteile.

Es ist allgemein bekannt, dass die MEV-Strategien in den letzten Jahren immer komplexer geworden sind. Wenn jeder normale Validator unabhängig die Transaktionsreihenfolge und Blockoptimierung durchführen müsste, würde dies zweifellos dazu führen, dass große Knoten mit mehr Kapital, Daten und technischen Fähigkeiten einen Vorteil erlangen.

Daher wird die komplexe Blockerstellungsarbeit an professionelle Builder delegiert, sodass normale Validator-Knoten, selbst wenn sie keine fortgeschrittenen Arbitragefähigkeiten besitzen, an der Blockvorschlag teilnehmen und entsprechende Erträge erzielen können, wodurch der Einfluss von MEV auf die Dezentralisierung des Stakings verringert wird.

Es hat jedoch unbeabsichtigt einen weiteren Nebeneffekt mit sich gebracht, nämlich die übermäßige Konzentration der Blockerstellungsrechte. Derzeit werden über 90 % der Ethereum-Blöcke im gesamten Netzwerk nur von wenigen professionellen Buildern produziert, und da diese Builder in der Regel über klare geschäftliche Hintergründe verfügen, sind sie leicht externem Druck durch spezifische nationale oder regionale rechtliche Vorschriften (z. B. OFAC-Sanktionslisten) ausgesetzt, was tatsächlich ein Risiko der Zentralisierung darstellt.

Aus diesem Grund, wenn diese wenigen Haupt-Builder selektiv bestimmte sensible Verträge (z. B. Tornado Cash) oder Transaktionen von bestimmten Adressen herausfiltern, können diese Transaktionen in eine lange Zeitspanne geraten, in der sie nicht verpackt werden können, und sie sind sogar dem Risiko einer „stillschweigenden Zensur“ ausgesetzt.

Zusammenfassend lässt sich sagen, dass Ethereum aus der Sicht normaler Benutzer ein offenes Netzwerk ist, mit dem sich jeder verbinden, Geld überweisen und Smart Contracts aufrufen kann. Aus der Perspektive des Protokollbetriebs ist das Senden einer Transaktion jedoch nur der erste Schritt. Ob die Transaktion tatsächlich wirksam wird, hängt davon ab, ob sie von einem Block-Builder ausgewählt, sortiert und in einen Block geschrieben wird.

Daher ist die Diskussion über „Anti-Zensur“ bei Ethereum nicht nur ein großes Konzept, das mit Politik, Regulierung oder Sanktionen verbunden ist, sondern es ist zunächst ein sehr konkretes technisches Problem:

Wenn eine Transaktion die Protokollregeln erfüllt, kann das Netzwerk garantieren, dass sie innerhalb eines angemessenen Zeitrahmens die Möglichkeit hat, in einen Block aufgenommen zu werden?

II. Von FOCIL zu FairFIL: Wie Ethereum die Block-Builder einschränkt

---

Tatsächlich ist das Problem hier bereits klar. Builder können die Effizienz der Blockerstellung erhöhen, aber wenn die Transaktionsrechte langfristig in den Händen weniger Builder konzentriert bleiben, wird Ethereum erneut ein neues Risiko der zentralisierten Monopolbildung schaffen.

Daher haben Ethereum-Forscher Inclusion Lists vorgeschlagen, die normalerweise als „Inklusionslisten“ bezeichnet werden.

Dieser Name klingt etwas abstrakt, aber die Kernlogik ist nicht kompliziert ------ Builder sind weiterhin für die Erstellung von Blöcken verantwortlich, dürfen jedoch nicht allein entscheiden, welche Transaktionen ein- oder ausgeschlossen werden. Die regulären Validator-Knoten, die an Ethereum-Staking teilnehmen, müssen ebenfalls einen Teil der Macht behalten, um ihnen zu ermöglichen, einige Transaktionen aufzulisten, die unbedingt bearbeitet werden müssen.

Nehmen wir als Beispiel eine Bushaltestelle. Man kann einen Block als eine begrenzte Anzahl von Sitzplätzen in einem Bus verstehen.

Builder entscheiden, wie die meisten Passagiere anstehen und wo sie sitzen, um durch eine effizientere Anordnung den Gesamtertrag der Fahrt zu steigern; aber Validator-Knoten können auch eine „Must-Board-Liste“ einreichen. Solange die Transaktionen auf dieser Liste weiterhin gültig sind, bereit sind, angemessene Gebühren zu zahlen und der Block genügend Platz hat, kann der Builder sie nicht einfach aufgrund seiner eigenen Vorlieben immer wieder ablehnen.

Die Fragen, wer eine solche Inklusionsliste erstellen soll und was zu tun ist, wenn jemand absichtlich Transaktionen auslässt, sind jedoch zwei Probleme, die weiterhin gelöst werden müssen.

FOCIL und FairFIL entwickeln sich genau in diese beiden Richtungen.

1. FOCIL: Keine Einzelproposer mehr, die die Inklusionsliste allein erstellen

FOCIL (Fork-Choice Enforced Inclusion Lists) überträgt die Entscheidung darüber, welche Transaktionen unbedingt enthalten sein müssen, von einem einzelnen Proposer auf ein „Validator-Komitee“, das aus mehreren Parteien besteht.

In jedem Blockzeitraum wählt das Netzwerk zufällig eine Gruppe von Validatoren aus, um ein temporäres Komitee zu bilden. Jedes Mitglied des Komitees beobachtet unabhängig den Mempool des Netzwerks und reicht jeweils eine lokale Inklusionsliste ein.

Das bedeutet, dass selbst wenn 99 % der Builder und Proposer im gesamten Netzwerk versuchen, eine bestimmte Transaktion zu zensieren, solange es im Komitee einen ehrlichen Knoten gibt, der diese Transaktion in die Liste aufnimmt, hat diese Transaktion die Möglichkeit, in die Protokollverpflichtung aufgenommen zu werden. Wenn die Zensoren weiterhin versuchen, sie auszuschließen, müssen sie nicht nur eine Person umgehen, sondern mehrere unabhängige Teilnehmer.

Der Vorteil liegt also darin, dass man nicht jedem im Komitee vertrauen muss, dass er neutral bleibt.

Aber nur eine Liste reicht nicht aus. Wenn der Builder die Liste erhält und sich dennoch entscheidet, sie nicht auszuführen, wird die Inklusionsliste zu einer unverbindlichen Empfehlung.

Daher hat FOCIL eine zweite Designschicht hinzugefügt, die Fork-Choice-Regel (Fork-Choice Rule) einführt, um eine strenge Verpflichtung zu schaffen. Alle Knoten, die für die Abstimmung verantwortlich sind, überprüfen streng die vom Builder eingereichten Blöcke. Wenn sie feststellen, dass der Builder gegen die von dem Komitee integrierte Inklusionsliste verstößt, wird das gesamte Netzwerk direkt ablehnen, für diesen Block zu stimmen.

Das bedeutet, dass ein nicht konformer Block sofort als ungültiger Block vom Protokoll eingestuft wird und der Builder dafür erhebliche Kosten für das Scheitern der Blockerstellung tragen muss.

2. FairFIL: Nicht nur Lücken schließen, sondern auch sicherstellen, dass die Auslassungen überprüfbar sind

Wenn FOCIL aus den Konsensregeln heraus Zensur strikt verbietet, dann zielt FairFIL (Fair Forward Inclusion Lists) mit einem Rechenschaftsmechanismus darauf ab, Zensurverhalten extrem kostspielig und unhaltbar zu machen.

Einfach ausgedrückt, es stellt weitergehende Anforderungen, wie warum eine Transaktion nicht in einen Block aufgenommen wurde, sollte nach Möglichkeit eine öffentlich überprüfbare Aufzeichnung hinterlassen.

Im tatsächlichen Betrieb des Netzwerks benötigt der Builder möglicherweise eine sehr kurze Pufferzeit, um die Transaktionsreihenfolge und MEV-Arbitrage zu optimieren. FairFIL erlaubt es dem Builder, innerhalb bestimmter Einschränkungen flexibel zu agieren, aber wenn der Builder versucht, eine Art von Zensurverhalten auf den nächsten Block zu übertragen, wird das Protokoll sofort einen Rechenschaftsprozess einleiten.

Die grundlegende Logik kann in drei Schritte unterteilt werden.

• Zunächst wird das Protokoll eine Reihe von öffentlichen, überprüfbaren Referenzregeln festlegen, um zu bestimmen, welche Transaktionen im öffentlichen Transaktionspool unter normalen Umständen die Bedingungen erfüllen, um in den aktuellen Block aufgenommen zu werden. Wenn bestimmte Transaktionen, die gemäß den Referenzregeln für die Aufnahme in den Block qualifiziert sind, letztendlich nicht verarbeitet werden, muss der Builder sie öffentlich im FairFIL auflisten;
• Anschließend wird der Validator überprüfen, ob diese Liste vollständig ist. Wenn der Builder offensichtlich qualifizierte Transaktionen ausgelassen hat, diese aber nicht in die Liste aufgenommen wurden, könnte dieses Verhalten entdeckt werden und die Unterstützung des Validierungsnodes für diesen Block beeinflussen;
• Schließlich werden die gültigen Transaktionen, die in den FairFIL aufgenommen werden, zu vorrangigen Aufgaben für die nachfolgenden Blöcke. Der nächste Builder kann sie weiterhin im Block an einer bestimmten Stelle anordnen, darf jedoch nicht so tun, als ob er sie nicht gesehen hätte;

Wenn eine Transaktion wiederholt ausgelassen wird, könnte der entsprechende Block die Unterstützung der Validatoren verlieren, und der Builder könnte dadurch die gesamten Erträge des Blocks verlieren.
Anders ausgedrückt, das, was FairFIL betont, ist die "Verantwortlichkeit", die tatsächlich **durch die Einführung von gestaffelten wirtschaftlichen Strafen erreicht wird. Ein Builder, der Transaktionen kontinuierlich überprüft, könnte das Risiko eingehen, die gesamte Blockbelohnung zu verlieren oder sogar seine hinterlegten Sicherheiten zu verlieren.**
Dies ist auch der Weg, wie die Anti-Zensur-Mechanismen von Ethereum schrittweise vertieft werden, mit dem Ziel, ein realistisches Regelwerk zu etablieren. Selbst wenn einige Teilnehmer Zensurabsichten haben, wird es schwierig sein, den Zugang zu Transaktionen langfristig zu kontrollieren; selbst wenn jemand absichtlich Transaktionen auslässt, muss er Spuren hinterlassen und für die kontinuierliche Überprüfung immer höhere Kosten tragen.
### Was bedeutet das für normale Benutzer? --------------
Für normale Benutzer, die täglich über Wallets Transaktionen durchführen, tauschen oder DeFi nutzen, erfordert diese grundlegende Mechanik, selbst wenn sie in Zukunft umgesetzt wird, keine Änderung ihrer bestehenden Gewohnheiten.
Die Benutzer geben weiterhin den Betrag in der Wallet ein, bestätigen die Gasgebühren, schließen die Signatur ab und warten dann, bis die Transaktion in die Blockchain aufgenommen wird. Aber auf der unsichtbaren Protokollebene könnte sich die Logik, ob eine Transaktion in den Block aufgenommen wird, erheblich ändern.
Was sich tatsächlich verbessert, ist die Deterministik des Transaktionsinhalts.
* **Zunächst wird eine regelkonforme Transaktion nicht mehr vollständig von der Wahl eines bestimmten Builders abhängen:** Selbst wenn der aktuelle Builder nicht bereit ist, sie zu verarbeiten, können andere Validatoren durch die Aufnahme in die Liste eine Protokollanforderung für die Aufnahme erstellen; * **Zweitens könnten die Rechte zur Aufnahme von Transaktionen und die Rechte zur Sortierung von Transaktionen allmählich getrennt werden:** Der Builder kann weiterhin spezialisierte Algorithmen verwenden, um die Reihenfolge der Transaktionen zu bestimmen und die Blockgewinne zu maximieren. Er kann auch weiterhin um Arbitrage und Abwicklung konkurrieren, aber seine Macht, zu entscheiden, „wer für den Markt qualifiziert ist“, wird eingeschränkt;
Darüber hinaus könnte die vertrauenswürdige Neutralität von Ethereum von einem Wertversprechen, das auf den Verpflichtungen der Teilnehmer beruht, allmählich zu einem Protokollregelwerk werden, das automatisch von Clients ausgeführt wird.
Benutzer müssen nicht wissen, welcher Builder den aktuellen Block erstellt hat, und sie müssen nicht jeden dieser Builder einzeln für neutral halten. Die Validierungsnoden werden den Block nach denselben Regeln überprüfen, was es schwierig macht, dass Blöcke, die die Aufnahmeverpflichtungen verletzen, im Netzwerk anerkannt werden.
In Zukunft könnten Wallets und Block-Explorer sogar detailliertere Transaktionsstatusinformationen bereitstellen.
Eine Transaktion wird nicht mehr nur allgemein als „ausstehend“ angezeigt, sondern könnte den Benutzern weiter mitteilen, ob sie bereits in die Aufnahmeliste aufgenommen wurde, ob sie die Verpflichtung zur Aufnahme in nachfolgende Blöcke erhalten hat und ob das Warten darauf zurückzuführen ist, dass die Gasgebühren nicht ausreichen, die Transaktion bereits ungültig ist oder ob es im Blockerstellungsprozess zu Anomalien gekommen ist.
Allerdings bedeutet das Anti-Zensur-Mechanismus nicht, dass jede Transaktion sofort erfolgreich sein kann.
Transaktionen mit unzureichendem Guthaben, Nonce-Konflikten, zu niedrigen Gasgebühren oder ungültigen Ausführungsbedingungen können weiterhin nicht in den Block aufgenommen werden. Wenn das Netzwerk überlastet ist und der Blockraum begrenzt ist, müssen die Benutzer weiterhin auf Bestätigungen durch Gebührenwettbewerb warten.
Aber es verbessert hauptsächlich eine Transaktion, die ursprünglich gültig, kostengünstig und bereits im öffentlichen Transaktionspool verbreitet ist, und sollte nicht aufgrund der subjektiven Entscheidungen weniger Blockbauer unbegrenzt verzögert werden.
In Bezug auf den Fortschritt befindet sich das FOCIL, das dem EIP-7805 entspricht, bis August 2026 noch im Entwurfsstatus. Es wurde jedoch von den Kernentwicklern von Ethereum als Headliner für das Hegotá-Upgrade ausgewählt und hat die Phase „Scheduled for Inclusion“ erreicht, was bedeutet, dass das Client-Team zugestimmt hat, die Umsetzung und Entwicklung von Netzwerktests voranzutreiben, aber der genaue Zeitpunkt des Live-Gangs im Hauptnetz ist noch nicht endgültig festgelegt.
FairFIL ist noch in einem früheren Stadium und derzeit hauptsächlich ein Forschungsprojekt, das im Juli 2026 veröffentlicht wurde. Ob es in die Ethereum-Roadmap aufgenommen wird, muss noch umfassender diskutiert, umgesetzt und sicherheitsvalidiert werden.
### Abschließend ----
Objektiv betrachtet kann Ethereum nicht garantieren, dass jeder Builder, Validator und Infrastrukturbetreiber immer neutral bleibt.
Teilnehmer könnten regulatorischem Druck ausgesetzt sein, ihren eigenen Interessen nachjagen oder externe Anreize annehmen. **Ein wirklich widerstandsfähiges dezentrales Netzwerk kann nicht auf der idealen Annahme basieren, dass „alle immer das Richtige tun“.**
Echte Anti-Zensur bedeutet, dass selbst wenn einige Teilnehmer versuchen, Transaktionen zu beeinflussen, andere Teilnehmer dennoch in der Lage sind, diese Kontrolle zu durchbrechen; selbst wenn jemand beschließt, von den Neutralitätsprinzipien abzuweichen, kann das Protokoll dieses Verhalten sichtbar, kostspielig und schwer aufrechtzuerhalten machen.
Von der anfänglichen Aufnahmeliste über das FOCIL, das Builder durch ein verteiltes Komitee gemeinsam bindet, bis hin zu FairFIL, das verlangt, dass Auslassungen öffentlich überprüfbar sind, von der Erlaubnis, dass jeder Transaktionen senden kann, bis zur Garantie, dass die Transaktionen aller gesehen werden können.
Aus dieser Perspektive betrachtet, versucht Ethereum tatsächlich, dieses Versprechen Schritt für Schritt in das Protokoll selbst zu schreiben, anstatt nur eine Wertdeklaration zu sein.
Es ist vielversprechend.

Dieser Inhalt wird nur zu allgemeinen Informationszwecken bereitgestellt und stellt keine finanzielle, Anlage-, Rechts- oder Steuerberatung dar. Alle erwähnten Ereignisse, Prämien, Online-Aktionen oder zugehörige Informationen sollten nicht als Empfehlung, Aufforderung oder Einladung zum Kauf, Verkauf, Handel oder anderweitigem Umgang mit Krypto-Assets betrachtet werden. Krypto-Assets sind sehr volatil und können zu Verlusten führen. Die Verfügbarkeit von WEEX Services, Produkten und zugehörigen Aktionen kann je nach Region unterschiedlich sein. Sie sind dafür verantwortlich sicherzustellen, dass Ihre Teilnahme mit geltenden lokalen Gesetzen und Vorschriften übereinstimmt.