Úvod

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Podobne ako pri koncepte absolútne silnej šifry z kryptografie, aj reálne protokoly “Publicly Verifiable Random Beacon” (ďalej PVRB) sa snažia len čo najviac priblížiť ideálnej schéme, pretože v reálnych sieťach nie je použiteľný v čistej forme: treba sa striktne dohodnúť na jednom bite, kôl musí byť veľa a všetky správy musia byť perfektne rýchle a vždy doručené. V reálnych sieťach to tak samozrejme nie je. Preto pri navrhovaní PVRB pre špecifické úlohy v moderných blockchainoch vzniká okrem nemožnosti kontroly výslednej náhodnosti a kryptografickej sily oveľa viac čisto architektonických a technických problémov.

Pre PVRB je samotný blockchain v podstate komunikačným médiom, v ktorom správy = transakcie. To vám umožňuje čiastočne abstrahovať od problémov siete, nedoručovania správ, problémov s middleware – všetky tieto riziká berie na seba decentralizovaná sieť a jej hlavnou hodnotou pre PVRB je nemožnosť odvolať alebo skorumpovať už odoslanú transakciu – to robí neumožniť účastníkom odmietnuť účasť na protokole, pokiaľ nevykonali úspešný útok na konsenzus. Táto úroveň bezpečnosti je prijateľná, takže PVRB by mal byť odolný voči tajným dohodám zo strany účastníkov presne v rovnakom rozsahu ako hlavný reťazec blockchainu. To tiež naznačuje, že PVRB musí byť súčasťou konsenzu, ak sa sieť dohodne na hlavnom blockchaine, aj keď sa dohodne aj na jedinej spravodlivej výslednej náhode. Alebo je PVRB jednoducho samostatný protokol implementovaný inteligentnou zmluvou, ktorá funguje asynchrónne s ohľadom na blockchain a bloky. Obe metódy majú svoje výhody a nevýhody a výber medzi nimi je mimoriadne netriviálny.

Dva spôsoby implementácie PVRB

Popíšme si podrobnejšie dve možnosti implementácie PVRB – samostatnú verziu, ktorá funguje pomocou inteligentného kontraktu nezávislého na blockchaine, a verziu integrovanú do konsenzu, zabudovanú do protokolu, podľa ktorej sa sieť dohodne na blockchaine a tzv. transakcie, ktoré sa majú zahrnúť. Vo všetkých prípadoch budem mať na mysli populárne blockchainové motory: Ethereum, EOS a všetky im podobné v spôsobe, akým hosťujú a spracúvajú inteligentné zmluvy.

Samostatná zmluva

PVRB je v tejto verzii smart kontrakt, ktorý akceptuje transakcie náhodných producentov (ďalej len RP), spracováva ich, kombinuje výsledky a v dôsledku toho sa dostáva k určitej hodnote, ktorú môže z tohto kontraktu získať každý užívateľ. Táto hodnota nemusí byť uložená priamo v zmluve, ale môže byť reprezentovaná iba údajmi, z ktorých možno deterministicky získať jednu a len jednu hodnotu výslednej náhodnosti. V tejto schéme sú RP používateľmi blockchainu a komukoľvek môže byť umožnené zúčastniť sa procesu generovania.

Možnosť so samostatnou zmluvou je dobrá:

• prenosnosť (zmluvy je možné presúvať z blockchainu do blockchainu)
• jednoduchosť implementácie a testovania (zmluvy sa ľahko píšu a testujú)
• pohodlie pri implementácii ekonomických schém (je ľahké vytvoriť si vlastný token, ktorého logika slúži na účely PVRB)
• možnosť spustenia na už fungujúcich blockchainoch

Má to aj nevýhody:

• silné obmedzenia výpočtových zdrojov, objemu transakcií a úložiska (inými slovami, cpu/mem/io)
• obmedzenia operácií v rámci zmluvy (nie sú k dispozícii všetky pokyny, je ťažké pripojiť externé knižnice)
• neschopnosť organizovať správy rýchlejšie, ako sú transakcie zahrnuté v blockchaine

Táto možnosť je vhodná na implementáciu PVRB, ktorú je potrebné spustiť na existujúcej sieti, neobsahuje zložitú kryptografiu a nevyžaduje veľký počet interakcií.

