Uvod

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

Kao i kod koncepta apsolutno jake šifre iz kriptografije, pravi “Publicly Verifiable Random Beacon” (u daljem tekstu PVRB) protokoli samo pokušavaju da se što više približe idealnoj šemi, jer u stvarnim mrežama to nije primjenjivo u svom čistom obliku: potrebno je striktno dogovoriti jedan bit, 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, prilikom dizajniranja PVRB-ova za specifične zadatke u modernim blok-čejnovima, pored nemogućnosti kontrole proizašle nasumice i kriptografske snage, pojavljuju se još mnogi čisto arhitektonski i tehnički problemi.

Za PVRB, sam blockchain je u suštini komunikacijski medij u kojem su poruke = transakcije. Ovo vam omogućava da se djelimično apstrahujete od mrežnih problema, neisporuke poruka, problema sa međuverskim softverom - sve ove rizike preuzima decentralizovana mreža, a njegova glavna vrijednost za PVRB je nemogućnost opoziva ili korumpiranja već poslane transakcije - to je slučaj. ne dozvoliti učesnicima da odbiju učešće u protokolu, osim ako nisu izvršili uspješan napad na konsenzus. Ovaj nivo sigurnosti je prihvatljiv, tako da bi PVRB trebao biti otporan na dosluhe učesnika u potpuno istoj mjeri kao i glavni blockchain lanac. Također, ovo nagovještava da PVRB mora biti dio konsenzusa ako se mreža složi oko glavnog blockchaina, čak i ako se slaže i o jedinom fer rezultirajućem slučajnom odabiru. Ili, PVRB je jednostavno samostalni protokol implementiran putem pametnog ugovora koji radi asinhrono u odnosu na blockchain i blokove. Obje metode imaju svoje prednosti i nedostatke, a izbor između njih je krajnje netrivijalan.

Dva načina za implementaciju PVRB-a

Opišimo detaljnije dvije opcije za implementaciju PVRB-a - samostalnu verziju, koja radi pomoću pametnog ugovora neovisnog o blockchainu, i konsenzus integriranu verziju, ugrađenu u protokol, prema kojoj se mreža slaže oko blockchaina i transakcije koje treba uključiti. U svim slučajevima, mislit ću na popularne blockchain motore: Ethereum, EOS i sve slične njima po načinu na koji hostuju i obrađuju pametne ugovore.

Samostalni ugovor

U ovoj verziji, PVRB je pametni ugovor koji prihvata transakcije nasumičnih proizvođača (u daljem tekstu RP), obrađuje ih, kombinuje rezultate i, kao rezultat, dolazi do određene vrijednosti koju svaki korisnik može dobiti od ovog ugovora. Ova vrijednost ne može biti pohranjena direktno u ugovoru, već je predstavljena samo podacima iz kojih se može deterministički dobiti jedna i samo jedna vrijednost rezultirajućeg slučajnog odabira. U ovoj shemi, RP-ovi su korisnici blockchaina i svakome može biti dopušteno da učestvuje u procesu generiranja.

Opcija sa samostalnim ugovorom je dobra:

• prenosivost (ugovori se mogu prevući sa blockchaina na blockchain)
• jednostavnost implementacije i testiranja (ugovore je lako napisati i testirati)
• pogodnost u implementaciji ekonomskih šema (lako je napraviti svoj vlastiti token, čija logika služi svrsi PVRB-a)
• mogućnost pokretanja na već funkcionalnim blockchainima

Takođe ima i nedostatke:

• jaka ograničenja na računske resurse, volumen transakcije i pohranu (drugim riječima, cpu/mem/io)
• ograničenja poslovanja unutar ugovora (nisu sva uputstva dostupna, teško je povezati vanjske biblioteke)
• nemogućnost organiziranja razmjene poruka brže nego što su transakcije uključene u blockchain

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

Integrisan konsenzusom

