💻 computer science

Perils of Parallelism: Transaction Fee Mechanisms under Execution Uncertainty

Diese Arbeit analysiert, wie die Ausführungsparallelität und Kontingenz in modernen Blockchains inhärente Zielkonflikte zwischen Nutzer- und Scheduler-Anreizen schaffen, beweist ein Unmöglichkeitsresultat für bestehende Gebührenmechanismen und schlägt ein neues Framework vor, das optimale Grenzen für Fairness und Performance in Systemen wie Sui und Monad erreicht.

Ursprüngliche Autoren: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Veröffentlicht 2026-06-15

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Sarisht Wadhwa, Aviv Yaish, Fan Zhang, Kartik Nayak

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich eine belebte Autobahn vor, auf der statt Autos, die einzeln nacheinander in einer Spur fahren, der Verkehr nun erlaubt ist, gleichzeitig über mehrere Spuren zu sausen. Dies ist die parallele Ausführung in modernen Blockchains: Eine Methode, um viele Transaktionen gleichzeitig zu verarbeiten, um das System schneller zu machen.

Dieses Paper argumentiert jedoch, dass, obwohl parallele Autobahnen schneller sind, die aktuellen „Mautstation“-Systeme (Gebührenmechanismen) defekt sind. Sie wissen nicht, wie sie fair abrechnen können, wenn Fahrer möglicherweise unterschiedliche Routen nehmen oder wenn gefälschte Fahrer versuchen, das System zu manipulieren.

Hier ist die Aufschlüsselung der Erkenntnisse des Papers unter Verwendung einfacher Analogien.

1. Die zwei großen Probleme

Die Autoren identifizieren zwei Hauptgefahren (Perils), die auftreten, wenn man versucht, Gebühren für die parallele Verarbeitung zu erheben.

Gefahr A: Der „Vielleicht“-Fahrer (Kontingente Transaktionen)

Stellen Sie sich vor, Sie bestellen eine maßgeschneiderte Pizza. Sie sagen der Küche: „Ich möchte eine Pizza mit Salami, Pilzen und Oliven.“

Die Realität: Sie essen tatsächlich nur die Salami. Die Küche hat die Pilze und Oliven vorbereitet, aber Sie haben sie nicht angerührt.
Das Problem: In einer parallelen Blockchain sagt eine Transaktion (die Pizza-Bestellung) oft: „Ich brauche vielleicht diese 5 Objekte (Zutaten).“ Aber je nach aktuelem Zustand der Welt (dem Preis für Salami) werden am Ende vielleicht nur 1 Objekt tatsächlich genutzt.
- Wenn Sie für das berechnen, was Sie nutzen: Verliert die Küche (der Scheduler) Geld, weil sie Zutaten vorbereitet hat, die verschwendet wurden.
- Wenn Sie für das berechnen, was Sie angegeben haben zu nutzen: Überzahlt der Nutzer (Sie) für Zutaten, die er nie berührt hat.

Die große Entdeckung des Papers: Man kann nicht beides haben. Man kann kein System entwerfen, in dem der Nutzer niemals zu viel bezahlt UND die Küche niemals Geld durch ungenutzte Vorbereitungsarbeit verliert. Es ist eine mathematische Unmöglichkeit. Man muss entscheiden, wer das Risiko trägt: der Nutzer oder das System.

Gefahr B: Die „falschen“ Fahrer (Shill-Angriffe)

Stellen Sie sich nun eine Mautstation vor, die basierend darauf abrechnet, wie viel Verkehr auf der Straße ist.

Der Trick des Nutzers: Ein Fahrer möchte eine niedrige Maut zahlen. Er schickt eine Reihe von gefälschten, nutzlosen Autos (Shill-Transaktionen) auf die Straße. Diese gefälschten Autos nehmen Platz ein, fahren aber eigentlich nirgendwohin. Die Mautstation sieht „starken Verkehr“ und verteilt die Kosten so, dass der echte Fahrer weniger zahlt.
Der Trick der Mautstation: Die Person, die die Station betreibt, möchte mehr Geld verdienen. Sie schickt ihre eigenen gefälschten Autos auf die Straße, um es so aussehen zu lassen, als ob die echten Fahrer einen massiven Stau verursachen würden. Die Mautstation berechnet den echten Fahrern dann einen Aufschlag für die „Verkehrsdichte“.

