Varnost in zmogljivost SNARK

SNARK (Succinct Non-interactive Argument of Knowledge) je kriptografsko orodje, ki odpira vznemirljive nove možnosti pri oblikovanju sistema, zlasti v decentraliziranih nastavitvah. SNARK-i omogočajo obdelavo podatkov s strani nezaupnih subjektov, ki lahko nato dokažejo, da so podatki veljavni in da so bili pravilno obdelani. Naiven način za dokazovanje tega bi bila objava podatkov, ki bi vsakomur omogočila, da preveri njihovo veljavnost in jih neposredno obdela. 

SNARK doseže enak učinek, vendar z nižjo cenos validatorjem. Na primer, v drugem nivoju (L2), ki ga je mogoče preveriti, storitev zbiranja obdeluje transakcije verige blokov. Storitev občasno objavlja stanja na računih svojih uporabnikov v verigi blokov prve plasti. Vsakič, ko objavi posodobitev stanja, doda dokaz SNARK, da pozna zaporedje veljavnih transakcij, ki so spremenile stara stanja na računu v posodobljena. Na ta način validatorjem verige blokov ni treba opraviti težkega dela preverjanja veljavnosti transakcij (npr. preverjanja digitalnega podpisa za vsako transakcijo) niti izrecno obdelati transakcij za izračun posodobljenih bilanc.  

My Prejšnja objava osredotočen na učinkovitost preverjalnikov SNARK – primarni dejavnik uporabnosti SNARK. Medtem ko je izvajanje dokazovalnika SNARK lahko računsko zahtevno, do te mere, da je morda neizvedljivo ustvariti dokaz za obsežne izračune, je preverjanje SNARK običajno veliko cenejše od neposrednega preverjanja in obdelave podatkov. Vendar se stroški preverjanja SNARK precej razlikujejo. Ta objava razpakira te stroške in primerja varnostne lastnosti različnih SNARK-ov. 

Še posebej pojasnjujem, da v praktičnih SNARK z verjetno postkvantno varnostjo (PQ-SNARK) obstaja velika napetost med varnostjo in stroški preverjanja. Poleg tega se v nekaterih primerih ta napetost trenutno rešuje v korist stroškov preverjanja pred varnostjo.

Da bi SNARK uresničili svoj potencial, morajo biti nameščeni sistemi varni in uporabniki morajo biti prepričani v njihovo varnost. Objavo zaključujem s predlaganjem preprostih dejanj, ki jih lahko sprejme skupnost web3, da zagotovi dolgoročno ohranitev teh lastnosti. 

Kvantitativni varnostni ukrepi 

SNARK je varen, če je računalniško neizvedljivo ustvariti prepričljiv dokaz napačne izjave. Na primer, v kontekstu zbiranja L2 bi napadalec, ki želi ukrasti moja sredstva, želel dokazati lažno izjavo v obliki: "Poznam digitalno podpisano transakcijo, ki prenese vsa Justinova sredstva na moj račun." 

Raven varnosti SNARK se meri s količino dela, ki ga je treba opraviti, da se najde prepričljiv dokaz lažne izjave. Podobno kot pri drugih kriptografskih primitivih, kot so digitalni podpisi, se logaritem te količine dela imenuje "biti varnosti". Na primer, 30 bitov varnosti pomeni, da 2³⁰ ≈ 1 milijarda "korakov dela" je potrebna za napad na SNARK. To je samo po sebi približna mera varnosti v resničnem svetu, ker se pojem enega koraka dela lahko razlikuje, praktični vidiki, kot so zahteve po pomnilniku ali priložnosti za vzporednost, pa niso upoštevani.

In to kakovostne

Delčki varnosti so a količinsko ukrep varnosti SNARK. SNARK se razlikujejo tudi po svojih kvalitativno varnostne lastnosti. 

Na primer, nekateri SNARK-i zahtevajo zaupanja vredno namestitveno slovesnost za generiranje strukturiranega dokaznega ključa. Pokličejo se SNARK-i, ki sploh ne potrebujejo zaupanja vredne nastavitve pregleden. 