U ovoj verziji, PVRB je implementiran u kodu blockchain čvora, ugrađen ili radi paralelno s razmjenom poruka između blockchain čvorova. Rezultati protokola se upisuju direktno u proizvedene blokove, a poruke protokola se šalju preko p2p mreže između čvorova. Budući da protokol rezultira brojevima koji se zapisuju u blokovima, mreža mora postići konsenzus o njima. To znači da PVRB poruke, kao i transakcije, moraju biti potvrđene od strane čvorova i uključene u blokove tako da svaki učesnik mreže može potvrditi usklađenost sa PVRB protokolom. To nas automatski dovodi do očiglednog rješenja - ako se mreža složi oko bloka i transakcija u njemu, onda bi PVRB trebao biti dio konsenzusa, a ne samostalni protokol. U suprotnom, moguće je da je blok validan sa stanovišta konsenzusa, ali se PVRB protokol ne poštuje i sa PVRB tačke gledišta blok ne može biti prihvaćen. Dakle, ako se odabere opcija „integrisana konsenzusom“, PVRB postaje važan dio konsenzusa.

Kada se opisuje PVRB implementacija na nivou mrežnog konsenzusa, nikako se ne može izbjeći pitanje 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 dužinu lanaca. A u EOS-u, na primjer, konačni su takozvani posljednji nepovratni blokovi, koji se pojavljuju u prosjeku na svaka 432 bloka (12*21 + 12*15, pre-vote + pre-commit). Ovaj proces u suštini čeka 2/3 potpisa proizvođača blokova (u daljem tekstu BP). Kada se pojave vilice koje su starije od posljednjeg LIB-a, one se jednostavno odbacuju. Ovaj mehanizam omogućava da se garantuje da je transakcija uključena u blockchain i da nikada neće biti vraćena, bez obzira na resurse napadača. Takođe, završni blokovi su blokovi potpisani od strane 2/3 BP u Hyperledger, Tendermint i drugim konsenzusima zasnovanim na pBFT-u. Takođe, ima smisla napraviti protokol za osiguranje konačnosti kao dodatak konsenzusu, jer može raditi asinhrono sa proizvodnjom i objavljivanjem blokova. Evo jednog dobrog članak o konačnosti u Ethereumu.

Konačnost je izuzetno važna za korisnike, koji se bez nje mogu naći žrtve „double potrošnje“ napada, gdje BP „drži“ blokove, i objavljuje ih nakon što mreža „vidi“ dobru transakciju. Ako nema konačnosti, tada objavljena viljuška zamjenjuje blok sa “dobrom” transakcijom drugom, iz “loše” fork-a, u kojoj se ista sredstva prenose na adresu napadača. U slučaju PVRB-a, zahtjevi za konačnost 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 najisplativiju, a ograničavanje vremena mogućeg napada je dobro rješenje.

Stoga je najbolja opcija kombinirati PVRB i finality u jedan protokol - tada finalizirani blok = finalizirani slučajni slučaj, a to je upravo ono što smo trebali dobiti. Sada će igrači dobiti zajamčeni slučajni slučaj za N sekundi i mogu biti sigurni da ga je nemoguće vratiti ili ponovo igrati.

Opcija integrirana konsenzusom je dobra:

• mogućnost asinhrone implementacije u odnosu na proizvodnju blokova - blokovi se proizvode kao i obično, ali paralelno s tim može raditi i PVRB protokol koji ne proizvodi slučajnost za svaki blok
• mogućnost implementacije čak i teške kriptografije, bez ograničenja nametnutih pametnim ugovorima
• mogućnost 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đe ima i nedostatke:

• Poteškoće u testiranju i razvoju - morat ćete emulirati mrežne greške, nedostajuće čvorove, mrežni hard fork
• Greške u implementaciji zahtijevaju mrežni hardfork

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

Blockchain, koji pruža transparentan i pouzdan kanal za razmjenu poruka, to ne čini besplatno. Svaki decentralizovani protokol mora uzeti u obzir mogućnost napada na Sybil; bilo koju radnju mogu izvršiti udružene snage više naloga, stoga je prilikom dizajniranja potrebno uzeti u obzir sposobnost napadača da kreira proizvoljan broj protokola. učesnici koji deluju u dosluhu.

PVRB i blok varijable.

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

