­č窭čç░ Zk-SNARKs: aktualizovate─żn├ę nastavenia na blockchaine

Zk-SNARKs: aktualizovate─żn├ę nastavenia na blockchaine

Zk-SNARK sa osved─Źili ako ÔÇť┼ívaj─Źiarsky arm├ídny n├┤┼żÔÇŁ pre blockchain a distribuovan├ę ├║─Źtovn├ę knihy s aplik├íciami v oblasti ochrany s├║kromia, interoperability a ┼ík├ílovate─żnosti

Zk-SNARKs: aktualizovate─żn├ę nastavenia na blockchaine

Od svojho zavedenia sa d├┤kazy nulovej znalosti (ZKP) pou┼ż├şvaj├║ na podporu potenci├ílnych aplik├íci├ş od overite─żn├Żch extern├Żch v├Żpo─Źtov a┼ż po anonymn├ę poverenia v r├ímci mno┼żstva nastaven├ş, ktor├ę vy┼żaduj├║ rovnov├íhu medzi s├║krom├şm a integritou. ZKP umo┼ż┼łuj├║ jednej strane dok├íza┼ą druhej strane, ┼że ur─Źit├Ż v├Żrok alebo tvrdenie je pravdiv├ę, bez toho, aby sa odhalil obsah tohto v├Żroku. Aplik├ícia ZKP v r├┤znych pr├şpadoch pou┼żitia v re┼ąazci prispieva k rie┼íeniu ot├ízok ochrany s├║kromia, interoperability a ┼ík├ílovate─żnosti.

V tomto pr├şspevku sa pozrieme na r├┤zne typy ZKP a ich ┼ípecifick├ę pr├şpady pou┼żitia. Diskutujeme tie┼ż o zk-SNARK, niektor├Żch zn├ímych probl├ęmoch pri jeho pou┼żit├ş a navrhujeme mechanizmus blockchainu s bezpe─Źn├Żmi vlastnos┼ąami za podmienok porovnate─żn├Żch s protokolom blockchainu. ─îl├ínok vych├ídza z v├Żskumnej pr├íce ÔÇťMining for Privacy: How to Bootstrap a Snarky BlockchainÔÇŁ, ktor├║ nap├şsali Thomas Kerber, Aggelos Kiayias a Markulf Kohlweiss.

R├┤zne typy ZKP

V prostred├ş blockchainu je be┼żn├ę, ┼że klienti s┼ąahuj├║ a overuj├║ ka┼żd├║ transakciu zverejnen├║ v sieti. To znamen├í, ┼że pre praktick├ę nasadenie zero-knowledge protokolov s├║ d├┤le┼żit├ę mal├ę ve─żkosti d├┤kazov a r├Żchly ─Źas overovania. Existuje nieko─żko praktick├Żch sch├ęm, z ktor├Żch si mo┼żno vybra┼ą, s rozsiahlym priestorom kompromisov v oblasti v├Żkonu a kryptografick├Żch predpokladov:

  • Neinterakt├şvne argumenty nulovej znalosti (NIZK): ide o najv┼íeobecnej┼í├ş koncept. NIZK m├┤┼że by┼ą ne├║pln├Ż, ale ako v├Żhoda sa m├┤┼że opiera┼ą o ┼ítandardn├ę kryptografick├ę predpoklady a ─Źasto sp─║┼ła siln├ę bezpe─Źnostn├ę z├íruky.
  • S├║rod├ę neinterakt├şvne argumenty nulovej znalosti (SNARG): dosahuj├║ s├║rodos┼ą za cenu silnej┼í├şch kryptografick├Żch predpokladov a ─Źasto slab┼í├şch bezpe─Źnostn├Żch z├íruk.
  • S├║hrnn├ę neinterakt├şvne argumenty nulovej znalosti (SNARK alebo niekedy zk-SNARK): ide o SNARG, ktor├ę s├║ z├írove┼ł d├┤kazmi znalosti a nulovej znalosti. Tento n├ízov je popul├írny aj v─Ćaka nonsensovej b├ísni Lewisa Carrola ÔÇťThe Hunting of the SnarkÔÇŁ.
  • S├║visl├ę transparentn├ę argumenty znalost├ş (STARK): transparentn├ę tu znamen├í, ┼że nastavenie vy┼żaduje len d├┤veryhodn├║ hashovaciu funkciu. Je to v├Żhodn├ę, ale m├┤┼że to by┼ą spojen├ę s v├Żkonnostnou r├ę┼żiou.

