Cross-Chainin lyhyt historia: Selitetään yhdeksän erilaista cross-chain-ratkaisua

Ketjujen väliset ratkaisut ovat olleet puhutuin aihe kuluneen vuoden aikana. Julkisten ketjuinfrastruktuurien nousun myötä on ollut valtava kiinnostus sitä kohtaan, miten eri ketjut puhuvat ja kommunikoivat. Ratkaisuja on ehdotettu ja toteutettu, mutta mikään niistä ei ratkaise perusongelmia ilman rajuja kompromisseja. Nyt tutkimme erilaisia ​​ketjujen välisiä lähestymistapoja ja paljastamme, miksi ja miten ne muokkaavat ketjujen välisen infrastruktuurin tulevaisuutta.

Ensin keskustellaan siitä, mitä cross-chain-tekniikka on ja miksi sitä tarvitaan. Käytön syy: ketjut ovat heterogeenisiä ja vaativat kehittäjiltä paljon aikaa erojen ja haasteiden seuraamiseen resurssien siirtämisessä. Sillat ovat vähemmän turvallisia, eikä niihin voi 100-prosenttisesti luottaa, koska ne ovat yleensä lohkoketjuprojektitiimien omistamia ja erittäin keskitettyjä (sotkuinen ilman koordinointia kummaltakin tiimiltä). Kerroksen 1 lohkoketjun tavoitteena on standardisoida, mutta kerroksen 1 ketjujen segmentointi johtaa tarpeeseen ketjujen väliselle infrastruktuurikerrokselle, joka on jopa kerrosten 1 alla.

Ketjujen välisten mekanismien historiaa on hahmoteltava ja verrattava, jotta voidaan ymmärtää ketjujen välisiä ratkaisuja ja vertailla niiden eroja ja ominaisuuksia.

Manuaalinen siirto

 
Ensimmäinen ketjujen välinen ratkaisu on omaisuuden manuaalinen siirto. Prosessi alkaa siten, että käyttäjä siirtää omaisuutta tiettyyn lompakkoon ketjussa A, ja keskitetty kokonaisuus tarkkailee lompakosta siirtoja ja tallentaa ne Exceliin. Sitten rajallisen ajan kuluttua (yleensä valvontatarkoituksiin) entiteetti hyvittää varat ketjulle B varmentamisen jälkeen. Tämän lähestymistavan etuna on helppokäyttöisyys, mutta se on altis inhimillisille virheille ja sen turvallisuustakuu on erittäin alhainen. Tässä lähestymistavassa ei myöskään ole hajauttamista.

Puoliautomaattinen siirto

Seuraava iteraatio paranee saamalla käyttäjän siirtämään omaisuutta tiettyyn lompakkoon ja/tai älysopimukseen ketjussa A. Sitten keskitetty ohjelma tarkkailee osoitetta siirtoja varten. Tällainen ohjelma lähettää automaattisesti varoja ketjuun B vahvistuksen jälkeen. Kääntöpuolena on edelleen helppokäyttöisyys ilman liiallista monimutkaisuutta tai koodausta, ja tietueet voidaan säilyttää ketjussa paikallisen sijaan. Haittapuolena on, että keskitetty ohjelma voi olla viallinen tai toimintahäiriö. Myös keskusluottotililtä voi loppua varat. Myös turvallisuustakuu on alhainen, eikä hajauttamista ole.

Keskitetty vaihto

Kun yksinkertaiset ketjujen väliset ratkaisut eivät ole skaalautuvia, keskitetty vaihto kukoistaa ketjujen väliset tarpeet. Ne toimivat siten, että käyttäjät siirtävät varoja keskitettyyn pörssiinsä ja muuttavat sitten pörssin "sisäistä" swapia käyttämällä tietuekirjanpidon avulla ketjun A "varat X" ketjun B "omaisuuksiksi Y". Etu on ilmeinen – se on helpoin ratkaisu käyttää – koodausta ei tarvita, ja tason 1 vaihdot ovat erittäin luotettavia. Mutta ongelma paljastaa päinvastaisen haitan – keskitetyn hallinnan siitä, milloin talletus/nosto on saatavilla. Keskitetty vaihto antaa korkean turvallisuuden vähiten hajauttamisen haittapuolena.

Keskitetty silta

Seuraava edistysaskel paranee, kun omaisuuden siirtoon ketjujen välillä on erillinen infrastruktuuri – silta. Keskitetty silta toimii siten, että käyttäjä siirtää resursseja ja sillan siirtoominaisuutta käyttämällä aloittaa ketjun A resurssien X siirtämisen ketjun B resursseihin Y. Prosessista vastaa keskitetty välitin (tai joukko niitä):

