Uvod

function getAbsolutelyRandomNumer() {
        return 4; // vraća apsolutno nasumičan broj!
}

Kao u slučaju koncepta apsolutno otpornog šifriranja iz kriptografije, stvarni protokoli “Publicly Verifiable Random Beacon” (dalje PVRB) pokušavaju se što više približiti idealnoj shemi, jer u stvarnim mrežama u čistom obliku ona nije primjenjiva: potrebno je dogovoriti se strogo o jednom bitu, mora biti puno rundi, a sve poruke trebaju biti savršeno brze i uvijek dostavljene. Naravno, u stvarnim mrežama to nije tako. Stoga, prilikom dizajniranja PVRB za određene zadatke u modernim blockchainima, osim nemogućnosti kontrole dobivenog nasumičnog broja i kriptografske otpornosti, pojavljuje se još mnogo čistih arhitektonskih i tehničkih problema.

Sam blockchain predstavlja za PVRB suštinski sredinu za komunikaciju, u kojoj su poruke=transakcije. To omogućava djelomičnu apstrakciju od mrežnih problema, neodgovarajućih poruka, problema posredničkog softvera — sve te rizike preuzima decentralizirana mreža, a njena glavna vrijednost za PVRB je nemogućnost povlačenja ili kvarenja već poslane transakcije — to ne dopušta sudionicima da odustanu od sudjelovanja u protokolu, osim ako nisu proveli uspješan napad na konsenzus. Takva razina sigurnosti je prihvatljiva, stoga PVRB mora biti otporan na dogovore sudionika u istoj mjeri kao što je to i glavna lancu blockchaina. Također, to sugerira da PVRB mora biti dio konsenzusa ako je mreža postigla dogovor oko glavne lančane blokade, neka se dogovori i o jedinom poštenom rezultantnom nasumičnom broju. Ili, PVRB je jednostavno samostalni protokol, implementiran pametnim ugovorom, koji djeluje asinkrono u odnosu na blockchain i blokove. Oba pristupa imaju svoje prednosti i nedostatke, a izbor između njih nije trivijalan.

Dva načina implementacije PVRB

Detaljnije ćemo opisati dva načina implementacije PVRB — standalone verziju koja radi koristeći pametni ugovor neovisno o blockchainu, i consensus-integrated — ugrađenu u protokol, prema kojem se mreža dogovara o lancu blokova i uključivanim transakcijama. U svim slučajevima imat ću na umu popularne blockchain motore: Ethereum, EOS i sve slične njima po načinu smještanja i procesuiranja pametnih ugovora.

Standalone ugovor

U ovoj verziji PVRB predstavlja pametni ugovor koji prihvaća transakcije random-producer-a (u daljnjem tekstu RP), obrađuje ih, kombinira rezultate i, kao rezultat, dolazi do određenog vrijednosti koju može dobiti svaki korisnik iz ovog ugovora. Ova vrijednost ne mora biti pohranjena u ugovoru izravno, već može biti predstavljena samo podacima iz kojih se može deterministički dobiti samo jedna i jedina vrijednost rezultantnog nasumičnog broja. U ovoj shemi RP su korisnici blockchaina, a u procesu generacije može sudjelovati tko god želi.

Standalone-contract opcija je dobra:

prijenosivošću (ugovore možete prenositi iz blockchaina u blockchain)
jednostavnošću implementacije i testiranja (ugovore je lako pisati i testirati)
praktičnošću implementacije ekonomskih shema (lako je izraditi svoj token, čija logika služi ciljevima PVRB)
mogućnošću pokretanja u već postojećim blockchainima

Ima i nedostatke:

snažna ograničenja resursa tijekom izračuna, volume transakcija i storage (jednostavno rečeno cpu/mem/io)
ograničenja na operacije unutar ugovora (nisu sve instrukcije dostupne, teško je povezati vanjske biblioteke)
nemogućnost organiziranja razmjene poruka brže nego što se transakcije uključuju u blockchain

