A keresztlánc rövid története: Kilenc különböző keresztlánc-megoldás magyarázata

A cross-chain megoldások voltak a legtöbbet emlegetett téma az elmúlt évben. A nyilvános láncinfrastruktúrák térnyerésével hatalmas érdeklődés mutatkozott az iránt, hogy a különböző láncok hogyan beszélnek és kommunikálnak. Megoldásokat javasoltak és megvalósítottak, de egyik sem oldja meg az alapvető problémákat drasztikus kompromisszumok nélkül. Most megvizsgáljuk a különböző láncokon átívelő megközelítéseket, és eláruljuk, miért és hogyan alakítják ezek a láncokon átívelő infrastruktúra jövőjét.

Először is beszéljük meg, mi az a cross-chain technológia, és miért van rá szükség. A használat oka: a láncok heterogének, és a fejlesztőknek jelentős időre van szükségük ahhoz, hogy nyomon kövessék a különbségeket és a kihívásokat az eszközök áthelyezése során. A hidak kevésbé biztonságosak, és nem lehet bennük 100%-ban megbízni, mert általában a blokklánc projektcsapatok tulajdonában vannak, és nagymértékben centralizáltak (zavaros, minden csapattól nincs koordináció). Az 1. réteg blokkláncának célja a szabványosítás, de az 1. rétegű láncok szegmentálása olyan cross-chain infrastruktúra réteg szükségességét eredményezi, amely még az 1. rétegek alatt is található.

A keresztlánc-mechanizmusok történetét fel kell vázolni és össze kell hasonlítani, hogy megértsük a keresztlánc-megoldásokat, összehasonlíthassuk azok különbségeit és tulajdonságait.

Kézi átvitel

 
A legelső cross-chain megoldás az eszközök kézi átadása. A folyamat azzal kezdődik, hogy a felhasználó átviszi az eszközöket egy adott pénztárcába az A láncban, és egy központosított entitás figyeli a pénztárcát az átvitelek szempontjából, és rögzíti azokat Excelben. Ezután egy véges idő elteltével (általában megfigyelési célból) az entitás ellenőrzés után jóváírja az eszközöket a B láncon. Ennek a megközelítésnek az előnye a könnyű kivitelezés, de hajlamos az emberi hibákra, és nagyon alacsony biztonsági garanciával rendelkezik. Ebben a megközelítésben szintén nincs decentralizáció.

Félautomata átvitel

A következő iteráció úgy javul, hogy a felhasználó átviheti az eszközöket egy adott pénztárcába és/vagy intelligens szerződésbe az A láncon. Ezután egy központosított program figyeli a címet az átvitelhez. Egy ilyen program ellenőrzéskor automatikusan elküldi az eszközöket a B láncba. A pozitív oldal továbbra is a könnyű implementáció, túl sok bonyolultság és kódolás nélkül, és a rekordok a lokális helyett a láncon tárolhatók. Hátránya, hogy a központosított program hibás vagy hibás lehet. A központi hitelszámlán is elfogyhat a pénz. A biztonsági garancia is alacsony, nincs decentralizáció.

Központosított tőzsde

Ha az egyszerű keresztlánc-megoldások nem skálázhatók, a központosított cserék boldogulnak a láncok közötti igények kielégítésével. Úgy működnek, hogy a felhasználók átviszik az eszközöket a központosított tőzsdére, majd a tőzsde „belső” csereügyletével az „A” lánc „X eszközeit” a „B” lánc „Y eszközeivé” alakítják a nyilvántartási elszámolással. Az előny nyilvánvaló – ez a legkönnyebben használható megoldás – nincs szükség kódolásra, és a Tier-1 cserék nagy megbízhatósággal rendelkeznek. A probléma azonban az ellenkező hátrányt fedi fel – a befizetés/kivonás lehetőségének központosított ellenőrzését. A központosított csere nagy biztonságot ad a legkisebb decentralizáció hátrányával.

Központi híd

A következő előrelépés azáltal javul, hogy külön infrastruktúrával rendelkezik az eszközök láncok közötti átviteléhez – egy híd. A központosított híd úgy működik, hogy a felhasználó átadja az eszközöket, majd a híd átviteli funkciójával kezdeményezi az A láncban lévő X eszközök átvitelét a B láncon lévő Y eszközökbe. A folyamatért egy központosított (vagy egy közvetítő) felelős:

Zárja be az X eszközöket az A láncon
Ellenőrzése
Y pénzverde a B láncon
Ennek a hídnak az előnye a teljesen automatikus folyamat, manuális megszakítás nélkül. A hátránya pedig továbbra is a központosított ellenőrzés, hogy mikor lehetséges a befizetés/kivétel. Ezenkívül előfordulhat, hogy a híd leállt vagy feltörik, ami időről időre működésképtelenné teszi. A biztonság tehát közepes, decentralizáció továbbra sincs.

Decentralizált híd MPC-vel

A következő iteráció a hitelesítési modell decentralizálása a központosított híd helyett. Az MPC (Multi-Party Computation) híd azzal kezdődik, hogy a felhasználók átviszik rá az eszközöket. A híd átviteli funkcióját használva kezdeményezi az A láncon lévő X eszközök átvitelét a B láncon lévő Y eszközökbe. Általában egy decentralizált közvetítőcsoport felelős a folyamatért:

Zárolja az X eszközöket az A láncon az MPC segítségével
Ellenőrizze az MPC-vel
Y eszközöket ver a B láncon MPC segítségével
Az MPC előnye a teljesen automatikus folyamat manuális megszakítás nélkül, és a relé csomópontokat nem kell központosítani. Hátránya az MPC magas számítási és kommunikációs költsége. Ezenkívül a csomópontok kompromittálhatók vagy összejátszhatók. A biztonság közepes, de a decentralizáció is közepes.

Atomic Swap Bridge HTLC-vel

A hidak egy másik osztálya az atomcsere (Lightning Network) technológiától függ. Ez a következőképpen működik: a felhasználó áthelyezi az eszközöket egy atomcsere hídba, majd a híd átviteli funkciójával kezdeményezi az A láncban lévő X eszközök átvitelét a B láncon lévő Y eszközökbe:

Hozzon létre egy új HTLC – Hash Lock időzített szerződést
Az X eszközöket helyezze be az A láncra vonatkozó szerződésbe
Hash zárkulcs létrehozása + titkos titkosítás a végső visszavonáshoz T időn belül a B láncon
Mutasson be titkosított titkot, hogy szerződést köthessen a B lánccal az Y eszközök visszavonására
VAGY T idő lejárt, és állítsa vissza az X eszközöket az A láncban lévő szerződésből a titkosított titokkal
Jelentős előnye, hogy nincs központosított csomópont/folyamat, amely a hídátvitelt vezérli. A hátrány pedig viszonylag gyakori – a HTLC telepítésének és a HTLC-hívások futtatásának magas költsége. A bizalmatlanság miatt kihívást jelent a magas szintű biztonság fenntartása és az ellenőrzési nyomvonal. Ennek a megközelítésnek a biztonsága magas, és a decentralizáció is magas a fenti hátrányok miatt.

Láncokon átívelő együttműködés a Light Client + Oracle szolgáltatással

A magas költségű híd megközelítések után újabb megvalósítások születnek a költségek csökkentésére. A könnyű kliens technológia a legújabb normává vált a láncok közötti ellenőrzések egyszerűsítésére. A folyamat a következő:

Először a felhasználó az X eszközöket egy láncok közötti interoperabilitási protokoll szerződésébe helyezi át az A láncon
Az átviteli üzenet a szerződésben van beállítva, és a decentralizált közvetítő csomópontok veszik fel
A csomópontok bizonyítékokat küldenek a B láncon lévő protokoll szerződésére
A blokkfejléc (könnyű kliens) frissítéseit az Oracle hálózat kezeli a kézbesítés és az érvényesség biztosítása érdekében
A felhasználó érvényesítéskor visszavonja az Y eszközöket a protokoll B láncon kötött szerződéséből
Ennek a megközelítésnek az előnye, hogy nincs szükség közvetítő tokenre vagy láncra az átviteltől a befejezésig. Azonnali megerősítés lehetséges a blokkfejlécek frissítése után. A hátrányok a következők: 1) az Oracle-től származó összejátszás kockázata, 2) a bizalmatlanság, a magas szintű biztonság fenntartása, és az ellenőrzési nyomvonal kihívást jelent. Ennek a megközelítésnek a biztonsága közepes, míg a decentralizáció magas.

Láncok közötti interoperabilitás a relélánccal

