Predstavitev

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

Tako kot pri konceptu absolutno močne šifre iz kriptografije se pravi protokoli »javno preverljivega naključnega svetilnika« (v nadaljevanju PVRB) samo poskušajo čim bolj približati idealni shemi, ker v realnih omrežjih ni uporabna v čisti obliki: dogovoriti se je treba strogo za en bit, krogov mora biti veliko, vsa sporočila morajo biti popolnoma hitra in vedno dostavljena. V realnih omrežjih seveda ni tako. Zato se pri oblikovanju PVRB-jev za specifične naloge v sodobnih verigah blokov poleg nezmožnosti nadzora posledične naključnosti in kriptografske trdnosti pojavljajo še številne čisto arhitekturne in tehnične težave.

Za PVRB je sama veriga blokov v bistvu komunikacijski medij, v katerem so sporočila = transakcije. To vam omogoča, da se delno abstrahirate od omrežnih težav, nedostave sporočil, težav z vmesno programsko opremo - vsa ta tveganja prevzame decentralizirano omrežje, njegova glavna vrednost za PVRB pa je nezmožnost preklica ali poškodovanja že poslane transakcije - to ne dovoli udeležencem, da zavrnejo sodelovanje v protokolu, razen če so izvedli uspešen napad na soglasje. Ta stopnja varnosti je sprejemljiva, zato mora biti PVRB odporen na tajno dogovarjanje udeležencev v popolnoma enaki meri kot glavna veriga blokov. To tudi namiguje, da mora biti PVRB del soglasja, če se omrežje strinja glede glavne verige blokov, tudi če se strinja tudi glede edinega poštenega naključnega rezultata. Ali pa je PVRB preprosto samostojen protokol, implementiran s pametno pogodbo, ki deluje asinhrono glede na verigo blokov in bloke. Obe metodi imata svoje prednosti in slabosti, izbira med njima pa je izjemno enostavna.

Dva načina implementacije PVRB

Naj podrobneje opišemo dve možnosti implementacije PVRB - samostojno različico, ki deluje s pametno pogodbo, neodvisno od blockchaina, in konsenzno integrirano različico, vgrajeno v protokol, po kateri se omrežje dogovori o blockchainu in transakcije, ki jih je treba vključiti. V vseh primerih bom mislil na priljubljene blockchain motorje: Ethereum, EOS in vse tiste, ki so jim podobni v načinu gostovanja in obdelave pametnih pogodb.

Samostojna pogodba

V tej različici je PVRB pametna pogodba, ki sprejme transakcije naključnih proizvajalcev (v nadaljevanju RP), jih obdela, združi rezultate in posledično pride do določene vrednosti, ki jo lahko vsak uporabnik prejme iz te pogodbe. Ta vrednost ne sme biti shranjena neposredno v pogodbi, ampak je lahko predstavljena le s podatki, iz katerih je mogoče deterministično pridobiti eno in samo eno vrednost nastalega naključja. V tej shemi so RP-ji uporabniki verige blokov in vsakomur se lahko dovoli sodelovanje v procesu generiranja.

Možnost s samostojno pogodbo je dobra:

• prenosljivost (pogodbe je mogoče povleči iz verige blokov v verigo blokov)
• enostavnost implementacije in testiranja (pogodbe je enostavno napisati in preizkusiti)
• udobje pri izvajanju ekonomskih shem (enostavno je izdelati lasten žeton, katerega logika služi namenom PVRB)
• možnost zagona na že delujočih verigah blokov

Ima tudi slabosti:

• močne omejitve glede računalniških virov, obsega transakcij in shranjevanja (z drugimi besedami, cpu/mem/io)
• omejitve pri poslovanju v okviru pogodbe (niso na voljo vsa navodila, oteženo povezovanje zunanjih knjižnic)
• nezmožnost organiziranja sporočanja hitreje, kot so transakcije vključene v verigo blokov

Ta možnost je primerna za implementacijo PVRB, ki ga je treba izvajati v obstoječem omrežju, ne vsebuje kompleksne kriptografije in ne zahteva velikega števila interakcij.