Ova opcija je pogodna za implementaciju PVRB, koji se mora pokrenuti u već postojeće mreži, ne sadrži složenu kriptografiju i ne zahtijeva puno interakcija.

Consensus-integrated

U ovoj verziji, PVRB je implementiran unutar koda blockchain čvora, integriran ili radi paralelno s razmjenom poruka između čvorova blockchaina. Rezultati protokola se bilježe direktno u generiranim blokovima, a poruke protokola se šalju putem P2P mreže između čvorova. Pošto protokol generira brojeve koji trebaju biti zabilježeni u blokovima, mreža mora doći do konsenzusa o njima. To znači da poruke PVRB, kao i transakcije, moraju biti validirane od strane čvorova i uključene u blokove, kako bi svaki sudionik mreže mogao validirati usklađenost s protokolom PVRB. Ovo nas automatski vodi do očiglednog rješenja — ako se mreža dogovara o konsenzusu u vezi s blokovima i transakcijama u njima, PVRB mora biti dio konsenzusa, a ne odvojeni protokol. Inače, može doći do situacije gdje je blok valjan u smislu konsenzusa, ali protokol PVRB nije poštivan, te blok ne može biti prihvaćen s gledišta PVRB. Tako da ako je odabran „consensus-integrated“ variant, PVRB postaje važan deo konsenzusa.

Pri opisivanju implementacija PVRB na razini konsenzusa u mreži, nikako ne smijemo zaobići pitanja finalnosti. Finalnost je mehanizam koji se koristi u determinističkim konsenzusima za fiksiranje bloka (i lanca koji vodi do njega), koji je finalan i nikada neće biti izbačen, čak i ako se pojavi paralelni fork. Na primjer, u Bitcoin-u ovaj mehanizam ne postoji — ako se objavi lanac veće složenosti, on će zamijeniti bilo koju manje složenu, bez obzira na dužinu lanaca. A u EOS-u, finalni su takozvani Last Irreversible Blocks, koji se pojavljuju u prosjeku svaka 432 bloka (12*21 + 12*15, pre-vote + pre-commit). Ovaj proces je suštinski čekanje na 2/3 potpisa od strane proizvođača blokova (dalje BP). Kada se pojave forkovi koji su stariji od posljednjeg LIB-a, oni se jednostavno odbacuju. Ovaj mehanizam omogućava da se garantuje da je transakcija uključena u blockchain i da nikada neće biti povučena, bez obzira na resurse koje napadač ima. Također, finalni blokovi su blokovi potpisani od strane 2/3 BP u Hyperledger, Tendermint i drugim pBFT-based konsenzusima. Također, protokol za osiguranje finalnosti ima smisla raditi kao nadogradnju na konsenzus, jer može raditi asinkrono s proizvodnjom i objavljivanjem blokova. Ovo je dobro članak o konačnosti u Ethereum-u.

Konačnost je izuzetno važna za korisnike, koji bez nje mogu postati žrtve napada "double spend", kada BP "zadržava" blokove i objavljuje ih nakon što je mreža "vidjela" dobru transakciju. Ako nema konačnosti, objavljeni fork će zameniti blok s "dobrom" transakcijom nečim iz "lošeg" forka, u kojem su isti resursi preneseni na adresu napadača. U slučaju PVRB, zahtevi za konačnost su još stroži, budući da izgradnja forkova za PVRB omogućava napadaču da pripremi nekoliko varijanti nasumičnosti s ciljem da objavi onu koja mu najviše odgovara, i da ograniči vreme potencijalnog napada — što je dobro rešenje.

Stoga je najbolje rešenje spojiti PVRB i konačnost u jedan protokol — tada finalizirani blok = finalizirana nasumičnost, a to je upravo ono što je trebalo postići. Sada igrači dobijaju garantovanu nasumičnost za N sekundi i mogu biti sigurni da ju je nemoguće vratiti ili ponovo odigrati.

