Stav kumulativních řešení interoperability

Jako nadšenec do ekosystému zaměřeného na rollup jsem se vždy zajímal o řešení, která zlepšují interoperabilitu rollupů. Navíc jediným důvodem, proč jsem vytvořil tuto výzkumnou zprávu, bylo podpořit poselství o důležitosti interoperability v této oblasti. Pak jsem si uvědomil, že psaní článků je skvělý způsob, jak upevnit své chápání určitého tématu a pomoci lidem je pochopit, a teď jsem tady.

Protože se každý den v kryptoměnách učí nové věci, mělo by se zdát zřejmé, že dnes vnímám vizi „souhrnná interoperabilita pro budoucnost Etherea“ – éru jako dost zastaralou. Z POV filozofie se stále řídím stejnou vizí** — rollup interoperabilita je pro budoucnost Etherea** naprosto klíčová a celý ekosystém by měl pracovat na řešeních, která jej vylepší. Z POV technologie jsem se však dozvěděl spoustu nových nápadů na toto téma a na některé věci jsem změnil názor.

Abychom porozuměli níže uvedenému materiálu, je užitečné mít základní znalosti o souhrnech a problému jejich interoperability. Pokud ne, můj článek „Dr. Dankshard aneb Jak jsem se naučil přestat se bát a milovat rollupy“ je skvělý úvod.

Merhaba!

Je večer 13. listopadu, první den Devconnect Istanbul . Jako velký fanoušek ZkSync jsem se rozhodl zúčastnit se zkSync Connect jako své první akce na tomto summitu, první v mém životě. Tam jsem potkal chlapa a společně jsme zamířili do „Mosyo Coffee“, jak je uvedeno na stránce Luma zkCafe. V té oblasti byli dva a to správné místo jsme našli až večer.

Bylo mnohem tmavší než na fotce výše a lil se liják. Zůstal jsem na okraji střechy, na které se nacházel food court, popíjel kávu, kterou jsme si zdarma koupili na Clave , a řekl jsem svému novému příteli o svém nápadu na projekt hackathonu.

Existují „miniúčty“: účty ERC-4337 , jejichž logikou ověřování není kontrola podpisu, ale existence hashe operace v jediném mostě doručené pošty na jeho L2. Hash musí být odeslán ze své nadřazené adresy v konkrétním zdrojovém řetězci. Rodičovská adresa je vaše hlavní chytrá peněženka na jakékoli L2 nebo Ethereum L1. Chcete-li komunikovat s jinou L2, musíte:

• Nasaďte na něj miniúčet a nastavte svou hlavní peněženku jako rodičovskou adresu. Nasazení může provést kdokoli; tedy může být financována protokolem nebo vaším poskytovatelem peněženky.

• Odešlete hash uživatelské operace, kterou chcete odeslat, do můstku doručené pošty na vašem L2 a nastavte ID cílového řetězce.

• Tento hash se sbalí s ostatními hash a odešle se do L1. Inteligentní smlouva na L1 předá tento balíček do cílové L2 a most doručené pošty rozdělí hash, aby je mini účty mohly číst.

• Odesílatel přidá ke svému hash malý poplatek, aby motivoval iniciátory transakcí na inteligentních kontraktech protokolu.

• Když hash dosáhne cílové L2, odešlete svou uživatelskou operaci do mempoolu AA na této L2. Využitím standardu ERC-4337 nemusíme znovu implementovat náš vlastní mini-účet mempool a protokol lze snadno integrovat do peněženek s již existující kódovou základnou.

  
  

Stručně řečeno, chtěl jsem vytvořit most založený na L1, který posílá transakce z chytré peněženky na vaší L2 do jakékoli L2, se kterou chcete komunikovat. Na hackathonu jsem to téměř implementoval, ale nemohl jsem to dokončit kvůli malým zkušenostem a práci sólo. Když to příteli vysvětlil, zeptal se mě:

Proč prostě nezmění síť ve své peněžence a nepoužije token bridge k přesunu potřebných prostředků do potřebné sítě?

Odpověděl jsem : Toto je absolutně možnost, pokud člověk používá peněženku EOA. Peněženky EOA fungují stejně ve všech sítích EVM a sdílejí stejnou adresu, takže ve všech můžete posílat transakce pouhou změnou sítě v nastavení peněženky.

Tato oblast však přechází na chytré účty založené na abstrakci účtů. Tyto účty nám umožňují programově přidávat do našich peněženek libovolné funkce, které chceme:

• Podpisy P256 umožňují používat zabezpečené čipy v našich telefonech k podepisování transakcí.

• Prostřednictvím sociálního zotavení můžeme přidat své příbuzné jako opatrovníky oprávněné získat zpět naše peněženky, čímž se vyloučí nebezpečné počáteční fráze.

• Technologie Paymaster nám umožňuje platit poplatek za plyn v jakémkoli tokenu nebo dokonce přimět někoho, aby poplatek zaplatil za nás .

• Když kvantové počítače začnou narušovat klasická schémata podpisů, stačí změnit schéma v našich AA peněženkách na kvantově bezpečné, aniž bychom museli vytvářet novou peněženku.

  
  

Tento seznam může pokračovat donekonečna, protože abstrakce účtů nám v podstatě umožňuje používat spustitelné programy jako plnohodnotné peněženky. To vše však něco stojí: nelze snadno migrovat své peněženky do jiného řetězce, protože kromě přesunu prostředků přes most to vyžaduje přemístění celého účtu se všemi klíči, strážci a nastaveními. V některých případech to může být příliš složité nebo dokonce nemožné; řekněme v souhrnech, které nepodporují předkompilaci P256 (použití tohoto podpisového schématu může být příliš drahé).

Proto jsem vytvořil ten protokol. V podstatě máte účty AA na mnoha L2. Chcete-li od nich odeslat transakci, musíte ověřit svůj záměr odesláním jeho hashe z vašeho hlavního účtu na konkrétním L2 na tyto „miniúčty“ prostřednictvím zasílání zpráv mostu L1. Ve skutečnosti se tímto způsobem nezbavíte více peněženek; jednoduše přesunete veškerou ověřovací logiku na jeden „rodičovský“ účet.

