Anmerkung der Autoren: init4ist ein Forschungskollektiv, das an Ethereum-Tools der nächsten Generation arbeitet. Dies ist eine Forschungsnotiz, kein Offenlegungsdokument. Obwohl wir Nuancen und Lücken in den Sicherheitsmodellen der implementierten und vorgeschlagenen Systeme diskutieren werden, wäre es übertrieben, diese als "Schwachstellen" oder als "zuvor unbekannt" zu bezeichnen.

Widerstand gegen Zensur bleibt ein Kernwert von Kryptowährungen im Allgemeinen und Ethereum.insbesondere. Wir glauben, dass die Vorteile von Transaktionen on-chain für jeden verfügbar sein sollten und dass die Regeln der Kette gleichermaßen auf alle Benutzer und Anwendungen angewendet werden sollten. Werte treiben diesen Raum voran. Engineering ist der Prozess, unsere Werte gegen die Realität zu testen, um herauszufinden, wo und wie sie versagen.

Dominosteine gehen auch in einer Sequenz :) Foto von Tom WilsonaufUnsplash

Die Definition von Widerstand gegen Zensur

Wir neigen dazu, Zensur so zu modellieren, dass Transaktionen absichtlich daran gehindert werden, in der kanonischen Reihenfolge zu erscheinen (d.h. Transaktionsausschluss). Wir betrachten Aufträge als fair oder neutral, wenn sie ausschließlich vom wirtschaftlichen Ergebnis für das Ordnungssystem abhängen, und als unfair oder zensiert, wenn sie von anderen Informationen abhängen. Wenn beispielsweise beim Erstellen eines Blocks eine Transaktion mit niedriger Gebühr nicht aufgenommen wird, es aber inakzeptabel ist, eine Transaktion nicht aufzunehmen, weil sie von einer bestimmten Person gesendet wurde. Daher sagen wir, dass eine Transaktion zensiert ist, wenn ihre Aufnahme von nicht-wirtschaftlichen Informationen abhängt. Wenn die Transaktion für das Ordnungssystem einen höheren beobachtbaren Gewinn erzielt als alle enthaltenen Transaktionen, aber selbst nicht enthalten ist, gilt sie als zensiert. Diese Definition motiviert die Arbeit an erzwungenen Inklusionsmechanismen für Widerstand gegen Zensur. Wenn ein Benutzer die Aufnahme seiner Transaktion erzwingen kann, kann sie nach dieser Definition nicht zensiert werden.

Mechanismen zur erzwungenen Inklusion

Ein wichtiges Sicherheitsziel von OP Stack Chains ist, dass der Sequencer Benutzer nicht daran hindern sollte, Transaktionen an die L2-Kette zu senden.

• Optimismus

Moderne Rollups neigen dazu, eine zentrale Sequenzierung zu haben. Dies bedeutet, dass die Zensur durch den Sequenzer trivial ist, da sie einfach wählen können, eine bestimmte Benutzertransaktion nicht einzuschließen. Um dies zu widerstehen, mehrere Rollups - einschließlich Optimism und Arbitrum- haben Zwangseinbeziehungsmethoden. Diese Mechanismen ermöglichen es einem Benutzer, sicherzustellen, dass seine Transaktion nach einer gewissen Zeitverzögerung vom Rollup ausgeführt wird, unabhängig vom Verhalten des Sequenzers. Die Einbeziehung wird über einen Vertrag erzwungen, der auf L1 bereitgestellt wird. Zwangseinbeziehungstransaktionen haben daher (theoretisch) den gleichen Widerstand gegen Zensur wie andere Ethereum-Transaktionen.

Die erzwungene Inklusion gibt den Teilbereich an, der in jeder gültigen Reihenfolge erhalten bleiben muss.