V s├║─Źasnosti je z poh─żadu overovate─ża najatrakt├şvnej┼í├şm syst├ęmom dokazovania (predspracovan├Ż) stru─Źn├Ż neinterakt├şvny argument znalost├ş, skr├ítene zk-SNARK, ktor├Ż m├í mal├║ kon┼ítantn├║ ve─żkos┼ą d├┤kazu a n├íklady na overenie v kon┼ítantnom ─Źase aj pre ─żubovo─żne ve─żk├ę vz┼ąahy. Zk-SNARK sa osved─Źili ako ÔÇť┼ívaj─Źiarsky arm├ídny n├┤┼żÔÇŁ pre blockchain a distribuovan├ę ├║─Źtovn├ę knihy s aplik├íciami v oblasti s├║kromia, interoperability a ┼ík├ílovate─żnosti.

Pr├şpady pou┼żitia

Pr├şpady pou┼żitia zk-SNARK s├║ ve─żmi rozmanit├ę. Niekedy sa SNARKy vyu┼ż├şvaj├║ na zlep┼íenie v├Żkonnosti a stru─Źnosti vlastnost├ş syst├ęmu. V in├Żch pr├şpadoch pou┼żitia sa zk-SNARK vyu┼ż├şvaj├║ na zlep┼íenie s├║kromia. Niektor├ę pr├şpady s├║ zmie┼ían├ę, kde hraj├║ ├║lohu oba aspekty.

V prostred├ş blockchainu, pri zoh─żadnen├ş v├Żkonnosti a stru─Źnosti, m├┤┼żu zk-SNARKS v├Żrazne prispie┼ą k pr├şpadom pou┼żitia, ako napr:

  • ─żahk├ş klienti: na zv├Ż┼íenie efekt├şvnosti parametrov a celkovej ┼ítrukt├║ry aplik├íci├ş. Efekt├şvne syst├ęmy d├┤kazov (bez po┼żiadavky na nulov├║ znalos┼ą) zohr├ívaj├║ d├┤le┼żit├║ ├║lohu pri zav├ídzan├ş ─żahk├Żch klientov. Rekurz├şvne d├┤kazov├ę syst├ęmy sa tie┼ż dobre hodia pre tento pr├şpad pou┼żitia, aby sa zabezpe─Źila bezpe─Źnos┼ą pre neobmedzen├║ rekurziu, ako aj pou┼żitie vonkaj┼í├şch funkci├ş (napr├şklad hashovac├şch funkci├ş) v rekurz├şvnych d├┤kazoch.
  • Chytr├ę kontrakty: na od─żah─Źenie mo┼żn├ęho pre┼ąa┼żenia ├║─Źtovnej knihy z d├┤vodu verejn├ęho vykon├ívania inteligentn├Żch kontraktov. Kompil├ícia k├│du na re┼ąazci do SNARK s kon┼ítantn├Żm alebo logaritmick├Żm ─Źasom overovania m├┤┼że umo┼żni┼ą zlo┼żitej┼íie valid├ítory.
  • D├┤kaz u┼żito─Źnej pr├íce (PoUW): SNARKy m├┤┼żu by┼ą k─ż├║─Źom k overovaniu ÔÇťu┼żito─Źn├Żch v├Żpo─ŹtovÔÇŁ vykon├ívan├Żch ban├şkmi, ktor├Żch valid├ícia na re┼ąazci by inak bola n├íkladn├í.