Konsenzuálne integrované

V tejto verzii je PVRB implementovaný v kóde uzla blockchainu, zabudovaný alebo bežiaci paralelne s výmenou správ medzi uzlami blockchainu. Výsledky protokolu sa zapisujú priamo do vytvorených blokov a protokolové správy sa posielajú cez sieť p2p medzi uzlami. Keďže výsledkom protokolu sú čísla, ktoré sa majú zapisovať do blokov, musí na nich sieť dosiahnuť konsenzus. To znamená, že správy PVRB, podobne ako transakcie, musia byť overené uzlami a zahrnuté do blokov, aby každý účastník siete mohol overiť súlad s protokolom PVRB. To nás automaticky vedie k jasnému riešeniu - ak sa sieť dohodne na konsenze o bloku a transakciách v ňom, potom by PVRB mal byť súčasťou konsenzu, a nie samostatný protokol. V opačnom prípade je možné, že blok je platný z hľadiska konsenzu, ale nie je dodržaný protokol PVRB a z hľadiska PVRB blok nemôže byť akceptovaný. Ak sa teda zvolí možnosť „integrovaná do konsenzu“, PVRB sa stane dôležitou súčasťou konsenzu.

Pri popise implementácií PVRB na úrovni konsenzu siete sa v žiadnom prípade nemožno vyhnúť problémom finality. Finalita je mechanizmus používaný v deterministických konsenzoch, ktorý uzamkne blok (a reťaz, ktorá k nemu vedie), ktorý je konečný a nikdy nebude zahodený, aj keď dôjde k paralelnej vidlici. Napríklad v Bitcoine takýto mechanizmus neexistuje – ak zverejníte reťazec väčšej zložitosti, nahradí akýkoľvek menej zložitý, bez ohľadu na dĺžku reťazcov. A napríklad v EOS sú finálne takzvané Last Irreversible Blocks, ktoré sa objavujú v priemere každých 432 blokov (12*21 + 12*15, pre-vote + pre-commit). Tento proces v podstate čaká na podpisy 2/3 výrobcov blokov (ďalej len BP). Keď sa objavia vidličky, ktoré sú staršie ako posledný LIB, jednoducho sa vyhodia. Tento mechanizmus umožňuje zaručiť, že transakcia je zahrnutá do blockchainu a nikdy nebude vrátená späť, bez ohľadu na to, aké zdroje má útočník. Posledné bloky sú tiež bloky podpísané 2/3 BP v Hyperledger, Tendermint a iných konsenzoch založených na pBFT. Tiež má zmysel vytvoriť protokol na zabezpečenie finality ako doplnok ku konsenzu, pretože môže pracovať asynchrónne s výrobou a publikovaním blokov. Tu je jeden dobrý článok o definitívnosti v Ethereu.

Finalita je mimoriadne dôležitá pre používateľov, ktorí sa bez nej môžu stať obeťami útoku „dvojitých výdavkov“, kde BP „drží“ bloky a zverejní ich potom, čo sieť „uvidí“ dobrú transakciu. Ak neexistuje konečnosť, zverejnená vidlica nahradí blok „dobrou“ transakciou inou, zo „zlej“ vidlice, pri ktorej sa rovnaké prostriedky prevedú na adresu útočníka. V prípade PVRB sú požiadavky na finalitu ešte prísnejšie, keďže budovanie vidlíc pre PVRB znamená pre útočníka možnosť pripraviť si niekoľko náhodných možností s cieľom zverejniť tú najziskovejšiu a obmedzenie času možného útoku je dobré riešenie.

Najlepšou možnosťou je preto spojiť PVRB a finalitu do jedného protokolu – potom finalizovaný blok = finalizovaný náhodný, a to je presne to, čo sme potrebovali získať. Teraz hráči dostanú zaručený náhodný výber za N sekúnd a môžu si byť istí, že ho nie je možné vrátiť späť alebo prehrať znova.

Možnosť integrovaná na základe konsenzu je dobrá:

• možnosť asynchrónnej implementácie vo vzťahu k výrobe blokov - bloky sa vyrábajú ako obvykle, ale paralelne s tým môže fungovať protokol PVRB, ktorý nevytvára náhodnosť pre každý blok
• schopnosť implementovať aj ťažkú ​​kryptografiu bez obmedzení uložených na smart kontrakty
• schopnosť organizovať výmenu správ rýchlejšie ako transakcie sú zahrnuté v blockchaine, napríklad časť protokolu môže fungovať medzi uzlami bez distribúcie správ cez sieť

Má to aj nevýhody:

• Ťažkosti pri testovaní a vývoji - budete musieť emulovať chyby siete, chýbajúce uzly, hard forky siete
• Chyby implementácie vyžadujú sieťový hardfork

Obidva spôsoby implementácie PVRB majú právo na život, ale implementácia inteligentných zmlúv v moderných blockchainoch je stále dosť obmedzená vo výpočtových zdrojoch a akýkoľvek prechod na serióznu kryptografiu je často jednoducho nemožný. A budeme potrebovať serióznu kryptografiu, ako bude ukázané nižšie. Hoci je tento problém zjavne dočasný, na vyriešenie mnohých problémov je potrebná seriózna kryptografia v kontraktoch a postupne sa objavuje (napríklad systémové kontrakty pre zkSNARK v Ethereu)

Blockchain, ktorý poskytuje transparentný a spoľahlivý protokolový kanál na zasielanie správ, to nerobí zadarmo. Každý decentralizovaný protokol musí brať do úvahy možnosť útoku Sybil, akúkoľvek akciu môžu vykonať spojené sily viacerých účtov, preto je pri návrhu potrebné brať do úvahy schopnosť útočníkov vytvoriť ľubovoľný počet protokolov účastníci konajúci v tajnej dohode.

PVRB a blokové premenné.

Neklamal som, keď som povedal, že ešte nikto neimplementoval dobrý PVRB, testovaný mnohými hazardnými aplikáciami, v blockchainoch. Odkiaľ sa potom na Ethereum a EOS berie toľko aplikácií na hazardné hry? To ma prekvapuje rovnako ako vás, kde vzali toľko „trvalých“ náhod v úplne deterministickom prostredí?

Obľúbeným spôsobom, ako získať náhodnosť v blockchaine, je zobrať z bloku nejaký druh „nepredvídateľnej“ informácie a na základe nej vytvoriť náhodnú – jednoducho hashovaním jednej alebo viacerých hodnôt. Dobrý článok o problémoch takýchto schém tu. Môžete vziať ktorúkoľvek z „nepredvídateľných“ hodnôt v bloku, napríklad hash bloku, počet transakcií, zložitosť siete a ďalšie vopred neznáme hodnoty. Potom ich hashujte, jeden alebo viac, a teoreticky by ste mali dostať skutočnú náhodu. Na úvodný papier môžete dokonca pridať, že vaša schéma je „post-kvantovo bezpečná“ (pretože existujú kvantovo odolné hašovacie funkcie :)).

Ale ani postkvantové bezpečné hashe nestačia, bohužiaľ. Tajomstvo spočíva v požiadavkách na PVRB, dovoľte mi ich pripomenúť z predchádzajúceho článku:

1. Výsledok musí mať preukázateľne rovnomerné rozloženie, t. j. musí byť založený na preukázateľne silnej kryptografii.
2. Nie je možné ovládať žiadny z bitov výsledku. Výsledkom je, že výsledok nemožno predvídať vopred.
3. Generačný protokol nemôžete sabotovať tým, že sa nezúčastníte na protokole alebo preťažením siete správami o útoku
4. Všetky vyššie uvedené musia byť odolné voči tajným dohodám s prípustným počtom nepoctivých účastníkov protokolu (napríklad 1/3 účastníkov).

V tomto prípade je splnená iba požiadavka 1 a nie je splnená požiadavka 2. Hašovaním nepredvídateľných hodnôt z bloku získame rovnomerné rozdelenie a dobré náhody. Ale BP má aspoň možnosť „zverejniť blok alebo nie“. BP si teda môže vybrať aspoň z DVOCH náhodných možností: „svojej“ a tej, ktorá sa ukáže, ak blok urobí niekto iný. BP môže vopred „odpozerať“, čo sa stane, ak zverejní blok, a jednoducho sa rozhodne, či to urobí alebo nie. Pri hraní napríklad „párne-nepárne“ alebo „červená/čierna“ v rulete teda môže zverejniť blok iba vtedy, ak vidí výhru. To tiež znemožňuje použitie stratégie napríklad blokového hashu „z budúcnosti“. V tomto prípade hovoria, že „bude použitý náhodný, ktorý sa získa hašovaním aktuálnych údajov a hashom budúceho bloku s výškou napríklad N + 42, kde N je aktuálna výška bloku. Toto trochu posilňuje schému, ale stále umožňuje BP, aj keď v budúcnosti, vybrať si, či bude blokovať alebo zverejniť.