Für Ethereum wurde auch ein erzwungener Inklusionsmechanismus vorgeschlagen überEIP-7547Inclusion-Listen würden es Blockvorschlägen ermöglichen, den Inhalt des nächsten Blocks teilweise zu spezifizieren. Unter der Annahme, dass Blockvorschläge weniger Anreize zur Zensur haben als Blockbauer, würde dies eine effektive Minderung der Zensur bieten.

Im Allgemeinen führen erzwungene Einschlussmechanismen zu neuen Einschränkungen bei gültigen Reihenfolgen. Sie machen breite Klassen von Reihenfolgen gemäß Protokollregeln ungültig.¹. Erzwungene Einbindung sollte als Möglichkeit betrachtet werden, dem Benutzer die Spezifizierung einer Teilmenge der zukünftigen Reihenfolge zu ermöglichen. Alle gültigen Reihenfolgen müssen auf der erzwungenen Teilmenge aufbauen.

Erweiterung unseres Modells der Zensur

Leider ist die Transaktionsbestätigung das Mittel, nicht das Ende. Unser Modell der Zensur ist unvollständig!

Zensur muss in Bezug auf Ziele definiert werden. Benutzer möchten Tokens senden, NFTs kaufen, Geld leihen, usw. Die Bestätigung der Transaktion ist dabei nur nebensächlich.²Auch Zensoren haben spezifische Ziele. Dieses Ziel kann sein, bestimmte Hack-Transaktionen zu verhindern, um bestimmte Gesetze einzuhalten oder um das Geschäft eines Konkurrenten zu stören. Unter Beachtung der Absicht beider Parteien müssen wir die Zensur neu definieren.

In diesem Sinne sollten wir unsere Definition von Zensur erweitern und sagen: Eine Transaktion wird zensiert, wenn eine dritte Partei verhindern kann, dass sie ihr Ziel erreicht. Das heißt, der Zensor muss die Transaktion nicht daran hindern, zu bestätigen; er muss nur die Rückgängigmachung der Ausführung des Smart Contracts bewirken. Das Rückgängigmachen einer EVM-Transaktion ist eine Zensur dieser Transaktion, obwohl diese Transaktion Teil der kanonischen Kette ist. Bedrohungsmodelle, die blind für den Inhalt einer Transaktion sind, modellieren Zensur nicht genau und können Benutzer daher nicht effektiv davor schützen.

Halbwegs formell würden wir sagen, dass für jede gegebene Interaktion mit der Kette eine gewisse Bewertungsfunktion f existiert, die die resultierende Reihenfolge bewertet und 0 (Ziel nicht erreicht) oder 1 (Ziel erreicht) produziert. In diesem Modell ist die Bewertungsfunktion des Zensors einfach die Negation: f' = !f. Der Zensor erreicht sein Ziel, wenn der Benutzer es nicht tut.³

Während das Ziel des Benutzers möglicherweise verborgen ist, enthält die Transaktion selbst fast immer genügend Informationen, um es zu erschließen. Uniswap-Trades haben offensichtliche Ziele. Darüber hinaus kann der Zensor aufgrund der Deterministik der Blockchains perfekt vorhersagen, welche Anordnungen das Prädikat des Zensors erfüllen werden. Benutzer können sich daher im EVM-Modell nicht auf verborgene Informationen verlassen, um sich vor Zensur zu schützen. Transaktionsdetails müssen öffentlich sein, was bedeutet, dass Informationen über das Ziel des Benutzers öffentlich sind.

Um es einfacher zu machen, nehmen wir an, dass wir im Standard-Vorauslauf-Sequenzer-Modell arbeiten.⁴. Wir werden uns später mit der erzwungenen Einbeziehung unter Sequenzerotation befassen. In diesem Modell hat der Sequenzer die vollständige Kontrolle über die Sequenz und kann jedes Ergebnis perfekt simulieren. Das heißt, er kann aus der Menge aller möglichen Reihenfolgen frei wählen. Unsere halbformale Frage zur Zensur lautet dann: „Existiert eine gültige Reihenfolge, über die f zu 0 ausgewertet wird?“ Wenn eine solche Reihenfolge existiert, kann der Sequenzer sie auswählen.

