Autor: Lisa A., Taiko Labs Překlad: Golden Finance xiaozou;
Tento článek prozkoumá různé metody křížového zasílání zpráv L2 z pohledu souhrnu se zaměřením na nedůvěryhodnou meziřetězovou komunikaci. Krátce se podíváme na přístup stavu přímého čtení, přístup odlehčeného klienta a důkaz o uložení. Zaměříme se také na spolehlivé agregační mechanismy, důvěryhodný přenos zpráv třetích stran napříč řetězci a základní řešení ZK cross-chain. Nakonec se podívejme, jak dnes různé L2 implementují cross-chain messaging.
1. Úvod do cross-chain messagingu
Pro cross-chain komunikaci musí mít všechny strany (L2, L3 atd.) přímý přístup k nejnovějšímu kořenu stavu Ethereum.
Všechny depozitní vrstvy mají „zabudovaný“ cross-chain mechanismus, který lze použít pro přístup ke kořenu stavu L1, který bude předán L2 jako zpráva o uložení.
1.1 Dva typy přístupu ke kořenům stavu
Typ 1: Přímé čtení kořene stavu – lze provést pomocí operačních kódů nebo předkompilovat. Dosud však nebyl implementován, takže není potřeba žádný důkaz.
Brecht Devos popsal možnou metodu přímého čtení stavu ve výzkumném článku: „...mohli bychom vystavit předkompilovanou smlouvu, která může přímo volat inteligentní smlouvy na cílovém řetězci. Zdrojový řetězec vloží a spustí kód inteligentní smlouvy To zajišťuje, že inteligentní smlouva má vždy přístup k nejnovějšímu dostupnému stavu účinným a snadno prokazatelným způsobem.
· K dispozici je také související popis v RFP společnosti Optimism „Remote Static Call Proof of Concept“.
Typ 2: Generování důkazů – tedy prokázání tvrzení o jednom blockchainu na jiném blockchainu.
Existují dva způsoby „zkříženého zasílání zpráv s důkazem“:
· Bezpečná meziřetězová komunikace – to znamená, že žádná důvěryhodná třetí strana (např. pomocí lehkých klientů nebo dokladu o uložení). Nedůvěryhodný přístup lze použít jak pro třetí strany, aby generovaly důkazy, tak pro účastníky meziřetězové komunikace, aby si sami vytvářeli důkazy.
· Sdílejte nátisky mezi různými souhrny, abyste zajistili operace napříč řetězci. Tato metoda nebude v tomto článku diskutována. V současné době je ve fázi výzkumu a průzkumu a není považována za řešení, které by mohlo být široce používáno.
1.2 Metoda „Předání zkřížených zpráv s důkazem“.
1.2.1 Křížové zasílání zpráv s lehkým klientem
Dokažte údaje o řetězci B
· Získejte údaje o důkazu Merkel z celého uzlu řetězce B (archivační uzel, pokud je vyžadován důkaz o uložení určitých historických stavů);
· Odeslat hlavičku bloku a důkazní data odpovídající bloku řetězce B obsahujícímu stav, který chceme ověřit, jako calldata do prověřovací smlouvy na řetězu A;
· Smlouva ověřovatele vypočítá hodnotu hash bloku na základě dat hlavičky bloku, dotáže se chytrého kontraktu lehkého klienta v řetězci A (sleduje hodnotu hash bloku řetězce B) a zkontroluje, zda je hodnota hash platná;
· Důkazová data jsou ověřena proti kořenu stavu bytes32 v hlavičce bloku.
1.2.2 Doklad o uložení
Existují dvě možnosti „pracovního postupu“ pro důkaz o uložení:
· Vytvořte doklad o uložení → použijte na řetěz
· Vygenerovat důkaz uložení → vygenerovat důkaz zk → použít na řetěz
Může také existovat účetní jednotka, která sbalí více kolekcí nátisků do jednoho nátisku (včetně nátisků o uložení a zk nátisků). Toto je volitelný krok optimalizace a zatím se o něm nebudeme diskutovat.
Podívejme se na tři hlavní fáze „pracovního postupu“ důkazu úložiště: generování důkazu úložiště, generování důkazu zk a jeho použití v řetězci.
(1) Vygenerujte certifikát úložiště
· Doklad o uložení nám umožňuje používat závazky důvěrnosti k prokázání, že určité informace v blockchainu existují a jsou autentické;
· Proof-of-storage je součástí kryptografické komunity od příchodu stromů Merkle v roce 1979. Vanilla storage certifikáty jsou však obvykle poměrně velké. Moderní inovace spočívá v kombinaci důkazů o úložišti s prokazatelnými výpočty za účelem vytvoření stručných důkazů, které lze ověřit v řetězci.
Aby bylo možné vygenerovat důkaz o uložení, musí být poskytnut konkrétní datový blok a jeho přidružená cesta Merkle nebo Verkle ve stromu Merkle. Cesta se skládá ze sourozeneckých hašů potřebných k rekonstrukci kořenového haše pomocí stejného hašovacího algoritmu.
Pro ověření důkazu o uložení může příjemce přepočítat kořenový hash pomocí poskytnutých dat a cesty Merkle nebo Verkle. Pokud se přepočítaný kořenový hash shoduje se známým kořenovým hashem, může si být příjemce jistý, že data jsou autentická a jsou součástí odeslané datové sady.
(2) Vygenerujte ZKP (důkaz nulových znalostí)
Nicméně proof-of-storage typu Ethereum je kolem 4kb – dost velké na zveřejnění celého proof-of-storage na cílovém řetězci, protože ověření proof by bylo velmi drahé. Proto je rozumné použít pro kompresi ZKP (např. ZK-SNARK), což může zmenšit důkaz a snížit náklady na ověření.
(3) Rozvinout ZKP
Po získání ZKP mohou uživatelé v cílovém řetězci rozbalit získané důkazy (např. přístup k historickému stavu prostřednictvím hlaviček bloků nebo hashů bloků).
Rozbalení lze provést následujícími způsoby:
On-chain akumulace: Celý proces rekonstrukce hlavičky bloku z proof se provádí přímo na blockchainu. Nevýhody: vysoké poplatky za plyn a spotřeba výpočetních zdrojů výhody: žádný další důkazní čas, nízká latence, protože není potřeba generovat důkazy mimo blockchain;
Komprese v řetězci: Odstraňte z dat nadbytečné nebo nepotřebné informace nebo použijte datové struktury optimalizované pro úsporu místa. Zkomprimovaná data jsou odeslána do blockchainu a lze je v případě potřeby dekomprimovat. Nevýhody: Komprese a dekomprese dat může znamenat dodatečné výpočty, ale toto zpoždění může být zanedbatelné. Použitý kompresní algoritmus může mít negativní dopad na bezpečnost dat: snížení nákladů na data;
Úložiště mimo řetězec: Ukládejte data mimo řetězec a na vyžádání umístěte konkrétní datové bloky do řetězce. To je relevantní pro řešení, která z nějakého důvodu potřebují ukládat velké množství dat (např. archivní uzly Ethereum počínaje blokem genesis). Nevýhody: Stejné jako on-chain komprese Výhody: dále snižuje náklady na data.
1.2.3 Důvěryhodná třetí strana
Kompletní cross-chain řešení by také mělo zahrnovat řešení cross-messagingu s důvěryhodnou třetí stranou (jako jsou oracles, centralizované mosty atd.).
1.2.4 „Univerzální“ důkazní systémy
V případě použití mechanismu sdílené důkazní agregační platformy lze doručování zpráv urychlit přijetím blokových hashů vypořádaných v agregační platformě a vypořádání zde bude také řešit doručení zpráv (ale pokud se něco pokazí na agregační platformě důkazů, co dělat? ).
1.2.5 Některé neznámé problémy v ZK cross-chain messaging
Je možné zasílání zpráv napříč řetězci bez důvěryhodné třetí strany (což může být jeden subjekt nebo více subjektů)? Jaký je účinný mechanismus pro zasílání zpráv napříč řetězci? Obecně řečeno, pro Ethereum L2 (které má přímý přístup k blokovým hashům L1) a samotné Ethereum, pokud může řetězec provozovat lehkého klienta atd. na jiném řetězci, může ověřit původ z této externí hlavičky řetězového bloku, což je dostatečné pro důvěryhodné cross-chain messaging.
Je obvod ZK použitý pro generování důkazu zkříženým řetězcem vhodný v měřítku? V některých případech, zejména když je konsenzuální vrstva (která vyžaduje ověření operací zkřížených řetězců) velmi velká, obvody používané pro zkřížené zasílání zpráv ZK mohou být řádově větší než rollup a on-chain storage a výpočetní režie bude také velký. Tento problém by se pravděpodobně dal překonat centralizovanějším přístupem.
2. Příklad řešení cross-chain messagingu
· Succinct Labs používá lehké klienty k ověření konsensu ze zdrojového řetězce k cílové vrstvě konsenzu. Specifickou myšlenkou je, že existuje lehký klientský protokol, který zajišťuje, že uzly mohou synchronizovat hlavičky bloků konečného stavu blockchainu. ZKP se používá ke generování konsensuálních důkazů.
· Lagrange Labs vytváří neinteraktivní křížové důkazy stavu. Lagrangeova síť je zodpovědná za vytvoření státního kořene. Každý uzel Lagrange obsahuje část soukromého klíče shard, který se používá k prokázání stavu konkrétního řetězce. Každý kořen stavu je kořen Verkle se znaménkem prahu, který lze použít k prokázání stavu konkrétního řetězce v konkrétním čase. Kořen stavu je zcela univerzální a lze jej použít ve státních důkazech k prokázání aktuálního stavu jakékoli smlouvy nebo peněženky v řetězci.
· Herodotus používá ZKP storage proof k poskytování chytrých kontraktů a synchronnímu přístupu k datům v řetězci ostatních vrstev Etherea. Pro ověření používá nativní zasílání zpráv L1<>L2 k synchronizaci hash bloků mezi souhrny Ethereum.
· =nil Foundation (Mina, L1) umožňuje chytré smlouvy na Ethereum pro ověření platnosti stavů Mina. Vytvářejte speciální důkazy stavu, které lze levně ověřit na Ethereu (nativní Mina důkazy jsou na Ethereu drahé). Předpokládá se, že (někdy v budoucnu) aplikace mohou přímo používat nástroje Mina pro generování důkazů ke kontrole platnosti cross-chain transakcí. =nil Foundation má také Proof Market, kde mohou uživatelé/projekty primárně nakupovat/prodávat certifikáty SNARK, které umožňují nedůvěryhodný přístup k datům.
Axiom: Pokud Axiom dosud vygeneroval ZKP pro účetní knihu - nepotřebuje generovat ZKP pro konkrétní datový blok - může tento ZKP předat řetězci (jako relé) a dokonce poskytnout přístup k tomuto ZKP Access.
3. L2 cross-chain messaging
Prohlášení: Cross-chain messaging se pro většinu L2 stále vyvíjí. Všechny níže uvedené analýzy jsou založeny na informacích z otevřeného zdroje. To znamená, že řešení zmíněná v článku mohou být ve fázi průzkumu a testování a rollup může nakonec přijmout jiné metody.
(1) Taiko
· Taiko ukládá blokovou hash hodnotu každého řetězce. Pro každý pár řetězců nasadí dvě chytré smlouvy, které si navzájem ukládají hash. V případě L2←→L1 se pokaždé, když je na Taiko vytvořen blok L2, hash okolního bloku na L1 uloží do kontraktu TaikoL2. Stejný způsob operace je použit v případě L1←→L2.
· Nejnovější známý kořen Merkle uložený v cílovém řetězci lze získat voláním getCrossChainBlockHash(0) na kontraktu TaikoL1/TaikoL2 a získat hodnotu/zprávu k ověření. Nejnovější známý sourozenecký hash kořene Merkle lze získat voláním požadavku eth_getProof pomocí standardního RPC na "origin chain".
· Poté je jednoduše odešlete k ověření podle nejnovějšího známého blokového hashe uloženého v seznamu v „cílovém řetězci“. Validátor vezme hodnotu (list ve stromu Merkle) a sourozenecký hash, aby přepočítal kořen Merkle a zkontroloval, zda se shoduje s kořenem uloženým v seznamu blokových hashů cílového řetězce.
(2) Starknet
Starknet používá důkaz o úložišti pro důvěryhodné zasílání zpráv napříč řetězci.
L2→L1 protokol zpráv
· Během provádění transakce Starknet odešle smlouva na Starknet zprávu L2→L1.
· Poté připojte parametry zprávy (obsahující smlouvu příjemce a související data na L1) k příslušné aktualizaci stavu (stromu hlavního úložiště).
· Zprávy L2 jsou uloženy na L1 smart kontraktu.
· Vyšle událost na L1 (uložte parametry zprávy).
· Adresa příjemce na L1 může přistupovat ke zprávě a používat ji jako součást transakce L1 opětovným poskytnutím parametrů zprávy.
· Cross-chain zprávy jsou uloženy v páteřním stromu.
L2 → L1
L1 → L2
(3) Optimismus
· Komunikace mezi L1 a L2 je zajištěna dvěma speciálními smart kontrakty nazývanými "messengers".
· Pro transakce z Optimismu (L2) do Etherea (L1) je nutné po zapsání kořene stavu poskytnout Merkleův důkaz o zprávě na L1. Poté, co se důkazní transakce stane součástí řetězce L1, začíná období chybové výzvy. Po této čekací době může kterýkoli uživatel „dokončit“ transakci spuštěním druhé transakce na Ethereu a odesláním zprávy do cílové smlouvy L1.
· Cross-chain zprávy jsou uloženy v páteřním stromu.
(4) Rozhodčí řízení
· Opakovatelné vstupenky jsou kanonickou metodou společnosti Arbitrum pro vytváření zpráv L1 až L2, tj. transakcí L1, které inicializují zprávy, které mají být provedeny na L2. Retryable lze odeslat na L1 za fixní poplatek (v závislosti pouze na velikosti jeho dat volání). Hlavní stavový strom se používá pro cross-chain komunikaci vlastních datových formátů v chytrých kontraktech. Odeslání opakovatelného lístku na L1 lze oddělit/asynchronně od provádění na L2. Retryables poskytují atomicitu mezi cross-chain operacemi. Pokud je požadavek na transakci L1 úspěšně odeslán (tj. nedojde k žádnému vrácení zpět), pak existuje silná záruka, že opakovatelné provedení na L2 bude nakonec úspěšné.
· Arbitrum má dva kmeny: Nitro řetězec je udržován ve formátu státního stromu Ethereum, což je strom Merkle. Assertion Tree ukládá stav řetězce Arbitrum potvrzený na Ethereu prostřednictvím „tvrzení“. Pravidla pro postup v řetězci Arbitrum jsou deterministická. To znamená, že vzhledem ke stavu řetězce a některým novým vstupním hodnotám existuje pouze jeden platný výstup. Pokud tedy strom důkazu obsahuje více listů, pak nejvýše jeden list může představovat platný stav řetězce.
· Systém Outbox společnosti Arbitrum umožňuje jakékoli smluvní volání z L2 do L1, to znamená, že zpráva je iniciována z L2 a nakonec provedena na L1. Zprávy L2 až L1 (neboli „odchozí zprávy“) mají mnoho společného se zprávami L1 až L2 (Retryable) společnosti Arbitrum, i když jsou zde některé významné rozdíly. Část stavu L2 řetězce Arbitrum – část, která je ověřena v každém RBlocku – je Merkle kořenem všech zpráv L2 až L1 v historii řetězce. Po potvrzení osvědčeného RBlocku (obvykle asi týden po důkazu) je kořen Merkle obsažený ve smlouvě Outbox zveřejněn na L1. Smlouva Pošta k odeslání pak uživatelům umožňuje spouštět jejich zprávy.
(5) Polygon zkEVM
· Bridge SC zkEVM používá speciální strom Merkle nazývaný Exit Tree pro každou síť účastnící se komunikací nebo transakcí aktiv.
· Používá kořeny Merkle (v samostatném stromě stavu) a diagram architektury mostu lze nalézt na githubu.
· Nasazení zkEVM Bridge SC provedlo několik změn na základě smlouvy o vkladu Ethereum 2.0. Například používá speciálně navržený Merkle strom pouze pro připojení, ale přijímá stejnou logiku jako smlouva o vkladu Ethereum 2.0. Další rozdíly se týkají základních hashů a listových uzlů.
· Hlavním rysem chytré smlouvy Polygon zkEVM Bridge je použití stromu odchodu a globálního stromu odchodu, kde kořen globálního stromu odchodu je hlavním zdrojem pravdivostního stavu. Existují tedy dva různí globální správci kořenového adresáře Exit pro L1 a L2 a samostatná logika pro Bridge SC.
(6) Posouvat
· Překlenovací smlouva nasazená na Ethereum a Scroll umožňuje uživatelům předávat libovolné zprávy mezi L1 a L2. Kromě tohoto protokolu pro zasílání zpráv jsme také vytvořili důvěryhodný přemosťovací protokol, který uživatelům umožňuje přemostit aktiva ERC-20 mezi L1 a L2. Za účelem odeslání zprávy nebo prostředků z Etherea do Scroll uživatel zavolá transakci sendMessage na smlouvě Bridge. Relé zaindexuje tuto transakci na L1 a odešle ji do sekvenceru pro zahrnutí do bloku L2. Na L2 bridge kontraktu je proces odesílání zpráv z Scroll back do Etherea podobný.
· Meziřetězcové zprávy jsou uloženy v běžných frontách zpráv. Sekvencer přijímá meziřetězcové zprávy z této fronty a přidává je do řetězce jako běžné transakce.
（7）zksync Era
Prohlášení: Tato část se týká pouze éry zksync a může se lišit od zasílání zpráv napříč řetězci na ZK Stack, modulárním rámci pro budování suverénních superřetězců ZK.
· Každý transakční balíček má samostatnou zprávu L2->L1.
· Není možné odesílat transakce přímo z L2 do L1. Můžete však posílat zprávy libovolné délky do Etherea ze zkSync Era a poté použít L1 smart kontrakty ke zpracování přijatých zpráv na Ethereum. zkSync Era má funkci potvrzení požadavku, která vrátí booleovský parametr indikující, zda byla zpráva úspěšně odeslána do L1. Získejte důkaz Merkle obsažený ve zprávě pozorováním na Ethereu nebo pomocí metody zks_getL2ToL1LogProof API zksync-web3.
· Pro L1→L2 smart kontrakt zkSync Era umožňuje odesílateli požádat o transakci na Ethereum L1 a předat data do zkSync Era L2.
· Překlenovací smlouva: https://github.com/matter-labs/era-contracts/blob/main/ethereum/contracts/bridge/L1ERC20Bridge.sol
4 Závěr
Cross-chain komunikace je nepostradatelná pro „must have“ aplikace pro hromadné přijetí blockchainu (např. cross-chain social recovery wallet popsaná v Buterinově článku). Většina cross-chain řešení, která se v současnosti používají, je navržena pro L1←→L2, aby pokryla funkci stažení. Tato řešení lze rozšířit na více blockchainů. Zároveň však lze implementovat pokročilejší řešení cross-chain komunikace, jako je „stav přímého čtení“, který vůbec nevyžaduje důkaz, nebo „důkaz úložiště“, který nevyžaduje důvěru. Pro většinu L2 je stále prostor pro rozvoj a pokrok v cross-chain komunikaci.