Uvod

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

Kao i kod koncepta apsolutno jake šifre iz kriptografije, pravi protokoli "javno provjerljivog slučajnog svjetionika" (u daljnjem tekstu PVRB) samo se pokušavaju približiti što je moguće bliže idealnoj shemi, jer u stvarnim mrežama nije primjenjiv u svom čistom obliku: potrebno je dogovoriti striktno oko jednog bita, mora biti mnogo rundi, a sve poruke moraju biti savršeno brze i uvijek isporučene. Naravno, to nije slučaj u stvarnim mrežama. Stoga se kod projektiranja PVRB-ova za specifične zadatke u modernim blockchainovima, osim nemogućnosti kontrole rezultirajuće slučajnosti i kriptografske snage, pojavljuju još mnogi čisto arhitektonski i tehnički problemi.

Za PVRB, sam blockchain je u biti komunikacijski medij u kojem su poruke = transakcije. To vam omogućuje djelomično apstrahiranje od mrežnih problema, neisporuke poruka, problema s međuprogramom - sve te rizike preuzima decentralizirana mreža, a njegova glavna vrijednost za PVRB je nemogućnost opoziva ili kvarenja već poslane transakcije - to čini ne dopustiti sudionicima da odbiju sudjelovanje u protokolu, osim ako su izveli uspješan napad na konsenzus. Ova razina sigurnosti je prihvatljiva, tako da bi PVRB trebao biti otporan na tajne dogovore sudionika u točno istoj mjeri kao i glavni lanac blockchaina. Također, ovo upućuje na to da PVRB mora biti dio konsenzusa ako se mreža složi oko glavnog lanca blokova, čak i ako se također složi oko jedinog pravednog rezultirajućeg slučajnog odabira. Ili, PVRB je jednostavno samostalni protokol implementiran pametnim ugovorom koji radi asinkrono s obzirom na blockchain i blokove. Obje metode imaju svoje prednosti i nedostatke, a izbor između njih je krajnje netrivijalan.

Dva načina implementacije PVRB-a

Opišimo detaljnije dvije opcije za implementaciju PVRB-a - samostalnu verziju, koja radi pomoću pametnog ugovora neovisno o blockchainu, i konsenzusno integriranu verziju, ugrađenu u protokol, prema kojoj se mreža dogovara oko blockchaina i transakcije koje treba uključiti. U svim slučajevima mislit ću na popularne blockchain motore: Ethereum, EOS i sve one koji su im slični u načinu na koji hostiraju i obrađuju pametne ugovore.

Samostalni ugovor

U ovoj verziji PVRB je pametni ugovor koji prihvaća transakcije slučajnih proizvođača (u daljnjem tekstu RP), obrađuje ih, kombinira rezultate i kao rezultat dolazi do određene vrijednosti koju svaki korisnik može dobiti iz ovog ugovora. Ta vrijednost ne može biti pohranjena izravno u ugovoru, već može biti predstavljena samo podacima iz kojih se može deterministički dobiti jedna i samo jedna vrijednost rezultirajuće slučajnosti. U ovoj shemi, RP-ovi su korisnici blockchaina i svakome se može dopustiti sudjelovanje u procesu generiranja.

Opcija sa samostalnim ugovorom je dobra:

• prenosivost (ugovori se mogu povlačiti iz blockchaina u blockchain)
• jednostavnost implementacije i testiranja (ugovore je lako napisati i testirati)
• pogodnost u implementaciji ekonomskih shema (lako je napraviti vlastiti token, čija logika služi u svrhu PVRB-a)
• mogućnost pokretanja na već funkcionalnim blockchainovima

Također ima nedostatke:

• jaka ograničenja računalnih resursa, volumena transakcija i pohrane (drugim riječima, cpu/mem/io)
• ograničenja poslovanja unutar ugovora (nisu dostupne sve upute, teško je spojiti vanjske knjižnice)
• nemogućnost organiziranja slanja poruka brže nego što su transakcije uključene u blockchain

