📈 economics

Ordering by Unanimity: Giving Applications Sequencing Rights Without Breaking Composability

Dit artikel introduceert het "unanimity override"-algoritme, dat blockchain-applicaties in staat stelt om hun voorkeursvolgorde van transacties af te dwingen wanneer alle betrokken partijen het eens zijn, terwijl een standaardvolgorde wordt gebruikt om cycli op te lossen en te garanderen dat specifieke transacties naar wens worden uitgevoerd, zelfs tegen kwaadwillige manipulatie in.

Oorspronkelijke auteurs: Andrea Canidio

Gepubliceerd 2026-07-08

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Andrea Canidio

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een blockchain voor als een gigantisch, gedeeld digitaal schrift waarin iedereen zijn transacties opschrijft. In dit schrift is composability (samenstelbaarheid) de superkracht die ervoor zorgt dat verschillende apps met elkaar kunnen communiceren. Je zou bijvoorbeeld op de ene app een aandeel kunnen verkopen en het geld direct kunnen gebruiken om een lening aan te gaan op een andere app, allemaal in één enkele stap.

Er is echter een probleem: Wie bepaalt de volgorde?

In een fysieke rij bij een koffiebar krijgt de persoon die als eerste arriveert, als eerste bediend. Maar in een blockchain is de persoon die de regel opschrijft (de "block proposer") meestal degene die bepaalt wie eerst komt. Dit zorgt voor een hoofdpijn voor app-ontwikkelaars.

Een veiling-app moet de hoogste bieding vóór de tweede hoogste laten worden verwerkt, anders gaat de veiling kapot.
Een trading-app heeft nodig dat een prijsupdate plaatsvindt vóórdat iemand handelt, anders handelen mensen tegen oude, foutieve prijzen.
Een annulerings-app moet een order annuleren vóórdat iemand probeert de order te vullen.

Als de block proposer de volgorde bepaalt, kunnen ze deze apps per ongeluk (of kwaadwillig) verstoren.

De Oplossing: "Unanimity Override"

De auteur stelt een nieuwe regel voor genaamd Unanimity Override. Zie dit als een "Groepsconsensus"-systeem voor het schrift.

Dit is het kernidee: Als alle apps die betrokken zijn bij een specifieke set transacties het eens zijn over wie er eerst moet komen, moet het schrift dat akkoord respecteren.

Het goede nieuws: Als App A zegt: "Transactie X moet vóór Y gaan," en App B (die ook beide ziet) het ermee eens is, dan gaat X vóór Y. Het systeem legt dit vast.
Het slechte nieuws (De Cyclus): Soms zijn apps het oneens in een cirkel.
- App A zegt: X vóór Y.
- App B zegt: Y vóór Z.
- App C zegt: Z vóór X.
- Dit creëert een cyclus (X → Y → Z → X). Het is een paradox. Het systeem kan ze niet allemaal uitvoeren in de volgorde die iedereen wenst.

De Cyclus Doorbreken: De "Demotion" Regel

Wanneer een cyclus optreedt, heeft het systeem een tie-breaker nodig om de lus te doorbreken. Het papier introduceert een "fallback"-regel:

Identificeer de probleemgevallen: Het systeem zoekt naar transacties die interageren met meerdere apps die conflicterende meningen hebben. Dit worden "Multi-Opinion Transactions" genoemd.
Degradeer ze: Het systeem kiest de transactie met de "laagste prioriteit" in de cyclus (gebaseerd op een standaardregel, zoals wie de laagste vergoeding betaalde) en degradeert deze (demotion).
Reset: De gedegradeerde transactie wordt naar de achterkant van de rij verplaatst. De cyclus is doorbroken en de resterende transacties kunnen in de volgorde worden uitgevoerd die de apps wensten.

De Twee Grote Garanties

Het papier bewijst dat zelfs als een kwaadwillige aanvaller probeert het systeem te manipuleren door nep-transacties te creëren om deze cycli te forceren, twee dingen onmogelijk zijn voor hen om te breken:

1. De "Single-App" Garantie
Als een transactie alleen met één specifieke app communiceert (en die app een sterke voorkeur heeft), kan de aanvaller dit niet verstoren.

