📈 economics

Ordering by Unanimity: Giving Applications Sequencing Rights Without Breaking Composability

Dieses Paper stellt den „Unanimity Override“-Algorithmus vor, der es Blockchain-Anwendungen ermöglicht, ihre bevorzugte Transaktionssequenzierung durchzusetzen, wenn alle beteiligten Parteien zustimmen, während eine Standardreihenfolge zur Auflösung von Zyklen verwendet wird und die Ausführung spezifischer Transaktionen wie beabsichtigt selbst gegen adversarielle Manipulation garantiert wird.

Ursprüngliche Autoren: Andrea Canidio

Veröffentlicht 2026-07-08

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Andrea Canidio

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 Blockchain wie ein riesiges, gemeinsames digitales Notizbuch vor, in das jeder seine Transaktionen einträgt. In diesem Notizbuch ist Komponierbarkeit die Superkraft, die es verschiedenen Apps ermöglicht, miteinander zu kommunizieren. Sie könnten zum Beispiel auf einer App eine Aktie verkaufen und das Geld sofort nutzen, um auf einer anderen App einen Kredit zu kaufen – alles in einem einzigen Schritt.

Es gibt jedoch ein Problem: Wer entscheidet über die Reihenfolge?

In einer physischen Schlange vor einem Café wird die Person zuerst bedient, die zuerst angekommen ist. Aber in einer Blockchain entscheidet meist derjenige, der die Zeile aufschreibt (der „Block-Proposer“), wer zuerst an der Reihe ist. Dies bereitet App-Entwicklern Kopfzerbrechen.

Eine Auktions-App muss das höchste Gebot vor dem zweithöchsten verarbeiten lassen, sonst bricht die Auktion zusammen.
Eine Trading-App muss ein Preisupdate vor dem Handel durchführen, sonst handeln die Leute zu alten, falschen Preisen.
Eine Stornierungs-App muss eine Bestellung stornieren, bevor jemand versucht, sie auszuführen.

Wenn der Block-Proposer die Reihenfolge bestimmt, kann er versehentlich (oder böswillig) diese Apps durcheinanderbringen.

Die Lösung: „Unanimity Override“ (Einstimmigkeits-Überschreibung)

Der Autor schlägt eine neue Regel vor, die man sich als „Gruppenkonsens-System“ für das Notizbuch vorstellen kann.

Die Kernidee lautet: Wenn alle an einem spezifischen Paar von Transaktionen beteiligten Apps übereinkommen, wer zuerst an der Reihe sein soll, muss das Notizbuch dieser Vereinbarung folgen.

Die gute Nachricht: Wenn App A sagt: „Transaktion X muss vor Y kommen“, und App B (die ebenfalls beide sieht) zustimmt, dann kommt X vor Y. Das System legt dies fest.
Die schlechte Nachricht (Der Zyklus): Manchmal widersprechen sich Apps in einem Kreis.
- App A sagt: X vor Y.
- App B sagt: Y vor Z.
- App C sagt: Z vor X.
- Dies erzeugt einen Zyklus (X → Y → Z → X). Es ist ein Paradoxon. Das System kann sie nicht alle in der Reihenfolge ausführen, die alle wollen.

Den Zyklus brechen: Die „Demotion“-Regel (Herabstufung)

Wenn ein Zyklus auftritt, benötigt das System einen Entscheidungsträger, um die Schleife zu brechen. Das Paper führt eine „Fallback“-Regel ein:

Identifizieren der Unruhestifter: Das System sucht nach Transaktionen, die mit mehreren Apps interagieren, die unterschiedliche Meinungen haben. Diese werden als „Multi-Opinion Transactions“ bezeichnet.
Herabstufen: Das System wählt die Transaktion mit der „niedrigsten Priorität“ im Zyklus (basierend auf einer Standardregel, wie etwa dem niedrigsten gezahlten Gebühr) und stuft sie herab (demoted).
Zurücksetzen: Die herabgestufte Transaktion wird ans Ende der Schlange gesetzt. Der Zyklus ist gebrochen, und die verbleibenden Transaktionen können in der von den Apps gewünschten Reihenfolge ausgeführt werden.