Opcija s integriranim konsenzusom je dobra:

mogućnošću asinkrone implementacije u odnosu na proizvodnju blokova — blokovi se proizvode kao i obično, ali paralelno s tim može raditi protokol PVRB, koji proizvodi nasumičnosti ne za svaki blok
mogućnošću implementacije čak i teške cryptografije, bez ograničenja koja nameću pametni ugovori
mogućnošću organizovanja razmene poruka brže nego što se transakcije uključuju u blockhain, na primer deo protokola može raditi između nodova bez širenja poruka po mreži

Ima i nedostatke:

težine prilikom testiranja i razvoja — biće potrebno emulirati mrežne greške, nestale nodove, hardforkove mreže
greške u implementaciji zahtevaju hardfork mreže

Oba načina implementacije PVRB imaju pravo na život, ali implementacija na pametnim ugovorima u savremenim blockchain-ima je ipak prilično ograničena u računalnim resursima, a svaki prelaz na ozbiljnu cryptografiju često je jednostavno nemoguć. A ozbiljna cryptografija će nam biti potrebna, kako će biti prikazano dalje. Iako, ovaj problem ima očigledno privremen karakter, ozbiljna cryptografija u ugovorima je potrebna za rešavanje mnogih zadataka, i postepeno se pojavljuje (na primer, sistemski ugovori za zkSNARKs u Ethereum-u)

Blockchain, which provides a transparent and reliable messaging exchange channel for the protocol, does not come for free. Any decentralized protocol must take into account the possibility of a Sybil attack; any action can be agreed upon by a multitude of accounts. Therefore, design must 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, tested by many gambling applications, hasn't yet been implemented in blockchains. Where then does such a number of gambling applications in Ethereum and EOS come from? It surprises me just as much as it surprises you; how did we find so many 'stubborn' randoms in a completely deterministic environment?

The favorite way to extract randomness in blockchain is to take some 'unpredictable' information from the block and use it to generate randomness — simply hashing one or several values. There's a good article about the problems of such schemes. ovdjeYou can take any of the 'unpredictable' values in the block, like the block hash, the number of transactions, network difficulty, and other unknown values. Then hash one or several of them, and, theoretically, you should get genuine randomness. You can even add to the whitepaper that your scheme is 'post-quantum secure' (since there are quantum-proof hash functions).

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

The result must have a provably uniform distribution, i.e., based on provably strong cryptography.
No bits of the result can be controlled. Consequently, the result cannot be predicted in advance.
The protocol generation cannot be sabotaged by non-participation in the protocol or by overloading the network with attacking messages.
All of the above must be resistant to collusion among a permissible number of dishonest participants in the protocol (for example, 1/3 of the participants).

U ovom slučaju poštuje se samo zahtjev 1, dok se 2 ne poštuje. Hashiranjem nepredvidivih vrijednosti iz bloka dobit ćemo ravnomjernu raspodjelu i dobre nasumične vrijednosti. No, BP ima barem mogućnost "objaviti blok ili ne". Tako BP može birati između DVA načina nasumičnosti: "svoju" i onu koja bi nastala ako bi blok napravio netko drugi. BP može unaprijed "zagledati" što će biti ako objavi blok i jednostavno donijeti odluku o tome hoće li to učiniti ili ne. Tako, igrajući primjerice "par-nepar" ili "crveno/crno" na ruletu, može objaviti blok samo ako vidi dobitak. To također čini neučinkovitom strategiju korištenja, primjerice, hash-a bloka "iz budućnosti". U ovom slučaju se govori da "će biti korištena nasumičnost koja se dobiva hashiranjem trenutnih podataka i hash-a budućeg bloka visine, primjerice, N + 42, gdje je N trenutna visina bloka. To malo jača shemu, ali svejedno omogućava BP-u da, iako u budućnosti, bira hoće li zadržati blok ili ga objaviti.

