Uvod

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

Так же, как и в случае концепции абсолютно стойкого шифра из криптографии, реальные протоколы "Publicly Verifiable Random Beacon" (далее PVRB) лишь пытаются максимально приблизиться к идеальной схеме, поскольку в реальных сетях в чистом виде она неприменима: необходимо договариваться строго об одном бите, раундов должно быть много, а все сообщения должны передаваться идеально быстро и всегда дойти до адресата. Разумеется, в реальных сетях это не так. Поэтому при проектировании PVRB под конкретные задачи в современных блокчейнах, помимо невозможности контроля получаемого рандома и криптографической стойкости, возникает еще много чисто архитектурных и технических проблем.

Сам блокчейн является для PVRB по сути средой для коммуникации, в которой сообщения равны транзакциям. Это позволяет частично абстрагироваться от сетевых проблем, недоставки сообщений, проблем промежуточного ПО — все эти риски берет на себя децентрализованная сеть, и главная ее ценность для PVRB — невозможность отозвать или испортить уже отправленную транзакцию — это не позволяет участникам отказаться от участия в протоколе, если только они не провели успешную атаку на консенсус. Такой уровень безопасности приемлем, поэтому PVRB должен быть устойчив к сговорам участников ровно в такой же мере, как и основная цепочка блокчейна. Также это намекает на то, что PVRB должен быть частью консенсуса, если сеть договорилась насчет основной цепочки блоков, пусть одновременно она согласится и на единственный честный результирующий рандом. Либо PVRB — это просто автономный протокол, реализованный смарт-контрактом, работающим асинхронно по отношению к блокчейну и блокам. У обоих способов есть свои преимущества и недостатки, и выбор между ними крайне нетривиален.

Два способа имплементации PVRB

Опишем подробнее два варианта имплементации PVRB — автономную версию, работающую с использованием независимого от блокчейна смарт-контракта, и встроенную в консенсусную систему — согласно которой сеть договаривается о цепочке блоков и включаемых транзакциях. Во всех случаях я буду иметь в виду популярные блокчейн-движки: Ethereum, EOS и все, похожие на них по способу размещения и процессинга смарт-контрактов.

Samostojni kontrakt

V tem primeru PVRB predstavlja pametno pogodbo, ki sprejme transakcije random-producerjev (v nadaljevanju RP), jih obdeluje, kombinira rezultate in na koncu pride do neke vrednosti, ki jo lahko pridobi vsak uporabnik iz te pogodbe. Ta vrednost morda ne bo neposredno shranjena v pogodbi, ampak bo predstavljena le s podatki, iz katerih je mogoče deterministično pridobiti eno in samo eno vrednost rezultantnega naključja. V tej shemi so RP uporabniki verige blokov, sodelovanje pri procesu generiranja pa je mogoče omogočiti komurkoli.

Izbira samostojnega kontrakta je dobra:

prenosljivostjo (pogodbe je mogoče prenašati iz verige blokov v verigo blokov)
enostavnostjo pri izvajanju in testiranju (pogodbe je enostavno pisati in testirati)
prikladnostjo pri izvajanju ekonomskih shem (enostavno je izdelati svoj žeton, katerega logika služi ciljem PVRB)
možnostjo zagoniti v že delujočih verigah blokov

Ima pa tudi pomanjkljivosti:

močne omejitve na vire pri izračunih, obsegu transakcij in shranjevanju (poenostavljeno rečeno cpu/mem/io)
omejitve pri operacijah znotraj pogodbe (ne vse instrukcije so na voljo, težko je vključiti zunanje knjižnice)
nemogočnost organizacije izmenjave sporočil hitreje, kot se transakcije vključijo v verigo blokov

Ta različica je primerna za izvajanje PVRB, ki ga je treba zagnati v že obstoječi mreži, ne da bi vseboval zapleteno kriptografijo in ne zahteva velikega števila interakcij.

Integriran konsenzus