Ova je opcija prikladna za implementaciju PVRB-a koji se mora pokrenuti na postojećoj mreži, ne sadrži složenu kriptografiju i ne zahtijeva velik broj interakcija.

Integriran konsenzusom

U ovoj verziji, PVRB je implementiran u kod blokchain čvora, ugrađen ili radi paralelno s razmjenom poruka između blockchain čvorova. Rezultati protokola zapisuju se izravno u proizvedene blokove, a poruke protokola se šalju preko p2p mreže između čvorova. Budući da protokol rezultira brojevima koji se trebaju pisati u blokovima, mreža mora postići konsenzus o njima. To znači da PVRB poruke, kao i transakcije, moraju potvrditi čvorovi i uključiti u blokove tako da svaki sudionik mreže može potvrditi usklađenost s PVRB protokolom. To nas automatski dovodi do očitog rješenja - ako se mreža složi oko bloka i transakcija u njemu, tada bi PVRB trebao biti dio konsenzusa, a ne samostalni protokol. U suprotnom, moguće je da je blok valjan s gledišta konsenzusa, ali se ne slijedi PVRB protokol, a s gledišta PVRB blok se ne može prihvatiti. Dakle, ako se odabere opcija "integrirana u konsenzus", PVRB postaje važan dio konsenzusa.

Kada se opisuju PVRB implementacije na razini konsenzusa mreže, ni na koji način se ne mogu izbjeći pitanja konačnosti. Konačnost je mehanizam koji se koristi u determinističkim konsenzusima koji zaključava blok (i lanac koji vodi do njega) koji je konačan i nikada neće biti odbačen, čak i ako dođe do paralelnog račvanja. Na primjer, u Bitcoinu ne postoji takav mehanizam - ako objavite lanac veće složenosti, on će zamijeniti svaki manje složen, bez obzira na duljinu lanaca. A u EOS-u, na primjer, posljednji su takozvani Last Irreversible Blocks, koji se pojavljuju u prosjeku svaka 432 bloka (12*21 + 12*15, pre-vote + pre-commit). Ovaj proces u biti čeka 2/3 potpisa proizvođača blokova (u daljnjem tekstu BP). Kada se pojave vilice koje su starije od zadnjeg LIB-a, jednostavno se odbacuju. Ovaj mehanizam omogućuje jamstvo da je transakcija uključena u blockchain i da se nikada neće vratiti, bez obzira na resurse koje napadač ima. Također, konačni blokovi su blokovi potpisani od strane 2/3 BP-a u Hyperledgeru, Tendermintu i drugim konsenzusima temeljenim na pBFT-u. Također, ima smisla napraviti protokol za osiguranje konačnosti kao dodatak konsenzusu, budući da može raditi asinkrono s proizvodnjom i objavom blokova. Evo jednog dobrog članak o konačnosti u Ethereumu.

Konačnost je iznimno važna za korisnike, koji bi se bez nje mogli naći žrtvama napada "dvostruke potrošnje", gdje BP "drži" blokove i objavljuje ih nakon što mreža "vidi" dobru transakciju. Ako nema konačnosti, tada objavljeni fork zamjenjuje blok s "dobrom" transakcijom drugom, iz "lošeg" forka, u kojem se ista sredstva prebacuju na adresu napadača. U slučaju PVRB-a, zahtjevi za konačnošću su još stroži, budući da izgradnja forkova za PVRB znači mogućnost da napadač pripremi nekoliko nasumičnih opcija kako bi objavio najprofitabilniju, a ograničenje vremena mogućeg napada je dobro rješenje.

Stoga je najbolja opcija spojiti PVRB i finality u jedan protokol - tada finalized block = finalized random, a to je upravo ono što smo trebali dobiti. Sada će igrači dobiti zajamčeno slučajni odabir za N sekundi i mogu biti sigurni da ga je nemoguće vratiti ili ponovo reproducirati.

Opcija integrirana konsenzusom je dobra:

• mogućnost asinkrone implementacije u odnosu na proizvodnju blokova - blokovi se proizvode kao i obično, ali paralelno s tim može raditi PVRB protokol koji ne proizvodi slučajnost za svaki blok
• mogućnost implementacije čak i teške kriptografije, bez ograničenja nametnutih pametnim ugovorima
• sposobnost organiziranja razmjene poruka brže nego što su transakcije uključene u blockchain, na primjer, dio protokola može raditi između čvorova bez distribucije poruka preko mreže

Također ima nedostatke:

• Poteškoće u testiranju i razvoju - morat ćete emulirati mrežne pogreške, nedostajuće čvorove, mrežne hard forkove
• Pogreške u implementaciji zahtijevaju hardfork mreže

Obje metode implementacije PVRB-a imaju pravo na život, ali implementacija na pametnim ugovorima u modernim blockchainovima još uvijek je prilično ograničena u računalnim resursima, a svaki prijelaz na ozbiljnu kriptografiju često je jednostavno nemoguć. I trebat će nam ozbiljna kriptografija, kao što će biti prikazano u nastavku. Iako je ovaj problem očito privremen, za rješavanje mnogih problema potrebna je ozbiljna kriptografija u ugovorima, koja se postupno pojavljuje (na primjer, sistemski ugovori za zkSNARK u Ethereumu)

Blockchain, koji pruža transparentan i pouzdan kanal za razmjenu poruka protokola, ne čini to besplatno. Svaki decentralizirani protokol mora uzeti u obzir mogućnost Sybil napada; bilo koju akciju mogu izvršiti združene snage višestrukih računa, stoga je prilikom dizajniranja potrebno uzeti u obzir sposobnost napadača da kreiraju proizvoljan broj protokola sudionici koji djeluju u dogovoru.

PVRB i blok varijable.

Nisam lagao kad sam rekao da još nitko nije implementirao dobar PVRB, testiran u mnogim aplikacijama za kockanje, u blockchain-ovima. Odakle onda toliko aplikacija za kockanje na Ethereumu i EOS-u? Ovo me iznenađuje koliko i vas, odakle im toliko "upornih" slučajnih odabira u potpuno determinističkom okruženju?

Omiljeni način dobivanja nasumičnosti u blockchainu je uzeti neku vrstu "nepredvidivih" informacija iz bloka i napraviti nasumičnu na temelju nje - jednostavno raspršivanjem jedne ili više vrijednosti. Dobar članak o problemima takvih shema здесь. Možete uzeti bilo koju od "nepredvidivih" vrijednosti u bloku, na primjer, hash bloka, broj transakcija, složenost mreže i druge unaprijed nepoznate vrijednosti. Zatim ih raspršite, jednu ili više, i, u teoriji, trebali biste dobiti pravi nasumični odabir. Možete čak dodati u wihitepaper da je vaša shema "postkvantno sigurna" (budući da postoje kvantno otporne hash funkcije :)).

Ali ni post-kvantno sigurni hashevi nisu dovoljni, nažalost. Tajna je u zahtjevima za PVRB, da vas podsjetim na njih iz prethodnog članka:

1. Rezultat mora imati dokazivo jednoliku distribuciju, tj. temeljiti se na dokazano jakoj kriptografiji.
2. Nije moguće kontrolirati nijedan od bitova rezultata. Kao posljedica toga, ishod se ne može unaprijed predvidjeti.
3. Ne možete sabotirati protokol generiranja nesudjelujući u protokolu ili preopterećivanjem mreže porukama napada
4. Sve navedeno mora biti otporno na dogovaranje dopuštenog broja nepoštenih sudionika protokola (npr. 1/3 sudionika).