Dalším zajímavým detailem takového protokolu je, že umožňuje interoperabilitu nejen s L2, ale se všemi L1 (sidechainy), které mají zakotvené mosty s Ethereem – Polygon PoS, Ronin, Gnosis a Avalanche jsou to, co mě napadá. Byl však navržen jako protokol interoperability zaměřený na rollup , takže je to jen zábavný technologický fakt.

Zatímco myšlenka projektu byla docela chytrá, praktická realizace měla významnou nevýhodu: rychlost . Celý design se opírá o kanonické rollup bridge připojené k Ethereum L1. Rollup bridge jsou zvláštní v tom, že dokazují svůj stav svým chytrým kontraktům na Ethereum, aby zdědily jeho bezpečnost. Jak už možná víte, optimistické a ověření ZK jsou dva nejoblíbenější způsoby, jak toho dosáhnout.

Optimistické ověřování funguje tak, že se otevře „okno výzvy“, obvykle asi sedm dní, během kterého mohou vyzyvatelé poslat důkaz o podvodu , který ukazuje na jakoukoli neplatnou část transakční dávky. Pokud je tento důkaz platný, rollup přeorganizuje svůj blockchain, aby tuto dávku odstranil. Po sedmi dnech bez důkazů o podvodu je dávka automaticky považována za platnou a všechny zprávy a výběry jsou dokončeny v Ethereu.

Pravděpodobně už jste na to přišli. Kvůli sedmidennímu zpoždění zasílání zpráv do L1 je odesílání transakcí napříč řetězci z optimistického souhrnu hrozný nápad. Proč? Počkáte si na výměnu DEX týden? Co se do této doby stane s cenou?

Odesílání transakcí napříč řetězci do optimistického souhrnu je mnohem lepší. I když sekvencer OP Stack čeká několik bloků před zpracováním zprávy, aby se minimalizovala možnost přeorganizování, čekání několik minut na vaši transakci je již pro některé úkoly poněkud přijatelné.

Komunita Ethereum navíc v současné době pracuje na jednoslotové finalitě , díky které bude každý blok finalizován samostatně, takže bude nevratný do dalšího bloku. Po jeho implementaci bude zasílání zpráv z L1 do L2 trvat asi 12 sekund.

Hostování takových účtů na rollupech ZK by bylo lepší, ale stále nepříliš použitelné. Jak můžeme vidět ze statistik níže, ZKsync Era skončí za 21 hodin, Linea za 5 hodin, Starknet za 9 hodin atd.

Ale proč to tak je? Není generování důkazu ZK na výkonných clusterech rychlé? Stručně řečeno, existují dva problémy:

• Některé souhrny ZK, jako je ZKsync Era, nastavují zpoždění provádění, takže bezpečnostní rada má čas vrátit některé dávky v případě chyby v jejich systému důkazů. zkEVM jsou opravdu komplikované části technologie a kvůli této složitosti zatím není možné pravděpodobnostní předcházení chyb pomocí více systémů důkazů najednou.
• I když je ověření ZK důkazem ve srovnání s výpočty, které prokazuje, velmi lehké, ověření v řetězci je stále dost drahé. V závislosti na systému důkazu může trvat až milion plynu na jedno ověření. Vezmeme-li průměrnou cenu plynu 9 gwei a dnešní ceny ETH, jeden důkaz stojí asi 30 $ pouze za ověření na L1.
  • Moderní rollupy ZK minimalizují tyto náklady tím, že generují jeden důkaz pro mnoho dávek jednou za určitou dobu, ale to zpomaluje rychlost finality mostu. Generování dávky a její prokázání každý blok vydělá 30 $ za blok nebo 216 000 $ za den . Při 100 TPS je to asi 0,025 USD za transakci pouze za náklady na ověření. A také musíme vygenerovat důkaz a publikovat dávku na řetězci!

Čekat hodinu nebo dvě na transakci je stále příliš dlouhá doba. co s tím můžeme dělat?

Nejprve zapomeňme na můj osm měsíců starý projekt hackathonu a pokusme se odstranit mentální model, že každou transakci je potřeba iniciovat z naší hlavní chytré peněženky. Proč vůbec potřebujeme sdílet naši logiku chytré peněženky v každém souhrnu? Proč prostě nevygenerujeme dočasné EOA, nepřekleneme tam finanční prostředky z naší hlavní chytré peněženky, neuděláme nějakou práci, kterou chceme udělat, a nepřekleneme to, co zbylo?

Moje Clave (nebo jakákoli chytrá peněženka, kterou používáte) má Secure Enclave podepisování a sociální obnovu, takže tam mohu být vždy v bezpečí o své prostředky, i když ztratím telefon. A koho zajímá, co se stane s těmi dočasnými účty? Už jsem si s nimi udělal své; všechny prostředky jsou teď na mém Clave.

Tento přístup má však zásadní problém: předpoklad, že nemůžete pravidelně používat stejnou peněženku na jiných řetězcích, značně omezuje počet úkolů, které na nich můžete dělat. Například nemůžete:

• Vytvořte vklad na místní platformě půjček , protože jej nemůžete migrovat do své hlavní sítě (v tomto případě ZKsync Era)
• Získejte tokeny, které nemají zastupitelný ekvivalent ve vaší hlavní síti (např. pokud jsou nativně raženy v této síti)
• Zúčastněte se místního DAO, protože vaše hlasy musí zůstat na tomto dočasném účtu.

V podstatě vše, co můžete jako uživatel udělat, je rozdělit prostředky více příjemcům bez přemostění pokaždé a získat lepší likviditu pro swap na token, který lze přemostit zpět do vašeho hlavního řetězce.

Aby byly tyto peněženky užitečné, musíme k nim přistupovat pomocí stejných pravidel, která používáme na našich hlavních chytrých peněženkách – bezpečné enklávy, sociální obnova atd. Vracíme se tedy k výše uvedené myšlence a její neproveditelnosti. Existuje však proveditelné paliativní řešení , které může těmto miniúčtům poskytnout pouze obnovovací vlastnosti naší hlavní peněženky:

Vytváříme stejné miniúčty popsané výše, ale umožňujeme jedním klíčem odesílat transakce přímo z nich. Naše nadřazená peněženka nyní může tento klíč změnit prostřednictvím mostu založeného na L1 nebo přimět miniúčet, aby jej načetl ze stavu nadřazené L2. Tímto způsobem, pokud dojde ke ztrátě dočasného klíče, může nadřazená peněženka iniciovat změnu klíče prostřednictvím pomalého, ale atomového mostu založeného na L1.