Die Entdeckung des Papers: Aktuelle Systeme sind anfällig für solche Tricks. Wenn das System basierend darauf abrechnet, wie viel „parallele Arbeit“ gerade stattfindet, können böswillige Akteure die Mathematik manipulieren, indem sie durch das Hinzufügen gefälschter Transaktionen die Gebühren senken oder erhöhen.

2. Drei Wege, die Rechnung aufzuteilen

Da man das Risiko ungenutzter Zutaten nicht eliminieren kann (Gefahr A), schlägt das Paper drei Wege vor, die Rechnung zwischen dem Nutzer und dem System aufzuteilen:

Der „Nutzerfreundliche“ Ansatz: Sie zahlen nur für die Salami, die Sie tatsächlich gegessen haben.
- Ergebnis: Der Nutzer ist glücklich (keine Überzahlung), aber die Küche (das System) verliert Geld durch die verschwendeten Pilze und Oliven.
Der „Scheduler-Freundliche“ Ansatz: Sie bezahlen für die ganze Pizza, die Sie bestellt haben, auch wenn Sie nur die Salami gegessen haben.
- Ergebnis: Die Küche ist glücklich (garantierter Umsatz), aber der Nutzer zahlt möglicherweise zu viel.
Der „Gleichberechtigte“ Ansatz: Sie teilen die Kosten für die verschwendeten Zutaten 50/50 auf.
- Ergebnis: Ein Kompromiss, bei dem beide Parteien das Risiko der „Vielleicht“-Zutaten teilen.

3. Die Lösung: Die „Objekt-gewichtete“ Mautstation

Um das Problem der „falschen Fahrer“ (Gefahr B) zu lösen und gleichzeitig das „Vielleicht“-Problem zu handhaben, schlagen die Autoren ein neues System namens OW-TFM (Object-Weighted Transaction Fee Mechanism) vor.

Die Analogie:
Anstatt basierend darauf abzurechnen, wie viele Autos gerade jetzt auf der Straße sind (was gefälscht werden kann), stellen Sie sich ein Mautsystem vor, das darauf basiert, wie beliebt eine bestimmte Spur gestern war.

Wenn ein bestimmtes Objekt (wie ein beliebter Pizza-Belag) im letzten Block viel verwendet wurde, steigt sein Preis für den nächsten Block leicht an.
Wenn es nicht verwendet wurde, bleibt der Preis niedrig.

Warum dies die Tricks verhindert:

Für Nutzer: Wenn Sie versuchen, gefälschte Transaktionen hinzuzufügen, um Ihre Gebühr zu senken, können Sie das nicht tun. Das Hinzufügen einer gefälschten Transaktion erhöht lediglich die Nutzungshäufigkeit eines Objekts, was den Preis für alle – einschließlich Ihnen selbst – erhöhen kann. Sie können den Preis nicht senken, indem Sie mehr Autos hinzufügen.
Für das System: Das System setzt die Preise basierend auf vergangenen Daten, sodass es nicht vorhersagen muss, was in der Zukunft passieren wird.

4. Das Fazit

Das Paper kommt zu dem Schluss, dass der Aufbau einer fairen, schnellen und sicheren parallelen Blockchain schwierig ist, da es einen grundlegenden Zielkonflikt gibt:

Geschwindigkeit vs. Fairness: Man kann nicht perfekt vorhersagen, welche „Zutaten“ eine Transaktion verwenden wird, ohne sie tatsächlich zuerst auszuführen (was Zeit kostet und den Zweck der Parallelität zunichtemacht).
Sicherheit vs. Effizienz: Man kann nicht gleichzeitig ein System haben, das perfekt effizient ist (genau für das abrechnet, was genutzt wird) und perfekt sicher (immun gegen gefälschte Transaktionen).