Softvér BP sa v tomto prípade stáva komplikovanejším, ale nie príliš. Jednoducho, pri validácii a zaradení transakcie do bloku je rýchla kontrola, či ide o výhru, prípadne výber jedného parametra transakcie pre získanie vysokej pravdepodobnosti výhry. Zároveň je takmer nemožné chytiť inteligentného BP za takéto manipulácie, zakaždým môžete použiť nové adresy a vyhrať kúsok po kúsku bez vzbudenia podozrenia.

Takže metódy využívajúce informácie z bloku nie sú vhodné ako univerzálna implementácia PVRB. V obmedzenej verzii, s obmedzeniami veľkosti stávok, obmedzením počtu hráčov a/alebo registráciou KYC (aby jeden hráč nemohol používať viacero adries), môžu tieto schémy fungovať pre malé hry, ale nič viac.

PVRB a commit-reveal.

Dobre, vďaka hashovaniu a aspoň relatívnej nepredvídateľnosti blokového hashu a ďalších premenných. Ak riešite problém čelných baníkov, mali by ste si zaobstarať niečo vhodnejšie. Pridajme používateľov do tejto schémy - nech tiež ovplyvňujú náhodnosť: každý zamestnanec technickej podpory vám povie, že najnáhodnejšia vec v IT systémoch je činnosť používateľov :)

Naivná schéma, keď používatelia jednoducho posielajú náhodné čísla a výsledok sa počíta napríklad ako hash ich súčtu, nie je vhodná. V tomto prípade môže posledný hráč výberom vlastného náhodného výberu kontrolovať, aký bude výsledok. To je dôvod, prečo sa používa veľmi často používaný vzor odovzdania a odhalenia. Účastníci najskôr pošlú haše zo svojich náhod (commits) a potom sami náhodné náhody otvoria (odhalia). Fáza „odhalenia“ sa začína až po zhromaždení potrebných odovzdaní, takže účastníci môžu poslať presne ten náhodný hash, z ktorého poslali predtým. Teraz to všetko spojme s parametrami bloku a lepšie ako s blokom prevzatým z budúcnosti (náhodnosť možno nájsť iba v jednom z budúcich blokov) a voila - náhodnosť je pripravená! Teraz každý hráč ovplyvňuje výslednú náhodnosť a môže „poraziť“ škodlivý BP tým, že ho prepíše svojou vlastnou, vopred neznámou náhodnosťou... Môžete tiež pridať ochranu proti sabotovaniu protokolu tým, že ho neotvoríte vo fáze odhalenia – jednoducho požiadavkou, aby bola k transakcii pri zaviazaní priložená určitá čiastka — zábezpeka, ktorá bude vrátená iba počas odhaľovacieho postupu. V tomto prípade bude zaviazanie a neodhalenie nerentabilné.

Bol to dobrý pokus a takéto schémy existujú aj v herných DApps, ale bohužiaľ to opäť nestačí. Teraz môže výsledok ovplyvniť nielen baník, ale aj ktorýkoľvek účastník protokolu. Samotnú hodnotu je stále možné kontrolovať s menšou variabilitou a nákladmi, ale ako v prípade ťažiara, ak sú výsledky žrebovania hodnotnejšie ako poplatok za účasť na protokole PVRB, potom náhodný -producent(RP) sa môže rozhodnúť, či odhalí, a stále si môže vybrať z najmenej dvoch náhodných možností.
Bolo však možné potrestať tých, ktorí sa dopustia a neodhalia, a táto schéma sa bude hodiť. Jeho jednoduchosť je vážnou výhodou – serióznejšie protokoly vyžadujú oveľa výkonnejšie výpočty.

