A SNARK teljesítményének mérése: előfelületek, háttérrendszerek és a jövő

A SNARK (Succinct Non-Interactive Arguments of Knowledge) fontos kriptográfiai primitív alkalmazásokat talál a blokklánc méretezhetőségére (pl. L2 rollupok) és a magánélet védelmére. A SNARK-ok lehetővé teszik, hogy valaki bizonyítson egy megbízhatatlan hitelesítőnek V (pl. az Ethereum blokklánc), hogy ismernek bizonyos adatokat (pl. érvényes tranzakciók kötegét). Ennek naiv módja az lenne, ha elküldené az adatokat a címre V, aki ezután közvetlenül ellenőrizheti annak érvényességét. A SNARK ugyanazt éri el, de jobb költségekkel V. A SNARK-bizonyítványnak különösen rövidebbnek kell lennie, mint a magát az adatokat tartalmazó naivnak. (További részletekért lásd a tankönyvem tervezetét, Bizonyítások, érvek és nulla tudás. A SNARK-ok bemutatását lásd: Sarah Meicklejohn bemutatás az a16z titkosítónál Nyári kutatási sorozat.)

A SNARK-ok ellenőrzési költségei változhatnak, de jól érthetőek, és gyakran meglehetősen jók. Például, PlonK az igazolások kb 290,000 gáz az Ethereumon való ellenőrzéshez, míg a StarkWare proofjai körülbelül 5 millió gázba kerültek. A SNARK-ok potenciálisan sokféle beállításban alkalmazhatók még a blokkláncokon kívül is – például lehetővé teszik a gyors, de nem megbízható szerverek és a hardver. 

De mivel a SNARK-ellenőrzés általában olcsó, az alkalmazhatóság fő meghatározói a SNARK-bizonyító költségei. P. Ebben a bejegyzésben elmagyarázom, hogyan lehet megbecsülni ezeket a költségeket annak meghatározásához, hogy mikor ésszerű a SNARK-ok használata, és hogyan fejlődhetnek a SNARK-ok a jövőben. Érdemes megjegyezni, hogy ez egy gyorsan mozgó tér, és az ebben a bejegyzésben tárgyalt projektek közül több aktívan javítja teljesítményét.

De először: Hogyan telepítik a SNARK-okat

A SNARK telepítésében a fejlesztő általában számítógépes programot ír ψ amely bemenetként veszi az adatokat w hogy a monda azt állítja, hogy tudja (w jelentése tanú), és ezt ellenőrzi w érvényes. Például az összesítésben a program ellenőrzi, hogy az összes tranzakció bekerült-e w digitálisan aláírva, ne okozzák a számlaegyenlegek nulla alá csökkenését stb. A program ψ ezután a SNARK frontend amely a SNARK technológia alkalmazására alkalmasabb formátumba fordítja. Ezt a SNARK-barát formátumot an köztes ábrázolás (MEGY). 

Az IR általában valamiféle áramkör-kielégíthetőségi példány, amely egyenértékű ψ. Ez azt jelenti, hogy az áramkör C bemenetként veszi az adatokat w, valamint néhány extra bemenetet, amelyeket általában „nem determinisztikus tanácsnak” neveznek, és lefut ψ on w. A bemeneti tanácsok segítségül szolgálnak C futás ψ, tartása közben C kicsi. Például minden alkalommal ψ oszt két számot x és a y, a hányados q és a maradék r tanácsként adható Cés C egyszerűen ellenőrizheti x = qy + r. Ez a csekk olcsóbb, mint az elkészítése C Futtasson egy osztási algoritmust a számításhoz q és a r a semmiből.

Végül az áramkör-kielégíthetőség SNARK-ját alkalmazzuk C. Ezt hívják SNARK háttérprogram. Egy maroknyi erősen strukturált problémára, mint pl mátrixszorzás, konvolúciókés több gráfprobléma, léteznek ismert SNARK-ok, amelyek elkerülik ezt a frontend/backend paradigmát, és ezáltal sokkal gyorsabb bebizonyítást érnek el. De ennek a bejegyzésnek a középpontjában az általános célú SNARK-ok állnak.