U ovom slučaju ispunjen je samo zahtjev 1, a nije ispunjen zahtjev 2. Raspršivanjem nepredvidivih vrijednosti iz bloka dobit ćemo jednoliku distribuciju i dobre slučajnosti. Ali BP barem ima opciju "objaviti blok ili ne". Dakle, BP može birati između DVIJE nasumične opcije: “svoje” i one koja će se pokazati ako netko drugi napravi blok. BP može unaprijed “njuškati” što će se dogoditi ako objavi blok i jednostavno odluči hoće li to učiniti ili ne. Tako, igrajući npr. "par-nepar" ili "crveno/crno" u ruletu, može objaviti blok samo ako vidi dobitak. To također čini strategiju korištenja, na primjer, hash bloka "iz budućnosti" neprovedivom. U ovom slučaju kažu da će se koristiti “random koji se dobije hashiranjem trenutnih podataka i hash-a budućeg bloka visine npr. N + 42, gdje je N trenutna visina bloka. Ovo malo jača shemu, ali još uvijek omogućuje BP-u, iako u budućnosti, da izabere hoće li zadržati blok ili objaviti.

BP softver u ovom slučaju postaje kompliciraniji, ali ne puno. Jednostavno, prilikom validacije i uključivanja transakcije u blok, postoji brza provjera hoće li biti dobitka, te eventualno odabir parametra jedne transakcije kako bi se dobila velika vjerojatnost dobitka. Istodobno, gotovo je nemoguće uhvatiti pametnog BP-a za takve manipulacije; svaki put možete koristiti nove adrese i malo po malo pobijediti bez izazivanja sumnje.

Stoga metode koje koriste informacije iz bloka nisu prikladne kao univerzalna implementacija PVRB-a. U ograničenoj verziji, s ograničenjima na veličinu uloga, ograničenja na broj igrača i/ili KYC registraciju (kako bi se spriječilo da jedan igrač koristi više adresa), ove sheme mogu funkcionirati za male igre, ali ništa više.

PVRB i commit-reveal.

U redu, zahvaljujući raspršivanju i barem relativnoj nepredvidivosti bloka raspršivanja i drugih varijabli. Ako riješite problem vodećih rudara, trebali biste nabaviti nešto prikladnije. Dodajmo korisnike u ovu shemu - neka i oni utječu na slučajnost: svaki zaposlenik tehničke podrške reći će vam da su najslučajnija stvar u IT sustavima akcije korisnika :)

Naivna shema, kada korisnici jednostavno šalju nasumične brojeve, a rezultat se izračunava kao, na primjer, hash njihovog zbroja, nije prikladna. U ovom slučaju, posljednji igrač može, odabirom vlastitog slučajnog odabira, kontrolirati kakav će biti rezultat. Zbog toga se koristi vrlo široko korišteni commit-reveal obrazac. Sudionici prvo šalju hashove iz svojih randoma (commit), a zatim sami otvaraju randome (reveals). Faza "otkrivanja" počinje tek nakon što se prikupe potrebne obveze, tako da sudionici mogu poslati točno onaj nasumični hash iz kojeg su poslali ranije. Sada stavimo sve ovo zajedno s parametrima bloka, i to boljeg od onog uzetog iz budućnosti (slučajnost se može pronaći samo u jednom od budućih blokova), i voila - slučajnost je spremna! Sada bilo koji igrač utječe na rezultirajuću nasumičnost i može "poraziti" zlonamjernog BP-a nadjačavajući ga vlastitom, unaprijed nepoznatom nasumičnošću... Također možete dodati zaštitu od sabotiranja protokola tako da ga ne otvorite u fazi otkrivanja - jednostavno zahtijevajući da se određeni iznos priloži transakciji prilikom preuzimanja — sigurnosni polog, koji će biti vraćen samo tijekom postupka otkrivanja. U ovom slučaju, obvezivanje i neotkrivanje bit će neisplativo.

Bio je to dobar pokušaj, a takve sheme također postoje u gaming DApps, ali nažalost, to opet nije dovoljno. Sada ne samo rudar, već i bilo koji sudionik u protokolu može utjecati na rezultat. I dalje je moguće kontrolirati samu vrijednost, uz manje varijabilnosti i uz trošak, ali, kao u slučaju rudara, ako su rezultati izvlačenja vrjedniji od naknade za sudjelovanje u PVRB protokolu, tada će slučajni odabir -producent(RP) može odlučiti hoće li otkriti i još uvijek može birati između najmanje dvije nasumične opcije.
Ali postalo je moguće kazniti one koji počine, a ne otkriju, a ova će nam shema dobro doći. Njegova jednostavnost je ozbiljna prednost - ozbiljniji protokoli zahtijevaju mnogo snažnije izračune.

