Autore: Quintus Kilbourn, Georgios Konstantopoulos, Paradigm Traduzione: Golden Finance 0xxz

introduzione

Recentemente, le discussioni sugli “intenti” e sulle loro applicazioni sono diventate un argomento caldo nella comunità di Ethereum.

Se le transazioni si riferiscono esplicitamente a "come" dovrebbe essere eseguita un'azione, gli intenti si riferiscono a "quali" dovrebbero essere i risultati attesi dall'azione. Se una transazione dice "Prima fai A, poi fai B, paga completamente C per ottenere X", allora gli intenti dicono "Voglio X, sono disposto a pagare fino a C".

Questo paradigma dichiarativo sblocca un'esperienza utente entusiasmante e miglioramenti dell'efficienza. Attraverso gli intenti, gli utenti possono semplicemente esprimere il risultato desiderato mentre esternalizzano i compiti migliori per raggiungere tale risultato a una terza parte esperta. Il concetto di intenti contrasta con l'odierno paradigma di transazione imperativa, dove ogni parametro è esplicitamente specificato dall'utente.

Sebbene la promessa di questi miglioramenti costituisca un passo estremamente necessario per l’ecosistema, la progettazione basata sugli intenti su Ethereum potrebbe anche avere un impatto significativo sull’infrastruttura off-chain. In particolare, esistono collegamenti importanti con le attività legate al MEV e i controlli del mercato. Questo articolo mira a fornire una breve definizione degli intenti e dei relativi vantaggi, un'esplorazione dei rischi coinvolti nella loro implementazione e alcune discussioni sulle potenziali mitigazioni.

Cosa sono gli intenti?

L'attuale modo standard con cui gli utenti interagiscono con Ethereum è effettuare e firmare transazioni, un messaggio appositamente formattato che fornisce tutte le informazioni necessarie affinché l'Ethereum Virtual Machine (EVM) esegua le transizioni di stato. Tuttavia, creare una transazione può essere una questione complicata. La creazione di transazioni richiede un ragionamento su dettagli come una vasta rete di contratti intelligenti e la gestione dei numeri casuali, pur detenendo risorse specifiche per pagare le tariffe del gas. Questa complessità porta a un'esperienza utente non ottimale e a una ridotta efficienza poiché gli utenti sono costretti a prendere decisioni senza un accesso adeguato alle informazioni o strategie di esecuzione sofisticate.

Gli intenti sono progettati per alleviare gli utenti da questi oneri. In modo informale, gli intenti firmano una serie di vincoli dichiarativi che consentono agli utenti di esternalizzare la creazione delle transazioni a terzi senza rinunciare al pieno controllo delle parti che effettuano la transazione.

In un processo standard basato su transazioni, le firme delle transazioni consentono ai validatori di seguire esattamente un percorso computazionale per uno stato specifico, mentre i suggerimenti incentivano i validatori a farlo. Gli intenti, d'altro canto, non specificano esplicitamente un percorso di calcolo da intraprendere, ma consentono qualsiasi percorso di calcolo che soddisfi determinati vincoli. Firmando e condividendo gli intenti, gli utenti concedono effettivamente ai destinatari il permesso di scegliere i percorsi computazionali per loro conto (vedi immagine sotto). Questa distinzione consente di definire gli intenti in modo leggermente più rigoroso come messaggi firmati, consentendo una serie di transizioni di stato da un dato stato iniziale, un caso speciale sono le transazioni che consentono transizioni univoche. Detto questo, continueremo a distinguere gli “intenti” dalle transazioni.

Figura 1: Quando si invia una transazione, l'utente specifica l'esatto percorso di calcolo. Quando invia gli intenti, l'utente specifica l'obiettivo e alcuni vincoli e il processo di corrispondenza determina il percorso computazionale da intraprendere.

È importante sottolineare che molti intenti possono essere inclusi in un'unica transazione, consentendo la corrispondenza di intenti sovrapposti, aumentando l'efficienza economica e del gas, ad esempio in un portafoglio ordini gestito da un costruttore, due ordini possono essere abbinati tra loro prima di entrare nel mercato. Altre applicazioni includono intenti interdominio - firma di un messaggio invece di transazioni multiple su domini diversi - utilizzando diversi schemi di resistenza alla riproduzione e pagamenti di gas utente più flessibili, come consentire a 3 parti seconde di sponsorizzare il gas o pagare con token diversi.