Von dort aus können wir unser Modell erweitern, um erzwungene Einbeziehung zu berücksichtigen. „Gibt es eine gültige Reihenfolge, die die Unterreihenfolge des Benutzers einschließt, für die f den Wert 0 ergibt?“ Wenn eine solche Reihenfolge existiert, kann sie vom Sequenzer ausgewählt werden. Erzwungene Einbeziehung hindert den Sequenzer nicht daran, die Reihenfolge zu kontrollieren, sie schränkt nur ihr Verhalten ein. Leider hat die erzwungene Einbeziehung grundlegende Probleme, die sie zu einem ineffektiven Mechanismus zur Widerstand gegen Zensur für viele Transaktionen machen.

Das Handoff-Problem

Mechanismen zur erzwungenen Einbeziehung bedeuten, dass die Bestellung in einem von zwei Modi erfolgt: unerzwungen oder erzwungen. Es gibt einen definierten Punkt, an dem es von unerzwungen zu erzwungen (und umgekehrt) wechselt. Dieser Punkt ist die Übergabe. Die Übergabe stellt ein heikles Problem für die Gestaltung von Mechanismen zur erzwungenen Einbeziehung dar.

Es muss eine Übergabe vom unfreiwilligen zum gewaltsamen Einschluss geben.

Die erzwungene Transaktion wird beim Übergang im Zustand ausgeführt. Also noch einmal, Zustandskonflikt⁵zeigt sein hässliches Gesicht. Wenn die Übergabe innerhalb eines Stapels von Transaktionen (wie einem Block) erfolgt, kann der Ersteller des Stapels die Kontrolle über den Zustand bei der Übergabe ausüben. Wenn die erzwungene Einschlusstransaktion einen öffentlichen Zustand liest, kann der Ersteller des Stapels diesen Zustand vor und nach der Ausführung der erzwungenen Transaktion neu schreiben. Kontention ist ausreichend für Zensur.

Da der Batch-Ersteller die Kontrolle über den Zustand bei der Übergabe ausüben kann, kann er das Ergebnis der erzwungenen Transaktion beeinflussen. Wenn er das Ergebnis beeinflussen kann, kann er potenziell das Ergebnis des Bewertungsprädikats beeinflussen. Betrachten Sie zum Beispiel eine einfache AMM-Interaktion. Der Benutzer legt einen minimal akzeptablen Preis fest, aber der Batch-Ersteller kann sicherstellen, dass zum Zeitpunkt der Übergabe der Marktpreis unter dem minimal akzeptablen Preis liegt. Dies führt dazu, dass die Benutzertransaktion rückgängig gemacht wird und der Benutzer somit zensiert wird.⁶⁷

Interessanterweise ist die Zensur über staatliche Kontroversen effektiver als die Zensur durch Ausschluss. Eine ausgeschlossene Transaktion kann in zukünftigen Blöcken enthalten sein. Eine durch Streitigkeiten zensierte Transaktion ist dauerhaft ungültig. Sie wurde in die Kette aufgenommen und kann nie wieder aufgenommen werden. Diese Transaktion kann das Ziel des Benutzers niemals erreichen. Um es erneut zu versuchen, muss der Benutzer die Transaktion neu erstellen und erneut senden (was möglicherweise erneut zensiert werden kann).

In praktischen Systemen

Jeder Benutzer kann den Sequencer vollständig umgehen, um jede Arbitrum-Transaktion (einschließlich einer, die beispielsweise eine L2-zu-L1-Nachricht zur Auszahlung von Geldern initiiert) direkt von Layer 1 aus zu übermitteln. Somit wird die Mechanismus die Widerstandsfähigkeit gegen Zensur auch dann bewahren, wenn der Sequencer vollständig unresponsive oder sogar bösartig ist.