PVRB i deterministički potpisi.

Postoji još jedan način da se RP prisili da pruži pseudo-nasumični broj na koji ne može utjecati ako mu je priložena "predslika" - ovo je deterministički potpis. Takav potpis je npr. RSA, a nije ECS. Ako RP ima par ključeva: RSA i ECC, i potpisuje određenu vrijednost svojim privatnim ključem, tada će u slučaju RSA dobiti JEDAN I SAMO JEDAN potpis, a u slučaju ECS može generirati bilo koji broj različite valjane potpise. To je zato što se prilikom kreiranja ECS potpisa koristi nasumični broj koji odabire potpisnik, a može se odabrati na bilo koji način, dajući potpisniku mogućnost odabira jednog od nekoliko potpisa. U slučaju RSA: “jedna ulazna vrijednost” + “jedan par ključeva” = “jedan potpis”. Nemoguće je predvidjeti kakav će potpis dobiti drugi RP, tako da se PVRB s determinističkim potpisima može organizirati kombiniranjem RSA potpisa nekoliko sudionika koji su potpisali istu vrijednost. Na primjer, prethodni slučajni. Ova shema štedi puno resursa, jer potpisi su i potvrda ispravnog ponašanja prema protokolu i izvor slučajnosti.

Međutim, čak i s determinističkim potpisima, shema je još uvijek osjetljiva na problem "posljednjeg aktera". Posljednji sudionik još uvijek može odlučiti hoće li objaviti potpis ili ne, čime kontrolira ishod. Možete modificirati shemu, dodati joj blok hashove, napraviti krugove tako da se rezultat ne može unaprijed predvidjeti, ali sve te tehnike, čak i uzimajući u obzir mnoge modifikacije, još uvijek ostavljaju neriješenim problem utjecaja jednog sudionika na kolektiv. rezultira nepouzdanim okruženjem i može raditi samo pod ekonomskim i vremenskim ograničenjima. Osim toga, veličina RSA ključeva (1024 i 2048 bita) je prilično velika, a veličina za blockchain transakcije iznimno je važan parametar. Očigledno ne postoji jednostavan način za rješavanje problema, idemo dalje.

PVRB i sheme dijeljenja tajni

U kriptografiji postoje sheme koje mogu omogućiti mreži dogovor o jednoj i samo jednoj PVRB vrijednosti, a takve sheme su otporne na bilo kakve zlonamjerne radnje pojedinih sudionika. Jedan koristan protokol s kojim se vrijedi upoznati je Shamirova shema dijeljenja tajni. Služi za dijeljenje tajne (npr. tajnog ključa) na nekoliko dijelova i raspodjelu tih dijelova na N sudionika. Tajna je raspoređena na način da je M dijelova od N dovoljno da se vrati, a to može biti bilo koji M dijelova. Ako je na prstima, tada imajući graf nepoznate funkcije, sudionici razmjenjuju bodove na grafu, a nakon što dobiju M bodova, cijela se funkcija može vratiti.
Dato je dobro objašnjenje wiki ali praktično igranje s njim kako biste igrali protokol u svojoj glavi korisno je za demo stranica.

Kada bi shema FSSS (Fiat-Shamir Secret Sharing) bila primjenjiva u svom čistom obliku, bila bi to neuništiva PVRB. U svom najjednostavnijem obliku, protokol bi mogao izgledati ovako:

• Svaki sudionik generira vlastiti slučajni odabir i iz njega dijeli dionice drugim sudionicima
• Svaki sudionik otkriva svoj dio tajni ostalih sudionika
• Ako sudionik ima više od M udjela, tada se može izračunati broj ovog sudionika, koji će biti jedinstven, bez obzira na skup otkrivenih sudionika
• Kombinacija otkrivenih slučajnih odabira je željeni PVRB