Il passato e il futuro delle intenzioni

Sono stati creati intenti che esternalizzano la complessità dell’interazione con la blockchain consentendo allo stesso tempo agli utenti di mantenere la custodia delle proprie risorse e identità crittografiche.

Potresti notare che molte di queste idee corrispondono a sistemi che funzionano da molti anni:

  • Ordine con limite: se ricevo almeno 200 Y, 100 X potrebbero essere prelevati dal mio conto.

  • Aste in stile CowSwap: come sopra, ma si affida a una terza parte o a un meccanismo per abbinare molti ordini e massimizzare la qualità di esecuzione.

  • Sponsorizzazione del gas: paga il gas in USDC anziché in ETH. Gli intenti possono essere raggiunti solo abbinando gli intenti, con commissioni pagate in ETH.

  • Delega: consente l'interazione con determinati account solo in determinate modalità pre-autorizzate. Gli intenti vengono soddisfatti solo se la transazione finale aderisce all'elenco di controllo degli accessi specificato nell'intento.

  • Transazioni batch: consente l'elaborazione batch di intenti per migliorare l'efficienza del gas.

  • Aggregatori: operano utilizzando solo il "miglior" prezzo/rendimento. Questo intento può essere raggiunto dimostrando che è stata eseguita l'aggregazione di più posizioni e che è stato intrapreso il percorso migliore.

Guardando al futuro, le intenzioni delle persone vengono rivitalizzate nel contesto del MEV cross-chain (come SUAVE), delle astrazioni di account in stile ERC4337 e persino degli ordini Seaport! Mentre ERC4337 sta procedendo a pieno ritmo, altre nuove applicazioni come gli intenti interdominio richiedono ancora ulteriori ricerche.

Fondamentalmente, in tutte le applicazioni basate sugli intenti, vecchie e nuove, è necessario che ci sia almeno un'altra parte che comprenda gli intenti, sia motivata a eseguirli e sia in grado di eseguirli in modo tempestivo. È necessario porsi domande su chi sono queste parti, come si comportano e quali sono le loro motivazioni per determinare l’efficacia, i presupposti di fiducia e l’impatto più ampio dei sistemi guidati dalle intenzioni.

L'intermediario e il suo pool di memoria

Il canale più ovvio affinché gli intenti finiscano nelle mani degli intermediari è il mempool di Ethereum. Sfortunatamente, la progettazione attuale non supporta la propagazione degli intenti. Le preoccupazioni sugli attacchi DoS possono significare che il supporto universale per intenti completamente universali nel mempool di Ethereum è improbabile anche a lungo termine. Come vedremo di seguito, la natura aperta e senza autorizzazione del mempool di Ethereum crea ulteriori barriere all’adozione degli intenti.

In assenza di un mempool Ethereum, i progettisti di sistemi di intenti ora devono affrontare diversi problemi di progettazione. Viene presa una decisione di alto livello se propagare gli intenti a un set di autorizzazioni o fornirli in modo senza autorizzazione in modo che qualsiasi parte possa eseguire l'intento.

Figura 2: Flusso di intenti dagli utenti ai pool di intenti autorizzati/non autorizzati e pubblici/privati, convertiti in transazioni da intermediari e infine in pool di memoria pubblici o direttamente nella catena tramite aste in stile MEV Boost

Pool di memoria senza autorizzazione

Un progetto a cui si potrebbe aspirare è un'API decentralizzata che consenta la propagazione degli intenti tra i vari nodi del sistema, fornendo accesso senza autorizzazione agli attori. Questo è già stato fatto. Ad esempio, spettegolare ordini limite tra relè di protocollo 0x e inserirli in catena quando abbinati. Questa idea viene esplorata anche nel contesto di un pool di memoria ERC4337 condiviso per combattere i rischi di centralizzazione e censura. Tuttavia, la progettazione di un tale pool di intenti senza autorizzazione deve affrontare alcune sfide significative:

  • Anti-DoS: potrebbe essere necessario limitare la funzionalità degli intent per evitare attacchi.

  • Incentivi sulla diffusione: per molte applicazioni, l’esecuzione degli intenti è un’attività redditizia. Pertanto, i nodi che gestiscono un pool di intenti hanno un incentivo a non propagarsi per ridurre la contesa durante l’esecuzione degli intenti.

  • MEV: gli intenti si basano sul buon comportamento dei partecipanti fuori catena per migliorare la qualità dell'esecuzione e si possono incontrare difficoltà utilizzando un pool di intenti pubblico e senza autorizzazione. Se una cattiva esecuzione è redditizia, è probabile che il pooling di intenti senza autorizzazione porti a questo risultato. Questo è simile a quello che viene catturato oggi nel mempool di Ethereum e si prevede che diventi un problema comune per gli intenti legati alla DeFi. Un possibile percorso da seguire potrebbe essere quello di pool di intenti senza autorizzazione ma crittografati.