V tej različici PVRB je implementiran v kodi blockchain vozlišča in ali deluje vzporedno z izmenjavami sporočil med vozlišči blockchaina. Rezultati protokola so zabeleženi neposredno v ustvarjenih blokih, sporočila protokola pa se po p2p omrežju pošiljajo med vozlišči. Ker protokol generira številke, ki jih je treba zabeležiti v blokih, se mora omrežje o teh številkah strinjati. To pomeni, da morajo biti sporočila PVRB, kot tudi transakcije, validirana z vozlišči in vključena v bloke, tako da lahko vsak udeleženec omrežja preveri skladnost s protokolom PVRB. To nas avtomatsko pripelje do očitne rešitve — če se omrežje dogovori o konsenzu glede bloka in transakcij v njem, potem mora biti PVRB del konsenza, ne pa ločen protokol. Pripravlja se lahko situacija, kjer je blok veljaven z vidika konsenza, a protokol PVRB ni upoštevan, in z vidika PVRB blok ne more biti sprejet. Tako v primeru izbire “konsensus-integriranega” modela PVRB postane pomemben del konsenza.

Pri opisovanju implementacij PVRB na ravni konsenza v omrežju nikakor ne smemo spregledati vprašanj dokončnosti. Dokončnost je mehanizem, ki se uporablja v determinističnih konsenzih, ki fiksira blok (in verigo, ki vodi do njega), ki je dokončen in nikoli ne bo izločen, tudi če se pojavi paralelna forks. Na primer, v Bitcoin-u takšen mehanizem ne obstaja — če se objavi veriga večje zapletenosti, bo zamenjala katero koli manj zapleteno, ne glede na dolžino verig. V EOS-u pa so dokončni tako imenovani Zadnji Nepovratni Bloki, ki se pojavijo povprečno vsakih 432 blokov (12*21 + 12*15, pre-vote + pre-commit). Ta postopek je v bistvu čakanje na 2/3 podpisov block-producerjev (BP). Ko se pojavijo forki, ki so starejši od zadnjega LIB, se preprosto zavržejo. Ta mehanizem omogoča, da se zagotovo potrdi, da je transakcija vključena v blockchain in nikoli ne bo umaknjena, ne glede na to, kakšne vire ima napadalec. Tudi dokončni bloki so bloki, ki jih podpiše 2/3 BP v Hyperledger, Tendermint in drugih pBFT-baziranih konsenzih. Poleg tega ima smisel, da protokol za zagotavljanje dokončnosti deluje kot nadgradnja nad konsenzom, saj lahko deluje asinhrono s proizvodnjo in objavo blokov. članek o finalnosti v Ethereum.

Finalnost je izredno pomembna za uporabnike, ki brez nje lahko postanejo žrtve napada "double spend", ko BP "zadrži" bloke in jih objavi, potem ko je omrežje "videlo" dobro transakcijo. Če ni finalnosti, objavljen forč zamenja blok z "dobro" transakcijo z drugim, iz "slabega" forka, kjer se ta sredstva prenašajo na naslov napadalca. V primeru PVRB so zahteve po finalnosti še bolj stroge, saj gradnja forkov za PVRB pomeni možnost za napadalca, da pripravi več možnosti naključja, da objavi najbolj ugodno zanj in omeji čas mogoče napadalne akcije — kar je dobra rešitev.

Zato je najboljša možnost združiti PVRB in finalnost v en protokol — takrat je finaliziran blok = finalizirano naključje, kar je prav tisto, kar smo želeli doseči. Zdaj bodo igralci prejeli zagotovljeno naključje v N sekundah in lahko bodo prepričani, da ga ni mogoče preklicati ali ponovno igrati.

Možnost s consensus-integrated je dobra:

z možnostjo asinhrone izvedbe v povezavi s proizvodnjo blokov — bloki se proizvajajo kot običajno, vendar paralelno s tem lahko deluje protokol PVRB, ki proizvaja naključja, ne vsak blok
z možnostjo implementacije tudi težke kriptografije, brez omejitev, ki jih nalagajo pametne pogodbe
z možnostjo organizacije izmenjave sporočil hitreje, kot se transakcije vključujejo v blockchain, na primer del protokola lahko deluje med vozlišči brez širjenja sporočil po omrežju