Ovdje pojedini sudionik više ne utječe na rezultate protokola, osim u slučajevima kada postizanje praga otkrivanja slučajnosti ovisi isključivo o njemu. Stoga ovaj protokol, ako postoji potreban udio RP-ova koji rade na protokolu i koji su dostupni, radi, implementirajući zahtjeve za kriptografskom snagom i otporan je na problem "posljednjeg aktera".

Ovo bi mogla biti idealna opcija, ova PVRB shema temeljena na Fiat-Shamir dijeljenju tajni opisana je na primjer u ovo članak. Ali, kao što je gore spomenuto, ako ga pokušate izravno primijeniti u blockchainu, pojavljuju se tehnička ograničenja. Evo primjera testne implementacije protokola u EOS pametnom ugovoru i njegovog najvažnijeg dijela - provjere objavljenog dioničkog sudionika: šifra. Iz koda možete vidjeti da provjera valjanosti zahtjeva nekoliko skalarnih množenja, a korišteni brojevi su vrlo veliki. Treba imati na umu da se u lancima blokova provjera događa u trenutku kada proizvođač blokova obrađuje transakciju, a općenito svaki sudionik mora lako provjeriti ispravnost protokola, tako da su zahtjevi za brzinom funkcije provjere vrlo ozbiljni. . U ovoj se opciji opcija pokazala neučinkovitom jer provjera nije ušla u ograničenje transakcije (0.5 sekundi).

Učinkovitost provjere jedan je od najvažnijih zahtjeva za korištenje, općenito, bilo koje napredne kriptografske sheme u blockchainu. Stvaranje dokaza, priprema poruka - ti se postupci mogu ukloniti izvan lanca i izvesti na računalima visokih performansi, ali se verifikacija ne može zaobići - ovo je još jedan važan zahtjev za PVRB.

PVRB i potpisi praga

Nakon što smo se upoznali sa shemom dijeljenja tajni, otkrili smo cijelu klasu protokola objedinjenih ključnom riječi "prag". Kada otkrivanje neke informacije zahtijeva sudjelovanje M poštenih sudionika od N, a skup poštenih sudionika može biti proizvoljan podskup od N, govorimo o shemama “praga”. Oni su ti koji nam omogućuju da se nosimo s problemom "zadnjeg glumca", sada ako napadač ne otkrije svoj dio tajne, drugi, pošteni sudionik će to učiniti umjesto njega. Ove sheme dopuštaju dogovor o jednom i samo jednom značenju, čak i ako neki od sudionika sabotiraju protokol.

Kombinacija determinističkih potpisa i shema praga omogućila je razvoj vrlo prikladne i obećavajuće sheme za implementaciju PVRB - to su determinističke signature praga. Ovdje članak o različitim upotrebama potpisa praga, a evo još jednog dobrog longread od Dash.

Zadnji članak opisuje BLS potpise (BLS je kratica za Boneh-Lynn-Shacham, ovdje članak), koji imaju vrlo važnu i izuzetno prikladnu kvalitetu za programere - javni, tajni, javni ključevi i BLS potpisi mogu se međusobno kombinirati pomoću jednostavnih matematičkih operacija, dok njihove kombinacije ostaju važeći ključevi i potpisi, što vam omogućuje jednostavno združivanje mnogih potpisa u jedan i više javnih ključeva u jedan. Oni su također deterministički i daju isti rezultat za iste ulazne podatke. Zahvaljujući ovoj kvaliteti, kombinacije BLS potpisa same su valjani ključevi, što omogućuje implementaciju opcije u kojoj M od N sudionika proizvodi jedan i samo jedan potpis koji je deterministički, javno provjerljiv i nepredvidljiv dok ga ne otvori Mth sudionik .

U shemi s BLS potpisima praga, svaki sudionik potpisuje nešto koristeći BLS (na primjer, prethodni nasumični), a zajednički prag je željeni nasumični potpis. Kriptografska svojstva BLS potpisa zadovoljavaju zahtjeve za nasumičnu kvalitetu, dio praga štiti od "zadnjeg aktera", a jedinstvena mogućnost kombiniranja ključeva omogućuje implementaciju mnogo zanimljivijih algoritama koji omogućuju, na primjer, učinkovito prikupljanje protokolarnih poruka .