• Arbitrum

Im Voraus-Abfolgemodell hat der Sequenzer nahezu perfekte Kontrolle über den Ort der Übergabe in der Sequenz und zahlt reduzierte Gebühren (da er kein Trinkgeld geben muss und etwas Kontrolle über das EIP-1559-Basisentgelt ausüben kann). Als Ergebnis befindet sich der Sequenzer in einer privilegierten Position, um den Zugang zu Benutzeraktionen durch Zustandskonflikte zu zensieren. Es ist belanglos. Das Übergabeproblem stellt sicher, dass der Sequenzer große Klassen von Transaktionen zensieren kann.

Für EIP-7547 wählen die Entwickler aus, wo die Blockübergaben stattfinden.⁸Als Ergebnis kann der Ersteller den Ort des Hand-offs innerhalb des Blocks wählen. Das bedeutet, dass sie nach Belieben ein Präfix und ein Suffix auswählen können,⁹solange sie die Blockgasregeln respektieren. Das Präfix kann die Kette in einen Zustand versetzen, in dem die Transaktion rückgängig gemacht wird, während das Suffix die Kette in einen normalen Zustand zurückversetzt. EIP-7547-Inklusionslisten reichen nicht aus, um die Zensur für Transaktionen, die auf umstrittene Zustände zugreifen, zu verhindern. Das Übergabeproblem verhindert, dass ILs in den meisten Fällen die Transaktionsausführung gewährleisten.

Die Zwangseingliederung ist bei den meisten nicht-trivialen Anwendungen der Blockchain ineffektiv, um Benutzer vor Zensur zu schützen. Das Übergabeproblem gewährleistet, dass der Zensor auch dann ausreichend Ermessensspielraum über den Zustand hat, wenn er nicht ausreichend Ermessensspielraum über die Reihenfolge hat. Dieses Problem betrifft AMMs, Kreditmärkte, Auktionen und die meisten anderen DeFi-Aktionen. Viele wichtige Aktionen sind zensierbar, selbst wenn Sie die Transaktionseingliederung garantieren können. Der Zustandsstreit schafft harte Grenzen für die Wirksamkeit der Zwangseingliederung als Mechanismus zur Widerstand gegen Zensur.

Fallstudie

Um die weitreichenden Auswirkungen dessen zu sehen, betrachten Sie einen Benutzer, der USDC auf einem Kreditmarkt auf Optimismus verleiht. Wenn der Benutzer USDC vom Markt abheben möchte, reicht er eine Optimismus-Transaktion ein, die vom Sequenzer zensiert wird. Anschließend verwenden sie den offiziellen erzwungenen Einbeziehungmechanismus, um ihre Transaktion in die Warteschlange auf Ethereum zu stellen und den Sequenzer zu umgehen.

Der Sequenzer kann diese Transaktion in der Warteschlange sehen und wählt aus, sie zu blockieren. Um die Transaktion zu zensieren, leiht der Sequenzer sofort alle verfügbaren USDC vom Markt, kurz bevor die erzwungene Transaktion stattfindet. Da der Markt keine Liquidität mehr hat, wird die erzwungene Transaktion rückgängig gemacht. Der Sequenzer kann dann die USDC sofort zurückzahlen.

Der Sequenzer oder Builder kann den Zustand bei der Übergabe manipulieren.

Dafür muss der Sequenzer über ausreichende Sicherheiten verfügen, um USDC ausleihen zu können, aber es fallen nur extrem geringe Ausleihkosten an.¹⁰Darüber hinaus ist das Pfand für alle Arten von Zensur wiederverwendbar, da das Darlehen nie offen gehalten wird. Als Ergebnis hat ein Benutzer von AAVE oder Compound auf Optimismus (oder Arbitrum oder einem anderen zentral sequenzierten Rollup) keine Garantie, dass er jemals das Pfand abheben kann. Der Sequenzer kann jederzeit jede Abhebung aus jedem Kreditmarkt zensieren. Eine erzwungene Einbeziehung reicht einfach nicht aus, um Benutzer vor Zensur zu schützen.

