Īsa krusteniskās ķēdes vēsture: deviņu dažādu šķērsķēžu risinājumu skaidrojums

Pārrobežu ķēdes risinājumi ir bijusi visvairāk apspriestā tēma pagājušajā gadā. Līdz ar publisko ķēžu infrastruktūru pieaugumu ir bijusi liela interese par to, kā dažādas ķēdes runā un sazinās. Risinājumi ir piedāvāti un ieviesti, taču neviens no tiem neatrisina fundamentālās problēmas bez krasiem kompromisiem. Tagad mēs pārbaudām dažādas starpķēžu pieejas un atklājam, kāpēc un kā tās veidos starpķēžu infrastruktūras nākotni.

Vispirms apspriedīsim, kas ir starpķēžu tehnoloģija un kāpēc tā ir nepieciešama. Izmantošanas iemesls: ķēdes ir neviendabīgas, un izstrādātājiem ir nepieciešams daudz laika, lai, pārvietojot līdzekļus, sekotu līdzi atšķirībām un izaicinājumiem. Tilti ir mazāk droši, un tiem nevar 100% uzticēties, jo tie parasti pieder blokķēdes projekta komandām un ir ļoti centralizēti (netīri, bez katras komandas koordinācijas). 1. slāņa blokķēdes mērķis ir standartizēt, bet 1. slāņa ķēžu segmentēšana rada nepieciešamību pēc starpķēžu infrastruktūras slāņa, kas atrodas pat zem 1. slāņa.

Ir jāizklāsta un jāsalīdzina pārrobežu ķēžu mehānismu vēsture, lai izprastu starpķēžu risinājumus un salīdzinātu to atšķirības un īpašības.

Manuālā pārsūtīšana

 
Pats pirmais starpķēžu risinājums ir manuāla līdzekļu pārsūtīšana. Process sākas ar to, ka lietotājs pārsūta līdzekļus uz noteiktu maku ķēdē A, un centralizēta vienība uzrauga, vai makā nav pārsūtīšanas, un ieraksta tos programmā Excel. Pēc tam pēc noteikta laika (parasti uzraudzības nolūkos) uzņēmums pēc pārbaudes kreditē aktīvus ķēdē B. Šīs pieejas priekšrocība ir ieviešanas vienkāršība, taču tā ir pakļauta cilvēku kļūdām un tai ir ļoti zema drošības garantija. Šajā pieejā nav arī decentralizācijas.

Pusautomātiskā pārsūtīšana

Nākamā iterācija tiek uzlabota, jo lietotājs pārsūta līdzekļus uz noteiktu maku un/vai viedo līgumu ķēdē A. Pēc tam centralizēta programma pārrauga pārsūtīšanas adresi. Šāda programma pēc pārbaudes automātiski nosūta līdzekļus ķēdei B. Pluss joprojām ir ieviešanas vienkāršība bez pārāk lielas sarežģītības vai kodēšanas, un ierakstus var glabāt ķēdē, nevis lokāli. Negatīvā puse ir tāda, ka centralizētā programma var būt kļūdaina vai nepareiza. Arī centrālajā kredītkontā var beigties līdzekļi. Arī drošības garantija ir zema, un nav nekādas decentralizācijas.

Centralizēta birža

Ja vienkāršie starpķēžu risinājumi nav mērogojami, centralizētās apmaiņas plaukst, apmierinot starpķēžu vajadzības. Tie darbojas, liekot lietotājiem nodot aktīvus savā centralizētajā biržā un pēc tam, izmantojot biržas “iekšējo” mijmaiņas darījumu, pārvērš “aktīvus X” ķēdē A par “aktīviem Y” ķēdē B, izmantojot ierakstu uzskaiti. Priekšrocība ir acīmredzama — tas ir visvieglāk lietojams risinājums — nav nepieciešama kodēšana, un 1. līmeņa apmaiņai ir augsta uzticamība. Taču problēma atklāj pretēju trūkumu – centralizētu kontroli pār to, kad ir pieejams depozīts/izņemšana. Centralizētā apmaiņa nodrošina augstu drošību ar mazāko decentralizācijas negatīvo pusi.

Centralizētais tilts

Nākamais sasniegums uzlabojas, izveidojot atsevišķu infrastruktūru aktīvu pārvietošanai pa ķēdēm – tiltu. Centralizēts tilts darbojas, lietotājam pārsūtot līdzekļus, pēc tam izmantojot tilta pārsūtīšanas funkciju, iniciējot aktīvu X pārsūtīšanu ķēdē A uz aktīviem Y ķēdē B. Par procesu ir atbildīgs centralizēts relayeris (vai to kopa):