Analogie: Stel je voor dat je in een rij staat voor een specifieke winkel. Alleen die winkel geeft om jouw plek in de rij. Zelfs als een pester probeert voor te dringen door bij andere winkels te schreeuwen, zal die winkel je nog steeds als eerste doorlaten omdat zij de enige zijn die er toe doen voor jouw positie.
Resultaat: Apps die hun eigen interne volgorde willen controleren (zoals een veiling), kunnen dit veilig doen, zolang gebruikers zich aan die app houden.

2. De "Gated" Garantie
Als een transactie "gated" is (wat betekent dat niemand die de aanvaller controleert een transactie kan maken die hoger rangschikt dan deze), is deze veilig.

Analogie: Stel je een VIP-pas voor met de tekst: "Niemand met een reguliere badge kan voor mij aansluiten." Als de aanvaller geen VIP-badge heeft (of er geen kan vervalsen), kan hij geen cyclus creëren om jou naar achteren te duwen.
Resultaat: Cruciale updates (zoals prijsfeeds van een vertrouwde bron) zijn beschermd omdat de aanvaller hen in de ogen van het systeem niet legaal kan "overbieden".

Wat gebeurt er met de "Gedegradeerde" Transacties?

De enige keer dat het systeem een wens van een app negeert, is wanneer een transactie betrokken is bij een rommelige cyclus met meerdere apps, en deze wordt "gedegradeerd".

De Catch: Het papier betoogt dat als een app wil dat haar transacties veilig zijn, ze gebruikers moet aanmoedigen om hun transacties simpel te houden (door alleen met die specifie of app te interageren). Als een gebruiker probeert heel ingewikkeld te doen door met veel apps tegelijk te interageren, loopt hij het risico in een cyclus terecht te komen en gedegradeerd te worden.
De Prikkel: Dit creëert een natuurlijke prikkel voor gebruikers om zich aan de regels te houden. Als je wilt dat je bod wint bij een veiling, probeer dan niet tegelijkertijd 10 andere dingen te doen; stuur je bod gewoon naar de veiling-app.

Samenvatting

Het papier introduceert een regel waarmee apps kunnen zeggen: "Wij hebben X vóór Y nodig," en de blockchain luistert — tenzij de apps ruzie maken in een cirkel. Als ze in een cirkel ruzie maken, doorbreekt het systeem de tie en duwt de "laagste prioriteit" multi-app transactie naar de achterkant.

Dit beschermt de belangrijkste transacties (die simpel of "gated" zijn) tegen manipulatie, terwijl het de blockchain toch een enkel, verbonden schrift laat blijven waar apps samen kunnen werken. Het is een manier om apps controle te geven over hun eigen lot zonder het hele systeem te breken.

Technische Samenvatting: Ordening door Unanimiteit

1. Probleemstelling