Die zwei großen Garantien

Das Paper beweist, dass selbst wenn ein böswilliger Angreifer versucht, das System zu manipulieren, indem er gefälschte Transaktionen erstellt, um diese Zyklen zu erzwingen, zwei Dinge unmöglich zu brechen sind:

1. Die „Single-App“-Garantie
Wenn eine Transaktion nur mit einer spezifischen App kommuniziert (und diese App eine starke Präferenz hat), kann der Angreifer sie nicht manipulieren.

Analogie: Stellen Sie sich vor, Sie stehen in einer Schlange für ein bestimmtes Geschäft. Nur dieses Geschäft kümmert sich darum, an welcher Stelle Sie in der Schlange stehen. Selbst wenn ein Bully versucht, sich vorzudrängeln, indem er bei anderen Geschäften laut schreit, wird dieses Geschäft Sie trotzdem zuerst lassen, weil nur dieses Geschäft für Ihren Platz relevant ist.
Ergebnis: Apps, die ihre eigene interne Reihenfolge kontrollieren wollen (wie eine Auktion), können dies sicher tun, solange die Nutzer sich an diese App halten.

2. Die „Gated“-Garantie (Gesteuerte Garantie)
Wenn eine Transaktion „gated“ ist (das heißt, niemand, den der Angreifer kontrolliert, kann eine Transaktion erstellen, die höher rangiert als sie), ist sie sicher.

Analogie: Stellen Sie sich eine VIP-Karte vor, die besagt: „Niemand mit einem normalen Ausweis darf vor mir in die Schlange.“ Wenn der Angreifer keinen VIP-Ausweis besitzt (oder keinen fälschen kann), kann er keinen Zyklus erzeugen, um Sie nach hinten zu drängen.
Ergebnis: Kritische Updates (wie Preisfeeds von einer vertrauenswürdigen Quelle) sind geschützt, da der Angreifer das System in ihren Augen nicht legal „überbieten“ kann.

Was ist mit den „herabgestuften“ Transaktionen?

Nur wenn eine Transaktion in einem unordentlichen Zyklus mit mehreren Apps involviert ist und dadurch „herabgestuft“ wird, ignoriert das System den Wunsch einer App.

Der Haken: Das Paper argumentet, dass eine App, die ihre Transaktionen sicher machen möchte, die Nutzer dazu ermutigen sollte, ihre Transaktionen einfach zu halten (also nur mit dieser einen App zu interagieren). Wenn ein Nutzer versucht, besonders ausgefeilt zu sein und gleichzeitig mit vielen Apps zu interagieren, riskiert er, in einen Zyklus zu geraten und herabgestuft zu werden.
Der Anreiz: Dies schafft einen natürlichen Anreiz für Nutzer, sich an die Regeln zu halten. Wenn Sie wollen, dass Ihr Gebot bei einer Auktion gewinnt, versuchen Sie nicht, gleichzeitig zehn andere Dinge zu tun; senden Sie das Gebot einfach an die Auktions-App.

Zusammenfassung

Das Paper führt eine Regel ein, die es Apps erlaubt zu sagen: „Wir brauchen X vor Y“, und die Blockchain hört zu – außer die Apps streiten in einem Kreis. Wenn sie in einem Kreis streiten, bricht das System das Unentschieden, indem es die „niedrigste Priorität“ der Multi-App-Transaktion ans Ende der Schlange schiebt.

Dies schützt die wichtigsten Transaktionen (jene, die einfach oder „gated“ sind) vor Manipulation, während es gleichzeitig ermöglicht, dass die Blockchain ein einzelnes, verbundeneres Notizbuch bleibt, in dem Apps zusammenarbeiten können. Es ist ein Weg, Apps die Kontrolle über ihr eigenes Schicksal zu geben, ohne das gesamte System zu beschädigen.