Softver BP u ovom slučaju postaje složeniji, ali ne pretjerano. Samo prilikom validacije i uključivanja transakcije u blok dolazi do brze provjere hoće li biti dobitka, a možda i odabira jednog parametra transakcije kako bi se postigla velika vjerojatnost dobitka. U isto vrijeme, uhvatiti pametnog BP-a u ovakvim manipulacijama gotovo je nemoguće, svaki put se mogu koristiti nove adrese, i dobitci se mogu osvajati pomalo, ne izazivajući sumnju.

Dakle, načini koji koriste informacije iz bloka nisu prikladni kao univerzalna implementacija PVRB. U ograničenoj varijanti, s ograničenjima na veličine oklada, ograničenjima broja igrača i/ili KYC registracijom (kako bi se spriječilo da jedan igrač koristi više adresa), ovi modeli mogu funkcionirati za manje igre, ali ne više od toga.

PVRB i commit-reveal.

U redu, hvala hashiranju i barem relativnoj nepredvidivosti hash-a bloka i drugih varijabli. Ako se riješi problem front-running-a rudara, trebali bismo dobiti nešto bolje. Dodajmo u ovu shemu korisnike — neka također utječu na nasumičnost: svaki djelatnik tehničke podrške reći će vam da su najnasumičniji u IT sustavima postupci korisnika 🙂

Naivna shema, kada korisnici jednostavno šalju slučajne brojeve, a rezultat se izračunava kao, na primjer, hash njihove sume, nije dovoljna. U ovom slučaju, poslednji igrač može kontrolisati koji će rezultat biti birajući vlastitu slučajnost. Zato se koristi široko primenjivani obrazac commit-reveal. Učesnici prvo šalju hasheve svojih slučajnosti (commit-ove), a zatim otkrivaju same slučajnosti (reveal-ove). Faza “reveal” počinje tek nakon što su prikupljeni neophodni commit-ovi, tako da učesnici mogu poslati tačno onu slučajnost čiji su hash poslali ranije. Sada ovo sve spojimo s parametrima bloka, pri čemu je bolje uzeti iz budućnosti (slučajnost će biti poznata samo u jednom od budućih blokova), i voila — slučajnost je spremna! Sada svaki igrač utiče na rezultantnu slučajnost i može “pobediti” zlonamerni BP, prekrivajući njegovu slučajnost svojom, unapred nepoznatom, slučajnosti... Takođe, može se dodati zaštita od sabotiranja protokola putem neotkrivanja u fazi reveal — jednostavno zahtevajući prilikom commit-a da prilože određen iznos uz transakciju — osiguranje, koje se vraća samo u proceduri reveal. U tom slučaju, praviti commit i ne napraviti reveal biće neisplativo.

To je bio dobar pokušaj, a takve sheme postoje u igračkim DApp-ima, ali nažalost, to opet nije dovoljno. Sada na rezultat može uticati ne samo rudar, već i svaki učesnik protokola. Kontrolisati samo vrednost je i dalje moguće, s manjom stepenom varijabilnosti i uz novac, ali, kao i u slučaju s rudarom, ako su rezultati izvlačenja vredniji od cene učešća u PVRB protokolu, random-producer (RP) može odlučiti hoće li napraviti reveal i i dalje može birati između najmanje dve varijante slučajnosti.
Zato je pojavila mogućnost kažnjavanja onih koji prave commit i ne rade reveal, a ova shema će se još koristiti. Njena jednostavnost predstavlja ozbiljnu prednost — ozbiljniji protokoli zahtevaju mnogo moćnije proračune.

PVRB i deterministički potpisi.

