Uvod

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

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

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

Два способа внедрения PVRB

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

Neodvisna pogodba

V tej različici PVRB predstavlja pametno pogodbo, ki sprejema transakcije random-producentov (v nadaljevanju RP), jih obdeluje, kombinira rezultate in tako doseže določeno vrednost, ki jo lahko pridobi vsak uporabnik iz te pogodbe. Ta vrednost morda ni neposredno shranjena v pogodbi, temveč je predstavljena le z podatki, iz katerih je mogoče deterministično pridobiti eno samo vrednost končnega naključja. V tej shemi so RP uporabniki blockchaina in v proces generiranja lahko vključite koga koli.

Različica z neodvisno pogodbo je dobra:

prenosljivostjo (pogodbe je mogoče prenašati iz blockchaina v blockchain)
enostavnostjo izvedbe in testiranja (pogodbe je enostavno pisati in testirati)
praktičnostjo pri realizaciji ekonomskih shem (enostavno je ustvariti svoj token, katerega logika služi namenom PVRB)
možnostjo zagon v že delujočih blockchainih

Ima pa tudi pomanjkljivosti:

močne omejitve virov pri izračunih, obsegu transakcij in shranjevanju (preprosto povedano cpu/mem/io)
omejitve na operacije znotraj pogodbe (ne vse ukaze so na voljo, težko je povezati zunanje knjižnice)
nemogoče je organizirati izmenjavo sporočil hitreje, kot se transakcije vključujejo v blockchain

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 veliko interakcij.

Integrirano soglasje

V tej različici je PVRB implementiran v kodi blockchain vozlišča, vgrajen ali deluje vzporedno izmenjavi sporočil med vozlišči blockchaina. Rezultati protokola se zapisujejo neposredno v ustvarjene bloke, sporočila protokola pa se pošiljajo po p2p omrežju med vozlišči. Ker protokol generira številke, ki jih je treba zapisati v bloke, mora omrežje doseči konsenz o njih. To pomeni, da morajo biti sporočila PVRB, tako kot transakcije, veljavna s strani vozlišč in vključena v bloke, da lahko vsak udeleženec omrežja veljavnost protokola PVRB preveri. To nas avtomatsko privede do očitne rešitve — če se omrežje dogovori o konsenzu glede bloka in transakcij v njem, mora biti PVRB del konsenza, ne pa ločen protokol. V nasprotnem primeru obstaja možnost, da je blok veljaven z vidika konsenza, vendar protokol PVRB ni bil spoštovan, in iz vidika PVRB blok ne more biti sprejet. Tako, če se izbere možnost 'konsenz-integriran', PVRB postane pomemben del konsenza.

Pri opisovanju implementacij PVRB na ravni konsenza v omrežju nikakor ne smemo spregledati vprašanj končnosti. Končnost je mehanizem, ki se uporablja v determinističnih konsenzih, ki fiksira blok (in verigo, ki ga vodi), ki je končen in nikoli ne bo zavrnjen, tudi če se pojavi paralelni fork. Na primer, v Bitcoinu tak mehanizem ne obstaja — če se objavi veriga večje zapletenosti, bo nadomestila katero koli manj zapleteno, ne glede na dolžino verig. V EOS-u, na primer, so končni tako imenovani Zadnji Nepovratni Bloki, ki se pojavijo povprečno vsakih 432 blokov (12*21 + 12*15, pre-vote + pre-commit). Ta postopek v bistvu pomeni čakanje na 2/3 podpisov proizvajalcev blokov (naprej BP). Ko se pojavijo forki, ki so starejši od zadnjega LIB, jih preprosto zavržejo. Ta mehanizem zagotavlja, da je transakcija vključena v blockchain in se nikoli ne bo umaknila, ne glede na vire, ki jih ima napadalec. Tudi končni bloki so bloki, ki jih podpiše 2/3 BP v Hyperledgeru, Tendermintu in drugih pBFT-podobnih konsenzih. Prav tako je smiselno protokol za zagotavljanje končnosti zasnovati kot nadgradnjo nad konsenzom, saj lahko deluje asinhrono s proizvodnjo in objavo blokov. članek o finalnosti v Ethereum.