PVRB a deterministické signatúry.

Existuje ďalší spôsob, ako prinútiť RP poskytnúť pseudonáhodné číslo, ktoré nemôže ovplyvniť, ak je vybavené „predobrazom“ – ide o deterministický podpis. Takýto podpis je napríklad RSA a nie je to ECS. Ak má RP pár kľúčov: RSA a ECC a podpíše svojim súkromným kľúčom určitú hodnotu, tak v prípade RSA získa JEDEN A LEN JEDEN podpis a v prípade ECS môže vygenerovať ľubovoľný počet rôzne platné podpisy. Pri vytváraní ECS podpisu sa totiž používa náhodné číslo, ktoré si vyberie podpisovateľ a dá sa zvoliť ľubovoľným spôsobom, čím dáva podpisovateľovi možnosť vybrať si jeden z viacerých podpisov. V prípade RSA: „jedna vstupná hodnota“ + „jeden pár kľúčov“ = „jeden podpis“. Nie je možné predpovedať, aký podpis získa ďalší RP, takže PVRB s deterministickými podpismi možno zorganizovať kombináciou RSA podpisov niekoľkých účastníkov, ktorí podpísali rovnakú hodnotu. Napríklad predchádzajúci náhodný. Táto schéma šetrí veľa zdrojov, pretože podpisy sú potvrdením správneho správania podľa protokolu a zdrojom náhodnosti.

Avšak aj s deterministickými podpismi je schéma stále zraniteľná voči problému „posledného aktéra“. Posledný účastník sa stále môže rozhodnúť, či podpis zverejní alebo nie, čím bude kontrolovať výsledok. Schému môžete upravovať, pridávať do nej blokové hash, kolovať tak, aby sa výsledok nedal vopred predvídať, ale všetky tieto techniky, aj keď zohľadnia mnohé úpravy, stále nechávajú nevyriešený problém vplyvu jedného účastníka na kolektív. výsledkom je nedôveryhodné prostredie a môže fungovať len v rámci ekonomických a časových obmedzení. Okrem toho je veľkosť RSA kľúčov (1024 a 2048 bitov) pomerne veľká a veľkosť pre blockchainové transakcie je mimoriadne dôležitý parameter. Zrejme neexistuje jednoduchý spôsob, ako problém vyriešiť, poďme ďalej.

PVRB a schémy tajného zdieľania

V kryptografii existujú schémy, ktoré umožňujú sieti dohodnúť sa na jedinej hodnote PVRB, pričom takéto schémy sú odolné voči akémukoľvek zlomyseľnému konaniu niektorých účastníkov. Jeden užitočný protokol, s ktorým sa oplatí zoznámiť, je Shamirova schéma tajného zdieľania. Slúži na rozdelenie tajomstva (napríklad tajného kľúča) na niekoľko častí a tieto časti rozdelí N účastníkom. Tajomstvo je distribuované takým spôsobom, že M dielov z N postačuje na jeho získanie, pričom to môžu byť ľubovoľné M diely. Ak na prstoch, potom s grafom neznámej funkcie, účastníci si vymenia body na grafe a po získaní M bodov je možné celú funkciu obnoviť.
Dobré vysvetlenie je uvedené v wiki ale hrať sa s tým prakticky za účelom prehrania protokolu v hlave je užitočné demonštrácie stránku.

Ak by bola schéma FSSS (Fiat-Shamir Secret Sharing) použiteľná v čistej forme, išlo by o nezničiteľné PVRB. Vo svojej najjednoduchšej forme môže protokol vyzerať takto:

• Každý účastník si vygeneruje svoj vlastný náhodný výber a rozdelí z neho zdieľania medzi ostatných účastníkov
• Každý účastník odhalí svoju časť tajomstiev ostatných účastníkov
• Ak má účastník viac ako M podielov, potom je možné vypočítať počet tohto účastníka a bude jedinečný bez ohľadu na množinu odhalených účastníkov
• Kombinácia odhalených náhod je želaným PVRB

Tu už individuálny účastník neovplyvňuje výsledky protokolu, okrem prípadov, keď dosiahnutie prahu odhalenia náhodnosti závisí výlučne od neho. Preto tento protokol, ak existuje požadovaný podiel RP pracujúcich na protokole a dostupných, funguje, implementuje požiadavky na kryptografickú silu a je odolný voči problému „posledného aktéra“.

