En kort historie om krysskjede: Forklaring av ni forskjellige løsninger for krysskjeder

Tverrkjedeløsninger har vært det mest omtalte temaet det siste året. Med fremveksten av offentlig kjedeinfrastruktur har det vært en massiv interesse for hvordan ulike kjeder snakker og kommuniserer. Løsninger har blitt foreslått og implementert, men ingen av dem løser de grunnleggende problemene uten drastiske avveininger. Nå undersøker vi de forskjellige tilnærmingene på tvers av kjeder og røper hvorfor og hvordan de vil forme fremtiden til infrastruktur på tvers av kjeder.

La oss først diskutere hva tverrkjedeteknologi er og hvorfor det er nødvendig. Årsak til bruk: kjeder er heterogene og krever mye tid for utviklere å holde styr på forskjellene og utfordringene når de flytter eiendeler. Broer er mindre sikre og kan ikke stoles 100 % på fordi de vanligvis eies av blockchain-prosjektteamene og er svært sentraliserte (rotete uten koordinering fra hvert lag). Målet med lag-1 blokkjede er å standardisere, men segmenteringen av lag-1-kjeder fører til behovet for et infrastrukturlag på tvers av kjeder som er til og med under lag-1-ene.

Historien til tverrkjedemekanismer må legges ut og sammenlignes for å forstå tverrkjedeløsningene og sammenligne deres forskjeller og egenskaper.

Manuell overføring

 
Den aller første krysskjedeløsningen er en manuell overføring av eiendeler. Prosessen starter med at brukeren overfører eiendeler til en spesifikk lommebok i kjede A, og en sentralisert enhet overvåker lommeboken for overføringer og registrerer dem i Excel. Etter en begrenset tid (vanligvis for overvåkingsformål), krediterer enheten eiendeler til kjede B ved verifisering. Fordelen med denne tilnærmingen er den enkle implementeringen, men den er utsatt for menneskelige feil og har en veldig lav sikkerhet. Det er heller ingen desentralisering i denne tilnærmingen.

Halvautomatisk overføring

Den neste iterasjonen forbedres ved at brukeren overfører eiendeler til en spesifikk lommebok og/eller smart kontrakt på kjede A. Deretter overvåker et sentralisert program adressen for overføringer. Et slikt program sender automatisk eiendeler til kjede B ved verifisering. Oppsiden er fortsatt enkel implementering uten for mye kompleksitet eller koding, og postene kan holdes på kjeden i stedet for lokalt. Ulempen er at det sentraliserte programmet kan være buggy eller feil. Den sentrale kredittkontoen kan også gå tom for midler. Sikkerhetsgarantien er også lav, og det er ingen desentralisering.

Sentralisert utveksling

Når de enkle tverrkjedeløsningene ikke er skalerbare, trives sentraliserte utvekslinger på krysskjedebehovene. De fungerer ved å få brukere til å overføre eiendeler til sin sentraliserte børs og deretter, ved å bruke børsens "interne" bytte, gjøre om "aktiva X" på kjede A til "aktiva Y" på kjede B gjennom postregnskap. Fordelen er åpenbar – det er den enkleste løsningen å bruke – ingen koding er nødvendig, og det er høy pålitelighet på tier-1-børser. Men problemet avslører den motsatte ulempen – sentralisert kontroll over når innskudd/uttak er tilgjengelig. Den sentraliserte sentralen gir høy sikkerhet med ulempen av minst desentralisering.

Sentralisert bro

Det neste fremskrittet forbedres ved å ha en egen infrastruktur for overføring av eiendeler på tvers av kjeder – en bro. En sentralisert bro fungerer ved at brukeren overfører eiendeler, og deretter bruker broens overføringsfunksjon, starter overføring av eiendeler X på kjede A til eiendeler Y på kjede B. En sentralisert (eller et sett med) reléer er ansvarlig for prosessen:

Lås eiendeler X på kjede A
Bekreft
Myntaktiva Y på kjede B
Fordelen med denne broen er den helautomatiske prosessen uten manuelle avbrudd. Og ulempen er fortsatt sentralisert kontroll av når innskudd/uttak er tilgjengelig. Broen kan også være nede eller hacket, noe som gjør den ufunksjonell fra tid til annen. Så sikkerheten er middels, og det er fortsatt ingen desentralisering.

Desentralisert bro med MPC

Den neste iterasjonen er å desentralisere verifikasjonsmodellen i stedet for en sentralisert bro. En MPC (Multi-Party Computation)-bro starter med at brukere overfører eiendeler til den. Ved å bruke broens overføringsfunksjon, starter den overføring av eiendeler X på kjede A til eiendeler Y på kjede B. Det er vanligvis et desentralisert sett med reléer som er ansvarlig for prosessen:

Lås eiendeler X på kjede A ved hjelp av MPC
Bekreft med MPC
Mint aktiva Y på kjede B ved bruk av MPC
Oppsiden av MPC er den helautomatiske prosessen uten manuelle avbrudd, og relénodene trenger ikke å sentraliseres. Ulempen er de høye beregnings- og kommunikasjonskostnadene til MPC. Nodene kan også være kompromittert eller sammenkoblet. Sikkerhet er middels, mens desentralisering også er middels.

Atomic Swap Bridge med HTLC

En annen klasse av broer oppstår avhengig av atomic swap (Lightning Network) teknologi. Det fungerer ved at: brukeren overfører eiendeler til en atombyttebro og deretter bruker broens overføringsfunksjon, starter overføring av eiendeler X på kjede A til eiendeler Y på kjede B:

Opprett en ny HTLC – Hash Lock Timed Contract
Sett eiendeler X inn i kontrakt på kjede A
Generer hash-låsnøkkel + krypter en hemmelighet for endelig uttak innen tid T på kjede B
Presenter kryptert hemmelighet for kontrakt på kjede B for å trekke ut eiendeler Y
ELLER tiden T har gått, og gjenopprett eiendeler X fra kontrakten på kjede A med den krypterte hemmeligheten
Den betydelige fordelen er at det ikke er noen sentralisert node/prosess som kontrollerer brooverføringen. Og ulempen er relativt vanlig – en høy kostnad ved å distribuere HTLC og kjøre HTLC-anrop. På grunn av tillitsløshet er det utfordrende å opprettholde høy sikkerhet og revisjonssporet. Sikkerheten til denne tilnærmingen er høy, og desentraliseringen er også høy, gitt de ovennevnte ulempene.

Interoperabilitet på tvers av kjeder med Light Client + Oracle

Etter at høykostnadsbroen nærmer seg, blir flere implementeringer født for å redusere denne kostnaden. Lett klientteknologi har blitt den siste normen for å forenkle verifikasjoner på tvers av kjeder. Prosessen er som følger:

Først overfører brukeren eiendeler X inn i en interoperabilitetsprotokoll på tvers av kjeder på kjede A
En overføringsmelding er satt på kontrakt og blir plukket opp av desentraliserte relénoder
Noder sender bevis over til protokollens kontrakt på kjede B
Blokkhodeoppdateringer (lett klient) håndteres av Oracle-nettverket for å sikre levering og gyldighet
Brukeren trekker aktiva Y fra protokollens kontrakt på kjede B ved validering
Fordelen med denne tilnærmingen er at ingen mellomledd token eller kjede er nødvendig fra overføringen til fullføringen. Umiddelbar bekreftelse er mulig etter at blokkoverskrifter er oppdatert. Ulempene er 1) samarbeidsrisiko fra Oracles, 2) på grunn av tillitsløshet, opprettholdelse av høy sikkerhet, og revisjonssporet er utfordrende. Sikkerheten til denne tilnærmingen er middels, mens desentraliseringen er høy.