Lukitse omaisuus X ketjussa A
Todentaa
Rahapajavarat Y ketjussa B
Tämän sillan etuna on täysin automaattinen prosessi ilman manuaalista keskeytystä. Ja haittana on edelleen keskitetty valvonta sille, milloin talletus/nosto on saatavilla. Myös silta voi olla alhaalla tai hakkeroitu, mikä tekee siitä toimimattoman ajoittain. Turvallisuus on siis keskitasoa, eikä hajauttamista ole vieläkään.

Hajautettu silta MPC:llä

Seuraava iteraatio on verifiointimallin hajauttaminen keskitetyn sillan sijaan. MPC (Multi-Party Computation) -silta alkaa siitä, että käyttäjät siirtävät omaisuutta siihen. Sillan siirtoominaisuutta käyttämällä se käynnistää ketjun A resurssien X siirtämisen ketjun B resursseihin Y. Prosessista vastaa yleensä hajautettu joukko välittimiä:

Lukitse resurssit X ketjussa A MPC:n avulla
Tarkista MPC:llä
Rahapaja Y ketjussa B käyttämällä MPC:tä
MPC:n kääntöpuolena on täysin automaattinen prosessi ilman manuaalista keskeytystä, eikä välityssolmuja tarvitse keskittää. Huono puoli on MPC:n korkeat laskenta- ja viestintäkustannukset. Solmut voivat myös vaarantua tai salata. Turvallisuus on keskitasoa, kun taas hajauttaminen on myös keskitasoa.

Atomic Swap Bridge HTLC:llä

Toinen siltojen luokka syntyy atominvaihtotekniikasta (Lightning Network) riippuen. Se toimii seuraavasti: käyttäjä siirtää resurssit atomin vaihtosillalle ja sitten sillan siirtoominaisuutta käyttämällä aloittaa ketjun A resurssien X siirtämisen ketjun B varoiksi Y:

Luo uusi HTLC – Hash Lock Timed Contract
Talleta varat X sopimukseen ketjussa A
Luo tiivistelukkoavain + salaa salaisuus lopullista nostoa varten ajassa T ketjussa B
Esitä salattu salaisuus tehdäksesi sopimuksen ketjussa B varojen Y poistamisesta
TAI aika T on kulunut, ja palauta varat X ketjun A sopimuksesta salatulla salaisuudella
Merkittävä etu on, ettei sillansiirtoa ohjaa keskitettyä solmua/prosessia. Haittapuoli on suhteellisen yleinen – HTLC:n käyttöönoton ja HTLC-puheluiden korkeat kustannukset. Luottamuksen vuoksi korkean turvallisuuden ja kirjausketjun ylläpitäminen on haastavaa. Tämän lähestymistavan turvallisuus on korkea, ja myös hajauttaminen on korkea, ottaen huomioon edellä mainitut haitat.

Ketjujen välinen yhteentoimivuus Light Client + Oraclen kanssa

Korkean kustannustason sillan lähestymisen jälkeen syntyy lisää toteutuksia näiden kustannusten alentamiseksi. Kevyestä asiakasteknologiasta on tullut uusin normi ketjujen välisten todentamisen yksinkertaistamiseksi. Prosessi on seuraava:

Ensin käyttäjä siirtää resurssit X ketjujen välisen yhteentoimivuusprotokollan sopimukseen ketjussa A
Siirtoviesti asetetaan sopimukseen, ja hajautetut välityssolmut vastaanottavat sen
Solmut lähettävät todisteita protokollan sopimukselle ketjussa B
Oracle-verkko hoitaa lohkootsikon (kevyt asiakas) päivitykset toimituksen ja kelpoisuuden varmistamiseksi
Käyttäjä vetää varoja Y protokollan sopimuksesta ketjussa B validoinnin yhteydessä
Tämän lähestymistavan etuna on, että mitään välittäjätunnusta tai ketjua ei tarvita siirrosta valmistumiseen. Välitön vahvistus on mahdollista, kun lohkootsikot on päivitetty. Haittapuolena ovat 1) Oraclesin yhteistyöriskit, 2) luottamattomuudesta johtuvat korkean turvallisuuden ylläpitäminen ja kirjausketju on haastava. Tämän lähestymistavan turvallisuus on keskitasoa, kun taas hajauttaminen on korkeaa.

Ketjujen välinen yhteentoimivuus releketjun kanssa

Oracle-lähestymistavan oppituntien perusteella on olemassa myös puhdas välitysketjuratkaisu. Prosessi on hieman erilainen:

Käyttäjä siirtää resurssit X ketjujen välisen yhteentoimivuusprotokollan sopimukseen ketjussa A
Siirtoviesti asetetaan sopimukseen, ja hajautetut välityssolmut vastaanottavat sen
Solmut lähettävät todisteet välitysketjun sopimukseen
Taustalla olevat välitysketjun tarkistajat käsittelevät lohkopäivitykset toimitusten ja kelpoisuuden varmistamiseksi
Vahvistuksen jälkeen välityssolmut välittävät siirtosanoman protokollan sopimukselle ketjussa B
Käyttäjä poistaa omaisuuden Y protokollan sopimuksesta ketjussa B
Tämän lähestymistavan etuna yksinkertaiseen Oracle-ratkaisuun verrattuna on releketjujen halvemmat maksut, jotka kuluttavat suurimman osan kustannuksista. Välitön vahvistus on mahdollista lohkojen päivityksen jälkeen, mikä on ratkaisevan tärkeää pitkien viiveaikojen ratkaisemisessa. Ongelmana on, että protokolla ei välttämättä tue koko ketjun ekosysteemiä. Turvallisuus on korkea (ekosysteemin sisällä), ja myös hajauttaminen on korkea.

Cross-chain Infrastructure Layer Light Client + Relay Chain

Seuraavan sukupolven ratkaisu keskittyy ketjujen väliseen infrastruktuurikerrokseen, joka ratkaisee kaikki yllä olevat perusongelmat. Siinä yhdistyvät kevyt asiakastekniikka releketjuun, joka yhdistää kaikki ketjut:

Käyttäjä siirtää resurssit X ketjujen välisen infrastruktuurikerroksen yhteentoimivuussopimukseen ketjussa A
Siirtoviesti asetetaan sopimukseen, ja hajautetut välityssolmut vastaanottavat sen
Solmut lähettävät todisteet välitysketjun yhteentoimivuussopimukseen
Lohkootsikon (kevyt asiakas) päivitykset käsittelevät hajautetut ylläpitosolmut toimitusten ja kelpoisuuden varmistamiseksi
Vahvistuksen jälkeen välityssolmut välittävät siirtosanoman yhteentoimivuussopimukseen ketjussa B
Käyttäjä poistaa omaisuuden Y ketjun B yhteentoimivuussopimuksesta
Tämä ratkaisu varmistaa yhteentoimivuuden erittäin halpoilla maksuilla välitysketjun toteutuksen ansiosta. Se antaa myös välittömän vahvistuksen, kun lohkootsikot on päivitetty. Suurin haaste on kevyiden asiakkaiden optimoinnin monimutkaisuus välitysketjussa. Tehmällä riittävästi tutkimusta ja suunnittelua, näiden optimointien pitäisi tukea etuja, joita muut eivät pysty ratkaisemaan. Turvallisuus on erittäin korkea, ja hajauttaminen on korkea.

Tietoja MAP-protokollasta

Ketjujen välisistä ratkaisuista emme ole vielä nähneet sellaista, joka ratkaisee kaikki yllä olevat ongelmat. Kunnes MAP-protokolla on otettu käyttöön. Kolmen vuoden monimutkaisen tutkimuksen ja kehityksen jälkeen MAP Protocol on vihdoin saavuttanut Omnichain-kerroksen kevyellä Client + releketjuteknologialla ilman kompromisseja. MAP on ottanut käyttöön Omnichain-periaatteet seuraavilla ominaisuuksilla:

Kehittäjä valmiina
Koko ketjun kattavuus
Vähimmäiskustannukset
Turvallisuuden lopullisuus
Välitön vahvistus

MAP Protocol on infrastruktuurikerros, joka tukee siltojen rakentamista, DEXE:itä, yhteentoimivuusprotokollia ja paljon muuta. Se tukee MAP-välitysketjun kevytasiakkaiden suorittamaa varmennusta suoraan – kustannusten vähentämiseksi. Ja se tarjoaa jokaiseen komponenttiin sisäänrakennettuja kannustimia, jotta dapp-kehittäjät voivat ansaita tai esittää loppukäyttäjille. MAP tukee EVM- ja ei-EVM-ketjuja – protokollakerros on isomorfinen kaikkien ketjujen kanssa.

Tulevaisuudessa MAP on infrastruktuuri kaikkien ketjujen takana ja muodostaa uuden pohjakerroksen. Kehittäjiä ei enää rajoita heidän valintaketjunsa, ja he voivat keskittyä itse dapp-tuotteeseen. Tulevaisuus on Omnichain, ja lisää modularisointia ja kannustimia ovat oikea tapa edetä.