Rollupy s nulovým vědomím (ZK-rollupy)

Rollupy s nulovým vědomím (ZK-rollupy) jsou řešení škálování na vrstvě 2 (L2), která zvyšují propustnost na Ethereum Mainnetu přesunem výpočtů a ukládání stavu offchain. ZK-rollupy dokážou zpracovat tisíce transakcí v dávce a poté na Mainnet odeslat pouze minimální souhrnná data. Tato souhrnná data definují změny, které by měly být provedeny ve stavu Etherea, a kryptografický důkaz, že jsou tyto změny správné.

Předpoklady

Měli byste si přečíst a pochopit naši stránku o škálování Etherea a vrstvě 2.

Co jsou rollupy s nulovým vědomím?

Rollupy s nulovým vědomím (ZK-rollupy) sdružují (neboli „rolují“) transakce do dávek, které jsou prováděny offchain. Offchain výpočty snižují množství dat, která musí být odeslána na blockchain. Operátoři ZK-rollupů předkládají souhrn změn potřebných k reprezentaci všech transakcí v dávce, místo aby posílali každou transakci zvlášť. Vytvářejí také , aby prokázali správnost svých změn.

Stav ZK-rollupu je udržován chytrým kontraktem nasazeným v síti Ethereum. K aktualizaci tohoto stavu musí uzly ZK-rollupu předložit důkaz platnosti k ověření. Jak již bylo zmíněno, důkaz platnosti je kryptografická záruka, že změna stavu navržená rollupem je skutečně výsledkem provedení dané dávky transakcí. To znamená, že ZK-rollupy potřebují k finalizaci transakcí na Ethereu poskytnout pouze důkazy platnosti, místo aby odesílaly všechna transakční data onchain jako optimistické rollupy.

Při přesunu prostředků ze ZK-rollupu na Ethereum nedochází k žádnému zpoždění, protože výstupní transakce jsou provedeny, jakmile kontrakt ZK-rollupu ověří důkaz platnosti. Naopak výběr prostředků z optimistických rollupů podléhá zpoždění, aby kdokoli mohl zpochybnit výstupní transakci pomocí .

ZK-rollupy zapisují transakce na Ethereum jako calldata. calldata je místo, kam se ukládají data zahrnutá v externích voláních funkcí chytrých kontraktů. Informace v calldata jsou publikovány na blockchainu, což komukoli umožňuje nezávisle rekonstruovat stav rollupu. ZK-rollupy používají kompresní techniky ke snížení objemu transakčních dat – například účty jsou reprezentovány indexem spíše než adresou, což šetří 28 bajtů dat. Publikování dat onchain představuje pro rollupy značný náklad, takže komprese dat může uživatelům snížit poplatky.

Jak ZK-rollupy interagují s Ethereem?

Řetězec ZK-rollupu je offchain protokol, který funguje nad blockchainem Etherea a je spravován onchain chytrými kontrakty Etherea. ZK-rollupy provádějí transakce mimo Mainnet, ale pravidelně odesílají offchain dávky transakcí do onchain kontraktu rollupu. Tento záznam transakcí je neměnný, podobně jako blockchain Etherea, a tvoří řetězec ZK-rollupu.

Základní architektura ZK-rollupu se skládá z následujících komponent:

1. Onchain kontrakty: Jak již bylo zmíněno, protokol ZK-rollupu je řízen chytrými kontrakty běžícími na Ethereu. To zahrnuje hlavní kontrakt, který ukládá bloky rollupu, sleduje vklady a monitoruje aktualizace stavu. Další onchain kontrakt (kontrakt ověřovatele) ověřuje důkazy s nulovou znalostí předložené producenty bloků. Ethereum tak slouží jako základní vrstva neboli „vrstva 1 (L1)“ pro ZK-rollup.

2. Offchain virtuální stroj (VM): Zatímco protokol ZK-rollupu žije na Ethereu, provádění transakcí a ukládání stavu probíhá na samostatném virtuálním stroji nezávislém na EVM. Tento offchain VM je spouštěcím prostředím pro transakce na ZK-rollupu a slouží jako sekundární vrstva neboli „vrstva 2 (L2)“ pro protokol ZK-rollupu. Důkazy platnosti ověřené na Ethereum Mainnetu zaručují správnost přechodů stavu v offchain VM.