Z h─żadiska ochrany s├║kromia mnoh├ę aplik├ície vyu┼ż├şvaj├║ d├┤kazy nulovej znalosti na nasadenie bezpe─Źn├Żch platobn├Żch rie┼íen├ş, v├Żmenu opci├ş, spr├ívu ident├şt, hlasovanie, aukcie, overite─żn├ę ┼ítatistiky (forma blockchainov├ęho or├íkula) alebo motivovan├║ anonymn├║ komunik├íciu. Medzi pr├şpady pou┼żitia m├┤┼żu patri┼ą napr:

  • S├║kromn├ę inteligentn├ę zmluvy: SNARK s├║ neoddelite─żnou s├║─Źas┼ąou s├║─Źasn├ęho n├ívrhu s├║kromn├Żch inteligentn├Żch zml├║v. Prvorad├ę s├║ dve veci: univerz├ílnos┼ą, aby sa podporili inteligentn├ę zmluvy nasaden├ę pou┼ż├şvate─żmi, a jednoduchos┼ą kompil├ície. Expresivitu inteligentn├Żch kontraktov mo┼żno eliminova┼ą, aby sa zmen┼íil probl├ęmov├Ż priestor, napr├şklad zak├ízan├şm neobmedzen├Żch cyklov a rekurzie, tak┼że rekurz├şvna kompoz├şcia SNARK nie je potrebn├í. V z├ísade mo┼żno do obvodu SNARK skompilova┼ą ur─Źit├║ podmno┼żinu vysoko├║rov┼łov├ęho zmluvn├ęho jazyka.
  • S├║kromn├ę platby: akt├şva mo┼żno pova┼żova┼ą za osobitn├║ formu n├íroku na identitu, ktor├í zah┼Ľ┼ła modelovanie nedostatku. N├ívrh s├║kromn├Żch platieb m├┤┼że podporova┼ą aj multi-assets a nefunguj├║ce tokeny a sp├íja┼ą tieto tokeny s inteligentn├Żmi zmluvami.
  • Spr├íva identity: V kontexte overite─żn├Żch poveren├ş m├┤┼żu emitenti tvrdi┼ą tvrdenia o subjektoch generovan├şm kryptografick├Żch objektov (poveren├ş). Subjekty nesk├┤r predkladaj├║ svoje poverenia in├Żm pou┼ż├şvate─żom, ktor├ş vystupuj├║ ako overovatelia. Overovatelia s├║ potom schopn├ş overi┼ą, ┼że vydavate─ż tvrdil tvrdenia o subjekte, ktor├Ż predlo┼żil poverenie.
  • Hlasovanie a pokladnica: D├┤kazy ZK sa m├┤┼żu pou┼żi┼ą pri hlasovan├ş o pokladnici. Napr├şklad protokol treasury system for cryptocurrencies poskytuje sch├ęmu hlasovania zachov├ívaj├║cu s├║kromie, kde s├║ hlasovacie l├şstky voli─Źov za┼íifrovan├ę a nesk├┤r s─Ź├ştan├ę pomocou homomorfn├Żch v├Żpo─Źtov. ZK d├┤kazy v pokladnici s├║ neinterakt├şvne Sigma protokoly zalo┼żen├ę na DLP, ktor├ę sa pou┼ż├şvaj├║ na dokazovanie spr├ívnosti za┼íifrovan├Żch spr├ív v r├┤znych f├ízach protokolu (napr. ┼że za┼íifrovan├Ż hlasovac├ş l├şstok voli─Źa obsahuje spr├ívne zostaven├Ż hlasovac├ş l├şstok).

Medzi zmie┼ían├ę pr├şpady pou┼żitia patria napr:

  • Blockchain oracles: SNARK m├┤┼żu zn├ş┼żi┼ą n├íklady na overenie pri agreg├ícii ├║dajov z viacer├Żch zdrojov a m├┤┼żu zn├ş┼żi┼ą ve─żkos┼ą zverejnen├Żch ├║dajov v re┼ąazci t├Żm, ┼że namiesto v┼íetk├Żch d├ítov├Żch bodov obsahuj├║ len agregovan├║ hodnotu a d├┤kaz. Na dosiahnutie t├Żchto dvoch vlastnost├ş by strany mali by┼ą schopn├ę stru─Źne dok├íza┼ą znalos┼ą podpisov na ur─Źitom po─Źte d├ítov├Żch bodov, ako aj pr├şslu┼ín├Ż priemer/medi├ín/variantu.
  • Bo─Źn├ę re┼ąazce: jeden re┼ąazec v konfigur├ícii prip├íjania re┼ąazcov m├┤┼że p├┤sobi┼ą ako ─żahk├Ż klient vo─Źi druh├ęmu re┼ąazcu, pri─Źom overuje transakcie medzi re┼ąazcami v druhom re┼ąazci bez toho, aby musel overova┼ą cel├Ż tento re┼ąazec. Rozdiel je v tom, ┼że toto pegging sa ─Źasto udr┼żiava dlhodobo, a tak sa d├┤kazy m├┤┼żu poskytova┼ą pravidelne a ÔÇťaktualizovate─żn├ŻmÔÇŁ sp├┤sobom. Viac inform├íci├ş n├íjdete v ─Źasti Proof of stake Sidechains.