Az Oracle megközelítés tanulságai alapján egy tiszta közvetítőláncos megoldás is jelen van. A folyamat kissé eltér:

A felhasználó átviszi az X eszközöket a láncok közötti interoperabilitási protokoll szerződésébe az A láncon
Az átviteli üzenet a szerződésben van beállítva, és a decentralizált közvetítő csomópontok veszik fel
A csomópontok bizonyítékokat küldenek a közvetítőlánc szerződéséhez
A mögöttes közvetítőlánc-ellenőrzők kezelik a blokkfrissítéseket a kézbesítés és az érvényesség biztosítása érdekében
Az érvényesítés után a közvetítő csomópontok továbbítják az átviteli üzenetet a protokoll B láncon lévő szerződéséhez
A felhasználó visszavonja az Y eszközöket a protokoll B láncon kötött szerződéséből
Ennek a megközelítésnek az előnye az egyszerű Oracle megoldással szemben a reléláncok olcsóbb díjai, amelyek a költségek nagy részét felemésztik. Azonnali megerősítés lehetséges a blokkok frissítése után, ami elengedhetetlen a hosszabb késleltetési idők megoldásához. A probléma az, hogy maga a protokoll nem támogatja a teljes láncú ökoszisztémát. Magas a biztonság (az ökoszisztémán belül), és a decentralizáció is magas.

Keresztláncú infrastruktúra réteg Light Client + Relé lánccal

A következő generációs megoldás a cross-chain infrastruktúra rétegre összpontosít, amely megoldja az összes fenti alapvető problémát. Egyesíti a könnyű kliens technológiát egy relélánccal, hogy az összes láncot magába foglalja:

A felhasználó átadja az X eszközöket a láncok közötti infrastruktúra réteg interoperabilitási szerződésébe az A láncon
Az átviteli üzenet a szerződésben van beállítva, és a decentralizált közvetítő csomópontok veszik fel
A csomópontok bizonyítékokat küldenek a közvetítőlánc együttműködési szerződéséhez
A blokkfejléc (könnyű kliens) frissítéseit decentralizált karbantartó csomópontok kezelik a kézbesítés és az érvényesség biztosítása érdekében
Érvényesítéskor a közvetítő csomópontok továbbítják az üzenetet a B láncon lévő együttműködési szerződéshez
A felhasználó kivonja az Y eszközöket a B lánc interoperabilitási szerződéséből
Ez a megoldás nagyon olcsó díjakkal biztosítja az interoperabilitást a közvetítőlánc megvalósításának köszönhetően. A blokkfejlécek frissítése után azonnali megerősítést is ad. A legnagyobb kihívást a közvetítőláncon belüli könnyű kliensek optimalizálásának bonyolultsága jelenti. Elegendő kutatás és tervezés elvégzésével ezeknek az optimalizálásoknak támogatniuk kell azokat az előnyöket, amelyeket a többiek nem tudnak megoldani. A biztonság nagyon magas, a decentralizáció pedig magas.

A MAP protokollról

A keresztlánc-megoldások közül még nem láttunk olyat, amelyik minden fenti problémát megoldana. A MAP Protokoll megvalósításáig. 3 év komplex kutatás és fejlesztés után a MAP Protocol végre kompromisszumok nélkül elérte az Omnichain réteget könnyű kliens + relélánc technológiával. A MAP az Omnichain elveket a következő tulajdonságokkal valósította meg:

Fejlesztő kész
Teljes lánc lefedettség
Minimális költség
Biztonsági véglegesség
Azonnali megerősítés

A MAP Protocol az infrastruktúra réteg, amely támogatja a hidak építését, a DEX-eket, az interoperabilitási protokollokat és egyebeket. Támogatja a könnyű kliensek általi ellenőrzést közvetlenül a MAP reléláncon – a költségek csökkentése érdekében. És minden egyes összetevőbe beépített ösztönzőket biztosít a dapp fejlesztők számára, hogy megszerezzék vagy bemutathassák a végfelhasználóknak. A MAP támogatja az EVM és nem EVM láncokat – a protokollréteg minden lánccal izomorf.

A jövőben a MAP az infrastruktúra az összes lánc mögött, amely az új alapréteg lesz. A fejlesztőket már nem korlátozza a választási lánc, és magára a dapp termékre összpontosíthatnak. A jövő az Omnichain, és a további modularizáció és ösztönzés a járható út.