Atomicita — vlastnost akce, která neumožňuje její selhání během provádění. Buď to nebylo zahájeno, nebo bylo hotovo. Mosty založené na L1 jsou atomické, protože zpráva nemůže být ztracena, pokud je odeslána. Objednání, dostupnost a pravost jsou zaručeny Ethereum L1.

Tohle je mnohem lepší! Běžné transakce nyní potřebují čas pouze na přemostění tokenů. Poté, co jsou tokeny v cíli, je odesílání transakcí tak rychlé, jako by to byl váš hlavní řetězec. Pokud klíč ztratíte, budete muset počkat několik hodin až sedm dní, v závislosti na řetězci vaší mateřské peněženky, ale nebudete jej používat příliš často, takže kompromis je pro většinu případů použití přijatelný. Také je možné jej implementovat do peněženek i dnes. Dokonce jsem vytvořil vlastní implementaci , ale ta není v žádném případě bezpečná ani produkčně připravená a je určena pouze pro účely vizualizace.

Podobná technika se používá v platformách Web3 pro obchodování futures: schválíte token v páru (obvykle USDC) k chytré smlouvě a přiřadíte dočasný klíč pro útratu, který je uložen na frontendu platformy. To umožňuje uživatelům provádět rychlé akce, aniž by každou akci podepisovali svou hlavní peněženkou. Pokud změníte své zařízení nebo vymažete data v prohlížeči, můžete pouze znovu přiřadit klíč pomocí hlavní peněženky.

Ale stejně jako u všeho v krypto, ani tento přístup není dokonalý. Má to dvě nevýhody:

• I když miniúčty mohou být kompatibilní s ERC-4337 a podporovat tak všechny jeho funkce, jako je dávkování, paymasters, limity útraty atd., tyto funkce se již nedědí z nadřazeného účtu. Ve skutečnosti rodičovský účet funguje pouze jako jediný opatrovník pro obnovení sociálního zabezpečení pro mini účet, ale opatrovníkem je samotný uživatel.
• Přemostění tokenů musí být provedeno pomocí externích mostů. S iniciací cross-chain transakce můžeme nést naše tokeny se zprávou a přijímat je prakticky 1:1 atomovým způsobem. U tohoto řešení však toto již nepřichází v úvahu, takže externí přemostění je jedinou rychlou možností.

I když moderní mosty dokážou převést finanční prostředky během několika sekund , a) berou si poplatek, který může být při velkých převodech strašně vysoký , b) nejsou atomické a nedědí bezpečnostní vlastnosti Etherea. Je zvláště důležité vzít na vědomí bezpečnostní vlastnosti blockchainových mostů .

Použití externích mostů k přenosu tokenů je do jisté míry přijatelné, na rozdíl od jejich použití k předávání zpráv pro provozování mini účtů. Důvodem jsou jejich nejhorší případy, pravděpodobně kvůli útoku na ně:

• Při přemostění tokenů je nejhorší, co se může stát, že neobdržíte tokeny, které jste poslali. V takovém případě ztratíte X žetonů, které jste chtěli přemostit, a přejdete na jiný most.
• Při zasílání zpráv napříč účty nejhorší, co se může stát, je, že všechny vaše miniúčty mohou být ukradeny předáváním zpráv vydávajících se za někoho jiného přes most. V takovém případě přicházíte o své peněženky na všech řetězcích s celou jejich hodnotou, kromě vašeho hlavního.

Spoléhat se na externí můstky pro přemostění tokenů je jako takové do značné míry možností, pokud neexistuje účinný způsob, jak je přemostit atomovým způsobem pomocí L1. Toto je ve skutečnosti možnost, kterou dnes používá mnoho uživatelů interagujících s rollup řetězci.

Předpokládejme, že chceme ověřovat všechny transakce na jednom místě, například nativně převádět tokeny mezi účty nebo ověřovat podpisy pomocí jedinečné předkompilace. V tom případě čelíme pomalé finalitě dnešních ZK rollupů. Vraťme se na chvíli k zamyšlení nad tím, co lze zlepšit předchozí technikou.

Proč mají souhrny pomalou finalitu mostu? Jako cíl si vezmeme souhrny ZK, protože u těch optimistických je důvod již zřejmý:

• ZK proof systémy pro plnohodnotná VM prostředí jsou komplikované, zvláště pokud prostředí není ZK-friendly (EVM). Je tedy velká šance, že budou obsahovat chyby. Systémy více nátisků tomu mohou zabránit, ale jejich implementace je velmi komplikovaná a generování více nátisků pro jednu dávku může být příliš pomalé a drahé. Jako náhradní řešení umožňují souhrnné týmy zpoždění provádění, což jim umožňuje v případě nouze vrátit řetězec zpět. To je to, co zpomaluje finalitu mostu v některých souhrnech (např. ZKsync Era).
• Navrhování nového stavu a prokázání ZK L1 jsou docela drahé úkoly, takže pro minimalizaci nákladů to rollup sekvencery dělají každých pár hodin, spíše než každý blok.

Existuje však výjimka; Scroll navrhuje stav přibližně každou minutu , ale a) ověření se stále provádí každých několik hodin, takže zůstane neověřeno, a b) rolování je jedním z nejdražších souhrnů, které se dnes používají.

Pokud to přeformulujeme ještě jednodušeji, problémy jsou prokazování nákladů a ověřování nákladů. Podívejme se na každý problém a způsoby jeho řešení.

Naším úkolem je v podstatě zajistit, aby naše chytrá peněženka na rollupu rychle spolupracovala s ostatními rollupy bez dalších předpokladů důvěry, které přináší externí mosty. Chytré peněženky se obvykle skládají z několika obvyklých funkcí AA – paymasters, sociální obnova, zabezpečené enklávy, limity útraty atd., a hlavní operace, která nám z nich umožňuje odesílat transakce v řetězci.

Proč potřebujeme hlavní operaci, když chceme použít ostatní rollupy z naší peněženky? Protože je pravděpodobně hostován na víceúčelovém rollupu – Arbitrum, Base, ZKsync Era – a my chceme na tomto rollupu také komunikovat s uživateli a inteligentními smlouvami.