Zn├íme probl├ęmy

Neinterakt├şvna nulov├í znalos┼ą vy┼żaduje ur─Źit├║ zdie─żan├║ n├íhodnos┼ą alebo spolo─Źn├Ż referen─Źn├Ż re┼ąazec. Pre mnoh├ę stru─Źn├ę syst├ęmy je potrebn├í silnej┼íia vlastnos┼ą:

Nielen┼że je potrebn├í zdie─żan├í n├íhodn├í hodnota, ale mus├ş dodr┼żiava┼ą ┼ípecifick├║ ┼ítrukt├║ru. ┼átrukt├║rovan├Ż referen─Źn├Ż re┼ąazec (SRS) sa zvy─Źajne sklad├í zo s├║visiacich skupinov├Żch prvkov, t. j.: gxi pre v┼íetky iÔłł­ŁĽźn.

Zrejm├Ż sp├┤sob v├Żberu vzorky tak├ęhoto referen─Źn├ęho re┼ąazca z verejnej n├íhodnosti odha─żuje pou┼żit├ę exponenty - a znalos┼ą t├Żchto hodn├┤t nar├║┼ía spo─żahlivos┼ą samotn├ęho d├┤kazov├ęho syst├ęmu. Aby to bolo e┼íte hor┼íie, bezpe─Źnos┼ą t├Żchto syst├ęmov sa zvy─Źajne spolieha (okrem in├ęho) na znalos┼ą exponentov├Żch predpokladov, ktor├ę hovoria, ┼że na vytvorenie takto s├║visiacich skupinov├Żch prvkov je potrebn├í znalos┼ą z├íkladn├Żch exponentov, a preto ka┼żd├Ż vzorkova─Ź SRS bude musie┼ą ÔÇťpozna┼ąÔÇŁ pou┼żit├ę exponenty a by┼ą d├┤veryhodn├Ż pri ich vymaz├ívan├ş, ─Ź├şm sa v podstate st├íva jedin├Żm bodom zlyhania z├íkladn├ęho syst├ęmu.

Bezpe─Źn├Ż v├Żpo─Źet s viacer├Żmi stranami (MPC) sa m├┤┼że pou┼żi┼ą a aj sa pou┼żil na zn├ş┼żenie d├┤veryhodnosti tak├ęhoto procesu nastavenia. V├Żber ├║─Źastn├şkov bezpe─Źn├ęho v├Żpo─Źtu a overovanie generovania SRS protokolom MPC si v┼íak zachov├íva prvok centraliz├ície. Pou┼żitie MPC zost├íva kontroverzn├Żm prvkom pri nastavovan├ş decentralizovan├ęho syst├ęmu, ktor├Ż vy┼żaduje SNARK.

Rie┼íenie ot├ízok ochrany s├║kromia pri bezpe─Źnom generovan├ş SRS

Aktualizovate─żn├Ż ┼ítrukt├║rovan├Ż referen─Źn├Ż re┼ąazec (uSRS) mo┼żno bezpe─Źne inicializova┼ą pomocou distribuovanej ├║─Źtovnej knihy t├Żm, ┼że sa od tvorcov blokov vy┼żaduje, aby po─Źas po─Źiato─Źn├ęho obdobia nastavenia vykon├ívali aktualiz├ície vyv├şjaj├║ceho sa uSRS. Po vy─Źkan├ş na dohodu o kone─Źnom uSRS ho mo┼żno bezpe─Źne pou┼ż├şva┼ą.