Ima pa tudi pomanjkljivosti:

težavnost pri testiranju in razvoju — treba bo emulirati omrežne napake, izginjajoča vozlišča, hard forke omrežja
napake v implementaciji zahtevajo hard fork omrežja

Oba načina implementacije PVRB imata pravico do obstoja, vendar je implementacija v pametnih pogodbah v sodobnih blockchainih še vedno precej omejena v računalniških virih, in vsak prehod na resno kriptografijo je pogosto preprosto nemogoč. Resna kriptografija bo potrebna, kot bo prikazano kasneje. Vendar pa je ta težava očitno začasnega značaja, resna kriptografija v pogodbah je potrebna za reševanje številnih nalog, in postopoma se pojavlja (na primer, sistemske pogodbe za zkSNARKs v Ethereum).

Blockchain, which provides a transparent and reliable channel for protocol messaging, is not free. Any decentralized protocol must take into account the possibility of a Sybil attack; any action can be made consistent by the colluding forces of multiple accounts, so when designing it is necessary to consider the attackers' ability to create an arbitrary number of protocol participants acting in collusion.

PVRB and block variables.

I wasn't lying when I said that a good PVRB, validated by numerous gambling applications, has not yet been implemented in blockchains. Then where did such a number of gambling applications in Ethereum and EOS come from? I find it as surprising as you do; how did so many 'resilient' randoms emerge in a fully deterministic environment?

The favorite way to extract randomness in the blockchain is to take some 'unpredictable' information from the block and base randomness on it — by simply hashing one or more values. A good article about the problems of such schemes. ovde. You can take some of the 'unpredictable' values in the block, such as the block hash, the number of transactions, the network difficulty, and other values that are not known in advance. Then hash them, one or more, and ideally, it should produce true randomness. You could even add to the white paper that your scheme is 'post-quantum secure' (since there are quantum-proof hash functions :)).

But even post-quantum secure hashes are not enough, unfortunately. The secret lies in the requirements for PVRB; let me remind you of them from the previous article:

The result must have a provably uniform distribution, i.e., based on provably secure cryptography.
It is impossible to control any of the bits of the result. Consequently, the result cannot be predicted in advance.
The protocol for generating cannot be sabotaged by non-participation in the protocol or by overloading the network with attacking messages.
All of the above must be resilient to collusion by an acceptable number of dishonest participants in the protocol (for example, 1/3 of participants).

V tem primeru je izpolnjena le zahteva 1, medtem ko 2 ni izpolnjena. Z hashiranjem nepredvidljivih vrednosti iz bloka bomo dobili enakomerno porazdelitev in dobre naključno izbrane vrednosti. Vendar ima BP vsaj možnost, da „objavi blok ali ne“. Tako lahko BP vsaj izbira med DVEMA možnostma naključja: „svojim“ in tistim, ki ga ustvarja nekdo drug. BP lahko vnaprej „pogleda“, kaj se bo zgodilo, če objavi blok, in preprosto sprejme odločitev, da ga objavi ali ne. Tako lahko ob igranju, na primer, v „parno-neparno“ ali „rdeče/črno“ pri ruleti objavi blok samo, če vidi zmago. To prav tako onemogoča strategijo uporabe, na primer, hasha bloka „iz prihodnosti“. V tem primeru govorimo, da „bo uporabljen naključno izbrani podatek, ki izhaja iz hashiranja trenutnih podatkov in hasha prihodnjega bloka višine, na primer, N + 42, kjer je N trenutna višina bloka. To nekoliko okrepi shemo, vendar še vedno omogoča BP, da, čeprav v prihodnosti, izbere, ali zadržati blok ali ga objaviti.