Postoji još jedan način da se RP prisili na generiranje pseudosluhanne brojeve na koje ne može utjecati, ako mu se pruži "prototip" - to su deterministički potpisi. Takav potpis je, na primjer, RSA, a ECS nije. Ako RP ima par ključeva: RSA i EСС, i potpisuje neku vrijednost svojim privatnim ključem, tada će u slučaju RSA dobiti JEDAN I JEDINI potpis, dok u slučaju ECS može generirati više različitih valjanih potpisa. To se događa jer se pri stvaranju ECS potpisa koristi slučajni broj koji bira potpisnik, i on ga može odabrati na različite načine, dajući potpisniku mogućnost biranja između više potpisa. U slučaju RSA: "jedna ulazna vrijednost" + "jedan par ključeva" = "jedan potpis". Nije moguće predvidjeti koji će potpis dobiti drugi RP, stoga se PVRB s determinističkim potpisima može organizirati kombiniranjem RSA potpisa više sudionika koji su potpisali istu vrijednost. Na primjer - prethodni slučajan broj. U ovoj shemi se štedi značajna količina resursa, jer su potpisi ujedno i potvrda pravilnog ponašanja prema protokolu i izvor slučajnog broja.

Međutim, čak i s determinističkim potpisima, shema je i dalje podložna problemu "posljednjeg aktera". Posljednji sudionik i dalje može odlučiti hoće li objaviti svoj potpis ili ne, čime kontrolira rezultat. Mogu se dodatno doraditi sheme, dodati hash-ovi blokova, organizirati runde kako bi se unaprijed ne bi moglo predvidjeti rezultat, ali sve te tehnike, i uz brojne dorade, i dalje ostavljaju neriješen problem utjecaja jednog sudionika na kolektivni rezultat u nepovjerenom okruženju i mogu raditi samo pod uvjetima ekonomskih i vremenskih ograničenja. Osim toga, veličina RSA ključeva (1024 i 2048 bitova) je prilično velika, dok je veličina za blockchain transakcije iznimno važan parametar. Čini se da jednostavno rješenje problema neće biti moguće, idemo dalje.

U kriptografiji postoje sheme koje omogućuju mreži da se dogovori o jednom i samo jednom vrijednosti PVRB, pri čemu su takve sheme otporne na zlonamjerne radnje dijela sudionika. Jedan od korisnih protokola koji vrijedi proučiti je shema dijeljenja tajne Shamir. Ona služi za dijeljenje tajne (na primjer, tajnog ključa) na nekoliko dijelova, i distribuciju tih dijelova N sudionicima. Tajna se raspodjeljuje na način da je za njezino obnavljanje potrebno M dijelova od N, pri čemu to mogu biti bilo koja M dijela. Ako se pojednostavi, imajući graf poznate funkcije, sudionici razmjenjuju točke na grafu, a nakon dobivanja M točaka, cijela funkcija može biti obnovljena.
Dobro objašnjenje je dano u wiki , a igrajući se s njim praktično, korisno je 'proći' protokol kroz glavu na demo stranici.

Da je shema FSSS (Fiat-Shamir Secret Sharing) primjenjiva u čistom obliku — bio bi to neuništiv PVRB. U najjednostavnijoj varijanti protokol može izgledati ovako:

Svaki sudionik generira svoj vlastiti random i dijeli dijelove od njega ostalim sudionicima.
Svaki sudionik otkriva svoje dijelove tajni drugih sudionika.
Ako je za sudionika prikupljeno više od M dijelova, onda se broj tog sudionika može izračunati, i on će biti jedinstven, bez obzira na skup otkrivenih sudionika.
Kombinacija otkrivenih randomova i predstavlja traženi PVRB.

Ovdje jedan pojedinačni sudionik više ne utječe na rezultate protokola, osim u slučajevima kada isključivo od njega ovisi postizanje threshold-a otkrivanja randoma. Stoga ovaj protokol, uz neophodan postotak onih koji rade prema protokolu i dostupne RP, funkcionira, ispunjavajući zahtjeve za kriptografsku otpornost, a ostajući otporan na problem 'zadnjeg aktera'.