Omiljeni način da dobijete slučajnost u blockchainu je da uzmete neku vrstu „nepredvidivih“ informacija iz bloka i napravite nasumične na osnovu njih - jednostavnim heširanjem jedne ili više vrijednosti. Dobar članak o problemima takvih shema ovdje. Možete uzeti bilo koju od "nepredvidivih" vrijednosti u bloku, na primjer, heš bloka, broj transakcija, složenost mreže i druge unaprijed nepoznate vrijednosti. Zatim ih heširajte, jedan ili više, i, u teoriji, trebali biste dobiti pravi slučajni odabir. Možete čak dodati na wihitepaper da je vaša shema “post-kvantno sigurna” (pošto postoje kvantno-dokazne hash funkcije :)).

Ali čak ni post-kvantno bezbedni heševi nisu dovoljni, nažalost. Tajna je u zahtjevima za PVRB, da vas podsjetim na njih iz prethodnog članka:

1. Rezultat mora imati dokazivo ujednačenu distribuciju, tj. biti zasnovan na dokazivo jakoj kriptografiji.
2. Nije moguće kontrolisati bilo koji od bitova rezultata. Kao posljedica toga, ishod se ne može unaprijed predvidjeti.
3. Ne možete sabotirati generacijski protokol tako što ne učestvujete u protokolu ili preopteretiti mrežu porukama napada
4. Sve navedeno mora biti otporno na dogovaranje dozvoljenog broja nepoštenih učesnika u protokolu (npr. 1/3 učesnika).

U ovom slučaju je ispunjen samo zahtjev 1, a nije ispunjen zahtjev 2. Heširanjem nepredvidivih vrijednosti iz bloka dobićemo ujednačenu distribuciju i dobre slučajne slučajeve. Ali BP barem ima opciju "objaviti blok ili ne". Dakle, BP može birati barem između DVIJE slučajne opcije: „svoju“ i onu koja će ispasti ako neko drugi blokira. BP može unaprijed da "pronjuška" šta će se dogoditi ako objavi blok, i jednostavno odluči hoće li to učiniti ili ne. Tako, kada igra, na primjer, "par-nepar" ili "crveno/crno" u ruletu, on može objaviti blok samo ako vidi pobjedu. Ovo takođe čini nefunkcionalnom strategiju korišćenja, na primer, heš bloka „iz budućnosti“. U ovom slučaju kažu da će se „koristiti slučajni odabir, koji se dobija heširanjem trenutnih podataka i hešom budućeg bloka visine, na primjer, N + 42, gdje je N trenutna visina bloka. Ovo malo pojačava šemu, ali i dalje omogućava BP-u, iako u budućnosti, da izabere hoće li zadržati blokadu ili objaviti.

BP softver u ovom slučaju postaje komplikovaniji, ali ne mnogo. Jednostavno, prilikom validacije i uključivanja transakcije u blok, postoji brza provjera da li će biti dobitka i, eventualno, odabir jednog parametara transakcije kako bi se dobila velika vjerovatnoća dobitka. Istovremeno, gotovo je nemoguće uhvatiti pametnog BP za takve manipulacije, svaki put možete koristiti nove adrese i osvajati malo po malo bez izazivanja sumnje.

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

PVRB i urezivanje-otkrivanje.

U redu, zahvaljujući heširanju i barem relativnoj nepredvidivosti heša bloka i drugih varijabli. Ako riješite problem prednjih rudara, trebali biste nabaviti nešto prikladnije. Dodajmo korisnike u ovu šemu - neka i oni utiču na slučajnost: svaki zaposlenik tehničke podrške će vam reći da je najsumičnija stvar u IT sistemima radnja korisnika :)