Amint látni fogjuk, a SNARK backend prover költségei együtt nőnek C„s méret. Megtartás C kicsi kihívást jelenthet, mivel az áramkörök rendkívül korlátozott formátumot jelentenek a számítások kifejezésére. A következőkből állnak kapuk, által összekötött vezetékek. Minden kapu g bizonyos értékeket táplál, és alkalmazza a nagyon egyszerű függvény ezekhez az értékekhez. Az eredményt ezután a kiinduló vezetékeken keresztül a „downstream” kapukba táplálják g.

SNARK méretezhetőség: mennyi időbe telik valójában?

A kulcskérdés az, hogy mennyivel több időt vesz igénybe a SNARK prover az egyszerű újrafuttatáshoz képest ψ az adatokon? A válasz az prover rezsi a SNARK-hoz képest közvetlen tanúvizsgálat. Ez utóbbi kifejezés arra utal, hogy abban a naiv bizonyításban, amelyben P küld w nak nek V, V ellenőrzések w's érvényessége végrehajtásával ψ rajta. 

Hasznos a prover overhead felosztása „frontend overhead” és „backend overhead”-re. Ha az áramkört értékeljük C kapunként van F szor drágább, mint a futás ψ, akkor azt mondjuk, hogy a frontend overhead az F. Ha a háttérprover-t alkalmazzuk a C is B szor drágább, mint értékelni C kapuról kapura, akkor azt mondjuk, hogy a backend overhead az B. A teljes prover rezsi a termék, F·B. Ez a multiplikatív többletköltség akkor is jelentős lehet, ha F és a B egyénileg szerények. 

Gyakorlatban, F és a B mindkettő nagyjából 1000 vagy nagyobb lehet. Ez azt jelenti, hogy a tanúk közvetlen ellenőrzéséhez viszonyított teljes bizonyítási költség 1 millió és 10 millió közötti vagy több is lehet. Egy laptopon csak egy másodpercig futó program könnyen SNARK-próbához vezethet, amely több tíz vagy több száz napos számítási időt igényel (egyszálú). Szerencsére ez a munka jellemzően változó mértékben párhuzamosítható (a SNARK-tól függően). 

Összefoglalva, ha ma SNARK-ot szeretne használni egy alkalmazásban, akkor a három dolog egyikének igaznak kell lennie:

1. A közvetlen tanúellenőrzés sokkal kevesebb, mint egy másodpercig tart egy laptopon.
2. A közvetlen tanú-ellenőrzés különösen alkalmas az áramkörben való képviseletre, így a frontend overhead kicsi.
3. Hajlandó vagy napokat várni, amíg a SNARK-próba befejeződik, és/vagy hatalmas párhuzamos számítási erőforrásokért fizet.

TA bejegyzés további része elmagyarázza, honnan származnak a frontend és a backend általános költségek, és hogyan becsülöm meg ezeket a különböző SNARK-okhoz. Ezután áttérünk a javulás kilátásaira. 

A frontendek és a háttérfelületek elkülönítése

A frontendek és a háttérrendszerek teljes elkülönítése kihívást jelenthet, mivel a különböző háttérrendszerek különböző típusú áramköröket támogatnak. Ezért a frontendek eltérőek lehetnek attól függően, hogy melyik háttérfelülettel várják a csatolást.

A SNARK háttérrendszerek általában támogatják az úgynevezett aritmetikai áramköröket, ami azt jelenti, hogy az áramkörök bemenetei valamilyen véges mező elemei, és az áramkör kapui két mezőelem összeadását és szorzását végzik. Ezek az áramkörök nagyjából egyenes vonalú számítógépes programoknak felelnek meg (nincs elágazás, feltételes utasítások stb.), amelyek algebrai jellegűek – vagyis primitív adattípusuk mezőelemek. 

A legtöbb háttérrendszer valójában támogatja az aritmetikai áramkörök általánosítását, amelyeket gyakran Rank-1 Constraint Satisfaction (R1CS) példányoknak neveznek. Figyelemre méltó kivétellel Groth16 és elődei, ezek a SNARK-ok más IR-ek támogatására is tehetők. Például a StarkWare az Algebrai Intermediate Representation (AIR) nevű valamit használ, ami szintén hasonló az ún. PlonKish aritmetizálás amelyet a PlonK és más háttérrendszerek támogathatnak. Egyes háttérrendszerek azon képessége, hogy támogassák az általánosabb IR-ket, csökkentheti az ilyen IR-ket előállító frontendek többletköltségét. 

