Autore originale: Archivio di letture speculari preferite
Compilazione originale: Shenchao TechFlow
Riepilogo dei punti chiave
L'attuale esperienza utente di crittografia predefinita prevede che gli utenti sappiano sempre con quale rete stanno interagendo. Tuttavia, gli utenti di Internet non hanno bisogno di sapere con quale provider cloud interagiscono. Introdurre questo approccio alla blockchain è ciò che chiamiamo Chain Abstraction.
Questo articolo introduce il framework Chain Abstraction Key Elements (CAKE). Il framework è composto da quattro parti: livello di applicazione, livello di autorizzazione, livello di risoluzione e livello di regolamento, con l'obiettivo di fornire agli utenti un'esperienza operativa cross-chain senza soluzione di continuità.
L'implementazione dell'astrazione della catena richiede un insieme complesso di tecnologie per garantire affidabilità, convenienza, sicurezza, velocità e privacy del processo di esecuzione.
Definiamo i compromessi tra catene nell'astrazione della catena come un trilemma e proponiamo sei alternative di progettazione, ciascuna con i suoi vantaggi unici.
Per compiere con successo il salto verso un futuro di astrazione concatenata, come settore dobbiamo definire e adottare uno standard comune per il passaggio delle informazioni tra gli strati di CAKE. Un buon standard è la ciliegina sulla torta.
introduzione
Nel 2020, la rete Ethereum è passata a una roadmap di scalabilità incentrata sul rollup. Quattro anni dopo, sono in uso più di 50 strati di rollup (L2). Sebbene il livello rollup fornisca il ridimensionamento orizzontale richiesto, interrompe completamente l'esperienza dell'utente.
Gli utenti non dovrebbero preoccuparsi o capire con quale rollup stanno interagendo. Gli utenti Crypto sanno quale rollup stanno utilizzando (Optimism o Base), equivalente agli utenti Web2 che sanno quale provider cloud stanno utilizzando (AWS o GCP). La visione di Chain Abstraction è quella di astrarre le informazioni sulla catena dal campo visivo dell'utente. L'utente collega semplicemente il portafoglio alla dApp e firma le azioni previste, i dettagli per garantire che l'utente abbia il corretto equilibrio sulla catena target e esegua le azioni previste sono tutti curati dietro le quinte.
In questo articolo esploreremo come l'astrazione della catena sia un problema veramente multidisciplinare che coinvolge l'interazione del livello dell'applicazione, del livello delle autorizzazioni, del livello del risolutore e del livello di regolamento. Introduciamo il framework Key Elements of Chain Abstraction (CAKE) e approfondiamo i compromessi di progettazione dei sistemi di astrazione a catena.
Presentazione del framework CAKE
Nel mondo dell’astrazione a catena, gli utenti visitano il sito web della dApp, si connettono al proprio portafoglio, firmano le operazioni e attendono il regolamento finale. Tutte le operazioni complesse vengono eseguite nel livello infrastrutturale di CAKE. I tre livelli infrastrutturali di CAKE includono:
Livello di autorizzazione: gli utenti collegano i propri portafogli alle dApp e richiedono preventivi per l'intento dell'utente. L'intento si riferisce al risultato che l'utente si aspetta di ottenere alla fine della transazione, non al percorso della transazione. Ad esempio, trasferisci USDT a un indirizzo Tron o deposita USDC in una strategia di generazione di rendimento su Arbitrum. Il portafoglio dovrebbe essere in grado di leggere le risorse dell'utente (ovvero leggere lo stato) ed eseguire transazioni sulla catena di destinazione (ovvero aggiornare lo stato).
Livello risolutore: il livello risolutore stima le tariffe e la velocità di esecuzione in base al saldo iniziale e alle intenzioni dell'utente. In un contesto cross-chain, questo processo, chiamato risoluzione, è fondamentale perché le transazioni sono asincrone e le transazioni secondarie possono fallire durante l'esecuzione. L’asincronicità introduce un trilemma cross-chain che coinvolge commissioni, velocità di esecuzione e garanzie di esecuzione.
Livello di regolamento: dopo che un utente ha approvato una transazione utilizzando una chiave privata, il livello di regolamento ne garantisce l'esecuzione. Si compone di due passaggi: collegare le risorse dell'utente alla catena target e quindi eseguire la transazione. Se i protocolli utilizzano risolutori complessi per determinate operazioni, possono fornire la propria liquidità ed eseguire operazioni per conto degli utenti senza la necessità di bridge.
Implementare l'astrazione della catena significa fondere i tre livelli infrastrutturali precedenti in un prodotto unificato. Un’intuizione chiave nell’unione di questi livelli è la differenza tra fornitura di informazioni e fornitura di valore. Il trasferimento di informazioni tra catene dovrebbe essere senza perdite, quindi affidati al percorso più sicuro. Ad esempio, gli utenti che votano "sì" da una catena a un voto di governance su un'altra catena non vogliono che il loro voto diventi "forse". D’altro canto, a seconda delle preferenze dell’utente, la fornitura di valore potrebbe andare perduta. È possibile sfruttare una terza parte consolidata per fornire agli utenti una consegna più rapida, economica o con valore garantito. È importante notare che il 95% dello spazio dei blocchi di Ethereum viene utilizzato per il trasferimento di valore, come misurato dalle commissioni pagate ai validatori.
decisioni chiave di progettazione
I tre livelli precedenti introducono le decisioni chiave di progettazione che CAF deve prendere. Queste decisioni riguardano chi controlla l'autorità per eseguire l'intento, quali informazioni vengono divulgate al risolutore e quali percorsi di risoluzione sono a disposizione del risolutore. Di seguito è riportata un'analisi dettagliata di ciascun livello.
Livello di autorizzazione
Il livello di autorizzazione conserva la chiave privata dell'utente e firma i messaggi per conto dell'utente, che vengono poi eseguiti come transazioni sulla catena. CAF deve supportare gli schemi di firma e i carichi utili delle transazioni di tutte le catene target. Ad esempio, i portafogli che supportano lo schema di firma ECDSA e lo standard di transazione EVM saranno limitati a Ethereum, al suo L2 e alle sidechain (come il portafoglio Metamask). D’altra parte, i portafogli che supportano EVM e SVM (Solana VM) saranno in grado di supportare questi due ecosistemi (come il portafoglio Phantom). Va notato che la stessa frase mnemonica può essere utilizzata per generare portafogli sia sulla catena EVM che su quella SVM.
Una transazione multicatena è composta da più transazioni secondarie che devono essere eseguite nell'ordine corretto. Queste sottotransazioni devono essere eseguite su più catene, ciascuna con le proprie commissioni e nonce variabili nel tempo. Il modo in cui queste transazioni secondarie vengono coordinate e regolate è una decisione progettuale chiave per il livello delle autorizzazioni.
Il portafoglio EOA è un software di portafoglio che viene eseguito sul computer dell'utente e ne conserva la chiave privata. Possono essere estensioni basate su browser come Metamask e Phantom, app mobili come Coinbase Wallet o hardware specializzato come Ledger. I portafogli EOA richiedono agli utenti di firmare ciascuna transazione secondaria individualmente, il che attualmente richiede più clic. Richiedono inoltre agli utenti di mantenere saldi tariffari sulla catena target, il che introduce notevoli attriti nel processo. Tuttavia, consentendo agli utenti di firmare più transazioni secondarie con un solo clic, l'attrito di più clic può essere sottratto all'utente.
In un portafoglio Account Abstraction (AA), gli utenti hanno ancora accesso alle proprie chiavi private, ma separano il firmatario del payload della transazione dall'esecutore della transazione. Consente a soggetti complessi di raggruppare ed eseguire transazioni utente in modo atomico (Avocado, Pimlico). I portafogli AA richiedono ancora agli utenti di firmare ciascuna transazione secondaria individualmente (attualmente tramite più clic), ma non richiedono che il saldo delle commissioni venga mantenuto su ciascuna catena.
Gli agenti basati su policy salvano la chiave privata dell'utente in un ambiente di esecuzione separato e generano messaggi firmati per conto dell'utente in base alla policy dell'utente. Telegram Bot, Near Account Aggregator o SUAVE TEE sono portafogli basati sulla strategia mentre Entropy o Capsule sono estensioni del portafoglio basate sulla strategia. Gli utenti devono solo firmare un modulo di approvazione e la successiva firma delle transazioni secondarie e della gestione delle commissioni può essere completata da questi agenti durante l'operazione.
strato risolutore
Dopo che l'utente ha pubblicato l'intento, il livello risolutore prevede la restituzione della tariffa e del tempo di conferma all'utente. Questo problema è strettamente correlato alla progettazione delle aste del flusso degli ordini ed è discusso in dettaglio qui. CAF può sfruttare percorsi intra-protocollo per eseguire l'intento dell'utente o sfruttare terze parti complesse (ad esempio risolutori) per scendere a compromessi su determinate garanzie di sicurezza per fornire agli utenti un'esperienza utente migliore. L'introduzione del solutore nel framework CAF porterà alle due decisioni di progettazione successive, strettamente correlate alle informazioni.
Gli intenti sono costituiti da due tipi di valori estraibili (EV): EV_ordering value ed EV_signal.
EV_ordering è un valore specifico della blockchain che viene generalmente estratto dall'entità che esegue gli ordini degli utenti (come i builder o i validatori di blocchi).
EV_signal rappresenta il valore accessibile a qualsiasi entità che rispetta l'ordine prima che venga registrato ufficialmente sulla blockchain.
Diversi intenti utente hanno distribuzioni diverse tra EV_ordering ed EV_signal. Ad esempio, l’intenzione di scambiare monete su un DEX ha in genere un valore EV_ordering elevato ma un valore EV_signal basso. Al contrario, la componente EV_signal di una transazione hackerata sarà più alta perché il front-running acquisirà più valore rispetto all’esecuzione della transazione. Vale la pena notare che EV_signal a volte può essere negativo, come nel caso del trading con un market maker, dove l'entità che esegue questi ordini può subire perdite poiché il market maker ha una migliore conoscenza delle future condizioni di mercato.
Quando qualcuno è in grado di osservare in anticipo le intenzioni di un utente, può saltare avanti, causando perdite di valore. Inoltre, la possibilità di un segnale EV_negativo crea un ambiente competitivo tra i solutori, inducendoli a presentare offerte più basse, causando un’ulteriore perdita di valore (nota anche come selezione avversa). In definitiva, le fughe di notizie hanno un impatto sugli utenti aumentando le tariffe o offrendo offerte migliori. Tieni presente che commissioni basse o prezzi più alti sono due facce della stessa medaglia e verranno utilizzati in modo intercambiabile nel resto di questo articolo.
Condivisione delle informazioni
Esistono tre modi per condividere le informazioni con il risolutore:
Mempool pubblico: gli intenti dell'utente vengono trasmessi pubblicamente al mempool pubblico o al livello di disponibilità dei dati e il primo risolutore che può soddisfare la richiesta esegue l'ordine e diventa il vincitore. Questo sistema è altamente estrattivo delle informazioni dell'utente perché gli utenti espongono il loro EV_ordering e EV_signal. Ad esempio, il mempool pubblico di Ethereum e vari bridge blockchain. Nel caso di un bridge, gli utenti devono depositare le risorse in garanzia prima di trasferirle alla catena di destinazione per prevenire attacchi dannosi, ma questo processo rende inavvertitamente pubbliche le loro intenzioni.
Condivisione parziale: il CAF può ridurre l'importo del valore divulgato agli offerenti limitando le informazioni divulgate. Tuttavia, questo approccio porterà direttamente alla perdita dell'ottimalità del prezzo e potrebbe portare a problemi come lo spam nelle offerte.
Mempool privati: i recenti sviluppi in MPC e TEE rendono possibili mempool completamente privati. Nessuna informazione viene trapelata al di fuori dell'ambiente di esecuzione e i risolutori codificano le loro preferenze e corrispondono a ciascun intento. Sebbene il mempool privato acquisisca EV_ordering, non può acquisire completamente EV_signal. Ad esempio, se una transazione compromessa viene inviata a mempool, la prima persona che vede l'ordine può anticipare la transazione e acquisire il segnale EV_signal. In un mempool privato, le informazioni vengono rilasciate solo dopo la conferma del blocco, quindi chiunque veda la transazione può acquisire l'EV_signal. È concepibile che il solutore stabilisca nodi di autenticazione per catturare EV_signal da blocchi TEE appena coniati, trasformando l'acquisizione di EV_signal in una competizione ritardata.
Elenco dei risolutori
Il CAF deve anche decidere quanti e quali offerenti potranno partecipare all'asta. Le opzioni principali sono le seguenti:
Accesso aperto: la barriera più bassa possibile all'ingresso per la possibilità di partecipare. Questo è simile all'esposizione di mempool, che fa trapelare EV_signal ed EV_ordering.
Limitare l'accesso: limitare le capacità di esecuzione degli ordini tramite whitelist, sistemi di reputazione, commissioni o aste dei posti. Il meccanismo di gating è necessario per garantire che il segnale EV_non venga catturato dai solutori nel sistema. Ad esempio, aste da 1 pollice, aste Cowswap e aste Uniswap X. La competizione vincitrice degli ordini cattura l'EV_ordering per gli utenti, mentre i meccanismi di gating catturano l'EV_signal per i generatori di ordini (portafogli, dApp).
Accesso esclusivo: L'accesso esclusivo è un formato d'asta speciale in cui viene selezionato un solo risolutore per periodo di tempo. Poiché nessuna informazione viene divulgata ad altri risolutori, non vi è selezione avversa e sconti anticipati. L'iniziatore del flusso degli ordini cattura i valori attesi di EV_signal e EV_ordering e, poiché non esiste concorrenza, gli utenti ottengono solo esecuzioni ma non miglioramenti dei prezzi. Esempi di tali aste sono le aste Robinhood e DFlow.
strato di insediamento
Una volta che un portafoglio firma una serie di transazioni, queste devono essere eseguite sulla blockchain. Le transazioni cross-chain trasformano il processo di regolamento da un'operazione atomica a un'operazione asincrona. Durante l'esecuzione e la conferma della transazione iniziale, lo stato sulla catena di destinazione potrebbe cambiare, causando potenzialmente il fallimento della transazione. Questa sottosezione esplora i compromessi tra costo della sicurezza, tempo di conferma e garanzie di esecuzione.
È importante notare che l’esecuzione della transazione prevista sulla catena target dipende dal meccanismo di inclusione delle transazioni della catena target, inclusa la capacità di rivedere le transazioni e il meccanismo di commissione della catena target, tra gli altri fattori. Riteniamo che la scelta della catena target sia una decisione della dApp e vada oltre lo scopo di questo articolo.
Oracolo a catena incrociata
Due blockchain con stati e meccanismi di consenso diversi richiedono un intermediario, come un oracolo, per facilitare il trasferimento di informazioni tra di loro. L'oracolo funge da relè per il trasferimento di informazioni tra catene, inclusa la verifica che un utente abbia bloccato i fondi in un conto di deposito a garanzia in un ponte di blocco e conio, o la conferma del saldo dei token di un utente sulla catena originale per partecipare ai voti di governance sulla catena. catena di obiettivi.
L'oracolo trasmette le informazioni alla velocità della catena più lenta. Questo per gestire il rischio di riorganizzazione, perché l'oracolo deve attendere il consenso della catena originaria. Supponiamo che un utente desideri collegare USDC dalla catena originale a quella di destinazione e, a questo scopo, l'utente blocca i propri fondi in un deposito a garanzia. Tuttavia, possono sorgere problemi se l'oracolo non attende sufficienti conferme e continua a coniare token per l'utente sulla catena di destinazione. Se si verifica una riorganizzazione e gli utenti sovrascrivono le loro transazioni di deposito a garanzia, l'oracolo causerà una doppia spesa.
Esistono due tipi di oracoli:
Oracoli fuori protocollo: devono essere separati dai validatori di terze parti che eseguono il consenso per passare le informazioni tra le catene. Ulteriori validatori aumentano il costo di gestione di un oracolo. LayerZero, Wormhole, ChainLink e Axelar Networks sono esempi di oracoli fuori protocollo.
Oracoli nel protocollo: profondamente integrati nell'algoritmo di consenso dell'ecosistema e comunicano informazioni utilizzando l'insieme di validatori che gestiscono il consenso. L'IBC di Cosmos viene utilizzato per le catene che eseguono Cosmos SDK, l'ecosistema Polygon sta sviluppando AggLayer e Optimism sta sviluppando Superchain. Ogni oracolo utilizza uno spazio di blocco dedicato per trasferire informazioni tra catene nello stesso ecosistema.
I sequenziatori condivisi sono entità esterne al protocollo che dispongono dei diritti di ordinamento delle transazioni all'interno del protocollo, ovvero possono raggruppare le transazioni attraverso catene. Sebbene sia ancora in fase di sviluppo, il sequenziatore condiviso non deve attendere conferme specifiche dei blocchi per ridurre il rischio di riorganizzazioni. Per ottenere veramente l'atomicità tra catene, il sequenziatore condiviso deve essere in grado di eseguire transazioni successive se le transazioni precedenti hanno successo, trasformandole così in catene.
gettone ponte
In un mondo multicatena, i saldi dei token e delle commissioni di un utente sono dispersi su tutte le reti. Prima di ogni operazione cross-chain, gli utenti devono trasferire i fondi dalla catena originale a quella target. Attualmente ci sono 34 cross-chain bridge attivi con un TVL totale di 7,7 miliardi di dollari e un volume di bridge negli ultimi 30 giorni pari a 8,6 miliardi di dollari.
I token ponte sono un caso di trasferimento di valore. Ciò crea opportunità per sfruttare terze parti professionali che sono brave nella gestione del capitale e disposte a sopportare i rischi di ristrutturazione, riducendo i costi e i tempi necessari agli utenti per effettuare operazioni.
Esistono due tipi di ponti a catena incrociata:
Lock and Mint Bridge: il Lock and Mint Bridge verifica i depositi di token sulla catena originale e conia i token sulla catena target. Il capitale richiesto per avviare un ponte di questo tipo è ridotto, ma il trasferimento sicuro di informazioni protette richiede investimenti significativi. Le violazioni della sicurezza su questi ponti hanno comportato perdite per miliardi di dollari per i possessori di token.
Liquidity Bridge: Liquidity Bridge utilizza i pool di liquidità sulla catena originale e sulla catena target e utilizza algoritmi per determinare il tasso di conversione tra la catena originale e il token target. Sebbene questi ponti abbiano un costo iniziale più elevato, richiedono minori garanzie di sicurezza. Se si verifica una violazione della sicurezza, solo i fondi nel pool di liquidità sono a rischio.
In entrambi i ponti a catena incrociata, gli utenti devono pagare i costi di liquidità. In un ponte di bloccaggio e conio, il costo della liquidità viene sostenuto quando si scambia dal token avvolgente al token desiderato (da USDC.e a USDC) sulla catena target, mentre in un ponte di liquidità, il costo della liquidità viene sostenuto quando si scambia dall'originale token in USDC Si verifica quando i token sulla catena vengono scambiati con token sulla catena di destinazione.
Trilemma della catena incrociata
Le cinque decisioni progettuali sopra menzionate sollevano il trilemma della catena incrociata. Il CAF deve scegliere due attributi tra garanzia di esecuzione, commissioni basse e velocità di esecuzione.
Percorso intra-protocollo: è il percorso designato per la trasmissione delle informazioni a catena incrociata. Questi sistemi tengono conto del rischio di riorganizzazione, sacrificando la velocità di esecuzione ma riducendo i costi eliminando set di validatori aggiuntivi o costi di liquidità.
Aggregazione dei risolutori: raccogli preventivi da più risolutori per identificare il percorso più economico e veloce per eseguire l'intento dell'utente. Tuttavia, a causa della selezione avversa e del front-running, a volte il risolutore potrebbe non riuscire a raggiungere l'intento, con conseguente riduzione dell'esecuzione.
Competizione di esecuzione: seleziona il risolutore vincente organizzando i risolutori in gare di intenti di esecuzione o selezionando un singolo risolutore. Entrambi gli approcci comportano commissioni elevate per gli utenti poiché i risolutori competono per l’esecuzione piuttosto che per il miglioramento dei prezzi.
I sei componenti della TORTA
Per questo articolo, abbiamo studiato oltre 20 progetti di team che lavorano direttamente e indirettamente sull'astrazione della catena. In questa sezione, discuteremo di sei implementazioni CA indipendenti che riteniamo abbiano efficienza intrinseca e idoneità al mercato del prodotto. Se costruiti correttamente, questi progetti hanno il potenziale per combinarsi tra loro.
Una conclusione chiave è che abbiamo bisogno di uno standard unificato per l’espressione di intenti cross-chain. Ogni team sta lavorando sui propri metodi e protocolli per codificare l'intento dell'utente. Uno standard unificato migliorerà la comprensione da parte degli utenti dei messaggi firmati, renderà più semplice per i risolutori e gli oracoli comprendere queste intenzioni e semplificherà l'integrazione con i portafogli.
Ponte designato come token
Esiste un caso speciale di ponti lock-and-mint che non pagano costi di liquidità, noti anche come ponti burn-and-mint (ad esempio USDC CCTP). Il token team assegna un indirizzo canonico del token su ciascuna catena e il bridge ha l'autorità di coniare i token di cui l'utente ha bisogno.
Se guardi da vicino, vedrai che il ponte burn and mint è simile a un trasferimento a catena incrociata con una velocità di conferma del blocco sufficiente. xERC 20 è uno standard per specificare i token canonici e i relativi bridge delegati su una catena di destinazione. I bridge specificati da token sono un esempio di percorso intra-protocollo che sacrifica la velocità per un'esecuzione garantita e commissioni basse, ad esempio CCTP impiega 20 minuti per completare un trasferimento.
Ponte di coordinamento dell’ecosistema
Il ponte di coordinamento dell'ecosistema può trasmettere messaggi arbitrari tra catene all'interno dello stesso ecosistema. Tali bridge sono percorsi intra-protocollo che privilegiano le garanzie di esecuzione e le commissioni basse rispetto alla velocità. Gli esempi includono Cosmos IBC, Polygon AggLayer e Optimism Superchain.
Tre anni fa, l’ecosistema Cosmos ha dovuto affrontare sfide simili a quelle affrontate oggi da Ethereum. La liquidità è dispersa in varie catene, ogni catena ha il proprio gettone di commissione e la gestione dei conti multicatena è molto macchinosa. L'ecosistema Cosmos risolve questi problemi implementando un bridge di messaggistica intraprotocollo IBC, consentendo una gestione degli account multicatena senza soluzione di continuità e trasferimenti incrociati.
L'ecosistema Cosmos è costituito da catene indipendenti con sicurezza sovrana e finalità rapida, rendendo la messaggistica incrociata all'interno del protocollo molto veloce. L'ecosistema di rollup si basa sulla fine del periodo di sfida (rollup ottimistici) o sulla presentazione di prove zk (rollup di validità) per raggiungere la finalità. A causa di queste restrizioni sulla finalità, la consegna dei messaggi nell’ecosistema sarà più lenta.
Concorrenza sui prezzi dei risolutori
La concorrenza sui prezzi dei risolutori implica la condivisione delle informazioni sugli ordini con tutti i risolutori. Il risolutore è progettato per combinare il valore atteso (EV) generato dall'intento dell'ordine e fornirlo all'utente. La selezione del Risolutore vincente nel sistema si basa sulla massimizzazione del miglioramento del prezzo per l'utente. Tuttavia, questa progettazione comporta il rischio di mancata esecuzione e richiede meccanismi aggiuntivi per garantire l’affidabilità degli ordini. Esempi di tali meccanismi includono Uniswap X, Bungee e Jumper.
Messaggi di riconciliazione del portafoglio
I messaggi di coordinamento del portafoglio sfruttano le funzionalità fornite da AA o portafogli basati su policy per fornire un'esperienza cross-chain compatibile con qualsiasi tipo di intento. Funziona come l'aggregatore di CA definitivo, reindirizzando l'intento dell'utente tra vari progetti di CA per soddisfare intenti specifici. Gli esempi includono Avocado Wallet, Near Account Aggregator e Metamask Portfolio.
È importante notare che negli ultimi dieci anni l’ecosistema crittografico ha imparato che la relazione tra gli utenti e i loro portafogli è molto lenta. Ogni volta che penso di migrare la mia frase mnemonica da Metamask a un altro portafoglio, mi sento estremamente terrorizzato. Questo è anche il motivo per cui EIP-4337 ha ancora un basso tasso di adozione dopo 2,5 anni, anche con il supporto dello stesso Vitalik Buterin. Sebbene le versioni più recenti del protocollo del portafoglio possano offrire agli utenti prezzi migliori (astrazione dell’account) o una maggiore facilità d’uso (portafogli basati su policy), la migrazione degli utenti dai loro portafogli attuali è un compito arduo.
Competizione sulla velocità del risolutore
La competizione sulla velocità del risolutore consente agli utenti di esprimere intenzioni per specifiche trasformazioni cross-chain per ottenere elevate garanzie di esecuzione. Non aiuta gli utenti a ridurre al minimo le commissioni, ma fornisce un canale affidabile per contenere transazioni complesse. Il primo Risolutore che eseguirà un intento in base alle tariffe del block builder o includerà la velocità vincerà quell'intento.
Il progetto mira a raggiungere tassi di inclusione elevati massimizzando l'EV catturato dal Risolutore. Tuttavia, ciò avviene a scapito della centralizzazione, poiché si basa su una complessa gestione del capitale sulla rete principale di Ethereum o sull’esecuzione a bassa latenza su L2.
Asta esclusiva in blocco
Un'asta batch esclusiva prevede un'asta per il diritto esclusivo di eseguire tutto il flusso degli ordini entro una finestra temporale. Poiché gli altri solutori non possono vedere gli ordini, fanno offerte in base alla volatilità del mercato prevista e alla qualità media di esecuzione. Le aste batch esclusive si basano su un prezzo di riserva per garantire buoni prezzi utente e pertanto non possono essere utilizzate per migliorare i prezzi. L'invio dell'intero flusso degli ordini a un singolo offerente elimina la perdita di informazioni e migliora la garanzia dell'esecuzione.
Insomma
Il Chain Abstraction Framework (CAF) promette di fornire agli utenti interazioni cross-chain senza soluzione di continuità. In questo articolo esamineremo i progetti in produzione e sviluppo di diversi team che stanno tentando esplicitamente o implicitamente di risolvere il problema dell'astrazione della catena. Riteniamo che questo sarà l'anno del CAF e prevediamo che nei prossimi 6-12 mesi si verificherà una concorrenza significativa tra diversi progetti e le loro implementazioni.
I trasferimenti di valore cross-chain saranno abilitati tramite bridging delegato da token per commissioni basse ed esecuzione rapida attraverso la velocità del risolutore o competizioni sui prezzi. I trasferimenti di messaggi vengono instradati attraverso bridge di messaggistica che corrispondono all'ecosistema, progettati per ridurre al minimo i costi per gli utenti e massimizzare la velocità attraverso una piattaforma controllata dal portafoglio. Alla fine, queste sei diverse opzioni di progettazione formeranno un cluster perché ciascuna soddisfa esigenze diverse e trae vantaggio dalle efficienze in diverse aree della matrice dei compromessi.
Una conclusione importante che abbiamo ottenuto da questo processo è che abbiamo bisogno di uno standard comune per esprimere le intenzioni trasversali alla catena. Attualmente, più team lavorano in modo indipendente su protocolli per codificare l’intento dell’utente, con conseguente duplicazione degli sforzi. Uno standard unificato aiuterà a migliorare la comprensione da parte degli utenti dei messaggi firmati, faciliterà l’elaborazione degli intenti da parte di risolutori e oracoli e semplificherà l’integrazione con i portafogli.
Collegamento originale
