Autor: MIDDLE.X

Původní název: "Paka Labs cross-chain research report (3/4) | Spojování izolovaných ostrovů do kontinentů: Interpretace 20 cross-chain mostů a 4 cross-chain technologických paradigmat"

Cross-chain bridge jsou obecně shrnuty do tří technických paradigmat, a to light client cross-chain, externí svědek cross-chain a atomic swap na základě hash time lock. Podle indukce Arjuna Bhuptaniho lze tato tři technická paradigmata také nazývat nativní ověření, externí ověření a místní ověření.

Téměř všechny nejpopulárnější zkřížené můstky v současnosti na trhu (jako je LayerZero, Multichain, Axelar a Hyperlane) jsou můstky externích svědků.

Přestože externí svědci mají lepší kompatibilitu napříč řetězovými mosty, lze je poměrně snadno rozšířit na více blockchainů. Ale nevyhnutelně zavádí nové předpoklady důvěry. Uživatelé musí důvěřovat sadě externích svědků, že nepáchají zlo. Naproti tomu vrstva důvěry lehkých klientských mostů je silnější a není třeba zavádět nové předpoklady důvěry, dokud je řetězec bezpečný, je bezpečný i most. V některých scénářích, kde je třeba propojit pouze 2 řetězce (nebo o něco více než 2 řetězce), budou vhodnější lehké klientské mosty.

V tomto článku provedeme inventuru hlavních lehkých klientských můstků, které jsou v současné době na trhu, a stav vývoje technologie zkřížených řetězců lehkých klientských můstků.

Princip lehkého klienta

Uveďme nejprve základní přehled principů světelných klientů. Light klienti, nazývaní také light nodes, jsou často prezentováni ve formě light smart kontraktů v řetězci. Základním principem křížového řetězce lehkého klienta je nasazení kontraktu lehkého uzlu zdrojového řetězce na cílový řetězec pro ověření zpráv ze zdrojového řetězce. Pokud chcete dosáhnout obousměrného zkříženého řetězce, musíte nasadit kontrakty světelných uzlů druhého řetězce na dva řetězce.

Ve srovnání s úplnými uzly jsou lehké uzly lehké uzly, které neukládají sekvenci úplných bloků, ale pouze sekvenci záhlaví bloků. Přestože je hlavička bloku malá, obsahuje kryptografický souhrn kompletních dat v bloku. Když lehký uzel potřebuje vědět, zda je transakce zahrnuta do řetězce, může provést SPV ověření transakce prostřednictvím hlavičky bloku, ve kterém se transakce nachází, a Merkle cesty transakce.

Aby se zachovaly rozmístění lehkých uzlů zdrojového řetězce v cílovém řetězci, musí mimořetězový agent nepřetržitě synchronizovat hlavičky bloků zdrojového řetězce s cílovým řetězcem. Smlouvy o lehkém uzlu nepředpokládají důvěru v mimořetězového agenta odpovědného za synchronizaci hlaviček bloků. Protože kontrakty lehkých uzlů provádějí ověření hlaviček bloků, které synchronizují, nemohou mimořetězcové proxy klamat lehké uzly.

Logika ověřování lehkých uzlů hlaviček bloků je stejná jako u úplných uzlů a uzlů těžařů a je rozdělena na dvě části: ověření platnosti a ověření finality.

V případě řetězce PoW se ověření platnosti týká především ověření dokladu o práci bloku a ověření definitivní platnosti spočívá v tom, zda je za hlavičku bloku přidáno více platných bloků (v řetězci BTC se obecně má za to, že 6 Doplnění bloků může potvrdit konečnost bloku V Ethereu se obecně věří, že přidání 25 bloků může potvrdit konečnost bloku).

U řetězců PoS se ověření platnosti týká ověření, zda je blok generován náhodně vybraným producentem bloků, a ověření platnosti má zjistit, zda je blok podepsán ověřovateli s více než 2/3 hlasovací váhy. PoS lehké uzly však nemusí ověřovat platnost, pouze konečnost. Protože v řetězci PoS musí být konečný blok platný, ale ne v řetězci PoW.

Níže začínáme bilancovat:

BTC relé

BTC-Relay je nejstarší kontrakt na světelný uzel a nejstarší zkřížený most mezi klienty. Jeho pracovní princip je velmi jednoduchý, to znamená nasazení světelného uzlu BTC SPV na Ethereum pro provádění SPV ověřování transakcí v řetězci BTC.

Off-chain role „Relayer“ je zodpovědná za průběžné předávání hlavičky bloku BTC řetězce kontraktu light node.

Překladač zaplatí společnosti Ethereum poplatek za plyn za uložení a ověření hlavičky bloku. Překladač zároveň obdrží poplatky jako kompenzaci od uživatele, který inicioval cross-chain požadavek, a získá odpovídající zisky. Překladačem se může stát kdokoli a nastavit si standard účtování pro každý hovor Pokud se ostatní chtějí stát přelévačem, mohou za něj zaplatit malý poplatek a místo toho nastavit nižší standard účtování, pokud se uživatel obává příliš vysokých poplatků , Vysoká, můžete službu Relayer spustit také sami.