To bi mogla biti idealna opcija, ova shema PVRB temeljena na dijeljenju tajne Fiat-Shamira opisana je, na primjer, u ove članku. No, kao što je rečeno, ako se pokuša primijeniti izravno u blockchainu, pojavljuju se tehnička ograničenja. Evo primjera testne implementacije protokola u smart ugovoru EOS i najvažnijeg dijela — provjera objavljenog dijela sudionika: kod. Iz koda je vidljivo da validacija proofa zahtijeva nekoliko skalarnih množenja, a korištena su vrlo velika brojeva. Pri tome je važno razumjeti da se u blockchainima verifikacija odvija u trenutku kada block-producer obrađuje transakciju, i zapravo svaki sudionik treba lako provjeriti ispravnost protokola, stoga su zahtjevi za brzinom funkcije verifikacije vrlo ozbiljni. U ovoj varijanti je rješenje pokazalo neispravnim, jer verifikacija nije stizala u vremenski okvir od 0.5 sekundi.

Efikasnost verifikacije jedan je od najvažnijih zahtjeva za korištenje gotovo svih naprednih kriptografskih shema u blockchainu. Kreiranje proof-ova, priprema poruka — te procedure mogu se iznijeti izvan lanca i izvoditi na visoko-performantnim računalima, ali verifikaciju se ne može zaobići — to je još jedan važan zahtjev za PVRB.

PVRB i threshold potpisi

Upoznajući se sa shemom tajnog dijeljenja, otvorili smo cijelu klasu protokola, ujedinjenih ključnom riječi “threshold”. Kada je za otkrivanje određenih informacija potrebno sudjelovanje M poštenih sudionika iz N, a skup poštenih sudionika može biti proizvoljna podskupina N, govori se o “threshold” shemama. One omogućavaju rješavanje problema “posljednjeg aktera”, sada ako napadač ne otkrije svoj dio tajne, to će učiniti drugi, pošteni sudionik. Ove sheme omogućavaju dogovor o jednom i jedinom vrijednosti, čak i kada dio sudionika sabotira protokol.

Kombinacija determinističkih potpisa i threshold-shema omogućila je razvoj vrlo prikladne i obećavajuće sheme za implementaciju PVRB — to su deterministički threshold-potpisi. Evo članak o različitim primjenama threshold-potpisa, a evo još jednog dobrog longread od Dash.

U posljednjem članku opisani su BLS potpisi (BLS se dekodira kao Boneh-Lynn-Shacham, evo članak ), koji imaju vrlo važnu i izuzetno korisnu karakteristiku za programere — javni, tajni, javni ključevi i potpisi BLS mogu se međusobno kombinirati pomoću jednostavnih matematičkih operacija, pri čemu njihova kombinacija ostaje valjana ključevi i potpisi, omogućujući lako agregiranje mnogih potpisa u jedan i mnogo javnih ključeva u jedan. Takođe, karakteriziraju ih i determinističnost, što znači da pri istim ulaznim podacima daju isti rezultat. Zahvaljujući ovoj osobini, kombinacije BLS potpisa same su valjani ključevi, što omogućava realizaciju varijante u kojoj M od N sudionika proizvode jedan i jedini potpis, koji je determiniran, javno provjerljiv i nepredvidiv sve dok ga ne otkrije M-ti sudionik.

U shemi s threshold BLS potpisima svaki sudionik potpisuje pomoću BLS nešto (na primjer prethodni random), a ukupni threshold-potpis je traženi random. Kriptografske osobine BLS potpisa zadovoljavaju zahtjeve za kvalitetu randoma, threshold-dio štiti od "last-actor" scenarija, a jedinstvena kombinabilnost ključeva omogućuje implementaciju mnogih zanimljivih algoritama koji, na primjer, omogućuju učinkovitu agregaciju poruka protokola.

Dakle, ako gradite PVRB u svom blockchainu, velika je vjerojatnost da ćete doći do sheme BLS threshold potpisa, koju već koriste neki projekti. Na primjer, DFinity (ovdje benchmark koji implementira shemu, a ovdje primjer implementacije verifiable secret sharing), ili Keep.network (evo njihovog random beacon yellowpaper, a evo primjer pametan ugovor koji podržava protokol).