Finalnost je izjemno pomembna za uporabnike, ki so brez nje lahko žrtve napada 'double spend', ko BP 'zadrži' bloke in jih objavi po tem, ko je omrežje 'videlo' dobro transakcijo. Če ni finalnosti, objavljen fork zamenja blok z 'dobro' transakcijo z drugim iz 'slabega' forka, kjer so ta sredstva prenesena na naslov napadalca. V primeru PVRB so zahteve po finalnosti še strožje, saj gradnja forkov za PVRB pomeni možnost, da napadalec pripravi več različic naključnih izidov z namenom objave najbolj dobičkonosnega zanj in omeji čas, v katerem lahko napad izvede — to je dobro rešitev.

Zato je najboljša možnost združiti PVRB in finalnost v en protokol — takrat finaliziran blok = finaliziran naključen izid, kar je točno to, kar je bilo treba doseči. Zdaj bodo igralci dobili zagotovljen naključni izid v N sekundah in lahko bodo prepričani, da ga ni mogoče razveljaviti ali ponovno odigrati.

Možnost z integracijo konsenza je dobra:

z možnostjo asinhrone izvedbe v zvezi s proizvodnjo blokov — bloki se proizvajajo običajno, vendar hkrati lahko deluje protokol PVRB, ki proizvaja naključne izide ne pri vsakem bloku
z možnostjo implementacije tudi zahtevne kriptografije, brez omejitev, ki jih nalagajo pametne pogodbe
z možnostjo organizacije sporočanja 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žave pri testiranju in razvoju — potrebno bo emulirati omrežne napake, izginjajoča vozlišča, hard forke omrežja
napake v izvedbi zahtevajo hard fork omrežja

Oba načina implementacije PVRB imata pravico do obstoja, vendar je izvedba na pametnih pogodbah v sodobnih blockchainih še vedno precej omejena glede na računalniške vire, in vsak prehod na resno kriptografijo je pogosto preprosto nemogoč. In resna kriptografija bo potrebna, kot bo prikazano kasneje. Kljub temu ta težava nosi očitno začasen značaj, 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 message exchange, does not do this for free. Any decentralized protocol must consider the possibility of a Sybil attack; any action can be coordinated by numerous accounts, so when designing, one must take into account the attackers' capabilities to create an arbitrary number of participants in the protocol acting in collusion.

PVRB and block variables.

I wasn't lying when I said that good PVRB, verified by numerous gambling applications, has not yet been implemented in blockchains. So where did such a number of gambling applications in Ethereum and EOS come from? This surprises me just as much as it surprises you; where did so many 'sturdy' randoms come from in a completely deterministic environment?

The favorite way to get randomness in the blockchain is to take some 'unpredictable' information from the block and use it to generate randomness—simply by hashing one or more values. A good article about the problems of such schemes. ovdeYou can take any of the 'unpredictable' values in the block, such as the block hash, transaction count, network difficulty, and other unknown values in advance. Then, hash them—one or several—and, ideally, you should get genuine randomness. You could even add in the whitepaper 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, which I remind you of from the previous article:

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

