Předmluva
Dosud většina protokolů, které jsme ve Web3 zažili, má určitý stupeň důvěry, když doufáme, že budeme pokračovat v „decentralizaci“, musíme nevyhnutelně obětovat určité soukromí. Například, když protokol poskytuje ochranu MEV, s největší pravděpodobností používá Private Mempool. Uživatelé musí předpokládat, že tato část poskytovatelů uzlů bude fungovat poctivě, to znamená, že existuje předpoklad důvěry třetí strany platí pro všechny protokoly - Předpokládá se určitá úroveň důvěry. Podle našeho pozorování v předchozí výzkumné zprávě je pro instituce a velké investory ochrana soukromí jedním z důležitých faktorů, když zvažují, zda migrovat aktiva do řetězce. To také znamená, že některé on-chain datové platformy třetích stran mohou zesílit cílené útoky MEV-Searcher a hackerů na velké domácnosti a instituce, takže zavedení on-chain ochrany soukromí nepochybně přirozeně vyhoví jejich potřebám.
Předtím jsme také napsali výzkumnou zprávu o Singularity, projektu o ochraně soukromí zaměřeném na transakce s temnými fondy (Rozšířené čtení: Podrobné vysvětlení Singularity: Soukromé transakce na transparentních blockchainech).
Otázka tedy zní: Co můžeme udělat pro ochranu soukromí?
Čtyři běžně slýchaná řešení ochrany soukromí jsou: plně homomorfní šifrování (FHE), vícestranné výpočty (MPC), důvěryhodné spouštěcí prostředí (TEE) a důkaz nulových znalostí (ZKP, Zero Knowledge Proof). Ve skutečnosti řeší potřeby scénáře v různých situacích.
Za prvé, u zašifrovaných dat je vlastnictví dat určeno tím, kdo vlastní dešifrovací/šifrovací klíč. Obecně lze říci, že soukromá data lze rozdělit na osobní viditelnost a skupinovou viditelnost.
Osobně viditelná data (Personal Private State): Data může vidět a měnit pouze jeden subjekt, například osobní zůstatek.
Skupinová viditelná data (sdílený soukromý stav): Data mohou být použita pro výpočty několika entitami při zajištění soukromí, jako je zůstatek ve fondu likvidity.
U FHE, MPC a TEE mohou všechny vyřešit problém skupinově viditelných dat. FHE však vyžaduje drahé výpočetní zdroje, MPC vyžaduje, aby všichni validátoři byli online, a TEE musí důvěřovat poskytovateli služeb. Současný průmyslový průzkum těchto řešení je vhodný pouze pro několik scénářů, jako jsou transakce temných fondů, správa soukromých klíčů atd. Přestože výstup informací o výsledku pomocí ZKP je omezený (tj. otázky typu „pravda nebo nepravda“) a je většinou použitelný pouze pro osobní viditelná data, jeho aplikační scénáře jsou plně prozkoumány současnými uživateli, jako jsou cross-chain bridges, Layer 2, KYC atd. Dokonce i v budoucnu, pokud se FHE a MPC nebo dokonce jiná řešení pro ochranu soukromí stanou populárními, nebude ZKP opuštěno kvůli kanibalizačnímu efektu / tržní konkurenci, protože:
ZKP + FHE: Například řetězec ZKVM, který používá model UTXO, pokud chcete ověřit každou transakci, ověřovatel si musí před ověřením stáhnout celý Merkle Tree a dekódovat jeden po druhém, takže FHE je zavedeno pro výpočet bez dekódování. vytváří stejný výsledek.
ZKP + MPC: Například temný fond, který používá MPC + ZKP, umožňuje uživatelům dále zajistit atomičnost transakcí a zároveň zajistit jejich vlastní soukromí.
ZKP + TEE: Například pro ZK-SNARK může generování společného referenčního řetězce provést uzel, na kterém běží TEE, aby bylo zajištěno, že nebudou unikat mezilehlé informace.
Můžeme předvídat, že široká škála aplikačních scénářů ZKP exploduje. Tento požadavek je však stále obtížné dovolit na základě současného hlavního proudu Layer1. Nejenže musí čelit vysokým poplatkům za plyn, ale také musí počkat na ověření sítě . Modulární ZK As A Service (MZaaS), jako konstrukční rámec poskytovatele služeb ZKP, výše uvedené problémy dobře řeší. MZaaS poskytuje řadu služeb souvisejících se ZKP s cílem snížit složitost generování ZKP a zlepšit efektivitu. Tyto služby lze dále rozdělit do následujících podkategorií:
Tržiště důkazů: Je založeno především na konceptu oddělení žadatel-prover, rozděluje Prover do různých scénářů a využívá nečinné zdroje Prover k poskytování veřejného trhu důkazů. Mezi projekty, na které lze odkazovat, patří Mina, =nil; a ZKPool.
Verification Layer: Ověřovatel především na základě konceptu agregace shromažďuje více důkazů a generuje nový důkaz k prokázání platnosti původního důkazu a snižuje náklady na proces ověřování poskytnutím ověřovací vrstvy. Mezi projekty, na které lze odkazovat, patří Aligned Layer, Horizen, Cloaking Layer (zCloak Network) a Nebra.
Jak je třeba chápat ZKP?
Než porozumíme trhu ZKP, udělejme si celkovou koncepci životního cyklu ZKP. Systém prokazování ZKP se v zásadě řídí následujícím procesem:
Prover prohlašuje, že zná určité informace a vyjadřuje je v systému omezení založeném na tomto problému.
Generujte obvody podle formulovaného omezovacího systému
Prover Zadejte odpověď na řešení (Witness), která odpovídá obvodu pro výpočet ZK Proof
Validátor může ověřit ZKP, aby zjistil, zda Prover skutečně zná informace
Předpokládejme, že nyní máme Merkle Tree používaný k zaznamenávání zůstatků na uživatelských účtech Za normálních okolností potřebujeme k aktualizaci zůstatku na účtu následující postup:
Ověřte záznamy odesílatele a příjemce v listových uzlech
Ověřte podpis odesílatele
Aktualizujte zůstatky odesílatele a příjemce
Aktualizujte kořen Merkleho stromu Merkle
Ale s požehnáním ZKP tento proces probíhá následovně:
Zkompletujte proces ověřování Merkle Tree do okruhu
Vezmeme-li Merkle Tree před a po aktualizaci a záznam transakce (někdo poslal 10 $ do A) jako vstup, vypočítej ZKP
Ověřovatel ověří ZKP (přijme ZKP, ověřovací klíč a veřejný vstup jako vstup), a pokud je výsledek výstupu správný, transakce je považována za důvěryhodnou.
V tomto procesu samotný ověřovatel nemusí Merkle Tree opakovaně ověřovat a musí pouze věřit výsledkům ověření (za předpokladu, že je obvod správně zkonstruován).
Pokud je ZKP dále rozebráno z vysoké perspektivy, pak proces od definice problému po konstrukci obvodu provádí frontend (zkompilovaný v jazyce vysoké úrovně), zatímco back-end (zkompilovaný v jazyce nízké úrovně ) je zodpovědná za vložení/kombinaci tohoto obvodu s určitým důkazním systémem pro generování ZKP, konkrétně je obvod nejprve zkombinován s informačně-teoretickým protokolem a poté zkompilován do vhodného systému ZKP pomocí kryptografického kompilátoru, jako je Groth16.
sexualita a integrita. Zdravost říká, že tvrzení je pravdivé, pokud je prokázáno v systému důkazů. Úplnost zaručuje, že pokud je tvrzení pravdivé, je v systému prokazatelné.
Interaktivní důkaz (IP): Ověřovatel položí dokazovateli řadu „náhodných“ otázek. Ověřovatel odpovídá. Toto pokračuje po mnoho kol, dokud se ověřovatel nepřesvědčí, že tvrzení ověřovatele je správné.
Pravděpodobnostní kontrolní nátisky (PCP): Nátisk je převeden do formátu pevné velikosti, který se nazývá „nátisk“. Ověřovatel se může náhodně dotazovat na malé množství dat v replice za účelem ověření. Aby ověřovatel nemohl předem odhadnout hodnotu dotazu a připravit padělaný důkaz, lze zavést orákulum, které generuje náhodné hodnoty pro ověřovatele k použití pro náhodné dotazy. Z teoretického hlediska je tato metoda efektivnější, ale z pohledu procesu ověřovatele je poměrně neefektivní.
Interactive Oracle Proof (IOP): Ověřovatel a ověřovatel vzájemně spolupracují a mají přístup k náhodným příkladům. IOP zlepšuje efektivitu interaktivních nátisků pomocí částečných kopií dat ke snížení složitosti komunikace a dotazů. Toto je také běžně používaný nátiskový systém v systému ZKP.
Výše zmíněný informačně-teoretický důkazní systém vytváří ideální předpoklady, které je obtížné implementovat v reálném životě. Může například předpokládat, že ověřovatel je důvěryhodný a že přístup k atestaci je omezený. Ale vlastnosti kryptografu umožňují tyto předpoklady za určitých okolností, jako jsou běžné matematické problémy:
Problém faktorizace celých čísel: Například bezpečnost RSA spoléhá na faktorizaci velkých čísel.
Problém diskrétního logaritmu: Diffie-Hellman Key Exchange spoléhá na diskrétní logaritmické výpočty velkých čísel.
Problém diskrétního logaritmu eliptické křivky: Kryptografie eliptické křivky (ECC) se opírá o eliptické křivky v konečných polích a diskrétní logaritmy komplexní eliptické křivky.
Po zkombinování informačně-teoretického důkazního systému a kryptografického kompilátoru lze získat systém ZKP, takže vlastnosti ZKP se budou měnit různými kombinacemi:
Výpočetní metody: Existují dva hlavní režimy obecného počítání: obvody a Turingovy stroje. Ačkoli se většina běžných programovacích jazyků pokouší popsat výpočetní cestu Turingova stroje, Turingův stroj není nejefektivnějším programovacím modelem pro kryptografické výpočty a všechny efektivnější programovací modely obvykle výrazně zvyšují složitost, čímž komplikují kryptografické protokoly . Lidé proto místo Turingových strojů používají obvody, protože obvody mohou velmi snadno vyjádřit mnoho přímých příkazů, ale kompromisem je, že uživatel musí zpracovávané výpočty předem zpracovat.
Výpočtové náklady: U různých kombinací se budou náklady na ověřovatele, dokazovatele a komunikaci lišit. Například v systému ZKP v kombinaci s PCP + Collision-Resistant Hash Function (CRFS) jsou náklady na kalkulaci následující:
Anti-kvantové: Některé šifrovací algoritmy mohou účinně odolávat prolomení hrubou silou kvantovými počítači. Například hašovací funkce odolná proti kolizi, kterou používá ZK-STARK, nemůže být v současném vývoji kvantovými počítači přímo prolomena. Stále však existuje riziko prolomení Například dva učenci z univerzity Shandong popsali, jak prolomit SHA1 a MD5 v článku zveřejněném v roce 2009. Stále tedy musíme mít předpoklady důvěry.
Důvěryhodná konfigurace: Důvěryhodná konfigurace obvykle spadá do dvou kategorií: Jednotný referenční řetězec (URS) Náhodná čísla generovaná URS jsou veřejně viditelná, což znamená, že „náhodnost“ je spravedlivá, strukturovaný referenční řetězec (SRS). Univerzální nastavení a Specifické nastavení, první umožňuje více subjektům účastnit se generování náhodných čísel, obvykle ve formě MPC, a druhé umožňuje účastnit se generování náhodných čísel pro konkrétní scénář.
Pokud ve scénáři peer-to-peer zná špatný hráč náhodnou hodnotu, může zfalšovat výstup systému a vygenerovat správné ZKP.
Z výše uvedeného je také patrné, že různé kombinace lze rozšířit na různé typy systémů ZKP. Stručně řečeno, lze jej rozdělit hlavně na ZK-SNARK, ZK-STARK a Bulletproof Následující základní rozdíly nám mohou pomoci lépe porozumět:
Důvěryhodná konfigurace: ZK-SNARK obvykle používá důvěryhodnou konfiguraci, ZK-STARK a Bulletproof takovou konfiguraci nevyžadují.
Spočítejte si náklady:
Doba důkazu: Neprůstřelné > ZK-SNARKs > ZK-STARKs
Doba ověření: Neprůstřelné > ZK-STARKs > ZK-SNARKs
Komunikační složitost/velikost důkazu: ZK-STARKs > Bulletproof > ZK-SNARK, ale když se objem dat zvýší, úložný prostor požadovaný ZK-STARK & Bulletproof bude menší než ZK-SNARK.
Kvantová odolnost: ZK-STARKS jsou obecně kvantově odolné, ZK-SNARK a Bulletproof takové vlastnosti nevyžadují.
Zdroj obrázků: https://github.com/matter-labs/awesome-zero-knowledge-proofs?ref=blog.pantherprotocol.io
Zdroj obrázku: https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa Zero-Knowledge Proof Potenciál a rozsah trhu
V současné době se trať ZKP rozvíjí především ve dvou hlavních směrech: soukromí a expanze.
Plán rozšíření
Týká se především použití ZKP jako řešení pro zlepšení škálovatelnosti, včetně ověření dostupnosti na vrstvě2, cross-chain atd. Mezi běžná řešení v současnosti patří Starknet, ZKsync, Polyhedra atd. Obvykle se dá rozdělit na dva konstrukční systémy: Vrstva1/Vrstva2 a protokol. V systému budov Layer1/Layer2 jsou souhrnné transakce a aplikace prováděny na ZKEVM a mají charakteristiky důkazu nulových znalostí. Ideální ZKEVM by měl být ekvivalentní EVM, což znamená, že může být plně kompatibilní se stávajícími protokoly a vývojovými zkušenostmi EVM. Podle Vitalikova blogu lze aktuální ZKEVM rozdělit do 5 kategorií:
Typ 1: Plně identický s Ethereem, nebudou provedeny žádné změny v jeho stavu nebo transakčním stromu, hash kódu nebo jakékoli jiné logice v jeho konsensu. Type-1 bude plně kompatibilní se všemi nativními aplikacemi Ethereum, ale bude vyžadovat delší zkušební doby, protože se neprovádí žádná předkompilace, která by urychlila generování důkazů. Mezi projekty, které jsou v současné době k dispozici pro referenci, patří Scroll a Taiko.
Typ 2: Vzhledově podobný Ethereu, ale s mírnými vnitřními změnami, jako je stavový strom, bloková struktura atd., aby se usnadnil vývoj a urychlilo generování důkazů. Mezi aktuální dostupné projekty patří Polygon Hermez.
Typ 2.5: Omezte některé funkce ZK zvýšením poplatku za plyn, abyste zkrátili dobu potenciálního ověření, která v podstatě léčí příznaky, ale ne hlavní příčinu.
Typ 3: Některé funkce, které je obzvláště obtížné implementovat do implementace ZK-EVM, mohou být odstraněny. Navíc někdy existují jemné rozdíly ve způsobu zacházení s kódem smlouvy, pamětí nebo zásobníky, takže kompatibilita s Ethereem bude slabší. Tato kategorie připomíná spíše přechodné období vývoje produktu než pozici produktu.
Typ 4: Zdrojový kód inteligentní smlouvy napsaný v jazyce na vysoké úrovni (jako je Solidity) je zkompilován do jazyka výslovně navrženého tak, aby byl přátelský k systému ZKP, jako je Cairo. I když se ukazuje, že čas lze urychlit. Jeho kompatibilita je však nejhorší Například některé DApps vyvinuté pomocí Ethereum bytecode nemusí být migrovány. Mezi projekty, které jsou v současné době k dispozici, patří ZKsync a Starknet.
Zdroj obrázků: https://vitalik.eth.limo/general/2022/08/04/zkevm.html
Na začátku návrhu Etherea se nepočítalo s tím, že by ZKEVM bylo v budoucnu použito pro expanzi, takže obtížnost vývoje je nepochybně velmi vysoká, a proto je volbou ZKsync a Starknet také spuštění univerzálního ZKEVM na trh co nejdříve Ve skutečnosti by se měly jmenovat ZKVM, protože jejich kompatibilita s Ethereem (pro vývojáře) je relativně nízká, ale výměnou za to mají vyšší architektonickou flexibilitu a nižší náklady na výrobu ZKP.
Tento typ ZKVM se může vymanit z omezení systému EVM a stát se vrstvou 1. Vývojáři používají jazyky na vysoké úrovni k psaní kódů pro konkrétní architektury virtuálních strojů a poté je kompilují do obvodů ZK nebo používají specifické pro doménu jazyků (DSL) (jako je Circom) pro přímé generování obvodu ZK.
Zdroj obrázku: https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
Pokud vezmeme v úvahu samotnou velikost trhu ZK Layer2, podle údajů L2Beat je současná TVL ZK Layer2 (včetně ZK Rollup a Validium) přibližně 5,015 USD, což představuje 10 % a 7 % celkové TVL vrstvy 2 Layer2 a Ethereum TVL respektive. Pokud se tržní podíl OP Rollup použije jako měřítko, ZK Rollup má v současné době prostor pro růst asi 10krát TVL a očekává se, že spustí dalších 10 - 12 nových linek ZK Layer 2.
Mezi nimi jsou Linea, Starknet a ZKsync první tři, což představuje 1,22 B, 1,06 B a 855 milionů $. Míra koncentrace tří firem je 62 %, což znamená, že současná konkurence na 2. vrstvě je monopolizována několika projekty. . Dále pozorujeme růst Layer2 TVL, k růstu TVL došlo hlavně 20. února 2024. Důvodem je příliv a zhodnocení nativních tokenů Starknet V současné době je v řetězci stále zachováno 75 % nativních tokenů Starknet.
Mezi nimi Linea patří do Type2 ZKEVM a Starknet a ZKsync patří do Type4 ZKEVM. A první tři jsou všechny ZK Rollup namísto Validium. První používá Ethereum jako DA a DA druhého bude umístěn mimo řetězec a bude řízen DAC. Ve Validiu je Immutable X na prvním místě s TVL téměř 200 milionů $. Za zmínku také stojí, že v OP Rollup většina z 10 nejlepších vrstev 2 s nejvyšší TVL používá OP stack, což znamená, že určitý stack má vysoký podíl na trhu. Ale v ZK Rollup se 10 nejlepších Layer2 s nejvyšší TVL v podstatě rozhodlo vyvinout svůj vlastní ZK Stack.
Zdroj obrázků: https://l2beat.com/scaling/summary
Zdroj obrázků: https://l2beat.com/scaling/summary
Kromě výše uvedených vrstev Layer1/Layer2 patří mezi hlavní scénáře rozšíření ZKP protokolová vrstva, jako je cross-chain. Zavedení ZKP do cross-chainu slouží především cross-chain infrastruktuře ověřování lehkých uzlů a Maker & Sender, jako je Polyhedra, Orbiter Finance atd. Během původního ověřovacího procesu lehkého uzlu musí kontrakt nasazený na cílovém řetězci průběžně získávat hlavičku bloku zdrojového řetězce pro následné ověřování informací napříč řetězcem, což však nevyhnutelně spotřebovává plyn, pokud je však ověřovací proces umístěn off-chain, Pokud je v řetězci uložen pouze jeden závazek, náklady na skladování se výrazně sníží a čím vyšší je frekvence aktualizací zdrojového řetězce, tím vyšší jsou náklady na plyn. Závazek lze konstruovat pomocí ZKP, které dokáže efektivně komprimovat jednu nebo více transakcí. V režimu Maker&Sender se ZKP kombinuje s důkazy o podvodu, aby se dále snížilo generování ZKP. Pokud jde o velikost trhu, vezmeme-li si jako příklad Orbiter Finance, přestože má v současné době měsíční objem transakcí přibližně 628 milionů USD a TVL 1,48 milionů USD, poptávka po ZKP se také zvýší v případě vysokého obratu.
plán ochrany osobních údajů
Týká se především protokolů/sítí, které používají ZKP jako řešení zabezpečení soukromí, včetně Zcash, Aztec a Tornado Cash.
Řešení zaměřená na soukromí vyžadují menší úsilí při vývoji než vývojové směry zaměřené na škálování. Stávající aplikace na ochranu soukromí se zaměřují hlavně na soukromí plateb a nejsou příliš programovatelné. Spojení soukromí a programovatelnosti je náročný úkol. Řešení zaměřená na soukromí lze vytvořit dvěma způsoby:
Protokoly: Tyto protokoly primárně využívají ZKP k vytváření soukromých fondů fondů. Uživatelé používají tyto soukromé fondy jako řešení ochrany soukromí, jako je Tornado Cash. U těchto aplikací důkaz provádí uživatel a ověření probíhá v řetězci. Protože vrstva 1 není navržena pro kryptografické výpočty, náklady na ověření jsou pro běžné uživatele často vysoké, což omezuje přijetí těchto aplikací. Intuitivním řešením je přesun aplikací soukromých transakcí do Rollup, aby se snížily poplatky za plyn. V tomto případě musí být soukromý důkaz transakce zahrnut do Rollup proof, tedy rekurzivního důkazu, což v současné době není možné u běžného ZK Rollup na Ethereum.
Vrstva1/Vrstva2: Tyto vrstvy 1/Vrstva2 implementují především ochranu soukromí prostřednictvím ZKP, jako jsou Manta Network a Aztec. Většina řetězců zaměřených na soukromí zatím nemůže podporovat obecné výpočty a může se zaměřit pouze na konkrétní případy použití. Na soukromé transakce se zaměřují například Penumbra a Renegade. Modely účtů přijaté těmito vrstvami Layer1/Layer2 lze rozdělit na: Account-Based a UTXO-Based. Oba mají své vlastní nedostatky: první může unikat určité soukromí kvůli transakční trase a vyžaduje sériové zpracování, zatímco druhé vyžaduje dešifrování každého dílčího uzlu, než jej lze správně dotazovat při ověřování a aktualizaci zůstatku transakce.
Podle Defilama je současná TVL na ochranu soukromí asi 709 milionů USD a míra koncentrace tří firem představuje téměř 99 %, konkrétně Tornado Cash (595 milionů USD), Railgun (96,97 milionů USD) a Aztec (9,45 milionů USD). Mezi nimi jsou protokoly Tornado Cash a Railgun a Aztec patří do vrstvy 2.
Zdroj obrázků: https://defillama.com/protocols/Privacy
Mezi nimi Tornado Cash čelí potlačování souladu, což také znamená, že mnoho požadavků na „compliance privacy“ bude postupně migrovat na jiné protokoly a sítě a míra koncentrace se bude jen postupně snižovat. Navíc mnoho datových platforem třetích stran a centralizovaných poskytovatelů uzlů na trhu v současnosti podkopává odpor cenzuře a někteří velcí investoři a instituce doufají, že převedou velké množství finančních prostředků bezpečnějším a soukromějším způsobem. Ke 3. červnu bylo přibližně 37 % bloků podrobeno kontrole OFAC, čemuž se veřejný Mempool nemůže vyhnout.
Zdroj obrázků: https://www.mevwatch.info
To také dále rozšiřuje požadavky na shodu, takže poskytovatelé služeb, jako je KYC, jsou také velmi důležití. Uživatelé však často chtějí zachovat osobní soukromí v největší míře Potenciální scénáře ZKP + KYC se budou zvyšovat se zlepšením transakcí na ochranu soukromí. Hlavními poskytovateli služeb na současném trhu jsou zCloak, zkMe atd. V tradičním procesu KYC, kdy potřebujeme pověřit více poskytovatelů služeb KYC, musíme provádět opakované ověření, ale v případě ZKP + KYC se mohou ostatní poskytovatelé služeb pokusit ověřit ZKP, aby byla zajištěna platnost identity. Kromě toho musí poskytovatelé služeb během procesu KYC zaznamenávat některé nezbytné informace, jako jsou citlivé informace, jako jsou identifikační karty. Pokud je prováděno u více poskytovatelů služeb, lineárně se zvýší i riziko úniku informací.
S jakými problémy se ZKP nyní potýká?
Jak jsme již zmínili, generování ZKP vyžaduje značné výpočetní zdroje. Vezmeme-li jako příklad běžný ZK-Rollup, doba generování ZKP ZKsync je asi 1 hodina. Pokud bude dále demontován, proces generování ZKP ZK-SNAKS zahrnuje především multi-skalární násobení (MSM) a teoretickou transformaci čísel (NTT). Tyto dva procesy mohou představovat 80 % až 95 % doby generování nátisku. Přestože ZK-STARKs používá různé algoritmy, potýká se také s problémem nízké účinnosti.
Systémy ZKP navíc v posledních letech poskytují širokou a neustále se rozšiřující nabídku možností s různými kompromisy. Kompromisem za vyšší rychlost nátisku je například větší velikost nátisku nebo využití paměti. Rozmanitost systémů nátisku s různými možnostmi přizpůsobení je obrovská a neustále se rozšiřuje. Ethereum však není schopno podporovat vyvíjející se systém důkazů. Nízkonákladově lze například podporovat pouze eliptické křivky BN-254. Ale přechod na bezpečnější křivku (jako je BLS12-381) je velmi komplikovaný úkol, natož aby byl kompatibilní s novým systémem ZKP.
Kromě toho, pokud jde o ověření ZKP na vrstvě 1, náklady na ověření STARK jsou asi 5 000 000 Gas, zatímco důkaz založený na Plonku je méně než 290 000 Gas poplatek. Pokud je důkazní systém přímo ověřen v Ethereu, existuje v současné době několik omezení, například důkazní systémy založené na vnitřních argumentech produktu, jako je Mina's Kimchi (implementace efektivní rekurze přes Pickles) nebo Brakedown-based Binius (důkazy s velikostí druhé odmocniny). , množství výpočtu nebo velikosti důkazu je relativně velké, takže náklady na ověření budou také velmi drahé. K tomu možná budeme muset převést na Ethereum-Friendly ZKP.
Jak modulární služby ZK urychlují proces ZKP
Směrem, o kterém se bude diskutovat v dalším vývoji ZKP, se proto kromě změn v algoritmech/obvodech dají současná hlavní řešení rozdělit do dvou kategorií:
Hardwarová akcelerace: Zlepšete proces generování ZKP vylepšením hardwaru. GPU má obvykle omezené zlepšení doby ověření ZKP Další možností je použít vyhrazený hardware, jako je FPGA nebo ASIC, a poté rozšířit vrstvu Hardware Abstraction Layer, kterou lze odkázat na cloudovou službu AI. Vzhledem k tomu, že cílem tohoto článku není diskutovat o hardwarové akceleraci, nebudeme ji podrobně rozebírat.
Modulární služba ZK-As-A-Service (MZaaS): Snižuje složitost generování ZKP a zlepšuje efektivitu poskytováním řady služeb souvisejících se ZKP. Tyto služby lze dále rozdělit do následujících podkategorií:
Tržiště důkazů: Je založeno především na konceptu oddělení žadatel-prover, rozděluje Prover do různých scénářů, aby využilo nečinné zdroje Prover k zajištění veřejného trhu důkazů. Mezi projekty, na které lze odkazovat, patří Mina, =nil a ZKPool.
Verification Layer: Ověřovatel především na základě konceptu agregace shromažďuje více důkazů a generuje nový důkaz k prokázání platnosti původního důkazu a snižuje náklady na proces ověřování poskytnutím ověřovací vrstvy. Mezi projekty, na které lze odkazovat, patří Aligned Layer, Horizen, Cloaking Layer (zCloak Network) a Nebra.
Tržiště důkazů
Za prvé, z výše uvedených aplikačních scénářů můžeme zjistit, že ne všechny transakce budou generovány v aplikačních scénářích ZKP, takže je můžeme rozdělit do dvou metod generování (jako příklad vezmeme cross-chain):
Plný ZK: ZKP se generuje pro každou transakci. Například pro každou transakci na ZK Bridge vygeneruje Maker ZKP pro ověření.
Poloviční ZK: ZKP se vygeneruje pouze při splnění určitých podmínek. Orbiter Finance například potřebuje vygenerovat ZKP pouze tehdy, když se objeví nesprávné nebo nedůvěryhodné informace o transakci.
Takže ve scénáři Half ZK nejsou všechny Prover plně využity. Když rozdělíme roli Prover na žadatele a Provera a vytvoříme sdílenou platformu Prover/Tržiště, můžeme zlepšit využití Prover a potenciálně zkrátit čas potřebný pro generování ZKP ve scénářích Full ZK. Otázkou ale je, jak si Prover vybrat?
Konkrétní návrh, jak vybrat Prover, lze ve skutečnosti chápat v několika dimenzích: Výkon, Náklady a Decentralizace. Je to v podstatě podobné nemožnému trojúhelníku konsenzuálního mechanismu Například pro zajištění decentralizace je zvolena víceuzlová verifikace, ale opakovaná verifikace nepochybně pouze prodlouží dobu verifikace (sníží výkon). Na základě různých ekonomických modelů ZKP, které Taiko prozkoumala, shrnuli níže uvedený graf. Autor se zde nebude příliš rozepisovat.
Zdroj obrázku: https://www.theblockbeats.info/news/45260 Verification Layer
Nejprve si musíme ujasnit rozdíl mezi agregační a verifikační vrstvou: ta první jen nějakým způsobem komprimuje ZKP, jako je rekurze a skládání, ta druhá na tomto základě přidává proces předběžné verifikace (Soft Finality). Proces Soft Finality se může opírat o externí smlouvy/sítě, což vyžaduje určitou míru důvěry.
Ve skutečném procesu agregace je architektura přijatá různými projekty mírně odlišná, ale obecně existují následující čtyři odkazy (jako příklad používáme ZKTree používané Polymerem):
Složení ZKP: Spojte libovolný okruh do nového ZKP, případně pomocí rekurze a skládání.
Uniformace ZKP: Sjednotit výše uvedený proces do nového ZKP.
Rekurze ZKP: Znovu zopakujte nově vygenerovanou dávku podřízených uzlů (sjednocené ZKP) a použijte tuto dávku ZKP jako důkaz o ověření k dosažení měkké platnosti/finality.
Transformace ZKP: Pokud potřebují obsluhovat konkrétní VM, mohou mít svou vlastní adaptabilitu na různé systémy ZKP a budou dále mapovány na ZKP různých systémů podle situace, aby se snížily náklady na ověřování.
Verification Layer může poskytovat okamžité ověření prostřednictvím Soft Finality a integrovat se s různými systémy (není omezeno na Ethereum). A prostřednictvím Verification Layer lze také umožnit paralelní výpočty, čímž se dále zbaví technického dluhu Etherea. Ještě důležitější je, že může snížit náklady na ověřování. Podle skutečných testů Nebra může každý důkaz předložený v řetězci Ethereum ušetřit až 184 tisíc plynu (přibližně 75 %) a každý důkaz předložený mimo řetězec může ušetřit až 207 tisíc plynu (přibližně 85 %). Kromě toho Aligned Layer také odhaduje, že náklady na ověření na Groth16 a STARK budou 29krát a 80krát nižší než původní ověření na Ethereu a bude používat domácí hardware.
Maskovací vrstva Jak implementovat ověřovací vrstvu
Zavedení
Cloaking Layer je nový produkt zCloak Network se zaměřením na poskytování služeb ověřovací vrstvy pro ZKP. Základní myšlenkou je využít mimořádně vysokou efektivitu a velmi nízké náklady Internet Computer (ICP) a použít smlouvu Canister založenou na WebAssembly (WASM) k přímému ověření každého ZKP. Poté se na základě stejného předpokladu důvěry použije technologie prahového podpisu k odeslání výsledků ověření do libovolného cílového veřejného řetězce, aby se dosáhlo ověřovacích služeb ZKP pokrývajících celý řetězec. (Rozšířené čtení: Cloaking Layer — ověřovací infrastruk ZK pro všechny řetězce)
Hlavní architektura
Zdroj obrázku: https://zcloaknetwork.medium.com/cloaking-layer-a-zk-verification-infra-for-all-chains-1162d3fcc37b
Za prvé, jádrem Cloaking Layer je ICP Canister, který může přímo spouštět ověřovač ZKP (Verifier) ve formě WASM pro přímé ověření důkazů „SNARK“ a „STARK“. ICP Canister lze chápat jako chytrou smlouvu na řetězu EVM, s nímž nelze po nasazení manipulovat a výsledky provozu vyžadují konsenzus celé sítě. Na rozdíl od smluv EVM, které musí být napsány v jazyce Solidity, mohou smlouvy Canister dobře podporovat kompilované objekty WASM. Vzhledem k tomu, že naprostá většina současných systémů ZKVM jako Polygon Miden, RISC0, SP1, Jolt atd. je napsána v programovacím jazyce Rust a lze je snadno zkompilovat do WASM, je Canister velmi vhodný jako validátor ZKP.
Veřejný řetězec ICP se skládá z více podsítí (Subnets) a každá podsíť obsahuje velký počet uzlů (Replica). Po nasazení smlouvy Canister bude kopie uložena v každém uzlu podsítě a bude spuštěna nezávisle v každém uzlu. Poté podsíť porovná provozní výsledky všech uzlů a získá konsensus, aby zajistila správné výsledky. Když maskovací vrstva obdrží ZKP, kanystr validátoru nasazený v každém uzlu nezávisle vypočítá a ověří ZKP. Jakmile výsledek atestace dosáhne konsensu v rámci podsítě, podsíť digitálně podepíše výsledek ověření pomocí podpisové technologie Threshold ECDSA. Podepsané výsledky ověření lze odeslat do jakéhokoli veřejného řetězce, který podporuje ověření podpisu ECDSA, jako jsou bitcoiny, ethereum a Solana k použití.
konkurenční analýza
Klíčové body:
Mezi oceněním řešení na současném trhu je velká propast.
V současné době je již většina řešení na Testnetu
Odhaduje se, že průměrné náklady na ověření se sníží více než 10krát, přičemž nejvyšší výkon bude mít maskovací vrstva.
Většina předpokladů důvěry je založena na vrstvě 1
Většina projektů provádí pouze „ověřovací expanzi“ pro Ethereum
hodnotit
Největší rozdíl mezi Cloaking Layer a jinými současnými řešeními Verification Layer spočívá v jejím předpokladu důvěry. V současné době je žádost o repliku (ICP uzel) extrémně náročná. Vyžaduje schválení od ICP Foundation a vyšší požadavky na konfiguraci uzlu (vyšší než Layer 1 s těžšími konfiguracemi uzlů, jako jsou Solana a Sui). jistý limit důvěry v účinnost prahového podpisu ECDSA, který v podstatě stále závisí na 2/3 poctivých uzlů v síti. Kromě toho, vzhledem k výkonnostním výhodám uzlů ICP, nemusí Cloaking Layer k dosažení komprese ZKP používat složitá schémata rekurze ZKP. Tato metoda je také nejpřímější a nejpohodlnější.
rozšířená diskuse
Jak mohu do ověřovací vrstvy zabudovat odolnost vůči cenzuře?
Nejjednodušším a nejúčinnějším způsobem je použití anticenzurního mechanismu Layer1. Pokud ověřovatel/Unified Prover v Verification Layer nemůže zachytit odeslanou transakci, může být zděděna anticenzurní schopnost Layer1. Skutečné pochopení je, že uživatel/protokol může přímo odeslat ZKP do inteligentní smlouvy Verification Layer ve vrstvě 1 (Kanystr na ICP) a uložit jej do čekající fronty čekající na zabalení Verifier/Unified Prover. Jak se na to Arbitrum dívá, kdokoli může začlenit transakci do historie transakcí vrstvy 2 po určité době bez odpovídajícího sekvenceru.
Co je to trh ZKP-EV?
Prostřednictvím výše uvedeného uvažování můžeme poskytnout dodatečné manipulační poplatky za upřednostnění balení. Pokud je rozsah relativně velký, je možné vytvořit trh ZKP-EV (Extractable Value) podobný trhu MEV.
Jak se liší měkká a tvrdá konečnost?
Všechny Verification Layers budou poskytovat Soft Finality, a protože výkon těchto Verification Layers je vyšší než u Etherea, je také rychlost ověření lepší než u Etherea. Ale pokud potřebujete projít tvrdou konečností vrstvy 1, pak bude čas delší než čas bez použití ověřovací vrstvy. To je také nevýhoda zachování tvrdé finále + agregovaného ZKP. Proto pro protokoly, které vyžadují větší opatrnost v Hard Finality, nemusí být současná Verification Layer dostatečně dobrým řešením, aby bylo možné zavést moduly pro snížení reputace, systémy reputace a pojistné mechanismy, aby bylo dosaženo rovnováhy mezi efektivitou a bezpečností. Můžete se podívat na naše minulé články (rozšířené čtení: TeleportDAO: The Game of Data Verification Security and Efficiency, nejnovější postupy v designu lehkých uzlů).
Jaké jsou zdroje příjmů pro ZK-As-A-Service?
Současný obchodní model všech ZaaS je stále poměrně vágní Kromě možnosti vytěžit část provize v procesu ZKP je to vydávání coinů. Peněžní tok podniku je však v podstatě oddělen od hodnoty tokenu, pokud není spojen silným závazkem zpětného odkupu (jako je MKR MakerDAO). Proto, ačkoli se očekává, že současná velikost trhu bude velká, skutečné výnosy musí trh ještě ověřit.
Odkaz
https://medium.com/casperblockchain/verified-merkle-tree-updates-without-zk-90d8f5100ccd
https://www.zkcamp.xyz/blog/information-theory
https://x.com/iam_preethi/status/1656411033366396929 https://crypto.stackexchange.com/questions/92018/which-is-the-relation-between-zero-knowledge-proofs-of-knowledge-and-circuits https://web.archive.org/web/20090521024709/http://merlot.usc.edu/csac-f06/papers/Wang05a.pdf
https://medium.com/@emilpepil/history-of-the-formation-of-zkp-151dd7001ffa
https://www.paradigm.xyz/2022/04/zk-hardware
https://medium.com/alliancedao/how-to-leverage-zkps-as-a-web3-builder-ae504783973d
https://vitalik.eth.limo/general/2022/08/04/zkevm.html
https://mirror.xyz/msfew.eth/Yl64OK3lLG48eJpVB3GxqFEhmWOm6yMlAo9sc1VrQP4?ref=blog.pantherprotocol.io
https://x.com/jaosef/status/1730313497513476326
https://l2beat.com/scaling/summary
https://defillama.com/protocols/Privacy
https://docs.zksync.io/zk-stack/concepts/finality.html#finality-on-zksync-era
https://figmentcapital.medium.com/decentralized-proving-proof-markets-and-zk-infrastructure-f4cce2c58596
https://dune.com/nebra/zkp-verify-spending
https://medium.com/@eternal1997L/Důvody úpadku icp-unikátní technologie a tenké ekologie-51dd7a9362fb