Je třeba poznamenat, že BTC Relay je jednosměrný most, který podporuje pouze ověřování informací BTC na Ethereu a nepodporuje ověřování informací v opačném směru. Proto BTC Relay nevydává cross-chain derivátová aktiva BTC a jeho případ použití je omezen na podporu uživatelů, aby používali bitcoiny k placení poplatků za Ethereum.

BTC Relay lze samozřejmě použít jako stavební blok a jednosměrnou vrstvu důvěry pro poskytování služeb ověřování transakcí ve směru BTC → Ethereum pro další cross-chain deriváty BTC.

Oficiální stránky BTC Relay: http://btcrelay.org/Dokumentace BTC Relay: https://github.com/ethereum/btcrelay

Most Waterloo

WaterLoo Bridge je cross-chain most vyvinutý společností Kyber Network. Je to také první cross-chain most, který implementuje obousměrné křížové ověřování klientů mezi Ethereem a EOS. Přestože WaterLoo Bridge získal kvůli úpadku EOS malou pozornost, jeho technické řešení je stále reprezentativní.

Waterloo Bridge implementuje lehkého klienta EOS prostřednictvím chytrých smluv Ethereum a také implementuje lehkého klienta Ethereum prostřednictvím chytrých smluv EOS.

Vzhledem k tomu, že Ethereum produkuje bloky relativně pomalu a výpočetní a úložné zdroje na EOS jsou relativně dostačující, smlouva o Ethereum light node, kterou vytvořila WaterLoo na EOS, je SPV light node, je v souladu s principem BTC Relay a bude ukládat Ethereum záhlaví bloku Synchronizujte s kontrakty lehkého uzlu jeden po druhém.

EOS však vytváří bloky velmi rychle a zdroje na Ethereu jsou omezené, a proto je kontrakt EOS light node na Ethereu navržen tak, aby se bloky synchronizovaly pouze se změnami v sadě BP (sada producentů bloků), nikoli jeden po druhém synchronizovat všechny bloky. Ale takový návrh musí vyřešit dva problémy:

  • Jak ověřit hlavičky historických bloků: Když transakce, která má být ověřena, není v uloženém bloku, smlouva lehkého uzlu musí nejprve získat odpovídající hlavičku bloku z úplného uzlu. Ale stále je zde vyžadován proces ověření Jak ověřuje smlouva o lehkém uzlu tyto získané hlavičky bloků?

  • Jak ověřit poslední hlavičku bloku: Jak ověřit konečnost poslední synchronizované hlavičky bloku, aniž byste měli úplnou historii hlavičky bloku?

Jak ověřit hlavičky historických bloků

Kontrakt lehkého uzlu musí být schopen ověřit hlavičku bloku získanou z úplného uzlu na základě uložené hlavičky bloku. Jak to udělat? Musíme pochopit, že konsensuální protokol EOS je DPoS. Staker of $EOS volí 21 BP (Block Producers) prostřednictvím hlasování být zpracovány 21 BP, bloky podepsané více než 15 BP jsou považovány za konečné a tyto podpisy se projeví v záhlaví bloku.

Přestože EOS vyrábí bloky rychleji, sada BP se nemění příliš často, pokud má lehký klient seznam sad BP (seznam veřejných klíčů), může ověřit všechny hlavičky bloků v rámci doby sady BP. Jinými slovy, pokud byla hlavička bloku získaná z úplného uzlu podepsána 15 BP v odpovídajícím termínu, bude přijata smlouvou s lehkým klientem.

Jak ověřit nejnovější hlavičku bloku

Vzhledem k tomu, že volební hlasování pro sadu BP probíhá v řetězci, výsledky hlasování se projeví v záhlaví určitého bloku Block{i} Záhlaví bloku bloku{i} bude odrážet seznam sady BP a jejich podmínky. . Když se vygeneruje Block{i} a nová sada BP v něm obsažená, nová sada BP ještě nenabyla účinnosti a Block{i} bude podepsána starou sadou BP.

Zjednodušeně lze také chápat, že stará sada BP schválila novou sadu BP podpisem bloku obsahujícího výsledky voleb nové sady BP. Dokud lehký klient správně uchopí počáteční sadu BP a uchopí blok, kde se sada BP pokaždé mění, prostřednictvím takového „řetězce vztahu schvalování“, lze jej vysledovat až k poslední sadě BP. Zvládnutím poslední sady BP můžete ověřit nejnovější blok.

Pokud je tedy během inicializace zadána správná počáteční sada BP do smlouvy s lehkým klientem, může uživatel s lehkým klientem dokončit následné ověřovací práce sám.

Proces ověření zprávy