V tem primeru je spoštovana samo zahteva 1, medtem ko 2 ni izpolnjena. S hashiranjem nepredvidljivih vrednosti iz bloka bomo dobili enakomerno porazdelitev in dobre naključne vrednosti. A BP ima vsaj možnost "objaviti blok ali ne". Tako lahko BP izbere med DVAjima možnostma naključja: "svojim" in tistim, ki ga bo ustvaril nekdo drug. BP lahko vnaprej "pogleda", kaj se bo zgodilo, če objavi blok, in preprosto sprejme odločitev, ali to stori ali ne. Tako lahko, na primer, pri igri "par-nepar" ali "rdeča/črna" v ruleti objavi blok le, če vidi zmago. To prav tako onesposobi strategijo uporabe, na primer, hasha bloka "iz prihodnosti". V tem primeru govorimo, da "bo uporabljen naključni podatek, ki ga dobimo z hashiranjem trenutnih podatkov in hasha prihodnjega bloka na višini, na primer, N + 42, kjer je N trenutna višina bloka. To nekoliko okrepi shemo, vendar še vedno omogoča BP, tudi v prihodnosti, da izbere, ali naj zadrži blok ali ga objavi.

Softver BP v tem primeru postane nekoliko bolj zapleten, vendar ne preveč. Preprosto med potrjevanjem in vključitvijo transakcije v blok poteka hiter pregled, ali bo zmaga, in morda izbira enega od parametrov transakcije, da pridobi visoko verjetnost zmage. Hkrati je skoraj nemogoče ujeti pametnega BP pri takšnih manipulacijah, saj je mogoče vsakokrat uporabiti nove naslove in z majhnimi zmagami ne vzbuditi suma.

Tako, načini, ki uporabljajo informacije iz bloka, niso primerni za univerzalno implementacijo PVRB. V omejenem različici, z omejitvami glede velikosti stav, omejitvami števila igralcev in/ali KYC registracijo (da se prepreči enemu igralcu, da uporablja več naslovov), lahko te sheme delujejo za manjše igre, vendar nič več.

PVRB in commit-reveal.

No, hvala hashiranju in vsaj relativni nepredvidljivosti hasha bloka ter drugih spremenljivk. Če rešimo problem predhodnega izvajanja s strani rudarjev, bi lahko dobili nekaj bolj uporabnega. Dodajmo v to shemo uporabnike — naj tudi vplivajo na naključje: vsak zaposleni v tehnični podpori vam bo povedal, da so najbolj naključni v IT sistemih ravnanja uporabnikov 🙂

Naivna shema, kjer uporabniki preprosto pošiljajo naključna števila, rezultati pa se izračunavajo kot na primer hash od njihove vsote, ni primerna. V tem primeru lahko zadnji igralec, ki igra, izbira svoje naključje in nadzira, kakšen rezultat bo. Zato se uporablja zelo razširjen vzorec commit-reveal. Udeleženci najprej pošljejo hashe svojih naključij (commit-e), nato pa razkrijejo svoja naključja (reveal-e). Faza “reveal” se začne šele potem, ko so zbrani potrebni commit-i, zato lahko udeleženci pošljejo točno tisto naključje, hash katerega so poslali prej. Zdaj vse to povežemo s parametri bloka, pri čemer je najbolje, da vzamemo tistega iz prihodnosti (naključje bomo izvedeli šele v enem od prihodnjih blokov), in voila — naključje je pripravljeno! Zdaj ima vsak igralec vpliv na končno naključje in lahko “premaga” zlonamernega BP, tako da njegovo naključje prekrije s svojim, prej neznanim, naključjem... Lahko dodamo tudi zaščito pred sabotažo protokola tako, da ne razkrijemo na stopnji razkritja — preprosto zahtevamo, da se pri commit-u priloži k transakciji neka vsota — zavarovalni depozit, ki se vrne šele pri postopku razkritja. V tem primeru bo nehvaležno delati commit in ne razkriti.

To je bila dobra poskus, in takšne sheme obstajajo tudi v igrah DApp-ih, ampak žal, to še vedno ni dovolj. Zdaj na rezultat lahko vpliva ne le rudar, temveč tudi kateri koli udeleženec protokola. Kontrolirati samo vrednost je še vedno mogoče, z manjšo stopnjo variabilnosti in za denar, vendar pa, kot pri rudarju, če so rezultati žrebanja vrednejši od cene za sodelovanje v protokolu PVRB, lahko random-producer (RP) odloči, ali bo razkril, in še vedno lahko izbira med najmanj dvema različnima naključjema.
Zato je nastala možnost kaznovanja tistih, ki naredijo commit in ne razkrijejo, in ta shema bo še uporabna. Njena preprostost je resna prednost — bolj zapleteni protokoli zahtevajo veliko bolj močnejše računalniške zmogljivosti.