Interoperabilitet på tvers av kjeder med relékjede

Etter lærdommen fra Oracle-tilnærmingen, er også en ren relékjedeløsning til stede. Prosessen er litt annerledes:

Brukeren overfører eiendeler X til en interoperabilitetsprotokoll på tvers av kjeder på kjede A
En overføringsmelding er satt på kontrakt og blir plukket opp av desentraliserte relénoder
Noder sender bevis til stafettkjedens kontrakt
Underliggende relékjedevalidatorer håndterer blokkoppdateringer for å sikre levering og gyldighet
Ved validering videresender relénoder overføringsmeldingen til protokollens kontrakt på kjede B
Brukeren trekker aktiva Y fra protokollens kontrakt på kjede B
Fordelen med denne tilnærmingen fremfor den enkle Oracle-løsningen er de billigere gebyrene fra relékjeder som bruker mesteparten av kostnadene. Umiddelbar bekreftelse er mulig etter at blokker er oppdatert, noe som er avgjørende for å løse lengre forsinkelsestider. Problemet er at selve protokollen kanskje ikke støtter et økosystem med hele kjeder. Sikkerheten er høy (innenfor økosystemet), og desentraliseringen er også høy.

Infrastrukturlag på tvers av kjeder med lett klient + relékjede

Neste generasjons løsning er fokusert på infrastrukturlaget på tvers av kjeder som løser alle de grunnleggende problemene ovenfor. Den kombinerer den lette klientteknologien med en relékjede for å inkludere alle kjeder:

Brukeren overfører eiendeler X til et krysskjedeinfrastrukturlags interoperabilitetskontrakt på kjede A
En overføringsmelding er satt på kontrakt og blir plukket opp av desentraliserte relénoder
Noder sender bevis til relékjedens interoperabilitetskontrakt
Blokkhodeoppdateringer (lett klient) håndteres av desentraliserte vedlikeholdsnoder for å sikre levering og gyldighet
Ved validering videresender relénoder overføringsmelding til interoperabilitetskontrakt på kjede B
Brukeren trekker aktiva Y fra interoperabilitetskontrakten i kjede B
Denne løsningen sikrer interoperabilitet med svært billige avgifter på grunn av en relékjedeimplementering. Det gir også en umiddelbar bekreftelse etter at blokkhodene er oppdatert. Den største utfordringen er den høye kompleksiteten ved å optimalisere lette klienter på relékjeden. Ved å utføre nok forskning og engineering, bør disse optimaliseringene støtte fordelene de andre ikke kan løse. Sikkerheten er veldig høy, og desentraliseringen er høy.

Om MAP-protokollen

Ut av tverrkjedeløsningene har vi ennå ikke sett en som løser alle problemene ovenfor. Inntil MAP-protokollen er implementert. Etter 3 år med kompleks forskning og utvikling, har MAP Protocol endelig oppnådd Omnichain-laget med lett Client + relékjedeteknologi uten kompromisser. MAP har implementert Omnichain-prinsippene med følgende egenskaper:

Klar for utvikler
Alle kjeder dekning
Minimumskostnad
Sikkerhetsavslutning
Øyeblikkelig bekreftelse

MAP Protocol er infrastrukturlaget for å støtte bygging av broer, DEX-er, interoperabilitetsprotokoller og mer. Den støtter verifisering av lette klienter på MAP-relékjeden direkte – for å redusere kostnadene. Og det gir insentiver innebygd i hver komponent for dapp-utviklere å tjene eller presentere for sluttbrukere. MAP støtter EVM- og ikke-EVM-kjeder - protokolllaget er isomorft med alle kjeder.

For fremtiden er MAP infrastrukturen bak alle kjeder som blir det nye basislaget. Utviklere er ikke lenger begrenset av valgkjeden og kan fokusere på selve dapp-produktet. Fremtiden er Omnichain, og mer modularisering og incentivisering er veien å gå.