Da bi bil neprozoren SNARK varen, se mora običajno vsaj en udeleženec slovesnosti obnašati pošteno, kar pomeni, da je izdelal in nato zavrgel "vrata", ki bi v kombinaciji z vrati vseh drugih udeležencev olajšala najti prepričljive "dokaze" SNARK za vsako lažno izjavo. Zaupanja vredne nastavitve so počutje run s stotinami ali tisoči udeležencev, da bi bila ta predpostavka čim bolj mila. 

SNARK se razlikujejo tudi po dovzetnosti za kvantne napade. Natančneje, veliko SNARK (npr. Groth16, PlonK, Marlin, Neprebojne zaščite, Nova) temeljijo na predpostavki, da je diskretne logaritme težko izračunati (in v nekaterih primerih tudi na dodatnih predpostavkah). Računanje diskretnih logaritmov je nekaj, kar bi kvantni računalniki zmogli učinkovito. Zato ti SNARK niso postkvantno varni (ne-PQ). 

Medtem ko potekajo nujna prizadevanja za prehod na postkvantno sheme šifriranja, je to predvsem posledica potrebe po ohranjanju tajnosti šifriranih sporočil več desetletij v prihodnosti. Nasprotnik, ki danes shrani prestreženo sporočilo in čaka, da kvantni računalnik prispe čez, recimo, petdeset let, lahko z računalnikom dešifrira petdeset let staro sporočilo. Situacija s SNARK je precej drugačna. Današnja uporaba SNARK, ki niso PQ, ne bi smela ogroziti varnosti verig blokov petdeset let v prihodnosti, tudi če do takrat pridejo kvantni računalniki. 

Polinomske zaveze

Vsi SNARK-ji uporabljajo kriptografski primitiv, znan kot a shema polinomske zaveze, in ta komponenta je pogosto ozko grlo pri delovanju. (Za podrobnosti glejte moj Prejšnja objava.) Poleg tega sta preglednost in verjetna postkvantna varnost SNARK določena izključno s shemo polinomske zaveze, ki jo uporablja. 

Izrazit primer je t.i Polinomske zaveze KZG, ki jih uporablja PlonK, Marlin, in mnogi drugi. Zaveze KZG niso niti transparentne niti postkvantno varne. Druge sheme zavez so pregledne, vendar ne tudi postkvantne Neprebojne zaščite, hyraxin Dory. 

Spet druge sheme so pregledne in verjetno postkvantne. Tej vključujejo FREE, Luč, Ligero++, Zaviranjein Orion. Vse te sheme temeljijo na kodah za popravljanje napak. Zgoščevanje je edini kriptografski primitiv, ki ga uporabljajo. Skupna jim je tudi naslednja lastnost: stroški preverjanja (merjeni s številom ocen zgoščevanja in operacij na terenu) rastejo linearno s številom bitov varnosti.

Grobo rečeno, ena sama "iteracija" teh postkvantnih polinomskih zavez doseže le majhno število (recimo 2-4) bitov varnosti. Zato je treba protokol večkrat ponoviti, da se "ojača" raven varnosti, pri čemer stroški preverjanja rastejo z vsako ponovitvijo. Tako so za nadzor stroškov preverjanja v PQ-SNARK (in s tem stroškov plina v aplikacijah blockchain) oblikovalci protokolov spodbujeni, da ohranijo nizko raven varnosti. 

Z redkimi Izjeme, ta napetost med konkretno varnostjo in stroški preverjanja ne nastane pri ne-PQ SNARK (tako preglednih kot nepreglednih). Ne-PQ-SNARK uporabljajo skupine eliptičnih krivulj, v katerih se domneva, da je diskretne logaritme težko izračunati, njihove ravni varnosti pa določa uporabljena skupina. Velikost ustrezne skupine eliptičnih krivulj in s tem stroški posameznega skupinskega delovanja rastejo z želeno stopnjo varnosti. Vendar pa je Številka elementov skupine v dokazu so neodvisni od izbire skupine. 