Pokud je na EOS zpráva, kterou je třeba přenést křížově do Etherea, Waterloo Bridge: ① Zkontroluje, zda záhlaví bloku, ve kterém je zpráva umístěna, již v lehkém klientovi existuje, pokud neexistuje. přejděte ke kroku ② Pokud existuje, přejděte ke kroku ③ ② na nejnovější sadě BP, kterou má, Jinými slovy, lehký klient kontroluje hlavičku bloku. Zjistit, zda je platná, zda je podepsána více než 2/3 sady BP ③ ověření pro provedení ověření SPV u zprávy.

Mechanismus konsenzu EOS patří ke konsenzuálnímu mechanismu typu BFT a metoda implementace lehkého klienta EOS se stala typickým paradigmatem veřejných řetězových klientů typu BFT.

Úvod do WaterLoo Bridge (část 1) https://blog.kyber.network/waterloo-a-decentralized-practical-bridge-between-eos-and-ethereum-1c230ac65524 Úvod do WaterLoo Bridge (část 2) https://blog .kyber.network/ waterloo-a-decentralized-praktický-most-mezi-eos-a-ethereum-c25b1698f010

Duhový most

Rainbow bridge je oficiální křížový most vyvinutý společností Near, aby propojil ekosystém Near a ekosystém Ethereum. V dokumentaci Rainbow bridge se zmiňuje: Hlavním konstruktérem Rainbow bridge je Anton Bukov, který je nyní CTO společnosti 1inch. Přestože již nepracuje na plný úvazek ve společnosti Near, stále řídí vývoj Rainbow bridge.

struktura

Hlavními součástmi Rainbow Bridge jsou dva on-chain kontrakty a tři off-chain agenti:

Řetězová smlouva:

  • EthOnNearClient: Světelný uzel Ethereum implementovaný jako Near kontrakt v Rustu

  • NearOnEthClient: Near light uzel implementovaný jako Ethereum kontrakt v Solidity

Off-chain proxy:

  • Eth2NearRelay: Zodpovídá za předání hlavičky bloku Ethereum EthOnNearClient

  • Near2EthRelay: Zodpovídá za předání záhlaví bloku Near do NearOnEthClient

  • Hlídací pes: Zodpovídá za zpochybnění Near2EthRelay, které odesílá neplatná záhlaví bloků, podrobnosti později

EthOnNearClient potřebuje sledovat každou hlavičku bloku na Ethereu. NearOnEthClient potřebuje pouze sledovat jednu hlavičku bloku pro každou epochu. An Epoch of Near je asi 43 000 bloků, což je asi 4 hodiny. Bylo by nereálné je všechny synchronizovat. Naštěstí se Nearova sada validátorů změní pouze jednou za Epochu a každá Epocha bude mít pouze jednu hlavičku bloku obsahující informace o výběru sady validátorů. Návrh NearOnEthClient silně čerpá z EosOnEthClient v WaterLoo Bridge a dokonce znovu používá část kódu WaterLoo Bridge.

Ale pro NearOnEthClient stále existuje technický problém, to znamená, že Ethereum není kompatibilní s formátem podpisu Ed25519, který používá Near, což činí ověřování Near blokových hlaviček NearOnEthClientem velmi problematické. Proto Rainbow Bridge zavádí optimistické schéma ověřování.

Když Near2EthRelay odešle hlavičku bloku do NearOnEthClient, potřebuje zapůjčit nějaké $ NEAR na řetězu Near Během 4hodinového okna mohou vyzyvatelé zvaní Watchdogs vyvolávat výzvy, období okna končí hlavička bloku je oficiálně přijímána společností NearOnEthClient. Pokud Hlídací pes vyzve výzvu a výzva je úspěšná, Near2EthRelay, který odeslal neplatnou hlavičku bloku, zaplatí finanční cenu, polovina jeho zajištění bude zničena a zbývající polovina se stane odměnou hlídacího psa, který výzvu vyvolal. .

Zavedení optimistického ověřování přináší nový předpoklad důvěry: alespoň jeden Watchdog je loajální.

V BTC Relay běží pouze jeden Relayer současně, ale v Rainbow Bridge, ať už je to Eth2NearRelay nebo Near2EthRelay, může běžet více najednou. Více převrstvovačů si může vzájemně konkurovat a pokusit se odeslat stejný blok ve stejnou dobu. Pouze jeden převrstvovač si může vytvořit zálohu odeslat, což snižuje možnost nedostupnosti služby.

Pobídky

V současné době Rainbow Bridge neposkytuje ekonomické pobídky pro dvě sady služeb Relay, které předávají hlavičky blokování, protože Near očekává, že hlavní aplikace běžící na Rainbow Bridge (například: $ETH Asset Bridge, $NEAR Asset Bridge, ERC20 Asset Bridge, NFT Bridge) automaticky spustí Relay služby a alespoň pár Relay služeb oficiálně provozuje Near. Budoucí verze Rainbow Bridge mohou zvýšit ekonomické pobídky pro Relay služby a zvýšit odpovídající mechanismy zpoplatnění pro cross-chain uživatele/aplikace.

nejnovější pokrok