Softver BP se v tem primeru zapleta, a ne preveč. Med validacijo in vključitvijo transakcije v blok poteka hitro preverjanje, ali bo zmaga, in morda izbira enega izmed parametrov transakcije, da se doseže velika verjetnost zmage. Hkrati je skoraj nemogoče ujeti pametnega BP-ja pri takšnih manipulacijah, saj vedno lahko koristi nove naslove in pridobiva majhne zmage, ne da bi vzbudil sum.

Tako da načini, ki uporabljajo informacije iz bloka, niso primerni za univerzalno implementacijo PVRB. V omejenem primeru, z omejitvami na višino stav, omejitvami števila igralcev in/ali KYC registracijo (da enemu igralcu ne bi omogočili uporabe več naslovov), te sheme lahko delujejo za manjše igre, vendar ne več.

PVRB in commit-reveal.

No, hvala hashiranju in vsaj relativni nepredvidljivosti hasha bloka ter drugih spremenljivk. Če bomo rešili problem front-running-a rudarjev, bi moralo priti do nečesa bolj primernega. Dodajmo v to shemo uporabnike — naj tudi vplivajo na naključnost: vsak zaposleni v službi za pomoč strankam vam bo povedal, da je najbolj naključno v IT sistemih vedenje uporabnikov 🙂

Naivna shema, v kotoroy pol'zovateli prosto shlyut randomnye chisla, a rezultat vychislyaetsya kak, naprimer, khesh ot ikh summu, ne goditsya. V etom sluchaye posledniy igroka mozhno kontrol'irovat' rezul'tat, vybiraia sobstvennyy random. Poetomu ispol'zuetsya ochen' shiroko ispol'zuyemyy pattern commit-reveal. Uchastniki snachala shlyut kheshy ot svoikh randomov (commit-y), a zatem otkryvayut sami randomy (reveal-y). Fazza “reveal” nachinaetsya lish' posle togo, kak byli sobrany neobkhodimye commit-y, poetomu uchastniki mogut prislat' rovno tot random, khesh ot kotorogo prislali ranee. Teper' slepim vse eto s parametrami bloka, prichom luchshe vzyatogo iz budushchego (random mozhno budet uznat' tol'ko v odnom iz budushchikh blokov), i vuolya — random gotov! Teper' lyuboy igrok vliyaet na rezultat ruandoma i mozhet “pobedit'” zlovrednogo BP, perekryvaya ego random svoim, neizvestnym zaranee, randomom… Yeshchyo mozhno dobavit' zashchitu ot sabotirovanija protokola putem neviskrytiya na etape reveal — prosto potrebuyaya pri commit-e prikladyvat' k transaktsii nekotoruyu summu — strakhovoy deposit, kotoryy vernet'sya tol'ko pri protsedure reveal. V etom sluchaye delat' commit i ne delat' reveal budet nevygodno.

Eto byla khoroshaya popytka, i takie skhemy tozhe yest' v igrovykh DApp-akh, no uvy, etogo opyat' nedostatochno. Teper' na rezultat mozhet vliyat' ne tol'ko mayner, no i lyuboy uchastnik protokola. Kontrol'irovat' samo znachenie po-prezhnemu mozhno, s men'shey stepen'yu variativnosti i za den'gi, no, kak i v sluchaye s maynerom, esli rezul'taty rozegrysha tsenee, chem plata za uchastie v protokole PVRB, to random-producer (RP) mozhet reshat', delat' li reveal i po-prezhnemu mozhet vybiraet' iz minimum dvukh variantov randoma.
Zato poyavilas' vozmozhnost' nakazyvat' tekh, kto delaet commit i ne delaet reveal, i eta skhema yeshchyo prigoitsya. Yeya prostota yavlyaetsya seryoznym preimushchestvom — boleye seryoznye protokoly trebuyut mnogo boleye moshchnykh vychisleniy.

PVRB i determinirovannye podpisy.