Naivna šema, kada korisnici jednostavno šalju nasumične brojeve, a rezultat se računa kao, na primjer, heš njihovog zbroja, nije prikladna. U ovom slučaju, posljednji igrač može, birajući svoj slučajni odabir, kontrolirati kakav će biti rezultat. Zbog toga se koristi vrlo široko korišteni obrazac urezivanja-otkrivanja. Učesnici prvo šalju hešove iz svojih nasumičnih (urezivanja), a zatim sami otvaraju nasumične (otkrivanje). Faza „otkrivanja“ počinje tek nakon što se prikupe potrebna urezivanja, tako da učesnici mogu poslati tačno onaj nasumični hash iz kojeg su poslali ranije. Sada da sve ovo spojimo sa parametrima bloka, i to bolje od onog koji je uzet iz budućnosti (slučajnost se može naći samo u jednom od budućih blokova), i voila - slučajnost je spremna! Sada bilo koji igrač utječe na rezultirajuću slučajnost i može "pobjediti" zlonamjerni BP tako što će ga nadjačati svojom, unaprijed nepoznatom, nasumičnošću... Možete dodati i zaštitu od sabotiranja protokola tako što ga ne otvarate u fazi otkrivanja - jednostavno tako što ćete zahtijevati da se određeni iznos primjenjuje na transakciju prilikom izvršenja — sigurnosni depozit, koji će biti vraćen samo tokom postupka otkrivanja. U ovom slučaju, obećanje i neotkrivanje bit će neisplativo.

