Sintesi Tecnica: I pericoli del parallelismo: Meccanismi di commissione delle transazioni sotto incertezza di esecuzione

1. Definizione del problema

Le moderne blockchain stanno transitando dall'esecuzione seriale a quella parallela per superare i colli di bottiglia del throughput causati dall'esecuzione piuttosto che dal consenso. Sebbene l'esecuzione parallela (utilizzata o pianificata da catene come Sui, Solana, Monad ed Ethereum) aumenti la capacità, introduce due sfide economiche critiche quando le transazioni comportano incertezza di esecuzione (contingenza) e contesa di risorse:

1. Contingenza di esecuzione e allocazione del rischio: Nei linguaggi di smart contract espressivi (Turing-completi), l'uso delle risorse di una transazione (oggetti acceduti) dipende spesso dallo stato della blockchain al tempo di esecuzione, il che non può essere noto prima dell'esecuzione stessa. Ciò crea una tensione tra il Rischio dell'Utente (gli utenti pagano eccessivamente per oggetti dichiarati che non vengono utilizzati) e il Rischio dello Scheduler (gli scheduler perdono entrate quando la capacità riservata non viene pagata a causa di una sotto-esecuzione).
2. Attacchi Shill sulla computazione del gas: Gli attuali Meccanismi di Computazione del Gas (GCM) progettati per contesti paralleli (ad esempio, valore di Shapley o Makespan proporzionale al tempo) sono vulnerabili alla manipolazione razionale. Sia gli utenti che gli scheduler possono iniettare transazioni "shill" (false) per alterare strategicamente il gas o le commissioni calcolate. Gli utenti possono abbassare le proprie commissioni aggiungendo transazioni parallele inutili, mentre gli scheduler possono gonfiare le commissioni aggiungendo contesa fittizia.

Il documento sostiene che gli attuali design non riescono a tenere conto simultaneamente di parallelismo, incertezza di esecuzione e robustezza economica, portando a inefficienze e vulnerabilità sfruttabili.

2. Metodologia e Modello

Gli autori formalizzano un framework per analizzare i Meccanismi di Commissione delle Transazioni (TFM) sotto esecuzione parallela con incertezza.

• Modello di Transazione: Una transazione $tx$ è definita da unità di calcolo $t$, una commissione prioritaria $g$ e set di lettura/scrittura dichiarati $(R, W)$. Fondamentalmente, gli oggetti effettivamente acceduti ($X_R, X_W$) possono essere un sottoinsieme dei set dichiarati a seconda del percorso di esecuzione (contingenza).
• Definizioni di Commissione: Il documento distingue tra:
  • Commissione Attuabile ($f_{att}$): La commissione se tutti gli oggetti dichiarati vengono utilizzati.
  • Commissione Base ($f_{base}$): La commissione per gli soli oggetti deterministici.
  • Commissione Ideale dell'Utente ($f_{ui}$): La commissione per gli oggetti effettivamente utilizzati.
  • Commissione Effettivamente Pagata ($f_{act}$): La commissione addebitata.
• Metriche di Rischio:
  • **Rischio dell'Utente ($UR$):**$f_{act} - f_{ui}$ (sovrappagamento).
  • **Rischio dello Scheduler ($SR$):**$f_{att} - f_{act}$ (entrate non realizzate).
• Modello Avversariale: Utenti e scheduler sono modellati come agenti razionali, economicamente motivati, che possono inserire transazioni shill per minimizzare i propri costi o massimizzare le entrate, rispettivamente.
• Analisi della Complessità: Il documento utilizza la teoria della complessità (specificamente la P-completezza) per analizzare la difficoltà di prevedere l'uso degli oggetti senza esecuzione.

3. Contributi Chiave e Risultati

A. Impossibilità di eliminazione simultanea del rischio

Il documento dimostra un risultato fondamentale di impossibilità: Nessun meccanismo può eliminare simultaneamente sia il Rischio dell'Utente che il Rischio dello Scheduler senza pre-eseguire le transazioni o collassare verso commissioni costanti.

• Teorema 1: Se uno scheduler è vincolato da un limite di calcolo $G$ (non può eseguire più lavoro di quanto consentito dal blocco), è impossibile impostare i pagamenti in modo che $UR=0$e$SR=0$ per tutti gli input che coinvolgono transazioni contingenti conflittuali.
• Teorema 2 (P-completezza): Decidere se un oggetto specifico è utilizzato da una transazione contingente (il Problema della Decisione dell'Uso dell'Oggetto) è P-completo. Ciò implica che verificare l'uso di un oggetto richiede un lavoro sequenziale proporzionale al tempo di esecuzione, rendendo computazionalmente impraticabile per uno scheduler prevedere l'uso "economicamente" prima dell'esecuzione.
• Trade-off: Esiste un trade-off lineare intrinseco. Ridurre il rischio dell'utente (addebitare solo per gli oggetti utilizzati) aumenta il rischio dello scheduler (perdita di entrate), e viceversa.