"pool di memoria" consentito

Le API centralizzate affidabili sono più resistenti ai DoS e non richiedono la propagazione degli intenti. I modelli attendibili forniscono anche alcune basi per il problema del MEV. Finché vale il presupposto della fiducia, la qualità dell’esecuzione dovrebbe essere garantita. Un intermediario affidabile può anche avere una reputazione ad esso associata, fornendo qualche incentivo a fornire una buona esecuzione. Per questo motivo, nel breve termine, i pool di intenti autorizzati saranno interessanti per gli sviluppatori di applicazioni basate su intenti. Tuttavia, come tutti ben sappiamo, il presupposto di una forte fiducia è errato e in qualche modo antitetico a gran parte dell’etica blockchain. Questi problemi vengono affrontati di seguito.

Soluzione ibrida

Alcune soluzioni sono una miscela di quanto sopra. Ad esempio, è possibile propagarsi con autorizzazione ma eseguire senza autorizzazione (supponendo che valga il presupposto di fiducia) o viceversa. Un esempio comune di soluzione ibrida è un'asta del flusso degli ordini.

L’idea di alto livello alla base di questi progetti è che gli utenti che necessitano di controparti potrebbero dover distinguere tra controparti migliori e peggiori (ad esempio, l’altra parte che accetta una transazione a un prezzo favorevole). Il processo di progettazione in genere include una parte fidata che riceve l'intento (o la transazione) dell'utente e facilita l'asta per suo conto. La partecipazione alle aste è (a volte) non autorizzata.

Questi tipi di progetti hanno i loro svantaggi e possono essere soggetti a molte delle preoccupazioni relative al pooling di intenti autorizzati, ma ci sono alcune differenze importanti che diventeranno evidenti in seguito.

In conclusione: le applicazioni basate sugli intenti non coinvolgono solo nuovi formati di messaggi per interagire con i contratti intelligenti, ma coinvolgono anche meccanismi alternativi di propagazione in stile mempool e di scoperta delle controparti. Progettare un meccanismo di scoperta e corrispondenza delle intenzioni che sia compatibile con gli incentivi e allo stesso tempo decentralizzato non è un compito facile.

Cosa potrebbe andare storto?

Sebbene gli intenti siano un nuovo entusiasmante paradigma di transazione, la loro adozione diffusa potrebbe significare che la tendenza più ampia dell’attività degli utenti verso mempool alternativi sta accelerando. Se non gestito adeguatamente, questo cambiamento potrebbe portare alla centralizzazione e al radicamento degli intermediari in cerca di rendita.

flusso degli ordini

Se è consentita l'esecuzione degli intenti, ma l'insieme di autorizzazioni non viene scelto con attenzione, la migrazione dal pool di memoria pubblica potrebbe portare a una concentrazione della produzione di blocchi Ethereum.

La stragrande maggioranza della produzione di blocchi su Ethereum avviene attualmente tramite MEV-Boost, un'implementazione fuori protocollo di Proposer-Builder Separation (PBS), e l'attuale roadmap non fornisce alcuna indicazione che questa interfaccia verrà implementata a breve. PBS fa affidamento sull'esistenza di un mercato competitivo per i costruttori di blocchi per indirizzare MEV al set di validatori. Uno dei problemi principali di PBS è che i costruttori di blocchi sono in grado di ottenere l'accesso esclusivo alle materie prime necessarie per produrre blocchi di valore: transazioni e intenti, noti anche come "flusso degli ordini". Nel linguaggio di PBS, l'accesso autorizzato agli intenti sarà chiamato "Exclusive Order Flow" (EOF). Come discusso in questo articolo, l’EOF nelle mani della parte sbagliata minaccia la struttura del mercato su cui fa affidamento PBS, poiché l’esclusività del flusso degli ordini significa un fossato contro le forze competitive.