ZK-rollupy jsou „hybridní řešení škálování“ – offchain protokoly, které fungují nezávisle, ale odvozují svou bezpečnost od Etherea. Konkrétně síť Ethereum vynucuje platnost aktualizací stavu na ZK-rollupu a zaručuje dostupnost dat za každou aktualizací stavu rollupu. V důsledku toho jsou ZK-rollupy podstatně bezpečnější než čistě offchain řešení škálování, jako jsou postranní řetězce (sidechains), které jsou samy zodpovědné za své bezpečnostní vlastnosti, nebo validia, která také ověřují transakce na Ethereu pomocí důkazů platnosti, ale ukládají transakční data jinde.

ZK-rollupy spoléhají na hlavní protokol Etherea v následujících ohledech:

Dostupnost dat

ZK-rollupy publikují stavová data pro každou transakci zpracovanou offchain na Ethereum. S těmito daty je možné, aby jednotlivci nebo podniky reprodukovali stav rollupu a sami validovali řetězec. Ethereum zpřístupňuje tato data všem účastníkům sítě jako calldata.

ZK-rollupy nepotřebují publikovat mnoho transakčních dat onchain, protože důkazy platnosti již ověřují pravost přechodů stavu. Nicméně ukládání dat onchain je stále důležité, protože umožňuje nezávislé ověření stavu L2 řetězce nevyžadující povolení, což následně umožňuje komukoli odesílat dávky transakcí, a brání tak škodlivým operátorům v cenzuře nebo zmrazení řetězce.

Onchain data jsou vyžadována pro interakci uživatelů s rollupem. Bez přístupu ke stavovým datům nemohou uživatelé dotazovat zůstatek na svém účtu nebo iniciovat transakce (např. výběry), které spoléhají na informace o stavu.

Finalita transakcí

Ethereum funguje jako vrstva vypořádání pro ZK-rollupy: L2 transakce jsou finalizovány pouze tehdy, pokud L1 kontrakt přijme důkaz platnosti. To eliminuje riziko, že by škodliví operátoři poškodili řetězec (např. ukradli prostředky rollupu), protože každá transakce musí být schválena na Mainnetu. Ethereum také zaručuje, že uživatelské operace nelze zvrátit, jakmile jsou finalizovány na L1.

Odolnost proti cenzuře

Většina ZK-rollupů používá k provádění transakcí, vytváření dávek a odesílání bloků na L1 „superuzel“ (operátora). I když to zajišťuje efektivitu, zvyšuje to riziko cenzury: škodliví operátoři ZK-rollupů mohou cenzurovat uživatele tím, že odmítnou zahrnout jejich transakce do dávek.

Jako bezpečnostní opatření umožňují ZK-rollupy uživatelům odesílat transakce přímo do kontraktu rollupu na Mainnetu, pokud se domnívají, že jsou operátorem cenzurováni. To uživatelům umožňuje vynutit si výstup ze ZK-rollupu na Ethereum, aniž by se museli spoléhat na povolení operátora.

Jak fungují ZK-rollupy?

Transakce

Uživatelé v ZK-rollupu podepisují transakce a odesílají je L2 operátorům ke zpracování a zahrnutí do další dávky. V některých případech je operátorem centralizovaná entita, zvaná sekvencer, která provádí transakce, agreguje je do dávek a odesílá na L1. Sekvencer v tomto systému je jedinou entitou, která má povoleno produkovat L2 bloky a přidávat transakce rollupu do kontraktu ZK-rollupu.

Jiné ZK-rollupy mohou rotovat roli operátora pomocí sady validátorů na bázi důkazu podílem (PoS). Potenciální operátoři vkládají prostředky do kontraktu rollupu, přičemž velikost každého staku ovlivňuje šance stakera na to, že bude vybrán k produkci další dávky rollupu. Stake operátora může být penalizován, pokud jedná zlomyslně, což ho motivuje k odesílání platných bloků.

Jak ZK-rollupy publikují transakční data na Ethereu

Jak bylo vysvětleno, transakční data jsou publikována na Ethereu jako calldata. calldata je datová oblast v chytrém kontraktu používaná k předávání argumentů funkci a chová se podobně jako paměť. Ačkoli calldata není uložena jako součást stavu Etherea, přetrvává onchain jako součást historických logů (opens in a new tab) řetězce Etherea. calldata neovlivňuje stav Etherea, což z ní činí levný způsob ukládání dat onchain.