D├┤kaz tohto sa opiera o z├íkladn├Ż sp├┤sob fungovania ├║─Źtovn├Żch kn├şh typu Nakamoto: r├┤zni pou┼ż├şvatelia m├┤┼żu roz┼í├şri┼ą re┼ąazec blokov, ak dok├í┼żu splni┼ą ur─Źit├║ podmienku, pri─Źom t├íto podmienka je spojen├í s typom tvrdosti, ktor├Ż zabezpe─Źuje, ┼że ├║to─Źn├şci s├║ obmedzen├ş v po─Źte roz┼í├şren├ş, ktor├ę m├┤┼żu vykona┼ą. Vzh─żadom na tak├║to ┼ítrukt├║ru prirad├şme ku ka┼żd├ęmu bloku aktualiz├íciu uSRS pred ─Źasom ­ŁŤ┐1. Tento ─Źas je zvolen├Ż tak, aby bezpe─Źnostn├ę vlastnosti ├║─Źtovnej knihy zabezpe─Źili, ┼że v ka┼żdom konkuren─Źnom re┼ąazci je v tomto ─Źase aspo┼ł jeden z blokov poctiv├Ż.

To mo┼żno skon┼ítruova┼ą z funkcie ├║─Źtovnej knihy s dodato─Źn├Żm stavom vedenia, ktor├Ż je odvoden├Ż z inform├íci├ş, ktor├ę ban├şci vkladaj├║ do svojich blokov na zak├│dovanie aktualiz├ície uSRS. Toto je ponechan├ę dostato─Źne v┼íeobecn├ę, aby umo┼żnilo aj in├ę pou┼żitie. Z├íkladnou my┼ílienkou je uk├íza┼ą, ┼że ├║─Źtovn├í kniha, ktor├í vykon├íva aktualiz├ície uSRS v stave vedenia, je ekvivalentn├í tej, ktor├í ich nevykon├íva, ale je sprev├ídzan├í bezpe─Źn├Żm uSRS. Po uplynut├ş ─Źasu ­ŁŤ┐1 pou┼ż├şvatelia ─Źakaj├║ ─Ćal┼í├ş ─Źasov├Ż ├║sek ­ŁŤ┐2, k├Żm spolo─Źn├Ż prefix nezabezpe─Ź├ş, ┼że sa v┼íetky strany dohodn├║ na referen─Źnom re┼ąazci.

Navrhovan├í abstrakcia ├║─Źtovnej knihy

Na┼ía kon┼ítrukcia funkcionality aktualizovate─żn├ęho ┼ítrukt├║rovan├ęho referen─Źn├ęho re┼ąazca sa opiera o vlastnosti spolo─Źn├Ż prefix, kvalita re┼ąazca a rast re┼ąazca definovan├ę v anal├Żze chrbtice Bitcoinu od Garaya a kol. pre konsenzu├ílne algoritmy v Nakamotovom ┼ít├Żle:

  • spolo─Źn├Ż prefix. Pri s├║─Źasn├Żch re┼ąazcoch ­ŁŤ▒1 a ­ŁŤ▒2 dvoch str├ín a odstr├ínen├ş k blokov z prv├ęho je prefixom druh├ęho: ­ŁŤ▒1ÔîŐk Ôë║­ŁŤ▒2.
  • Existenci├ílna kvalita re┼ąazca. Pre aktu├ílny re┼ąazec ─żubovo─żnej strany ­ŁŤ▒ bud├║ v┼íetky po sebe nasleduj├║ce l bloky v tomto re┼ąazci obsahova┼ą aspo┼ł jeden blok vytvoren├Ż poctivou stranou.
  • Rast re┼ąazca. Ak m├í re┼ąazec strany d─║┼żku c, potom o s ─Źasov├Żch intervalov nesk├┤r bude ma┼ą d─║┼żku aspo┼ł c+­ŁŤż.

Decentralizovaná konštrukcia uSRS

Nami navrhovan├í kon┼ítrukcia, podrobne op├şsan├í v ─Źl├ínku Mining for Privacy, je jednoduch├í: ka┼żd├Ż re┼ąazec je spojen├Ż s konkr├ętnym uSRS a ke─Ć ban├şk re┼ąazec pred─║┼żi, dodato─Źne vykon├í aktualiz├íciu uSRS. Pri vzniku re┼ąazca sa m├┤┼że pou┼żi┼ą zn├íma n├íhodnos┼ą (alebo dokonca ┼żiadna n├íhodnos┼ą). Princ├şp tohto n├ívrhu je jednoduch├Ż: aktualizovate─żnos┼ą uSRS zaru─Źuje, ┼że ak sa jedna aktualiz├ícia vykon├í poctivo (s pou┼żit├şm skuto─Źnej n├íhodnosti aj vymazan├şm tejto n├íhodnosti po vykonan├ş aktualiz├ície), v├Żsledn├Ż uSRS sa m├┤┼że bezpe─Źne pou┼ż├şva┼ą. Na zaru─Źenie tohto sa spoliehame na vlastnos┼ą existen─Źnej kvality re┼ąazca - po vygenerovan├ş l blokov mus├ş aspo┼ł jeden z nich vytvori┼ą poctiv├Ż ban├şk, a preto po l blokoch je uSRS re┼ąazca bezpe─Źn├Ż.