Integriran s soglasjem

V tej različici je PVRB implementiran v kodo vozlišča blockchain, vgrajen ali teče vzporedno z izmenjavo sporočil med vozlišči blockchain. Rezultati protokola so zapisani neposredno v proizvedene bloke, sporočila protokola pa se pošiljajo po omrežju p2p med vozlišči. Ker protokol povzroči številke, ki jih je treba zapisati v bloke, mora omrežje doseči soglasje o njih. To pomeni, da morajo sporočila PVRB, tako kot transakcije, potrditi vozlišča in vključiti v bloke, tako da lahko kateri koli udeleženec omrežja potrdi skladnost s protokolom PVRB. To nas samodejno pripelje do očitne rešitve – če se omrežje strinja s soglasjem o bloku in transakcijah v njem, potem mora biti PVRB del soglasja in ne samostojen protokol. V nasprotnem primeru je možno, da je blok veljaven s stališča soglasja, vendar se ne upošteva protokol PVRB in z vidika PVRB bloka ni mogoče sprejeti. Torej, če je izbrana možnost "integriranega s soglasjem", postane PVRB pomemben del soglasja.

Pri opisovanju izvedb PVRB na ravni soglasja omrežja se nikakor ne moremo izogniti vprašanjem dokončnosti. Dokončnost je mehanizem, ki se uporablja v determinističnih soglasjih, ki zaklene blok (in verigo, ki vodi do njega), ki je dokončen in ne bo nikoli zavržen, tudi če pride do vzporednega forka. Na primer, v Bitcoinu ni takega mehanizma - če objavite verigo večje kompleksnosti, bo nadomestila vsako manj kompleksno, ne glede na dolžino verig. In v EOS-u so na primer zadnji tako imenovani zadnji nepovratni bloki, ki se v povprečju pojavijo na vsakih 432 blokov (12*21 + 12*15, predhodno glasovanje + vnaprejšnja objava). Ta postopek v bistvu čaka na 2/3 podpisov proizvajalcev blokov (v nadaljnjem besedilu BP). Ko se pojavijo vilice, ki so starejše od zadnjega LIB, se preprosto zavržejo. Ta mehanizem omogoča jamstvo, da je transakcija vključena v verigo blokov in ne bo nikoli povrnjena nazaj, ne glede na vire, ki jih ima napadalec. Prav tako so zadnji bloki bloki, ki jih podpiše 2/3 BP v Hyperledgerju, Tendermintu in drugih soglasjih, ki temeljijo na pBFT. Prav tako je smiselno narediti protokol za zagotavljanje dokončnosti dodatek konsenzu, saj lahko deluje asinhrono s proizvodnjo in objavo blokov. Tukaj je dober članek o dokončnosti v Ethereumu.

Dokončnost je izjemno pomembna za uporabnike, ki se brez nje lahko znajdejo kot žrtve napada z dvojno porabo, kjer BP "drži" bloke in jih objavi, ko omrežje "vidi" dobro transakcijo. Če ni dokončnosti, potem objavljeni fork nadomesti blok z "dobro" transakcijo z drugim, iz "slabega" forka, v katerem se ista sredstva prenesejo na naslov napadalca. V primeru PVRB so zahteve po dokončnosti še strožje, saj gradnja vilic za PVRB pomeni možnost, da napadalec pripravi več naključnih možnosti, da bi objavil najbolj donosno, omejitev časa morebitnega napada pa je dobra rešitev.

Zato je najboljša možnost združiti PVRB in finality v en protokol - potem finalized block = finalized random in to je točno to, kar smo morali dobiti. Zdaj bodo igralci prejeli zajamčeno naključno igro v N sekundah in so lahko prepričani, da je nemogoče vrniti nazaj ali ponovno predvajati.

Možnost, integrirana s soglasjem, je dobra:

• možnost asinhrone izvedbe glede na proizvodnjo blokov - bloki se proizvajajo kot običajno, vendar vzporedno s tem lahko deluje protokol PVRB, ki ne proizvaja naključnosti za vsak blok
• zmožnost izvajanja celo zahtevne kriptografije, brez omejitev, ki veljajo za pametne pogodbe
• možnost organiziranja izmenjave sporočil hitreje, kot so transakcije vključene v verigo blokov, na primer, del protokola lahko deluje med vozlišči brez distribucije sporočil po omrežju

Ima tudi slabosti:

• Težave pri testiranju in razvoju - posnemati boste morali omrežne napake, manjkajoča vozlišča, omrežne hard forke
• Napake pri implementaciji zahtevajo hardfork omrežja

Obe metodi implementacije PVRB imata pravico do življenja, vendar je implementacija pametnih pogodb v sodobnih verigah blokov še vedno precej omejena v računalniških virih in vsak prehod na resno kriptografijo je pogosto preprosto nemogoč. In potrebovali bomo resno kriptografijo, kot bo prikazano spodaj. Čeprav je ta težava očitno začasna, je za rešitev številnih težav potrebna resna kriptografija v pogodbah in se postopoma pojavlja (na primer sistemske pogodbe za zkSNARK v Ethereumu)

Blockchain, ki zagotavlja pregleden in zanesljiv kanal za sporočanje protokolov, tega ne počne brezplačno. Vsak decentraliziran protokol mora upoštevati možnost napada Sybil; vsako dejanje lahko izvedejo usklajene sile več računov, zato je treba pri načrtovanju upoštevati zmožnost napadalcev, da ustvarijo poljubno število protokolov. udeležencev, ki delujejo v dogovoru.

PVRB in blokovne spremenljivke.

Nisem lagal, ko sem rekel, da še nihče ni implementiral dobrega PVRB, preizkušenega v številnih aplikacijah za igre na srečo, v verigah blokov. Od kod potem toliko aplikacij za igre na srečo na Ethereumu in EOS? To me preseneča enako kot vas, kje so dobili toliko "vztrajnih" naključij v popolnoma determinističnem okolju?

Najljubši način za pridobitev naključnosti v verigi blokov je, da iz bloka vzamete nekakšne "nepredvidljive" informacije in na njihovi podlagi naredite naključne informacije - preprosto z zgoščevanjem ene ali več vrednosti. Dober članek o težavah takih shem tukaj. V bloku lahko vzamete katero koli od "nepredvidljivih" vrednosti, na primer zgoščeno vrednost bloka, število transakcij, kompleksnost omrežja in druge vnaprej neznane vrednosti. Nato jih zgostite, enega ali več, in v teoriji bi morali dobiti pravo naključje. V wihitepaper lahko celo dodate, da je vaša shema "postkvantno varna" (saj obstajajo kvantno odporne zgoščevalne funkcije :)).

Toda tudi post-kvantno varne zgoščene vrednosti niso dovolj, žal. Skrivnost je v zahtevah za PVRB, naj vas spomnim nanje iz prejšnjega članka:

1. Rezultat mora imeti dokazljivo enakomerno porazdelitev, tj. temeljiti mora na dokazljivo močni kriptografiji.
2. Ni mogoče nadzorovati nobenega bita rezultata. Posledično izida ni mogoče vnaprej predvideti.
3. Generacijskega protokola ne morete sabotirati tako, da ne sodelujete pri protokolu ali da preobremenite omrežje z napadalnimi sporočili
4. Vse našteto mora biti odporno na dogovarjanje dovoljenega števila nepoštenih udeležencev protokola (npr. 1/3 udeležencev).