A háttérprogramok a natívan támogatott véges mezők tekintetében is változnak. Erről bővebben a következő részben fogok beszélni.

Különféle megközelítések a frontendekhez

Egyes (nagyon speciális) számítógépes programok természetesen megfelelnek a számtani áramköröknek. Példa erre az a számítógépes program, amely naiv mátrixszorzást hajt végre valamilyen mezőn. De a legtöbb számítógépes program sem nem egyenes vonalú, sem nem algebrai. Gyakran tartalmaznak feltételes utasításokat, olyan műveleteket, mint az egész számok osztása vagy a lebegőpontos aritmetika, amelyek természetesen nem felelnek meg a véges mező aritmetikának, és így tovább. Ezekben az esetekben a frontend többletköltsége jelentős lesz. 

Az egyik népszerű frontend megközelítés olyan áramkörök létrehozása, amelyek lényegében lépésről lépésre hajtanak végre néhány egyszerű CPU-t, amelyet virtuális gépnek (VM) is neveznek. A frontend tervezők „primitív műveletek” készletét határozzák meg, amelyek analógok a valódi számítógépes processzorok összeszerelési utasításaival. Azok a fejlesztők, akik a frontendet szeretnék használni, vagy közvetlenül assembly nyelven írnak „tanú-ellenőrző programokat”, vagy valamilyen magasabb szintű nyelven, például a Solidity-n, és programjaikat automatikusan assembly kódba fordítják. 

Például a StarkWare Kairó egy nagyon korlátozott assembly nyelv, amelyben az összeállítási utasítások hozzávetőlegesen megengedik az összeadást és a szorzást véges mezőn keresztül, a függvényhívásokat, valamint a megváltoztathatatlan (azaz egyszer írható) memóriába való olvasást és írást. A Cairo VM egy Neumann-architektúra, ami azt jelenti, hogy a frontend által készített áramkörök lényegében egy kairói programot vesznek fel nyilvános bemenetként, és „futtatják” a programot a tanún. A kairói nyelv a Turing Complete – korlátozott utasításkészlete ellenére több szabványos architektúrát is képes szimulálni, bár ez költséges lehet. A kairói frontend elindítja a kairói programokat T primitív utasítások az úgynevezett „fok-2 AIR a T sorok és kb 50 oszlopok." Mit pontosan ez jelenti nem fontos ennél a posztnál, de ami a SNARK-proverseket illeti, ez 50 és 100 kapu közötti áramköröknek felel meg minden egyes T a kairói CPU lépései. 

RISC Zero hasonló megközelítést alkalmaz Kairóhoz, de a virtuális gép az ún RISC-V architektúra, egy nyílt forráskódú architektúra gazdag szoftver-ökoszisztémával, amely egyre népszerűbb. Nagyon egyszerű utasításkészletként egy hatékony SNARK frontend tervezése, amely támogatja, viszonylag kezelhető lehet (legalábbis olyan bonyolult architektúrákhoz képest, mint az x86 vagy az ARM). Májustól a RISC Zero programokat forgat végrehajtó T primitív RISC-V utasítások 5-ös fokozatú AIR-ekbe 3T sorok és 160 oszlopok. Ez megfelel a legalább 500 kapuk a RISC-V CPU lépésenként. A közeljövőben további fejlesztések várhatók.