Bio je to dobar pokušaj, a takve šeme postoje i u igraćim DApp-ovima, ali nažalost, to opet nije dovoljno. Sada ne samo rudar, već i bilo koji učesnik u protokolu može utjecati na rezultat. I dalje je moguće kontrolisati samu vrijednost, uz manje varijabilnosti i po cijeni, ali, kao u slučaju rudara, ako su rezultati izvlačenja vrijedniji od naknade za učešće u PVRB protokolu, onda će se slučajni -proizvođač (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 i ne otkriju, a ova šema će dobro doći. Njegova jednostavnost je ozbiljna prednost - ozbiljniji protokoli zahtijevaju mnogo moćnije proračune.

PVRB i deterministički potpisi.

Postoji još jedan način da se RP prisili da obezbijedi pseudo-slučajni broj na koji ne može utjecati ako mu se dodijeli “predslika” - ovo je deterministički potpis. Takav potpis je, na primjer, RSA, a nije ECS. Ako RP ima par ključeva: RSA i ECC, i on potpisuje određenu vrijednost svojim privatnim ključem, tada će u slučaju RSA dobiti JEDAN I SAMO JEDAN potpis, au slučaju ECS može generirati bilo koji broj različiti validni potpisi. To je zato što se prilikom kreiranja ECS potpisa koristi nasumični broj koji bira potpisnik, a može se izabrati na bilo koji način, dajući potpisniku mogućnost da odabere jedan od nekoliko potpisa. U slučaju RSA: “jedna ulazna vrijednost” + “jedan par ključeva” = “jedan potpis”. Nemoguće je predvidjeti koji će potpis dobiti drugi RP, pa se PVRB sa determinističkim potpisima može organizirati kombiniranjem RSA potpisa više učesnika koji su potpisali istu vrijednost. Na primjer, prethodni slučajni odabir. Ova šema štedi mnogo sredstava, jer potpisi su i potvrda ispravnog ponašanja prema protokolu i izvor nasumice.

Međutim, čak i sa determinističkim potpisima, shema je i dalje ranjiva na problem “posljednjeg aktera”. Posljednji sudionik još uvijek može odlučiti hoće li potpisati objaviti ili ne, čime kontrolira ishod. Možete modificirati shemu, dodati joj blok heševe, napraviti krugove tako da se rezultat ne može unaprijed predvidjeti, ali sve ove tehnike, čak i uzimajući u obzir mnoge modifikacije, i dalje ostavljaju neriješenim problem utjecaja jednog sudionika na kolektiv. rezultiraju nepouzdanim okruženjem i mogu 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 je izuzetno važan parametar. Očigledno ne postoji jednostavan način za rješavanje problema, idemo dalje.

PVRB i šeme dijeljenja tajnih podataka

U kriptografiji postoje šeme koje mogu omogućiti mreži da se dogovori oko jedne i samo jedne PVRB vrijednosti, dok su takve šeme otporne na bilo kakve zlonamjerne radnje nekih sudionika. Jedan koristan protokol s kojim se vrijedi upoznati je Shamirova shema dijeljenja tajne. Služi za podjelu tajne (na primjer, tajni ključ) na nekoliko dijelova i distribuciju ovih dijelova N učesnika. Tajna je raspoređena na način da je M dijelova od N dovoljno da se ona povrati, a to mogu biti bilo koji M dijelovi. Ako su na prstima, tada imajući graf nepoznate funkcije, učesnici razmjenjuju bodove na grafu, a nakon što dobiju M bodova, cijela funkcija se može vratiti.
Dato je dobro objašnjenje Wiki ali igranje s njim praktično da bi se puštao protokol u glavi je korisno za demo stranica.

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

• Svaki učesnik generiše sopstveni slučajni slučaj i distribuira udio od njega drugim učesnicima
• Svaki učesnik otkriva svoj dio tajni ostalih učesnika
• Ako učesnik ima više od M dionica, tada se broj ovog učesnika može izračunati i on će biti jedinstven, bez obzira na skup otkrivenih učesnika
• Kombinacija otkrivenih slučajnih izbora je željeni PVRB

Ovdje pojedini učesnik više ne utiče na rezultate protokola, osim u slučajevima kada postizanje praga otkrivanja slučajnosti zavisi isključivo od njega. Dakle, ovaj protokol, ako postoji potreban udio RP-ova koji rade na protokolu i koji su dostupni, radi, implementirajući zahtjeve za kriptografsku snagu i otporan je na problem “posljednjeg aktera”.

Ovo bi mogla biti idealna opcija, ova PVRB šema zasnovana na Fiat-Shamirovom tajnom dijeljenju je opisana na primjer u ovo članak. Ali, kao što je gore spomenuto, ako pokušate to direktno primijeniti u blockchainu, pojavljuju se tehnička ograničenja. Evo primjera probne implementacije protokola u EOS pametnom ugovoru i njegovog najvažnijeg dijela - provjere objavljenog share učesnika: kod. Iz koda možete vidjeti da validacija dokaza zahtijeva nekoliko skalarnih množenja, a brojevi koji se koriste su vrlo veliki. Treba shvatiti da se kod blockchaina verifikacija događa u trenutku kada proizvođač blokova obrađuje transakciju, i općenito, svaki sudionik mora lako provjeriti ispravnost protokola, tako da su zahtjevi za brzinu funkcije verifikacije vrlo ozbiljni . U ovoj opciji opcija se pokazala neefikasnom, jer se verifikacija nije uklapala u ograničenje transakcije (0.5 sekundi).

Efikasnost verifikacije jedan je od najvažnijih zahtjeva za korištenje, općenito, bilo koje napredne kriptografske sheme u blockchainu. Kreiranje dokaza, priprema poruka – ove procedure se mogu skinuti van lanca i izvoditi na računarima visokih performansi, ali verifikacija se ne može zaobići – ovo je još jedan važan zahtjev za PVRB.

PVRB i granični potpisi

Nakon što smo se upoznali sa shemom dijeljenja tajne, otkrili smo čitavu klasu protokola ujedinjenih ključnom riječi "prag". Kada obelodanjivanje neke informacije zahteva učešće M poštenih učesnika od N, a skup poštenih učesnika može biti proizvoljan podskup od N, govorimo o „graničnim“ šemama. Oni su ti koji nam dozvoljavaju da se pozabavimo problemom „posljednjeg aktera“, a ako napadač ne otkrije svoj dio tajne, to će umjesto njega učiniti drugi, pošteni učesnik. Ove šeme dozvoljavaju dogovor oko jednog i samo jednog značenja, čak i ako neki od učesnika sabotira protokol.

Kombinacija determinističkih potpisa i šema praga omogućila je razvoj vrlo zgodne i obećavajuće sheme za implementaciju PVRB - to su deterministički granični potpisi. Evo članak o različitim upotrebama graničnih potpisa, a evo još jednog dobrog longread od Dash.

Posljednji članak opisuje BLS potpise (BLS je skraćenica od Boneh-Lynn-Shacham, Evo članak), koji imaju vrlo važan i izuzetno pogodan kvalitet za programere - javni, tajni, javni ključevi i BLS potpisi mogu se međusobno kombinirati jednostavnim matematičkim operacijama, dok njihove kombinacije ostaju valjani ključevi i potpisi, što vam omogućava da lako agregirate mnoge 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 ovom kvalitetu, kombinacije BLS potpisa su same po sebi validni ključevi, što omogućava implementaciju opcije u kojoj M od N učesnika proizvodi jedan i samo jedan potpis koji je deterministički, javno provjerljiv i nepredvidiv dok ga ne otvori Mth. učesnik .

U šemi sa graničnim BLS potpisima, svaki učesnik nešto potpisuje koristeći BLS (na primjer, prethodni slučajni odabir), a zajednički granični potpis je željeni slučajni odabir. Kriptografska svojstva BLS potpisa zadovoljavaju zahtjeve za nasumični kvalitet, dio praga štiti od "posljednjeg aktera", a jedinstvena kombinacija ključeva omogućava implementaciju mnogo zanimljivijih algoritama koji omogućavaju, na primjer, efikasnu agregaciju protokolarnih poruka .

Dakle, ako gradite PVRB na svom blockchainu, najvjerovatnije ćete završiti sa BLS shemom graničnih potpisa, nekoliko projekata je već koristi. Na primjer, DFinity (ovdje benchmark koji implementira kolo, i ovdje primjer implementacije provjerljivog dijeljenja tajne), ili Keep.network (ovdje je njihov nasumični svjetionik žuti papir, ali primer 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, njihova tehnička primjena na postojeća rješenja nije laka. Za centralizovane sisteme, PVRB nema smisla, a decentralizovani su strogo ograničeni u svim računarskim resursima: CPU, memorija, skladište, I/O. Dizajniranje PVRB-a je kombinacija različitih protokola kako bi se stvorilo nešto što ispunjava sve zahtjeve za barem neki održivi blockchain. Jedan protokol izračunava efikasnije, ali zahtijeva više poruka između RP-ova, dok drugi zahtijeva vrlo malo poruka, ali stvaranje dokaza može biti zadatak koji traje desetine minuta, pa čak i sati.

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

• Kriptografska snaga. Vaš PVRB mora biti striktno nepristrasan, bez mogućnosti kontrole ni jednog bita. U nekim shemama to nije slučaj, pa pozovite kriptografa
• Problem "posljednjeg aktera".. Vaš PVRB mora biti otporan na napade gdje napadač koji kontrolira jedan ili više RP-ova može izabrati jedan od dva ishoda.
• Problem sabotaže protokola. Vaš PVRB mora biti otporan na napade u kojima napadač koji kontrolira jedan ili više RP-ova odlučuje hoće li biti nasumičan ili ne i može biti zagarantovan ili sa datom vjerovatnoćom da utiče na to
• Problem sa brojem poruka. Vaši RP-ovi bi trebali slati minimalan broj poruka u blockchain i izbjegavati sinhrone radnje koliko je to moguće, kao što su situacije poput „Poslao sam neke informacije, čekam odgovor od određenog sudionika“. U p2p mrežama, posebno geografski raspršenim, ne treba računati na brz odgovor
• Problem računske složenosti. Verifikacija bilo koje faze PVRB on-lanca bi trebala biti izuzetno laka, budući da je izvode svi puni klijenti mreže. Ako se implementacija vrši pomoću pametnog ugovora, onda su zahtjevi za brzinu vrlo strogi
• Problem pristupačnosti i životnosti. Vaš PVRB bi trebao nastojati da bude otporan na situacije u kojima dio mreže postane nedostupan na određeno vrijeme, a dio RP jednostavno prestane raditi
• Problem pouzdanog podešavanja i početne distribucije ključa. Ako vaš PVRB koristi primarnu postavku protokola, onda je ovo posebna velika i ozbiljna priča. Evo primer. Ako učesnici moraju jedni drugima reći svoje ključeve prije pokretanja protokola, to je također problem ako se promijeni sastav učesnika
• Razvojni problemi. Dostupnost biblioteka na traženim jezicima, njihova sigurnost i performanse, publicitet, složeni testovi itd.

Na primjer, granični BLS potpisi imaju značajan problem - prije početka rada, učesnici moraju podijeliti ključeve jedni drugima, organizirajući grupu unutar koje će prag raditi. To znači da će barem jedan krug razmjene u decentraliziranoj mreži morati pričekati, a s obzirom da je generirani rand, na primjer, neophodan u igricama, gotovo u realnom vremenu, to znači da je u ovoj fazi moguća sabotaža protokola , a prednosti šeme praga se gube. Ovaj problem je već jednostavniji od prethodnih, ali i dalje zahtijeva razvoj posebne procedure za formiranje graničnih grupa, koje će se morati ekonomski zaštititi, kroz depozite i povlačenje sredstava (slashing) od učesnika koji ne prate protokol. Također, BLS verifikacija s prihvatljivim nivoom sigurnosti jednostavno se ne uklapa, na primjer, u standardnu ​​EOS ili Ethereum transakciju - jednostavno nema dovoljno vremena za verifikaciju. Šifra ugovora je WebAssembly ili EVM, koju izvršava virtuelna mašina. Kriptografske funkcije nisu implementirane nativno (još) i rade desetine puta sporije od konvencionalnih kriptografskih biblioteka. Mnogi protokoli ne ispunjavaju zahtjeve jednostavno zasnovane na volumenu ključa, na primjer 1024 i 2048 bita za RSA, 4-8 puta veći od standardnog potpisa transakcije u Bitcoin-u i Ethereumu.

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

zaključak

Nadam se u prethodnom članak Uspio sam vas uvjeriti da je generiranje slučajnih brojeva na blockchainu ključno za mnoge aspekte života decentraliziranih mreža, a ovim člankom sam pokazao da je ovaj zadatak izuzetno ambiciozan i težak, ali dobra rješenja već postoje. Općenito, konačni dizajn protokola je moguć tek nakon provođenja masivnih testova koji uzimaju u obzir sve aspekte od podešavanja do emulacije greške, tako da je malo vjerovatno da ćete pronaći gotove recepte u timskim bijelim papirima i člancima, a mi sigurno nećemo odlučite u narednih godinu-dvije napišite “uradite to na ovaj način, tačno kako treba”.

Zbogom, za naš PVRB u blockchainu koji se razvija Haya, odlučili smo se na korištenje threshold BLS potpisa, planiramo implementirati PVRB na nivou konsenzusa, budući da verifikacija u pametnim ugovorima sa prihvatljivim nivoom sigurnosti još nije moguća. Moguće je da koristimo dvije sheme odjednom: prvo skupo dijeljenje tajne za kreiranje dugoročnog random_seed, a zatim ga koristimo kao osnovu za visokofrekventnu nasumično generiranje koristeći BLS potpise determinističkog praga, možda ćemo se ograničiti samo na jedna od šema. Nažalost, nemoguće je unaprijed reći kakav će biti protokol, jedino dobro je to što je, kao u nauci, 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. Da bismo ispunili poslovne zahtjeve, rješavamo specifičan praktični problem - obezbjeđivanje aplikacijama za igre pouzdanim izvorom entropije, tako da moramo obratiti pažnju i na sam blockchain, posebno na pitanja konačnosti lanca i upravljanja mrežom.

I iako još ne vidimo dokazano otporan PVRB u blockchain-u, koji bi se koristio dovoljno vremena da ga testiraju stvarne aplikacije, višestruke revizije, opterećenja i, naravno, stvarni napadi, ali broj mogućih puteva to potvrđuje rješenje postoji, a koji od ovih algoritama će na kraju riješiti problem. Rado ćemo podijeliti rezultate i zahvaliti ostalim timovima koji također rade na ovom pitanju na člancima i kodu koji omogućavaju inženjerima da ne stanu dvaput na iste grablje.

Dakle, kada sretnete programera koji dizajnira decentralizovano nasumično, budite pažljivi i brižni i pružite psihološku pomoć ako je potrebno :)

izvor: www.habr.com