Ristahela lühiajalugu: üheksa erineva ahelavahelise lahenduse selgitamine

Viimase aasta enim kõneainet pakkunud teemad on ahelatevahelised lahendused. Avaliku keti infrastruktuuri tõusuga on tekkinud tohutu huvi selle vastu, kuidas erinevad ketid räägivad ja suhtlevad. Lahendusi on pakutud ja ellu viidud, kuid ükski neist ei lahenda põhimõttelisi probleeme ilma drastiliste kompromissideta. Nüüd uurime erinevaid ahelatevahelisi lähenemisviise ja avaldame, miks ja kuidas need kujundavad ahelaülese infrastruktuuri tulevikku.

Kõigepealt arutleme, mis on ahelatevaheline tehnoloogia ja miks seda vaja on. Kasutamise põhjus: ketid on heterogeensed ja nõuavad arendajatelt palju aega, et varade teisaldamisel erinevusi ja väljakutseid jälgida. Sillad on vähem turvalised ja neid ei saa 100% usaldada, kuna need kuuluvad tavaliselt plokiahela projektimeeskondadele ja on väga tsentraliseeritud (segased, ilma iga meeskonna koordineerimiseta). Esimese kihi plokiahela eesmärk on standardida, kuid 1. kihi ahelate segmenteerimine toob kaasa vajaduse ahelatevahelise infrastruktuuri kihi järele, mis oleks isegi kihtide 1 all.

Ristahelate mehhanismide ajalugu tuleb paika panna ja võrrelda, et mõista ahelatevahelisi lahendusi ning võrrelda nende erinevusi ja omadusi.

Käsitsi ülekanne

 
Kõige esimene ahelaülene lahendus on varade käsitsi ülekandmine. Protsess algab sellega, et kasutaja kannab varad ahelas A konkreetsesse rahakotti ning tsentraliseeritud üksus jälgib rahakotti ülekannete osas ja salvestab need Excelisse. Seejärel krediteerib üksus teatud aja pärast (tavaliselt jälgimise eesmärgil) varad pärast kontrollimist ahelasse B. Selle lähenemisviisi eeliseks on rakendamise lihtsus, kuid see on altid inimlikele vigadele ja sellel on väga madal turvagarantii. Selles lähenemisviisis puudub ka detsentraliseerimine.

Poolautomaatne ülekanne

Järgmine iteratsioon paraneb, kuna kasutaja kannab varad ahelas A konkreetsesse rahakotti ja/või nutikasse lepingusse. Seejärel jälgib tsentraliseeritud programm ülekannete aadressi. Selline programm saadab varad pärast kontrollimist automaatselt ahelasse B. Plussiks on siiski juurutamise lihtsus ilma liigse keerukuse või kodeerimiseta ning kirjeid saab hoida ahelas, mitte lokaalselt. Negatiivne külg on see, et tsentraliseeritud programm võib olla lollakas või talitlushäire. Kesksel krediidikontol võib samuti raha otsa saada. Turvagarantii on samuti madal ja detsentraliseerimist ei toimu.

Tsentraliseeritud börs

Kui lihtsad ahelatevahelised lahendused ei ole skaleeritavad, saavad tsentraliseeritud vahetused ahelaüleste vajaduste rahuldamiseks hakkama. Need töötavad nii, et kasutajad kannavad varad oma tsentraliseeritud börsile ja muudavad seejärel börsi sisemise vahetuslepingu abil ahela A varad X ahela B varadeks Y. Eelis on ilmne – seda on kõige lihtsam kasutada – pole vaja kodeerida ja 1. astme vahetustel on kõrge töökindlus. Kuid probleem paljastab vastupidise puuduse – tsentraliseeritud kontroll selle üle, millal on võimalik sissemakse/väljamakse võimalus. Tsentraliseeritud börs annab kõrge turvalisuse, mille negatiivne külg on vähim detsentraliseerimine.

Tsentraliseeritud sild

Järgmine edasiminek paraneb tänu sellele, et varade üle ahelate ülekandmiseks on eraldi infrastruktuur – sild. Tsentraliseeritud sild toimib nii, et kasutaja kannab varasid üle, seejärel alustab silla edastusfunktsiooni kasutades ahela A varade X ülekandmist ahela B varadesse Y. Protsessi eest vastutab tsentraliseeritud relee (või nende komplekt):