V tomto konkrétním případě by dávalo smysl jednoduše použít externí token bridge. Stačí úkol nahradit například interakcí s dApp ve stejném souhrnu a dalším.

Tato víceúčelovost je to, co zavádí složitost systému důkazů souhrnů. Ověření stavu celého virtuálního stroje se spoustou chytrých smluv a transakcí probíhajících každou sekundu je docela náročný úkol. Chceme provádět dva typy úloh, které vyžadují zcela odlišnou sadu funkcí v kumulaci: pro transakci v řetězci je to rychlé začlenění L2, nízké poplatky L2 a široká funkčnost virtuálního počítače a pro multi kumulativní transakci , je to rychlá finalita mostu.

Ale co když se prostě zbavíme virtuálního stroje a vytvoříme souhrn, který zvládne pouze chytré účty a zasílání zpráv ostatním L2? Vitalik Buterin navrhl podobnou techniku zhruba v době Devconnect Istanbul nazvanou „souhrny klíčů“. Diskutujeme o tom dále.

Souhrny úložiště klíčů

Cílem je vytvořit souhrn ZK, který může ukládat pouze klíče účtu a měnit je pomocí jiného klíče. Tento souhrn přesune kořen stromu Merkle, který obsahuje všechny tyto klíče, do L1. Když pak budete chtít odeslat transakci z jednoho z vašich chytrých účtů na L2, vygenerujete Merkle důkaz vašeho aktuálního klíče a váš účet jej ověří proti kořenovému adresáři úložiště klíčů dostupnému na L1. Nyní zná váš klíč a může jej použít k ověření vašich podpisů.

Takový rollup je velmi jednoduchý a lze snadno implementovat vícenásobné kontrolní systémy, takže klíče v něm uložené jsou ve skutečnosti stejně bezpečné jako L1.

Kromě původního designu Vitalik existují tři hlavní návrhy pro souhrny úložiště klíčů:

• Scrollův přístup je ukládat data úložiště klíčů na L1, ale umožnit je aktualizovat z jejich souhrnu zkEVM. Za tímto účelem zavádějí předkompilaci L1SLOAD, která umožňuje levné čtení úložiště L1. Účty AA na jiných L2 pak mohou číst tato data a synchronizovat jejich konfiguraci – klíče, opatrovníky atd.
• Základní tým zkoumá techniku, kde je na L1 uložen pouze kořen stavu, ale transakce jsou sekvenovány pomocí dat volání, takže strom lze vždy znovu vytvořit. Očekává se, že účty na L2 budou získávat aktuální klíče pomocí důkazů Merkle.
• Design Stackru je velmi podobný designu Base nebo Vitalik, ale využívá svůj vlastní rámec „mikro rollupů“ se specializovanými minimálními VM.

Obecně řečeno, liší se v počtu úkolů delegovaných na zpracování mimo řetězce (jinými slovy, kolik věcí je na L2) a v detailech jejich implementace.

Tuto myšlenku můžeme dále rozšířit tím, že budeme manipulovat nejen s klíči , ale také s celou logikou chytrého účtu . Ani to by nebylo o moc výpočetně náročnější; v podstatě musíme zvládnout pouze tyto úkoly:

• Odesílání dat do L1: Účty v kumulativním úložišti klíčů musí být schopny informovat L1 o svém transakčním záměru. Uložení celé transakce na L1 není nutné; něco jako kořen Merkleho stromu se všemi hashemi uživatelských operací by stačilo. K odeslání transakce z miniúčtu pak stačí načíst kořen z cílové L2 a prokázat, že určitá operace AA byla skutečně vyžádána z nadřazeného účtu.

• Kontroly podpisu: Uživatel podepíše hash uživatelské operace, kterou chce provést v určitém souhrnu. Kumulativní úložiště klíčů ověří podpis, aby prokázal záměr, a přidá hash do stromu, aby jej pak poslal do L1. Stačí několik podpisových schémat, jako je ECDSA , P256 a kvantově bezpečná .

• Sociální zotavení: Nechte ostatní, záměrně vybrané účty, nazývané „strážci“, hlasovat pro klíčovou změnu na uživatelském účtu. Uživatel může nastavit strážce a práh a požádat je o obnovu v případě ztráty klíče. Můžeme také implementovat obnovování založené na vetu nebo alternativní schémata opatrovníků, jako je ZK-Email , ZK-OTP nebo Web Proofs , abychom rozšířili sociální obnovu mimo uživatele souhrnu.

• Pravidla útraty: V případě krádeže peněženky mohou pravidla útraty kontrolovaná opatrovníky výrazně snížit potenciální ztráty, než uživatel peněženku získá. Tato funkce je také užitečná při šetření finančních prostředků nebo například při výrobě peněženek pro děti – rodiče mohou poslat příspěvek a omezit jeho utrácení, aby se dítě naučilo šetřit.

• Zůstatky tokenů: Může se to zdát zbytečné, ale možnost ukládat krypto uvnitř souhrnného úložiště klíčů dramaticky zvyšuje bezpečnost aktiv uživatelů tím, že je nelze rozdělovat do více mini účtů. Umožňuje také mnoho funkcí, které zlepšují uživatelský zážitek:

• Paymasters: Souhrn může nabízet bezplatné transakce k přilákání nových uživatelů nebo jim umožnit platit poplatek jakýmkoli tokenem, nikoli pouze ETH. Lze implementovat i složitější logiku paymaster – sekvencer si například může vzít poplatek ze swapu na jiném řetězci, když je přemostěn zpět do kumulativního úložiště klíčů.

• Interní převody tokenů: Kromě okamžitého odesílání prostředků mezi uživateli kumulativních operací jsou přímé převody užitečné také pro implementaci přemostění založeného na záměru s jinými kumulativními nástroji, které mají příliš pomalou konečnost na to, aby bylo možné použít L1 k přemostění z miniúčtu na nadřazený účet v kumulativním úložišti klíčů. Tímto způsobem může kumulativní úložiště klíčů v podstatě fungovat jako centrum pro levný přenos tokenů mezi miniúčty na desítkách různých L2.

  
  

Takový systém je technicky mnohem jednodušší než úplný VM uvnitř souhrnu, takže je možné generovat nátisky pro více systémů nátisků současně a složitost generování nátisků bude stále mnohem menší.