Společnost Near vydala prostředí Aurora kompatibilní s EVM V současné době podporuje Rainbow Bridge 2.0 cross-chain mezi Ethereem a Aurorou. Je třeba poznamenat, že ačkoli Aurora udržuje nezávislou účetní knihu a má nezávislý blockchainový prohlížeč, nejedná se o nezávislý blockchain, ale běhové prostředí na Auroře nemá nastavený nezávislý validátor Near a Most mezi Aurorou není kříž -řetězový most, ale most mezi běhovými prostředími. Musíme také poznamenat, že v době psaní tohoto článku Ethereum právě dokončilo transformaci PoS. Proto mohou být světelní klienti Ethereum navržení pro verzi PoW v Rainbow Bridge a WaterLoo Bridge v blízké budoucnosti přepracovány.

Blízko úvodního dokumentu:

https://near.org/blog/eth-near-rainbow-bridge/

Snowbridge (sněhová vidle)

SnowBridge je oficiální projekt cross-chain bridge s Polkadot, vyvinutý týmem Snowfork. Jeho účelem je vytvořit nativní ověřovací most mezi ekosystémem Polkadot a Ethereem.

Snowbridge je projekt, který je stále ve vývoji. Naše znalosti o něm pocházejí z aktuální dokumentace SnowBridge, která se na některých místech stále ještě píše „již brzy“. Proveďte analýzu.

Snowbridge bude mít svůj vlastní parachain, který bude v budoucnu fungovat jako veřejný blahobytový parachain s názvem SnowBridge Parachain. Tento parachain bude zodpovědný za vytvoření mostu s Ethereem. To znamená, že lehký uzel Pallet Etherea bude provozován na SnowBridge Parachain.

  • V Substrate neexistuje žádný koncept kontraktu Vývojáři nasazují aplikace do řetězce přidáním palet, ale jejich podstata je stejná jako kontrakty a oba jsou běhové moduly v řetězci.

Snowbridge se bude skládat z následujících modulů

Smlouvy nasazené na Ethereum:

  • Polkadot RPC: používá se ke zpracování cross-chain požadavků na Ethereum

  • POLKADOT A PARACHAIN ​​LIGHT KLIENTSKÝ OVĚŘOVAČ

Paleta nasazená na Snowbridge Parachain:

  • ETHEREUM RPC se používá ke zpracování cross-chain požadavků na Polkadot

  • Ethereum LIGHT KLIENTSKÝ OVĚŘOVAČ

Ethereum light klient na Snowbridge Parachain

Podle aktuální dokumentace Snowbridge (2022.10.14) je Ethereum light klient navržen jako SPV light uzel Relayer bude zodpovědný za synchronizaci Ethereum blokových hlaviček jeden po druhém. Light klient Pallet zkontroluje důkaz práce a bude následovat Nejtěžší split. (Ale aby se Snowbridge po transformaci na PoS adaptoval na Ethereum, měl by mít nová řešení.)

Polkadot light klient na Ethereum

Je třeba poznamenat, že protože přenosový řetězec je zodpovědný za shodu SnowBridge Parachain, lehký klient bude synchronizovat hlavičku bloku přenosového řetězce, nikoli hlavičku bloku SnowBridge Parachain. Aby bylo možné sledovat nejnovější informace o sadě validátoru, musí být synchronizována hlavička bloku obsahující opětovný výběr sady validátorů, což znamená, že v každé epochě je třeba synchronizovat alespoň jedno záhlaví bloku. Když existuje transakce, kterou je třeba ověřit, je podle potřeby z předávacího řetězce vyžádána hlavička bloku SnowBridge Parachain a její konečnost je ověřena pomocí hlavičky přenosového řetězového bloku, která ji obsahuje.

Ve srovnání s WaterLoo musí Snowfork čelit novému problému: EOS má pouze 21 validátorů, ale Polkadot má asi 1 000 validátorů, i když jen 2/3 validátorů podepsaly blok, 600 bude ověřeno v Ethereu počet podpisů je také neuvěřitelně vysoký. Rainbow Bridge tento problém obchází pomocí optimistické autentizace, zatímco Snowfork se mu rozhodl čelit čelem.

Řešení Snowbridge spočívá v přijetí vzorkovacího mechanismu: při získávání hlavičky bloku si lehký klient náhodně vybere podmnožinu ze sady validátorů odpovídající hlavičce bloku. Lehký klient ověří pouze podpisy této podmnožiny, aniž by musel ověřovat všechny '. s podpisem. Podle výzkumu Snowfork potřebuje počet validátorů v této podmnožině pouze ceil(log2(3*N)) (N je celkový počet validací). Pokud N je 1000, pak je třeba extrahovat pouze podpisy 12 validátorů.

SVALNATÝ