Klíčové slovo calldata často identifikuje metodu chytrého kontraktu volanou transakcí a obsahuje vstupy do metody ve formě libovolné sekvence bajtů. ZK-rollupy používají calldata k publikování komprimovaných transakčních dat onchain; operátor rollupu jednoduše přidá novou dávku zavoláním požadované funkce v kontraktu rollupu a předá komprimovaná data jako argumenty funkce. To pomáhá snížit náklady pro uživatele, protože velká část poplatků za rollup jde na ukládání transakčních dat onchain.

Závazky stavu

Stav ZK-rollupu, který zahrnuje L2 účty a zůstatky, je reprezentován jako Merkleův strom. Kryptografický hash kořene Merkleova stromu (Merkleho kořen) je uložen v onchain kontraktu, což umožňuje protokolu rollupu sledovat změny ve stavu ZK-rollupu.

Rollup přechází do nového stavu po provedení nové sady transakcí. Operátor, který inicioval přechod stavu, je povinen vypočítat nový kořen stavu a odeslat jej do onchain kontraktu. Pokud je důkaz platnosti spojený s dávkou ověřen kontraktem ověřovatele, nový Merkleho kořen se stane kanonickým kořenem stavu ZK-rollupu.

Kromě výpočtu kořenů stavu vytváří operátor ZK-rollupu také kořen dávky – kořen Merkleova stromu zahrnujícího všechny transakce v dávce. Když je odeslána nová dávka, kontrakt rollupu uloží kořen dávky, což uživatelům umožňuje prokázat, že transakce (např. žádost o výběr) byla zahrnuta do dávky. Uživatelé budou muset poskytnout podrobnosti o transakci, kořen dávky a Merkleův důkaz ukazující cestu zahrnutí.

Důkazy platnosti

Nový kořen stavu, který operátor ZK-rollupu odesílá do L1 kontraktu, je výsledkem aktualizací stavu rollupu. Řekněme, že Alice pošle 10 tokenů Bobovi, operátor jednoduše sníží zůstatek Alice o 10 a zvýší zůstatek Boba o 10. Operátor poté provede hashování aktualizovaných dat účtu, znovu sestaví Merkleův strom rollupu a odešle nový Merkleho kořen do onchain kontraktu.

Kontrakt rollupu však automaticky nepřijme navrhovaný závazek stavu, dokud operátor neprokáže, že nový Merkleho kořen vyplynul ze správných aktualizací stavu rollupu. Operátor ZK-rollupu to provede vytvořením důkazu platnosti, stručného kryptografického závazku ověřujícího správnost dávkovaných transakcí.

Důkazy platnosti umožňují stranám prokázat správnost tvrzení, aniž by odhalily samotné tvrzení – proto se jim také říká důkazy s nulovou znalostí. ZK-rollupy používají důkazy platnosti k potvrzení správnosti offchain přechodů stavu, aniž by musely znovu provádět transakce na Ethereu. Tyto důkazy mohou mít podobu ZK-SNARK (opens in a new tab) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) nebo ZK-STARK (opens in a new tab) (Zero-Knowledge Scalable Transparent Argument of Knowledge).

Jak SNARKy, tak STARKy pomáhají potvrdit integritu offchain výpočtů v ZK-rollupech, ačkoli každý typ důkazu má své specifické vlastnosti.

ZK-SNARKy

Aby protokol ZK-SNARK fungoval, je nutné vytvořit společný referenční řetězec (Common Reference String, CRS): CRS poskytuje veřejné parametry pro dokazování a ověřování důkazů platnosti. Bezpečnost dokazovacího systému závisí na nastavení CRS; pokud se informace použité k vytvoření veřejných parametrů dostanou do držení škodlivých aktérů, mohou být schopni generovat falešné důkazy platnosti.

Některé ZK-rollupy se pokoušejí tento problém vyřešit pomocí ceremonie vícestranných výpočtů (MPC) (opens in a new tab), do které jsou zapojeni důvěryhodní jednotlivci, aby vygenerovali veřejné parametry pro obvod ZK-SNARK. Každá strana přispívá určitou náhodností (nazývanou „toxický odpad“) ke konstrukci CRS, kterou musí okamžitě zničit.