PVRB in deterministični podpisi.

Obstaja še en način, kako prisiliti RP, da zagotovi psevdonaključne številke, nad katerimi ne more vplivati, če mu je podano "predlogo" — to je deterministični podpis. Tak podpis je na primer RSA, ni pa ECS. Če ima RP par ključev: RSA in ECC, in s svojim zasebnim ključem podpiše neko vrednost, potem v primeru RSA dobi EN samo EN podpis, v primeru ECS pa lahko ustvari poljubno število različnih veljavnih podpisov. To se dogaja, ker pri ustvarjanju ECS podpisa uporabljamo naključno število, ki ga izbere podpisnik, in ga lahko izbere poljubno, kar daje podpisniku možnost izbrati enega od več podpisov. V primeru RSA: "ena vhodna vrednost" + "en par ključev" = "en podpis". Napovedati, kakšen podpis bo imel drugi RP, ne moremo, zato je PVRB z determinističnimi podpisi mogoče organizirati z združevanjem RSA podpisov več udeležencev, ki so podpisali isto vrednost. Na primer — prejšnje naključno število. V takšni shemi se prihrani precej virov, saj so podpisi hkrati tudi potrditev pravilnega ravnanja po protokolu in vir naključnosti.

Kljub temu pa je shema, tudi z determinističnimi podpisi, še vedno ranljiva na problem "zadnjega igralca". Zadnji udeleženec še vedno lahko odloči, ali bo objavil svoj podpis ali ne, s čimer nadzira rezultat. Možno je izboljšati shemo, dodati hashe blokov, izvajati kroge, da bi vnaprej rezultat težje napovedali, vendar vse te tehnike, tudi ob upoštevanju mnogih izboljšav, vseeno puščajo nerešeno vprašanje vpliva enega udeleženca na skupni 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, medtem ko je velikost za blockchain transakcije izredno pomemben parameter. Očitno problema ne bo mogoče preprosto rešiti, gremo naprej.

V kriptografiji obstajajo sheme, ki omogočajo, da se omrežje dogovori o enem in edinem PVRB, pri čemer so te sheme odporne na zlonamerne ukrepe dela udeležencev. Eden uporabnih protokolov, s katerim se je smiselno seznaniti, je shema deljenja skrivnosti Shamirja. Ta služi za delitev skrivnosti (na primer skrivnega ključa) na več delov, ki se razdelijo N udeležencem. Skrivnost se razdeli tako, da za njeno obnovo zadostujejo M delov od N, pri čemer so lahko to poljubi M deli. Če povzamemo, imajo udeleženci graf neznane funkcije, in si izmenjujejo točke na grafu, po prejemu M točk pa se lahko celotna funkcija obnovi.
Dober opis je podan v wiki in igranje z njim praktično, da bi protokol razumeli, je koristno na demo stran.

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

Vsak udeleženec generira svojega random in deli deleže z ostalimi udeleženci.
Vsak udeleženec razkrije svoje deleže skrivnosti ostalih udeležencev.
Če je za udeleženca zbranih več M deležev, je možno izračunati število tega udeleženca, ki bo edinstveno, ne glede na skupino razkritih udeležencev.
Kombinacija razkritih random-ov je iskan PVRB.

Tukaj posamezni udeleženec ne vpliva več na rezultate protokola, razen v primerih, ko od njega odvisno doseganje praga razkritja. Zato ta protokol, ob prisotnosti potrebne deleža delujočih po protokolu in dostopnih RP, deluje, izpolnjuje zahteve po kriptografski odpornosti in ostaja odporen na težavo 'zadnjega igralca'.