V tem primeru je izpolnjena samo zahteva 1, zahteva 2 pa ni izpolnjena. Z zgoščevanjem nepredvidljivih vrednosti iz bloka bomo dobili enakomerno porazdelitev in dobre naključne vrednosti. Toda BP ima vsaj možnost "objaviti blok ali ne." Tako lahko BP izbira vsaj med DVEMI naključnimi možnostmi: »svojo« in tisto, ki se bo izkazala, če blokira nekdo drug. BP lahko vnaprej "vohlja", kaj se bo zgodilo, če objavi blok, in se preprosto odloči, ali bo to storil ali ne. Tako lahko pri igranju na primer "sodo-liho" ali "rdeče/črno" v ruleti objavi blok le, če vidi dobitek. Zaradi tega tudi strategija uporabe, na primer, zgoščenega bloka "iz prihodnosti" ni izvedljiva. V tem primeru pravijo, da bo »uporabljen naključni, ki ga dobimo z zgoščevanjem trenutnih podatkov in zgoščevanja bodočega bloka z višino na primer N + 42, kjer je N trenutna višina bloka. To nekoliko okrepi shemo, vendar še vedno omogoča BP, čeprav v prihodnosti, da izbere, ali bo zadržal blok ali objavil.

Programska oprema BP v tem primeru postane bolj zapletena, vendar ne veliko. Preprosto, pri preverjanju in vključitvi transakcije v blok je na voljo hitra kontrola, ali bo prišlo do dobitka, in po možnosti izbira parametrov ene transakcije za pridobitev visoke verjetnosti dobitka. Hkrati je skoraj nemogoče ujeti pametnega BP za takšne manipulacije, vsakič, ko lahko uporabite nove naslove in malo po malo zmagate, ne da bi vzbudili sum.

Torej metode, ki uporabljajo informacije iz bloka, niso primerne kot univerzalna izvedba PVRB. V omejeni različici, z omejitvami glede velikosti stav, omejitvami glede števila igralcev in/ali registracijo KYC (da enemu igralcu preprečite uporabo več naslovov), lahko te sheme delujejo za majhne igre, vendar nič več.

PVRB in commit-reveal.

V redu, zahvaljujoč zgoščevanju in vsaj relativni nepredvidljivosti zgoščevanja bloka in drugih spremenljivk. Če rešite problem naprednih rudarjev, bi morali dobiti nekaj primernejšega. Dodajmo uporabnike v to shemo - naj tudi oni vplivajo na naključnost: vsak zaposleni v tehnični podpori vam bo povedal, da so najbolj naključna stvar v IT sistemih dejanja uporabnikov :)

Naivna shema, ko uporabniki preprosto pošljejo naključna števila, rezultat pa se izračuna kot na primer zgoščena vrednost njihove vsote, ni primerna. V tem primeru lahko zadnji igralec z lastno naključno izbiro nadzira, kakšen bo rezultat. Zato se uporablja zelo razširjen vzorec commit-reveal. Udeleženci najprej pošljejo zgoščene vrednosti iz svojih naključij (commits), nato pa jih sami odprejo (reveals). Faza »razkritja« se začne šele, ko so zbrane potrebne objave, tako da lahko udeleženci pošljejo natanko tisto naključno zgoščeno vrednost, iz katere so poslali prej. Sedaj pa sestavimo vse to skupaj s parametri bloka, bolje kot tistega, vzetega iz prihodnosti (naključnost je mogoče najti samo v enem od prihodnjih blokov), in voila - naključnost je pripravljena! Zdaj kateri koli igralec vpliva na posledično naključnost in lahko »premaga« zlonamerni BP tako, da ga preglasi z lastno, vnaprej neznano naključnostjo ... Prav tako lahko dodate zaščito pred sabotažo protokola, tako da ga ne odprete na stopnji razkritja - preprosto z zahtevo, da se transakciji pri izvršitvi priloži določen znesek — varščina, ki bo vrnjena šele med postopkom razkritja. V tem primeru bo zaveza in nerazkritje nedonosno.

To je bil dober poskus in takšne sheme obstajajo tudi v igralnih DApps, a žal, to spet ni dovolj. Zdaj lahko na rezultat vpliva ne le rudar, ampak tudi kateri koli udeleženec protokola. Še vedno je mogoče nadzorovati samo vrednost, z manj variabilnosti in s stroški, vendar, tako kot v primeru rudarja, če so rezultati žrebanja dragocenejši od pristojbine za sodelovanje v protokolu PVRB, potem naključni -proizvajalec (RP) se lahko odloči, ali bo razkril, in še vedno lahko izbira med vsaj dvema naključnima možnostma.
Toda postalo je mogoče kaznovati tiste, ki se zavežejo in ne razkrijejo, in ta shema bo prišla prav. Njegova preprostost je resna prednost - resnejši protokoli zahtevajo veliko močnejše izračune.