Toto by mohla byť ideálna možnosť, táto schéma PVRB založená na zdieľaní tajomstva Fiat-Shamir je opísaná napr. toto článok. Ale ako už bolo spomenuté vyššie, ak sa to pokúsite použiť priamo v blockchaine, objavia sa technické obmedzenia. Tu je príklad testovacej implementácie protokolu v EOS smart kontrakte a jeho najdôležitejšej časti – kontroly zverejneného účastníka zdieľania: kód. Z kódu môžete vidieť, že overenie si vyžaduje niekoľko skalárnych násobení a použité čísla sú veľmi veľké. Malo by byť zrejmé, že v blockchainoch k overeniu dochádza v momente, keď výrobca bloku spracováva transakciu, a vo všeobecnosti každý účastník musí ľahko overiť správnosť protokolu, takže požiadavky na rýchlosť funkcie overenia sú veľmi vážne. . Pri tejto možnosti sa táto možnosť ukázala ako neúčinná, pretože overenie sa nezmestilo do limitu transakcie (0.5 sekundy).

Účinnosť overovania je jednou z najdôležitejších požiadaviek na používanie, vo všeobecnosti, akýchkoľvek pokročilých kryptografických schém v blockchaine. Vytváranie dôkazov, príprava správ – tieto postupy je možné stiahnuť z reťaze a vykonávať ich na vysokovýkonných počítačoch, ale overenie nemožno obísť – to je ďalšia dôležitá požiadavka na PVRB.

PVRB a prahové podpisy

Po oboznámení sa so schémou tajného zdieľania sme objavili celú triedu protokolov spojených kľúčovým slovom „threshold“. Keď si zverejnenie niektorých informácií vyžaduje účasť M čestných účastníkov z N a množina čestných účastníkov môže byť ľubovoľnou podmnožinou N, hovoríme o „prahových“ schémach. Práve oni nám umožňujú riešiť problém „posledného aktéra“, ak teraz útočník neprezradí svoju časť tajomstva, urobí to za neho iný, čestný účastník. Tieto schémy umožňujú dohodu o jednom a jedinom význame, aj keď je protokol niektorými účastníkmi sabotovaný.

Kombinácia deterministických signatúr a prahových schém umožnila vyvinúť veľmi pohodlnú a sľubnú schému na implementáciu PVRB - ide o deterministické prahové signatúry. Tu článok o rôznych použitiach prahových podpisov a tu je ďalší dobrý longread od Dash.

Posledný článok popisuje podpisy BLS (BLS znamená Boneh-Lynn-Shacham, tu článok), ktoré majú pre programátorov veľmi dôležitú a mimoriadne pohodlnú kvalitu – verejné, tajné, verejné kľúče a podpisy BLS je možné navzájom kombinovať pomocou jednoduchých matematických operácií, pričom ich kombinácie zostávajú platnými kľúčmi a podpismi, čo vám umožňuje jednoducho agregovať mnohé podpisy do jedného a veľa verejných kľúčov do jedného. Sú tiež deterministické a vytvárajú rovnaký výsledok pre rovnaké vstupné údaje. Vďaka tejto kvalite sú kombinácie podpisov BLS samy o sebe platnými kľúčmi, čo umožňuje implementáciu možnosti, v ktorej M z N účastníkov vytvorí jeden a iba jeden podpis, ktorý je deterministický, verejne overiteľný a nepredvídateľný, kým ho neotvorí Mth. účastník .

V schéme s prahovými podpismi BLS každý účastník niečo podpíše pomocou BLS (napríklad predchádzajúci náhodný) a spoločný prahový podpis je požadovaný náhodný. Kryptografické vlastnosti podpisov BLS spĺňajú požiadavky na náhodnú kvalitu, prahová časť chráni pred „posledným aktérom“ a jedinečná kombinovateľnosť kľúčov umožňuje implementovať mnoho ďalších zaujímavých algoritmov, ktoré umožňujú napríklad efektívnu agregáciu protokolových správ. .