Die Autoren schlagen vor, dass Blockchain-Designer (wie diejenigen, die Sui, Solana oder Monad bauen) explizit entscheiden müssen, wer das Risiko ungenutzter Ressourcen (Nutzer oder System) trägt, und ein Preismodell verwenden sollten, das auf der historischen Objektnutzung basiert, um zu verhindern, dass Menschen das System mit gefälschten Transaktionen manipulieren.

Kurz gesagt: Parallele Blockchains sind wie eine belebte Küche. Man kann nicht perfekt für eine Mahlzeit abrechnen, bevor man weiß, was der Kunde tatsächlich isst, und man kann nicht verhindern, dass Leute vorgeben, Essen zu bestellen, um die Rechnung zu manipulieren. Die Lösung besteht darin, sich darauf zu einigen, wer für das verschwendete Essen bezahlt, und die Preise basierend darauf festzulegen, was die Leute normalerweise bestellen, und nicht darauf, was sie gerade jetzt behaupten zu bestellen.

Technisches Resümee: Die Gefahren der Parallelität: Transaktionsgebührmechanismen unter Ausführungsunsicherheit

1. Problemstellung

Moderne Blockchains gehen von sequenzieller zu paralleler Ausführung über, um Durchsatzengpässe zu überwinden, die durch die Ausführung und nicht durch den Konsens verursacht werden. Während die parallele Ausführung (verwendet oder geplant von Chains wie Sui, Solana, Monad und Ethereum) die Kapazität erhöht, führt sie zwei kritische ökonomische Herausforderungen ein, wenn Transaktionen mit Ausführungsunsicherheit (Kontingenz) und Ressourcenkonflikten zu tun haben:

Ausführungskontingenz und Risikoallokation: In ausdrucksstarken Smart-Contract-Sprachen (Turing-vollständig) hängt der Ressourcenverbrauch einer Transaktion (die aufgerufenen Objekte) oft vom Zustand der Blockchain zur Laufzeit ab, was vor der Ausführung nicht bekannt sein kann. Dies erzeugt ein Spannungsfeld zwischen dem Nutzerrisiko (Nutzer zahlen zu viel für deklarierte Objekte, die nicht verwendet werden) und dem Scheduler-Risiko (Scheduler verliert Einnahmen, wenn reservierte Kapazität aufgrund von Unterausführung unbezahlt bleibt).
Shill-Angriffe auf die Gas-Berechnung: Bestehende Gas-Berechnungsmechanismen (GCMs), die für parallele Umgebungen konzipiert sind (z. B. Shapley-Wert oder zeitproportionale Makespan), sind anfällig für rationale Manipulation. Sowohl Nutzer als auch Scheduler können „Shill“-Transaktionen (gefälschte Transaktionen) einspeisen, um die berechnete Menge an Gas oder Gebühren strategisch zu verändern. Nutzer können ihre Gebühren senken, indem sie nutzlose parallele Transaktionen hinzufügen, während Scheduler Gebühren erhöhen können, indem sie künstliche Konflikte erzeugen.

Das Paper argumentiert, dass aktuelle Designs versagen, da sie Parallelität, Ausführungsunsicherheit und ökonomische Robustheit nicht gleichzeitig berücksichtigen können, was zu Ineffizienzen und ausnutzbaren Schwachstellen führt.

2. Methodik und Modell

Die Autoren formalisieren einen Rahmen zur Analyse von Transaktionsgebührmechanismen (TFMs) unter paralleler Ausführung mit Unsicherheit.