Dakle, ako gradite PVRB na svom blockchainu, najvjerojatnije ćete završiti sa shemom potpisa BLS praga, nekoliko projekata je već koristi. Na primjer, DFinity (здесь benchmark koji implementira sklop, i ovdje primjer implementacije provjerljivog dijeljenja tajni), ili Keep.network (ovdje je njihov slučajni svjetionik žuti papir, Ali primjer pametni ugovor koji služi protokolu).

Implementacija PVRB

Nažalost, još uvijek ne vidimo gotov protokol implementiran u PVRB blockchains koji je dokazao svoju sigurnost i stabilnost. Iako su sami protokoli spremni, tehnička primjena na postojeća rješenja nije laka. Za centralizirane sustave PVRB nema smisla, a decentralizirani su strogo ograničeni u svim računalnim resursima: CPU, memorija, pohrana, I/O. Dizajniranje PVRB-a je kombinacija različitih protokola kako bi se stvorilo nešto što ispunjava sve zahtjeve za barem neki održiv blockchain. Jedan protokol izračunava učinkovitije, ali zahtijeva više poruka između RP-ova, dok drugi zahtijeva vrlo malo poruka, ali stvaranje dokaza može biti zadatak koji traje desetke minuta, pa čak i sate.

Navest ću čimbenike koje ćete morati uzeti u obzir pri odabiru kvalitetnog PVRB-a:

• Kriptografska snaga. Vaš PVRB mora biti strogo nepristrasan, bez mogućnosti kontrole ijednog bita. U nekim shemama to nije slučaj, pa pozovite kriptografa
• Problem “posljednjeg glumca”.. Vaš PVRB mora biti otporan na napade gdje napadač koji kontrolira jedan ili više RP-ova može odabrati jedan od dva ishoda.
• Problem sabotaže protokola. Vaš PVRB mora biti otporan na napade gdje napadač koji kontrolira jedan ili više RP-ova odlučuje hoće li biti nasumičan ili ne i može zajamčeno ili s određenom vjerojatnošću utjecati na to
• Problem s brojem poruka. Vaši RP-ovi bi trebali slati minimalno poruka u blockchain i izbjegavati sinkrone radnje što je više moguće kao što su situacije poput "Poslao sam neke informacije, čekam odgovor od određenog sudionika." U p2p mrežama, pogotovo geografski raspršenim, ne treba računati na brzi odgovor
• Problem računske složenosti. Provjera bilo kojeg stupnja PVRB-a u lancu trebala bi biti iznimno laka, budući da je provode svi puni klijenti mreže. Ako se implementacija provodi pomoću pametnog ugovora, tada su zahtjevi za brzinom vrlo strogi
• Problem pristupačnosti i živosti. Vaš PVRB trebao bi nastojati biti otporan na situacije u kojima dio mreže postane nedostupan neko vrijeme, a dio RP-a jednostavno prestane raditi
• Problem pouzdanog postavljanja i početne distribucije ključeva. Ako vaš PVRB koristi primarnu postavku protokola, onda je to posebna velika i ozbiljna priča. Ovdje primjer. Ako sudionici moraju jedni drugima reći svoje ključeve prije pokretanja protokola, to također predstavlja problem ako se mijenja sastav sudionika
• Problemi razvoja. Dostupnost knjižnica na traženim jezicima, njihova sigurnost i performanse, publicitet, složeni testovi itd.