V PQ-SNARK-ih ne le, da velikost zgoščenih ocen raste linearno z želeno stopnjo varnosti, raste tudi število ocenjevanj, ki so vključena v dokaz in jih izvede preveritelj. 

Konkretni stroški preverjanja in varnost v razporejenih SNARK-ih

Konkretni stroški preverjanja in ravni varnosti nameščenih SNARK se precej razlikujejo. Tukaj je nekaj ilustrativnih primerov:

Stroški overitelja 

My Prejšnja objava omenil dva primera konkretnih stroškov preverjanja: PlonK stroški dokazil pod 300,000 plin za preverjanje na Ethereumu, medtem ko dokazila StarkWare stanejo približno 5 milijonov plina. Dokazi StarkWare so pregledni in verjetno postkvantni, medtem ko dokazi PlonK niso. Vendar, kot je podrobno opisano v nadaljevanju, se dokazila StarkWare izvajajo na veliko nižji ravni varnosti kot dokazila PlonK na Ethereumu.

Betonska varnost

Edina eliptična krivulja s predkompilacijami Ethereuma se imenuje altbn128, tako da je to krivulja, ki jo uporabljajo vsi ne-PQ SNARK-ji, ki so nameščeni na Ethereum, vključno z Aztecje in zkSync's. Ta krivulja – in s tem tudi razporejeni SNARK-ji, ki jo uporabljajo – je prvotno veljalo, da ponuja približno 128 bitov varnosti. Toda zaradi izboljšani napadi (katerega natančen čas izvajanja je težko določiti), za krivuljo zdaj velja, da ponuja 100 do 110 bitov varnosti. 

Obstajajo EIP pod premislek za uvedbo predkompilacij za različne krivulje, za katere se še vedno domneva, da nudijo skoraj 128 bitov varnosti. Takšne krivulje so že uporabljeno v SNARK-ih projektov, ki niso Ethereum, vključno z ZCash, Algorand, Dfinity, Filecoin in Aleo. 

Nasprotno pa so glede na podatke v verigi StarkWare PQ-SNARK (v tako imenovanem sistemu SHARP, okrajšava za SHARed Prover) konfigurirani tako, da ciljajo na 80-bitno varnost. Ta varnostna stopnja velja pod določenimi domnevami o statistični zanesljivosti FRI (ki jih bom obravnaval pozneje v tej objavi). 

Izraz "80 bitov varnosti" je v tem kontekstu nejasen, zato naj ga razpakiram. Grobo povedano to pomeni, da lahko napadalec ustvari prepričljiv dokaz napačne izjave z vrednotenjem zgoščevalne funkcije 2⁸⁰ krat (in sicer KECCAK-256, zgoščevalna funkcija, ki jo uporablja Ethereum). Natančneje, napadalec, ki je pripravljen izvesti 2^k zgoščene ocene lahko ustvarijo prepričljiv dokaz z verjetnostjo približno 2^k-80. Na primer z 2⁷⁰ zgoščevalnih vrednotenj, lahko najdemo SNARK "dokaz" napačne izjave z verjetnostjo približno 2^-10 = 1/1024. 

Ta pojem je šibkejši od tistega, kar izraz "80 bitov varnosti" pomeni v drugih kontekstih. Na primer, zgoščevalna funkcija, odporna proti trkom (CRHF), konfigurirana na 80-bitno varnost, bi ustvarila 160-bitne izhode. Če je zgoščevalna funkcija dobro zasnovana, bo najhitrejši postopek iskanja kolizije Napad na rojstni dan, postopek s surovo silo, ki lahko najde trčenje s približno 2^160/2 = 2⁸⁰ zgoščene ocene. Vendar pa z 2^k zgoščenih ocen bo napad Birthday našel kolizijo z verjetnostjo samo 2^2k-160. 