Důkazní ověření je však stále problém. Jak jsme spočítali dříve, jeho cena plynu může být až 1 milion plynu nebo ~ 25-50 $, v závislosti na ceně plynu. Tato cena je pevná a nezávisí na počtu transakcí v dávce. To znamená, že pokud je transakcí příliš málo, poplatek za každou transakci může být velmi vysoký. Existují dva hlavní způsoby, jak tyto náklady snížit:

Zarovnaná vrstva

Aligned je EigenLayer AVS, který využívá operátory resakingu k levnému ověření důkazů ZK. Pokud neznáte EigenLayer, toto je zjednodušené shrnutí toho, jak se ověřují důkazy v Aligned:

• Uživatel odešle požadavek na ověření do sítě a zaplatí za něj poplatek;

• Vyrovnaní operátoři, z nichž každý je validátorem Etherea s vázanými vklady, ověřují důkaz na svých uzlech a podepisují jeho platnost;

• Když 2/3 operátorů podepíší důkaz, je agregovaný podpis odeslán a ověřen na Ethereum L1.

• Pokud neplatný důkaz dosáhne platnosti, validátoři, kteří se za něj podepsali, mohou být seříznuti ověřením v řetězci. Tímto způsobem získá důkaz ekonomickou jistotu rovnající se 2/3 celkového podílu zarovnaných operátorů.

  
  

Tento přístup má zjevnou nevýhodu – Ethereum již nezaručuje platnost důkazu. Pokud je TVL můstku rollupu vyšší než 2/3 celkové sázky Aligned, útok na něj se stává ziskovým. A jelikož se bavíme o latenci finality 1-2 bloky, nemůžeme útoku optimisticky zabránit.

To však může být relativně bezpečná možnost, pokud se souhrn příliš nezvětší. Když se tak stane, transakční poptávka by již mohla vyplatit ověření L1. Podle dokumentů stojí ověření důkazu ZK pomocí Aligned asi 3000 plynu, což je téměř zdarma i pro Ethereum L1.

Důkaz agregačních vrstev

Pokud je vám nepříjemné zavádět do systému další předpoklady důvěry nebo se váš protokol již stal příliš velkým, ale jeho transakční poptávka nikoli, existuje alternativa.

Týmy ZK a rollup nedávno začaly aktivně pracovat na protokolech pro agregaci důkazů. Pokud nejste příliš obeznámeni se ZK, agregace důkazů je, když důkaz ZK prokazuje platnost jiného důkazu ZK (který může naopak dokazovat další důkaz atd.), čímž je „agreguje“ do jediného důkazu a v podstatě přesunout všechny své náklady na ověřování do nákladů na prokazování. Zbývá ověřit jediný důkaz ZK na řetězci a ujistit se o platnosti všech ostatních důkazů ZK, které prokazuje. Fuj!

Ověření ZK na řetězu.

Agregace důkazů má smysl tam, kde jsou náklady na ověřování vyšší než prokazování agregace důkazů. To znamená, že agregace se stává ziskovou, pokud jsou náklady na vytvoření důkazu pro deset důkazů a jeho ověření nižší než na nezávislé ověření těchto deseti důkazů. To je ještě užitečnější v Ethereum L1, které je silně omezeno výpočetní kapacitou. V závislosti na systému nátisku může celý blok obsahovat pouze asi 100 ověření nátisků , s výjimkou všech ostatních činností v řetězci.

Obecně existují dva typy protokolů agregace důkazů:

• Obecná (univerzální) agregace: Takové projekty obvykle podporují několik nejoblíbenějších protokolů ZK (Groth16, Halo2, Plonky), nad nimiž je postavena většina obvodů ZK a jejich zpracování je zpoplatněno. dApps, kteří potřebují důkazy, pak odhalí data z protokolu a zpracují je sami. Systém Universal Proof Aggregation společnosti Nebra , který je v současné době ve vývoji, přesně toto dělá. Aligned také pracuje na takzvaném „pomalém režimu“ ověřování , což je ve skutečnosti také systém agregace důkazů.
• Agregace sdílených kumulativních mostů: Podobně jako sdílené sekvenování v optimistických kumulacích fungují kumulativní ZK se svými zásobníky na sdílených můstcích s agregovanými kontrolami stavu pro každé kumulativní ZK v mostě. To nejen umožňuje synchronní skládání uvnitř zásobníku a la sdílené sekvenování, ale také minimalizuje náklady na ověření nátisku. Možná jste slyšeli o Polygon's AggLayer nebo ZKsync's Hyperbridge , což jsou sdílené rollup bridge, které fungují na důkazu agregace uvnitř mostu.

Výhody univerzálních agregačních systémů spočívají v tom, že jsou projektově agnostické a specializují se pouze na samotný proces agregace, což otevírá poměrně rychlé ověřování důkazů a nízké náklady. Je také pravděpodobné, že nebude mít cvičná kola kvůli nedostatku můstku.

Agregované kumulativní mosty jsou zase užitečné pro kumulativní úložiště klíčů, aby bylo možné synchronně skládat s již existujícím kumulativním zásobníkem. Například podle L2BEAT je v současné době 13 projektů postaveno pomocí Polygon CDK a 11 používá ZK Stack. Když se všechny připojí ke sdílenému agregačnímu můstku, připojení kumulativního úložiště klíčů k jednomu z nich otevře bezproblémovou interakci s mnoha L2, aniž byste se dotkli L1. Aby to fungovalo, musí most podporovat jinou logiku přechodu stavu pro své L2, protože logika kumulativního úložiště klíčů se v něm liší od ostatních L2.

Tyto mosty jsou však obvykle upgradovatelné a kontrolovány jeho DAO nebo bezpečnostní radou. Rollup projektům úložiště klíčů nemusí vyhovovat, když se vzdávají své suverenity operátorům mostu, ke kterému jsou připojeni. Mosty mohou také zavádět zpoždění provádění jako preventivní opatření pro tréninková kola, podobně jako nyní funguje ZKsync Era, což v podstatě zabíjí veškerou efektivitu tohoto návrhu souhrnného úložiště klíčů.

Tímto způsobem mohou kumulativní úložiště klíčů, stejně jako jakékoli jiné kumulativní soubory ZK, minimalizovat náklady na ověření důkazů a dokonce je kombinovat se synchronní komponovatelností s již existujícím kumulativním zásobníkem.

