Kratka istorija unakrsnog lanca: Objašnjavanje devet različitih unakrsnih rješenja

Međulančana rješenja su tema o kojoj se najviše pričalo u protekloj godini. Sa porastom infrastrukture javnih lanaca, pojavio se ogroman interes za to kako različiti lanci razgovaraju i komuniciraju. Rješenja su predložena i implementirana, ali nijedno od njih ne rješava fundamentalne probleme bez drastičnih kompromisa. Sada ispitujemo različite pristupe unakrsnog lanca i otkrivamo zašto i kako će oni oblikovati budućnost međulančane infrastrukture.

Prvo, razgovarajmo o tome šta je cross-chain tehnologija i zašto je potrebna. Razlog za upotrebu: lanci su heterogeni i zahtijevaju programerima značajno vrijeme da prate razlike i izazove prilikom premještanja imovine. Mostovi su manje sigurni i ne može im se 100% vjerovati jer su obično u vlasništvu projektnih timova blockchain i visoko su centralizirani (neuredni bez koordinacije svakog tima). Cilj blockchaina sloja 1 je standardizacija, ali segmentacija lanaca sloja 1 dovodi do potrebe za infrastrukturnim slojem unakrsnog lanca koji je čak i ispod sloja 1.

Istorija unakrsnih mehanizama mora se izložiti i uporediti da bi se razumjela međulančana rješenja i uporedile njihove razlike i atributi.

Ručni transfer

 
Prvo cross-chain rješenje je ručni prijenos sredstava. Proces počinje tako što korisnik prenosi sredstva u određeni novčanik u lancu A, a centralizirani entitet nadzire novčanik za transfere i bilježi ih u Excelu. Zatim nakon ograničenog vremenskog perioda (obično u svrhu praćenja), entitet kreditira sredstva u lanac B nakon verifikacije. Prednost ovog pristupa je jednostavnost implementacije, ali je podložan ljudskim greškama i ima vrlo nisku sigurnosnu garanciju. U ovom pristupu također nema decentralizacije.

Poluautomatski transfer

Sljedeća iteracija se poboljšava tako što korisnik prenosi sredstva u određeni novčanik i/ili pametni ugovor na lancu A. Zatim, centralizirani program nadgleda adresu za transfere. Takav program automatski šalje sredstva u lanac B nakon verifikacije. Dobra strana je i dalje lakoća implementacije bez previše složenosti ili kodiranja, a zapisi se mogu čuvati na lancu umjesto lokalno. Nedostatak je što centralizirani program može biti u grešci ili neispravan. Centralni kreditni račun također može ostati bez sredstava. Sigurnosna garancija je također niska, a nema decentralizacije.

Centralizirana razmjena

Kada jednostavna rješenja unakrsnog lanca nisu skalabilna, centralizirane razmjene napreduju na potrebama unakrsnog lanca. Oni rade tako što korisnici prenose sredstva u svoju centralizovanu berzu, a zatim, koristeći „internu“ razmenu razmene, pretvaraju „imovinu X“ u lancu A u „imovinu Y“ u lancu B putem evidencije. Prednost je očigledna – to je najlakše rješenje za korištenje – nije potrebno kodiranje, a postoji i visoka pouzdanost na tier-1 razmjenama. Ali problem otkriva suprotan nedostatak – centralizovanu kontrolu kada je depozit/povlačenje dostupan. Centralizovana razmena daje visoku sigurnost sa nedostatkom najmanje decentralizacije.

Centralizovani most

Sljedeći napredak se poboljšava tako što ima posebnu infrastrukturu za prijenos sredstava kroz lance – most. Centralizirani most funkcionira tako što korisnik prenosi sredstva, a zatim pomoću funkcije prijenosa mosta inicira prijenos sredstava X na lancu A u sredstva Y na lancu B. Centralizirani (ili skup) prenosilac je odgovoran za proces:

Zaključavanje sredstava X na lancu A
provjeriti
Sredstva kovnice Y na lancu B
Prednost ovog mosta je potpuno automatski proces bez ikakvog ručnog prekida. A nedostatak je još uvijek centralizirana kontrola kada je depozit/povlačenje dostupan. Također, most može biti porušen ili hakovan, što ga s vremena na vrijeme čini nefunkcionalnim. Dakle, sigurnost je srednja, a decentralizacije i dalje nema.

Decentralizovani most sa MPC-om

Sljedeća iteracija je decentralizacija modela verifikacije umjesto centraliziranog mosta. MPC (Multi-Party Computation) most počinje tako što korisnici prenose sredstva u njega. Koristeći funkciju prijenosa mosta, on inicira prijenos sredstava X na lancu A u sredstva Y na lancu B. Obično postoji decentralizirani skup relejera koji je odgovoran za proces:

Zaključajte sredstva X na lancu A koristeći MPC
Provjerite pomoću MPC-a
Kovnica sredstava Y na lancu B koristeći MPC
Prednost MPC-a je potpuno automatski proces bez ikakvog ručnog prekida, a relejni čvorovi ne moraju biti centralizirani. Loša strana su visoki računarski i komunikacioni troškovi MPC-a. Takođe, čvorovi mogu biti kompromitovani ili dogovarani. Sigurnost je srednja, dok je decentralizacija također srednja.

Atomic Swap Bridge sa HTLC

Druga klasa mostova se javlja ovisno o tehnologiji atomske zamjene (Lightning Network). Funkcioniše tako što: korisnik prenosi sredstva u atomski swap most, a zatim koristeći funkciju prijenosa mosta, inicira prijenos sredstava X na lancu A u sredstva Y na lancu B:

Kreirajte novi HTLC – Hash Lock vremenski ograničen ugovor
Deponujte sredstva X u ugovor na lancu A
Generirajte ključ za heš zaključavanje + šifrirajte tajnu za konačno povlačenje unutar vremena T na lancu B
Predstavite šifriranu tajnu za ugovor na lancu B za povlačenje sredstava Y
ILI vrijeme T je prošlo i povratite sredstva X iz ugovora na lancu A sa šifriranom tajnom
Značajna prednost je u tome što ne postoji centralizirani čvor/proces koji kontrolira prijenos mosta. A nedostatak je relativno čest – visoka cijena implementacije HTLC-a i pokretanja HTLC poziva. Zbog nepovjerenja, održavanje visoke sigurnosti i revizorskog traga je izazovno. Sigurnost ovog pristupa je visoka, a decentralizacija je također visoka, s obzirom na gore navedene nedostatke.

Interoperabilnost unakrsnog lanca sa Light Client + Oracle

Nakon pristupa premošćivanju sa visokim troškovima, rađa se više implementacija koje smanjuju ovaj trošak. Lagana klijentska tehnologija postala je najnovija norma za pojednostavljenje verifikacije unakrsnih lanaca. Proces je sljedeći:

Prvo, korisnik prenosi sredstva X u ugovor protokola interoperabilnosti između lanaca na lancu A
Poruka o prijenosu je postavljena ugovorom i preuzimaju je decentralizirani relejni čvorovi
Čvorovi šalju dokaze preko ugovora protokola na lancu B
Oracle mreža upravlja ažuriranjima zaglavlja bloka (lakog klijenta) kako bi se osigurala isporuka i valjanost
Korisnik povlači sredstva Y iz protokolarnog ugovora o lancu B nakon validacije
Prednost ovog pristupa je što nije potreban posrednički token ili lanac od prijenosa do završetka. Trenutna potvrda je moguća nakon ažuriranja zaglavlja bloka. Nedostaci su 1) rizici dosluha od Oracles-a, 2) zbog nepovjerenja, održavanja visoke sigurnosti, a revizorski trag je izazovan. Sigurnost ovog pristupa je srednja, dok je decentralizacija visoka.

Interoperabilnost unakrsnog lanca sa relejnim lancem