Implementacija PVRB

Nažalost, još uvijek ne vidimo gotov, implementiran u PVRB blockchainima protokol koji je dokazao svoju sigurnost i otpornost. Iako su sami protokoli spremni, tehnički je teško primijeniti ih na postojeća rješenja. Za centralizirane sustave PVRB nema smisla, dok su decentralizirani strogo ograničeni u svim računalnim resursima: CPU, memorija, pohrana, I/O. Dizajniranje PVRB-a znači kombiniranje različitih protokola kako bi se ipak stvorilo nešto što će zadovoljiti sve zahtjeve barem za neki održivi blockchain. Jedan protokol djelotvornije računa, ali zahtijeva više poruka između RP-a, dok drugi zahtijeva ekstremno malo poruka, ali kreiranje dokaza može trajati desetke minuta, pa čak i sati.

Nabrojat ću čimbenike koje morate uzeti u obzir prilikom odabira kvalitetnog PVRB-a:

Kryptografska otpornost. Vaš PVRB mora biti strogo neistran, bez mogućnosti kontrole jednog bita. U nekim shemama to nije slučaj, stoga pozovite kriptografa.
Problema “posljednjeg aktera”. Vaš PVRB mora biti otporan na napade kada napadač, koji kontrolira jednog ili više RP-a, može birati jedan od dva moguća rezultata.
Problema sabotiranja protokola. Vaš PVRB mora biti otporan na napade kada napadač, koji kontrolira jednog ili više RP-a, odlučuje o tome hoće li randomizirati ili ne te može zajamčeno, ili s određenom vjerojatnošću utjecati na to.
Problema broja poruka. Vaši RP-ovi trebaju slati minimalno poruka u blockchain i maksimalno izbjegavati sinkronizirane aktivnosti poput situacija “poslao sam neke informacije, čekam odgovor od određenog sudionika”. U p2p mrežama, posebno geografski raspršenim, ne treba računati na brzi odgovor.
Problema računalne kompleksnosti. Verifikacija bilo kojeg koraka PVRB-a on-chain mora biti izuzetno jednostavna, budući da je izvode svi puni klijenti mreže. Ako se implementacija radi putem pametnog ugovora, zahtjevi za brzinom su vrlo strogi.
Problema dostupnosti i stalnosti. Vaš PVRB treba težiti da bude otporan na situacije kada dio mreže postane nedostupan neko vrijeme, a dio RP-a jednostavno prestane raditi.
Problema pouzdane postavke i prvotne distribucije ključeva. Ako vaš PVRB koristi primarni setup protokola, to je velika i ozbiljna priča. Evo primjer. Ako sudionici moraju prije početka protokola međusobno razmijeniti svoje ključeve — to je također problem, ako se sastav sudionika mijenja
Problemi razvoja. Postojanje biblioteka na potrebnim jezicima, njihova sigurnost i performanse, javnost, složeni testovi itd.

Na primjer, kod threshold BLS potpisa postoji značajan problem — prije nego što započnu rad, sudionicima je obavezno potrebna razmjena ključeva, organizirajući grupu koja će raditi na thresholdu. To znači da se barem jedan krug razmjene u decentraliziranoj mreži mora čekati, a s obzirom na to da je generirani random, na primjer, potreban u igrama, praktički u realnom vremenu, to implicira da je sabotiranje protokola moguće u ovoj fazi, a prednosti threshold sheme se gube. Ovaj problem je već jednostavniji od prethodnog, ali ipak zahtijeva razvoj zasebne procedure formiranja threshold grupa, koju će biti potrebno ekonomски zaštititi, putem depozita i oduzimanja sredstava (slashing) od sudionika koji se ne pridržavaju protokola. Također, verifikacija BLS s prihvatljivim nivoom sigurnosti jednostavno ne staje, na primjer, u standardnu transakciju EOS-a ili Ethereuma — jednostavno nema dovoljno vremena za verifikaciju. Kod ugovora — to je WebAssembly ili EVM, izvršava se od strane virtualne mašine. Kriptografske funkcije nisu implementirane nativno (za sada) i rade desetke puta sporije od običnih kriptografskih biblioteka. Mnogi protokoli ne ispunjavaju zahtjeve jednostavno zbog volumena ključeva, na primjer, to su 1024 i 2048 bit za RSA, 4-8 puta više od standardnog potpisa transakcije u Bitcoinu i Ethereumu.