Na primer 2⁷⁰ zgoščene ocene bodo povzročile kolizijo z verjetnostjo 2^-20  ≈ 1/1,000,000. To je veliko manj kot verjetnost 1/1,000, da bi napadalec ponaredil dokaz PQ-SNARK, konfiguriran na 80-bitno varnost. 

Ta razlika lahko drastično spremeni privlačnost izvajanja napada. Za ponazoritev si predstavljajte, da ima napadalec proračun 100 $, s katerim lahko kupi 2⁷⁰ zgoščene ocene. In če bi napadalcu uspelo, bi bil izplačilo 200 milijonov dolarjev. Pričakovana vrednost napada na PQ-SNARK, konfiguriran za 80-bitno varnost, je (1/1,000) * 200 milijonov $ ali 200 $ – dvakratni stroški. Če bi bila verjetnost uspeha le 1/1,000,000, kot pri CRHF, bi bila pričakovana vrednost napada samo 200 $. 

Pojma "80-bitne varnosti" se močno razlikujeta tudi po svoji odpornosti na neodvisne napade. Na primer, predpostavimo, da vsaka 1,000 neodvisnih strank napade PQ-SNARK tako, da izvede 2⁷⁰ zgoščene ocene. Ker vsak uspe z verjetnostjo približno 1/1,000, je verjetno, da bo vsaj enemu uspelo. To ne bi bilo tako, če bi vsakemu uspelo z verjetnostjo le 1/1,000,000.

Pričakuje se, da se bodo dobro zasnovane skupine eliptičnih krivulj obnašale podobno kot CRHF, z rojstnodnevnimi napadi, kot je npr. Pollardov rho algoritem biti najbolj znan. To pomeni, da v skupini, ki ponuja 128 bitov varnosti, 2^k skupinske operacije bi morale prinesti rešitev primerka problema diskretnega logaritma z verjetnostjo le 2^2k-256. Na primer 2⁷⁰ skupinske operacije bi našle diskretni logaritem z le astronomsko majhno verjetnostjo 2^-116. Poleg tega je vsaka skupinska operacija počasnejša od ocene CRHF. 

Koliko ocenjevanj zgoščevanja je danes izvedljivih?

Januarja 2020 so bili stroški računalništva malo manj kot 2⁶⁴ Ocene SHA-1 z uporabo grafičnih procesorjev so bile $45,000. To pomeni strošek 2⁷⁰ Ocene SHA-1 na GPU-jih pri nekaj milijonih dolarjev (morda nižje po združitvi Ethereuma, saj bo prehod od rudarjenja dokazov o delu, ki ga prevladuje GPU, verjetno zmanjšal povpraševanje po GPU-ju in znižal stroške). 

Ker zbiranje veljavnosti že hrani na stotine milijonov dolarjev v uporabniških sredstvih, lahko iskanje prepričljivega dokaza o napačni izjavi prinese več milijonov dolarjev dobička. Konfiguracija PQ-SNARK z 80-bitno varnostjo pod agresivnimi domnevami pušča manj kot 10 bitov prostora za premikanje med donosnimi napadi in domnevno varnostjo PQ-SNARK.

Druga podatkovna točka je, da je stopnja razpršitve omrežja Bitcoin trenutno približno 2⁶⁴  zgoščenih ocen na sekundo, kar pomeni, da rudarji bitcoinov kot celota delujejo 2⁸⁰ Ocene SHA-256 vsakih 18 ur. Seveda je ta osupljiva številka posledica velikih naložb v ASIC-je za rudarjenje bitcoinov. 

Ob predpostavki šest bitcoin blokov ustvarjenih na uro in glede na trenutno nagrado za blok 6.25 Bitcoina na blok, ti ​​2⁸⁰ Vrednotenja SHA-256 domnevno stanejo manj kot 22,000 $ * 18 * 6 * 6.25 ≈ 15 milijonov $. V nasprotnem primeru rudarjenje bitcoinov po trenutnih cenah ne bi bilo donosno. 