Nacharbeiten

Wir haben einige Bereiche, in denen wir nachforschen müssen.

Zunächst kann EIP-7547 trivial verbessert werden, indem IL-Transaktionen am Ende des nächsten Blocks verarbeitet werden. Im Kontext der PBS-Auktion ist Zensur MEV. Der Ersteller leitet einen gewissen nicht-ökonomischen Wert ab, dem sie einen subjektiven Wert zuweisen müssen, der in ETH denominiert ist. Zensur durch den Ersteller führt daher zu einer Erhöhung des Blockgebots des Erstellers.¹¹Dies gilt auch für Suchende, die Zensurbündel erstellen können. Ein Teil des wirtschaftlichen Werts der Zensur wird dann vom Antragsteller erfasst, was einen Anreiz bietet, Zensur auch dann zu tolerieren, wenn man nicht direkt daran teilnimmt. Durch das Platzieren von erzwungenen Inklusionstransaktionen am Ende des Blocks wird dem Blockbuilder die Möglichkeit genommen, die IL-Transaktionen einfach einzuschließen, und die wirtschaftlichen Kosten einer umstrittenen Zensur steigen. Zum Beispiel könnte das Zensieren einer AMM-Interaktion über einen Zustandsstreit bedeuten, dass man etwas AMM-Arbitrage aufgeben oder hohe Kosten aufbringen muss, um den Markt aus dem Bereich zu drücken, die durch das Schließen des Sandwichs nicht wieder hereingeholt werden können. Darüber hinaus würde dies die von Suchenden (anstatt von Blockbuildern) produzierten Zensurbündel auf eines pro Block beschränken.¹²Wir würden die Ausführung am Anfang des Blocks empfehlen, da das Präfix wichtiger ist als das Suffix. Allerdings würde dies die Kosten einer IL-Transaktion drastisch erhöhen, da es die MEV-Extraktion am Anfang des Blocks durch erzwungene Einbindung ermöglichen würde.¹³Die Entfernung des Zensurrechts, IL-Transaktionen atomar anzuhängen, ist eine kleine Verbesserung.

Zweitens besteht das Problem des Handoffs, weil der Zensor durch die Transaktionssimulation vorausschauen und die Kontrolle über den Eingangszustand ausüben kann. Viele MEV-Widerstandsmechanismen führen versteckte Informationen ein, um die Fähigkeit des Zensors zu entfernen, Informationen über die Ziele der Benutzer abzuleiten und Ergebnisse zu simulieren. Typischerweise handelt es sich dabei um Commit-Reveal-Schemata, bei denen einige Transaktionsinformationen privat sind, bis die Reihenfolge festgelegt ist. Die Trennung von Reihenfolge und Ausführung sowie versteckte Informationen scheinen vielversprechend zu sein, sind aber weitgehend unvereinbar mit der MEV-Lieferkette, den Ethereum-Konsensprozessen und dem sequenziellen Rollup-Modell. Ein Weg, die Fähigkeit zur Simulation von Transaktionen zu unterbinden, würde Zensur und große Klassen von MEV angehen, wäre aber äußerst invasiv für das Protokoll, die Betreiber des Protokolls, Anwendungen und den Endbenutzer.