PVRB in deterministični podpisi.

Obstaja še en način, kako prisiliti RP, da zagotovi psevdo-naključno število, na katerega ne more vplivati, če ima "predsliko" - to je deterministični podpis. Takšen podpis je na primer RSA in ni ECS. Če ima RP par ključev: RSA in ECC in s svojim zasebnim ključem podpiše določeno vrednost, potem bo v primeru RSA dobil EN IN SAMO EN podpis, v primeru ECS pa lahko ustvari poljubno število različni veljavni podpisi. To je zato, ker se pri ustvarjanju podpisa ECS uporablja naključna številka, ki jo izbere podpisnik in jo je mogoče izbrati na poljuben način, kar podpisniku daje možnost, da izbere enega izmed več podpisov. V primeru RSA: "ena vhodna vrednost" + "en par ključev" = "en podpis". Nemogoče je predvideti, kakšen podpis bo dobil drug RP, zato je PVRB z determinističnimi podpisi mogoče organizirati s kombiniranjem podpisov RSA več udeležencev, ki so podpisali isto vrednost. Na primer prejšnji naključni. Ta shema prihrani veliko sredstev, saj podpisi so hkrati potrditev pravilnega vedenja v skladu s protokolom in vir naključnosti.

Toda tudi z determinističnimi podpisi je shema še vedno občutljiva na problem "zadnjega akterja". Zadnji udeleženec se lahko še vedno odloči, ali bo podpis objavil ali ne, in tako nadzoruje izid. Shemo lahko spreminjate, ji dodajate zgoščene bloke, delate kroge, tako da rezultata ni mogoče vnaprej predvideti, vendar vse te tehnike, tudi ob upoštevanju številnih sprememb, še vedno puščajo nerešen problem vpliva enega udeleženca na kolektiv. povzroči nezaupljivo okolje in lahko deluje samo v gospodarskih in časovnih omejitvah. Poleg tega je velikost ključev RSA (1024 in 2048 bitov) precej velika, velikost za transakcije v verigi blokov pa je izjemno pomemben parameter. Očitno ni preprostega načina za rešitev problema, pojdimo naprej.

PVRB in sheme za skupno rabo skrivnosti

V kriptografiji obstajajo sheme, ki omogočajo, da se omrežje dogovori za eno in samo eno vrednost PVRB, medtem ko so takšne sheme odporne na morebitna zlonamerna dejanja nekaterih udeležencev. En uporaben protokol, s katerim se je vredno seznaniti, je Shamirjeva shema za skupno rabo skrivnosti. Služi za razdelitev skrivnosti (npr. skrivnega ključa) na več delov in te dele razdeli na N udeležencev. Skrivnost je porazdeljena tako, da je M delov od N dovolj za njeno pridobitev in to je lahko poljubnih M delov. Če so na prstih, potem imajo graf neznane funkcije, udeleženci izmenjajo točke na grafu in po prejemu M točk je mogoče obnoviti celotno funkcijo.
Podana je dobra razlaga wiki vendar je praktično igranje z njim za predvajanje protokola v vaši glavi koristno za demo strani.

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

• Vsak udeleženec ustvari svoj naključni izbor in iz njega razdeli deleže drugim udeležencem
• Vsak udeleženec razkrije svoj del skrivnosti drugih udeležencev
• Če ima udeleženec več kot M delnic, se lahko izračuna število tega udeleženca, ki bo edinstveno, ne glede na nabor razkritih udeležencev.
• Kombinacija razkritih naključij je želeni PVRB

Pri tem posamezni udeleženec ne vpliva več na rezultate protokola, razen v primerih, ko je doseganje praga razkritja naključnosti odvisno izključno od njega. Zato ta protokol, če obstaja zahtevani delež RP-jev, ki delajo na protokolu in so na voljo, deluje, izvaja zahteve za kriptografsko trdnost in je odporen na problem "zadnjega igralca".

