La governance di Uniswap sta valutando una richiesta di commenti, o RFC, che introdurrebbe un percorso opzionale di esecuzione privata all’interno dell’interfaccia Uniswap. La proposta utilizzerebbe gli hook di Uniswap v4 e UniswapX per ridurre la quantità di informazioni sulle transazioni esposte prima dell’esecuzione di uno swap.

L’RFC, presentata da SilentSwap, descrive la funzionalità proposta come un’opzione “Swap Privately”. Secondo la proposta, gli swap standard rimarrebbero invariati e le commissioni dei pool non sarebbero interessate. Il design suggerito si basa su zk-SNARKs e su controlli di conformità pre-esecuzione per supportare un’elaborazione degli scambi più privata.

Il problema degli utenti alla base del design tecnico è diretto: gli swap on-chain sono trasparenti. Questa trasparenza è una caratteristica fondamentale della finanza decentralizzata, ma può anche rivelare l’intento della transazione prima dell’esecuzione. Quando queste informazioni diventano visibili, bot e trader sofisticati possono essere in grado di effettuare front-running, sandwich attack o comunque sfruttare gli utenti.

Poiché Uniswap è una delle interfacce di trading più utilizzate nella DeFi, una discussione di governance sulla privacy dell’esecuzione potrebbe avere una rilevanza superiore a quella di una singola funzione dell’interfaccia. La proposta rimane un tema di discussione e non è stata approvata né distribuita.

Perché la privacy degli swap è importante

Il trading DeFi affronta da tempo un problema di visibilità. Quando gli utenti inviano transazioni, le loro intenzioni possono diventare visibili prima del regolamento finale. I bot possono monitorare le transazioni in sospeso, stimare il probabile impatto sul prezzo e inserire le proprie operazioni intorno alla transazione di un utente. Questo può portare a un’esecuzione peggiore per i trader ordinari.

MEV, sandwich attack e leakage dell’esecuzione sono problemi ricorrenti nella DeFi da anni. Il termine MEV, abbreviazione di maximal extractable value, è stato formalizzato intorno al 2019 e da allora è diventato una sfida strutturale riconosciuta nel trading basato su Ethereum. Infrastrutture come Flashbots’ MEV-Boost, ampiamente adottate dopo il passaggio di Ethereum al proof-of-stake, sono state costruite per affrontare alcuni aspetti di questo problema a livello di costruzione dei blocchi. Alcuni utenti si affidano anche a RPC privati, aggregatori, controlli di slippage o strumenti di routing più avanzati per ridurre l’esposizione. Altri non usano queste protezioni, perché non ne sono a conoscenza o perché gli strumenti non fanno parte del loro normale flusso operativo di trading.

Un percorso di esecuzione privata mirerebbe a rendere questo tipo di protezione più facilmente accessibile a livello di interfaccia. La distinzione è importante perché la maggior parte degli utenti interagisce con la DeFi tramite frontend, anziché direttamente tramite smart contract. Se la privacy o la protezione MEV resta limitata a strumenti specialistici, molti utenti potrebbero non adottarla mai.

L’aggiunta di un’opzione “Swap Privately” a un’interfaccia mainstream porterebbe la protezione più vicino al punto in cui gli utenti avviano le operazioni. L’RFC presenta la funzione come opzionale, non come sostituzione dell’esecuzione standard degli swap.

Gli hook v4 supporterebbero un design più flessibile

Gli hook di Uniswap v4 sono una parte centrale dell’architettura proposta. Gli hook consentono agli sviluppatori di personalizzare il comportamento dei pool e la logica di esecuzione intorno agli swap. Questa flessibilità può supportare diversi design di routing, strutture di commissioni, meccanismi di gestione degli ordini e funzionalità legate alla privacy. Uniswap v4 stessa rimane in fase di sviluppo e non è ancora stata distribuita su mainnet, il che significa che la base tecnica della funzione proposta è ancora in fase di audit e test.

Secondo l’RFC, gli hook v4 verrebbero utilizzati come parte dell’architettura di esecuzione privata. Anche UniswapX è incluso nel design perché supporta già un’esecuzione degli swap più flessibile attraverso un sistema di routing basato su aste che utilizza filler esterni. UniswapX è stato introdotto nel 2023 e incorpora a sua volta, per design, alcune proprietà di protezione MEV, poiché gli ordini vengono eseguiti off-chain tramite aste competitive anziché inviati direttamente al mempool pubblico. Insieme, i due componenti potrebbero fornire un percorso in cui i dettagli della transazione sono meno esposti prima dell’esecuzione, pur continuando a fare affidamento sulla liquidità e sull’interfaccia di Uniswap.

Il design, tuttavia, resta soggetto alla discussione di governance. Un RFC non è una modifica di governance approvata e non significa che la funzione sia live. È una proposta che la comunità deve esaminare, criticare, perfezionare o respingere.