I costruttori di blocchi (o entità cooperative) che controllano la maggior parte del flusso degli ordini di Ethereum saranno in grado di produrre la maggior parte dei blocchi della mainnet, aprendo così un vettore per la censura. Poiché la rete fa affidamento sulla competizione tra costruttori per fornire valore ai validatori (o essere distrutta in futuro), il dominio di un singolo costruttore costituirà un trasferimento di valore da Ethereum al costruttore. La ricerca di rendite e la censura rappresentano senza dubbio minacce importanti per l’accordo.

Fiducia

Poiché molte soluzioni richiedono fiducia negli intermediari, lo sviluppo di nuove architetture basate sugli intenti è ostacolato da elevate barriere all’ingresso, il che significa tassi di innovazione e concorrenza più bassi per garantire la qualità dell’esecuzione.

Nel peggiore dei casi, gli utenti possono trovarsi in una posizione in cui solo una parte esegue gli intenti, come nel caso del monopolio della creazione di blocchi nella sezione precedente. In un mondo del genere, i monopoli basati sulla costruzione di blocchi sarebbero in grado di ricavare rendite, e qualsiasi nuova proposta su come gestire le intenzioni verrebbe respinta se i costruttori non le adottassero. I singoli utenti perdono potere negoziale di fronte a un monopolista, un effetto che viene esacerbato quando gli utenti utilizzano le intenzioni per fornire agli intermediari ulteriori gradi di libertà.

Sfortunatamente, la stagnazione del mercato dovuta alle infrastrutture centralizzate non include preoccupazioni per il mercato edilizio. Anche per le imprese che non si occupano di blockbuilding, le barriere all’ingresso più elevate pongono gli intermediari in vantaggio perché devono affrontare poca concorrenza. Ad esempio, consideriamo lo stato attuale del mercato delle aste a flusso di ordini. Diverse entità come Flashbots e CoWswap ricevono la maggior parte del flusso di ordini verso OFA. La distribuzione del flusso degli ordini è in gran parte dovuta al fatto che queste entità esistono da molti anni o sono associate a entità rispettabili, il che significa che sono riuscite a guadagnare un certo livello di fiducia pubblica. Se un nuovo design OFA tenta di entrare nel mercato, chiunque lo gestisca dovrà dedicare molto tempo a convincere gli utenti e i portafogli che sono affidabili e che non abuseranno del proprio potere. La necessità di questa campagna per guadagnare fiducia costituisce certamente una barriera sostanziale all’ingresso.

Il mercato delle aste a flusso di ordini ha iniziato solo di recente a guadagnare terreno, e resta da vedere come si svilupperà la concorrenza, ma il mercato fornisce un esempio illustrativo in cui un mempool autorizzato e affidabile può servire un piccolo numero di partecipanti potenti, danneggiando così il miglior interesse degli utenti.

Il formato intento EIP4337 fornisce un altro esempio di un possibile meccanismo. Considera un mondo in cui è presente un'architettura affidabile per supportare 4337 intent. Cosa accadrebbe se venisse proposto un altro formato di intenti, magari servendo casi d'uso aggiuntivi come funzionalità interdominio, ma gli intermediari fidati stabiliti non adottassero questo nuovo formato (dopo tutto, non ha molta adozione e rilevanza per la loro attività) modello di competizione), l’implementazione del nuovo formato richiede la creazione di fiducia nella nuova entità. Allo stesso modo, ci troviamo in situazioni in cui innoviamo e sfidiamo lo status quo, ma incontriamo barriere all’ingresso basate sulla fiducia.

opacità

Poiché l'architettura a molti intenti richiede agli utenti di rinunciare a un certo controllo sulle proprie risorse on-chain e i mempool autorizzati implicano un certo grado di impenetrabilità esterna, corriamo il rischio di costruire un sistema opaco in cui non si è consapevoli di come o se le aspettative degli utenti vengono soddisfatte e le minacce all’ecosistema rimangono da scoprire.

La sezione precedente tratta i rischi che gli squilibri di potere nel mercato del flusso degli ordini comportano per gli utenti e i protocolli. Un problema correlato è che l’ecosistema di middleware e mempool che si sviluppa tra gli utenti e la blockchain è diventato opaco, anche per gli osservatori più astuti. Questa preoccupazione è particolarmente rilevante per le applicazioni basate sugli intenti che cercano di consentire agli utenti di esternalizzare decisioni importanti come l'instradamento degli ordini.

