Articol preluat din: Gate Ventures
Introducere
De când Ethereum a trecut la soluții de scalare bazate pe Layer 2 și cu apariția uneltelor precum RaaS, multe lanțuri publice s-au dezvoltat rapid. Multe entități doresc să construiască propriile lanțuri pentru a reprezenta diferite cerințe de interes și a căuta evaluări mai mari. Totuși, apariția a numeroase lanțuri publice face ca dezvoltarea ecosistemului să nu poată ține pasul cu ritmul acestora, ceea ce duce la prăbușirea multor proiecte în timpul TGE.
Cu ajutorul OP Stack, Coinbase a lansat propriul său Layer 2, Kraken a lansat Ink; cu ajutorul tehnologiei ZK, OKX a lansat XLayer; Sony a lansat Soneium, LINE a lansat Kaia etc. În prezent, costul și pragul tehnic pentru construirea unui lanț au fost semnificativ reduse, costul operării unui lanț bazat pe OP Stack fiind de aproximativ 10.000 de dolari pe lună.
Viitorul va fi cu siguranță o eră de coexistență multi-lanț. Deși aceste lanțuri Layer 2 ar putea alege compatibilitatea EVM pentru a realiza interoperabilitatea, datorită entităților Web2 care au numeroase aplicații downstream, este dificil pentru ele să construiască aplicații și să ajungă la un consens pe aceeași lanț.
Descompunerea TVL, sursă: Defillama
Ecologia multi-lanț actuală aduce o nouă provocare: dispersia lichidității și a stării. Deoarece coexistența multi-lanț este inevitabilă, interoperabilitatea devine un domeniu care trebuie explorat și rezolvat. Există multe soluții de lichiditate, cum ar fi abstractizarea lanțului (Particle Network, Socket, XION, INFINIT, Borsa), intenții (Anoma, Khalani), execuție de decontare (Connext), CrossNative (Cross), ZKSharding (=nil; Foundation), dar esența lor centrală este aceeași.
Stiva de Abstracție a Lanțului, Sursa: FrontierResearch
Folosim arhitectura Cake, recunoscută în industrie, pentru a descrie structura componentelor esențiale ale abstractizării între lanțuri de sus în jos:
Stratul aplicației (Application Layer)
Aceasta este stratul cu care utilizatorul interacționează direct și este cel mai abstract strat dintre soluțiile de lichiditate, deoarece ascunde complet detaliile conversiei lichidității. În stratul aplicației, utilizatorul interacționează cu interfața de front-end, fără a înțelege neapărat mecanismele de conversie a lichidității de bază.
Stratul de permisiuni (Permission Layer)
Situat sub stratul aplicației, utilizatorul se conectează la dApp prin portofel și solicită oferte pentru a îndeplini intenția tranzacției. Aici, „intenția” se referă la rezultatul final dorit al utilizatorului (adică ieșirea), nu la calea specifică de executare a tranzacției.
Stratul de gestionare a conturilor și abstractizare (Key Management and Account Abstraction)
Datorită existenței unui mediu multi-lanț, este necesar un sistem de gestionare a conturilor și abstractizare adaptat diferitelor lanțuri pentru a menține structurile unice ale conturilor. 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 construiește un sistem de conturi de încredere, fără a necesita consens între lanțuri, ci doar angajamente de încredere între sistemele existente de conturi. Near Account realizează gestionarea abstractizată prin generarea de portofele multi-lanț pentru utilizatori, optimizând semnificativ experiența utilizatorului și reducând fragmentarea UX. Cu toate acestea, în ceea ce privește lichiditatea, se integrează în principal cu lanțurile publice existente.
Stratul Solver (Solver Layer)
Acest strat este responsabil pentru primirea și realizarea intențiilor de tranzacție ale utilizatorului. Rolul Solver-ului concurează aici pentru a oferi o experiență mai bună utilizatorului, inclusiv timpi mai rapizi de tranzacționare și viteză de execuție. Pe baza acestui principiu, proiectele bazate pe intenții, cum ar fi Anoma, au construit diverse soluții bazate pe intenții. Derivatele acestor intenții, cum ar fi componentele Predicate, pot realiza intențiile utilizatorilor în conformitate cu reguli specifice.
Stratul de decontare (Settlement Layer)
Acesta este stratul intermediar utilizat de stratul Solver pentru a realiza intențiile utilizatorului. Componentele esențiale ale soluțiilor pentru dispersarea lichidității și stării includ:
Oracol (Oracle): folosit pentru a obține informații de stare de pe alte lanțuri.
Poduri între lanțuri (Bridges): Responsabile pentru transmiterea informațiilor și lichidității între lanțuri.
Plan de confirmare anticipată (Pre-Confirmation): Reduce timpul de confirmare între lanțuri.
Disponibilitatea datelor (DA): Oferă accesibilitatea datelor.
În plus, trebuie să se ia în considerare lichiditatea între lanțuri, finalitatea (Finality), mecanismele de dovadă Layer 2 etc., pentru a asigura funcționarea eficientă a întregului sistem multi-lanț.
Soluție
În prezent, pe piață există mai multe soluții pentru problema fragmentării lichidității. După ce am analizat numeroase soluții, am constatat că principalele moduri sunt următoarele:
1. Centrat pe RaaS: Similar cu soluțiile Rollup precum OP Stack, prin adăugarea de ordonatori partajați specifici și poduri între lanțuri pentru a asista la construirea lichidității și stării partajate în OP Stack. Acesta speră să abordeze dispersarea lichidității și stării într-o direcție mai înaltă. Un aspect mai specific este designul separat al ordonatorului partajat, această soluție este mai mult orientată spre Layer 2 și nu are universalitate, cum ar fi Astria, Espresso și Flashbots.
Abstracția Lanțului, sursa: NEAR
2. Centrat pe conturi: Similar cu NEAR, construiește un portofel de conturi multi-lanț, printr-o tehnologie numită „semnătura lanțului” care sprijină semnarea și executarea tranzacțiilor pe mai multe protocoale de blockchain. Componenta centrală este rețeaua MPC, care semnează tranzacțiile multi-lanț în locul utilizatorilor. Această soluție, deși poate rezolva semnificativ problema fragmentării UX, implică o implementare complexă în backend și nu rezolvă în esență dispersarea lichidității și a stării.
3. Centrat pe rețeaua de intenții off-chain: Aceasta este rețeaua Solver din diagrama de arhitectură a „introducerii” noastre. Ideea centrală este ca utilizatorii să trimită intenții rețelei Solver, acest rol de Solver concurează pentru oferte, oferind cel mai bun timp de finalizare și preț de tranzacție. Acești Solvatori pot fi agenți AI, CEX, market maker sau chiar protocoale integrate precum Liquorice etc. Proiectele din acest domeniu includ Anoma, Khalani, Enso, aori și Valantis. Deși intențiile pot teoretic realiza operațiuni între lanțuri de orice complexitate, implementarea necesită suficient lichiditate din partea Solver-ilor pentru asistență, iar în cazul unor cerințe off-chain, Solver-ii pot prezenta riscuri de fraudă. Dacă sunt introduse dovezi de fraudă, dificultatea implementării rețelei Solver va crește, iar pragul de operare pentru Solver va fi mai mare.
4. Centrat pe rețeaua de lichiditate on-chain: Această direcție se concentrează pe optimizarea problemelor de lichiditate între lanțuri, dar nu rezolvă problemele de dispersie a altor stări pe lanțuri. Elementul său central este construirea unui strat de lichiditate, pe care se construiesc aplicații pentru a partaja lichiditatea pe întreaga rețea. Unele proiecte includ: Raye Network, INFINIT, Everclear, Elixir etc.
5. Centrat pe aplicații 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 fluxuri complexe între lanțuri, ceea ce impune cerințe ridicate dezvoltatorilor, făcându-le astfel foarte vulnerabile la atacuri cibernetice.
Rezolvarea problemei lichidității este o temă foarte importantă; în lumea financiară, lichiditatea reprezintă adesea totul. Dacă se poate construi o platformă integrată de lichiditate, în special prin integrarea lichidității dispersate pe întreaga rețea, ar avea un potențial enorm, iar noi am examinat multe soluții diferite.
În cele două categorii anterioare, putem vedea că, conform structurii cake, Stratul de Decontare este cea mai atomică soluție. Deasupra acestor soluții atomice, precum poduri între lanțuri, oracole, soluții de Pre-Confirmation etc., este construit un strat mai abstract, care este Stratul Solver, Stratul de Permisiuni și Stratul Aplicației. Diferitele soluții pentru abstractizare sau lichiditate pe care le-am enumerat mai sus se aliniază la acest set de niveluri diferite, putând fi înțelese ca relații de upstream și downstream. Cu toate acestea, aceste soluții nu sunt soluții atomice. Problema fragmentării întregii lichidități aduce la suprafață multe probleme derivate complexe. Astfel, în contextul interoperabilității, au apărut o varietate de soluții. Totuși, în esență, totul se bazează pe aceste componente. În continuare, vom discuta despre câteva proiecte tipice din conceptele de abstractizare a lanțului pentru a vedea cum fiecare abordează problema fragmentării lichidității.
INFINIT
Structura INFINIT, sursa: Infinit
INFINIT a construit un serviciu RaaS în domeniul DeFi, care poate oferi componentele necesare pentru construcția directă a protocoalelor DeFi, cum ar fi Oracle, Tip de Piscină, IRM, Asset etc., și poate oferi componente precum Tranzacționare cu Leverage și Strategii de Randament care sunt imediat activate. Acesta este echivalent cu un endpoint de construcție pentru alte aplicații, dar lichiditatea finală este plasată în stratul de lichiditate al Infinit. Cu toate acestea, în prezent, nu a dezvăluit principiile de funcționare de bază. În prezent, INFINIT a obținut 6 milioane de dolari în rundă de finanțare Seed de la Robot Ventures, Electric Capital și Maelstrom Capital.
Rețeaua Khalani
Structura Rețelei Khalani, sursa: KhalaniNetwork
Khalani a construit trei componente centrale: stratul de compatibilitate cu intenția, Validitatea și stratul de decontare general.
Aplicațiile externe sau stratul de intenție pot publica intenții către Khalani, iar stratul de compatibilitate cu intenția al Khalani poate transforma intențiile externe într-un format pe care protocolul Solver îl poate recunoaște, folosind un format normalizat numit limbajul Validity. Nodurile Khalani sunt responsabile pentru a trimite rezultatul final stratului de decontare general prin poduri între lanțuri, tehnici rapide de decontare etc. Acest proiect este încă în faza de construcție și nu a dezvăluit mai multe detalii de lucru. A obținut în luna august o finanțare de 2,2 milioane de dolari din partea Ethereal Ventures, Nascent, Maelstrom Capital etc.
Liquorice
Structura Liquorice, sursa: Liquorice
Liquorice este o aplicație descentralizată care permite descoperirea prețurilor bazată pe licitații și piscine de lichiditate unilaterale. Misiunea principală a Liquorice este de a oferi companiilor de trading profesioniste instrumente eficiente de gestionare a stocurilor și de a se conecta ușor la protocoalele DeFi de bază precum 1inch și Uniswap X atunci când se finalizează tranzacții bazate pe intenții de utilizare. În același timp, Liquorice a creat o piață de împrumut pentru a facilita tranzacțiile de împrumut. Această aplicație se concentrează mai mult pe tranzacții în sine. În prezent, este încă în faza de dezvoltare și a anunțat în luna iulie că a obținut 1,2 milioane de dolari în rundă de finanțare Pre-seed condusă de GreenField.
Xion
Xion este o evoluție a brandului Burnt, care anterior s-a concentrat pe aplicații pentru consumatori. Ulterior, echipa a descoperit o problemă semnificativă de fragmentare în interacțiunile de pe lanț, motiv pentru care a dezvoltat Xion pentru a îmbunătăți această situație. Xion este construit pe protocolul de consens Comet BFT. Comunicația sa între lanțuri se bazează pe Cosmos IBC, ceea ce îl face mai nativ și mai sigur decât alte poduri între lanțuri. A realizat patru runde de finanțare, investitorii includ Animoca, Multicoin, Alliance DAO, Mechanism etc.
=nil; Foundation
nil este piața de putere ZK a Ethereum, procesorul ZK și dezvoltatorul Layer2, echipa având o expertiză profundă în tehnologia ZK. A propus soluția zkSharding, care este utilizarea tehnologiei ZK pentru a extinde orizontal rețeaua principală Ethereum, executând procese paralele de fragmentare a tranzacțiilor și generând ZKP, în timp ce fragmentul principal validează datele, comunică cu Ethereum și sincronizează starea rețelei între toți validatoarele. Fragmentul principal gestionează, de asemenea, distribuția validatorilor și a conturilor în fragmentul de execuție. Protocolul de consens utilizat de comitetul de validare este de asemenea Hotstuff, care este comun în cele mai recente proiecte de execuție paralelă. =nil; L2 a încorporat comunicarea între fragmente în protocol de la început. Mesajele între fragmente sunt validate de comitetul de validare al fiecărui fragment ca tranzacție.
Ideea de bază este de a construi o arhitectură de comunicare între fragmente similară cu IBC printr-o arhitectură Layer 2 fragmentată, care poate rezolva problemele de lichiditate și de dispersie a stării. Totuși, ideea sa centrală nu este rezonabilă, deoarece problema dispersării lichidității este o problemă multi-lanț, iar ceea ce construiește este un singur Layer 2, ceea ce înseamnă că pentru a rezolva problema trebuie ca toate lanțurile să devină un fragment al ZK-sharding, ceea ce este greu de realizat.
ERC-7683
ERC-7683, sursa: Across
Ethereum este, de asemenea, angajat în rezolvarea problemei lichidității între lanțuri. În prezent, Arbitrum, OP, Uniswap au fost primele care au susținut public standardul ERC7683, folosind de asemenea o metodă bazată pe intenții între lanțuri. Obiectivul său principal este de a stabili standarde generale pentru operațiunile între L2 și lanțurile laterale, standardizând comenzile și interfețele de decontare pentru a realiza execuția fără cusur între lanțuri. Elementul său central este un Filler, care poate fi considerat rolul Solver în abstractizarea lanțului. 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 soluții interne ale Ethereum pentru fragmentarea lichidității între Layer 2, rezolvând problemele la nivel de arhitectură, consens și aplicație. OP Stack proiectează o soluție completă multi Layer 2 pentru a rezolva o dată pentru totdeauna problemele de transmitere a informațiilor și de descentralizare a Sequencer-ului. Atunci când utilizați arhitectura OP Stack, contractele între lanțuri vor fi implementate automat, existând un Supervisor care va contesta evitarea transmiterii de informații false între lanțuri. În prezent, Coinbase, Uniswap, Kraken etc. folosesc arhitectura OP Stack.
Printre acestea, un exemplu tipic este Unichain. Unichain rezolvă problema fragmentării lichidității între lanțuri prin integrarea cu rețeaua Superchain. Această configurație facilitează mișcarea lichidității fără cusur prin furnizarea următoarelor funcționalități:
Podul bazat pe intenții: Acest pod sprijină transferul rapid și fiabil 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 abstractizează complexitatea pentru utilizatori, făcând tranzacțiile între lanțuri mai fluide și rapide.
Rețeaua de validare Unichain (UVN): Această rețea de operare descentralizată a nodurilor validează tranzacțiile între lanțuri, oferind o finalitate economică mai rapidă. O finalitate mai rapidă este esențială pentru a asigura decontările eficiente ale tranzacțiilor între lanțuri, minimizând riscurile de fragmentare a lichidității cauzate de întârzierea decontării.
Flashblocks și construcția de blocuri verificabile: Prin utilizarea Flashblocks, Unichain a redus semnificativ timpul de blocare, îmbunătățind eficiența furnizorilor de lichiditate și realizând piețe între lanțuri mai sincronizate. Flashblocks ajută la asigurarea disponibilității lichidității în orice moment și reduce impactul negativ al întârzierilor de confirmare a blocurilor, care pot duce la fragmentarea lichidității.
Sumar
Rezolvarea problemei lichidității între lanțuri este un domeniu foarte complex și cu multe soluții. De exemplu, soluțiile Layer2 sunt împărțite în soluții care folosesc mesaje între lanțuri încorporate în Ethereum, în special ERC-7683, și Layer2 precum OP, care construiește OP Stack pentru a partaja Sequencer pentru a rezolva această problemă. Fără contextul Layer2, toate Layer1 se confruntă cu probleme de fragmentare a lichidității, stării și experienței utilizatorului. Există soluții special concepute pentru aplicații centrate pe lichiditate, precum și soluții off-chain bazate pe rețeaua Solver, și chiar soluții centrate pe conturi precum NEAR, dar toate necesită roluri off-chain precum Solver.
Considerăm că fragmentarea lichidității, stării și experienței utilizatorului este o problemă a întregii industrii blockchain. Dacă gândim la un nivel global, este necesar să adoptăm o abordare mai abstractă, similară cu abstractizarea lanțului, ceea ce poate fi considerat o intrare reală în Web3, rezolvând fragmentarea experienței utilizatorului, în timp ce integrarea lichidității și a stării se face în moduri pe care utilizatorii nu le percep. Cum se face această integrare este de asemenea împărțită în utilizarea rețelei Solver off-chain și facilități precum podurile între lanțuri de integrare atomică, ceea ce merită să fie discutat. În general, viitorul va fi cu siguranță multi-lanț, iar rezolvarea problemei dispersării lichidității este o problemă inevitabilă pe care o industrie trebuie să o înfrunte. Această integrare a lichidității pe întreaga rețea are un potențial uriaș de creștere și ar putea construi Google-ul epocii Web3.