To bi bila lahko idealna možnost, ta shema PVRB na osnovi deljenja skrivnosti Fiata-Shamirja je opisana, na primer, v tole članku. Vendar, kot je bilo že omenjeno, se pri poskusu njene neposredne uporabe v blockchain-u pojavijo tehnične omejitve. Tukaj je primer testne implementacije protokola v pametni pogodbi EOS in njen najpomembnejši del — preverjanje objavljenega deleža udeleženca: kodoZ kode je razvidno, da validacija proof-a zahteva več skalarnim množenjem, pri čemer so števila zelo velika. Ob tem je treba razumeti, da se v blockchainih verify zgodi v trenutku, ko block-producer obdela transakcijo, in vsak udeleženec mora zlahka preveriti pravilnost protokola, zato so zahteve po hitrosti funkcije verify zelo stroge. V tej različici se je izkazala za neuporabno, ker verifikacija ni ustrezala omejitvi na transakcijo (0,5 sekunde).

Učinkovitost verifikacije je eden od najpomembnejših zahtev za uporabo pravzaprav vseh naprednih kriptografskih shem v blockchainu. Ustvarjanje proof-ov, priprava sporočil — te postopke je mogoče izvesti off-chain in jih izvajati na visokozmogljivih računalnikih, toda verifikacije ne bo mogoče obiti — to je še en pomemben zahtevek za PVRB.

PVRB in threshold podpisi

S spoznanjem sheme secret sharing smo odprli cel razred protokolov, povezanih z ključnimi besedami „threshold“. Ko je za razkritje neke informacije potrebna udeležba M poštenih udeležencev iz N, in skupina poštenih udeležencev je lahko poljubna podmnožica N, govorimo o „threshold“ shemah. Te sheme omogočajo reševanje problema „zadnjega akterja“, zdaj, če napadalec ne odkrije svojega dela skrivnosti, bo to storil drug, pošten udeleženec. Te sheme omogočajo dogovor o eni in samo eni vrednosti, tudi ob sabotiranju protokola s strani nekaterih udeležencev.

Združitev determinističnih podpisov in threshold-shem je omogočila razvoj zelo priročne in obetavne sheme za izvedbo PVRB — to so deterministični threshold-podpisi. Tukaj članek o različnih uporabljenih threshold-podpisih, tukaj pa je še ena dobra longread od Dash.

V zadnjem članku so opisani BLS podpisi (BLS se razlaga kot Boneh-Lynn-Shacham, tukaj je Članek ), ki ima zelo pomembno in izjemno priročno lastnost za programerje — javni, skrivni, javni ključi in BLS podpisi se lahko med seboj kombinirajo s pomočjo preprostih matematičnih operacij, pri tem pa ostanejo veljavni ključi in podpisi, kar omogoča enostavno agregacijo številnih podpisov v enega in mnogih javnih ključev v enega. Imajo tudi determinističnost in na istih vhodnih podatkih dajejo enak rezultat. Zaradi te lastnosti so kombinacije BLS podpisov same veljavni ključi, kar omogoča izvedbo scenarija, v katerem M od N udeležencev proizvede eno samo podpis, ki je deterministična, javno preverljiva in nepričakovana, dokler je ne razkrije M-ti udeleženec.

V shemi z threshold BLS podpisi vsak udeleženec podpiše s pomočjo BLS nekaj (na primer prejšnjo naključnost), skupni threshold-podpis pa je želeno naključje. Kriptografske lastnosti BLS podpisov zadostujejo zahtevam glede kakovosti naključja, threshold-del pa ščiti pred "zadnjim igralcem", medtem ko edinstvena kombinabilnost ključev omogoča še številne zanimive algoritme, ki omogočajo učinkovito agregacijo sporočil protokola.