Predlagani ukrepi za zdrav ekosistem

Bistvo uporabe SNARK-ov v zbiranjih je doseči razširljivost verige blokov, ne da bi uporabnikom bilo treba slepo zaupati storitvi zbiranja. Ker je storitev zbiranja napisala pametno pogodbo, ki deluje kot preveritelj SNARK, mora imeti javnost možnost pregledati pogodbo in potrditi, da res preverja dokazila SNARK ustreznih izjav. Javni nadzor nad pametno pogodbo je morda potreben tudi za zagotovitev, da storitev zbiranja ne more cenzurirati svojih uporabnikov. Predlagane metode za odpornost proti cenzuri zahtevajo, da pametna pogodba zbiranja omogoča uporabnikom, da prisilno dvignejo svoja sredstva, če storitev zbiranja ne uspe obdelati njihovih transakcij. 

Glede na sofisticirano naravo teh protokolov ta paradigma javnega nadzora nalaga strokovnjakom nekaj bremena, da odkrito in odkrito razpravljajo o varnosti razporejenih pogodb. 

Toda pri PQ-SNARK je lahko celo za strokovnjake težko ugotoviti raven varnosti razporejenega protokola iz istega razloga, kot sta varnost in učinkovitost preverjanja v napetosti za te SNARK: raven varnosti (in stroški preverjanja) so odvisni od notranjih parametrov SNARK. In vsaj za StarkWare pametne pogodbe, ti parametri, called logBlowupFactor, ​​proofOfWorkBits in n_Queries, niso neposredno določeni v kodi pametne pogodbe, temveč so v pametno pogodbo posredovani kot javni podatki. Kolikor vem, je najlažji način za prepoznavanje teh parametrov iz informacij v verigi s postopkom v štirih korakih: 

1. pogled na ustrezno pametno pogodbo v raziskovalcu blokov, kot je Etherscan, 
2. kliknite na an ustrezno transakcijo »preveri dokaz«., 
3. dekodirati vhodne podatke transakcije in
4. ugotoviti, kako razlagajo dekodirane vhodne podatke za učenje ključnih parametrov SNARK, ki skupaj določajo raven varnosti. 

Ta zadnji korak zahteva iskanje ustrezne kode Solidity, ki izvaja transakcijo, kar je samo po sebi lahko zmedeno opravilo. (Ko sem se pripravljal Raziskava Pogovori pri zbiranjih to poletje je Etherscan uspel dekodirati ustrezne vhodne podatke za transakcije preverjanja SHARP v skladu z 2. korakom zgoraj. Vendar se zdi, da to ne deluje več.)

Predlog 1: Pregled 

S tem v mislih je moj prvi predlog skupnosti web3, da bi bilo veliko lažje pregledati stopnjo varnosti razporejenih postkvantnih SNARK. To verjetno vključuje boljše orodje za razumevanje podatkov v verigi in večjo preglednost samih projektov pri oznanjanju teh parametrov. 

Predlog 2: Strožji normativi

80-bitna varnost je prenizka, še posebej šibka različica, v kateri 2⁷⁰ zgoščene ocene zadostujejo za uspešen napad z verjetnostjo približno 1/1000 — še toliko bolj glede na dolgo zgodovino presenetljivih napadov na kriptografske primitive. Eden, omenjen zgoraj, je boljši napad na eliptične krivulje, ki so prijazne do parov, kot je altbn128. Bolj znan primer je SHA-1, ki je bil standardiziran na 80 bitov varnosti, vendar se je sčasoma pokazalo, da dosega le približno 60 bitov. S to zgodovino v mislih bi si oblikovalci PQ-SNARK morali pustiti več kot 10 bitov prostora za premikanje pri konfiguraciji ravni varnosti, še posebej, če varnostna analiza vključuje močne domneve o statistični varnosti relativno novih protokolov, kot je FRI.