Bloķējiet īpašumus X ķēdē A
Pārbaudīt
Kaltuves aktīvi Y ķēdē B
Šī tilta priekšrocība ir pilnībā automātisks process bez manuāliem pārtraukumiem. Un trūkums joprojām ir centralizēta kontrole pār to, kad ir pieejams depozīts/izņemšana. Tāpat tilts var būt nojaukts vai uzlauzts, ik pa laikam padarot to nefunkcionālu. Tātad drošība ir vidēja, un joprojām nav nekādas decentralizācijas.

Decentralizēts tilts ar MPC

Nākamā iterācija ir verifikācijas modeļa decentralizācija centralizēta tilta vietā. MPC (Multi-Party Computation) tilts sākas ar to, ka lietotāji pārsūta uz to aktīvus. Izmantojot tilta pārsūtīšanas funkciju, tas sāk aktīvu X pārsūtīšanu ķēdē A uz aktīviem Y ķēdē B. Parasti par procesu ir atbildīgs decentralizēts releju kopums:

Bloķējiet īpašumus X ķēdē A, izmantojot MPC
Pārbaudiet, izmantojot MPC
Minēt aktīvus Y ķēdē B, izmantojot MPC
MPC priekšrocība ir pilnībā automātisks process bez manuāliem pārtraukumiem, un releja mezgli nav jācentralizē. Negatīvā puse ir MPC augstās skaitļošanas un sakaru izmaksas. Arī mezgli var tikt apdraudēti vai slepeni. Drošība ir vidēja, savukārt decentralizācija ir arī vidēja.

Atomu maiņas tilts ar HTLC

Cita tiltu klase rodas atkarībā no atomu mijmaiņas (zibens tīkla) tehnoloģijas. Tas darbojas šādi: lietotājs pārsūta līdzekļus uz atomu mijmaiņas tiltu un pēc tam, izmantojot tilta pārsūtīšanas funkciju, uzsāk aktīvu X pārnešanu ķēdē A uz aktīviem Y ķēdē B:

Izveidojiet jaunu HTLC — Hash Lock Timed Contract
Noguldiet aktīvus X līgumā ķēdē A
Ģenerējiet jaucējkoda bloķēšanas atslēgu + šifrējiet noslēpumu galīgai izņemšanai laikā T ķēdē B
Uzrādiet šifrētu noslēpumu, lai noslēgtu līgumu ķēdē B par aktīvu Y atsaukšanu
VAI laiks T ir pagājis, un atgūstiet aktīvus X no līguma ķēdē A ar šifrētu noslēpumu
Būtiska priekšrocība ir tāda, ka nav centralizēta mezgla/procesa, kas kontrolētu tilta pārsūtīšanu. Un mīnuss ir salīdzinoši izplatīts – augstās izmaksas par HTLC izvietošanu un HTLC zvanu veikšanu. Neuzticības dēļ augstas drošības un audita izsekojamības uzturēšana ir sarežģīta. Šīs pieejas drošība ir augsta, un arī decentralizācija ir augsta, ņemot vērā iepriekš minētos trūkumus.

Vairāku ķēžu savietojamība ar Light Client + Oracle

Pēc tam, kad tuvojas augsto izmaksu tilts, tiek radīts vairāk ieviešanu, lai samazinātu šīs izmaksas. Vieglā klienta tehnoloģija ir kļuvusi par jaunāko normu, lai vienkāršotu starpķēžu pārbaudes. Process ir šāds:

Pirmkārt, lietotājs pārsūta aktīvus X uz starpķēžu sadarbspējas protokola līgumu ķēdē A
Pārsūtīšanas ziņojums tiek iestatīts līgumā, un to uztver decentralizētie relayer mezgli
Mezgli nosūta pierādījumus protokola līgumam ķēdē B
Bloku galvenes (vieglā klienta) atjauninājumus apstrādā Oracle tīkls, lai nodrošinātu piegādi un derīgumu
Pēc apstiprināšanas lietotājs atsauc aktīvus Y no protokola līguma ķēdē B
Šīs pieejas priekšrocība ir tāda, ka no pārsūtīšanas līdz pabeigšanai nav nepieciešams starpnieka marķieris vai ķēde. Tūlītējs apstiprinājums ir iespējams pēc bloku galvenes atjaunināšanas. Mīnusi ir 1) Oracle slepenās vienošanās riski, 2) neuzticēšanās, augstas drošības uzturēšanas un audita izsekojamības dēļ. Šīs pieejas drošība ir vidēja, savukārt decentralizācija ir augsta.

