Recentemente, questo progetto AltVMs Catalyst, che a prima vista sembra avere uno stile UI molto MEME, è stato lanciato sulla mainnet, ma sfogliando la documentazione tecnica ufficiale si scopre che non è semplice; deve collegare soluzioni di liquidità multi-chain tra EVM, SVM, MoveVM e la rete BTC, rientrando nel progetto di trading basato su intenti. Come dovrebbe essere compreso? Riassumo brevemente alcuni punti salienti:
1) I progetti di trading basati su intenti non evidenziano eccessivamente la complessità tecnica del «cross-chain», ma si concentrano maggiormente sull'esecuzione e sul risultato degli ordini di intenti cross-chain. Gli utenti inviano ordini sulla «catena sorgente», il risolutore (Solver) esegue l'ordine in base alla descrizione dell'ordine, e la catena Romote può essere inclusa nello scambio degli ordini purché sia in grado di verificare/provare la validità della transazione.
Pertanto, sebbene questi progetti rientrino nella categoria dell'«astrazione della catena» dal punto di vista delle caratteristiche di aggregazione della liquidità, sarebbe più appropriato definire Catalyst come un sistema di trading automatico AMM cross-chain.
2) CrossCats è il prodotto di ponte cross-chain più recente lanciato da Catalyst, in grado di collegare diversi client omogenei o eterogenei (altVMs), e segue solo una logica «provabile» (Provable); le transazioni di intenti cross-chain più comuni includono:
Le transazioni tra catene EVM, ad esempio da Ethereum a Base, vengono gestite interamente dal sistema contrattuale: l'utente firma l'ordine di transazione —> il risolutore (Solver) richiede l'ordine e fornisce garanzie —> la catena sorgente blocca gli asset autorizzati dall'utente —> il risolutore esegue l'ordine sulla catena obiettivo tramite un contratto oracolo —> dopo l'esecuzione, rilascia e regola gli asset bloccati dell'utente.
Le transazioni da catene EVM ad altre catene VM (SVM, MoveVM, ecc.) rientrano anche nella categoria delle transazioni automatizzate basate su smart contract delle catene omogenee; tuttavia, è necessario implementare un meccanismo di verifica provabile su catene non EVM, stabilendo gli oracoli e i contratti di verifica corrispondenti; la logica di firma, blocco, esecuzione e regolazione degli ordini è simile a quella delle transazioni tra catene EVM.
Le transazioni tra Bitcoin e catene VM, ad esempio da Bitcoin a Ethereum o Solana, richiedono una soluzione Pseudo Solver poiché Bitcoin non può gestire smart contract. Gli utenti raccolgono prima gli ordini inversi forniti da veri Solver —> il vero Solver firma l'ordine inverso —> l'utente reclama l'ordine e ottiene asset sulla catena VM —> l'utente avvia attivamente una transazione di trasferimento verso un indirizzo specifico entro un tempo limitato —> completa la verifica dello stato attraverso la validazione SPV leggera di Bitcoin, completando l'intero processo di transazione.
Le transazioni tra catene EVM con lo stesso ambiente di elaborazione della macchina virtuale sono le più semplici; altre catene omogenee che supportano smart contract richiedono un meccanismo specifico di prova cross-chain; le transazioni più complesse riguardano quelle che coinvolgono Bitcoin, necessitando di logiche di verifica client SPV e trattamenti speciali in fase di oracolo, blocco degli asset e così via.
3) Dopo aver realizzato l'esecuzione degli ordini di transazione basati su meccanismi provabili, è necessario considerare l'efficienza dell'uso dei fondi, la condivisione dei meccanismi di gestione, l'ottimizzazione degli Oracle, ecc.
Ad esempio, le regole di blocco e rilascio dei fondi influenzeranno direttamente l'efficienza del capitale; CrossCats consente agli utenti di non dover bloccare preventivamente i fondi di liquidità, bloccando brevemente gli asset solo durante il processo di transazione effettivo (minimizzando il blocco), al fine di non sacrificare l'efficienza dell'uso dei fondi.
Ad esempio, CrossCats ha progettato un piano di rilascio dei pagamenti multi-livello per bilanciare efficienza e rischio. Inoltre, sono stati adottati tre piani di rilascio: pagamento ottimista sulla catena sorgente, verifica sulla catena obiettivo e meccanismo di sottoscrizione.
Il pagamento ottimista presuppone che lo stato della transazione sia eseguito normalmente, liberando prima i fondi e garantendo la sicurezza attraverso la pre-staking di asset e una finestra di contestazione; la verifica della catena obiettivo richiede che la catena Romote fornisca prove alla catena sorgente; il meccanismo di sottoscrizione sposta parte della responsabilità degli ordini su altri partecipanti per migliorare l'efficienza di abbinamento.
Fine.
Come ho detto in un precedente commento sul ribaltamento delle sanzioni di Tornado, con la risoluzione delle soluzioni di privacy on-chain, il trading basato su intenti rappresenterà un potenziale nuovo mercato in rapida crescita.
In questo processo, realizzare la circolazione cross-chain degli asset è solo la base; come ottimizzare le perdite e l'efficienza nelle transazioni cross-chain degli asset, come resistere ai problemi di tempestività delle quotazioni degli Oracle sotto la volatilità del mercato, come arricchire la logica di esecuzione delle transazioni per migliorare l'esperienza automatizzata, sono tutte sfide che il trading basato su intenti deve affrontare.