Obstaja še en način, kako prisiliti RP, da zagotovi psevdonaključne številke, na katere ne more vplivati, če mu je na voljo "predhodnik" — to je deterministični podpis. Tak podpis je na primer RSA in ni ECS. Če ima RP par ključev: RSA in ECC, in podpiše neko vrednost s svojim zasebnim ključem, bo v primeru RSA prejel ENO IN SAMO podpis, medtem ko lahko v primeru ECS ustvari nešteto različnih veljavnih podpisov. To se dogaja, ker se pri ustvarjanju ECS podpisa uporablja naključna številka, ki jo izbere podpisnik, in ta lahko izbira poljubno, kar podpisniku omogoča, da izbere enega od več podpisov. V primeru RSA: "eno vhodno vrednost" + "en par ključev" = "ena podpis". Napovedati, kakšen bo podpis drugega RP, ni mogoče, zato se PVRB z determinističnimi podpisi lahko organizira z združevanjem RSA podpisov več udeležencev, ki so podpisali isto vrednost. Na primer — prejšnja naključna številka. V takšni shemi se prihrani precej sredstev, saj so podpisi hkrati tudi potrditev pravilnega vedenja po protokolu in vir naključnosti.

Kljub temu pa je shema, celo z determinističnimi podpisi, še vedno ranljiva na težavo "zadnjega akterja". Zadnji udeleženec še vedno lahko odloča, ali bo objavil svoj podpis ali ne, s tem pa nadzoruje rezultat. Schemo je mogoče izboljšati, dodati hashe blokov, izvajati kroge, da vnaprej ne bi bilo mogoče napovedati rezultata, vendar vse te tehnike, tudi ob upoštevanju številnih izboljšav, še vedno puščajo nerazrešeno težavo vpliva enega udeleženca na kolektivni rezultat v nezaupljivem okolju in lahko delujejo le v pogojih gospodarskih in časovnih omejitev. Poleg tega je velikost ključev RSA (1024 in 2048 bitov) precej velika, velikost za transakcije blockchain je izredno pomemben parameter. Očitno preprosta rešitev ne bo delovala, gremo naprej.

V kriptografiji obstajajo sheme, ki omogočajo omrežju, da se dogovori o enem in samo enem PVRB-ju, pri čemer so te sheme odporne na morebitne zlonamerne akcije dela udeležencev. Eden od koristnih protokolov, ki jih je vredno spoznati, je shema deljenja skrivnosti Shamirja. Namenjena je delitvi skrivnosti (na primer tajnega ključa) na več delov, ki jih prejme N udeležencev. Skrivnost se razdeli tako, da za njeno obnovitev zadostuje M delov od N, pri čemer so lahko to kakršni koli M deli. Če to ponazorimo, udeleženci izmenjujejo točke na grafu neznane funkcije, in po prejemu M točk lahko obnovijo celotno funkcijo.
Dober opis je podan v wiki in za eksperimentiranje z njim je praktično koristno, da v mislih predvajate protokol na demo strani.

Če bi bila shema FSSS (Fiat-Shamir Secret Sharing) uporabna v svoji čisti obliki — bi bil to neuničljiv PVRB. V najpreprostejši različici lahko protokol izgleda takole:

Vsak udeleženec generira svoj lastni naključni podatek in deli deleže z ostalimi udeleženci.
Vsak udeleženec razkrije svoj del skrivnosti ostalih udeležencev.
Če je udeleženec zbral več M delov, se lahko izračuna število tega udeleženca, ki bo edinstveno, ne glede na nabor razkrivenih udeležencev.
Kombinacija razkritih naključnih podatkov in je iskani PVRB.

Tukaj posamezen udeleženec ne vpliva na rezultate protokola, razen v primerih, ko je dosego praga razkritja naključnega podatka odvisno le od njega. Zato ta protokol, ob voljo potrebne količine sodelujočih in dostopnih RP, deluje tako, da izpolnjuje zahteve glede kriptografske odpornosti in je odporen na problem "zadnjega akterja".