Aby bylo možné lépe podporovat přemostění s jinými veřejnými řetězci, Polkadot vyvinul finální gadget nazvaný BEEFY na základě GRANDPA konsensu (v době psaní tohoto článku se kód BEEFY stále vylepšuje). Poté, co GRANDPA ukončí blok řetězce relé Polkadot, bude existovat odkaz BEEFY konsenzuálního podpisu V tomto odkazu musí validátor přidat kořenování MMR do hlavičky bloku a poté provést samostatné kolo konsenzuálního podpisu na bloku. záhlaví.

S BEEFY nebudou lehcí klienti muset rozumět složitosti GRANDPA a budou muset pouze ověřit podpis BEEFY. Nejdůležitější je, že formát podpisu BEEFY je plně kompatibilní s Ethereem, což usnadňuje ověření na straně Etherea.

Pobídky

SnowBridge je vydán ve dvou fázích. První fáze je Basic Bridge. Tato fáze již má základní funkce cross-chain bridge, ale nejsou zde žádné pobídky pro Head Relayer a Message Relayer. Pokud chtějí uživatelé/aplikace zajistit, aby jejich zprávy byly úspěšně přenášeny, musí samy spustit službu Relayer. Druhá fáze přejde na Incentive Bridge, který zavede pobídky pro Relayery.

Aplikační vrstva

V plánu týmu Snowfork, jakmile bude SnowBridge online, budou brzy uvolněny tři asset bridge, konkrétně DOT Asset Bridge: podporuje vytvoření snowDOT ETH Asset Bridge na Ethereu podporuje vytvoření snowETH ERC20 Asset Bridge na straně Polkadot: podporuje Create mapovaná verze aktiva ERC20 na straně Polkadot s formátem názvu: snow-[název aktiva].

Dokumentace Snowbridge

https://snowbridge-docs.snowfork.com/

Masivní dokumentace

https://github.com/paritytech/grandpa-bridge-gadget/blob/master/docs/walkthrough.md

LCMP (Darwinia)

LCMP (Light-client Cross-chain Messaging Protocol) je heterogenní cross-chain protokol vyvinutý společností Darwinia Jedná se o univerzální a otevřený cross-chain přenosový protokol založený na řešení lehkého klienta. Protokol je v současné době ve formě SDK, což umožňuje Dapps volně integrovat. V ekologické struktuře zkříženého řetězce postavené Darwinií jsou dva řetězce, Darwinia Chain a Darwinia Parachain je paralelní řetězec Polkadot. Oba mají odpovídající kanárské sítě, Krabí řetězec a Krabí Parachain, z nichž Krabí Parachain je Kusama. paralelních řetězců.

Na Darwinia Chain je nasazeno prostředí kompatibilní s EVM, které se nazývá Darwinia Smart Chain. Říká se mu Chain, protože Darwinia Smart Chain má nezávislý stavový stroj a prohlížeč, ale není to nezávislý blockchain. (Viz vztah mezi Aurorou a Near) V souladu s tím existuje na Crab Chain také prostředí kompatibilní s EVM, nazvané Crab Smart Chain.

Lehký klientský design

V době psaní tohoto článku byl implementován LCMP

  • Most mezi Darwinia Chain a Ethereum

  • Přemosťování krabího řetězce a krabího parachainu

Mezi nimi je řešení lehkého klienta, které používá, stejné jako Waterloo. Zaměřujeme se na sadu lehkých klientů používaných k přemostění Darwinia Chain a Ethereum. Darwinia Chain Client On Eth Vzhledem k tomu, že Beefy ještě není k dispozici, podpis hlavičky bloku Darwinia Chain vyvinutý na základě Substrate není kompatibilní s Ethereem.

Darwinia v současné době přijímá přechodný plán a volí podepisující skupinu prostřednictvím správy parlamentu, která je zodpovědná za podepsání hlavičky bloku Darwinia Chain. Light klient ověří, zda je hlavička bloku legální ověřením podpisu skupiny. Ačkoli je na Darwinia Chain více než 100 validátorů, skupina podepisujících nepřesahuje 10 osob a ekonomické náklady na Ethereum straně na ověřování těchto podpisů jsou přijatelné.

Eth klient na řetězci Darwinia

Sloučený řetězec majáků Ethereum má jako řetězec PoS stovky tisíc validátorů a je zjevně nereálné ověřovat jejich podpisy. Proto Ethereum přidalo nový konsensuální odkaz v upgradu s názvem Altair. Po upgradu Altairu bude z validátorů v řetězci Ethereum každých 256 epoch (přibližně 27 hodin) vybrána komise 512 validátorů. Lehký klient potřebuje pouze ověřit, že jej podepsaly 2/3 výboru, aby ověřil hlavičku bloku. 512 je však stále trochu příliš, takže Ethereum také používá technologii BLS k agregaci četných podpisů výboru do jednoho podpisu, což dále snižuje náklady na ověření lehkých klientů.

Darwinia byla upgradována na Altair a implementovala lehkého klienta Ethereum v řetězci Darwinia. Lehký klient potřebuje synchronizovat hlavičku bloku každých 27 hodin. Toto by měl být první on-chain light klient implementovaný na Ethereu po transformaci PoS.