Lukusta varad X ketis A
Kontrollima
Rahapaja Y ahelas B
Selle silla eeliseks on täisautomaatne protsess ilma käsitsi katkestamata. Ja puuduseks on endiselt tsentraliseeritud kontroll selle üle, millal sissemakse/väljamakse on saadaval. Samuti võib sild olla maas või häkitud, muutes selle aeg-ajalt ebafunktsionaalseks. Seega on turvalisus keskmine ja detsentraliseerimist ikka veel ei toimu.

MPC-ga detsentraliseeritud sild

Järgmine iteratsioon on kontrollimudeli detsentraliseerimine tsentraliseeritud silla asemel. MPC (Multi-Party Computation) sild algab sellega, et kasutajad kannavad sinna varasid. Silla edastusfunktsiooni kasutades käivitab see ahelas A varade X ülekandmise ahelas B varadesse Y. Protsessi eest vastutab tavaliselt detsentraliseeritud releerite komplekt:

Lukustage varad X ketti A kasutades MPC
Kinnitage MPC abil
Rahapaja Y ahelas B, kasutades MPC-d
MPC pluss on täisautomaatne protsess ilma käsitsi katkestamata ja releesõlmed ei pea olema tsentraliseeritud. Negatiivne külg on MPC kõrge arvutus- ja sidekulu. Samuti võivad sõlmed olla ohustatud või kokkulepitud. Turvalisus on keskmine, samas kui ka detsentraliseerimine on keskmine.

Aatomivahetussild HTLC-ga

Teine sildade klass tekib sõltuvalt aatomivahetuse (Lightning Network) tehnoloogiast. See toimib järgmiselt: kasutaja kannab varad üle aatomivahetussilda ja seejärel silla edastusfunktsiooni kasutades algatab ahela A varade X ülekandmise ahela B varadesse Y:

Looge uus HTLC – Hash Lock Timed Contract
Deponeerige varad X lepingusse ahelas A
Looge räsiluku võti + krüpteerige saladus lõplikuks väljavõtmiseks aja T ahelas B
Esitage krüpteeritud saladus, et sõlmida ahelas B, et vara Y tagasi võtta
VÕI aeg T on möödas ja taastage varad X ahela A lepingust koos krüpteeritud saladusega
Oluliseks eeliseks on see, et puudub sillaedastust juhtiv tsentraliseeritud sõlm/protsess. Ja miinus on suhteliselt tavaline – HTLC juurutamise ja HTLC kõnede käitamise kõrge hind. Usaldamatuse tõttu on kõrge turvalisuse ja kontrolljälje säilitamine keeruline. Selle lähenemisviisi turvalisus on kõrge ja ka detsentraliseeritus kõrge, arvestades ülaltoodud puudusi.

Ketiülene koostalitlusvõime Light Client + Oracle'iga

Pärast kallite sillade lähenemist sünnib selle kulude vähendamiseks rohkem rakendusi. Kergest klienditehnoloogiast on saanud uusim norm ahelatevahelise kontrollimise lihtsustamiseks. Protsess on järgmine:

Esiteks kannab kasutaja varad X üle ahelatevahelise koostalitlusvõime protokolli lepingusse ahelas A
Edastussõnum määratakse lepingu alusel ja selle võtavad vastu detsentraliseeritud releesõlmed
Sõlmed saadavad tõendid protokolli lepingule ahelas B
Plokipäise (kerge kliendi) värskendustega tegeleb Oracle'i võrk, et tagada kohaletoimetamine ja kehtivus
Kasutaja võtab valideerimisel B-ahela protokolli lepingust vara Y tagasi
Selle lähenemisviisi eeliseks on see, et ülekandest kuni lõpetamiseni pole vaja vahendajat ega ahelat. Pärast plokipäiste värskendamist on võimalik kohene kinnitus. Miinused on 1) Oraclesi kokkumänguriskid, 2) usaldusväärsus, kõrge turvalisuse tagamine ja kontrolljälg on keeruline. Selle lähenemisviisi turvalisus on keskmine, samas kui detsentraliseeritus on kõrge.