Drittens gibt es eine interessante Klasse von "ordnungsunabhängigen" Bewertungsfunktionen. Dies sind Ziele, die nicht durch staatliche Auseinandersetzungen zensiert werden können, entweder weil sie keinen umstrittenen Zustand aufrufen oder weil der umstrittene Zustand, den sie aufrufen, ausreichende Einschränkungen hat, um ihn in gewisser Weise "zuverlässig" zu machen. Ordnungsunabhängige Aktionen umfassen das Senden von ETH an ein EOA, die meisten ERC-20-Sendungen,¹⁴und einige DeFi-Interaktionen wie das Hinzufügen von Sicherheiten zu einem Markt. Diese Handlungen sind durch Widerstand gegen Zensur geschützt. Diese Klasse von Zielen hat auch interessante Entsprechungen in sicherer Cross-Chain-Kommunikation und Widerstand gegen MEV und ist eine eingehendere Untersuchung wert. Anwendungen und Protokolle können in einigen Fällen nur ordnungsunabhängige Aktionen enthalten, aber weitere Studien sind erforderlich.

Fazit

Der Rich-Zustand ermöglicht es böswilligen Akteuren, Transaktionen zu zensieren, während sie weiterhin einbezogen werden. Das Problem der Übergabe ist grundlegend für Mechanismen der erzwungenen Inklusion und kann nur gemildert werden. Bei zentral sequenzierten Rollups ist keine Risikominderung möglich. Erzwungene Inklusion kann Zensur in Gegenwart eines umstrittenen Staates nicht bekämpfen. Große Klassen von wirtschaftlich wichtigen Transaktionen können zensiert werden, selbst wenn sie mit Gewalt einbezogen werden. Das Übergabeproblem ist in modernen Rollups endemisch und in den zensurresistenten EIPs von Ethereum vorhanden. Infolgedessen ist erzwungene Inklusion zwar von Vorteil, reicht aber niemals aus, um den Ketten reicher Staaten Zensurresistenz zu bieten. Rollups "erben" nicht die Sicherheitseigenschaften von Ethereum und es ist dumm zu behaupten, dass sie dies tun. Wenn man aufhört, sich mit Inklusion zu beschäftigen, wird klar, dass Zensurresistenz ein Sonderfall von MEV-Widerstand ist.

Wir möchten uns bedanken Mike Neuder, Tarun Chitra, und Brandon Curtiszur Überprüfung und Rückmeldung.

1

Wie üblich geschieht dies bei L1s durch die Ablehnung ungültiger Blöcke, während es bei Rollups durch das Erzwingen ungültiger Sequenzen zu gültigen Sequenzen mithilfe einer Filterfunktion geschieht.

2

Dies ist kein Beitrag über Absichten, die Welt braucht an diesem Punkt nicht mehr davon.

3

Dies ist offensichtlich ein unvollständiges Modell, da es die subjektiven Werte der Ergebnisse nicht berücksichtigt. Z.B. kann der Zensor jeden Geldbetrag verlieren, wenn die Zensur scheitert (z.B. weil er von der französischen Polizei verhaftet werden könnte, wenn er ein bestimmtes Verhalten nicht zensiert). Auf der anderen Seite könnte der Benutzer einen beliebigen Geldbetrag gewinnen/verlieren, wenn sein Ziel in einem bestimmten Zeitrahmen nicht erreicht wird (z. B. hat er 100 Mio. $+ an Krediten gegen seinen eigenen Token aufgenommen und muss die Position erneut besichern, bevor er liquidiert wird).

4

Im Gegensatz zu einem „basierten“ Sequenzer-Modell. In den meisten modernen Rollups läuft der Sequenzer „voraus“ von Ethereum, da er Ein- und Ausführungsattestierungen für eine Transaktion bereitstellt, bevor die Transaktion auf Ethereum verbindlich geworden ist. In diesem Modell hat der Sequenzer die vollständige Kontrolle über die Sequenz, und das Ergebnis der Transaktion muss unabhängig von Ethereum-Reorgs sein.

5

