Stručná historie cross-chain: vysvětlení devíti různých cross-chain řešení

Cross-chain řešení byla nejvíce diskutovaným tématem posledního roku. Se vzestupem veřejných řetězcových infrastruktur se objevil obrovský zájem o to, jak různé řetězce mluví a komunikují. Řešení byla navržena a implementována, ale žádné z nich neřeší zásadní problémy bez drastických kompromisů. Nyní zkoumáme různé cross-chain přístupy a prozradíme, proč a jak budou utvářet budoucnost cross-chain infrastruktury.

Nejprve si proberme, co je to cross-chain technologie a proč je potřeba. Důvod použití: řetězce jsou heterogenní a vyžadují vývojářům značný čas, aby sledovali rozdíly a problémy při přesunu aktiv. Mosty jsou méně bezpečné a nelze jim 100% důvěřovat, protože jsou obvykle ve vlastnictví projektových týmů blockchainu a jsou vysoce centralizované (nepořádné bez koordinace ze strany každého týmu). Cílem blockchainu vrstvy 1 je standardizace, ale segmentace řetězců vrstvy 1 vede k potřebě vrstvy infrastruktury napříč řetězci, která je dokonce pod vrstvami 1.

Aby bylo možné porozumět křížovým řešením a porovnat jejich rozdíly a atributy, musí být popsána a porovnána historie cross-chain mechanismů.

Ruční přenos

 
Úplně prvním cross-chain řešením je manuální převod majetku. Proces začíná tím, že uživatel převede aktiva do konkrétní peněženky v řetězci A a centralizovaná entita monitoruje převody peněženky a zaznamenává je v Excelu. Poté po určité době (obvykle pro účely monitorování) účetní jednotka po ověření připíše aktiva do řetězce B. Výhodou tohoto přístupu je snadná implementace, ale je náchylný k lidským chybám a má velmi nízkou záruku zabezpečení. V tomto přístupu také neexistuje žádná decentralizace.

Poloautomatický převod

Další iterace se zlepší tím, že uživatel převede aktiva do konkrétní peněženky a/nebo inteligentní smlouvy v řetězci A. Poté centralizovaný program monitoruje adresu pro převody. Takový program automaticky odesílá aktiva do řetězce B po ověření. Výhodou je stále snadná implementace bez přílišné složitosti nebo kódování a záznamy lze uchovávat v řetězci namísto lokálně. Nevýhodou je, že centralizovaný program může být chybný nebo nefunkční. Na centrálním úvěrovém účtu mohou také docházet prostředky. Záruka bezpečnosti je také nízká a nedochází k decentralizaci.

Centralizovaná burza

Když jednoduchá cross-chain řešení nejsou škálovatelná, centralizované burzy prosperují z cross-chain potřeb. Fungují tak, že uživatelé převedou aktiva do své centralizované burzy a poté pomocí „interního“ swapu burzy přemění „aktiva X“ v řetězci A na „aktiva Y“ v řetězci B prostřednictvím evidenčního účetnictví. Výhoda je zřejmá – je to nejjednodušší řešení – není potřeba žádné kódování a na burzách tier-1 je vysoká spolehlivost. Problém ale odhaluje opačnou nevýhodu – centralizované řízení toho, kdy je vklad/výběr dostupný. Centralizovaná burza poskytuje vysokou bezpečnost s nevýhodou nejmenší decentralizace.

Centralizovaný most

Další pokrok se zlepšuje tím, že máme samostatnou infrastrukturu pro převod aktiv napříč řetězci – most. Centralizovaný most funguje tak, že uživatel převede aktiva a poté pomocí převodové funkce mostu zahájí převod aktiv X v řetězci A do aktiv Y v řetězci B. Za proces je zodpovědný centralizovaný (nebo soubor) přepojovacího zařízení:

Zamkněte aktiva X na řetězu A
Ověřit si
Mint aktiva Y v řetězci B
Výhodou tohoto můstku je plně automatický proces bez jakéhokoli ručního přerušení. A nevýhodou je stále centralizované řízení, kdy je vklad/výběr dostupný. Most může být také nefunkční nebo hacknutý, což jej čas od času činí nefunkčním. Zabezpečení je tedy střední a stále zde není žádná decentralizace.

Decentralizovaný most s MPC

Další iterací je decentralizace ověřovacího modelu namísto centralizovaného mostu. Most MPC (Multi-Party Computation) začíná tím, že do něj uživatelé převedou aktiva. Pomocí přenosové funkce můstku zahájí převod aktiv X v řetězci A do aktiv Y v řetězci B. Obvykle je za proces odpovědná decentralizovaná sada přepojovacích zařízení:

Uzamkněte aktiva X na řetězu A pomocí MPC
Ověřte pomocí MPC
Mint aktiva Y v řetězci B pomocí MPC
Výhodou MPC je plně automatický proces bez jakéhokoli ručního přerušení a reléové uzly není třeba centralizovat. Nevýhodou jsou vysoké výpočetní a komunikační náklady MPC. Také uzly mohou být kompromitovány nebo tajně dohodnuty. Bezpečnost je střední, zatímco decentralizace je také střední.

Atomic Swap Bridge s HTLC

Další třída mostů vzniká v závislosti na technologii atomic swap (Lightning Network). Funguje to tak, že: uživatel převede aktiva do atomového swapovacího můstku a poté pomocí funkce přenosu můstku zahájí převod aktiv X v řetězci A do aktiv Y v řetězci B:

Vytvořte novou smlouvu HTLC – Hash Lock Timed Contract
Vložit aktiva X do smlouvy o řetězci A
Vygenerujte klíč hash lock + zašifrujte tajemství pro konečné stažení v čase T na řetězu B
Předložte zašifrované tajemství, abyste uzavřeli smlouvu s řetězcem B a stáhli aktiva Y
NEBO čas T uplynul a obnovte aktiva X ze smlouvy v řetězci A se zašifrovaným tajemstvím
Významnou výhodou je, že neexistuje žádný centralizovaný uzel/proces řídící přenos mostu. A nevýhoda je poměrně častá – vysoké náklady na nasazení HTLC a provozování HTLC hovorů. Vzhledem k nedůvěřivosti je udržování vysoké bezpečnosti a auditní stopy náročné. Bezpečnost tohoto přístupu je vysoká a decentralizace je také vysoká, vzhledem k výše uvedeným nevýhodám.

Cross-chain interoperabilita s Light Client + Oracle

Poté, co se přiblíží vysokonákladový most, se rodí další implementace, aby se tyto náklady snížily. Technologie Light client se stala nejnovější normou pro zjednodušení cross-chain ověřování. Postup je následující:

Nejprve uživatel převede aktiva X do smlouvy meziřetězového protokolu interoperability v řetězci A
Přenosová zpráva je nastavena na základě smlouvy a je vyzvednuta decentralizovanými přenosovými uzly
Uzly posílají důkazy ke smlouvě protokolu o řetězci B
Aktualizace hlaviček bloku (light client) jsou řešeny sítí Oracle, aby bylo zajištěno doručení a platnost
Uživatel stáhne aktiva Y ze smlouvy protokolu o řetězci B po validaci
Výhodou tohoto přístupu je, že od převodu až po dokončení není potřeba žádný zprostředkovatelský token ani řetězec. Po aktualizaci hlaviček bloků je možné okamžité potvrzení. Nevýhody jsou 1) rizika tajné dohody ze strany Oracle, 2) kvůli nedůvěře, udržování vysoké bezpečnosti a audit trail je náročný. Bezpečnost tohoto přístupu je střední, zatímco decentralizace je vysoká.

Cross-chain interoperabilita s Relay Chain