To bi lahko bil idealen primer, ta shema PVRB na podlagi deljenja skrivnosti FSSS je opisana na primer v tole članku. Vendar, kot je bilo omenjeno zgoraj, se pri poskusu njene neposredne uporabe v blockchain-u pojavijo tehnične omejitve. Tukaj je primer testne izvedbe protokola v pametni pogodbi EOS in njen najpomembnejši del — preverjanje objavljenega deleža udeleženca: kodoIz kode je razvidno, da validacija dokaza zahteva več skalarnih množenj, pri čemer so številke zelo velike. Pri tem je treba razumeti, da se v blokchainih preverjanje zgodi v trenutku, ko block-producer obdeluje transakcijo, in vsak udeleženec mora zlahka preveriti pravilnost protokola, zato so zahteve glede hitrosti funkcije preverjanja zelo resne. V tej različici se je izkazalo, da je rešitev neobvladljiva, saj preverjanje ni ustrezalo omejitvi transakcije (0,5 sekunde).

Učinkovitost preverjanja je ena najpomembnejših zahtev za uporabo pravzaprav kateregakoli naprednega kriptografskega sistema v blokchainu. Ustvarjanje dokazov, priprava sporočil — te postopke lahko prenesemo izven verige in jih izvajamo na visokozmogljivih računalnikih, vendar preverjanje ne bo mogoče obiti — to je še en pomemben zahtev za PVRB.

PVRB in pragovne podpise

Ko smo se spoznali s shemo deljenja skrivnosti, smo odprli cel razred protokolov, povezanih s ključnimi besedami "prag". Ko za razkritje nekaterih informacij sodeluje M poštenih udeležencev iz N, in nabor poštenih udeležencev je lahko poljuben podmnožek N, govorimo o "prag" shemah. Te sheme omogočajo rešitev problema "zadnjega akterja", zdaj, če napadalec ne razkrije svojega dela skrivnosti, to stori drug, pošten udeleženec. Te sheme omogočajo dogovor o enem in edinem vrednotenju, tudi ob sabotage protokola s strani nekaterih udeležencev.

Kombinacija determinističnih podpisov in pragovnih shem je omogočila razvoj zelo priročne in obetavne sheme za izvajanje PVRB — to so deterministični pragovni podpisi. Tukaj članek o različnih aplikacijah pragovnih podpisov, tukaj pa je še ena dobra longread od Dash.

V zadnjem članku so opisani BLS podpisi (BLS pomeni Boneh-Lynn-Shacham, tukaj je članek ), ki ima zelo pomembno in izjemno praktično kakovost za programerje – javni, tajni, javni ključi in podpisi BLS se lahko kombinirajo med seboj z enostavnimi matematičnimi operacijami, pri čemer njihove kombinacije ostanejo veljavni ključi in podpisi, kar omogoča enostavno ageracijo več podpisov v enega in več javnih ključev v enega. Imajo tudi determinističnost in pri enakih vhodnih podatkih dajo enak rezultat. Zaradi te lastnosti so kombinacije BLS podpisov same veljavni ključi, kar omogoča uresničitev različice, kjer M od N udeležencev ustvari en sam podpis, ki je determiniran, javno preverljiv in nepredvidljiv, dokler ga ne razkrije M-ti udeleženec.

V shemi z threshold BLS podpisom vsak udeleženec podpiše s pomočjo BLS nekaj (na primer prejšnji naključni številki), skupni threshold-podpis pa je iskani naključni številki. Kriptografske lastnosti BLS podpisov izpolnjujejo zahteve glede kakovosti naključnosti, threshold del ščiti pred “zadnjim izvajalcem”, edinstvena kombinabilnost ključev pa omogoča izvajanje še mnogih zanimivih algoritmov, ki omogočajo, na primer, učinkovito ageracijo sporočil protokola.

Torej, če gradite PVRB v svojem blockchainu, boste z veliko verjetnostjo prišli do sheme BLS threshold podpisov, ki jo že uporabljajo nekateri projekti. Na primer, DFinity (ovde benchmark, ki izvaja shemo, ter tukaj primer izvajanja verifiable secret sharing), ali Keep.network (tu je njihov random beacon yellowpaper, a evo primer pametne pogodbe, ki upravlja protokol).