Poplatky a pobídky

Iniciátor cross-chain (což může být uživatel nebo Dapp) musí zaplatit poplatek při odesílání cross-chain zprávy. Poplatek bude zahrnovat tři části:

  • Poplatky za plyn za provádění transakcí zdrojového řetězce.

  • Poplatky zaplacené Relayeru.

Konkrétní ceny jsou určeny trhem a mnoho překladačů může konkurovat cenou. Je třeba poznamenat, že překladač musí zaplatit poplatek za plyn v cílovém řetězci a překladač tyto náklady zohlední v ceně. Jinými slovy, iniciátor napříč řetězcem již nemusí platit poplatek za plyn v cílovém řetězci odděleně.

  • Poplatky zaplacené pokladu.

Určité procento z cross-chain poplatků zaplacených cross-chain iniciátory půjde do Darwinia Treasure. Treasure použije část svých prostředků na dotování Head Relayer.

Darwinia Docs:

https://docs.darwinia.network/lcmp-overview

以太坊 Altair forkhttps://blockdaemon.com/blog/ethereum-altair-hard-folk-light-clients-sync-committees/

zkBridge

V době psaní tohoto článku je zkBridge rodící se projekt s dokončeným pouze malým množstvím vývoje. Ale tento projekt je zatím jedním z mála projektů, který využívá technologii nulových znalostí pro stavbu křížových řetězových mostů. zkBridge používá pro rozšíření světelných uzlů důkaz ZK-SNARK.

Aktuálně zkBridge implementoval instanci Cosmos Client na Ethereum pomocí Solidity Podle testů dokáže vygenerovat certifikát ZK-SNARK pro hlavičku bloku Cosmos Zone za 2 minuty a následně jej ověřit na straně Etherea utracením pouze 220k plynu. Naopak, pokud se nepoužije důkaz ZK-SNARK, náklady budou 64 milionů plynu.

Hlavní inovace zkBridge jsou:

  • deVirgo: Použijte distribuovanou metodu pro generování důkazů ZK-SNARK Tato metoda se nazývá deVirgo. Tato metoda výrazně zlepšuje efektivitu generování důkazů ZK-SNARK mimo řetězec tím, že rozděluje výpočetní práci a přiděluje ji více zařízením.

  • Rekurzivní důkaz: Za účelem snížení nákladů na řetězci používá zkBridge rekurzivní schéma důkazu (důkaz, který generuje důkaz) ke komprimaci důkazu ZK-SNARK na přibližně 131 bajtů pomocí dvou rekurzí.

  • Dávkové zpracování: zkBridge implementuje smlouvu o aktualizaci záhlaví bloku, která bere výšku bloku jako vstup a vrací odpovídající záhlaví bloku. ZkBridge však nevolá smlouvu o aktualizaci, když je generován každý nový blok. Ověřovatel může nejprve shromáždit N hlaviček bloků a vygenerovat jediný důkaz. Hodnotu N lze nastavit, čím větší N, tím delší doba čekání uživatele, ale nižší provozní náklady systému.

Je třeba říci, že technologie zero-knowledge proof je technologie, která dokáže zázraky. Hlavní překážkou omezující jeho přijetí je vysoký technický práh a obtížnost vývoje. Nicméně při vývoji technologie s nulovými znalostmi jsou odměny a úsilí vždy úměrné.

zkBridge Twitter dlouhý příspěvek: https://twitter.com/dawnsongtweets/status/1574775723767783424

papír zkbridge:

https://rdi.berkeley.edu/zkp/zkBridge/uploads/paper.pdf

Protokol MAP

MAP Protocol je obecný heterogenní cross-chain protokol založený na lehkých klientech a přenosových řetězcích.

Na rozdíl od mnoha výše uvedených projektů se MAP rozhodl založit přenosový řetězec MAP Chain jako přenosovou stanici pro přenos zpráv napříč řetězcem. Přístupové řetězce nemusí být navzájem přímo propojeny, ale jsou všechny připojeny k řetězci MAP. To znamená: každý přístupový řetězec potřebuje pouze nasadit kontrakt lehkého uzlu řetězce MAP a světelné uzly každého přístupu. řetězce jsou nasazeny na kontraktu MAP Chain.

Architektura protokolu MAP je rozdělena do tří vrstev, a to protokolová vrstva, cross-chain servisní vrstva a aplikační vrstva. v:

  • Protokolová vrstva: Můžeme ji chápat jako vrstvu důvěry, včetně MAP Chain a každého programu lehkého klienta přístupového řetězce;

  • Cross-chain service layer: Poskytněte některé společné moduly pro aplikační vrstvu, aby aplikační vrstva nemusela „znovu objevovat kolo“, například běžný modul Vault může uzamknout prostředky pro některé aplikace přemosťování aktiv, ale vybrat si mohou i aplikace k vybudování vlastních Vaultů Tento modul se nepoužívá.

  • Aplikační vrstva: označuje aplikace, které používají protokol MAP jako médium pro přenos zpráv napříč řetězci.