Na základě lekcí přístupu Oracle je také přítomno čistě reléové řešení. Postup je trochu jiný:

Uživatel převede aktiva X do smlouvy meziřetězcové interoperability protokolu o řetězci A
Přenosová zpráva je nastavena na základě smlouvy a je vyzvednuta decentralizovanými přenosovými uzly
Uzly posílají důkazy o smlouvě přenosového řetězce
Základní validátory přenosového řetězce zpracovávají aktualizace bloků, aby zajistily doručení a platnost
Po ověření předají přenosové uzly přenosovou zprávu do smlouvy protokolu v řetězci B
Uživatel odebere aktiva Y ze smlouvy protokolu o řetězci B
Výhodou tohoto přístupu oproti jednoduchému řešení Oracle jsou levnější poplatky od přenosových řetězců, které spotřebují většinu nákladů. Okamžité potvrzení je možné po aktualizaci bloků, což je klíčové pro řešení delších časů zpoždění. Problém je v tom, že samotný protokol nemusí podporovat ekosystém všech řetězců. Bezpečnost je vysoká (v rámci ekosystému) a vysoká je také decentralizace.

Cross-chain Infrastructure Layer s Light Client + Relay Chain

Řešení nové generace je zaměřeno na cross-chain infrastrukturní vrstvu řešící všechny základní problémy výše. Kombinuje technologii lehkého klienta s reléovým řetězcem, aby zahrnoval všechny řetězce:

Uživatel převede aktiva X do smlouvy o interoperabilitě meziřetězcové infrastruktury v řetězci A
Přenosová zpráva je nastavena na základě smlouvy a je vyzvednuta decentralizovanými přenosovými uzly
Uzly zasílají důkazy do smlouvy o interoperabilitě přenosového řetězce
Aktualizace hlavičky bloku (odlehčeného klienta) jsou řešeny decentralizovanými uzly správce, aby bylo zajištěno doručení a platnost
Po ověření předají přenosové uzly přenosovou zprávu do smlouvy o interoperabilitě v řetězci B
Uživatel stáhne aktiva Y ze smlouvy o interoperabilitě v řetězci B
Toto řešení zajišťuje interoperabilitu s velmi nízkými poplatky díky implementaci reléového řetězce. Poskytuje také okamžité potvrzení po aktualizaci záhlaví bloků. Největší výzvou je vysoká složitost optimalizace lehkých klientů na reléovém řetězci. Provedením dostatečného výzkumu a inženýrství by tyto optimalizace měly podporovat výhody, které ostatní nemohou vyřešit. Zabezpečení je velmi vysoké a decentralizace vysoká.

O protokolu MAP

Z cross-chain řešení jsme ještě neviděli řešení, které řeší všechny výše uvedené problémy. Dokud nebude implementován protokol MAP. Po 3 letech komplexního výzkumu a vývoje MAP Protocol konečně dosáhl vrstvy Omnichain s technologií Light Client + Relay Chain bez kompromisů. MAP implementoval principy Omnichainu s následujícími vlastnostmi:

Vývojář připraven
Pokrytí všech řetězců
Minimální náklady
Finalita zabezpečení
Okamžité potvrzení

Protokol MAP je vrstva infrastruktury pro podporu budování mostů, DEXů, protokolů interoperability a dalších. Podporuje ověřování lehkými klienty přímo v řetězci MAP relay – pro snížení nákladů. A poskytuje pobídky zabudované do každé komponenty pro vývojáře dapp, které mohou vydělávat nebo prezentovat koncovým uživatelům. MAP podporuje EVM a non-EVM řetězce – protokolová vrstva je izomorfní se všemi řetězci.

Pro budoucnost je MAP infrastrukturou všech řetězců, které budou novou základní vrstvou. Vývojáři již nejsou omezováni svým řetězcem výběru a mohou se soustředit na samotný produkt dapp. Budoucnost je Omnichain a cestou je další modularizace a pobídky.