Tudi za PQ-SNARK je vedno mogoče doseči ustrezne ravni varnosti, preprosto s povečanjem stroškov preverjanja. Na primer, povečanje varnosti SHARP-ovega preverjalnika z 80 na 128 bitov (pod domnevami o statistični zanesljivosti FRI) bi povečalo stroške plina za približno dvakrat, z nekaj več kot 5 milijonov na malo več kot 10 milijonov. Brez ugibanj o FRI bi se stroški plina povečali še dvakrat, na več kot 20 milijonov. 

Moj naslednji predlog je torej, da bi morala skupnost web3 razviti strožje norme glede ustreznih ravni varnosti za nameščene SNARK. Moje osebno priporočilo bi bilo vsaj 100 bitov in vsaj 128, če varnost SNARK temelji na nestandardnih predpostavkah. Nisem prvi podati tak predlog.

Tukaj sem pripravljen kategorizirati kot "standardno predpostavko" brezpogojno varnost v naključni orakeljski model, če je naključni orakelj v razporejenem SNARK instanciran s standardno zgoščevalno funkcijo, kot je KECCAK-256. Naključni orakeljski model je idealizirana nastavitev, ki je namenjena zajemanju vedenja dobro zasnovanih kriptografskih zgoščevalnih funkcij. Pogosto se uporablja za analizo varnosti PQ-SNARK. 

Primer nestandardnih predpostavk so domneve (opisane spodaj) v zvezi s kvantitativno zanesljivostjo protokola, kot je FRI, bodisi v interaktivni nastavitvi bodisi kot neinteraktivni protokol v modelu naključnega oraklja.

Oblikovalci SNARK uvajajo inovacije na številne vznemirljive načine, od katerih lahko nekateri presežejo meje v smislu varnosti – na primer z uporabo SNARK prijaznih zgoščevalnih funkcij, ki niso bile podvržene toliko kriptoanalizi kot bolj standardne zgoščevalne funkcije. Ne pozivam h koncu takih prizadevanj – daleč od tega. Toda te primitive je treba instancirati na varnostnih ravneh, ki presegajo znane, možne napade za več kot 10 bitov. 

Združitve, ki uporabljajo SNARK, so običajno opisane kot podedovanje varnosti njihovega L1. Vendar je to težko narediti, če so konfigurirani na veliko nižjih ravneh varnosti kot kateri koli kriptografski primitiv, ki ga uporablja L1. Ker se SNARK povečuje, bi morali zagotoviti, da jih uvajamo na načine, ki so skladni s tem, kako govorimo o njih. Dokler so SNARK skrbno analizirani, ustrezno konfigurirani in pravilno implementirani, so tako varni kot kateri koli kriptografski primitiv, ki se danes uporablja. 

Na stran: Potopite se še globlje v varnost PQ-SNARK

80-bitna varnost v StarkWare PQ-SNARK je upoštevana na naslednji način. Ti PQ-SNARK uporabljajo shemo polinomske zaveze, imenovano FREE, in StarkWarejev preverjalnik SHARP izvaja FRI pri 48-bitni varnosti pod domnevo. Grobo rečeno, domneva je, da je preprost napad na trdnost FRI optimalen. V tem napadu preverjevalnik goljufanja z malo truda ustvari "dokaz PET", ki prestane naključno izbrana preverjanja preverjatelja z verjetnostjo 2^-48. 

StarkWare združuje FRI s tehniko, imenovano "mletje". To zahteva, da pošten dokaznik pripravi 32-bitni dokaz o delu, preden pripravi dokaz FRI. Prednost mletja je v tem, da drastično poveča delo, ki ga zahteva goljufivi dokaznik, da izvede zgoraj omenjeni preprost napad na FRI, na približno 2³² zgoščene ocene. 

Od (v pričakovanju) 2⁴⁸ poskusi preprostega napada so potrebni, preden je eden od njih uspešen, skupna količina dela, ki jo mora opraviti goljufivi dokaznik, da ponaredi dokaz FRI, je približno 2⁴⁸ * 2³² = 2⁸⁰ zgoščene ocene.

