Riepilogo Tecnico: Ordinamento per Unanimità

1. Definizione del Problema

Le applicazioni blockchain possiedono spesso preferenze specifiche riguardo l'ordine di esecuzione delle transazioni per poter funzionare correttamente. Esempi includono gli automated market makers (AMM) che richiedono che gli aggiornamenti dei prezzi degli oracle precedano gli swap, gli exchange con order-book che necessitano che le cancellazioni vengano eseguite prima degli ordini a mercato, e le aste on-chain che richiedono che le offerte siano elaborate dalla più alta alla più bassa. Attualmente, l'ordinamento delle transazioni è determinato dalla blockchain sottostante (ad esempio, tramite i proposers di blocchi o le commissioni di priorità), il che può non allinearsi con i requisiti specifici delle applicazioni.

Le soluzioni esistenti per imporre l'ordinamento spesso sacrificano la composibilità — ovvero la capacità delle applicazioni di interagire liberamente su un registro condiviso. Ad esempio, i PropAMMs (AMM dipendenti da oracle) sono realizzabili su Solana grazie alle sue specifiche regole di ordinamento, ma sono difficili da implementare altrove; exchange come Hyperliquid hanno creato catene isolate per proteggere la propria logica di ordinamento; e i rollup ottengono il controllo dell'ordinamento solo isolando le transazioni dal livello base. Questo documento affronta la sfida di concedere alle applicazioni diritti di sequenziamento senza frammentare la blockchain o sacrificare la composibilità.

2. Metodologia: Override di Unanimità

Il documento propone una regola di ordinamento a livello di protocollo chiamata override di unanimità (unanimity override). L'intuizione centrale è che se tutte le applicazioni coinvolte in una coppia di transazioni concordano sul loro ordine relativo, il protocollo dovrebbe rispettare tale accordo. Se le applicazioni sono in disaccordo o se le preferenze risultanti formano un ciclo, un meccanismo di fallback risolve il conflitto.

Il Meccanismo

L'algoritmo opera in due fasi principali:

1. Relazione di Unanimità ($\succ_u$): Viene costruita una relazione diretta dove la transazione $x_i \succ_u x_j$ se e solo se ogni applicazione che interagisce con entrambe $x_i$ e $x_j$ classifica $x_i$ sopra $x_j$, e almeno un'applicazione preferisce strettamente $x_i$.

   • Questa relazione è generalmente incompleta (alcune coppie non sono classificate) e non transitiva (possono formarsi cicli).
   • I cicli sorgono specificamente quando le transazioni interagiscono con molteplici applicazioni "opinanti" (applicazioni che hanno espresso preferenze strette).

2. Rottura del Ciclo (Fallback): Per recuperare un ordine di esecuzione totale, il protocolo deve rompere i cicli. Il documento introduce una regola di demozione:

   • Componenti Cicliche: L'algoritmo identifica le componenti fortemente connesse massimali (cicli) nel grafo di unanimità.
   • Demozione: All'interno di una componente ciclica, la regola seleziona un set di transazioni da "demetere". Fondamentalmente, solo le transazioni a opinione multipla (quelle che interagiscono con $\ge 2$ applicazioni opinanti) sono idonee alla demozione.
   • Logica di Selezione: Il fallback demote iterativamente la transazione a opinione multipla con il valore di "ordine predefinito" (es. la commissione di priorità più bassa) più basso finché la componente non diventa aciclica.
   • Relazione Riparata ($\tilde{\succ}_u$): Le transazioni demotate vengono rimosse dai confronti di unanimità all'interno del ciclo e posizionate al di sotto di tutte le transazioni non demotate in quella componente. Il loro ordine relativo è determinato dall'ordine predefinito.
   • Completamento: L'ordine parziale aciclico risultante viene esteso a un ordine di esecuzione totale ($\succ_e$) utilizzando un ordinamento topologico reverse-Kahn, usando l'ordine predefinito per risolvere i pareggi all'interno dei livelli.

3. Modello di Minaccia

L'analisi assume una forma forte di resistenza alla censura (le transazioni non possono essere trattenute). L'attaccante è modellato come un giocatore che può:

• Distribuire nuove applicazioni con preferenze arbitrarie.
• Iniettare transazioni nel blocco con attributi specifici (es. commissione, applicazione target).
• Controllare l'ordine predefinito ($U_d$) nello scenario peggiore (es. agendo come propositi del blocco).
• L'attaccante non può modificare le transazioni oneste o cambiare le preferenze delle applicazioni oneste esistenti.

4. Risultati Chiave e Garanzie

Il documento deriva due garanzie primarie che si mantengono contro qualsiasi strategia di un attaccante fattibile, inclusi quelli che controllano l'ordine predefinito:

Garanzia 1: La Garanzia della Singola Opinione