Technisches Resümee: Ordnung durch Einstimmigkeit

1. Problemstellung

Blockchain-Anwendungen besitzen oft spezifische Präferenzen hinsichtlich der Ausführungsreihenfolge von Transaktionen, um korrekt zu funktionieren. Beispiele hierfür sind Automated Market Maker (AMMs), die benötigen, dass Oracle-Preis-Updates vor Swaps ausgeführt werden, Orderbuch-Börsen, die benötigen, dass Stornierungen vor Marktordern ausgeführt werden, oder On-Chain-Auktionen, die Gebote von hoch nach niedrig verarbeiten müssen. Derzeit wird die Transaktionsreihenfolge durch die zugrunde liegende Blockchain bestimmt (z. B. über Block-Proposer oder Prioritätsgebühren), was jedoch nicht unbedingt mit diesen anwendungsspezifischen Anforderungen übereinstimmen muss.

Bestehende Lösungen zur Erzwingung einer Ordnung opfern oft die Komponierbarkeit – die Fähigkeit von Anwendungen, frei auf einem gemeinsamen Ledger zu interagieren. Beispielsweise sind PropAMMs (Oracle-abhängige AMMs) auf Solana aufgrund dessen spezifischer Ordnungsregeln realisierbar, aber schwierig an anderen Orten zu implementieren; Börsen wie Hyperliquid haben isolierte Chains geschaffen, um ihre Ordnungslogik abzusichern; und Rollups erreichen die Kontrolle über die Ordnung nur durch die Isolierung von Transaktionen von der Basisschicht. Dieses Paper adressiert die Herausforderung, Anwendungen Sequenzierungsrechte zu gewähren, ohne die Blockchain zu fragmentieren oder die Komponierbarkeit zu opfern.

2. Methodik: Unanimity Override (Einstimmigkeits-Override)

Das Paper schlägt eine auf Protokollebene implementierte Ordnungsregel namens Unanimity Override vor. Die Kernintuition ist: Wenn alle an einem Paar von Transaktionen beteiligten Anwendungen über deren relative Reihenfolge einig sind, sollte das Protokoll dieser Übereinstimmung Folge leisten. Wenn Anwendungen uneins sind oder wenn die resultierenden Präferenzen einen Zyklus bilden, löst ein Fallback-Mechanismus den Konflikt auf.

Der Mechanismus

Der Algorithmus operiert in zwei primären Schritten:

Unanimity Relation ( $\succ_u$ ): Eine gerichtete Relation wird konstruiert, wobei $x_i \succ_u x_j$ gilt, wenn und nur wenn jede Anwendung, die mit sowohl $x_i$ als auch $x_j$ interagiert, $x_i$ vor $x_j$ rankt und mindestens eine Anwendung $x_i$ strikt bevorzugt.
- Diese Relation ist im Allgemeinen unvollständig (einige Paare sind nicht gerankt) und nicht-transitiv (Zyklen können entstehen).
- Zyklen entstehen spezifisch dann, wenn Transaktionen mit mehreren „meinungsstarken“ Anwendungen interagieren (Anwendungen, die eine strikte Präferenz geäußert haben).
Zyklusbruch (Fallback): Um eine totale Ausführungsordnung zu erhalten, muss das Protokoll Zyklen aufbrechen. Das Paper führt eine Demotionsregel ein:
- Zyklische Komponenten: Der Algorithmus identifiziert maximale stark zusammenhängende Komponenten (Zyklen) im Unanimity-Graphen.
- Demotion (Abwertung): Innerhalb einer zyklischen Komponente wählt die Regel eine Menge von Transaktionen aus, die „demotiert“ werden. Entscheidend ist, dass nur Multi-Opinion-Transaktionen (jene, die mit $\ge 2$ meinungsstarken Anwendungen interagieren) für eine Demotion infrage kommen.
- Selektionslogik: Der Fallback demotiert iterativ die Multi-Opinion-Transaktion mit dem niedrigsten „Default Order“-Wert (z. B. niedrigstes Prioritätsgebühr), bis die Komponente azyklisch wird.
- Reparierte Relation ( $\tilde{\succ}_u$ ): Demotierte Transaktionen werden aus den Unanimity-Vergleichen innerhalb des Zyklus entfernt und unter alle nicht-demotierten Transaktionen in dieser Komponente platziert. Ihre relative Reihenfolge wird durch die Default-Order bestimmt.
- Vervollständigung: Die resultierende azyklische partielle Ordnung wird mittels eines Reverse-Kahn-Topological-Sort zu einer totalen Ausführungsordnung ( $\succ_e$ ) erweitert, wobei die Default-Order verwendet wird, um Gleichstände innerhalb der Layer aufzulösen.