Důvěryhodná nastavení se používají, protože zvyšují bezpečnost nastavení CRS. Dokud alespoň jeden poctivý účastník zničí svůj vstup, je bezpečnost systému ZK-SNARK zaručena. Přesto tento přístup vyžaduje důvěru v to, že zúčastnění smažou svou vzorkovanou náhodnost a nenaruší bezpečnostní záruky systému.

Pomineme-li předpoklady důvěry, ZK-SNARKy jsou oblíbené pro svou malou velikost důkazu a ověřování v konstantním čase. Vzhledem k tomu, že ověřování důkazů na L1 představuje větší část nákladů na provoz ZK-rollupu, L2 používají ZK-SNARKy ke generování důkazů, které lze rychle a levně ověřit na Mainnetu.

ZK-STARKy

Stejně jako ZK-SNARKy, i ZK-STARKy prokazují platnost offchain výpočtů bez odhalení vstupů. ZK-STARKy jsou však považovány za vylepšení oproti ZK-SNARKům díky své škálovatelnosti a transparentnosti.

ZK-STARKy jsou „transparentní“, protože mohou fungovat bez důvěryhodného nastavení společného referenčního řetězce (CRS). Místo toho ZK-STARKy spoléhají na veřejně ověřitelnou náhodnost k nastavení parametrů pro generování a ověřování důkazů.

ZK-STARKy také poskytují větší škálovatelnost, protože čas potřebný k dokazování a ověřování důkazů platnosti roste kvazilineárně v závislosti na složitosti základního výpočtu. U ZK-SNARKů se časy dokazování a ověřování škálují lineárně v závislosti na velikosti základního výpočtu. To znamená, že ZK-STARKy vyžadují méně času než ZK-SNARKy na dokazování a ověřování, když se jedná o velké datové sady, což je činí užitečnými pro velkoobjemové aplikace.

ZK-STARKy jsou také bezpečné proti kvantovým počítačům, zatímco kryptografie eliptických křivek (ECC) používaná v ZK-SNARKách je obecně považována za náchylnou k útokům kvantových počítačů. Nevýhodou ZK-STARKů je, že produkují větší velikosti důkazů, jejichž ověření na Ethereu je dražší.

Jak fungují důkazy platnosti v ZK-rollupech?

Generování důkazu

Před přijetím transakcí provede operátor obvyklé kontroly. To zahrnuje potvrzení, že:

• Účty odesílatele a příjemce jsou součástí stavového stromu.
• Odesílatel má dostatek prostředků ke zpracování transakce.
• Transakce je správná a odpovídá veřejnému klíči odesílatele na rollupu.
• Nonce odesílatele je správná atd.

Jakmile má uzel ZK-rollupu dostatek transakcí, agreguje je do dávky a sestaví vstupy pro dokazovací obvod, aby je zkompiloval do stručného ZK-důkazu. To zahrnuje:

• Kořen Merkleova stromu zahrnující všechny transakce v dávce.
• Merkleovy důkazy pro transakce k prokázání zahrnutí do dávky.
• Merkleovy důkazy pro každý pár odesílatel-příjemce v transakcích k prokázání, že tyto účty jsou součástí stavového stromu rollupu.
• Sadu mezilehlých kořenů stavu, odvozených z aktualizace kořene stavu po aplikaci aktualizací stavu pro každou transakci (tj. snížení účtů odesílatelů a zvýšení účtů příjemců).

Dokazovací obvod vypočítá důkaz platnosti „smyčkováním“ přes každou transakci a provedením stejných kontrol, které operátor dokončil před zpracováním transakce. Nejprve ověří, že účet odesílatele je součástí existujícího kořene stavu pomocí poskytnutého Merkleova důkazu. Poté sníží zůstatek odesílatele, zvýší jeho nonce, provede hashování aktualizovaných dat účtu a zkombinuje je s Merkleovým důkazem k vygenerování nového Merkleho kořene.

Tento Merkleho kořen odráží jedinou změnu ve stavu ZK-rollupu: změnu zůstatku a nonce odesílatele. To je možné, protože Merkleův důkaz použitý k prokázání existence účtu se používá k odvození nového kořene stavu.