Efektivní přemostění založené na záměrech pomocí souhrnů „Keystore+“.

Jak již bylo zmíněno, přemostění z L2 do L1 není jediným problémem. Většina rollup sekvencerů také aplikuje zpoždění na předávání zpráv z L1 do L2. Je to proto, že když je vytvořen blok Ethereum, není ještě konečný a lze jej zvrátit během následujících ~64 bloků (dvě epochy, asi 13 minut). K těmto reorganizacím dochází kvůli latenci sítě, což způsobuje, že se některé návrhy objevují v síti příliš pozdě, když je některé uzly již považují za zmeškané.

Přestože většina reorganizací není hlubší než dva bloky (před dvěma lety se ve zprávách dokonce objevila sedmibloková reorganizace) , týmy pro souhrnné operace stále nechtějí riskovat v souvislosti se zmeškanými zprávami a uplatňovat zpoždění při přemostění z L1. Tato zpoždění jsou u některých souhrnů jen asi 1 minutu ( OP Stack , ZK Stack ), ale mohou být až 6 minut, jako v Arbitrum , nebo dokonce požádat o konečnost L1, jako v Linea .

Komunita Ethereum aktivně pracuje na Single-Slot Finality , díky které bude každý blok finalizován nezávisle, nikoli jednou za epochu. Ale můžeme s jistotou říci, že se neplánuje další upgrade Pectra v Q1 2025, takže bude trvat nejméně rok, než bude implementován SSF.

Pokud týmu implementující tento rozšířený návrh kumulativního úložiště klíčů nevyhovuje taková latence transakce, může implementovat paliativní řešení popsané výše. Každý miniúčet má klíč autorizovaný k odesílání transakcí nebo využívá statický klíč z úložiště klíčů (podle původního návrhu Vitalika), ale správa účtu je stále na hlavním účtu úložiště klíčů. Po implementaci SSF na L1 může souhrn odstranit klíče autorizovaných výdajů a uživatelé získají celou funkci přizpůsobení AA bez výrazného snížení rychlosti.

Tady souhlasím s Alexem; 15 sekund latence je absolutně přijatelné, zejména proto, že operace je atomická poté, co je dokončena kumulativní transakce úložiště klíčů na L1. Pokud mluvíme o převodech tokenů, peněženky příjemců mohou dokonce implementovat stav „Nevyřízeno“ na úrovni uživatelského rozhraní.

Převody cross-rollup tokenů však stále představují problém. Pokud implementujeme trezory tokenů uvnitř kumulativního úložiště klíčů, přenos tokenů z něj bude trvat 1 až 15 minut v závislosti na kumulativním souboru pro příjemce. Pokud tak neučiníme, rozdělení zůstatků uživatelů na miniúčty na více L2 může představovat bezpečnostní rizika a dokonce uzamknout některá aktiva do nelikvidních L2, jejichž přemostění může stát příliš mnoho nebo trvat příliš dlouho.

Alternativně můžeme do souhrnu integrovat most založený na záměru a nasadit jej na všechny ostatní souhrny nebo dokonce znovu použít existující infrastrukturu, jako jsou protokoly vyhovující ERC-7683 . V další části stručně probereme mosty záměrů.

Co je most založený na záměru?

Většina existujících cross-chain mostů je založena na protokolech zasílání zpráv. Například Stargate používá LayerZero k předávání zpráv o vkladech cílovým řetězcům a spoléhá se na ni jako na zdroj důvěry. Když pošlete žetony přes takové mosty, uzamknou vaše žetony na jedné straně a pošlou zprávu o vašem vkladu na druhé straně a tamní trezor vám odemkne příslušné množství žetonů.

Mosty založené na záměru zase neposílají zprávy mezi dvěma řetězci. Místo toho jsou odesílané prostředky uzamčeny v trezoru jako „objednávka napříč řetězci“ a poté může kdokoli splnit objednávku odesláním požadovaného množství tokenů v cílovém řetězci. Ten, kdo objednávku vyplní, si pak může nárokovat uzamčené tokeny ze zdrojového řetězce, když je trezor v něm informován o konečném stavu cílového řetězce a může potvrdit převod.

To se může stát buď čekáním na cíl cílového řetězce (most) nebo prostřednictvím nějakého externího protokolu Oracle. Například Across používá optimistický orákulum UMA k načtení stavu ještě nedokončených L2.

V tomto scénáři se jako zdroj důvěry používá Ethereum L1. Některé protokoly, jako je Across, místo toho používají externí věštce. Skutečný design se může u stávajících projektů lišit; zobrazí se pouze obecná myšlenka.

Můžeme použít stejný design pro tyto rozšířené kumulativní úložiště klíčů k implementaci důvěryhodného, rychlého a levného obousměrného přemostění mezi úložištěm klíčů a všemi ostatními L2. Rychlé přemostění umožňuje , aby objednávky na základě záměru od ostatních L2 byly téměř zdarma, protože prokázání splnění na L2 trvá jen několik minut.

Objednávky z úložiště klíčů budou pravděpodobně také levné, protože likvidita na L2 může být relativně rychle dodávána prostřednictvím úložiště klíčů. Tímto způsobem se takový návrh kumulativního úložiště klíčů může stát centrem pro přemostění založené na záměru, které uživatelům umožní odesílat transakce okamžitě, nikoli během několika minut, přičemž za přemostění neplatí téměř nic. Rollup tým může také dodat likviditu pro přemostění úložiště klíčů 1:1, a to by ho nestálo mnoho.

Jednotný název ENS pro všechny řetězce

Představte si, že máte jediné uživatelské jméno.eth , které se přenese na všechny vaše miniúčty bez ohledu na to, v jakém řetězci je příjemce. Tento design to umožňuje. Jak?

Protože již známe adresu našeho hlavního účtu úložiště klíčů, můžeme použít továrny na více řetězců a CREATE2 k tomu, aby byly adresy našich miniúčtů stejné ve všech řetězcích EVM ekvivalentních s bajtovým kódem, dokonce včetně Ethereum L1. Poté nastavíme jednotnou adresu v ENS resolveru a naše jméno funguje ve všech EVM L2.

Existují však dva výjimečné případy:

• Bytecode neekvivalentní EVM, jako je ZK Stack. Můžeme jim vygenerovat vlastní adresu podle jejich pravidel CREATE2 a přidat ji do ENS s jejich řetězovými identifikátory podle ENSIP-11 .
• Jiné než EVM L2, jako je naše úložiště klíčů. Logika je pro ně stejná, ale místo toho přidáme jejich vlastní adresy do ENS podle ENSIP-9 .

I když je tento přístup velmi přátelský k uživatelskému prostředí, používá spoustu drahých výpočtů a úložiště na L1, protože jména a adresy jsou uloženy na překladačích L1. Tento problém lze vyřešit pomocí CCIP Read , ale přišel jsem s jinou, efektivnější logikou rozlišení v řetězci:

Každý účet v úložišti klíčů je registrován a indexován podle názvu hash jeho názvu ENS (registrovaného pod jediným názvem ENS pomocí vlastního překladače). Když je vyřešena její subdoména, smlouva překladače zkontroluje, zda účet s takovým namehash existuje v souhrnu, a použije namehash ke generování adres miniúčtů CREATE2 .

Když jsou tyto nasazeny, požádají L1 o data úložiště klíčů patřící k namehash, se kterým byly nasazeny. Může to být samotný záměr transakce nebo jen aktuální podpisový klíč, v závislosti na implementaci úložiště klíčů. Tímto způsobem získáme účty úložiště klíčů, z nichž každý má v každém kumulativním spojení název ENS a jeho miniúčty. Tyto miniúčty se zase budou spoléhat na tento název ENS při ověřování transakce pomocí kumulativního úložiště klíčů.

**

Mechanismy sekvenování v souhrnech „Keystore+“.

Protože konečnost mostu na rozšířeném kumulativním úložišti klíčů má být několik bloků L1, můžeme se také úplně zbavit centralizovaných sekvenátorů a přeměnit je na založený kumulativní soubor. Jak jsme již diskutovali dříve, ~12 sekund transakční rychlosti je pro průměrného uživatele přijatelná, ale sekvenování založené na sekvenování by učinilo souhrn mnohem odolnějším vůči cenzuře a jednotlivým bodům selhání.

Stojí za zvážení, že při sekvenování založeném na sekvencích budou interní transakce trvat stejně dlouho jako ty externí (kromě času na dosažení L2). To může být pro některé týmy nepřijatelné, protože díky centralizovanému sekvenování jsou všechny interní operace okamžité.

Alternativní řešení kumulativní interoperability aneb: Proč jsem nezmínil sdílené sekvenování

Celý článek jsem napsal o rollupech ZK a technologii ZK. Optimistické rollupy totiž v zásadě nemohou mít rychlou objektivní finalitu a taková vlastnost je dosažitelná pouze pomocí ZK. Dnešní optimističtí rollupové chápou svou zapečetěnou pozici a aktivně zkoumají proveditelnost integrace návrhů zaměřených na validitu do svých zásobníků, proto například nedávné partnerství Optimism a RISC Zero .

Optimistický design je zásadně omezující v tom, že nikdy nezvládne interoperabilitu s jinými souhrny. Interoperabilita v rámci optimistického ekosystému se však rychle rozvíjí. Primární technologií pro zajištění vzájemné interoperability optimistických souhrnů je sdílené sekvenování . Jednoduše řečeno, toto je mechanismus, kdy sekvencer může sestavit dávku pro více rollupů současně. Pokud je jakákoli transakce v některém ze sekvenovaných souhrnů neplatná, lze celou dávku zpochybnit a vrátit zpět.

To dává všem šaržím v této „megadávce“ atomovou vlastnost – buď jsou platné všechny šarže, nebo žádná. To zase umožňuje atomovou synchronní složitelnost uvnitř dávky. Atomický – protože nic v dávce nemůže být neplatné, pokud je platné, synchronní – protože veškerá zasílání zpráv je uvnitř dávky, která je zpracována současně všemi uzly jejích souhrnů.

Tato technologie v podstatě promění všechny souhrny v určitém optimistickém zásobníku na jeden velký, rozstříhaný souhrn. Proč jen jeden zásobník a ne všechny? Protože aby to fungovalo, musí být rollupy připojeny k jedinému mostu. Každý zásobník má svůj vlastní most a neexistuje žádný spolehlivý způsob, jak vytvořit dávky ve více mostech současně. To znamená, že sdílené sekvenování umožňuje OP Mainnet bezproblémově spolupracovat s Base a Zora, ale ne Arbitrum nebo Metis, a naopak.

Taková konsolidace vytváří nebezpečnou situaci v souhrnném ekosystému. Nové souhrny mají možnost buď se připojit ke stávajícímu zásobníku a být s ním integrovány, ale ne s nikým jiným, NEBO stavět na vrcholu ZK a být integrovány s kýmkoli kromě zásobníku výše. Nyní neexistuje žádná taková volba, protože sdílené sekvenování ještě není k dispozici a každý OP Stack nebo Arbitrum Orbit rollup je nezávislý a má svůj vlastní most. Když se však zkonsolidují, vytvoří v rámci ekosystému dva pevné organismy, z nichž každý drží asi 40 % celkových L2s TVL .

"Dobře. Pokud budou držet drtivou většinu celkového TVL, proč se nezbavíme ZK a nepostavíme místo toho na ně?“

Za prvé, sdílené sekvencery jsou obrovským centralizačním ovladačem. Pokud spustíte sekvencer OP Mainnet, vaše dávky nebudou zahrnovat transakce z jiných souhrnů v zásobníku; vyděláte méně na poplatcích a nakonec budete zastíněni velkými komerčními sekvencery, které zvládnou celý stack ve svých dávkách.

Nejkritičtějším problémem však je, že v takovém případě se rollup ekosystém uzavře do oligopolních impérií , které sledují své vlastní zájmy, snaží se získat větší kontrolu nad kapitálem a polevují v technologickém pokroku v ekosystému. Pak bychom se museli vypořádat s tím, že Ethereum bude rozdrceno do disjunktní oblasti, kde záleží na PR a vnitrodruhovém boji, nikoli na technologiích, které skutečně mění svět.

„Vytvářejte nástroje, ne impéria . Impéria se snaží chytit a uvěznit uživatele uvnitř obezděné zahrady; nástroje plní svůj úkol, ale jinak spolupracují s širším otevřeným ekosystémem.“ — Vitalik Buterin