Nazadnje razkrijmo, kako nastane 48 bitov varnosti za FRI. Verifikator FRI naredi "poizvedbe" za dodeljeni polinom. Stroški verifikacije FRI rastejo linearno s številom poizvedb. Na primer, 36 poizvedb za preverjanje FRI je približno 4-krat dražje od 9 poizvedb. Toda več poizvedb pomeni večjo varnost. Število "varnostnih bitov na poizvedbo" je odvisno od drugega parametra FRI, imenovanega kodna hitrost. 

Natančneje, FRI uporablja nekaj, kar se imenuje Reed-Solomonova koda stopnje r, Kjer r je vedno število strogo med 0 in 1. Stroški dokazovalnika FRI so obratno sorazmerni z r, tako da stopnja 1/16 vodi do preverjalnika, ki je približno štirikrat počasnejši in bolj prostorsko intenziven kot stopnja ¼. 

Preverjevalnik SHARP je izvajal PET s kodno hitrostjo 1/16 in z 12 poizvedbami za preverjanje.

StarkWare domneva, da vsaka poizvedba FRI preveritelja doda dnevnik₂(1/r) koščki varnosti. Po tej domnevi 12 poizvedb za preverjanje prinese 12 * log₂(16) = 48 bitov varnosti.

Vendar pa trenutne analize le ugotavljajo, da vsaka poizvedba za preverjanje doda nekaj manj kot dnevnik₂(1/r^1/2) koščki varnosti. Torej 12 poizvedb za preverjanje PET daje samo manj kot 12 * log₂(4) = 24 bitov "dokazljive" varnosti. 

Predlog za ublažitev napetosti med varnostjo in zmogljivostjo

Praktični PQ-SNARK imajo stroške preverjanja, ki rastejo linearno z želenim številom bitov varnosti. Ena obetavna tehnika za ublažitev te napetosti je sestava SNARK - ki sem jo opisal v svoji prejšnji objavi kot sredstvo za razrešitev napetosti med stroški dokazovalnika in verifikatorja, lahko pa obravnava tudi varnost. 

Dva primera 

Poligon Hermez je sestavljanje PQ-SNARK s PlonK. Ideja je, da dokazovalnik najprej ustvari dokaz PQ-SNARK π. Če je PQ-SNARK konfiguriran tako, da ima hiter preverjalnik in ustrezno varnostno raven, bo π velik. Torej dokazovalnik ne pošlje π preveritelju. Namesto tega uporablja PlonK, da dokaže, da pozna π. 

To pomeni uporabo PlonK v vezju, ki sprejme π kot vhod in preveri, ali bi preverjalnik PQ-SNARK sprejel π. Ker ima PQ-SNARK stroške polilogaritmične verifikacije, se PlonK uporablja za majhno vezje, zato je dokazilo PlonK hitro. Ker so dokazila PlonK majhna in poceni za preverjanje, so stroški preverjanja nizki. 

Na žalost uporaba PlonK uniči preglednost in postkvantno varnost. Namesto tega lahko razmislite o uporabi samega PQ-SNARK namesto PlonK za dokazovanje poznavanja π (pravzaprav je PQ-SNARK, ki ga uporablja Polygon, na ta način sestavljen sam). 

V tej drugi aplikaciji PQ-SNARK je za dokazovanje poznavanja π sistem mogoče konfigurirati za doseganje ustrezne varnosti z dokazi razumne velikosti, na primer z izbiro zelo majhne stopnje kode za uporabo v FRI. Ključna točka je, da čeprav je ta nizka stopnja kodiranja slaba za čas preverjanja, se druga uporaba PQ-SNARK uporablja samo za majhno vezje, tako da mora biti skupni čas preverjanja še vedno majhen.