Se una transazione $x$ interagisce con esattamente un'applicazione opinante (una transazione a singola opinione), e tale applicazione preferisce strettamente $x$ rispetto a un'altra transazione $y$ (che può interagire con altre applicazioni), allora $x$ verrà eseguita prima di $y$.

• Ragionamento: Poiché $x$ è a singola opinione, nessun'altra applicazione può esprimere una preferenza sulla coppia $(x, y)$. Pertanto, la classificazione di unanimità coincide con la preferenza della singola applicazione. Poiché la regola di fallback non demote mai le transazioni a singola opinione, questa preferenza è preservata nell'ordine di esecuzione finale.
• Significato: Questo estende le garanzie dei rollup isolati al livello base. Le applicazioni possono proteggere le loro transazioni critiche (come gli aggiornamenti degli oracle o le cancellazioni) assicurandosi di interagire solo con quella specifica applicazione, anche se parti della transazione toccano contratti non opinanti.

Garanzia 2: La Garanzia della Regione Recintata

Esiste un set di transazioni, $X^*$, definito come la regione recintata (gated region), che è protetta contro il riordinamento. Una transazione appartiene a $X^*$ se:

1. Nessuna transazione esterna a $X^*$ (sia essa preesistente o iniettabile dall'attaccante) può essere classificata unanimemente sopra di essa.
2. Il sottografo delle relazioni di unanimità ristretto a $X^*$ è aciclico.

• Risultato: Nessun membro di $X^*$ viene mai demotato. Di conseguenza, se una transazione in $X^*$ è unanimemente classificata sopra un'altra, essa viene eseguita per prima, indipendentemente dalla capacità dell'attaccante di iniettare transazioni o controllare l'ordine predefinito.
• Applicazione: Ciò protegge le transazioni come gli aggiornamenti degli oracle da indirizzi designati o le cancellazioni che sono classificate come le più alte da tutti i mercati rilevanti, a condizione che il "cancello" (l'insieme di transazioni che potrebbero superarle in classifica) non possa essere violato dall'attaccante.

Vulnerabilità: Transazioni a Opinione Multipla

Il documento identifica che le transazioni a opinione multipla (che interagiscono con $\ge 2$ applicazioni opinanti) sono le uniche vulnerabili agli attacchi di riordinamento. Un attaccante può costruire un ciclo che coinvolga una transazione target a opinione multipla e iniettare transazioni per forzare il fallback a demotarla. Tuttavia, il documento nota che se il target è una transazione a singola opinione, un tale attacco è impossibile.

5. Confronto con i Benchmark

• Vs. Ordine Predefinito Controllato dall'Attaccante: L'override di unanimità riduce strettamente l'insieme delle coppie di transazioni reversibili rispetto a un sistema in cui l'attaccante ha il pieno controllo sull'ordine del blocco.
• Vs. Ordinamento per Commissione di Priorità: Il confronto è sfumato. L'override di unanimità protegge le transazioni a singola opinione e quelle della regione recintata indipendentemente dalle commissioni. Tuttavia, per le transazioni a opinione multipla non protette, il costo di un attacco (es. front-running) può essere superiore o inferiore a seconda della specifica topologia del ciclo e della struttura delle commissioni. Il documento nota che gli attacchi di griefing (riordinare transazioni oneste per danneggiare un competitore) sono possibili sotto l'override di unanimità, ma impossibili sotto il puro ordinamento per commissione di priorità.

6. Significato e Ambito

Il documento sostiene di fornire un meccanismo che espande lo spazio di progettazione delle applicazioni su blockchain senza sacrificare la composibilità.

• Preservazione delle Garanzie: Permette alle applicazioni di imporre preferenze di ordinamento (come aggiornamenti di oracle prima di uno swap o cancellazioni prima di un trade) senza richiedere l'isolamento su catene separate o rollup.
• Allineamento degli Incentivi: Il meccanismo comunica ai mittenti in anticipo quali transazioni sono sicure. Ad esempio, in un'asta on-chain, i partecipanti sono incentivati a mantenere le loro offerte come transazioni a singola opinione per garantire che non vengano demotate, assicurando così che l'asta funzioni come previsto.
• Contributo Teorico: Il lavoro collega l'ordinamento delle transazioni alla teoria della scelta sociale. Riconosce che la relazione di unanimità è non transitiva (una conseguenza del Teorema dell'Impossibilità di Arrow) e propone una specifica regola di aggregazione paretiana che sacrifica l'"indipendenza dalle alternative irrilevanti" per ottenere un ordine di esecuzione completo e aciclico.

Il documento conclude notando che la definizione di "insiemi di interazione" (quali applicazioni una transazione tocca) è una sfida pratica. Discute il compromesso tra l'uso di interazioni dichiarate (più facili da verificare, ma potenzialmente sovrastimanti lo stato di opinione multipla) e interazioni effettive (garanzie più forti, ma che richiedono una soluzione a punto fisso per la coerenza). L'analisi attuale assume che gli insiemi di interazione siano forniti.