"V čem je agregování sdílených mostů v ZK lepší než optimistické sdílené sekvenování?"

Ve sdílených můstcích souhrnů ZK lze řazení provádět nezávisle na ostatních souhrnech v mostě. Každý rollup může mít svůj vlastní sekvencer nebo implementovat sdílené sekvenování. Navrhovatelé , kteří tvrdí výsledný stavový kořen po všech sekvenovaných dávkách a dokazují jej pomocí ZK, jsou těmi, kdo provádějí agregaci.

Navíc charakteristika relativně rychlé objektivní finality v rollupech ZK je neuzavře do jejich ekosystému, bez ohledu na to, jak velký roste nebo jak je centralizovaný. Když se ZK vyvine na úroveň, kdy lze rychle generovat velké nátisky zkVM pro více systémů nátisků, budou všechny kumulativní zásobníky založené na ZK spolupracovat téměř hladce, stejně jako výše popsané teoretické kumulativní úložiště klíčů odesílá transakce ve všech ostatních kumulativních záležitostech během L1. bloky.

"Ale jak to, že optimistické souhrny stále existují, když jsou tak zlé a v souhrnech ZK existuje alternativa?"

V rámci naší komunity výzkumníků a vysoce technických lidí panuje shoda v tom, že ZK je nejlepší škálovací řešení. A budete překvapeni, když si uvědomíte, že pro běžné uživatele a stavitele jsou optimistické rollupy mnohem lepší než ZK! jak to?

Pro uživatele : Existuje dobře zavedený ekosystém. Všechny platformy vědí, co je Arbitrum a Base, dApps mají vždy vysokou likviditu a UX je voňavé. Zkuste pojmenovat aplikaci na Base a okamžitě si vzpomenete na Friend.tech , Farcaster , Daimo , Time.fun (nyní exkluzivně pro Solana), různé kolekce NFT, ZKP2P. Dokonce i Mirror zpočátku podporoval pouze rollupy OP Stack pro ražbu. Zkuste pojmenovat aplikaci na ZKsync Era. Uhhh…

Pro vývojáře : Existuje absolutní ekvivalence Etherea, takže celá infrastruktura Etherea a EVM forků funguje hned od začátku. Kromě toho dokumentace pečlivě definuje a vysvětluje všechny zvláštnosti a nástroje optimistických rollupů. Existuje spousta tutoriálů, kurzů, maratonů, vztahů s vývojáři a tak dále.

Na druhou stranu existují rok staré zkEVM, z nichž ne všechny mají dokonce ekvivalenci bytecode. Všechny mají dlouhý seznam rozdílů a obtíží, když se na ně staví. Většinou jsou špatně zdokumentovány a existuje značná závislost na existující infrastruktuře, která je se sítěmi sotva kompatibilní. Auditování „kompatibilních“ virtuálních počítačů je velmi obtížné a drahé a nemáte ani ChatGPT, na který byste se mohli zeptat.

Pro uživatele: Rollupy ZK nemají žádný ekosystém. Neexistují žádné aplikace k použití, žádné sociální sítě, žádné oblíbené NFT nebo tokeny a veškerá aktivita se scvrkává na výsadkové hospodaření. Stěží najdete likviditu pro páry, které nejsou v top 10 ekosystému Ethereum, a DefiLlama začne ukazovat souhrny ZK, když vás omrzí rolování.

„Optimistické souhrny však ve skutečnosti vítězí díky kompatibilitě se stávající infrastrukturou. Jak je v něm mohou ZK rollupy porazit?“

Nemusíte zavádět ekvivalenci bytecode nebo předkompilaci blake2f , abyste na svou platformu přilákali vývojáře a aktivitu. Rollupy ZK v tom prý nejsou lepší. Místo toho v jejich rychlé finalitě a interoperabilitě, plně horizontální škálovatelnosti, zásadně vyšším zabezpečení a decentralizaci. To je to, co by mělo být využito v projektech v ekosystému rollupů ZK, aby byly v ekosystému výhodné.

Tento článek jsem napsal proto, abych dal dohromady kompletní obrázek všech těchto technologií, včetně rollupů ZK, které se v této oblasti objevily a vyvinuly, a ukázal, jak je lze použít k vyřešení dnešního nejdůležitějšího problému v oboru – rollup interoperability. Musíme přijmout ZK a jeho neomezené výhody. Musíme je využít ve svůj prospěch, abychom vytvořili věci, které nás přiblíží k tomu, aby se Web3 stal místem pro každého na světě.

Toto je možná největší srovnávací tabulka, jakou jsem kdy udělal. Není divu – v posledním roce přišla komunita Ethereum s mnoha novými nápady a technologiemi, které lze flexibilně kombinovat a manipulovat s nimi, aby vytvořila zcela nová řešení, která řeší nejpalčivější problémy v této oblasti, a to i se stávající technologií.

Ano, stále jsem přesvědčen, že kumulativní interoperabilita je nejpalčivějším problémem, který nám brání začlenit celý svět do Web3. Škálování již není tak naléhavé – 4844 nám umožňuje zvládnout až tisíc transakcí za sekundu, srovnatelné s finanční aktivitou v největších zemích světa; PeerDAS bude brzy k dispozici a toto ještě zvýší. Fragmentace však stále představuje vážnou hrozbu pro ekosystém Ethereum. Bez ohledu na to, jak velký roste, by se ekosystém neměl cítit jako tucet odlišných říší, ale jako jeden velký mechanismus. Tak odlišné, ale tak stejné.

Nejsme brzy a tento článek vám to má ukázat. Musíme využít všechny své síly k vývoji fungujících systémů, které pomohou gigantickému ekosystému L2 spolupracovat. To je možné právě teď. Brzy byste se měli moci zúčastnit jakéhokoli DAO a posílat jakákoli aktiva ENS, jejíž vlastník je od vás několik tisíc kilometrů. Zeměpisné hranice by neměly být nahrazovány digitálními.

Pokud se vám tato práce líbila, souhlasíte s její tezí, naučili jste se něco nového nebo chcete tuto zprávu šířit dál – sdílejte ji na sociálních sítích, zanechte své komentáře a více mluvte o důležitosti kumulativní interoperability. Děkuji za přečtení.

Poznámka autora: Verze tohoto článku byla dříve publikována zde .