Blockchain-applicaties hebben vaak specifieke voorkeuren met betrekking tot de executievolgorde van transacties om correct te kunnen functioneren. Voorbeelden zijn automated market makers (AMM's) die vereisen dat oracle prijsupdates voorafgaan aan swaps, orderboek-exchanges die nodig hebben dat annuleringen worden uitgevoerd vóór marktorders, en on-chain veilingen die eisen dat biedingen worden verwerkt van hoog naar laag. Momenteel wordt de transactievolgorde bepaald door de onderliggende blockchain (bijv. via block proposers of priority fees), wat mogelijk niet overeenkomt met deze applicatie-specifieke vereisten.

Bestaande oplossingen om ordening af te dwingen offeren vaak composability op — het vermogen van applicaties om vrij met elkaar te interageren op een gedeelde ledger. Bijvoorbeeld: PropAMMs (oracle-afhankelijke AMM's) zijn haalbaar op Solana vanwege de specifieke ordeningsregels daar, maar zijn moeilijk te implementeren elders; exchanges zoals Hyperliquid hebben geïsoleerde chains gecreëerd om hun ordeningslogica te beveiligen; en rollups bereiken controle over de ordening alleen door transacties te isoleren van de base layer. Dit paper adresseert de uitdaging om applicaties sequencing-rechten te verlenen zonder de blockchain te fragmenteren of composability op te offeren.

2. Methodologie: Unanimity Override

Het paper stelt een op protocolniveau gebaseerde ordeningsregel voor genaamd unanimity override. De kernintuïtie is dat als alle applicaties die betrokken zijn bij een paar transacties instemmen met hun relatieve volgorde, het protocol die overeenkomst moet respecteren. Als applicaties van mening verschillen of als de resulterende voorkeuren een cyclus vormen, lost een fallback-mechanisme het conflict op.

Het Mechanisme

Het algoritme werkt in twee primaire stappen:

Unanimity Relation ( $\succ_u$ ): Een gerichte relatie wordt geconstrueerd waarbij transactie $x_i \succ_u x_j$ geldt indien en slechts indien elke applicatie die met zowel $x_i$ als $x_j$ interacteert, $x_i$ boven $x_j$ rangschikt, en ten minste één applicatie strikt voorkeur geeft aan $x_i$ .
- Deze relatie is over het algemeen incompleet (sommige paren zijn niet gerankt) en niet-transitief (cycli kunnen ontstaan).
- Cycli ontstaan specifiek wanneer transacties interageren met meerdere "opinionated" applicaties (applicaties die strikte voorkeuren hebben geuit).
Cycle Breaking (Fallback): Om een totale executievolgorde te herstellen, moet het protocol cycli doorbreken. Het paper introduceert een demotie-regel:
- Cyclische Componenten: Het algoritme identificeert maximale sterk samenhangende componenten (cycli) in de unanimiteitsgrafiek.
- Demotie: Binnen een cyclische component selecteert de regel een set transacties om te "demoten". Cruciaal is dat alleen multi-opinion transacties (die interageren met $\ge 2$ opinionated applicaties) in aanmerking komen voor demotie.
- Selectielogica: De fallback demoteert iteratief de multi-opinion transactie met de laagste "default order" waarde (bijv. de laagste priority fee) totdat de component acyclisch wordt.
- Gerepareerde Relatie ( $\tilde{\succ}_u$ ): Gedemoteerde transacties worden verwijderd uit de unanimiteitsvergelijkingen binnen de cyclus en onder alle niet-gedemoteerde transacties in die component geplaatst. Hun relatieve volgorde wordt bepaald door de default order.
- Voltooiing: De resulterende acyclische partiële orde wordt uitgebreid tot een totale executievolgorde ( $\succ_e$ ) met behulp van een reverse-Kahn topologische sort, waarbij de default order wordt gebruikt om gelijke rangen binnen lagen te breken.

3. Dreigingsmodel

De analyse gaat uit van een sterke vorm van censorship resistance (transacties kunnen niet worden achtergehouden). De aanvaller wordt gemodelleerd als een speler die kan:

Nieuwe applicaties implementeren met willekeurige voorkeuren.
Transacties in de block injecteren met specifieke attributen (bijv. fee, target applicaties).
De default order ( $U_d$ ) controleren in het slechtste scenario (bijv. optreden als de block proposer).
De aanvaller kan geen eerlijke transacties wijzigen of de voorkeuren van bestaande eerlijke applicaties aanpassen.

4. Belangrijkste Resultaten en Garanties

Het paper leidt twee primaire garanties af die standhouden tegen elke haalbare strategie van een aanvaller, inclusief zij die de default order controleren:

Garantie 1: De Single-Opinion Garantie

Als een transactie $x$ interacteert met exact één opinionated applicatie (een single-opinion transactie), en die applicatie geeft strikt voorkeur aan $x$ boven een andere transactie $y$ (die mogelijk met andere applicaties interacteert), dan zal $x$ vóór $y$ worden uitgevoerd.

Redenering: Omdat $x$ een single-opinion transactie is, kan geen enkele andere applicatie een voorkeur uiten over het paar $(x, y)$ . De unanimiteitsrangschikking komt dus overeen met de voorkeur van die specifieke applicatie. Omdat de fallback-regel nooit single-opinion transacties demoteert, wordt deze voorkeur bewaard in de uiteindelijke executievolgorde.
Betekenis: Dit breidt de garanties van geïsoleerde rollups uit naar de base layer. Applicaties kunnen hun kritieke transacties (zoals oracle updates of annuleringen) beveiligen door ervoor te zorgen dat ze alleen met die specifieke applicatie interageren, zelfs als andere delen van de transactie andere (niet-opinionated) contracten raken.

Garantie 2: De Gated Region Garantie

Er bestaat een set transacties, $X^*$ , de zogenaamde gated region, die beschermd is tegen herordening. Een transactie behoort tot $X^*$ indien:

Geen enkele transactie buiten $X^*$ (of deze nu reeds bestond of door de aanvaller geïnjecteerd kan worden) unaniem boven deze transactie gerangschikt kan worden.
De subgraph van unanimiteitsrelaties beperkt tot $X^*$ acyclisch is.

Resultaat: Geen enkel lid van $X^*$ wordt ooit gedemoteerd. Bijgevolg, als een transactie in $X^*$ unaniem boven een andere transactie staat, wordt deze eerst uitgevoerd, ongeacht het vermogen van de aanvaller om transacties te injecteren of de default order te controleren.
Toepassing: Dit beschermt transacties zoals oracle updates van aangewezen adressen of annuleringen die het hoogst gerangschikt worden door alle relevante markten, mits de "gate" (de set transacties die hen zou kunnen overtreffen) niet door de aanvaller doorbroken kan worden.

Kwetsbaarheid: Multi-Opinion Transacties

Het paper identificeert dat multi-opinion transacties (die interageren met $\ge 2$ opinionated applicaties) de enige zijn die kwetsbaar zijn voor herordeningsaanvallen. Een aanvaller kan een cyclus construeren waarbij een doelwit van een multi-opinion transactie betrokken is en transacties injecteren om de fallback te dwingen deze transactie te demoten. Het paper merkt echter op dat als het doelwit een single-opinion transactie is, een dergelijke aanval onmogelijk is.

5. Vergelijking met Benchmarks

Vs. Aanvaller-gecontroleerde Default Order: Unanimity override reduceert strikt de set van omkeerbare transactieparen vergeleken met een systeem waar de aanvaller volledige controle heeft over de block order.
Vs. Priority-Fee Ordering: De vergelijking is genuanceerd. Unanimity override beschermt single-opinion en gated transacties ongeacht de fees. Echter, voor onbeschermde multi-opinion transacties kan de kosten van een aanval (bijv. front-running) hoger of lager zijn, afhankelijk van de specifieke topologie van de cyclus en de fee-structuur. Het paper merkt op dat griefing-aanvallen (het herordenen van eerlijke transacties om een concurrent te schaden) mogelijk zijn onder unanimity override, maar onmogelijk zijn onder pure priority-fee ordering.

6. Betekenis en Omvang

Het paper beweert een mechanisme te bieden dat de ontwerpruimte voor applicaties op blockchains uitbreidt zonder composability op te offeren.

Behoud van Garanties: Het stelt applicaties in staat om ordeningsvoorkeuren af te dwingen (zoals oracle updates vóór swaps of annuleringen vóór trades) zonder dat zij zich op aparte chains of rollups hoeven te isoleren.
Incentive Alignment: Het mechanisme informeert verzenders vooraf welke transacties veilig zijn. Bijvoorbeeld, in een on-chain veiling worden bieders gestimuleerd om hun biedingen als single-opinion transacties te houden om te voorkomen dat ze gedemoteerd worden, waardoor zij garanderen dat de veiling naar behoren verloopt.
Theoretische Bijdrage: Het werk verbindt transactievolgorde met sociale keuzetheorie. Het erkent dat de unanimiteitsrelatie niet-transitief is (een gevolg van de Stelling van Arrow) en stelt een specifieke Paretiaanse aggregatieregel voor die "onafhankelijkheid van irrelevante alternatieven" opoffert om een volledige, acyclische executievolgorde te bereiken.

Het paper concludeert door te merken dat de definitie van "interactiesets" (welke applicaties een transactie raakt) een praktische uitdaging vormt. Het bespreekt de afweging tussen het gebruik van gedeclareerde interacties (makkelijker te verifiëren, maar potentieel de multi-opinion status overschattend) en werkelijke interacties (sterkere garanties, maar vereist een fixed-point oplossing voor consistentie). De huidige analyse gaat ervan uit dat interactiesets gegeven zijn.