Transaktionsmodell: Eine Transaktion $tx$ ist definiert durch Recheneinheiten $t$ , eine Prioritätsgebühr $g$ und deklarierte Lese-/Schreibmengen $(R, W)$ . Entscheidend ist, dass die tatsächlich aufgerufenen Objekte ( $X_R, X_W$ ) je nach Ausführungspfad eine Teilmenge der deklarierten Mengen sein können (Kontingenz).
Gebührendefinitionen: Das Paper unterscheidet zwischen:
- Erreichbare Gebühr ( $f_{att}$ ): Die Gebühr, falls alle deklarierten Objekte verwendet werden.
- Basisgebühr ( $f_{base}$ ): Die Gebühr nur für deterministische Objekte.
- Nutzer-ideale Gebühr ( $f_{ui}$ ): Die Gebühr für exakt die tatsächlich verwendeten Objekte.
- Tatsächlich gezahlte Gebühr ( $f_{act}$ ): Die berechnete Gebühr.
Risikometriken:
- **Nutzerrisiko ($UR $):**$ f_{act} - f_{ui}$ (Überzahlung).
- **Scheduler-Risiko ($SR $):**$ f_{att} - f_{act}$ (nicht realisierter Umsatz).
Adversarielles Modell: Nutzer und Scheduler werden als rationale, ökonomisch motivierte Agenten modelliert, die Shills einspeisen können, um ihre Kosten zu minimieren bzw. ihren Umsatz zu maximieren.
Komplexitätsanalyse: Das Paper nutzt die Komplexitätstheorie (speziell P-Vollständigkeit), um die Schwierigkeit der Vorhersage der Objektnutzung ohne Ausführung zu analysen.

3. Zentrale Beiträge und Ergebnisse

A. Unmöglichkeit der gleichzeitigen Eliminierung von Risiken

Das Paper beweist ein fundamentales Unmöglichkeitsresultat: Kein Mechanismus kann gleichzeitig das Nutzerrisiko und das Scheduler-Risiko eliminieren, ohne Transaktionen vorab auszuführen oder zu konstanten Gebühren zu kollabieren.

Theorem 1: Wenn ein Scheduler durch ein Rechelimit $G$ beschränkt ist (nicht mehr Arbeit leisten kann, als der Block erlaubt), ist es unmöglich, Zahlungen so festzulegen, dass $UR=0$ und $SR=0$ für alle Eingaben gilt, die mit konfliktbehafteten kontingenten Transaktionen involviert sind.
Theorem 2 (P-Vollständigkeit): Zu entscheiden, ob ein spezifisches Objekt durch eine kontingente Transaktion verwendet wird (das Object Usage Decision Problem), ist P-vollständig. Dies impliziert, dass die Verifizierung der Objektnutzung sequenzielle Arbeit erfordert, die proportional zur Ausführungszeit ist, was es für einen Scheduler rechnerisch unmöglich macht, die Nutzung „günstig“ vor der Ausführung vorherzusagen.
Trade-off: Es besteht ein inhärenter linearer Trade-off. Die Reduzierung des Nutzerrisikos (nur für genutzte Objekte zu berechnen) erhöht das Scheduler-Risiko (Umsatzverlust) und umgekehrt.

B. Charakterisierung von Risiko-Teilungsmechanismen

Angesichts der Unmöglichkeit charakterisieren die Autoren den Designraum über drei kanonische Risiko-Teilungsmechanismen, die durch $\alpha \in [0,1]$ parametrisiert sind:

Nutzerfreundlich ( $\alpha=0$ ): Nutzer zahlen nur für die realisierte Ausführung ( $f_{act} = f_{ui}$ ). Der Scheduler trägt das gesamte Risiko.
Scheduler-freundlich ( $\alpha=1$ ): Nutzer zahlen für alle deklarierten Objekte ( $f_{act} = f_{att}$ ). Der Nutzer trägt das gesamte Risiko.
„Even-Steven“ ( $\alpha=0.5$ ): Das Risiko wird gleichmäßig geteilt.
Das Paper analysiert diese unter verschiedenen Scheduler-Utility-Modellen (optimistisch, pessimistisch, median), um die Auswirkungen auf den Umsatz abzubilden.

C. Shill-Angriffe und gebührenbasierte Shill-Robustheit

Das Paper stellt fest, dass Standard-GCM-Eigenschaften (wie die Mengeninklusion) nicht ausreichen, um Shill-Angriffe in Anwesenheit von Kontingenz zu verhindern.