Na primjer, threshold BLS potpisi imaju značajan problem - prije početka rada sudionici moraju međusobno podijeliti ključeve, organizirajući grupu unutar koje će threshold raditi. To znači da će barem jedna runda razmjene u decentraliziranoj mreži morati pričekati, a s obzirom da je generirani rand, primjerice, neophodan u igrama, gotovo u stvarnom vremenu, to znači da je u ovoj fazi moguća sabotaža protokola. , a prednosti sheme praga su izgubljene. Ovaj problem je već sada jednostavniji od prethodnih, ali još uvijek zahtijeva razvoj posebne procedure za formiranje prag grupa, koje će morati biti zaštićene ekonomski, uplatama i povlačenjem sredstava (slashing) od sudionika koji se ne pridržavaju protokol. Također, BLS verifikacija s prihvatljivom razinom sigurnosti jednostavno se ne uklapa, na primjer, u standardnu ​​EOS ili Ethereum transakciju - jednostavno nema dovoljno vremena za verifikaciju. Kod ugovora je WebAssembly ili EVM, a izvršava ga virtualni stroj. Kriptografske funkcije (još) nisu izvorno implementirane i rade desetke puta sporije od konvencionalnih kriptografskih biblioteka. Mnogi protokoli ne ispunjavaju zahtjeve samo na temelju volumena ključa, na primjer 1024 i 2048 bita za RSA, 4-8 puta veće od standardnog potpisa transakcije u Bitcoinu i Ethereumu.

Prisutnost implementacija u različitim programskim jezicima također igra ulogu - kojih je malo, posebno za nove protokole. Opcija s integracijom u consensus zahtijeva pisanje protokola u jeziku platforme, tako da ćete morati tražiti kod u Go za geth, u Rust za Parity, u C++ za EOS. Svi će morati tražiti JavaScript kod, a budući da JavaScript i kriptografija nisu baš bliski prijatelji, pomoći će WebAssembly, koji sada definitivno tvrdi da je sljedeći važan internetski standard.

Zaključak

Nadam se u prethodnom članak Uspio sam vas uvjeriti da je generiranje nasumičnih brojeva na blockchainu kritično za mnoge aspekte života decentraliziranih mreža, a ovim sam člankom pokazao da je taj zadatak iznimno ambiciozan i težak, ali dobra rješenja već postoje. Općenito, konačni dizajn protokola moguć je tek nakon provođenja opsežnih testova koji uzimaju u obzir sve aspekte od postavljanja do emulacije greške, tako da je malo vjerojatno da ćete pronaći gotove recepte u timskim dokumentima i člancima, a mi sigurno nećemo odlučite u sljedećih godinu ili dvije napišite "učini to na ovaj način, točno kako treba."

Zbogom, za naš PVRB u blockchainu koji se razvija Haya, odlučili smo se za korištenje BLS potpisa s pragom, planiramo implementirati PVRB na razini konsenzusa, budući da provjera u pametnim ugovorima s prihvatljivom razinom sigurnosti još nije moguća. Moguće je da koristimo dvije sheme odjednom: prvo, skupo dijeljenje tajni za stvaranje dugoročnog random_seed-a, a zatim ga koristimo kao osnovu za visokofrekventno nasumično generiranje pomoću determinističkih BLS potpisa praga, možda ćemo se ograničiti samo na jedna od shema. Nažalost, nemoguće je unaprijed reći kakav će biti protokol, jedina dobra stvar je što je, kao i u znanosti, u inženjerskim problemima negativan rezultat također rezultat, a svaki novi pokušaj rješavanja problema je još jedan korak za istraživanje svih uključenih u problem. Kako bismo zadovoljili poslovne zahtjeve, rješavamo specifičan praktični problem - osiguravamo igraćim aplikacijama pouzdan izvor entropije, stoga moramo obratiti pozornost i na sam blockchain, posebice na pitanja konačnosti lanca i upravljanja mrežom.

I iako još ne vidimo dokazano otporan PVRB u lancima blokova, koji bi se koristio dovoljno vremena da se testira stvarnim aplikacijama, višestrukim revizijama, učitavanjima i, naravno, pravim napadima, broj mogućih puteva potvrđuje da rješenje postoji i koji će od ovih algoritama na kraju riješiti problem. Rado ćemo podijeliti rezultate i zahvaliti drugim timovima koji također rade na ovom problemu za članke i kod koji inženjerima omogućuju da ne stanu dvaput na iste grablje.

Dakle, kada sretnete programera koji dizajnira decentralizirani random, budite pažljivi i brižni, a po potrebi pružite i psihološku pomoć :)

Izvor: www.habr.com