Ak teda staviate PVRB na svojom blockchaine, s najväčšou pravdepodobnosťou skončíte so schémou prahových podpisov BLS, niekoľko projektov ju už používa. Napríklad DFinity (tu benchmark, ktorý implementuje obvod, a tu príklad implementácie overiteľného zdieľania tajomstiev) alebo Keep.network (tu je ich náhodný maják žltý papier, Ale príklad smart kontrakt obsluhujúci protokol).

Realizácia PVRB

Bohužiaľ, stále nevidíme hotový protokol implementovaný v blockchainoch PVRB, ktorý by preukázal svoju bezpečnosť a stabilitu. Aj keď sú samotné protokoly pripravené, ich technická aplikácia na existujúce riešenia nie je jednoduchá. Pre centralizované systémy nemá PVRB zmysel a decentralizované sú prísne obmedzené vo všetkých výpočtových zdrojoch: CPU, pamäť, úložisko, I/O. Navrhovanie PVRB je kombináciou rôznych protokolov s cieľom vytvoriť niečo, čo spĺňa všetky požiadavky na aspoň nejaký životaschopný blockchain. Jeden protokol počíta efektívnejšie, ale vyžaduje viac správ medzi RP, zatiaľ čo druhý vyžaduje veľmi málo správ, ale vytvorenie dôkazu môže byť úlohou, ktorá trvá desiatky minút alebo dokonca hodiny.

Uvediem zoznam faktorov, ktoré budete musieť zvážiť pri výbere kvalitného PVRB:

• Kryptografická sila. Váš PVRB musí byť prísne nezaujatý, bez schopnosti ovládať jediný bit. V niektorých schémach to tak nie je, preto zavolajte kryptografa
• Problém „posledného herca“.. Váš PVRB musí byť odolný voči útokom, pri ktorých si útočník ovládajúci jedno alebo viacero RP môže vybrať jeden z dvoch výsledkov.
• Problém so sabotážou protokolu. Váš PVRB musí byť odolný voči útokom, pri ktorých sa útočník ovládajúci jedno alebo viacero RP rozhodne, či bude náhodný alebo nie, a dá sa to zaručiť alebo s určitou pravdepodobnosťou ovplyvniť.
• Problém s počtom správ. Vaše RP by mali posielať minimum správ do blockchainu a mali by sa čo najviac vyhýbať synchrónnym akciám, ako sú situácie typu „Poslal som nejaké informácie, čakám na odpoveď od konkrétneho účastníka“. V p2p sieťach, najmä geograficky rozptýlených, by ste nemali počítať s rýchlou odozvou
• Problém výpočtovej zložitosti. Overenie ktorejkoľvek fázy PVRB on-chain by malo byť mimoriadne jednoduché, pretože ho vykonávajú všetci plnohodnotní klienti siete. Ak sa implementácia vykonáva pomocou inteligentnej zmluvy, potom sú požiadavky na rýchlosť veľmi prísne
• Problém dostupnosti a živosti. Váš PVRB by sa mal snažiť byť odolný voči situáciám, keď sa časť siete na určitý čas stane nedostupnou a časť RP jednoducho prestane fungovať
• Problém dôveryhodného nastavenia a počiatočnej distribúcie kľúča. Ak váš PVRB používa primárne nastavenie protokolu, potom je to samostatný veľký a vážny príbeh. Tu príklad. Ak si účastníci musia pred spustením protokolu povedať svoje kľúče, je to tiež problém, ak sa zmení zloženie účastníkov
• Vývojové problémy. Dostupnosť knižníc v požadovaných jazykoch, ich bezpečnosť a výkon, publicita, komplexné testy a pod.