Nutzer-Shill-Angriffe: Nutzer schleusen gefälschte Transaktionen ein, um das effektive Gas/die Gebühr ihrer echten Transaktion zu senken.
Scheduler-Shill-Angriffe: Scheduler schleusen gefälschte Transaktionen ein, um die Gebühren für ehrliche Nutzer zu erhöhen.
Gebührenbasierte Shill-Robustheit: Die Autoren schlagen neue Definitionen für die Shill-Robustheit vor, die auf Gebühren statt nur auf Gas basieren und dabei Prioritätsgebühren sowie Ausführungskontingenz berücksichtigen. Sie beweisen, dass für nutzerfreundliche Mechanismen die Shill-Robustheit nur dann erreichbar ist, wenn die Gebühr unabhängig vom Schedule ist (Theorem 3).

D. Der objektengewichtete TFM (OW-TFM)

Um diese Probleme zu lösen, schlagen die Autoren den Object-Weighted Transaction Fee Mechanism (OW-TFM) vor.

Mechanismus: Gebühren werden basierend auf dem Preis der von der Transaktion deklarierten Objekte berechnet, wobei die Objektpreise basierend auf der historischen Auslastung aktualisiert werden (ähnlich wie EIP-1559).
Risikoparametrisierung: Der Mechanismus nutzt einen Parameter $\alpha$ , um zu bestimmen, wie viel ein Nutzer für deklarierte, aber ungenutzte Objekte zahlt ( $\alpha \cdot \text{Preis}$ ).
Shill-Resistenz: Es wird gezeigt, dass der OW-TFM unter spezifischen Bedingungen Shill-resistent ist. Da die Preise aus der vergangenen Blockauslastung abgeleitet werden, kann eine Shill-Transaktion im aktuellen Block den Preis eines Objekts für den aktuellen Block nicht senken (sie kann nur zukünftige Preise erhöhen).
Bedingungen: Lemma 4 legt einen Schwellenwert für $\alpha$ fest, der erforderlich ist, um Scheduler-Shill-Angriffe zu verhindern, abhängig vom Verhältnis von Prioritäts- zu Basisgebühr ( $\pi_o$ ), der Preisresponsivität ( $\eta$ ) und dem Retention-Verhältnis ( $\gamma$ ).

4. Bedeutung und Ansprüche

Das Paper beansprucht, die rigorosen Grundlagen für die Evaluierung und das Design von Gebührmechanismen für parallele Blockchains zu liefern. Seine Bedeutung liegt in:

Identifizierung fundamentaler Grenzen: Es zeigt auf, dass die Spannung zwischen Nutzergerechtigkeit und Scheduler-Einnahmen in der parallelen Ausführung kein Designfehler ist, sondern eine fundamentale Folge der Ausführungsunsicherheit und der computationalen Komplexität.
Aufdeckung von Schwachstellen: Es offenbart, dass bestehende Vorschläge für die parallele Gas-Berechnung (z. B. Shapley-basierte Ansätze) anfällig für rationale Shill-Angriffe sind – eine Bedrohung, die in der Literatur bisher unberücksichtigt blieb.
Bereitstellung eines Design-Frameworks: Es bietet einen fundierten Designraum (das $\alpha$ -Spektrum) und einen konkreten Mechanismus (OW-TFM), der es Systemdesignern ermöglicht, ihre Strategie zur Risikoallokation explizit zu wählen und gleichzeitig die Manipulationsresistenz zu wahren.
Relevanz für die Industrie: Die Ergebnisse lassen sich direkt auf die Designs prominenter paralleler Chains (Sui, Monad, Solana) anwenden und kritisieren auch die Roadmap von Ethereum für die parallele Ausführung via Access Lists.

Die Autoren bewahren einen bescheidenen Ton und merken an, dass ihre Arbeit fundamentale Einschränkungen und Trade-offs identifiziert, anstatt eine einzige „perfekte“ Lösung vorzuschreiben, wobei sie anerkennen, dass die praktische Implementierung weitere Überlegungen zu probabilistischen Ausführungsmodellen und spezifischen Details erfordert.