To bi lahko bila idealna možnost, ta shema PVRB, ki temelji na delitvi skrivnosti Fiat-Shamir, je opisana na primer v to Članek. Toda, kot je bilo omenjeno zgoraj, se pojavijo tehnične omejitve, če ga poskušate neposredno uporabiti v verigi blokov. Tukaj je primer testne implementacije protokola v pametni pogodbi EOS in njen najpomembnejši del - preverjanje objavljenega delniškega udeleženca: koda. Iz kode lahko vidite, da preverjanje dokazov zahteva več skalarnih množenj, uporabljena števila pa so zelo velika. Treba je razumeti, da se v verigah blokov preverjanje zgodi v trenutku, ko proizvajalec blokov obdela transakcijo, na splošno pa mora vsak udeleženec zlahka preveriti pravilnost protokola, zato so zahteve glede hitrosti funkcije preverjanja zelo resne. . Pri tej možnosti se je možnost izkazala za neučinkovito, saj preverjanje ni ustrezalo omejitvi transakcije (0.5 sekunde).

Učinkovitost preverjanja je ena najpomembnejših zahtev za uporabo na splošno vseh naprednih kriptografskih shem v verigi blokov. Ustvarjanje dokazov, priprava sporočil - te postopke je mogoče odstraniti iz verige in izvesti na visoko zmogljivih računalnikih, vendar preverjanja ni mogoče zaobiti - to je še ena pomembna zahteva za PVRB.

PVRB in mejni podpisi

Ko smo se seznanili s shemo delitve skrivnosti, smo odkrili cel razred protokolov, ki jih združuje ključna beseda »prag«. Kadar je za razkritje neke informacije potrebno sodelovanje M poštenih udeležencev od N, nabor poštenih udeležencev pa je lahko poljubna podmnožica N, govorimo o "pragovih" shemah. Prav oni nam omogočajo, da se spopademo s problemom »zadnjega igralca«, zdaj, če napadalec ne razkrije svojega dela skrivnosti, bo to namesto njega storil drug, pošten udeleženec. Te sheme omogočajo dogovor o enem in samo enem pomenu, tudi če protokol sabotirajo nekateri udeleženci.

Kombinacija determinističnih podpisov in pragovnih shem je omogočila razvoj zelo priročne in obetavne sheme za implementacijo PVRB - to so deterministični pragovi. Tukaj članek o različnih uporabah pragovnih podpisov in tukaj je še en dober longread od Dash.

Zadnji članek opisuje podpise BLS (BLS je kratica za Boneh-Lynn-Shacham, glej člen), ki imajo zelo pomembno in izjemno priročno lastnost za programerje - javne, skrivne, javne ključe in podpise BLS je mogoče kombinirati med seboj z uporabo preprostih matematičnih operacij, medtem ko njihove kombinacije ostanejo veljavni ključi in podpisi, kar vam omogoča enostavno združevanje številnih podpisov v enega in več javnih ključev v enega. Prav tako so deterministični in dajejo enak rezultat za iste vhodne podatke. Zahvaljujoč tej kakovosti so kombinacije podpisov BLS same po sebi veljavni ključi, kar omogoča izvedbo možnosti, pri kateri M od N udeležencev ustvari en in samo en podpis, ki je determinističen, javno preverljiv in nepredvidljiv, dokler ga ne odpre Mth udeleženec .

V shemi s podpisi praga BLS vsak udeleženec nekaj podpiše z uporabo BLS (na primer prejšnji naključni), skupni podpis praga pa je želeni naključni podpis. Kriptografske lastnosti podpisov BLS izpolnjujejo zahteve po naključni kakovosti, pragovni del ščiti pred "zadnjim akterjem", edinstvena združljivost ključev pa omogoča implementacijo veliko več zanimivih algoritmov, ki omogočajo na primer učinkovito združevanje protokolarnih sporočil. .