Torej, če gradite PVRB v svojem blockchainu, boste z veliko verjetnostjo prišli do sheme BLS threshold podpisov, ki jo že uporablja več projektov. Na primer, DFinity (ovde benchmark, ki implementira shemo, in tukaj primer implementacije preverljivega tajnega deljenja), ali Keep.network (tukaj je njihov random beacon yellowpaper, a evo primer pametna pogodba, ki upravlja protokol).

Implementacija PVRB

Nažalost, do danas još ne vidimo gotov, implementiran protokol PVRB u blokčejnovima koji je dokazao svoju sigurnost i otpornost. Iako su protokoli sami po sebi spremni, tehnički ih primeniti na postojeće rešenja nije jednostavno. PVRB nema smisla za centralizovane sisteme, dok su decentralizovani strogo ograničeni u svim računalnim resursima: CPU, memorija, skladište, I/O. Dizajniranje PVRB-a podrazumeva kombinovanje različitih protokola kako bi se formirao sistem koji će ispunjavati zahteve barem za neki životno sposoban blokčejn. Jedan protokol efikasnije obračunava, ali zahteva više poruka između RP, dok drugi zahteva izuzetno malo poruka, ali stvaranje proof-a može potrajati desetine minuta, pa i sati.

Nabrojaću faktore koje ćete morati uzeti u obzir prilikom odabira kvalitetnog PVRB-a:

Kriptografska otpornost. Vaš PVRB mora biti strogo nepristrasan, bez mogućnosti kontrole jedinog bita. U nekim shemama to nije slučaj, zato pozovite kriptografa.
Problem “poslednjeg aktera”. Vaš PVRB treba biti otporan na napade kada napadač, koji kontroliše jednog ili više RP, može birati između dve opcije rezultata.
Problem sabotaže protokola. Vaš PVRB treba biti otporan na napade kada napadač, koji kontroliše jednog ili više RP, odlučuje da li će biti nasumično ili ne, i može garantovano, ili uz zadatu verovatnoću uticati na to.
Problem količine poruka. Vaši RP trebaju slati minimalan broj poruka u blokčejn i maksimalno izbegavati sinhrone radnje tipa ‘poslao sam neku informaciju, čekam odgovor od određenog učesnika’. U p2p mrežama, posebno geografski raspršenim, ne treba očekivati brzi odgovor.
Problem računarske složenosti. Verifikacija bilo koje faze PVRB-a on-chain treba biti veoma jednostavna, jer je obavljaju svi puni klijenti mreže. Ako se implementacija vrši putem pametnog ugovora, zahtevi za brzinom su veoma strogi.
Problem dostupnosti i postojanosti. Vaš PVRB treba težiti tome da bude otporan na situacije kada deo mreže postane nedostupan na određeno vreme i deo RP jednostavno prestane sa radom.
Problem pouzdane konfiguracije i inicijalne raspodele ključeva.. Če vaš PVRB uporablja primarno nastavitev protokola, je to ločena velika in resna zgodba. Tukaj je primer. Če morajo udeleženci pred začetkom protokola sporočiti drug drugemu svoje ključe — je to tudi problem, če se sestava udeležencev spreminja
Problemi pri razvoju. Prisotnost knjižnic v potrebnih jezikih, njihova varnost in zmogljivost, javnost, zahtevni testi itd.

