En kort historie om cross-chain: Forklaring af ni forskellige cross-chain-løsninger

Tværkædeløsninger har været det mest omtalte emne i det seneste år. Med fremkomsten af ​​offentlige kædeinfrastrukturer har der været massiv interesse for, hvordan forskellige kæder taler og kommunikerer. Løsninger er blevet foreslået og implementeret, men ingen af ​​dem løser de grundlæggende problemer uden drastiske afvejninger. Nu undersøger vi de forskellige cross-chain tilgange og afslører hvorfor og hvordan de vil forme fremtiden for cross-chain infrastruktur.

Lad os først diskutere, hvad cross-chain teknologi er, og hvorfor det er nødvendigt. Årsag til brug: Kæder er heterogene og kræver, at udviklere har lang tid til at holde styr på forskellene og udfordringerne, når de flytter aktiver på tværs. Broer er mindre sikre og kan ikke stoles 100 % på, fordi de normalt ejes af blockchain-projektholdene og meget centraliserede (rodet uden koordinering fra hvert hold). Målet med lag-1 blockchain er at standardisere, men segmenteringen af ​​lag-1-kæder fører til behovet for et tværkædet infrastrukturlag, der endda er under lag-1'erne.

Historien om tværkædede mekanismer skal udlægges og sammenlignes for at forstå de tværkædede løsninger og sammenligne deres forskelle og egenskaber.

Manuel overførsel

 
Den allerførste cross-chain løsning er en manuel overførsel af aktiver. Processen starter med, at brugeren overfører aktiver til en specifik tegnebog i kæde A, og en centraliseret enhed overvåger tegnebogen for overførsler og registrerer dem i Excel. Derefter efter et begrænset tidsrum (normalt til overvågningsformål), krediterer enheden aktiver på kæde B efter verifikation. Fordelen ved denne tilgang er den lette implementering, men den er tilbøjelig til menneskelige fejl og har en meget lav sikkerhedsgaranti. Der er heller ingen decentralisering i denne tilgang.

Halvautomatisk overførsel

Den næste iteration forbedres ved at få brugeren til at overføre aktiver til en specifik tegnebog og/eller smart kontrakt på kæde A. Derefter overvåger et centraliseret program adressen for overførsler. Et sådant program sender automatisk aktiver til kæde B ved verificering. Fordelen er stadig den lette implementering uden for meget kompleksitet eller kodning, og registreringerne kan holdes på kæden i stedet for lokalt. Ulempen er, at det centraliserede program kan være buggy eller funktionsfejl. Den centrale kreditkonto kan også løbe tør for midler. Sikkerhedsgarantien er også lav, og der er ingen decentralisering.

Centraliseret udveksling

Når de simple cross-chain-løsninger ikke er skalerbare, trives centraliserede udvekslinger på tværs af kæde-behovene. De fungerer ved at få brugere til at overføre aktiver til deres centraliserede børs og derefter, ved hjælp af børsens "interne" swap, omdanne "aktiver X" på kæde A til "aktiver Y" på kæde B gennem registreringsregnskab. Fordelen er indlysende – det er den nemmeste løsning at bruge – ingen kodning er nødvendig, og der er høj pålidelighed på tier-1-udvekslinger. Men problemet afslører den modsatte ulempe – centraliseret kontrol af, hvornår indbetaling/udbetaling er tilgængelig. Den centraliserede udveksling giver høj sikkerhed med bagsiden af ​​den mindste decentralisering.

Centraliseret bro

Det næste fremskridt forbedres ved at have en separat infrastruktur til at overføre aktiver på tværs af kæder - en bro. En centraliseret bro fungerer ved, at brugeren overfører aktiver og derefter bruger broens overførselsfunktion, starter overførsel af aktiver X på kæde A til aktiver Y på kæde B. En centraliseret (eller et sæt af) relæer er ansvarlig for processen:

Lås aktiver X på kæde A
Bekræft
Møntaktiver Y på kæde B
Fordelen ved denne bro er den fuldautomatiske proces uden nogen manuel afbrydelse. Og ulempen er stadig den centraliserede kontrol af, hvornår indbetaling/udbetaling er tilgængelig. Broen kan også være nede eller hacket, hvilket gør den ufunktionel fra tid til anden. Så sikkerheden er medium, og der er stadig ingen decentralisering.

Decentral bro med MPC

Den næste iteration er at decentralisere verifikationsmodellen i stedet for en centraliseret bro. En MPC (Multi-Party Computation)-bro starter med, at brugere overfører aktiver til den. Ved at bruge broens overførselsfunktion initierer den overførsel af aktiver X på kæde A til aktiver Y på kæde B. Der er normalt et decentraliseret sæt relæer, der er ansvarlige for processen:

Lås aktiver X på kæde A ved hjælp af MPC
Bekræft ved hjælp af MPC
Mint aktiver Y på kæde B ved hjælp af MPC
Fordelen ved MPC er den fuldautomatiske proces uden nogen manuel afbrydelse, og relæknuderne behøver ikke at være centraliserede. Ulempen er de høje beregnings- og kommunikationsomkostninger ved MPC. Også knudepunkterne kan være kompromitteret eller indgået i et samarbejde. Sikkerhed er medium, mens decentralisering også er medium.

Atomic Swap Bridge med HTLC

En anden klasse af broer opstår afhængigt af atomic swap (Lightning Network) teknologi. Det fungerer ved at: brugeren overfører aktiver til en atomar swap-bro og derefter ved hjælp af broens overførselsfunktion starter overførsel af aktiver X på kæde A til aktiver Y på kæde B:

Opret en ny HTLC – Hash Lock Timed Contract
Deponer aktiver X i kontrakt på kæde A
Generer hash-låsnøgle + krypter en hemmelighed til endelig tilbagetrækning inden for tid T på kæde B
Præsenter krypteret hemmelighed til kontrakt på kæde B for at trække aktiver Y tilbage
ELLER tiden T er gået, og gendan aktiver X fra kontrakten på kæde A med den krypterede hemmelighed
Den væsentlige fordel er, at der ikke er nogen centraliseret node/proces, der styrer brooverførslen. Og ulempen er relativt almindelig - en høj omkostning ved at implementere HTLC og køre HTLC-opkald. På grund af tillidsløshed er det udfordrende at opretholde høj sikkerhed og revisionssporet. Sikkerheden ved denne tilgang er høj, og decentraliseringen er også høj, givet ovenstående ulemper.

Interoperabilitet på tværs af kæder med Light Client + Oracle

Efter de høje omkostninger bro tilgange, er flere implementeringer født for at reducere disse omkostninger. Let klientteknologi er blevet den seneste norm til at forenkle kontrol på tværs af kæder. Processen er som følger:

For det første overfører brugeren aktiver X til en interoperabilitetsprotokols kontrakt på tværs af kæder på kæde A
En overførselsmeddelelse er sat på kontrakt og bliver opfanget af decentrale relayer noder
Noder sender beviser over til protokollens kontrakt på kæde B
Blokheader-opdateringer (let klient) håndteres af Oracle-netværket for at sikre levering og gyldighed
Brugeren trækker aktiver Y fra protokollens kontrakt på kæde B efter validering
Fordelen ved denne tilgang er, at der ikke kræves nogen mellemliggende token eller kæde fra overførslen til færdiggørelsen. Øjeblikkelig bekræftelse er mulig efter opdatering af blokoverskrifter. Ulemperne er 1) samordningsrisici fra Oracles, 2) på grund af tillidsløshed, opretholdelse af høj sikkerhed, og revisionssporet er udfordrende. Sikkerheden ved denne tilgang er middel, mens decentraliseringen er høj.