Dokazovací obvod provádí stejný proces na účtu příjemce. Zkontroluje, zda účet příjemce existuje pod mezilehlým kořenem stavu (pomocí Merkleova důkazu), zvýší jeho zůstatek, znovu provede hashování dat účtu a zkombinuje je s Merkleovým důkazem k vygenerování nového kořene stavu.

Proces se opakuje pro každou transakci; každá „smyčka“ vytvoří nový kořen stavu z aktualizace účtu odesílatele a následný nový kořen z aktualizace účtu příjemce. Jak bylo vysvětleno, každá aktualizace kořene stavu představuje změnu jedné části stavového stromu rollupu.

ZK-dokazovací obvod iteruje přes celou dávku transakcí a ověřuje sekvenci aktualizací, které vedou ke konečnému kořeni stavu po provedení poslední transakce. Poslední vypočítaný Merkleho kořen se stává nejnovějším kanonickým kořenem stavu ZK-rollupu.

Ověření důkazu

Poté, co dokazovací obvod ověří správnost aktualizací stavu, L2 operátor odešle vypočítaný důkaz platnosti do kontraktu ověřovatele na L1. Ověřovací obvod kontraktu ověří platnost důkazu a také zkontroluje veřejné vstupy, které tvoří součást důkazu:

• Předchozí kořen stavu (Pre-state root): Starý kořen stavu ZK-rollupu (tj. před provedením dávkovaných transakcí), odrážející poslední známý platný stav L2 řetězce.

• Následný kořen stavu (Post-state root): Nový kořen stavu ZK-rollupu (tj. po provedení dávkovaných transakcí), odrážející nejnovější stav L2 řetězce. Následný kořen stavu je konečný kořen odvozený po aplikaci aktualizací stavu v dokazovacím obvodu.

• Kořen dávky (Batch root): Merkleho kořen dávky, odvozený merklizací transakcí v dávce a hashováním kořene stromu.

• Vstupy transakcí: Data spojená s transakcemi provedenými jako součást odeslané dávky.

Pokud důkaz vyhovuje obvodu (tj. je platný), znamená to, že existuje sekvence platných transakcí, které převádějí rollup z předchozího stavu (kryptograficky otisknutého předchozím kořenem stavu) do nového stavu (kryptograficky otisknutého následným kořenem stavu). Pokud se předchozí kořen stavu shoduje s kořenem uloženým v kontraktu rollupu a důkaz je platný, kontrakt rollupu převezme následný kořen stavu z důkazu a aktualizuje svůj stavový strom tak, aby odrážel změněný stav rollupu.

Vstupy a výstupy

Uživatelé vstupují do ZK-rollupu vložením tokenů do kontraktu rollupu nasazeného na L1 řetězci. Tato transakce je zařazena do fronty, protože transakce do kontraktu rollupu mohou odesílat pouze operátoři.

Pokud se fronta čekajících vkladů začne plnit, operátor ZK-rollupu vezme vkladové transakce a odešle je do kontraktu rollupu. Jakmile jsou prostředky uživatele v rollupu, mohou začít provádět transakce odesláním transakcí operátorovi ke zpracování. Uživatelé mohou ověřit zůstatky na rollupu hashováním dat svého účtu, odesláním hashe do kontraktu rollupu a poskytnutím Merkleova důkazu k ověření proti aktuálnímu kořeni stavu.

Výběr ze ZK-rollupu na L1 je přímočarý. Uživatel iniciuje výstupní transakci odesláním svých aktiv na rollupu na určený účet ke spálení. Pokud operátor zahrne transakci do další dávky, uživatel může odeslat žádost o výběr do onchain kontraktu. Tato žádost o výběr bude obsahovat následující:

• Merkleův důkaz prokazující zahrnutí transakce uživatele na účet pro spálení do dávky transakcí

• Transakční data

• Kořen dávky

• L1 adresa pro příjem vložených prostředků

Kontrakt rollupu provede hashování transakčních dat, zkontroluje, zda existuje kořen dávky, a pomocí Merkleova důkazu zkontroluje, zda je hash transakce součástí kořene dávky. Poté kontrakt provede výstupní transakci a odešle prostředky na uživatelem zvolenou adresu na L1.

ZK-rollupy a kompatibilita s EVM