3. Bedrohungsmodell

Die Analyse setzt eine starke Form der Zensurresistenz voraus (Transaktionen können nicht zurückgehalten werden). Der Angreifer wird als Akteur modelliert, der in der Lage ist:

Neue Anwendungen mit beliebigen Präferenzen bereitzustellen.
Transaktionen mit spezifischen Attributen (z. B. Gebühr, Ziel-Anwendungen) in den Block einzuschleusen.
Die Default-Order ( $U_d$ ) im Worst-Case-Szenario zu kontrollieren (z. B. als Block-Proposer agiert).
Der Angreifer kann keine ehrlichen Transaktionen modifizieren oder die Präferenzen bestehender ehrlicher Anwendungen ändern.

4. Zentrale Ergebnisse und Garantien

Das Paper leitet zwei primäre Garantien ab, die gegenüber jeder praktikablen Angreiferstrategie gelten, einschließlich solcher, die die Default-Order kontrollieren:

Garantie 1: Die Single-Opinion-Garantie

Wenn eine Transaktion $x$ mit genau einer meinungsstarken Anwendung interagiert (eine Single-Opinion-Transaktion), und diese Anwendung $x$ strikt vor einer anderen Transaktion $y$ bevorzugt (welche möglicherweise mit anderen Anwendungen interagiert), dann wird $x$ vor $y$ ausgeführt.

Begründung: Da $x$ eine Single-Opinion-Transaktion ist, kann keine andere Anwendung eine Präferenz über das Paar $(x, y)$ ausdrücken. Somit entspricht die Unanimity-Rangfolge der Präferenz der einen Anwendung. Da die Fallback-Regel niemals Single-Opinion-Transaktionen demotiert, wird diese Präferenz in der finalen Ausführungsreihenfolge bewahrt.
Bedeutung: Dies erweitert die Garantien isolierter Rollups auf die Basisschicht. Anwendungen können ihre kritischen Transaktionen (wie Oracle-Updates oder Stornierungen) absichern, indem sie sicherstellen, dass diese nur mit dieser spezifischen Anwendung interagieren, selbst wenn andere Teile der Transaktion andere (nicht-meinungsstarke) Verträge berühren.

Garantie 2: Die Gated Region-Garantie

Es existiert eine Menge von Transaktionen, $X^*$ , bezeichnet als die Gated Region, die gegen Umordnung geschützt ist. Eine Transaktion gehört zu $X^*$ , wenn:

Keine Transaktion außerhalb von $X^*$ (ob präexistierend oder vom Angreifer injizierbar) unaniem über ihr gerankt werden kann.
Der Subgraph der Unanimity-Relationen beschränkt auf $X^*$ azyklisch ist.

Ergebnis: Kein Mitglied von $X^*$ wird jemals demotiert. Folglich wird ein Mitglied von $X^*$ , das unaniem vor einer anderen Transaktion gerankt wurde, zuerst ausgeführt, unabhängig von der Fähigkeit des Angreifers, Transaktionen zu injizieren oder die Default-Order zu kontrollieren.
Anwendung: Dies schützt Transaktionen wie Oracle-Updates von designierten Adressen oder Stornierungen, die von allen relevanten Märkten am höchsten gerankt werden, sofern das „Gate“ (die Menge der Transaktionen, die sie übertreffen könnten) vom Angreifer nicht durchbrochen werden kann.