Interoperabilitet på tværs af kæder med relækæde

Ud fra erfaringerne fra Oracle-tilgangen er der også en ren relækædeløsning til stede. Processen er lidt anderledes:

Brugeren overfører aktiver X til en interoperabilitetsprotokols kontrakt på tværs af kæder på kæde A
En overførselsmeddelelse er sat på kontrakt og bliver opfanget af decentrale relayer noder
Noder sender beviser til relækædens kontrakt
Underliggende relækædevalidatorer håndterer blokopdateringer for at sikre levering og gyldighed
Efter validering videresender relayer noder overførselsmeddelelsen til protokollens kontrakt på kæde B
Brugeren trækker aktiver Y fra protokollens kontrakt på kæde B
Fordelen ved denne tilgang i forhold til den simple Oracle-løsning er de billigere gebyrer fra relækæder, som optager størstedelen af ​​omkostningerne. Øjeblikkelig bekræftelse er mulig, efter at blokke er opdateret, hvilket er afgørende for at løse længere forsinkelsestider. Problemet er, at selve protokollen muligvis ikke understøtter et økosystem med alle kæder. Sikkerheden er høj (inden for økosystemet), og decentraliseringen er også høj.

Infrastrukturlag på tværs af kæder med let klient + relækæde

Næste generations løsning er fokuseret på det tværkædede infrastrukturlag, der løser alle de grundlæggende problemer ovenfor. Den kombinerer den lette klientteknologi med en relækæde for at inkorporere alle kæder:

Brugeren overfører aktiver X til et tværkædet infrastrukturlags interoperabilitetskontrakt på kæde A
En overførselsmeddelelse er sat på kontrakt og bliver opfanget af decentrale relayer noder
Noder sender beviser til relækædens interoperabilitetskontrakt
Opdateringer af blokheader (let klient) håndteres af decentraliserede vedligeholdelsesknuder for at sikre levering og gyldighed
Efter validering videresender relayer noder overførselsmeddelelse til interoperabilitetskontrakt på kæde B
Brugeren trækker aktiver Y tilbage fra interoperabilitetskontrakten i kæde B
Denne løsning sikrer interoperabilitet med meget billige gebyrer på grund af en relækædeimplementering. Det giver også en øjeblikkelig bekræftelse efter opdatering af blokoverskrifter. Den største udfordring er den høje kompleksitet i at optimere lysklienter på relækæden. Ved at udføre tilstrækkelig forskning og ingeniørarbejde bør disse optimeringer understøtte de fordele, de andre ikke kan løse. Sikkerheden er meget høj, og decentraliseringen er høj.

Om MAP-protokollen

Ud af de tværkædede løsninger har vi endnu ikke set en, der løser alle ovenstående problemer. Indtil MAP-protokollen er implementeret. Efter 3 års kompleks forskning og udvikling har MAP Protocol endelig opnået Omnichain-laget med let Client + relækædeteknologi uden kompromis. MAP har implementeret Omnichain-principperne med følgende egenskaber:

Udvikler klar
All-Chain dækning
Minimumsomkostninger
Endelig sikkerhed
Øjeblikkelig bekræftelse

MAP Protocol er infrastrukturlaget til at understøtte bygning af broer, DEX'er, interoperabilitetsprotokoller og mere. Det understøtter verifikation af lette klienter på MAP-relækæden direkte - for at reducere omkostningerne. Og det giver incitamenter indbygget i hver komponent, som dapp-udviklere kan tjene eller præsentere for slutbrugere. MAP understøtter EVM- og ikke-EVM-kæder - protokollaget er isomorft med alle kæder.

For fremtiden er MAP infrastrukturen bag alle kæder, der bliver det nye basislag. Udviklere er ikke længere begrænset af deres valgkæde og kan fokusere på selve dapp-produktet. Fremtiden er Omnichain, og mere modularisering og incitamenter er vejen at gå.