Implementacija PVRB

Žal, še vedno ne vidimo dokončnega, v blokchainih PVRB realiziranega protokola, ki bi dokazal svojo varnost in odpornost. Kljub temu, da so protokoli pripravljeni, je tehnično težko uporabiti jih za obstoječe rešitve. Za centralizirane sisteme PVRB nima smisla, decentralizirani sistemi pa so strogo omejeni v vseh računalniških virih: CPU, pomnilnik, shranjevanje, I/O. Načrtovanje PVRB je združevanje različnih protokolov, da bi oblikovali tisto, kar ustreza vsem zahtevam vsaj za kakšen življenjsko sposoben blokchain. Ena protokol učinkoviteje izračunava, vendar zahteva več sporočil med RP, medtem ko drugi zahteva izjemno malo sporočil, vendar lahko ustvarjanje proof-a predstavlja nalogo, ki traja desetine minut, morda celo ur.

Naštel bom dejavnike, ki jih boste morali upoštevati pri izbiri kakovostnega PVRB:

Kryptografska odpornost. Vaš PVRB mora biti strogo unbiasable, brez možnosti nadzora nad enim bitom. V nekaterih shemama to ni tako, zato pokličite kriptografa.
Težava 'zadnjega igralca'. Vaš PVRB mora biti odporen na napade, kjer napadalec, ki nadzira enega ali več RP, lahko izbere eno od dveh možnosti rezultata.
Težava sabotaže protokola. Vaš PVRB mora biti odporen na napade, kjer napadalec, ki nadzira enega ali več RP, odloča, ali bo randomizacija izvedena ali ne ter lahko z gotovostjo ali z določeno verjetnostjo vpliva na to.
Težava števila sporočil. Vaši RP morajo poslati v blokchain najmanj sporočil in se izogibati sinhronim dejanjem, kot so situacije 'poslal sem določene informacije, čakam na odgovor od določenega udeleženca'. V p2p omrežjih, še posebej geografsko razpršenih, ne gre pričakovati hitrega odgovora.
Težava računalniške zapletenosti. Verifikacija katerega koli koraka PVRB on-chain mora biti izjemno enostavna, saj jo izvajajo vsi polni odjemalci omrežja. Če se izvedba dela s pomočjo pametnih pogodb, so zahteve glede hitrosti zelo stroge.
Težava dostopnosti in življenjske sposobnosti. Vaš PVRB mora stremeti k temu, da je odporen na situacije, ko del omrežja postane nedostopen za določeno obdobje in del RP preprosto preneha delovati.
Težava zaupanja vredne nastavitve in začetne distribucije ključev. Če vaš PVRB uporablja primarno nastavitev protokola, je to posebna in resna zgodba. Tukaj je primer. Če morajo udeleženci pred začetkom protokola sporočiti drug drugemu svoje ključe — to je prav tako težava, če se sestava udeležencev spreminja
Problemi razvoja. Prisotnost knjižnic v potrebnih jezikih, njihova varnost in učinkovitost, javnost, kompleksni testi itd.

Na primer, pri threshold BLS podpisih je resna težava — pred začetkom dela se morajo udeleženci obvezno izmenjati ključe, organizirati skupino, v kateri bo delovala threshold. To pomeni, da bo potrebno počakati na vsaj en krog izmenjave v decentralizirani mreži, in če upoštevamo, da je generirani naključni element, na primer, potreben v igrah, praktično v realnem času, to pomeni, da je sabotiranje protokola možno v tej fazi, in prednosti threshold sheme se izgubijo. Ta težava je že enostavnejša od prejšnjih, vendar še vedno zahteva razvoj posebne procedure za oblikovanje threshold skupin, ki jo bo potrebno zaščititi ekonomsko, preko depozitov in odvzema sredstev (slashing) od udeležencev, ki ne sledijo protokolu. Poleg tega, verifikacija BLS z sprejemljivo stopnjo varnosti preprosto ni mogoča, na primer, v standardni transakciji EOS ali Ethereum — preprosto ni dovolj časa za verifikacijo. Koda pogodb — to je WebAssembly ali EVM, ki jo izvršuje virtualna naprava. Kriptografske funkcije niso natančno implementirane (še), in delujejo desetkrat počasneje od običajnih kriptografskih knjižnic. Mnogi protokoli ne ustrezajo zahtevam samo na podlagi količine ključev, na primer 1024 in 2048 bit za RSA, kar je 4-8 krat več kot standardni podpis transakcije v Bitcoin in Ethereum.