Torej, če gradite PVRB na vaši verigi blokov, boste najverjetneje končali s shemo podpisov praga BLS, več projektov jo že uporablja. Na primer DFinity (tukaj merilo uspešnosti, ki izvaja vezje, in tukaj primer izvedbe preverljive skupne rabe skrivnosti) ali Keep.network (tukaj je njihov naključni svetilnik rumeni papir, Pa Primer pametna pogodba, ki služi protokolu).

Implementacija PVRB

Na žalost še vedno ne vidimo že pripravljenega protokola, implementiranega v verige blokov PVRB, ki bi dokazal svojo varnost in stabilnost. Čeprav so sami protokoli pripravljeni, njihova tehnična uporaba na obstoječih rešitvah ni enostavna. Za centralizirane sisteme PVRB ni smiseln, decentralizirani pa so strogo omejeni v vseh računalniških virih: CPE, pomnilnik, shranjevanje, I/O. Oblikovanje PVRB je kombinacija različnih protokolov, da bi ustvarili nekaj, kar izpolnjuje vse zahteve za vsaj nekaj uspešnega blockchaina. En protokol računa učinkoviteje, vendar zahteva več sporočil med RP-ji, medtem ko drugi zahteva zelo malo sporočil, vendar je ustvarjanje dokaza lahko opravilo, ki traja več deset minut ali celo ur.

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

• Kriptografska moč. Vaš PVRB mora biti popolnoma nepristranski, brez možnosti nadzora enega bita. V nekaterih shemah temu ni tako, zato pokličite kriptografa
• Problem "zadnjega igralca".. Vaš PVRB mora biti odporen na napade, kjer lahko napadalec, ki nadzoruje enega ali več RP-jev, izbere enega od dveh rezultatov.
• Problem sabotaže protokola. Vaš PVRB mora biti odporen na napade, pri katerih se napadalec, ki nadzoruje enega ali več RP-jev, odloči, ali bo naključen ali ne, in lahko zajamčeno ali z dano verjetnostjo vpliva na to
• Težava s številom sporočil. Vaši RP-ji bi morali pošiljati najmanj sporočil v verigo blokov in se čim bolj izogibati sinhronim dejanjem, kot so situacije, kot je "Poslal sem nekaj informacij, čakam na odgovor določenega udeleženca." V p2p omrežjih, še posebej geografsko razpršenih, ne smete računati na hiter odziv
• Problem računske kompleksnosti. Preverjanje katere koli stopnje PVRB v verigi bi moralo biti izjemno enostavno, saj ga izvajajo vsi polnopravni odjemalci omrežja. Če je implementacija izvedena s pametno pogodbo, so zahteve glede hitrosti zelo stroge
• Problem dostopnosti in živosti. Vaš PVRB bi moral biti odporen na situacije, ko del omrežja za nekaj časa postane nedosegljiv in del RP preprosto preneha delovati
• Težava zaupanja vredne nastavitve in začetne distribucije ključev. Če vaš PVRB uporablja primarno nastavitev protokola, potem je to ločena velika in resna zgodba. Tukaj Primer. Če morajo udeleženci drug drugemu povedati svoje ključe pred začetkom protokola, je to tudi problem, če se spremeni sestava udeležencev
• Razvojne težave. Razpoložljivost knjižnic v zahtevanih jezikih, njihova varnost in zmogljivost, obveščanje javnosti, kompleksni testi itd.