Ketiülene koostalitlusvõime releeahelaga

Oracle'i lähenemisviisi õppetundide põhjal on olemas ka puhas releeahela lahendus. Protsess on veidi erinev:

Kasutaja kannab varad X üle ahelatevahelise koostalitlusvõime protokolli lepingusse ahelas A
Edastussõnum määratakse lepingu alusel ja selle võtavad vastu detsentraliseeritud releesõlmed
Sõlmed saadavad tõendid releeahela lepingule
Aluseks olevad releeahela valideerijad töötlevad ploki värskendusi, et tagada kohaletoimetamine ja kehtivus
Valideerimisel edastavad ülekandesõlmed edastusteate protokolli lepingule ahelas B
Kasutaja võtab B-ahela protokolli lepingust varad Y tagasi
Selle lähenemisviisi eelis Oracle'i lihtsa lahenduse ees on releeahelate odavamad tasud, mis kulutavad suurema osa kuludest. Pärast plokkide värskendamist on võimalik kohene kinnitus, mis on pikemate viivitusaegade lahendamiseks ülioluline. Probleem on selles, et protokoll ise ei pruugi toetada kogu ahelaga ökosüsteemi. Turvalisus on kõrge (ökosüsteemi sees) ja ka detsentraliseeritus on kõrge.

Ahelaülene infrastruktuurikiht koos Light Client + releeahelaga

Järgmise põlvkonna lahendus on keskendunud ahelatevahelisele infrastruktuurikihile, mis lahendab kõik ülaltoodud põhiprobleemid. See ühendab kerge kliendi tehnoloogia releeahelaga, et hõlmata kõik ahelad:

Kasutaja kannab varad X üle ahelaülese infrastruktuuri kihi koostalitluslepingusse ahelas A
Edastussõnum määratakse lepingu alusel ja selle võtavad vastu detsentraliseeritud releesõlmed
Sõlmed saadavad tõendid edastusahela koostalitlusvõime lepingule
Ploki päise (kerge kliendi) värskendustega tegelevad detsentraliseeritud hooldussõlmed, et tagada kohaletoimetamine ja kehtivus
Valideerimisel edastavad ülekandesõlmed edastusteate ahela B koostalitlusvõime lepingule
Kasutaja võtab varad Y tagasi ahela B koostalitluslepingust
See lahendus tagab koostalitlusvõime väga odavate tasudega tänu releeahela rakendamisele. See annab ka kohese kinnituse pärast plokipäiste värskendamist. Suurim väljakutse on kergete klientide optimeerimise keerukus releeahelas. Piisava uurimis- ja inseneritöö läbiviimisega peaksid need optimeerimised toetama eeliseid, mida teised ei suuda lahendada. Turvalisus on väga kõrge ja detsentraliseeritus kõrge.

MAP-protokolli kohta

Ahelaülestest lahendustest ei ole me veel näinud sellist, mis lahendaks kõik ülaltoodud probleemid. Kuni MAP-protokolli rakendamiseni. Pärast 3 aastat kestnud keerulist uurimis- ja arendustegevust on MAP Protocol lõpuks saavutanud kompromissideta Omnichaini kihi kerge Client + releeahela tehnoloogiaga. MAP on rakendanud Omnichaini põhimõtted järgmiste omadustega:

Arendaja valmis
Kogu ahela katvus
Minimaalne maksumus
Turvalisuse lõplikkus
Kohene kinnitus

MAP-protokoll on infrastruktuuri kiht, mis toetab sildade, DEX-ide, koostalitlusvõime protokollide ja palju muud ehitamist. Kulude vähendamiseks toetab see MAP-releeahelas otse kergklientide kontrollimist. Ja see pakub igale komponendile sisseehitatud stiimuleid, et dappide arendajad saaksid teenida või lõppkasutajatele esitada. MAP toetab EVM-i ja mitte-EVM-i ahelaid – protokollikiht on kõigi ahelatega isomorfne.

Tuleviku jaoks on MAP kõigi kettide taga olev infrastruktuur, millest saab uus aluskiht. Arendajaid ei piira enam nende valikuahel ja nad saavad keskenduda dapp-tootele endale. Tulevik on Omnichain ning rohkem modulariseerimist ja stiimuleid on õige tee.