Igra tudi vlogo prisotnost realizacij v različnih programskih jezikih — katerih je malo, zlasti za nove protokole. Možnost integracije v konsenz zahteva, da se protokol napiše v jeziku platforme, zato bo treba iskati kodo v Go za geth, v Rust za Parity, v C++ za EOS. Kodo v JavaScriptu bo treba poiskati pri vsem, in ker JavaScript in kriptografija nista prav zares dobri prijatelji, bo pomagal WebAssembly, ki že danes resnično kandidira za vlogo naslednjega pomembnega internetnega standarda.

Zaključek

Upam, da je v prejšnjem članku Uspeo sam vas uveriti da je generisanje nasumičnih brojeva na blockchainu od kritične važnosti za mnoge aspekte života decentralizovanih mreža, a ovim člankom sam pokazao da je ovaj zadatak izuzetno ambiciozan i složen, ali već postoje dobra rešenja. U suštini, konačan dizajn protokola moguć je tek nakon obimnih testova koji uzimaju u obzir sve aspekte, od postavljanja do emulacije grešaka, tako da teško da ćete pronaći gotove recepte u whitepaper-ima timova i u člancima, a ni mi se u naredne godinu-dve sigurno nećemo usuditi da kažemo „radite ovako, to je sigurno ispravno“.

Za sada, za naš PVRB u razvijajućem blockchainu Haya, zaustavili smo se na primeni threshold BLS potpisa, planiramo da implementiramo PVRB na nivou konsenzusa, jer verifikacija u pametnim ugovorima sa prihvatljivim nivoom sigurnosti još uvek nije moguća. Moguće je da ćemo koristiti odmah dve sheme: prvo skupu tajnu deljenja za kreiranje dugoročnog random_seed, a zatim je koristiti kao osnovu za visoko frekventno generisanje nasumičnih brojeva pomoću determinističkih threshold BLS potpisa; možda ćemo se ograničiti samo na jednu od shema. Teško je unapred reći kakav će biti protokol, nažalost, ali je ohrabrujuće to da, kao i u nauci, u inženjerskim zadacima negativan rezultat je takođe rezultat, a svaki novi pokušaj rešavanja problema predstavlja još jedan korak za sve koji se bave ovim izazovima. Da bismo ispunili zahteve sa strane biznisa, rešavamo konkretan praktičan problem - obezbeđivanje igračkih aplikacija pouzdanim izvorom entropije, zbog čega moramo obratiti pažnju i na sam blockchain, posebno na pitanja finalnosti lanca i upravljanja mrežom.

I iako trenutno ne vidimo u blockchainima dokazano otpornog PVRB koji je korišćen dovoljno dugo da bi prošao testove pravih aplikacija, višestrukih revizija, opterećenja i naravno, pravih napada, broj mogućih puteva potvrđuje da rešenje postoji, i neki od ovih algoritama će na kraju rešiti problem. Rado ćemo deliti rezultate i zahvaljujemo se drugim timovima koji se takođe bave ovim pitanjem za članke i kod koji omogućavaju inženjerima da ne ponavljaju iste greške.

Zato, ko srečate programerja, ki oblikuje decentralizirano naključje, bodite previdni in skrbni, po potrebi mu nudite psihološko pomoč 🙂

Izvor: habr.com