Na primer, pri BLS podpisih v pragu obstaja pomemben problem — preden začnejo z delom, morajo udeleženci nujno izmenjati ključe in organizirati skupino, v okviru katere bo deloval prag. To pomeni, da bo najmanj ena izmenjava v decentralizirani mreži morala biti izvedena, in ob upoštevanju, da je generirani naključni podatek, na primer, potreben v igrah skoraj v realnem času, to pomeni, da je sabotiranje protokola možno v tej fazi, kar pomeni, da so prednosti sheme prag bolj ali manj izgubljene. Ta problem je že enostavnejši od prejšnjih, a vseeno zahteva razviti ločeno proceduro oblikovanja pragovnih skupin, ki jo je treba zaščititi ekonomsko, s pomočjo depozitov in odvzemom sredstev (slashing) udeležencem, ki ne spoštujejo protokola. Prav tako verifikacija BLS z dostojnim nivojem varnosti preprosto ne ustreza, na primer, standardni transakciji EOS ali Ethereum — preprosto zmanjkuje časa za verifikacijo. Koda pogodb — je WebAssembly ali EVM, ki teče na virtualni napravi. Kriptografske funkcije niso implementirane nativno (zaenkrat), in delujejo desetkrat počasneje od običajnih kriptografskih knjižnic. Mnogi protokoli preprosto ne ustrezajo zahtevam glede na volumen 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 vlogo tudi prisotnost implementacij v različnih programskih jezikih — katerih ni veliko, še posebej 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. Koda v JavaScriptu bo morala biti iskana s strani vseh, a ker JavaScript in kriptografija nista ravno najboljši prijatelji, bo pomagal WebAssembly, ki zdaj že zagotovo pretenda na vlogo naslednjega pomembnega internetnega standarda.

Zaključek

Upam, da je v prejšnjem članku Uspelo mi je da vas uverim da je generisanje nasumičnih brojeva na blockchainu od suštinskog značaja za mnoge aspekte života decentralizovanih mreža, a ovom članku pokazujem da je taj zadatak izuzetno ambiciozan i složen, ali dobra rešenja već postoje. U suštini, konačni dizajn protokola moguć je tek nakon opsežnih testiranja koja pokrivaju sve aspekte, od postavljanja do emulacije kvarova, tako da verovatno nećete pronaći gotove recepte u whitepaper-ima timova i u člancima, a ni mi se u narednih godinu-dve sigurno nećemo usuditi da pišemo "radite ovako, ovako je sigurno ispravno."

Za sada, za naš PVRB u razvijajućem blockchainu Haya, odlučili smo se za primenu threshold BLS potpisa, planiramo implementaciju PVRB na nivou konsenzusa, jer verifikacija u pametnim ugovorima sa prihvatljivim nivoom sigurnosti trenutno nije moguća. Moguće je da ćemo koristiti dve sheme odjednom: prvo skupu tajnu deljenja za kreiranje dugoročnog random_seed-a, a zatim ćemo ga koristiti kao osnovu za visoko-frekventno generisanje slučajnih brojeva pomoću determinističkih threshold BLS potpisa, moguće da ćemo se ograničiti samo na jednu od shema. Žao mi je što ne mogu unapred reći kakav će biti protokol, ali raduje to da, kao i u nauci, u inženjerskim zadacima negativan rezultat takođe predstavlja rezultat, a svaki novi pokušaj rešavanja problema je još jedan korak ka istraživanju svih koji se bave tim pitanjima. Kako bismo zadovoljili zahteve poslovanja, rešavamo konkretan praktičan problem — obezbeđivanje pouzdane izvora entropije za igre, pa moramo obratiti pažnju i na sam blockchain, posebno na pitanja finalnosti lanca i upravljanja mrežom.

I iako trenutno ne vidimo dokazano otpornu PVRB u blockchainovima, koja bi se koristila dovoljno dugo da prođe testove stvarnih aplikacija, višestrukih revizija, opterećenja, a svakako i stvarnih napada, broj mogućih puteva potvrđuje da rešenje postoji, i neki od tih algorithama će na kraju rešiti problem. Radujemo se deljenju rezultata i zahvaljujemo drugim timovima koji se takođe bave ovim pitanjem za članke i kod koji omogućava inženjerima da ne kroče dva puta na iste grablje.

Tako da, ko srečate programerja, ki oblikuje decentraliziran naključnjak, bodite previdni in skrbni, po potrebi nudite psihološko pomoč 🙂

Izvor: habr.com