Privacy e compliance vengono affrontate insieme

Uno degli elementi rilevanti dell’RFC è la combinazione di funzionalità di privacy con controlli di conformità pre-esecuzione. La proposta riflette un cambiamento più ampio nelle discussioni sulla privacy nella DeFi, in cui privacy e compliance sono sempre più trattate come considerazioni progettuali che potrebbero dover coesistere.

I dibattiti precedenti nel settore crypto spesso presentavano privacy e compliance come obiettivi contrapposti: le transazioni erano visibili e conformi, oppure private e potenzialmente sospette. L’RFC adotta un approccio più sfumato, tentando di proteggere gli utenti da front-running e perdita di dati, includendo al contempo controlli di conformità.

L’uso proposto degli zk-SNARKs attinge a una tecnologia testata sul campo in progetti come Zcash, lanciato nel 2016, e nei rollup zero-knowledge di Ethereum che hanno guadagnato adozione dal 2023. Gli zk-SNARKs consentono a una parte di dimostrare la conoscenza di informazioni senza rivelare le informazioni stesse, rendendoli rilevanti sia per la privacy sia per i design di compliance basati sulla divulgazione selettiva.

Gli utenti possono volere protezione dalla fuoriuscita dell’intento di transazione e da comportamenti predatori nell’esecuzione. Allo stesso tempo, regolatori e protocolli possono cercare di evitare strumenti che facilitino attività sanzionate o altri abusi. I builder stanno quindi esplorando sistemi in grado di proteggere gli utenti legittimi preservando una qualche forma di controllo di conformità.

Questo equilibrio è difficile e probabilmente resterà controverso. Il fatto che la governance di Uniswap stia discutendo un modello che coinvolge zk-SNARKs e controlli di conformità mostra quanto la conversazione sulla privacy nella DeFi sia diventata più complessa.

L’approvazione non è garantita

L’RFC non dovrebbe essere considerato un prodotto completato o approvato. La governance di Uniswap dovrebbe ancora valutare se il design sia appropriato, se l’implementazione tecnica sia sicura, se le assunzioni sulla compliance siano accettabili, se l’esperienza utente sia chiara e se la funzione introduca nuovi rischi per il protocollo o l’interfaccia.

Le potenziali preoccupazioni includono complessità tecnica, assunzioni di fiducia, fornitori di screening, esposizione legale, costi e la possibilità che gli utenti comprendano cosa significhi “privato” in questo contesto. Queste domande sono centrali in qualsiasi tentativo di aggiungere privacy dell’esecuzione a una grande interfaccia DeFi.

La privacy dell’esecuzione è un tema sensibile perché un sistema progettato male potrebbe creare falsa sicurezza o nuove superfici di attacco. Un sistema ben progettato potrebbe rendere il trading on-chain più sicuro per gli utenti ordinari riducendo l’esposizione ad alcune forme di esecuzione predatoria.

Il ruolo di Uniswap nella struttura di mercato della DeFi

La posizione di Uniswap nel trading decentralizzato conferisce alla proposta una rilevanza più ampia. Quando Uniswap esplora nuovi modelli di esecuzione, altri protocolli DeFi, DEX e aggregatori probabilmente ne valuteranno le implicazioni. Il protocollo e l’interfaccia sono profondamente integrati nel modo in cui gli utenti fanno trading on-chain.

Altre piattaforme di trading decentralizzato hanno già perseguito approcci diversi alla protezione da MEV e dell’esecuzione. CoW Swap utilizza aste batch con competizione tra solver per ridurre la capacità dei bot di riordinare o inserire operazioni. 1inch ha integrato funzionalità pensate per mitigare il front-running. L’RFC di Uniswap aggiunge un altro approccio progettuale a questa conversazione di settore in corso.

Un’opzione di privacy all’interno di quel flusso di trading potrebbe influenzare ciò che gli utenti si aspettano da altri exchange decentralizzati e aggregatori. Potrebbe anche contribuire a una discussione più ampia sugli standard di esecuzione nella DeFi.

Gli utenti non dovrebbero dover comprendere MEV a un livello tecnico profondo per ridurre il rischio di essere sfruttati. Strumenti a livello di interfaccia possono offrire impostazioni predefinite più sicure o opzioni più chiare per gli utenti che altrimenti si affidano a percorsi pubblici di invio delle transazioni.

Per ora, l’RFC resta soltanto una proposta. Indica un possibile modello in cui gli swap DeFi continuano a regolarsi in modo trasparente on-chain, esponendo però meno informazioni durante il periodo in cui gli utenti sono più vulnerabili al leakage dell’esecuzione.

Questo articolo si basa sull’RFC della governance di Uniswap sulla privacy nativa dell’esecuzione tramite v4 hooks e UniswapX. Il report originale di Bitcoinist è stato scritto dal News Desk e curato da Samuel Rae, e si basava su informazioni pubblicate nella documentazione di fonte primaria.