Kromě toho MAP Protocol obsahuje tři off-chain role

  • Správce: Zodpovídá za aktualizaci záhlaví bloků každého kontraktu lehkého uzlu a může získat odměny za inflaci $ MAP.

  • Messenger: Zodpovídá za doručování meziřetězových zpráv a může získat meziřetězové poplatky placené uživateli, ale musí uhradit poplatky za plyn v cílovém řetězci a předávacím řetězci.

  • Validátor MAP Chain: Zodpovídá za proces konsensu MAP Chain a potřebuje slíbit $MAP, aby získal $MAP inflační odměny. MAP Chain v současnosti využívá mechanismus konsenzu IBFT-PoS.

Tok zpráv napříč řetězcem

Dokument MAP Protocol neklade velký důraz na mechanismus přenosu zpráv Z několika současných slov by tok zpráv měl vypadat takto: Když aplikace na zdrojovém řetězci zahájí cross-chain požadavek, cross-chain zpráva M je. zahrnuta v transakci T1, je odeslána do předávacího řetězce messengerem Po přijetí transakce T1 přenosový řetězec zahrnuje transakci T1 a zprávu M, kterou nese v transakci T2, předá messenger cílovému řetězci. a cílový řetězec přijme do T2 a po ověření jej odešle do cílové aplikace.

Přestože je MAP Protocol projekt spuštěný v roce 2019, zatím jsou jedinými podporovanými řetězci Ethereum, BSC a Polygon Slovo „univerzální“ není hodné svého jména. Ve skutečnosti, protože kontrakty lehkých uzlů nelze znovu použít, když se rozšíří do různých řetězců a je třeba je vyvinout samostatně, je obtížné být „univerzálními“ zkřížené můstky založené na kontraktech lehkých uzlů.

Dokumentace protokolu MAP https://docs.maplabs.io/

Kosmos IBC

IBC je velmi dobře navržený izomorfní cross-chain protokol a důležitá součást cross-chain sítě Cosmos Cross-chain síť Cosmos se skládá hlavně z Hub a Zone a Hub jsou přemostěny protokolem IBC (InterBlcokChain). Zóna a mosty jsou vytvořeny mezi zónami pomocí rozbočovače jako relé. Cross-chain síť Cosmos také zahrnuje zónu Peg a heterogenní přemosťovací části, které nespadají do působnosti IBC. Hub i zóna jsou otevřené pro přístup Jakýkoli blockchain postavený na Cosmos SDK se může stát Hubem nebo se stát zónou a zaregistrovat se jako přístupový řetězec u kteréhokoli Hubu. Na rozdíl od Polkadotova reléového řetězce není Cosmos’ Hub jedinečný.

lehký klient

Každá zóna registrovaná v Hubu musí nasadit IBC modul, který obsahuje smlouvu s lehkým klientem Hubu Modul IBC v Hubu bude také integrovat smlouvu s lehkým klientem každé připojené zóny.

V mechanismu konsenzu Tendermint neexistuje žádná koncepce epochy a každý blok může vést ke změnám ve validátorech. Lehká klientská smlouva v IBC má však koncept TrustPeriod (doba důvěry), což je parametr, který musí light klient nastavit během inicializace V rámci TrustPeriod může sada ověřovatelů provádět drobné změny a jednotliví ověřovatelé Vy může vstoupit nebo odejít, ale nedojde k žádným zásadním změnám.

Tato malá změna je přijatelná, protože každý podpis bude mít jen málokdy přesně 2/3 hlasovacích práv a vždy dojde k určitému přetečení I když se jednotliví validátoři připojí nebo odejdou, lehký klient bude následovat ověření před změnou uživatelská sada kontroluje hlavičku bloku, je vysoká pravděpodobnost, že lze ještě pozorovat, že byly podepsány 2/3 hlasovacích práv.

Proto lehká klientská smlouva v IBC potřebuje aktualizovat informace o sadě validátoru pouze jednou za TrustPeriod, což znamená, že každé TrustPeriod potřebuje synchronizovat pouze jednu hlavičku bloku.

Práci na synchronizaci hlaviček bloků bude provádět Relayer.

Základní pojmy a principy

IBC konstruuje tři abstraktní pojmy, jmenovitě připojení, kanál a paket.

  • Spojení

Spojení označuje spojení mezi dvěma zónami. Navázání spojení lze chápat jako spárování dvou zón. V tuto chvíli si tyto dvě zóny vyžádají od Hubu nejnovější hlavičku bloku svého lehkého klienta. Navázání spojení probíhá na principu třícestného handshake (handshake komunikace je spuštěna Relayerem Po dokončení handshake je spojení otevřeno).

V tomto okamžiku lze Kanál navázat nad Připojením. Channel Connection spojuje dvě zóny, zatímco Channel spojuje pár aplikací na dvou zónách (pár aplikací může pocházet ze stejné aplikace nebo mohou pocházet z různých aplikací). Dvě aplikace vytvoří Kanál prostřednictvím principu třícestného handshake (komunikace handshake je spuštěna Relayerem Po vytvoření kanálu si mohou obě aplikace posílat pakety).

  • Kanál