B. Caratterizzazione dei Meccanismi di Divisione del Rischio

Data l'impossibilità, gli autori caratterizzano lo spazio di progettazione attraverso tre meccanismi canonici di divisione del rischio, parametrizzati da $\alpha \in [0,1]$:

1. User-Friendly ($\alpha=0$): Gli utenti pagano solo per l'esecuzione realizzata ($f_{act} = f_{ui}$). Lo scheduler si assume tutto il rischio.
2. Scheduler-Friendly ($\alpha=1$): Gli utenti pagano per tutti gli oggetti dichiarati ($f_{act} = f_{att}$). L'utente si assume tutto il rischio.
3. Even-Steven ($\alpha=0.5$): Il rischio è diviso equamente.
   Il documento analizza questi casi sotto diversi modelli di utilità dello scheduler (Ottimista, Pessimista, Mediano) per mappare le implicazioni sulle entrate.

C. Attacchi Shill e Resistenza alle Commissioni (Fee-Based Shill-Proofness)

Il documento identifica che le proprietà standard dei GCM (come l'Inclusione dell'Insieme) sono insufficienti per prevenire attacchi shill in presenza di contingenza.

• Attacchi Shill dell'Utente: Gli utenti iniettano transazioni false per ridurre il gas/commissione effettivo della loro transazione reale.
• Attacchi Shill dello Scheduler: Gli scheduler iniettano transazioni false per aumentare il gas/commissione addebitato agli utenti onesti.
• Resistenza alle Commissioni (Fee-Based Shill-Proofness): Gli autori propongono nuove definizioni di resistenza allo shill basate sulle commissioni piuttosto che solo sul gas, tenendo conto delle commissioni prioritarie e della contingenza di esecuzione. Dimostrano che per i meccanismi User-Friendly, la resistenza allo shill è ottenibile solo se la commissione è indipendente dallo schedule (Teorema 3).

D. L'Object-Weighted TFM (OW-TFM)

Per risolvere queste problematiche, gli autori propongono l'Object-Weighted Transaction Fee Mechanism (OW-TFM).

• Meccanismo: Le commissioni sono calcolate in base al prezzo degli oggetti dichiarati dalla transazione, dove i prezzi degli oggetti vengono aggiornati in base all'utilizzo storico (simile a EIP-1559).
• Parametrizzazione del Rischio: Il meccanismo utilizza un parametro $\alpha$ per determinare quanto un utente paga per gli oggetti dichiarati ma non utilizzati ($\alpha \cdot \text{prezzo}$).
• Resistenza allo Shill: L'OW-TFM è dimostrato essere resistente allo shill sotto specifiche condizioni. Poiché i prezzi derivano dall'utilizzo passato, una transazione shill nel blocco corrente non può abbassare il prezzo di un oggetto per il blocco corrente (può solo aumentare i prezzi futuri).
• Condizioni: Il Lemma 4 stabilisce una soglia per $\alpha$ necessaria per prevenire attacchi shill dello scheduler, dipendente dal rapporto tra commissione prioritaria e base ($\pi_o$), dalla reattività del prezzo ($\eta$) e dal rapporto di ritenzione ($\gamma$).

4. Significato e Rivendicazioni

Il documento sostiene di fornire le fondamenta rigorose per valutare e progettare meccanismi di commissione per le blockchain parallele. La sua importanza risiede in:

1. Identificazione dei Limiti Fondamentali: Dimostra che la tensione tra equità per l'utente e entrate dello scheduler nell'esecuzione parallela non è un difetto di progettazione, ma una conseguenza fondamentale dell'incertezza di esecuzione e della complessità computazionale.
2. Esposizione delle Vulnerabilità: Rivela che le attuali proposte per la computazione del gas parallelo (ad esempio, approcci basati su Shapley) sono vulnerabili ad attacchi shill razionali, una minaccia precedentemente non affrontata nella letteratura.
3. Fornitura di un Framework di Progettazione: Offre uno spazio di progettazione principato (lo spettro $\alpha$) e un meccanismo concreto (OW-TFM) che consente ai progettatori di sistema di scegliere esplicitamente la propria strategia di allocazione del rischio mantenendo la resistenza alla manipolazione.
4. Rilevanza per l'Industria: I risultati si applicano direttamente e criticano i design di prominenti catene parallele (Sui, Monad, Solana) e la roadmap di Ethereum per l'esecuzione parallela tramite access list.

Gli autori mantengono un tono modesto, sottolineando che il loro lavoro identifica limiti fondamentali e trade-off piuttosto che prescrivere una singola soluzione "perfetta", riconoscendo che l'implementazione pratica richiede ulteriori considerazioni sui modelli di esecuzione probabilistica e dettagli di implementazione specifici.