Naše teoretično razumevanje varnosti sestavljenih SNARK pušča veliko želenega. Vendar pa ni znanih napadov nanje, ki bi bili hitrejši od napada na enega od sestavnih SNARK-ov posebej. Na primer, če sestavljamo PQ-SNARK s PlonK, ne poznamo boljšega napada kot napad na PQ-SNARK (tj. najti PQ-SNARK dokaz π napačne izjave) ali napad na PlonK (tj. poiščite dokaz PlonK za napačno izjavo »Poznam dokaz PQ-SNARK π, ki bi ga preveritelj sprejel.«)

Sestavljanje SNARK-jev na ta način je vse bolj priljubljen način za izboljšanje zmogljivosti. Upam, da ga bodo oblikovalci protokolov uporabili tudi za izboljšanje varnosti.

***

Justin Thaler je izredni profesor na univerzi Georgetown. Preden se je pridružil Georgetownu, je bil dve leti kot raziskovalec pri Yahoo Labs v New Yorku, pred tem pa je bil raziskovalec pri Simonsov inštitut za teorijo računalništva na UC Berkeley. 

Urednik: Tim Sullivan @tim_org

***

Tukaj izražena stališča so stališča posameznega citiranega osebja družbe AH Capital Management, LLC (»a16z«) in niso stališča družbe a16z ali njenih podružnic. Nekatere informacije, vsebovane tukaj, so bile pridobljene iz virov tretjih oseb, vključno s portfeljskimi družbami skladov, ki jih upravlja a16z. Čeprav so vzeti iz virov, za katere menijo, da so zanesljivi, a16z ni neodvisno preveril takih informacij in ne daje nobenih zagotovil o trajni točnosti informacij ali njihovi ustreznosti za dano situacijo. Poleg tega lahko ta vsebina vključuje oglase tretjih oseb; a16z ni pregledal takšnih oglasov in ne podpira nobene oglaševalske vsebine v njih.

Ta vsebina je na voljo samo v informativne namene in se je ne smete zanašati kot pravni, poslovni, naložbeni ali davčni nasvet. Glede teh zadev se morate posvetovati s svojimi svetovalci. Sklici na katere koli vrednostne papirje ali digitalna sredstva so samo v ilustrativne namene in ne predstavljajo naložbenega priporočila ali ponudbe za zagotavljanje investicijskih svetovalnih storitev. Poleg tega ta vsebina ni namenjena nobenim vlagateljem ali bodočim vlagateljem niti ji ni namenjena in se nanjo v nobenem primeru ne smete zanašati, ko se odločate za vlaganje v kateri koli sklad, ki ga upravlja a16z. (Ponudba za vlaganje v sklad a16z bo podana le z memorandumom o zasebni plasiranju, pogodbo o vpisu in drugo ustrezno dokumentacijo katerega koli takega sklada in jo je treba prebrati v celoti.) Vse naložbe ali portfeljske družbe, omenjene, navedene ali opisane niso reprezentativne za vse naložbe v vozila, ki jih upravlja a16z, in ni nobenega zagotovila, da bodo naložbe donosne ali da bodo imele druge naložbe v prihodnosti podobne značilnosti ali rezultate. Seznam naložb skladov, ki jih upravlja Andreessen Horowitz (razen naložb, za katere izdajatelj ni dal dovoljenja a16z za javno razkritje, ter nenapovedanih naložb v digitalna sredstva, s katerimi se javno trguje), je na voljo na https://a16z.com/investments /.

Grafi in grafi, ki so navedeni znotraj, so izključno informativne narave in se nanje ne bi smeli zanašati pri sprejemanju kakršnih koli investicijskih odločitev. Pretekla uspešnost ni pokazatelj prihodnjih rezultatov. Vsebina govori samo od navedenega datuma. Vse projekcije, ocene, napovedi, cilji, obeti in/ali mnenja, izražena v tem gradivu, se lahko spremenijo brez predhodnega obvestila in se lahko razlikujejo ali so v nasprotju z mnenji, ki so jih izrazili drugi. Za dodatne pomembne informacije obiščite https://a16z.com/disclosures.