Cross-ķēdes savietojamība ar releja ķēdi

Pēc Oracle pieejas mācībām ir pieejams arī tīrs releja ķēdes risinājums. Process ir nedaudz atšķirīgs:

Lietotājs pārsūta aktīvus X uz starpķēžu sadarbspējas protokola līgumu ķēdē A
Pārsūtīšanas ziņojums tiek iestatīts līgumā, un to uztver decentralizētie relayer mezgli
Mezgli nosūta apliecinājumus releja ķēdes līgumam
Pamatā esošie releja ķēdes pārbaudītāji apstrādā bloku atjauninājumus, lai nodrošinātu piegādi un derīgumu
Pēc apstiprināšanas relayer mezgli pārsūta pārsūtīšanas ziņojumu uz protokola līgumu ķēdē B
Lietotājs atsauc aktīvus Y no protokola līguma ķēdē B
Šīs pieejas priekšrocība salīdzinājumā ar vienkāršo Oracle risinājumu ir lētākās maksas no releju ķēdēm, kas patērē lielāko daļu izmaksu. Tūlītējs apstiprinājums ir iespējams pēc bloku atjaunināšanas, kas ir ļoti svarīgi, lai atrisinātu ilgākus aizkaves laikus. Problēma ir tāda, ka pats protokols var neatbalstīt visas ķēdes ekosistēmu. Drošība ir augsta (ekosistēmā), un arī decentralizācija ir augsta.

Cross-ķēdes infrastruktūras slānis ar Light Client + Relay Chain

Nākamās paaudzes risinājums ir vērsts uz starpķēžu infrastruktūras slāni, kas atrisina visas iepriekš minētās pamatproblēmas. Tas apvieno vieglā klienta tehnoloģiju ar releja ķēdi, lai iekļautu visas ķēdes:

Lietotājs pārsūta aktīvus X uz starpķēžu infrastruktūras slāņa sadarbspējas līgumu ķēdē A
Pārsūtīšanas ziņojums tiek iestatīts līgumā, un to uztver decentralizētie relayer mezgli
Mezgli nosūta apliecinājumus releja ķēdes sadarbspējas līgumam
Bloku galvenes (vieglā klienta) atjauninājumus apstrādā decentralizēti uzturētāja mezgli, lai nodrošinātu piegādi un derīgumu
Pēc apstiprināšanas relayer mezgli pārsūta ziņojumu uz sadarbspējas līgumu ķēdē B
Lietotājs atsauc aktīvus Y no sadarbspējas līguma ķēdē B
Šis risinājums nodrošina sadarbspēju ar ļoti lētām maksām, pateicoties releja ķēdes ieviešanai. Tas arī sniedz tūlītēju apstiprinājumu pēc bloku galvenes atjaunināšanas. Lielākais izaicinājums ir vieglo klientu optimizēšanas augstā sarežģītība releja ķēdē. Veicot pietiekami daudz pētījumu un inženierijas, šīm optimizācijām vajadzētu atbalstīt ieguvumus, ko citi nevar atrisināt. Drošība ir ļoti augsta, un decentralizācija ir augsta.

Par MAP protokolu

No starpķēžu risinājumiem mums vēl nav jāredz tāds, kas atrisinātu visas iepriekš minētās problēmas. Līdz MAP protokola ieviešanai. Pēc 3 gadu sarežģītas izpētes un izstrādes, MAP Protocol beidzot ir ieguvis Omnichain slāni ar vieglo Client + relay ķēdes tehnoloģiju bez kompromisiem. MAP ir ieviesis Omnichain principus ar šādām īpašībām:

Izstrādātājs gatavs
Visu ķēžu pārklājums
Minimālās izmaksas
Drošības galīgums
Tūlītējs apstiprinājums

MAP Protocol ir infrastruktūras slānis, kas atbalsta tiltu, DEX, sadarbspējas protokolu un daudz ko citu. Tas atbalsta vieglo klientu verifikāciju tieši MAP releju ķēdē, lai samazinātu izmaksas. Un tas nodrošina katrā komponentā iebūvētus stimulus, lai dapp izstrādātāji varētu nopelnīt vai piedāvāt galalietotājiem. MAP atbalsta EVM un ne-EVM ķēdes – protokola slānis ir izomorfs ar visām ķēdēm.

Nākotnē MAP ir infrastruktūra aiz visām ķēdēm, kas būs jaunais bāzes slānis. Izstrādātājus vairs neierobežo viņu izvēles ķēde, un viņi var koncentrēties uz pašu dapp produktu. Nākotne ir Omnichain, un lielāka modularizācija un stimulēšana ir pareizais ceļš.