Le situazioni in cui il MEV ha un impatto negativo sull'esecuzione dell'utente sono solitamente dovute alla rinuncia del boia a operazioni altamente liberali (ad esempio limiti di slippage). Pertanto, non è un grande salto logico affermare che le applicazioni basate sugli intenti che rinunciano a maggiore libertà dovrebbero progettare i propri sistemi di esecuzione con maggiore attenzione. Il risultato peggiore a questo riguardo è un mondo in cui l'utilizzo di applicazioni basate su intent richiede la firma di un intento che scompare (una foresta oscura, se vuoi) e quindi in qualche modo implementato come transazione, ma non è chiaro come o chi abbia creato la transazione. Naturalmente, la capacità di monitorare tali ecosistemi è anche legata alle preoccupazioni sull’EOF e sulle difese basate sulla fiducia.

Mitigare il rischio

Il pool di memoria di Ethereum è limitato. Per alcune app ciò è dovuto alla mancanza di privacy (sandwich grip), mentre per altre è dovuto all'incapacità di supportare una gamma più ampia di formati di messaggi. Ciò mette gli sviluppatori di portafogli e applicazioni in una posizione difficile, poiché devono trovare un modo per connettere gli utenti alla blockchain evitando i pericoli sopra menzionati.

Dall'esame delle domande di cui sopra, possiamo dedurre alcune proprietà di un sistema ideale. Un sistema di questo tipo dovrebbe essere privo di autorizzazioni in modo che chiunque possa abbinare ed eseguire gli intenti senza sacrificare troppo la qualità di esecuzione universale in modo che la distribuzione di nuove applicazioni non richieda la creazione di nuovi pool di memoria e trasparente in modo che siano pubblici i rapporti sul processo di esecuzione; intenti e fornisce dati per eseguire controlli di qualità laddove le garanzie sulla privacy lo consentono.

Mentre team come Flashbots e Anoma stanno lavorando su soluzioni generali che soddisfino i requisiti di cui sopra combinando privacy e assenza di autorizzazione, il sistema ideale potrebbe non essere pronto in tempi brevi. Pertanto, soluzioni diverse possono servire al meglio applicazioni diverse con i propri compromessi. Mentre meccanismi come i crlist, emersi in risposta a molti degli stessi problemi relativi alle applicazioni basate su transazioni, potrebbero non funzionare bene con gli intenti, i gadget che consentono agli utenti di ricorrere alle transazioni quando possibile potrebbero funzionare bene migliorando lo scenario peggiore , un'applicazione che desidera avviare un pool di intenti farebbe meglio a cercare generalità senza autorizzazione e scegliere attentamente un intermediario con autorizzazione.

In generale, chiediamo ai progettisti di app basate sugli intenti di considerare attentamente l'impatto fuori catena delle loro app, poiché queste potrebbero toccare una comunità più ampia oltre alla semplice base di utenti. La comunità presta molta attenzione all'ecosistema fuori catena che circonda Ethereum.

Insomma

L'adozione degli intenti rappresenta un passaggio dal paradigma imperativo al paradigma dichiarativo, che dovrebbe migliorare significativamente l'esperienza dell'utente e le perdite di efficienza dovute al MEV. La necessità di queste applicazioni è chiara e molte applicazioni basate sugli intenti sono ampiamente utilizzate da molti anni.

La crescente adozione di intenti, guidata da ERC4337, potrebbe accelerare il passaggio dal mempool di Ethereum a nuove sedi. Sebbene questa mossa sia ragionevole e inevitabile, i progettisti di applicazioni basate sugli intenti hanno buone ragioni per progettare attentamente i componenti off-chain dei loro sistemi sviluppando allo stesso tempo un’infrastruttura solida.

C’è ancora molta ricerca e ingegneria da fare in questo nascente paradigma di transazione e in aree che non abbiamo trattato in questo articolo, come la progettazione di un linguaggio di espressione di intenti che consenta la privacy.

Mille grazie a Dan Robinson, Charlie Noyes, Matt Huang, John Guibas, Xinyuan Sun ed Elijah Fox per il loro feedback su questo articolo e ad Achal Srinivasan per il suo design.