Na primer, pragovi BLS podpisi imajo veliko težavo - preden začnejo delati, morajo udeleženci razdeliti ključe drug drugemu in organizirati skupino, znotraj katere bo prag deloval. To pomeni, da bo treba počakati vsaj na en krog izmenjave v decentraliziranem omrežju, in glede na to, da je generirani rand, na primer, potreben v igrah, skoraj v realnem času, to pomeni, da je na tej stopnji možna sabotaža protokola. in izgubijo se prednosti sheme pragov. Ta problem je že enostavnejši od prejšnjih, vendar še vedno zahteva razvoj ločenega postopka za oblikovanje pragovnih skupin, ki jih bo treba ekonomsko zaščititi z vplačili in dvigi sredstev (slashing) od udeležencev, ki ne upoštevajo protokol. Tudi preverjanje BLS s sprejemljivo stopnjo varnosti preprosto ne ustreza, na primer, standardni transakciji EOS ali Ethereum - preprosto ni dovolj časa za preverjanje. Koda pogodbe je WebAssembly ali EVM, ki jo izvaja virtualni stroj. Kriptografske funkcije (še) niso izvorno implementirane in delujejo desetkrat počasneje kot običajne kriptografske knjižnice. Številni protokoli ne izpolnjujejo zahtev zgolj na podlagi količine ključa, na primer 1024 in 2048 bitov za RSA, kar je 4–8-krat več kot standardni podpis transakcije v Bitcoinu in Ethereumu.

Prisotnost implementacij v različnih programskih jezikih ima tudi vlogo - ki jih je malo, zlasti za nove protokole. Možnost z integracijo v consensus zahteva pisanje protokola v jeziku platforme, zato boste morali iskati kodo v Go za geth, v Rust za Parity, v C++ za EOS. Vsi bodo morali poiskati kodo JavaScript in ker JavaScript in kriptografija nista posebej tesna prijatelja, bo pomagal WebAssembly, ki zdaj zagotovo trdi, da je naslednji pomemben internetni standard.

Zaključek

Upam, da v prejšnji članek Uspelo mi je prepričati vas, da je generiranje naključnih števil na blockchainu ključnega pomena za številne vidike življenja decentraliziranih omrežij, s tem člankom pa sem pokazal, da je ta naloga izjemno ambiciozna in težka, vendar dobre rešitve že obstajajo. Na splošno je končna zasnova protokola mogoča šele po izvedbi obsežnih testov, ki upoštevajo vse vidike od namestitve do emulacije napak, zato je malo verjetno, da boste našli pripravljene recepte v belih knjigah in člankih skupine, mi pa jih zagotovo ne bomo odločite se v naslednjem letu ali dveh, napišite "naredi tako, točno tako."

Adijo, za naš PVRB v blockchainu, ki se razvija Haya, odločili smo se za uporabo pragovnih BLS podpisov, načrtujemo implementacijo PVRB na konsenzni ravni, saj preverjanje v pametnih pogodbah s sprejemljivo stopnjo varnosti še ni možno. Možno je, da uporabimo dve shemi hkrati: najprej drago tajno deljenje za ustvarjanje dolgoročnega random_seed, nato pa ga uporabimo kot osnovo za visokofrekvenčno naključno generiranje z uporabo determinističnih pragov BLS podpisov, morda se bomo omejili le na ena od shem. Žal je vnaprej nemogoče povedati, kakšen bo protokol, edina dobra stvar je, da je tako kot v znanosti tudi pri inženirskih problemih negativen rezultat rezultat in je vsak nov poskus rešitve problema še en korak za raziskovanje vseh, ki so vpleteni v problem. Za izpolnjevanje poslovnih zahtev rešujemo specifičen praktični problem - zagotavljanje igralnim aplikacijam zanesljivega vira entropije, zato moramo biti pozorni tudi na samo verigo blokov, predvsem na vprašanja končnosti verige in upravljanja omrežja.

In čeprav v verigah blokov še ne vidimo dokazano odpornega PVRB, ki bi se uporabljal dovolj časa za testiranje z resničnimi aplikacijami, večkratnimi revizijami, obremenitvami in seveda resničnimi napadi, pa število možnih poti potrjuje, da rešitev obstaja in kateri od teh algoritmov bo na koncu rešil problem. Z veseljem bomo delili rezultate in se zahvalili drugim ekipam, ki se prav tako ukvarjajo s to problematiko, za članke in kodo, ki inženirjem omogočajo, da ne stopijo dvakrat na iste grablje.

Torej, ko srečate programerja, ki načrtuje decentralizirano naključje, bodite pozorni in skrbni ter po potrebi zagotovite psihološko pomoč :)

Vir: www.habr.com