O scurtă istorie a Cross-Chain: Explicarea a nouă soluții diferite Cross-Chain

Soluțiile cross-chain au fost subiectul cel mai discutat în ultimul an. Odată cu creșterea infrastructurilor lanțurilor publice, a existat un interes masiv pentru modul în care diferitele lanțuri vorbesc și comunică. Au fost propuse și implementate soluții, dar niciuna dintre ele nu rezolvă problemele fundamentale fără compromisuri drastice. Acum examinăm diferitele abordări cross-chain și divulgăm de ce și cum vor modela viitorul infrastructurii cross-chain.

În primul rând, să discutăm ce este tehnologia cross-chain și de ce este necesară. Motivul utilizării: lanțurile sunt eterogene și necesită dezvoltatorilor un timp semnificativ pentru a urmări diferențele și provocările atunci când transferă activele. Podurile sunt mai puțin sigure și nu pot fi 100% de încredere, deoarece sunt de obicei deținute de echipele de proiect blockchain și sunt extrem de centralizate (dezordonate, fără coordonare din partea fiecărei echipe). Scopul blockchain-ului layer-1 este standardizarea, dar segmentarea lanțurilor layer-1 duce la necesitatea unui strat de infrastructură încrucișat, care se află chiar și sub nivelul 1.

Istoria mecanismelor încrucișate trebuie să fie prezentată și comparată pentru a înțelege soluțiile încrucișate și pentru a compara diferențele și atributele acestora.

Transfer manual

 
Prima soluție cross-chain este un transfer manual de active. Procesul începe prin ca utilizatorul să transfere active la un anumit portofel din lanțul A, iar o entitate centralizată monitorizează portofelul pentru transferuri și le înregistrează în Excel. Apoi, după o perioadă finită de timp (de obicei în scopuri de monitorizare), entitatea creditează active pe lanțul B după verificare. Avantajul acestei abordări este ușurința de implementare, dar este predispusă la erori umane și are o garanție de securitate foarte scăzută. Nu există nici o descentralizare în această abordare.

Transfer semi-automat

Următoarea iterație se îmbunătățește prin faptul că utilizatorul transferă active către un anumit portofel și/sau un contract inteligent pe lanțul A. Apoi, un program centralizat monitorizează adresa pentru transferuri. Un astfel de program trimite automat active pe lanțul B după verificare. Avantajul este încă ușurința de implementare fără prea multă complexitate sau codare, iar înregistrările pot fi păstrate în lanț în loc de local. Dezavantajul este că programul centralizat poate fi defect sau defect. Contul de credit central ar putea rămâne, de asemenea, fără fonduri. Garanția de securitate este, de asemenea, scăzută și nu există descentralizare.

Schimb centralizat

Atunci când soluțiile simple cross-chain nu sunt scalabile, schimburile centralizate prosperă pe nevoile cross-chain. Aceștia funcționează prin ca utilizatorii să transfere active în bursa lor centralizată și apoi, folosind schimbul „intern” al bursei, să transforme „activele X” din lanțul A în „active Y” din lanțul B prin evidența contabilă. Avantajul este evident – ​​este cea mai ușor soluție de utilizat – nu este necesară codificare și există o fiabilitate ridicată pe schimburile de nivel 1. Dar problema expune dezavantajul opus – controlul centralizat al momentului în care depunerea/retragerea este disponibilă. Schimbul centralizat oferă securitate ridicată, cu dezavantajul că este cea mai mică descentralizare.

Podul centralizat

Următorul progres se îmbunătățește prin existența unei infrastructuri separate pentru transferul activelor peste lanțuri – o punte. O punte centralizată funcționează prin faptul că utilizatorul transferă active, apoi utilizând caracteristica de transfer a podului, inițiază transferul activelor X pe lanțul A în activele Y pe lanțul B. Un releu centralizat (sau un set de) este responsabil pentru proces:

Blocați activele X pe lanțul A
Verifica
Activele monetare Y pe lanțul B
Avantajul acestei punți este procesul complet automat fără nicio întrerupere manuală. Iar dezavantajul este încă controlul centralizat al momentului în care depunerea/retragerea este disponibilă. De asemenea, puntea poate fi dărâmată sau spartă, făcându-l nefuncțional din când în când. Deci securitatea este medie și încă nu există descentralizare.

Pod descentralizat cu MPC

Următoarea iterație este descentralizarea modelului de verificare în loc de o punte centralizată. O punte MPC (Multi-Party Computation) începe prin a solicita utilizatorilor să transfere active în el. Folosind caracteristica de transfer a podului, acesta inițiază transferul activelor X pe lanțul A în activele Y pe lanțul B. De obicei, există un set descentralizat de relee care este responsabil pentru proces:

Blocați activele X pe lanțul A folosind MPC
Verificați folosind MPC
Mint active Y pe lanțul B folosind MPC
Avantajul MPC este procesul complet automat, fără nicio întrerupere manuală, iar nodurile releu nu trebuie să fie centralizate. Dezavantajul este costul ridicat de calcul și de comunicare al MPC. De asemenea, nodurile pot fi compromise sau consimțite. Securitatea este medie, în timp ce descentralizarea este, de asemenea, medie.

Atomic Swap Bridge cu HTLC

O altă clasă de punți apare în funcție de tehnologia de schimb atomic (Lightning Network). Funcționează prin: utilizatorul transferă active într-o punte de swap atomică și apoi, folosind caracteristica de transfer a podului, inițiază transferul activelor X pe lanțul A în activele Y pe lanțul B:

Creați un nou HTLC – Hash Lock Timed Contract
Depuneți activele X în contract pe lanțul A
Generați cheia de blocare hash + criptați un secret pentru retragerea finală în timpul T pe lanțul B
Prezentați secretul criptat pentru a contracta pe lanțul B pentru a retrage activele Y
SAU timpul T a trecut și recuperați activele X din contractul pe lanțul A cu secretul criptat
Avantajul semnificativ este că nu există un nod/proces centralizat care să controleze transferul de punte. Iar dezavantajul este relativ comun - un cost ridicat al implementării HTLC și al rulării apelurilor HTLC. Datorită lipsei de încredere, menținerea securității ridicate și a pistei de audit este o provocare. Securitatea acestei abordări este mare, iar descentralizarea este, de asemenea, mare, având în vedere dezavantajele de mai sus.

Interoperabilitate încrucișată cu Light Client + Oracle

După abordarea podurilor cu costuri mari, se nasc mai multe implementări pentru a reduce acest cost. Tehnologia clientului ușor a devenit cea mai recentă normă pentru simplificarea verificărilor încrucișate. Procesul este după cum urmează:

În primul rând, utilizatorul transferă activele X într-un contract de protocol de interoperabilitate între lanțuri pe lanțul A
Un mesaj de transfer este setat pe contract și este preluat de nodurile de releu descentralizate
Nodurile trimit dovezi prin contractul protocolului pe lanțul B
Actualizările antetului blocului (client ușor) sunt gestionate de rețeaua Oracle pentru a asigura livrarea și valabilitatea
Utilizatorul retrage activele Y din contractul protocolului pe lanțul B la validare
Avantajul acestei abordări este că nu este nevoie de nici un jeton intermediar sau lanț de la transfer până la finalizare. Confirmarea instantanee este posibilă după actualizarea antetelor blocurilor. Contra sunt 1) riscurile de coluziune de la Oracles, 2) din cauza lipsei de încredere, menținerea securității ridicate, iar pista de audit este provocatoare. Securitatea acestei abordări este medie, în timp ce descentralizarea este ridicată.

Interoperabilitate încrucișată cu lanțul de relee

Pe baza lecțiilor abordării Oracle, este prezentă și o soluție pură de lanț de relee. Procesul este ușor diferit:

Utilizatorul transferă activele X într-un contract de protocol de interoperabilitate între lanțuri pe lanțul A
Un mesaj de transfer este setat pe contract și este preluat de nodurile de releu descentralizate
Nodurile trimit dovezi la contractul lanțului de relee
Validatoarele de bază ale lanțului de relee gestionează actualizările de bloc pentru a asigura livrarea și valabilitatea
După validare, nodurile de retransmisie transmit mesajul de transfer către contractul protocolului de pe lanțul B
Utilizatorul retrage activele Y din contractul protocolului pe lanțul B
Avantajul acestei abordări față de soluția simplă Oracle este tarifele mai ieftine de la lanțurile de relee care consumă majoritatea costurilor. Confirmarea instantanee este posibilă după ce blocurile sunt actualizate, ceea ce este crucial pentru rezolvarea timpilor de întârziere mai mari. Problema este că este posibil ca protocolul în sine să nu suporte un ecosistem cu toate lanțurile. Securitatea este ridicată (în cadrul ecosistemului), iar descentralizarea este, de asemenea, mare.

Strat de infrastructură încrucișat cu Light Client + Relay Chain

Soluția de ultimă generație se concentrează pe stratul de infrastructură cross-chain care rezolvă toate problemele fundamentale de mai sus. Combină tehnologia light client cu un lanț de relee pentru a încorpora toate lanțurile:

Utilizatorul transferă activele X într-un contract de interoperabilitate al unui strat de infrastructură încrucișat pe lanțul A
Un mesaj de transfer este setat pe contract și este preluat de nodurile de releu descentralizate
Nodurile trimit dovezi la contractul de interoperabilitate al lanțului de relee
Actualizările antetului blocului (client ușor) sunt gestionate de noduri de întreținere descentralizate pentru a asigura livrarea și valabilitatea
După validare, nodurile de retransmisie transmit mesajul de transfer către contractul de interoperabilitate din lanțul B
Utilizatorul retrage activele Y din contractul de interoperabilitate pe lanțul B
Această soluție asigură interoperabilitatea cu taxe foarte ieftine datorită implementării unui lanț de relee. De asemenea, oferă o confirmare instantanee după ce anteturile blocurilor sunt actualizate. Cea mai mare provocare este complexitatea ridicată a optimizării clienților ușoare pe lanțul de relee. Efectuând suficiente cercetări și inginerie, aceste optimizări ar trebui să susțină beneficiile pe care ceilalți nu le pot rezolva. Securitatea este foarte mare, iar descentralizarea este mare.

Despre Protocolul MAP

Dintre soluțiile încrucișate, încă nu am văzut una care să rezolve toate problemele de mai sus. Până la implementarea Protocolului MAP. După 3 ani de cercetare și dezvoltare complexă, MAP Protocol a atins în sfârșit stratul Omnichain cu tehnologia light Client + relay chain fără compromisuri. MAP a implementat principiile Omnichain cu următoarele proprietăți:

Dezvoltator gata
Acoperire integrală
Cost minim
Finalitatea de securitate
Confirmare instantanee

Protocolul MAP este nivelul de infrastructură pentru a sprijini construirea de poduri, DEX-uri, protocoale de interoperabilitate și multe altele. Acceptă verificarea directă de către clienții ușoare pe lanțul de relee MAP – pentru a reduce costurile. Și oferă stimulente încorporate în fiecare componentă pentru ca dezvoltatorii dapp să le câștige sau să le prezinte utilizatorilor finali. MAP acceptă lanțuri EVM și non-EVM - stratul de protocol este izomorf cu toate lanțurile.

Pentru viitor, MAP este infrastructura din spatele tuturor lanțurilor care vor fi noul strat de bază. Dezvoltatorii nu mai sunt restricționați de lanțul lor de alegere și se pot concentra pe produsul dapp în sine. Viitorul este Omnichain, iar mai multă modularizare și stimulare sunt calea de urmat.