A különféle zkEVM projektek (pl. zkSync 2.0, Scroll, Polygon's zkEVM) a virtuális gépet az Ethereum Virtual Machine-nek (duh) tekintik. Az a folyamat, amikor minden EVM utasítást egyenértékű „kütyüvé” (vagyis az utasítást megvalósító optimalizált áramkörré) alakítanak át, lényegesen nagyobb szerepet kapnak, mint az egyszerűbb Cairo és RISC-V architektúrák esetében. Emiatt és egyéb okokból, néhány zkEVM projekt nem közvetlenül implementálják az EVM utasításkészletet, hanem magas szintű Solidity programokat fordítanak le más assembly nyelvekre, mielőtt áramkörökké alakítanák azokat. Ezeknek a projekteknek a teljesítménye még várat magára.

A „CPU emulátor” projektek, mint például a RISC-V és a Cairo, egyetlen áramkört hoznak létre, amely képes kezelni az összes programot a kapcsolódó assembly nyelven. Az alternatív megközelítések „ASIC-szerűek”, különböző áramköröket állítanak elő a különböző programok számára. Ez az ASIC-szerű megközelítés kisebb áramköröket eredményezhet bizonyos programok számára, különösen akkor, ha a program által minden egyes időlépésben végrehajtott összeállítási utasítás nem függ a program bemenetétől. Például potenciálisan teljes mértékben elkerülheti a frontend overheadet az olyan lineáris programok esetében, mint a naiv mátrixszorzás. De az ASIC megközelítés is erősen korlátozottnak tűnik; amennyire én tudom, nem ismert, hogyan kell használni előre meghatározott iterációs korlátok nélküli ciklusok támogatására. 

A frontend overhead utolsó összetevője abból a tényből származik, hogy minden SNARK olyan áramkört használ, amely véges mezőkön keresztül működik. A laptop CPU-ja egyetlen gépi utasítással képes megszorozni vagy összeadni két egész számot. Ha egy frontend egy elég nagy karakterisztikájú mezőn keresztül ad ki egy áramkört, akkor lényegében szimulálni tudja ezt a szorzást vagy összeadást a megfelelő mezőművelettel. A helyszíni művelet megvalósítása valódi CPU-n azonban jellemzően sok gépi utasítást igényel (bár néhány modern processzor natív támogatással rendelkezik bizonyos mezőkhöz). 

Egyes SNARK háttérrendszerek rugalmasabb mezőválasztást tesznek lehetővé, mint mások. Például, ha a háttérrendszer kriptográfiai csoportot használ G, az áramkör mezőjének meg kell egyeznie a benne lévő elemek számával G, ami korlátozó lehet. Ráadásul nem minden mező támogatja a praktikus FFT algoritmusokat. 

Csak egy SNARK van megvalósítva, Lefékezés, amely natívan támogatja a számításokat tetszőleges (elég nagy) mezőkön. Azzal együtt leszármazottai, ez rendelkezik a leggyorsabb ismert konkrét bizonyítási teljesítménnyel még olyan mezők felett is, amelyeket más SNARK-ok támogatnak, de a bizonyításai jelenleg túl nagyok sok blokklánc-alkalmazáshoz. Legutóbbi munka a bizonyítási méret javítására törekszik, de a bizonyító aszimptotikusan lassabb és ott van úgy tűnik, hogy akadályok a gyakorlatiasságra.

Egyes projektek úgy döntöttek, hogy a mezőket különösen gyors aritmetikával dolgozzák fel. Például, Plonky2 mások pedig a 2. jellemző mezőjét használják⁶⁴ - 2³² + 1 because arithmetic in this field can be implemented several times faster than in less structured fields. However, using such a small characteristic may lead to challenges in efficiently representing integer arithmetic via field operations (e.g., multiplying two 32-bit unsigned integers might yield a result greater than the field characteristic). 

 De bármi is legyen, ahhoz, hogy az összes népszerű SNARK elérje a 128 bites biztonságot (az ellenőrzési költségek jelentős növekedése nélkül), 2-nél nagyobb méretű mezőn kell működniük.¹²⁸. Amennyire meg tudom ítélni, ez azt jelenti, hogy minden mezőművelethez legalább tíz 64 bites gépi szorzásra, valamint jóval több összeadásra és bitenkénti műveletre lesz szükség. Ezért legalább egy nagyságrenddel figyelembe kell venni a frontend overheadet, mivel olyan áramkörökre van szükség, amelyek véges mezőkön működnek. 

Összefoglalva, a virtuálisgép-absztrakciót használó meglévő frontendek a virtuális gép lépésenkénti 100-1000-szeres kapujával hoznak létre áramköröket, bonyolultabb virtuális gépek esetén pedig valószínűleg többet. Ráadásul a véges mezős aritmetika legalább 10-szer lassabb, mint a modern processzorok analóg utasításai (az esetleges kivételekkel, ha a processzor bizonyos mezőket beépített támogatással rendelkezik). Az „ASIC frontend megközelítés” csökkentheti ezen általános költségek egy részét, de jelenleg korlátozott a támogatható programok típusaiban.

Mik a backend szűk keresztmetszetek?

Az áramkör-kielégítést szolgáló SNARK-okat általában egy információelméletileg biztonságos protokoll, az úgynevezett „polinomiális IOP" egy "" nevű kriptográfiai protokollalpolinomiális kötelezettségvállalási séma.” A legtöbb esetben a bizonyító konkrét szűk keresztmetszete a polinomiális elkötelezettségi séma. Ezeknek a SNARK-oknak a bebizonyítója kriptográfiailag elkötelezi magát egy vagy több olyan polinomhoz, amelynek foka (legalább) |C|, a kapuk száma az áramkörben C. 

A polinomiális kötelezettségvállalási sémán belüli konkrét szűk keresztmetszet viszont az alkalmazott sémától és az áramkör méretétől függ. De ez mindig a következő három művelet egyike lesz: FFT-k kiszámítása, hatványozás egy kriptográfiai csoportban, vagy Merkle-hashing. A Merkle-hash tipikusan csak akkor jelent szűk keresztmetszetet, ha kicsi az áramkör, ezért nem tárgyaljuk tovább. 

Polinom kötelezettségvállalások diszkrét napló alapján

Polinomiális kötelezettségvállalásokban a diszkrét logaritmus-probléma keménysége alapján egy kriptográfiai csoportban G (KZG, Golyóálló, lapos fenekű csónakés Hyrax-commit), a bizonyítónak ki kell számítania a Pedersen vektor elkötelezettség a polinom együtthatóihoz. Ez egy többszörös hatványozást foglal magában, amelynek mérete megegyezik a polinom fokával. A SNARK-okban ez a fokozat jellemzően a méret |C| az áramkör C.

Naivan csinálva, a méret többszörös hatványozása |C| körülbelül 1.5 szükséges·|C|·log |G| ≈ 400·|C| csoportos műveletek, ahol |G| a csoport elemeinek számát jelöli G. Van azonban egy megközelítés, az úgynevezett Pippenger-algoritmus, amely ezt nagyjából log faktorral csökkentheti. |C|. Nagy áramkörökhöz (mondjuk |C| ≥ 225), ez a napló |C| faktor konkrétan 25 vagy több is lehet, vagyis nagy áramkörök esetén arra számítunk, hogy a Pedersen-vektor elkötelezettsége kicsivel több mint 10-el is kiszámítható·|C| csoportos műveletek. Minden csoportművelet (mint egy nagyon durva labdapark) körülbelül 10-szer lassabb, mint egy véges mező művelet. Az ezeket a polinomiális kötelezettségvállalásokat használó SNARK-ok ugyanolyan drágák P mint 100 körül·|C| terepi műveletek. 

Sajnos a meglévő SNARK-ok a fenti 100-szoros faktoron felül további általános költségekkel is járnak. Például:

• spártaiA Hyrax polinom elkötelezettségét használó bizonyítónak meg kell tennie |C|^½ sok több hatványozás, mindegyik méretben |C|^½, ami nagyjából kétszeresére gyengíti a Pippenger-algoritmusból származó gyorsulást. 
• In Groth16, P egy párosításbarát csoporton kell dolgoznia, amelynek működése jellemzően legalább kétszer lassabb, mint a nem baráti párosítási csoportok. P 3 többszörös hatványozást is végre kell hajtania 1 helyett. Ez együttesen legalább további 6-os faktoros lassulást eredményez a 100-hoz képest·|C| fenti becslés. 
• Marlin és a PlonK párosítást is igényelnek, és ezek bizonyítói 3-nál jóval több polinom mellett kötelezik el magukat. 
• Bármely SNARK-hoz, amelyik használja Golyóálló (például, Halo 2, ami nagyjából PlonK, de inkább Bulletproofs, mint KZG polinomiális kötelezettségvállalásokkal), a bizonyítónak logaritmikusan sok többszörös hatványozást kell kiszámítania a kötelezettségvállalási séma „megnyitási” fázisában, és ez nagyrészt törli a Pippenger-gyorsítást. 

Összefoglalva, az ismert SNARK-ok, amelyek Pedersen vektor-kötelezettségeket használnak, úgy tűnik, hogy a háttérben legalább 200-szoros, de akár 1000-szeres vagy annál nagyobb overheadtel rendelkeznek. 

Egyéb polinomiális kötelezettségvállalások

Más polinomiális kötelezettségeket használó SNARK-okhoz (pl INGYENES és a Ligero-commit), a szűk keresztmetszet az, hogy a provernek nagy FFT-ket kell végrehajtania. Például a Kairó által gyártott 2-es fokozatú AIR-ekben (51 oszloppal és T sorok, a kairói CPU lépésenként egy), a StarkWare telepített proverje legalább 2 FFT-t végez oszloponként, ezek közötti hosszúságban 16 ·T és a 32 ·T. Az állandók 16 és a 32 az FRI StarkWare által beállított belső paramétereitől függ, és csökkenthető – de megnövekedett ellenőrzési költségek árán. 

Optimistán egy 32 hosszúságú FFT·T körülbelül 64-et vesz igénybe·T·log(32T) mező szorzások. Ez azt jelenti, hogy még viszonylag kis értékek esetén is T (például, T ≥ 2²⁰), a mezőműveletek száma oszloponként legalább 64·25·T= 1600·T. Tehát úgy tűnik, hogy a backend többletköltsége legalább ezres nagyságrendű. Ezenkívül lehetséges, hogy a nagy FFT-ket még jobban szűk keresztmetszetet okozza a memória sávszélessége, mint a helyszíni műveletek miatt. 

Egyes összefüggésekben a nagy FFT-eket végrehajtó SNARK-ok háttér többletterhelése csökkenthető az úgynevezett proof aggregation technikával. A rollupoknál ez azt jelentené P (az összesítő szolgáltatás) a tranzakciók nagy tételét mondjuk 10 kisebb kötegre bontja. Minden kis tételhez i, P SNARK bizonyítást állít elő πi a tétel érvényességétől. De P nem küldi el ezeket a bizonyítékokat az Ethereumnak, mivel ez közel 10-szeres gázköltség növekedéshez vezetne. Ehelyett ismét a SNARK-t alkalmazzák, ezúttal a bizonyíték előállítására π annak megállapítása P tudja π₁ ...,π₁₀. Vagyis a tanú annak P azt állítja, hogy tudja, a tíz π bizonyíték₁,…,π₁₀, és a közvetlen tanúellenőrzés a SNARK ellenőrzési eljárást alkalmazza minden egyes bizonyításra. Ez az egyetlen bizonyíték π felkerül az Ethereumba. 

Az olyan polinomiális kötelezettségvállalások esetében, mint a FRI és a Ligero-commit, erős feszültség van közöttük P idő és V költségeket, a belső paraméterek olyan gombként működnek, amely kicserélheti egyiket a másikra. Mivel π₁ ,…,π₁₀ nincsenek közzétéve az Ethereumban, a gombot be lehet hangolni, így ezek a bizonyítások nagyok, és gyorsabb az előállításuk. Csak a SNARK végső alkalmazásakor, az összesítéshez π₁ ,…,π₁₀ egyetlen bizonyítékba π, kell-e konfigurálni a kötelezettségvállalási sémát, hogy biztosítsa a kis bizonyítást. 

A StarkWare azt tervezi, hogy proof aggregációt telepít küszöbön áll. Erre fókuszálnak olyan projektek is, mint pl Plonky2.

Melyek a SNARK skálázhatóságának további szűk keresztmetszete?

Ez a bejegyzés a bizonyításra összpontosít idő, de más bizonyító költségek is szűk keresztmetszetek lehetnek a méretezhetőségben. Például sok SNARK háttérprogram esetén a provernek több mezőelemet kell tárolnia minden egyes kapuhoz C, és ez a helyköltség óriási lehet. Például egy program ψ Egy laptopon egy másodperc alatt lefutva talán egymilliárd primitív műveletet hajthat végre egy modern processzoron. Mint láttuk, általában számítani kell rá C hogy ilyen műveletenként jóval több mint 100 kapura van szükség. Ez 100 milliárd kaput jelent, ami a SNARK-tól függően több tíz vagy száz terabájtnyi helyet jelenthet P. 

Egy másik példa: sok népszerű SNARK (pl. PlonK, Marlin, Groth16) bonyolult „megbízható beállítási ceremónia” szükséges a strukturált „bizonyítási kulcs” létrehozásához, amelyet a bizonyítónak el kell tárolnia. Amennyire én tudom, a legnagyobb ilyen szertartás generált egy bizonyító kulcsot, amely képes támogatni az áramköröket körülbelül 2-vel²⁸≈250 millió kapu. A bizonyító kulcs több tucat gigabájt méretű. 

Azokban az összefüggésekben, ahol lehetséges a bizonyítékok összesítése, ezek a szűk keresztmetszetek jelentősen mérsékelhetők. 

Előretekintve: több skálázható SNARK-ok kilátásai

Mind a frontend, mind a backend általános költségek három vagy több nagyságrendűek lehetnek. Számíthatunk arra, hogy a közeljövőben ezek jelentősen csökkennek? 

Azt hiszem, megtesszük – egy bizonyos pontig. Először is, a mai leggyorsabb háttérprogramok (pl. spártai és a Lefékezés, és más SNARK-ok, amelyek egyesítik a összeg-ellenőrzési protokoll polinomiális kötelezettségvállalásokkal) nagy bizonyításaik vannak – jellemzően négyzetgyök az áramkör méretében –, így az emberek nem igazán használják őket. Arra számítok, hogy a próbaméret és a hitelesítési idő a közeljövőben jelentősen lecsökken a mélység-egy kompozíció révén, kis próbával rendelkező SNARK-okkal. A bizonyítási aggregációhoz hasonlóan ez azt jelenti, hogy a bizonyító először SNARK bizonyítást generál π a „gyors-próbáló, nagybiztos” SNARK-kal, de nem küld π nak nek V. Inkább, P egy kisméretű SNARK-ot használna a bizonyításhoz π" hogy az tudja π, és küld π" nak nek V. Ez nagyságrendekkel csökkentheti a ma népszerű SNARK-ok háttérköltségeit. 

Másodszor, a hardveres gyorsítás segíthet. Egy nagyon durva általános szabály az, hogy a GPU-k 10-szeres gyorsítást vásárolhatnak a CPU-khoz képest, az ASIC-ek pedig 10-szeres gyorsulást a GPU-khoz képest. Három aggályom van azonban ezen a téren. Először is, a nagy FFT-ket a memória sávszélessége szűkítheti, nem pedig a helyszíni műveletek, így az ilyen FFT-eket végrehajtó SNARK-ok korlátozottan gyorsulhatnak a speciális hardvertől. Másodszor, míg ez a bejegyzés a polinomiális elkötelezettség szűk keresztmetszetére összpontosított, sok SNARK megköveteli a bizonyítótól, hogy más műveleteket is végezzen, amelyek csak valamivel olcsóbbak. Így megtörjük a polinomiális elkötelezettség szűk keresztmetszetét (pl. a többszörös hatványozás felgyorsítása diszkrét napló alapú SNARK-okban) új szűk keresztmetszeti műveletet hagyhat maga után, amely nem sokkal jobb a réginél. (Például a Groth16-ot, a Marlint és a PlonK-t tartalmazó SNARK-ok is rendelkeznek az FFT-vel, a többszörös hatványozás mellett.) Végül a leghatékonyabb SNARK-okhoz vezető mezők és elliptikus görbék egy ideig tovább fejlődhetnek, és ez kihívások elé állíthatja az ASIC-alapú gyorsítást.

A frontend oldalon egyre inkább azt tapasztalhatjuk, hogy az olyan projektek „CPU emulátor” megközelítése, mint a Cairo, a RISC Zero, a zkEVM-ek és mások, valójában meglehetősen jól skálázható (a teljesítmény szempontjából) a CPU utasításkészleteinek összetettségéhez képest. Valójában ez a különféle zkEVM projektek reménye. Ez azt jelentheti, hogy miközben a frontend többletterhelése három nagyságrenddel vagy annál nagyobb marad, a frontendek képesek támogatni azokat a virtuális gépeket, amelyek egyre inkább megfelelnek a valódi CPU architektúrának. Az ellensúlyozó aggodalomra ad okot, hogy a frontendek bonyolultabbá válhatnak, és nehezen ellenőrizhetők, mivel elszaporodnak az egyre bonyolultabb utasításokat megvalósító, kézzel kódolt kütyük. A formális ellenőrzési módszerek valószínűleg fontos szerepet fognak játszani ennek a problémának a megoldásában. 

Végül, legalábbis a blokklánc-alkalmazásokban azt tapasztalhatjuk, hogy a legtöbb vadon megjelenő intelligens szerződés elsősorban egyszerű, SNARK-barát utasításokat használ. Ez a gyakorlatban lehetővé teheti az alacsony előtér-költséget, miközben megőrzi az általánosságot és a jobb fejlesztői élményt, amely a magas szintű programozási nyelvek, például a Solidity és a gazdag utasításkészletek, köztük az EVM támogatásával jár. 

***

Justin Thaler is a Georgetown Egyetem docense. Mielőtt csatlakozott Georgetownhoz, két évet töltött kutató tudósként a Yahoo Labs-nál New Yorkban, előtte a Simons Institute for the Theory of Computing a Berkeley Egyetemen. 

***

Köszönetnyilvánítás: Hálás vagyok Elena Burger a bejegyzés témájának javaslatáért, és Arasu Arun, Joseph Bonneaués Sam Ragsdale az éleslátó megjegyzésekért. Külön köszönet a szerkesztőmnek is, Tim Sullivan.

***

Az itt kifejtett nézetek az AH Capital Management, LLC („a16z”) egyes alkalmazottainak nézetei, és nem az a16z vagy leányvállalatai nézetei. Az itt található bizonyos információk harmadik féltől származnak, többek között az a16z által kezelt alapok portfólióvállalataitól. Noha megbízhatónak vélt forrásokból származnak, az a16z nem ellenőrizte önállóan ezeket az információkat, és nem nyilatkozik az információk tartós pontosságáról vagy adott helyzetre való megfelelőségéről. Ezenkívül ez a tartalom harmadik féltől származó hirdetéseket is tartalmazhat; az a16z nem vizsgálta át az ilyen hirdetéseket, és nem támogatja az abban található reklámtartalmat.

Ez a tartalom csak tájékoztatási célokat szolgál, és nem támaszkodhat rá jogi, üzleti, befektetési vagy adótanácsadásként. Ezekkel a kérdésekkel kapcsolatban konzultáljon saját tanácsadójával. Bármely értékpapírra vagy digitális eszközre történő hivatkozások csak illusztrációs célt szolgálnak, és nem minősülnek befektetési ajánlásnak vagy ajánlatnak befektetési tanácsadási szolgáltatások nyújtására. Ezen túlmenően ez a tartalom nem befektetőknek vagy leendő befektetőknek szól, és nem is szánható felhasználásra, és semmilyen körülmények között nem támaszkodhat rá az a16z által kezelt alapokba történő befektetésről szóló döntés meghozatalakor. (A16z alapba történő befektetésre vonatkozó ajánlatot csak az ilyen alap zártkörű kibocsátási memoranduma, jegyzési szerződése és egyéb vonatkozó dokumentációja tesz, és azokat teljes egészében el kell olvasni.) Minden említett, hivatkozott befektetés vagy portfóliótársaság, ill. A leírtak nem reprezentatívak az a16z által kezelt járművekbe történő összes befektetésre, és nem garantálható, hogy a befektetések nyereségesek lesznek, vagy a jövőben végrehajtott egyéb beruházások hasonló tulajdonságokkal vagy eredménnyel járnak. Az Andreessen Horowitz által kezelt alapok befektetéseinek listája (kivéve azokat a befektetéseket, amelyek esetében a kibocsátó nem adott engedélyt az a16z számára a nyilvánosságra hozatalra, valamint a nyilvánosan forgalmazott digitális eszközökbe történő be nem jelentett befektetéseket) a https://a16z.com/investments oldalon érhető el. /.

A benne található diagramok és grafikonok kizárólag tájékoztató jellegűek, és nem szabad rájuk hagyatkozni befektetési döntések meghozatalakor. A múltbeli teljesítmény nem jelzi a jövőbeli eredményeket. A tartalom csak a feltüntetett dátum szerint beszél. Az ezekben az anyagokban megfogalmazott előrejelzések, becslések, előrejelzések, célok, kilátások és/vagy vélemények előzetes értesítés nélkül változhatnak, és mások véleményétől eltérhetnek vagy ellentétesek lehetnek. További fontos információkért látogasson el a https://a16z.com/disclosures oldalra.