Na lekcijama Oracle pristupa, prisutno je i čisto rješenje lanca releja. Proces je malo drugačiji:

Korisnik prenosi sredstva X u ugovor protokola interoperabilnosti između lanaca na lancu A
Poruka o prijenosu je postavljena ugovorom i preuzimaju je decentralizirani relejni čvorovi
Čvorovi šalju dokaze ugovoru relejnog lanca
Osnovni validatori lanca releja obrađuju ažuriranja blokova kako bi osigurali isporuku i valjanost
Nakon validacije, čvorovi predajnika prosljeđuju poruku prijenosa ugovoru protokola na lancu B
Korisnik povlači sredstva Y iz protokolarnog ugovora o lancu B
Prednost ovog pristupa u odnosu na jednostavno Oracle rješenje su jeftinije naknade od relejnih lanaca koji troše većinu troškova. Trenutna potvrda je moguća nakon ažuriranja blokova, što je ključno za rješavanje dužih vremena kašnjenja. Problem je u tome što sam protokol možda ne podržava ekosistem svih lanaca. Sigurnost je visoka (unutar ekosistema), a decentralizacija je također visoka.

Infrastrukturni sloj unakrsnog lanca sa Light Client + Relay Chain

Rješenje sljedeće generacije je fokusirano na sloj infrastrukture unakrsnog lanca koji rješava sve osnovne probleme iznad. Kombinira laganu klijentsku tehnologiju sa relejnim lancem kako bi uključio sve lance:

Korisnik prenosi sredstva X u ugovor o interoperabilnosti sloja međulančane infrastrukture na lancu A
Poruka o prijenosu je postavljena ugovorom i preuzimaju je decentralizirani relejni čvorovi
Čvorovi šalju dokaze ugovoru o interoperabilnosti relejnog lanca
Ažuriranjem zaglavlja bloka (lakog klijenta) rukuju decentralizovani čvorovi održavanja kako bi se osigurala isporuka i valjanost
Nakon validacije, relejni čvorovi prosljeđuju prijenosnu poruku ugovoru o interoperabilnosti na lancu B
Korisnik povlači sredstva Y iz ugovora o interoperabilnosti na lancu B
Ovo rješenje osigurava interoperabilnost uz vrlo jeftine naknade zbog implementacije lanca releja. Također daje trenutnu potvrdu nakon ažuriranja zaglavlja bloka. Najveći izazov je visoka složenost optimizacije lakih klijenata na relejnom lancu. Sprovođenjem dovoljno istraživanja i inženjeringa, ove optimizacije bi trebale podržati prednosti koje drugi ne mogu riješiti. Sigurnost je vrlo visoka, a decentralizacija je visoka.

O MAP protokolu

Od rješenja unakrsnog lanca, tek treba da vidimo neko koje rješava sve gore navedene probleme. Dok se ne implementira MAP protokol. Nakon 3 godine kompleksnog istraživanja i razvoja, MAP Protocol je konačno postigao Omnichain sloj s laganom tehnologijom Client + relay chain bez kompromisa. MAP je implementirao Omnichain principe sa sljedećim svojstvima:

Developer Ready
Pokrivenost svih lanaca
Minimalni trošak
Sigurnosna konačnost
Trenutna potvrda

MAP protokol je infrastrukturni sloj koji podržava izgradnju mostova, DEX-ova, protokola interoperabilnosti i još mnogo toga. Podržava verifikaciju od strane lakih klijenata na MAP relejnom lancu direktno – radi smanjenja troškova. I pruža poticaje ugrađene u svaku komponentu za dapp programere da zarade ili prezentiraju krajnjim korisnicima. MAP podržava EVM i ne-EVM lance – sloj protokola je izomorfan sa svim lancima.

Za budućnost, MAP je infrastruktura iza svih lanaca koji će biti novi osnovni sloj. Programeri više nisu ograničeni svojim lancem izbora i mogu se fokusirati na sam dapp proizvod. Budućnost je Omnichain, a više modularizacije i stimulacije su način na koji treba ići.