Kanál je základním konceptem IBC, který umožňuje aplikacím přímo navazovat spojení. Jako abstraktní pojem Kanál neexistuje jako entita Pro přijímající aplikaci Kanál definuje odesílatele. Pokud víte, ze kterého Kanálu zpráva pochází, budete vědět, ze které aplikace zpráva pochází , Pokud jde o aplikace, Kanál definuje příjemce, které aplikaci chcete poslat zprávu, vložte zprávu do odpovídajícího Kanálu.

Kanál také definuje časování zpráv Zprávy ve stejném kanálu sledují frontu a mají striktní časový vztah. Zpráva odeslaná jako první je vždy doručena jako první. Mezi zprávami v různých kanálech neexistuje žádný časový vztah.

Zde je třeba poznamenat, že pro aplikaci je nejlepší používat kanál stabilně. Pokud například aplikace pro přemostění aktiv používá více kanálů k vytvoření mapovaných aktiv v cílovém řetězci, pak více kanálů vygeneruje různé mapované položky, což způsobí zbytečné potíže.

  • Paket

Paket je standardizovaná datová struktura a předepsaný formát pro cross-chain zprávy, které mohou být přenášeny v kanálu. Přenos paketů je rozdělen do tří kroků:

  • sendPacket: Aplikace na odesílající straně vytvoří paket se sériovým číslem N ve zdrojovém řetězci a přidá jej do čekající fronty;

  • recvPacket: Relayer přenáší paket do cílového řetězce, kde je uložen aplikací na přijímající straně.

  • cancelPacket: Relayer přenese důkaz, že přijímající aplikace uložila paket zpět do zdrojového řetězce, a zdrojový řetězec paket se sériovým číslem N vymaže z odchozí fronty.

Pokud přijímající smlouva neuchovává paket po dlouhou dobu, Relay vrátí zprávu o vypršení časového limitu. Je třeba poznamenat, že Cosmos IBC se liší od protokolu MAP Pakety jsou odesílány přímo ze zdrojové zóny do cílové zóny a není nutné je přenášet v rozbočovači. Je to proto, že cílová zóna může přímo dotazovat Hub na hlavičku bloku zdrojové zóny a poté provést ověření paketu. To znamená, že Hub potřebuje přeposlat pouze hlavičku bloku.

Konkrétně je na Hubu světelný uzel zdrojové zóny, který může ověřit hlavičku bloku zdrojové zóny Na cílové zóně je světelný uzel, který může ověřit hlavičku bloku Kdy cílová zóna vyžaduje určité záhlaví bloku zdrojové zóny SourceZoneBlockHead{i }, můžete nechat Relayer získat je z Hubu. Uzel světla na cílové zóně ověří HubBlockHead{i} a použije HubBlockHead{i} k ověření SourceZoneBlockHead{i. } Poté můžete použít SourceZoneBlockHead{i} k ověření paketu zdrojové zóny.

Poplatky a pobídky

V IBC je konfigurovatelný modul poplatků a iniciátor připojení může přizpůsobit standard účtování a standard plateb pro Relayer. Podle našeho pozorování jsou však účastníci projektu Zone a účastníci aplikačního projektu často motivováni ke spuštění Relayeru sami.

Cosmos IBC Docs

https://ibc.cosmos.network/Cosmos Analýza kódu IBC https://blog.csdn.net/mutourend/article/details/122576435

souhrn

V současné době, pokud jde o návrh řešení lehkých klientů, jsou PoW lehcí klienti stále založeni na lehkých klientech SPV, kteří synchronizují všechny hlavičky bloků zdrojového řetězce jednu po druhé, zatímco lehcí klienti PoS většinou přijímají schéma skokové synchronizace hlaviček bloků. Synchronizují se pouze hlavičky bloků, které mění sadu validátorů, musíme nechat lehkého klienta uchopit změny v sadě validátorů, pokud je inicializace správná, aby mohl lehký klient uchopit nejnovější sadu validátorů.

V praxi bude konstrukce lehkých klientů také narážet na problémy, jako jsou vysoké náklady na ověřování hlaviček bloků a nekompatibilita podpisových schémat Různé projekty přijmou různé metody, jak se s nimi vypořádat, včetně optimistického ověřování (RainbowBridge), vzorkování sady validátorů (Snowfork). Zero-knowledge proofs (zkBridge) jsou generovány mimo řetězec Navíc, aby lépe podporovaly cross-chainy, jsou veřejné řetězce také motivovány k transformaci a upgradu, jako je upgrade Ethereum Altair a vývoj modulu Beefy od společnosti Polkadot.

Stručně řečeno, technologie lehkých klientů je stále uprostřed intenzivního vývoje S dalším výzkumem a průzkumem se bude obtížnost budování lehkých klientů v budoucnu postupně snižovat.