Igra ulogu i postojanje implementacija na različitim programskim jezicima — kojih nema puno, posebno za nove protokole. Opcija s integracijom u konsenzus zahtijeva pisanje protokola na jeziku platforme, pa će trebati tražiti kod na Go za geth, na Rust za Parity, na C++ za EOS. Kod na JavaScriptu mora tražiti svatko, a s obzirom na to da JavaScript i kriptografija nisu posebno bliski prijatelji, WebAssembly će pomoći, koji sada već sigurno pretendira na ulogu sljedećeg važnog internet standarda.

Zaključak

Nadam se da je u prethodnoj članku Uspio sam vas uvjeriti da je generiranje nasumičnih brojeva na blockchainu od kritične važnosti za mnoge aspekte života decentraliziranih mreža, a ovim člankom sam pokazao da je ta zadaća izuzetno ambiciozna i složena, ali dobra rješenja već postoje. Općenito, konačni dizajn protokola moguć je tek nakon masovnog testiranja koje uzima u obzir sve aspekte, od postavljanja do simulacije kvarova, stoga vjerojatno nećete pronaći gotove recepte u whitepaperima timova i u člancima, a ni mi se nećemo usuditi pisati "radite ovako, ovo je definitivno ispravno" u sljedećih godinu ili dvije.

Za sada, za naš PVRB u razvoju blockchaina Haya, odlučili smo se za primjenu threshold BLS potpisa, planiramo implementirati PVRB na razini konsenzusa, jer verifikacija u pametnim ugovorima s prihvatljivim razinama sigurnosti još uvijek nije moguća. Moguće je da ćemo koristiti dvije sheme: prvo skupu tajnu podijeliti za stvaranje dugoročnog random_seed-a, a zatim ćemo ga koristiti kao osnovu za visoko-frekventno generiranje nasumičnih brojeva pomoću determiniranih threshold BLS potpisa, i možda ćemo se ograničiti samo na jednu od shema. Nažalost, unaprijed nije moguće reći kakav će biti protokol, ali veseli nas da, kao u znanosti, u inženjerskim zadacima negativan rezultat - također je rezultat, i svaki novi pokušaj rješavanja zadatka predstavlja još jedan korak u istraživanju svih koji se bave tim problemom. Kako bismo zadovoljili poslovne zahtjeve, rješavamo konkretan praktični problem - osiguranje igračkih aplikacija pouzdanim izvorom entropije, pa smo prisiljeni obratiti pažnju i na sam blockchain, posebno na pitanja konačnosti lanca i upravljanja mrežom.

I iako trenutno ne vidimo u blockchainu dokazano otpornog PVRB-a koji je već dovoljno dugo korišten da bi prošao testove stvarnim aplikacijama, višestrukim revizijama, opterećenjima i, naravno, stvarnim napadima, broj mogućih puteva potvrđuje da rješenje postoji i da će neki od tih algoritama na kraju riješiti problem. S zadovoljstvom ćemo dijeliti rezultate i zahvaljujemo drugim timovima koji se također bave ovim pitanjem na člancima i kodu koji omogućuju inženjerima da ne kroče dvaput u iste zamke.

Ako sretnete programtera koji dizajnira decentralizirani generator nasumičnih brojeva, budite oprezni i pažljivi, a ako je potrebno, pružite psihološku podršku 🙂

Izvor: habr.com