Nesta─Ź├ş v┼íak ├║plne vedie┼ą, ┼że referen─Źn├Ż re┼ąazec konkr├ętneho re┼ąazca je bezpe─Źn├Ż - pre v├Ą─Ź┼íinu praktick├Żch aplik├íci├ş chceme, aby sa v┼íetci pou┼ż├şvatelia zhodli na referen─Źnom re┼ąazci. To zabezpe─Źuje vlastnos┼ą spolo─Źn├Ż prefix, ktor├í zaru─Źuje, ┼że pre ─żubovo─żn├Ż re┼ąazec dlh├Ż l+k blokov bud├║ ma┼ą v┼íetci ostatn├ş pou┼ż├şvatelia rovnak├Ż referen─Źn├Ż re┼ąazec ako ten, ktor├Ż je generovan├Ż t├Żmto re┼ąazcom - za predpokladu, ┼że pou┼ż├şvatelia prestan├║ aktualizova┼ą po l blokoch!

A nakoniec, rast re┼ąazca zaru─Źuje, ┼że udalos┼ą, ktor├í n├ís zauj├şma - ke─Ć sa v┼íetci zhodn├║ na referen─Źnom re┼ąazci - nakoniec nastane. Zaru─Źuje, ┼że pou┼ż├şvatelia bud├║ ma┼ą nakoniec re┼ąazec d─║┼żky l+k. Konkr├ętne, ke─Ć┼że ka┼żd├Żch s ─Źasov├Żch jednotiek sa generuj├║ bloky, udalos┼ą nastane najnesk├┤r v ─Źase Ôîł(l+k)/sÔîë.

To v┼íetko je abstraktne dobre, ale ponech├íva to ot├ízky praktick├ęho vyu┼żitia: tak├ęto abstraktn├ę anal├Żzy predpokladaj├║, ┼że aktualiz├ície sa daj├║ vytvori┼ą s mal├Żmi alebo ┼żiadnymi n├íkladmi a ┼że neovplyv┼łuj├║ ┼ítandardn├Ż postup ┼ąa┼żby. V pr├şpade ┼ąa┼żby proof-of-work to v┼íak nie je celkom pravda:

  1. Aktualiz├ície s├║ relat├şvne n├íkladn├ę, ich v├Żpo─Źet trv├í 5 a┼ż 10 min├║t v z├ívislosti od ve─żkosti cie─żov├ęho uSRS.
  2. Aktualiz├ície je mo┼żn├ę podv├ídza┼ą, vykon├íva┼ą ich r├Żchlej┼íie, ale bez pridania bezpe─Źnosti referen─Źn├ęho re┼ąazca.

V kombin├ícii tieto faktory predstavuj├║ v├Żzvu, najm├Ą v nastaven├ş proof-of-work, kde sa aktualiz├ícia mus├ş vykona┼ą predt├Żm, ako m├┤┼że ban├şk za─Źa┼ą ┼ąa┼żi┼ą blok. To zdr┼żuje nepodv├ídzaj├║cich ban├şkov, zatia─ż ─Źo ich podv├ídzaj├║ci kolegovia u┼ż ┼ąa┼żia! V d├┤sledku toho by ┼ąa┼żobn├í obtia┼żnos┼ą (zodpovedaj├║ca zam├Ż┼í─żan├ęmu ─Źasu medzi blokmi) nemala by┼ą pr├şli┼í n├şzka, preto┼że ─Ź├şm je ni┼ż┼íia, t├Żm v├Ą─Ź┼íie v├Żhody m├í podv├ídzaj├║ci ban├şk. Na druhej strane, vysok├í obtia┼żnos┼ą prirodzene vedie k dlh┼íiemu ─Źasu na dosiahnutie konsenzu. Tento kompromis je zn├ízornen├Ż na obr├ízku 1.