Wenn mehrere Benutzer auf denselben Vertrag, dieselbe Anlage oder denselben Status zugreifen möchten, "konkurrieren" ihre Transaktionen miteinander und beeinträchtigen möglicherweise die Ergebnisse des jeweils anderen. Der Streit kann zufällig oder absichtlich entstehen. Dies ist ein hartnäckiges Problem des reichen Zustands in Blockchain-Systemen. Der öffentliche Zugang zum gemeinsamen Staat ist die Wurzel von MEV, Skalierbarkeitsproblemen und dem Niedergang der Zivilität in der modernen Gesellschaft.

6

Im Allgemeinen sollten Sie die Zensur durch staatlichen Widerstand als einen spezialisierten Fall von MEV betrachten. Da der extrahierte Wert außerhalb der Kette, nicht beobachtbar und potenziell sehr groß ist, kann es schwierig sein, vorherzusagen, wann die Zensur durch staatlichen Widerstand auftreten wird.

7

Wir haben in unserem Artikel von 2017 speziell die Verwendung von Zustandsstreitigkeiten zur Rückgängigmachung von Transaktionen behandelt.Miner sind nicht deine Freunde”. Damals war der Begriff "MEV" noch nicht gebräuchlich.

8

Es ist allgemein bekannt, dass PBS den Widerstand gegen Zensur dramatisch kompliziert. Siehe VB’s @vbuterin/pbs_censorship_resistance">forschungsnote.

9

Das Präfixieren und Postfixieren einer Transaktion wird allgemein als "Sandwiching" bezeichnet und wird als Methode zur Verwendung von Zustandskonflikten zum Extrahieren von MEV verstanden.

10

Das Ausleihen dauert nur wenige Sekunden, wenn überhaupt. In einigen Fällen können Rollup-Sequenzer Zeitstempel oder Blockgrenzen halten, um die effektive Ausleihzeit auf 0 zu reduzieren.

11

Der Ersteller wird bereit sein, bis zu seinem subjektiven Wert des Widerstands gegen Zensur zu zahlen, was das Angebot möglicherweise über den objektiv beobachtbaren extrahierbaren Wert des Blocks treibt. In extremen Fällen kann dies dazu führen, dass der Zensierer eine negative ETH-Bilanzänderung hat (d.h. er zahlt mehr ETH für die Erstellung des Blocks als er an Gebühren und Belohnungen erhält).

12

Beachten Sie, dass dies auf MEV-Auktionsregeln beruht, die das Verschachteln von Transaktionen aus verschiedenen Bundles verhindern und keine 'must revert'-Transaktionen zulassen. Wenn diese Regeln gelockert würden, um das Verschachteln von Bundle-Transaktionen zu ermöglichen und/oder wenn Builder 'must revert'-Blöcke in Bundles unterstützen würden, würde der Schutz verschwinden. Diese Dynamik entsteht, weil bei IL-Transaktionen am Ende des Blocks keine nicht erzwungenen Transaktionen verschachtelt werden dürfen und daher höchstens ein Sucher-Zensur-Bundle auftreten könnte.

13

Dadurch kann der Erbauer effektiv begrenzte Zwischenblock-Bundles erstellen. Vorabkonsenssysteme wie FOCILkönnte dies mildern.

14

Bei einem standardmäßigen ERC-20-Token ist der Transfer-Aufruf in der Regel nicht über Streitigkeiten zensierbar, da Dritte das Guthaben des Benutzers nicht verringern können. Allerdings ist bei einem transferFrom-Aufruf zu beachten. Wenn der zugelassene Übertragende eine Vertragspartei ist, die Streitigkeiten in ihrem eigenen Zustand zulässt, kann die Aktion über diese Streitigkeiten zensierbar sein (indem die für den transferFrom erforderliche Genehmigung auf ungewollte Weise verbraucht wird).

Haftungsausschluss:

1. Dieser Artikel ist abgedruckt von [die Technologie], Alle Urheberrechte gehören dem Originalautor [ init4]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Tor lernenTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die Ansichten und Meinungen, die in diesem Artikel zum Ausdruck gebracht werden, sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel untersagt.