Na rozdíl od optimistických rollupů nejsou ZK-rollupy snadno kompatibilní s Ethereum Virtual Machine (EVM). Dokazování obecných výpočtů EVM v obvodech je obtížnější a náročnější na zdroje než dokazování jednoduchých výpočtů (jako je dříve popsaný převod tokenů).

Nicméně pokroky v technologii s nulovým vědomím (opens in a new tab) podněcují obnovený zájem o zabalení výpočtů EVM do důkazů s nulovou znalostí. Toto úsilí směřuje k vytvoření implementace zkEVM (zero-knowledge EVM), která dokáže efektivně ověřit správnost provádění programu. zkEVM znovu vytváří existující operační kódy (opcodes) EVM pro dokazování/ověřování v obvodech, což umožňuje provádět chytré kontrakty.

Stejně jako EVM, i zkEVM přechází mezi stavy po provedení výpočtu na některých vstupech. Rozdíl je v tom, že zkEVM také vytváří důkazy s nulovou znalostí k ověření správnosti každého kroku v provádění programu. Důkazy platnosti by mohly ověřit správnost operací, které se dotýkají stavu VM (paměť, zásobník, úložiště), a samotného výpočtu (tj. zavolala operace správné operační kódy a provedla je správně?).

Očekává se, že zavedení ZK-rollupů kompatibilních s EVM pomůže vývojářům využít záruky škálovatelnosti a bezpečnosti důkazů s nulovou znalostí. Ještě důležitější je, že kompatibilita s nativní infrastrukturou Etherea znamená, že vývojáři mohou budovat ZK-přátelské decentralizované aplikace (dapps) pomocí známých (a v praxi ověřených) nástrojů a jazyků.

Jak fungují poplatky u ZK-rollupů?

Kolik uživatelé platí za transakce na ZK-rollupech, závisí na poplatku za plyn (gas fee), stejně jako na Ethereum Mainnetu. Poplatky za gas však na L2 fungují odlišně a jsou ovlivněny následujícími náklady:

1. Zápis stavu: Existuje fixní náklad na zápis do stavu Etherea (tj. odeslání transakce na blockchain Etherea). ZK-rollupy tento náklad snižují dávkováním transakcí a rozložením fixních nákladů mezi více uživatelů.

2. Publikování dat: ZK-rollupy publikují stavová data pro každou transakci na Ethereum jako calldata. Náklady na calldata se v současnosti řídí EIP-1559 (opens in a new tab), který stanovuje náklad 16 gas za nenulové bajty a 4 gas za nulové bajty calldata. Náklad placený za každou transakci je ovlivněn tím, kolik calldata je pro ni potřeba odeslat onchain.

3. Poplatky L2 operátorovi: Jedná se o částku placenou operátorovi rollupu jako kompenzaci za výpočetní náklady vzniklé při zpracování transakcí, podobně jako transakční „prioritní poplatky (spropitné)“ na Ethereum Mainnetu.

4. Generování a ověřování důkazů: Operátoři ZK-rollupů musí vytvářet důkazy platnosti pro dávky transakcí, což je náročné na zdroje. Ověřování důkazů s nulovou znalostí na Mainnetu také stojí gas (~ 500 000 gas).

Kromě dávkování transakcí snižují ZK-rollupy poplatky pro uživatele kompresí transakčních dat. Můžete se podívat na přehled v reálném čase (opens in a new tab), kolik stojí používání ZK-rollupů na Ethereu.

Jak ZK-rollupy škálují Ethereum?

Komprese transakčních dat

ZK-rollupy rozšiřují propustnost na základní vrstvě Etherea přesunem výpočtů offchain, ale skutečným impulsem pro škálování je komprese transakčních dat. Velikost bloku Etherea omezuje data, která může každý blok pojmout, a v důsledku toho i počet transakcí zpracovaných v jednom bloku. Kompresí dat souvisejících s transakcemi ZK-rollupy významně zvyšují počet transakcí zpracovaných v jednom bloku.

ZK-rollupy dokážou komprimovat transakční data lépe než optimistické rollupy, protože nemusí odesílat všechna data potřebná k validaci každé transakce. Musí odeslat pouze minimální data potřebná k obnovení nejnovějšího stavu účtů a zůstatků na rollupu.

Rekurzivní důkazy