Za predpokladu, ┼że je obtia┼żnos┼ą vhodne kalibrovan├í, simula─Źn├í anal├Żza ukazuje, ┼że tento efekt nepo┼íkodzuje celkov├║ bezpe─Źnos┼ą. V z├ívislosti od pravdepodobnosti zlyhania (Đö), ktor├║ sme ochotn├ş tolerova┼ą, a od podielu ┼ąa┼żobnej sily ├║to─Źn├şka (đ░), pred ktor├Żm chceme chr├íni┼ą, sa d├í uSRS bezpe─Źne vygenerova┼ą pomocou postupu bu─Ć v priebehu nieko─żk├Żch hod├şn, alebo v priebehu nieko─żk├Żch mesiacov v pesimistickej┼íom scen├íri, ako je zn├ízornen├ę na obr├ízku 1.

snarks

Obr├ízok 1. ─îas potrebn├Ż, k├Żm je zaru─Źen├í aspo┼ł jedna poctiv├í aktualiz├ícia, ako funkcia ─Źasu cie─żov├ęho bloku

Zdroj: ÔÇťMining for Privacy: How to Bootstrap a Snarky BlockchainÔÇŁ v├Żskumn├Ż dokument.

Podobn├Ż probl├ęm nast├íva aj pri uva┼żovan├ş o racion├ílnom spr├ívan├ş - ┼ąa┼żiarov, ktor├ş sa sna┼żia len o zisk, sa bud├║ sna┼żi┼ą podv├ídza┼ą aj pri aktualiz├íci├ích, nie v┼íak zo zl├ęho ├║myslu, ale jednoducho preto, ┼że ak to urobia, m├┤┼żu vytv├íra┼ą bloky r├Żchlej┼íie. Tento probl├ęm sa d├í ob├şs┼ą dodato─Źn├Żm odme┼łovan├şm dobr├ęho spr├ívania - v├Żberov├║ vzorku ban├şkov mo┼żno dodato─Źne po┼żiada┼ą, aby poskytli n├íhodnos┼ą svojich aktualiz├íci├ş a preuk├ízali, ┼że bola vybran├í vhodn├Żm sp├┤sobom (napr├şklad pomocou ha┼íovacej funkcie). Ak sa im to podar├ş, m├┤┼żu z├şska┼ą dodato─Źn├║ odmenu, ktor├í vyv├í┼żi pr├şpadn├║ stratu z nepodv├ídzania.

Celkovo mo┼żno poveda┼ą, ┼że pou┼żite─żnos┼ą zk-SNARK v├Żrazne prospieva r├┤znym pr├şpadom pou┼żitia v re┼ąazci, ktor├ę rie┼íia ot├ízky s├║kromia, interoperability a ┼ík├ílovate─żnosti. Hoci sa zd├í, ┼że d├┤veryhodn├ę nastavenie, ktor├ę sa vy┼żaduje pre mnoh├ę zk-SNARKy, je v rozpore s decentralizovanou povahou distribuovan├Żch ├║─Źtovn├Żch kn├şh, v pr├şpade SNARKov s aktualizovate─żn├Żmi referen─Źn├Żmi re┼ąazcami ho mo┼żno vykona┼ą plne decentralizovan├Żm sp├┤sobom. Hoci v princ├şpe je mo┼żn├ę pou┼ż├şva┼ą aj transparentn├ę SNARKy, ako napr├şklad Halo, vy┼í┼íie op├şsan├ę techniky umo┼ż┼łuj├║, aby sa SNARKy, ako napr├şklad Plonk (ktor├ę m├┤┼żu by┼ą efekt├şvnej┼íie v z├ívislosti od okolnost├ş), spoliehaj├║ce sa na aktualizovate─żn├ę referen─Źn├ę re┼ąazce, bezpe─Źne pou┼ż├şvali aj pre aplik├ície v re┼ąazci - u┼ż neplat├ş, ┼że nastavenia SNARKov s├║ pr├şli┼í neprieh─żadn├ę na to, aby sa im dalo d├┤verova┼ą, ak v├┤bec niekedy boli.


(Nap├şsal Thomas Kerber) - preklad @Martin.M
P├┤vodn├Ż ─Źl├ínok: Zk-SNARKs: updatable setups on the blockchain - IOHK Blog