Napríklad podpisy BLS s prahom majú významný problém – pred začatím práce si účastníci musia navzájom rozdeliť kľúče a zorganizovať skupinu, v rámci ktorej bude prah fungovať. To znamená, že minimálne jedno kolo výmeny v decentralizovanej sieti bude musieť počkať a vzhľadom na to, že vygenerovaný rand je napríklad potrebný v hrách takmer v reálnom čase, znamená to, že v tejto fáze je možná sabotáž protokolu. a výhody systému prahových hodnôt sa strácajú. Tento problém je už jednoduchší ako predchádzajúce, ale stále si vyžaduje vypracovanie samostatného postupu na vytváranie prahových skupín, ktoré bude potrebné chrániť ekonomicky, prostredníctvom vkladov a vyberania finančných prostriedkov (sekcie) od účastníkov, ktorí nedodržiavajú protokol. Taktiež overenie BLS s prijateľnou úrovňou zabezpečenia sa jednoducho nezmestí napríklad do štandardnej transakcie EOS alebo Ethereum – na overenie jednoducho nie je dostatok času. Kód zmluvy je WebAssembly alebo EVM, vykonávaný virtuálnym strojom. Kryptografické funkcie nie sú natívne (zatiaľ) implementované a fungujú desaťkrát pomalšie ako bežné kryptografické knižnice. Mnohé protokoly nespĺňajú požiadavky jednoducho na základe objemu kľúča, napríklad 1024 a 2048 bitov pre RSA, čo je 4-8 krát viac ako štandardný podpis transakcie v bitcoinoch a ethereu.

Svoju úlohu zohráva aj prítomnosť implementácií v rôznych programovacích jazykoch - ktorých je málo, najmä pre nové protokoly. Možnosť s integráciou do konsenzu vyžaduje napísanie protokolu v jazyku platformy, takže budete musieť hľadať kód v Go for goth, v Rust pre Parity, v C++ pre EOS. Každý bude musieť hľadať kód JavaScript, a keďže JavaScript a kryptografia nie sú príliš blízkymi priateľmi, pomôže WebAssembly, ktorý sa teraz rozhodne považuje za ďalší dôležitý internetový štandard.

Záver

Dúfam, že v predchádzajúcej článok Podarilo sa mi vás presvedčiť, že generovanie náhodných čísel na blockchaine je kritické pre mnohé aspekty života decentralizovaných sietí a týmto článkom som ukázal, že táto úloha je mimoriadne ambiciózna a náročná, no dobré riešenia už existujú. Vo všeobecnosti je konečný návrh protokolu možný až po vykonaní rozsiahlych testov, ktoré zohľadňujú všetky aspekty od nastavenia až po emuláciu chýb, takže je nepravdepodobné, že by ste našli hotové recepty v tímových whitepaperoch a článkoch, a my to určite nenájdeme. rozhodnite sa v nasledujúcom roku alebo dvoch napíšte „urobte to takto, presne správne“.

Ahoj, pre náš PVRB v blockchaine, ktorý sa vyvíja Haya, sme sa dohodli na používaní prahových BLS podpisov, plánujeme implementovať PVRB na úrovni konsenzu, keďže overovanie v smart kontraktoch s prijateľnou úrovňou bezpečnosti zatiaľ nie je možné. Je možné, že použijeme dve schémy naraz: po prvé, drahé tajné zdieľanie na vytvorenie dlhodobého random_seed, a potom ho použijeme ako základ pre vysokofrekvenčné náhodné generovanie pomocou deterministických prahových BLS podpisov, možno sa obmedzíme len na jedna zo schém. Žiaľ, nedá sa vopred povedať, aký bude protokol, dobré je len to, že ako vo vede, aj v inžinierskych problémoch je výsledkom aj negatívny výsledok a každý nový pokus o vyriešenie problému je ďalším krokom pre výskum všetkých zainteresovaných v probléme. Aby sme vyhoveli obchodným požiadavkám, riešime špecifický praktický problém – poskytovanie herných aplikácií spoľahlivým zdrojom entropie, takže musíme venovať pozornosť aj samotnému blockchainu, najmä otázkam finality reťazca a správy siete.

A aj keď zatiaľ v blockchainoch nevidíme overený odolný PVRB, ktorý by bol dostatočne dlhý na to, aby ho otestovali reálne aplikácie, viacnásobné audity, záťaže a samozrejme reálne útoky, no množstvo možných ciest potvrdzuje, že existuje riešenie a ktorý z týchto algoritmov nakoniec vyrieši problém. S radosťou sa podelíme o výsledky a poďakujeme ostatným tímom, ktoré tiež pracujú na tejto problematike, za články a kód, vďaka ktorému inžinieri nestúpia dvakrát na ten istý rake.

Takže, keď stretnete programátora, ktorý navrhuje decentralizované náhodné, buďte pozorní a starostliví a v prípade potreby poskytnite psychologickú pomoc :)

Zdroj: hab.com