Výhodou důkazů s nulovou znalostí je, že důkazy mohou ověřovat jiné důkazy. Například jeden ZK-SNARK může ověřit jiné ZK-SNARKy. Takové „důkazy důkazů“ se nazývají rekurzivní důkazy a dramaticky zvyšují propustnost na ZK-rollupech.

V současné době jsou důkazy platnosti generovány blok po bloku a odesílány do L1 kontraktu k ověření. Ověřování důkazů jednotlivých bloků však omezuje propustnost, které mohou ZK-rollupy dosáhnout, protože při odeslání důkazu operátorem může být finalizován pouze jeden blok.

Rekurzivní důkazy však umožňují finalizovat několik bloků pomocí jednoho důkazu platnosti. Je to proto, že dokazovací obvod rekurzivně agreguje více důkazů bloků, dokud není vytvořen jeden konečný důkaz. L2 operátor odešle tento rekurzivní důkaz, a pokud jej kontrakt přijme, všechny příslušné bloky budou okamžitě finalizovány. S rekurzivními důkazy se zvyšuje počet transakcí ZK-rollupu, které lze v intervalech finalizovat na Ethereu.

Výhody a nevýhody ZK-rollupů

Vizuální vysvětlení ZK-rollupů

Podívejte se, jak Finematics vysvětluje ZK-rollupy:

Kdo pracuje na zkEVM?

Mezi projekty pracující na zkEVM patří:

• zkEVM (opens in a new tab) – zkEVM je projekt financovaný Nadací Ethereum (Ethereum Foundation) za účelem vývoje ZK-rollupu kompatibilního s EVM a mechanismu pro generování důkazů platnosti pro bloky Etherea.

• Polygon zkEVM (opens in a new tab) – je decentralizovaný ZK-rollup na Ethereum Mainnetu pracující na Ethereum Virtual Machine s nulovým vědomím (zkEVM), který transparentním způsobem provádí transakce Etherea, včetně chytrých kontraktů s validacemi pomocí důkazů s nulovou znalostí.

• Scroll (opens in a new tab) – Scroll je technologicky zaměřená společnost pracující na budování nativního řešení zkEVM na vrstvě 2 pro Ethereum.

• Taiko (opens in a new tab) – Taiko je decentralizovaný ZK-rollup ekvivalentní Ethereu (ZK-EVM typu 1 (opens in a new tab)).

• ZKsync (opens in a new tab) – ZKsync Era je ZK-rollup kompatibilní s EVM vytvořený společností Matter Labs, poháněný vlastním zkEVM.

• Starknet (opens in a new tab) – Starknet je řešení škálování na vrstvě 2 kompatibilní s EVM vytvořené společností StarkWare.

• Morph (opens in a new tab) – Morph je hybridní řešení škálování rollupu, které využívá zk-důkaz k řešení problému se stavem na vrstvě 2.

• Linea (opens in a new tab) – Linea je zkEVM na vrstvě 2 ekvivalentní Ethereu vytvořené společností ConsenSys, plně sladěné s ekosystémem Etherea.

Další čtení o ZK-rollupech

• Co jsou rollupy s nulovým vědomím? (opens in a new tab)
• Co jsou rollupy s nulovým vědomím? (opens in a new tab)
• Praktický průvodce rollupy na Ethereu (opens in a new tab)
• STARKy vs. SNARKy (opens in a new tab)
• Co je to zkEVM? (opens in a new tab)
• Typy ZK-EVM: Ekvivalentní Ethereu, ekvivalentní EVM, Typ 1, Typ 4 a další kryptická módní slova (opens in a new tab)
• Úvod do zkEVM (opens in a new tab)
• Co jsou ZK-EVM L2? (opens in a new tab)
• Zdroje Awesome-zkEVM (opens in a new tab)
• ZK-SNARKy pod pokličkou (opens in a new tab)
• Jak jsou SNARKy možné? (opens in a new tab)

Návody: Soukromí a nulové vědomí na Ethereu

• Využití nulového vědomí pro tajný stav – Jak používat ZK-důkazy a offchain serverové komponenty k udržování tajného stavu hry onchain.
• Používání skrytých adres (Stealth Addresses) – Jak skryté adresy ERC-5564 umožňují anonymní převody ETH pomocí odvození kryptografického klíče.
• Použití Etherea pro autentizaci ve Web2 – Jak integrovat podpisy peněženky Etherea s autentizačními systémy Web2 založenými na SAML.