Articol scris de: Gate Ventures
Introducere
De când Ethereum a trecut la soluții de scalare centrate pe Layer 2, împreună cu apariția instrumentelor precum RaaS, numeroase lanțuri publice au evoluat rapid. Multe entități doresc să construiască propriile lanțuri pentru a reprezenta diferite cerințe de interes și pentru a căuta evaluări mai mari. Cu toate acestea, apariția multor lanțuri publice a făcut ca dezvoltarea ecosistemului să nu țină pasul cu ritmul lanțurilor publice, provocând multe proiecte să eșueze în momentul TGE.
Folosind OP Stack, Coinbase a lansat propriul său Layer 2, Kraken a lansat Ink; folosind tehnologia ZK, OKX a lansat XLayer; Sony a lansat Soneium, LINE a lansat Kaia etc. În prezent, costurile și pragurile tehnologice pentru construirea unui lanț s-au redus semnificativ, operarea unui lanț bazat pe OP Stack costând aproximativ 10.000 de dolari pe lună.
Viitorul va fi cu siguranță o eră de coexistență multi-chain. Deși aceste lanțuri Layer 2 pot alege compatibilitatea EVM pentru a realiza interoperabilitate, datorită entităților Web2 din spatele lor, care au o mulțime de aplicații downstream, este dificil pentru ele să construiască aplicații și să ajungă la un consens pe aceeași lanț.
Analiza TVL, sursa: Defillama
Ecologia multi-chain actuală a adus o nouă provocare: dispersarea lichidității și stării. Datorită inevitabilității existenței multi-chain, interoperabilitatea devine un domeniu ce trebuie explorat și rezolvat. Există multe soluții de lichiditate, cum ar fi abstractizarea lanțului (Particle Network, Socket, XION, INFINIT, Borsa), intenția (Anoma, Khalani), Clearing Execution (Connext), Native CrossChain (Cross), ZKSharding (=nil; Foundation), dar esența lor de bază este aceeași.
Stiva de abstractizare a lanțului, sursa: Frontier Research
Folosim arhitectura Cake, recunoscută în industrie, pentru a prezenta de sus în jos componentele esențiale ale abstractizării cross-chain:
Nivelul aplicației (Application Layer)
Aceasta este stratul direct de interacțiune al utilizatorului, fiind și cel mai abstract strat din soluțiile de lichiditate, deoarece ascunde complet detaliile conversiei lichidității. În stratul aplicației, utilizatorul interacționează cu interfața front-end, fără a înțelege neapărat mecanismele de conversie a lichidității de bază.
Stratul de permisiune (Permission Layer)
Situat sub nivelul aplicației, utilizatorii se conectează la portofelul lor pentru a dApp și solicită o ofertă pentru a-și satisface intenția de tranzacție. Aici, „intenția” se referă la rezultatul final așteptat al tranzacției (adică output), nu la calea specifică de execuție a tranzacției.
Gestionarea conturilor și stratul de abstractizare (Key Management and Account Abstraction)
Datorită existenței unui mediu multi-chain, este nevoie de un sistem de gestionare a conturilor și abstractizare care să se adapteze structurilor unice de conturi ale fiecărui lanț. De exemplu, sistemul de conturi centrat pe obiecte al SUI este complet diferit de EVM. One Balance este un proiect reprezentativ în acest domeniu, care a construit un sistem de conturi de încredere, fără a necesita un consens inter-chain, ci doar angajamente de încredere între sistemele de conturi existente. Near Account realizează gestionarea abstractizată generând portofele de conturi multi-chain pentru utilizatori, optimizând semnificativ experiența utilizatorului și reducând fragmentarea UX. Totuși, în ceea ce privește lichiditatea, s-au integrat în principal lanțurile publice existente.
Stratul de soluționare (Solver Layer)
Acest strat este responsabil pentru a primi și a realiza intențiile de tranzacție ale utilizatorilor, rolul Solver concurând aici pentru a oferi o experiență mai bună utilizatorilor, incluzând timpi de tranzacție și viteze de execuție mai rapide. Pe această bază, proiecte bazate pe intenție, cum ar fi Anoma, au construit diverse soluții bazate pe intenție. Derivatele unor astfel de intenții, cum ar fi componentele Predicate, pot realiza intențiile utilizatorilor sub reguli specifice.
Stratul de decontare (Settlement Layer)
Aceasta este stratul intermediar utilizat de Solver pentru a realiza intențiile utilizatorilor. Componentele esențiale ale soluțiilor pentru dispersarea lichidității și stării includ:
Oracle (Prevederi): utilizat pentru a obține informații de stare de pe alte lanțuri.
Poduri cross-chain (Bridges): responsabile pentru transmiterea informațiilor și lichidității între lanțuri.
Soluții de pre-confirmare (Pre-Confirmation): reducerea timpului de confirmare cross-chain.
Disponibilitatea datelor (DA): oferirea accesibilității datelor.
În plus, trebuie să se ia în considerare lichiditatea inter-chain, finalitatea (Finality), mecanismele de dovadă Layer 2 etc., pentru a asigura funcționarea eficientă a întregului sistem multi-chain.
Soluții
În prezent, pe piață există mai multe soluții pentru fragmentarea lichidității, după ce am analizat o mulțime de soluții, am descoperit că principalele metode sunt:
1. Centrat pe RaaS: Similar soluției Rollup OP Stack, prin adăugarea de ordonatori partajați specifici și poduri cross-chain pentru a asista în construirea de Rollup-uri pe OP Stack, partajând lichiditatea și starea. Aceasta speră să abordeze dispersarea lichidității și stării la un nivel mai înalt. Un aspect mai detaliat este proiectarea separată a ordonatorilor partajați, această soluție fiind mai mult pentru Layer2, fără aplicabilitate generală, cum ar fi Astria, Espresso și Flashbots.
Abstractizarea lanțului, sursa: NEAR
2. Centrat pe conturi: similar cu NEAR, construiește un portofel de conturi pe întreaga lanț, sprijinit de o tehnologie numită „semnătură pe lanț” pentru a semna și executa tranzacții între diferite protocoale blockchain. Componenta esențială este rețeaua MPC, care semnează tranzacțiile multi-chain în numele utilizatorului. Această soluție, deși poate rezolva semnificativ problemele de fragmentare a UX, implică realizări backend complexe pentru dezvoltatori și nu rezolvă în mod esențial dispersarea lichidității și stării.
3. Centrat pe rețeaua de intenții off-chain: aceasta este rețeaua Solver din diagrama de arhitectură a tortului „Introducere”, iar esența este ca utilizatorul să trimită intenții rețelei Solver, iar acest rol de Solver concurează pentru a oferi cel mai bun timp de finalizare și preț de tranzacționare; acești Solver pot fi agenți AI, CEX, Market Maker sau chiar protocoale integrate, cum ar fi Liquorice etc. Proiectele din acest domeniu includ Anoma, Khalani, Enso, aori și Valantis. Deși intenția poate, în teorie, să realizeze operațiuni cross-chain de complexitate oricât de mare, în practică este nevoie de suficientă lichiditate de la Solver pentru a asista, iar când apar cerințe off-chain, există posibilitatea de fraudă din partea Solver. Dacă se introduc dovezi de fraudă și alte măsuri, dificultatea implementării rețelei Solver va crește, iar pragul de operare al Solver-ului va fi și mai ridicat.
4. Centrat pe rețeaua de lichiditate on-chain: această direcție se concentrează în special pe optimizarea problemelor de lichiditate cross-chain, dar nu a rezolvat problemele dispersării stării pe alte lanțuri. Esența este construirea unui strat de lichiditate, pe care se construiesc aplicații pentru a partaja lichiditatea pe întreaga lanț. Unele proiecte includ: Raye Network, INFINIT, Everclear, Elixir etc.
5. Centrat pe aplicațiile on-chain: aceste aplicații construiesc aplicații cu lichiditate ridicată prin integrarea MM mari sau aplicații terțe, cum ar fi Liquorice, Socket, Radiant Capital, 1inch, Hedgemony etc. Aceste proiecte trebuie să gestioneze procese complexe cross-chain, impunând cerințe foarte mari dezvoltatorilor, făcându-le astfel vulnerabile la atacuri cibernetice.
Rezolvarea problemelor de lichiditate este o problemă foarte importantă; în lumea financiară, lichiditatea reprezintă totul. Dacă se poate construi o platformă integratoare de lichiditate, în special prin integrarea lichidității fragmentate pe întreaga lanț, aceasta va avea un potențial foarte mare, iar noi am studiat multe soluții diferite.
În cele două categorii de mai sus, putem observa că, conform structurii de tip tort, Settlement Layer este cea mai atomică soluție, iar deasupra acestor soluții atomice cum ar fi cross-chain, oracle, solutii Pre-Confirmation, se construiește un nivel mai abstract, adică Solver Layer, Permission Layer și Application Layer. Proiectele enumerate mai sus, care construiesc abstractizări sau soluții de lichiditate în diverse direcții, se conformează acestei ierarhii diferite, putând fi înțelese ca relații de upstream și downstream. Totuși, aceste soluții nu sunt încă soluții atomice, iar întreaga problemă a dispersării lichidității a dus la apariția multor probleme derivate complexe, iar în ceea ce privește interoperabilitatea, au apărut o multitudine de soluții. Dar, în esență, acestea trebuie să depindă de aceste componente. În continuare, vom discuta câteva proiecte tipice ale conceptului de abstractizare a lanțului, pentru a vedea cum fiecare abordează problema dispersării lichidității din perspectiva proprie.
INFINIT
Structura INFINIT, sursa: Infinit
INFINIT a construit un serviciu RaaS pentru DeFi, care poate oferi componentele necesare pentru construcția directă a protocolului DeFi, cum ar fi Oracle, Tip Pool, IRM, Active etc., și poate oferi componente precum Trading cu Leverage și Strategii de Yield care pot fi activate imediat. Este echivalent cu alte aplicații de construcție, dar lichiditatea finală este plasată în stratul de lichiditate al Infinit. Cu toate acestea, în prezent, modul de funcționare de bază nu a fost dezvăluit. INFINIT a obținut deja o finanțare de 6 milioane de dolari în runda de seed de la Robot Ventures, Electric Capital și Maelstrom Capital.
Khalani Network
Structura Khalani Network, sursa: Khalani Network
Khalani a construit trei componente esențiale: stratul de compatibilitate Intent, Validity și stratul de decontare universal.
Aplicațiile externe sau stratul de intenție pot publica intenții către Khalani, iar stratul de compatibilitate Intent al Khalani poate transforma intențiile externe într-un format pe care protocolul Solver îl poate recunoaște, folosind un format standardizat cunoscut sub numele de validitate. Nodurile Khalani sunt responsabile pentru a trimite rezultatul final către stratul de decontare universal prin poduri cross-chain și tehnici de decontare rapidă. Acest proiect se află încă în stadiul de construcție și nu a dezvăluit mai multe detalii despre muncă. În august, a obținut 2,2 milioane de dolari în runda de seed de la Ethereal Ventures, Nascent, Maelstrom Capital etc.
Liquorice
Structura Liquorice, sursa: Liquorice
Liquorice este o aplicație descentralizată, care permite descoperirea prețurilor bazate pe licitații și piscine de lichiditate unilaterale. Misiunea principală a Liquorice este de a oferi companiilor de tranzacționare profesionale instrumente eficiente de gestionare a stocurilor și de a se conecta ușor la protocoale DeFi esențiale precum 1inch și Uniswap X atunci când se finalizează tranzacții bazate pe intenții, în același timp, Liquorice a creat o piață de împrumuturi pentru tranzacții de împrumut. Această aplicație se concentrează mai mult pe tranzacție în sine. Este încă în faza de dezvoltare, anunțând în iulie că a obținut 1,2 milioane de dolari în finanțare Pre-seed de la GreenField.
Xion
Xion a fost modernizat din marca Burnt, care anterior se concentra pe aplicații pentru consumatori. Ulterior, echipa a descoperit că există o mare fragmentare în interacțiunile on-chain, motiv pentru care a construit Xion pentru a îmbunătăți această problemă. Xion este construit pe protocolul de consens Comet BFT. Comunicația cross-chain utilizată se bazează pe Cosmos IBC, fiind astfel mai nativ și mai sigur decât alte poduri cross-chain. A avut patru runde de finanțare, investitorii fiind Animoca, Multicoin, Alliance DAO, Mechanism etc.
=nil; Foundation
nil este piața de putere ZK a Ethereum, co-procesor ZK și dezvoltator de Layer2, echipa având o bază solidă în tehnologia ZK. A propus soluția zkSharding, care utilizează tehnologia ZK pentru a extinde orizontal rețeaua principală Ethereum, executând procesarea paralelă a tranzacțiilor și generând ZKP, în timp ce fragmentul principal verifică datele, comunică cu Ethereum și sincronizează starea rețelei între toți validatorii. Fragmentul principal gestionează, de asemenea, distribuția validatorilor și conturilor în fragmentele de execuție. Protocolul de consens folosit de comitetele de validare este, de asemenea, Hotstuff, care este foarte comun în cele mai recente proiecte de execuție paralelă. =nil; L2 a integrat de la început comunicarea cross-shard în protocol. Mesajele cross-shard sunt verificate ca tranzacții de comitetele de validare ale fiecărui fragment.
Ideea de bază este de a construi o arhitectură Layer2 fragmentată similară cu IBC, care să rezolve problemele de comunicare cross-shard integrate, astfel încât să rezolve problemele de dispersare a lichidității și stării. Cu toate acestea, ideea sa de bază nu este rațională, deoarece problema dispersării lichidității se referă la problemele multi-chain, iar ceea ce se construiește este un singur Layer2, adică pentru a rezolva, toate lanțurile trebuie să devină un fragment al ZK-sharding, ceea ce este greu de realizat.
ERC-7683
ERC-7683, sursa: Across
Ethereum se ocupă de asemenea cu rezolvarea acestei probleme de lichiditate cross-chain, iar în prezent Arbitrum, OP, Uniswap sunt primele care susțin public standardul ERC7683, folosind o metodă cross-chain bazată pe intenție. Obiectivul său principal este de a stabili un standard universal pentru operațiunile cross-chain între L2 și sidechains, standardizând comenzile și interfețele de decontare, realizând execuția cross-chain fără probleme, iar componenta principală este un Filler care poate fi considerat un rol de Solver în abstractizarea lanțului, care plătește pentru utilizator. Această propunere a fost construită de Uniswap și Across, și este în prezent revizuită de grupul de lucru Cake.
OP Stack
OP Stack, ERC-7683 și zkSharding sunt toate soluții interne Ethereum pentru fragmentarea lichidității între Layer2, abordând problemele la nivel de arhitectură, consens și aplicație. OP Stack, prin proiectarea unei soluții complete multi-Layer2, rezolvă simultan problemele de transmitere a informațiilor și descentralizarea Sequencer-ului. Atunci când utilizați arhitectura OP Stack, se vor desfășura automat contracte cross-chain, existând de asemenea un Supervisor care contestă pentru a evita transmiterea informațiilor false cross-chain. În prezent, Coinbase, Uniswap, Kraken etc. utilizează arhitectura OP Stack.
Dintre acestea, un exemplu tipic este Unichain. Unichain rezolvă problema fragmentării lichidității cross-chain prin integrarea cu rețeaua Superchain. Această configurație facilitează mișcarea lichidității fără probleme prin oferirea următoarelor funcționalități:
Poduri cross-chain bazate pe intenție: acest pod suportă transferuri rapide și fiabile de lichiditate între blockchain-uri, permițând utilizatorilor să stabilească intenții, ajutând astfel sistemul să aleagă automat cea mai bună cale pentru mișcarea lichidității. Această abordare abstrează complexitatea pentru utilizatori, făcând tranzacțiile cross-chain mai fluide și mai rapide.
Rețeaua de validare Unichain (UVN): această rețea descentralizată de operare a nodurilor validează tranzacțiile cross-chain, oferind o finalitate economică mai rapidă. O finalitate mai rapidă este esențială pentru a asigura decontarea eficientă a tranzacțiilor cross-chain, minimizând riscurile de fragmentare a lichidității cauzate de întârzierile de decontare.
Flashblocks și construirea blocurilor verificabile: prin utilizarea Flashblocks, Unichain a redus semnificativ timpul de blocare, sporind eficiența furnizorilor de lichiditate și realizând piețe cross-chain mai sincronizate. Flashblocks ajută la asigurarea că lichiditatea este disponibilă în orice moment, reducând efectele negative cauzate de întârzierile în confirmarea blocurilor, care pot duce la fragmentarea lichidității.
Sumar
Rezolvarea problemei lichidității cross-chain este un domeniu foarte complex și cu multe soluții, de exemplu, soluțiile Layer2 sunt împărțite în cele care rezolvă problemele de comunicare cross-chain integrate în Ethereum, în special ERC-7683, și Layer2 cum ar fi OP care construiește OP Stack pentru a partaja Sequencer pentru a rezolva. În afara contextului Layer2, toate Layer1 se confruntă și cu probleme de dispersare a lichidității, stării și experienței utilizatorului, existând soluții centrate pe aplicații dedicate lichidității, soluții de tip Solver Network off-chain, și chiar soluții centrate pe conturi, cum ar fi NEAR, dar acestea trebuie să se bazeze pe rolul off-chain al Solver.
Considerăm că fragmentarea lichidității cross-chain, stării și experienței utilizatorului reprezintă o problemă a întregii industrii blockchain, iar dacă ne gândim la ansamblu, este necesar să abordăm problema într-un mod mai abstract, similar cu abstractizarea lanțului. Acesta este, de fapt, adevăratul punct de intrare în Web3, rezolvând fragmentarea experienței utilizatorului, în timp ce integrarea lichidității și stării se realizează în locuri pe care utilizatorul nu le poate percepe. Cum se realizează integrarea este împărțită în utilizarea rețelelor Solver off-chain și a podurilor cross-chain atomice etc., toate acestea fiind demne de discutat. În general, viitorul va fi cu siguranță multi-chain, iar rezolvarea problemei dispersării lichidității este o problemă inevitabilă pe care industria trebuie să o confrunte, iar integrarea lichidității pe întreaga lanț are un potențial vast de creștere, având posibilitatea de a construi Google din era Web3.