Vulnerabilität: Multi-Opinion-Transaktionen

Das Paper identifiziert, dass Multi-Opinion-Transaktionen (Interaktion mit $\ge 2$ meinungsstarken Anwendungen) die einzigen sind, die anfällig für Reordering-Angriffe sind. Ein Angreifer kann einen Zyklus unter Einbeziehung einer Ziel-Multi-Opinion-Transaktion konstruieren und Transaktionen injizieren, um den Fallback zu erzwingen, die betreffende Transaktion zu demotieren. Das Paper stellt jedoch fest, dass ein solcher Angriff unmöglich ist, wenn es sich bei dem Ziel um eine Single-Opinion-Transaktion handelt.

5. Vergleich mit Benchmarks

Vs. Angreifer-kontrollierte Default-Order: Unanimity Override reduziert strikt die Menge der umkehrbaren Transaktionspaare im Vergleich zu einem System, in dem der Angreifer die volle Kontrolle über die Blockreihenfolge hat.
Vs. Priority-Fee-Ordering: Der Vergleich ist nuanciert. Unanimity Override schützt Single-Opinion- und Gated-Transaktionen unabhängig von den Gebühren. Für ungeschützte Multi-Opinion-Transaktionen kann die Kosten eines Angriffs (z. B. Front-Running) jedoch je nach spezifischer Topologie des Zyklus und der Gebührenstruktur höher oder niedriger sein. Das Paper merkt an, dass Griefing-Angriffe (das Umordnen ehrlicher Transaktionen, um einen Konkurrenten zu schädigen) unter Unanimity Override möglich sind, unter reinem Priority-Fee-Ordering hingegen unmöglich.

6. Bedeutung und Umfang

Das Paper behauptet, einen Mechanismus bereitzustellen, der den Gestaltungsspielraum für Anwendungen auf Blockchains erweitert, ohne die Komponierbarkeit zu opfern.

Bewahrung von Garantien: Es ermöglicht Anwendungen, Ordnungspräferenzen (wie Oracle-Updates vor Swaps oder Stornierungen vor Trades) durchzusetzen, ohne eine Isolation auf separaten Chains oder Rollups zu benötigen.
Anreizharmonisierung: Der Mechanismus informiert Sender im Voraus, welche Transaktionen sicher sind. Beispielsweise werden Bieter in einer On-Chain-Auktion dazu motiviert, ihre Gebote als Single-Opinion-Transaktionen zu halten, um sicherzustellen, dass sie nicht demotiert werden, wodurch der korrekte Ablauf der Auktion gewährleistet wird.
** Theoretischer Beitrag:** Die Arbeit verbindet die Transaktionsreihenfolge mit der Social-Choice-Theorie. Sie erkennt an, dass die Unanimity-Relation nicht-transitiv ist (eine Folge des Arrowschen Unmöglichkeitstheorems) und schlägt eine spezifische Pareto-Aggregationsregel vor, die die „Unabhängigkeit von irrelevanten Alternativen“ opfert, um eine vollständige, azyklische Ausführungsordnung zu erreichen.

Das Paper schließt mit dem Hinweis, dass die Definition von „Interaktions-Sets“ (welche Anwendungen eine Transaktion berührt) eine praktische Herausforderung darstellt. Es diskutiert den Trade-off zwischen der Verwendung von deklarierten Interaktionen (leichter zu verifizieren, aber potenziell Überschätzung des Multi-Opinion-Status) und tatsächlichen Interaktionen (stärkere Garantien, erfordern aber eine Fixpunktlösung für Konsistenz). Die aktuelle Analyse geht davon aus, dass die Interaktions-Sets gegeben sind.