{"id":33888,"date":"2019-10-31T21:55:15","date_gmt":"2019-10-31T18:55:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\/"},"modified":"2019-10-31T21:55:15","modified_gmt":"2019-10-31T18:55:15","slug":"sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","title":{"rendered":"Numere aleatorii \u0219i re\u021bele decentralizate: implement\u0103ri","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1 id=\"vvedenie\">Introducere<\/h1>\n<p><\/p>\n<pre><code class=\"plaintext\">function getAbsolutelyRandomNumer() {\n        return 4; \/\/ returns absolutely random number!\n}<\/code><\/pre>\n<p><\/p>\n<p>La fel ca \u00een cazul conceptului de criptare absolut rezistent\u0103 din criptografie, protocoalele reale \u201ePublicly Verifiable Random Beacon\u201d (PVRB) \u00eencearc\u0103 doar s\u0103 se apropie c\u00e2t mai mult de schema ideal\u0103, deoarece \u00een re\u021belele reale aceasta nu poate fi aplicat\u0103 \u00een form\u0103 pur\u0103: trebuie s\u0103 ne \u00een\u021belegem strict asupra unui singur bit, trebuie s\u0103 fie multe runde, iar toate mesajele trebuie s\u0103 fie perfect rapide \u0219i s\u0103 fie livrate \u00eentotdeauna. Evident, \u00een re\u021belele reale nu este a\u0219a. Prin urmare, \u00een proiectarea PVRB pentru sarcini specifice \u00een blockchain-urile moderne, pe l\u00e2ng\u0103 imposibilitatea de a controla randomul ob\u021binut \u0219i rezisten\u021ba criptografic\u0103, apar multe probleme pur arhitecturale \u0219i tehnice.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>\u00censu\u0219i blockchain-ul reprezint\u0103 pentru PVRB, \u00een esen\u021b\u0103, un mediu de comunicare \u00een care mesajele sunt tranzac\u021bii. Acest lucru permite o par\u021bial\u0103 abstractizare de la problemele de re\u021bea, ne\u00eenceperea mesajelor, problemele software-ului intermediar \u2014 toate aceste riscuri sunt asumate de re\u021beaua descentralizat\u0103, iar cea mai mare valoare pentru PVRB este imposibilitatea de a retracta sau distruge o tranzac\u021bie deja trimis\u0103 \u2014 acest lucru \u00eempiedic\u0103 participan\u021bii s\u0103 se retrag\u0103 din protocol, cu excep\u021bia cazului \u00een care au efectuat un atac de succes asupra consensului. Acest nivel de securitate este acceptabil, astfel c\u0103 PVRB trebuie s\u0103 fie rezistent la conspir\u0103rile participan\u021bilor la aceea\u0219i m\u0103sur\u0103 ca \u0219i lan\u021bul principal al blockchain-ului. De asemenea, aceasta sugereaz\u0103 c\u0103 PVRB trebuie s\u0103 fie parte din consens, dac\u0103 re\u021beaua s-a \u00een\u021beles cu privire la lan\u021bul principal de blocuri, l\u0103s\u00e2ndu-se \u00een acela\u0219i timp s\u0103 se \u00een\u021beleag\u0103 \u0219i cu privire la singurul random rezultat onest. Sau, PVRB este pur \u0219i simplu un protocol standalone, realizat printr-un smart contract, func\u021bion\u00e2nd asincron \u00een raport cu blockchain-ul \u0219i blocurile. Ambele metode au avantajele \u0219i dezavantajele lor, iar alegerea \u00eentre ele este extrem de non-trivial\u0103. <\/p>\n<p><\/p>\n<h2 id=\"dva-sposoba-implementacii-pvrb\">Cele dou\u0103 moduri de implementare a PVRB<\/h2>\n<p><\/p>\n<p>Vom descrie mai \u00een detaliu cele dou\u0103 variante de implementare a PVRB \u2014 versiunea standalone, care func\u021bioneaz\u0103 prin utilizarea unui smart contract independent de blockchain, \u0219i varianta integrat\u0103 \u00een consens \u2014 \u00eencorporat\u0103 \u00een protocolul conform c\u0103ruia re\u021beaua se \u00een\u021belege cu privire la lan\u021bul de blocuri \u0219i tranzac\u021biile incluse. \u00cen toate cazurile, voi avea \u00een vedere motoare blockchain populare: Ethereum, EOS \u0219i toate cele care sunt similare cu ele \u00een ceea ce prive\u0219te plasarea \u0219i procesarea smart contractelor. <\/p>\n<p><\/p>\n<h3 id=\"standalone-contract\">Contract independent<\/h3>\n<p><\/p>\n<p>\u00cen aceast\u0103 variant\u0103, PVRB reprezint\u0103 un contract inteligent care accept\u0103 tranzac\u021biile produc\u0103torilor random (denumi\u021bi ulterior RP), le proceseaz\u0103, combin\u0103 rezultatele \u0219i, \u00een final, ajunge la o anumit\u0103 valoare, pe care oricare utilizator o poate ob\u021bine din acest contract. Aceast\u0103 valoare nu este neap\u0103rat stocat\u0103 direct \u00een contract, ci poate fi reprezentat\u0103 doar prin datele din care se poate determina clar o singur\u0103 valoare a rezultatului aleatoriu. \u00cen aceast\u0103 schem\u0103, RP sunt utilizatorii blockchain-ului \u0219i se poate permite oricui s\u0103 participe la procesul de generare.<\/p>\n<p><\/p>\n<p>Varianta cu contract independent este bun\u0103:<\/p>\n<p><\/p>\n<ul>\n<li>portabilitate (contractele pot fi mutate dintr-un blockchain \u00een altul)<\/li>\n<li>simplitatea implement\u0103rii \u0219i test\u0103rii (contractele sunt u\u0219or de scris \u0219i testat)<\/li>\n<li>convenien\u021ba \u00een implementarea schemelor economice (este simplu s\u0103 creezi un token, a c\u0103rui logic\u0103 serve\u0219te scopurilor PVRB)<\/li>\n<li>posibilitatea de a fi lansat \u00een blockchain-uri deja func\u021bionale<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00cen acela\u0219i timp, are \u0219i dezavantaje:<\/p>\n<p><\/p>\n<ul>\n<li>restric\u021bii severe asupra resurselor \u00een timpul calculului, volumului de tranzac\u021bii \u0219i stocare (\u00een termeni simpli, cpu\/mem\/io)<\/li>\n<li>restric\u021bii asupra opera\u021biunilor din interiorul contractului (nu toate instruc\u021biunile sunt disponibile, este greu s\u0103 conectezi biblioteci externe)<\/li>\n<li>imposibilitatea de a organiza comunicarea mai repede dec\u00e2t tranzac\u021biile sunt incluse \u00een blockchain<\/li>\n<\/ul>\n<p><\/p>\n<p>Aceast\u0103 variant\u0103 este potrivit\u0103 pentru implementarea PVRB, care trebuie s\u0103 fie lansat\u0103 \u00eentr-o re\u021bea existent\u0103, f\u0103r\u0103 criptografie complex\u0103 \u0219i care nu necesit\u0103 multe interac\u021biuni.<\/p>\n<p><\/p>\n<h3 id=\"consensus-integrated\">Integrat \u00een consens<\/h3>\n<p><\/p>\n<p>\u00cen aceast\u0103 variant\u0103, PVRB este implementat \u00een codul nodului blockchain, fiind integrat sau lucr\u00e2nd paralel cu schimbul de mesaje \u00eentre nodurile blockchain-ului. Rezultatele protocolului sunt \u00eenregistrate direct \u00een blocurile produse, iar mesajele protocolului sunt trimise prin re\u021beaua p2p \u00eentre noduri. Deoarece protocolul genereaz\u0103 numere care trebuie \u00eenregistrate \u00een blocuri, re\u021beaua trebuie s\u0103 ajung\u0103 la consens asupra acestora. Asta \u00eenseamn\u0103 c\u0103 mesajele PVRB, la fel ca tranzac\u021biile, trebuie s\u0103 fie validate de noduri \u0219i incluse \u00een blocuri, pentru ca orice participant al re\u021belei s\u0103 poat\u0103 valida respectarea protocolului PVRB. Aceasta ne conduce \u00een mod automat la o solu\u021bie evident\u0103 \u2014 dac\u0103 re\u021beaua ajunge la un consens asupra blocului \u0219i a tranzac\u021biilor din acesta, atunci PVRB trebuie s\u0103 fac\u0103 parte din consens, nu s\u0103 fie un protocol separat. Altfel, ar putea ap\u0103rea situa\u021bia \u00een care blocul este valid din perspectiva consensului, dar protocolul PVRB nu este respectat, iar din perspectiva PVRB, blocul nu poate fi acceptat. A\u0219adar, dac\u0103 este ales varianta \u201econsensus-integrated\u201d, PVRB devine o parte important\u0103 a consensului.<\/p>\n<p><\/p>\n<p>Descriind implement\u0103rile PVRB la nivel de consens \u00een re\u021bea, nu se poate ocoli deloc problema finalit\u0103\u021bii. Finalitatea este un mecanism utilizat \u00een consensurile deterministe, care fixeaz\u0103 un bloc (\u0219i lan\u021bul care duce la acesta) ca fiind final, \u0219i care nu va fi niciodat\u0103 eliminat, chiar dac\u0103 apare un fork paralel. De exemplu, \u00een Bitcoin nu exist\u0103 un asemenea mecanism \u2014 dac\u0103 se public\u0103 un lan\u021b cu o complexitate mai mare, acesta va \u00eenlocui orice lan\u021b cu complexitate mai mic\u0103, indiferent de lungimea lan\u021burilor. \u00cen EOS, de exemplu, blocurile finale sunt numitele Last Irreversible Blocks, care apar \u00een medie la fiecare 432 de blocuri (12*21 + 12*15, pre-vote + pre-commit). Acest proces este, \u00een esen\u021b\u0103, a\u0219teptarea a 2\/3 din semn\u0103turile produc\u0103torilor de blocuri (BP). \u00cen cazul \u00een care apar fork-uri care sunt mai vechi dec\u00e2t ultimul LIB, acestea sunt pur \u0219i simplu eliminate. Acest mecanism permite garantarea faptului c\u0103 tranzac\u021bia este inclus\u0103 \u00een blockchain \u0219i nu va fi eliminat\u0103, indiferent de resursele pe care le-ar avea atacatorul. De asemenea, blocurile finale sunt blocuri care sunt semnate de 2\/3 din BP \u00een Hyperledger, Tendermint \u0219i alte consensuri bazate pe pBFT. De asemenea, este logic ca protocolul pentru asigurarea finalit\u0103\u021bii s\u0103 fie implementat ca un strat deasupra consensului, deoarece poate func\u021biona asincron cu produc\u021bia \u0219i publicarea blocurilor. <noindex><a rel=\"nofollow\" href=\"https:\/\/arxiv.org\/pdf\/1710.09437.pdf\">articol<\/a><\/noindex> despre finalitate \u00een Ethereum.<\/p>\n<p><\/p>\n<p>Finalitatea este extrem de important\u0103 pentru utilizatori, care, f\u0103r\u0103 ea, pot deveni victime ale atacului \u201edouble spend\u201d, c\u00e2nd BP \u201ere\u021bine\u201d blocuri \u0219i le public\u0103 dup\u0103 ce re\u021beaua \u201evede\u201d o tranzac\u021bie bun\u0103. Dac\u0103 nu exist\u0103 finalitate, atunci fork-ul publicat \u00eenlocuie\u0219te blocul cu tranzac\u021bia \u201ebun\u0103\u201d cu altul din fork-ul \u201er\u0103u\u201d, \u00een care acelea\u0219i fonduri sunt transferate c\u0103tre adresa atacatorului. \u00cen cazul PVRB, cerin\u021bele de finalitate sunt \u0219i mai stricte, deoarece construirea fork-urilor pentru PVRB d\u0103 atacatorului posibilitatea de a preg\u0103ti mai multe variante de randomizare pentru a publica cea mai avantajoas\u0103 variant\u0103 \u0219i de a limita timpul atacului posibil - o solu\u021bie bun\u0103.<\/p>\n<p><\/p>\n<p>Prin urmare, cea mai bun\u0103 op\u021biune este s\u0103 combin\u0103m PVRB \u0219i finalitatea \u00eentr-un singur protocol - atunci blocul finalizat = randomizarea finalizat\u0103, iar aceasta este precisamente ceea ce trebuie ob\u021binut. Acum, juc\u0103torii vor ob\u021bine o randomizare garantat\u0103 \u00een N secunde \u0219i pot fi siguri c\u0103 nu este posibil s\u0103 o anuleze sau s\u0103 o rejoace.<\/p>\n<p><\/p>\n<p>Op\u021biunea cu consensus-integrated este bun\u0103:<\/p>\n<p><\/p>\n<ul>\n<li>cu posibilitatea implement\u0103rii asincrone \u00een raport cu produc\u021bia de blocuri - blocurile sunt produse ca de obicei, dar \u00een paralel, protocolul PVRB poate func\u021biona, produc\u00e2nd randomiz\u0103ri nu la fiecare bloc.<\/li>\n<li>cu posibilitatea de a implementa chiar \u0219i criptografie grea, f\u0103r\u0103 limit\u0103ri impuse de contractele inteligente.<\/li>\n<li>cu posibilitatea de a organiza schimbul de mesaje mai repede dec\u00e2t tranzac\u021biile sunt incluse \u00een blockchain, de exemplu, o parte din protocol poate func\u021biona \u00eentre noduri f\u0103r\u0103 a r\u0103sp\u00e2ndi mesaje prin re\u021bea.<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00cen acela\u0219i timp, are \u0219i dezavantaje:<\/p>\n<p><\/p>\n<ul>\n<li>dificult\u0103\u021bi \u00een testare \u0219i dezvoltare - va trebui s\u0103 emul\u0103m erorile de re\u021bea, nodurile disp\u0103rute, hard fork-urile re\u021belei.<\/li>\n<li>erorile \u00een implementare necesit\u0103 un hard fork al re\u021belei.<\/li>\n<\/ul>\n<p><\/p>\n<p>Ambele metode de implementare a PVRB au dreptul la via\u021b\u0103, dar implementarea pe contracte inteligente \u00een blockchain-urile moderne este totu\u0219i destul de limitat\u0103 \u00een resursele computa\u021bionale, \u0219i orice tranzi\u021bie c\u0103tre criptografie serioas\u0103 este adesea pur \u0219i simplu imposibil\u0103. Iar criptografia serioas\u0103 ne va fi necesar\u0103, a\u0219a cum va fi demonstrat mai departe. De\u0219i aceast\u0103 problem\u0103 este evident temporar\u0103, criptografia serioas\u0103 \u00een contracte este necesar\u0103 pentru solu\u021bionarea multor probleme \u0219i, treptat, aceasta apare (de exemplu, contractele sistemice pentru zkSNARKs \u00een Ethereum).<\/p>\n<p><\/p>\n<p>Blockchain-ul care asigur\u0103 un canal de comunicare transparent \u0219i fiabil pentru protocol nu este gratuit. Orice protocol descentralizat trebuie s\u0103 ia \u00een considerare posibilitatea atacului Sybil, deoarece orice ac\u021biune poate fi realizat\u0103 prin for\u021bele coordonate ale mai multor conturi, astfel c\u0103, la proiectare, trebuie s\u0103 se \u021bin\u0103 cont de capabilit\u0103\u021bile atacatorilor de a crea un num\u0103r arbitrar de participan\u021bi la protocol care ac\u021bioneaz\u0103 \u00een conspira\u021bie. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-peremennye-bloka\">PVRB \u0219i variabilele blocului.<\/h2>\n<p><\/p>\n<p>Nu am min\u021bit c\u00e2nd am spus c\u0103 un PVRB bun, verificat de numeroase aplica\u021bii de gambling, nu a fost implementat \u00eenc\u0103 \u00een blockchains. De unde provine atunci at\u00e2ta num\u0103r de aplica\u021bii de gambling \u00een Ethereum \u0219i EOS? M\u0103 mir\u0103 la fel de mult ca pe voi, dar de unde \u00een acest mediu complet determinist au ap\u0103rut at\u00e2\u021bia \u201erandomi\u201d \u201erezisten\u021bi\u201d?<\/p>\n<p><\/p>\n<p>Modul favorit de a ob\u021bine random \u00een blockchain este s\u0103 iei o informa\u021bie \u201eneprev\u0103zut\u0103\u201d din bloc \u0219i, pe baza acesteia, s\u0103 generezi random \u2014 pur \u0219i simplu prin hash-area uneia sau mai multor valori. Un articol bun despre problemele acestor scheme. <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.positive.com\/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620\">aici<\/a><\/noindex>. Po\u021bi lua oricare dintre valorile \u201eneprev\u0103zute\u201d din bloc, de exemplu hash-ul blocului, num\u0103rul de tranzac\u021bii, dificultatea re\u021belei \u0219i altele valori necunoscute dinainte. Apoi, po\u021bi s\u0103 le hash-ezi, una sau mai multe, \u0219i, \u00een teorie, ar trebui s\u0103 ob\u021bii un adev\u0103rat random. Po\u021bi chiar s\u0103 adaugi \u00een whitepaper c\u0103 schema ta este \u201erezistent\u0103 post-cuantic\u0103\u201d (deoarece exist\u0103 func\u021bii hash rezistente la cuantice :)).<\/p>\n<p><\/p>\n<p>Dar, din p\u0103cate, chiar \u0219i func\u021biile hash rezistente post-cuantic nu sunt suficiente. Secretul const\u0103 \u00een cerin\u021bele pentru PVRB, s\u0103 le reamintesc din articolul anterior:<\/p>\n<p><\/p>\n<ol>\n<li>Rezultatul trebuie s\u0103 aib\u0103 o distribu\u021bie dovedit uniform\u0103, adic\u0103 s\u0103 se bazeze pe criptografie dovedit rezistent\u0103.<\/li>\n<li>Nu se pot controla niciunul dintre bi\u021bii rezultatului. Ca urmare, rezultatul nu poate fi prezis \u00een avans.<\/li>\n<li>Nu se poate sabota protocolul de generare prin neparticiparea la protocol sau prin supra\u00eenc\u0103rcarea re\u021belei cu mesaje de atac.<\/li>\n<li>Toate cele men\u021bionate anterior trebuie s\u0103 fie rezistente la conspira\u021biile unui num\u0103r permisibil de participan\u021bi necinstit (de exemplu, 1\/3 din participan\u021bi).<\/li>\n<\/ol>\n<p><\/p>\n<p>\u00cen acest caz, se respect\u0103 doar cerin\u021ba 1 \u0219i nu se respect\u0103 2. Prin hash-uirea valorilor imprevizibile din bloc, ob\u021binem o distribu\u021bie uniform\u0103 \u0219i bune randomiz\u0103ri. \u00cens\u0103 BP are cel pu\u021bin posibilitatea de a \u201epublica blocul sau nu\u201d. Astfel, BP poate alege din DOU\u0102 variante de randomizare: \u201ea sa\u201d \u0219i cea care ar rezulta dac\u0103 blocul ar fi publicat de altcineva. BP poate \u201epreviziona\u201d ce va ie\u0219i dac\u0103 public\u0103 blocul \u0219i ia pur \u0219i simplu decizia de a face asta sau nu. Astfel, juc\u00e2nd, de exemplu, la \u201epar\/impar\u201d sau \u201ero\u0219u\/negru\u201d la rulet\u0103, el poate publica blocul doar dac\u0103 vede o victorie. Aceasta face ca strategia de utilizare a, de exemplu, hash-ului blocului \u201edin viitor\u201d s\u0103 nu mai func\u021bioneze. \u00cen acest caz, se spune c\u0103 \u201eva fi folosit un random generat prin hash-uirea datelor curente \u0219i hash-ului blocului din viitor cu \u00een\u0103l\u021bimea, de exemplu, N + 42, unde N este \u00een\u0103l\u021bimea curent\u0103 a blocului. Aceasta \u00eent\u0103re\u0219te ceva schema, dar tot permite BP-ului, chiar \u0219i \u00een viitor, s\u0103 aleag\u0103 s\u0103 p\u0103streze blocul sau s\u0103 \u00eel publice.<\/p>\n<p><\/p>\n<p>Software-ul BP \u00een acest caz devine mai complicat, dar nu foarte mult. Pur \u0219i simplu, \u00een timpul valid\u0103rii \u0219i includerii unei tranzac\u021bii \u00een bloc, se face o verificare rapid\u0103 pentru a vedea dac\u0103 va fi o victorie \u0219i, posibil, ajustarea unuia dintre parametrii tranzac\u021biei pentru a ob\u021bine o probabilitate \u00eenalt\u0103 de c\u00e2\u0219tig. \u00cen acest proces, prinderea unui BP iste\u021b prin aceste manipul\u0103ri este practic imposibil\u0103, deoarece se pot folosi mereu adrese noi \u0219i se pot c\u00e2\u0219tiga sume mici f\u0103r\u0103 a st\u00e2rni suspiciuni.<\/p>\n<p><\/p>\n<p>Prin urmare, metodele care folosesc informa\u021bii din bloc nu sunt adecvate ca implementa\u021bie universal\u0103 a PVRB. \u00cen variante limitate, cu restric\u021bii asupra dimensiunii pariu-lor, restric\u021bii asupra num\u0103rului de juc\u0103tori \u0219i\/sau KYC pentru a \u00eempiedica un singur juc\u0103tor s\u0103 foloseasc\u0103 mai multe adrese, aceste scheme pot func\u021biona pentru jocuri mici, dar nu mai mult dec\u00e2t at\u00e2t.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-commit-reveal\">PVRB \u0219i commit-reveal.<\/h2>\n<p><\/p>\n<p>Bine, mul\u021bumim hash-u-ului \u0219i cel pu\u021bin pentru relativa imprevizibilitate a hash-ului blocului \u0219i a altor variabile. Dac\u0103 rezolv\u0103m problema front-running-ului minerilor, ar trebui s\u0103 ob\u021binem ceva mai solid. S\u0103 ad\u0103ug\u0103m utilizatorii \u00een aceast\u0103 schem\u0103 \u2014 s\u0103 lase \u0219i ei influen\u021b\u0103 asupra randomiz\u0103rii: oricare angajat al suportului tehnic \u00ee\u021bi va spune c\u0103 cel mai random \u00een sistemele IT sunt ac\u021biunile utilizatorilor \ud83d\ude42<\/p>\n<p><\/p>\n<p>Schema naiv\u0103, \u00een care utilizatorii trimit pur \u0219i simplu numere aleatorii, iar rezultatul este calculat, de exemplu, ca hash al sumei lor, nu este adecvat\u0103. \u00cen acest caz, cel care joac\u0103 ultima dat\u0103 poate controla ce rezultat va fi, aleg\u00e2nd propria aleatorietate. De aceea este folosit un model foarte popular, commit-reveal. Participan\u021bii trimit mai \u00eent\u00e2i hash-uri ale aleatorilor lor (commit-uri), apoi dezv\u0103luie aleatorii \u00een\u0219i\u0219i (reveal-uri). Faza \u201creveal\u201d \u00eencepe doar dup\u0103 colectarea commit-urilor necesare, astfel \u00eenc\u00e2t participan\u021bii pot trimite exact acea aleatorie, hash-ul c\u0103reia l-au trimis anterior. Acum, s\u0103 combin\u0103m toate acestea cu parametrii blocului, de preferin\u021b\u0103 lua\u021bi din viitor (aleatorul va fi cunoscut doar \u00eentr-unul dintre blocurile viitoare), \u0219i voila \u2014 aleatorul este gata! Acum orice juc\u0103tor influen\u021beaz\u0103 aleatorul rezultant \u0219i poate \u201c\u00eenvinge\u201d BP-ul malefic, suprapun\u00e2nd aleatorul s\u0103u, ne\u0219tiut dinainte, peste al lui... De asemenea, se poate ad\u0103uga o protec\u021bie \u00eempotriva sabotorilor protocolului prin imposibilitatea de a dezv\u0103lui \u00een etapa reveal \u2014 pur \u0219i simplu cer\u00e2ndu-se, la commit, s\u0103 se ata\u0219eze o anumit\u0103 sum\u0103 la tranzac\u021bie \u2014 un depozit de garan\u021bie, care va fi returnat doar \u00een timpul procedurii de reveal. \u00cen acest caz, a face commit \u0219i a nu face reveal va fi dezavantajos.<\/p>\n<p><\/p>\n<p>A fost o \u00eencercare bun\u0103, iar astfel de scheme exist\u0103 \u00een DApp-urile de jocuri, dar din p\u0103cate, din nou, asta nu este suficient. Acum, rezultatul poate fi influen\u021bat nu doar de miner, ci \u0219i de orice participant la protocol. Controlul asupra valorii \u00een sine este \u00een continuare posibil, cu o variabilitate mai mic\u0103 \u0219i contra cost, dar, ca \u0219i \u00een cazul minerului, dac\u0103 rezultatele extragerii valoreaz\u0103 mai mult dec\u00e2t taxa de participare \u00een protocolul PVRB, atunci produc\u0103torul de aleator (RP) poate decide dac\u0103 s\u0103 fac\u0103 reveal \u0219i poate alege \u00een continuare din minimum dou\u0103 op\u021biuni de aleator.<br \/>\n\u00cen schimb, a ap\u0103rut posibilitatea de a penaliza pe cei care fac commit \u0219i nu fac reveal, iar aceast\u0103 schem\u0103 va fi util\u0103. Simplitatea sa este un avantaj serios \u2014 protocoalele mai serioase necesit\u0103 calculi mult mai puternici.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-determinirovannye-podpisi\">PVRB \u0219i semn\u0103turi determinate.<\/h2>\n<p><\/p>\n<p>Exist\u0103 o alt\u0103 metod\u0103 de a face RP s\u0103 furnizeze un num\u0103r pseudo-aleatoriu asupra c\u0103ruia nu poate influen\u021ba, dac\u0103 i se ofer\u0103 un \u201eexemplar\u201d \u2013 aceasta este o semn\u0103tur\u0103 determinist\u0103. O semn\u0103tur\u0103 de acest tip este, de exemplu, RSA, \u0219i nu este ECS. Dac\u0103 RP are o pereche de chei: RSA \u0219i E\u0421C, \u0219i semneaz\u0103 cu cheia sa privat\u0103 o anumit\u0103 valoare, \u00een cazul RSA va ob\u021bine O SINGUR\u0102 SEMN\u0102TUR\u0102, iar \u00een cazul ECS \u2013 el poate genera un num\u0103r nelimitat de semn\u0103turi valide diferite. Acest lucru se datoreaz\u0103 faptului c\u0103, la crearea semn\u0103turii ECS, se folose\u0219te un num\u0103r aleatoriu ales de semnatar, iar acesta poate fi ales \u00een orice mod, d\u00e2nd semnatarului posibilitatea de a alege dintre mai multe semn\u0103turi. \u00cen cazul RSA: \u201eo valoare de intrare\u201d + \u201eo pereche de chei\u201d = \u201eo semn\u0103tur\u0103\u201d. Nu se poate prezice care va fi semn\u0103tura unui alt RP, prin urmare, PVRB cu semn\u0103turi deterministe poate fi organizat prin combinarea semn\u0103turilor RSA ale mai multor participan\u021bi care au semnat aceea\u0219i valoare. De exemplu \u2013 num\u0103rul aleatoriu precedent. \u00cen acest sistem se economisesc multe resurse, deoarece semn\u0103turile sunt simultan \u0219i o confirmare a corectitudinii comportamentului conform protocolului, \u0219i o surs\u0103 de aleatoriu.<\/p>\n<p><\/p>\n<p>Cu toate acestea, chiar \u0219i cu semn\u0103turi deterministe, schema r\u0103m\u00e2ne vulnerabil\u0103 la problema \u201eultimului actor\u201d. Ultimul participant poate \u00eenc\u0103 decide dac\u0103 public\u0103 semn\u0103tura sau nu, control\u00e2nd astfel rezultatul. Schema poate fi \u00eembun\u0103t\u0103\u021bit\u0103, ad\u0103ug\u00e2nd hash-uri ale blocurilor, realiz\u00e2nd runde, astfel \u00eenc\u00e2t rezultatul s\u0103 nu poat\u0103 fi prev\u0103zut dinainte, dar toate aceste tehnici, chiar \u0219i cu numeroasele \u00eembun\u0103t\u0103\u021biri, las\u0103 totu\u0219i nerezolvat\u0103 problema influen\u021bei unui singur participant asupra rezultatului colectiv \u00eentr-un mediu ne\u00eencrez\u0103tor \u0219i pot func\u021biona doar \u00een condi\u021bii de restric\u021bii economice \u0219i de timp. \u00cen plus, dimensiunea cheilor RSA (1024 \u0219i 2048 bi\u021bi) este destul de mare, iar dimensiunea pentru tranzac\u021biile blockchain este un parametru extrem de important. Se pare c\u0103 nu se poate rezolva problema \u00een mod simplu, a\u0219a c\u0103 mergem mai departe.<\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-secret-sharing-shemy\">PVRB \u0219i schemele de secret sharing<\/h2>\n<p><\/p>\n<p>\u00cen criptografie exist\u0103 scheme care pot permite re\u021belei s\u0103 ajung\u0103 la un singur \u0219i unic PVRB, aceste scheme fiind rezistente la orice ac\u021biuni mali\u021bioase din partea participan\u021bilor. Unul dintre protocoalele utile de explorat este schema de \u00eemp\u0103r\u021bire a secretului a lui Shamir. Aceasta serve\u0219te pentru a \u00eemp\u0103r\u021bi un secret (de exemplu, o cheie secret\u0103) \u00een mai multe p\u0103r\u021bi, care sunt distribuite celor N participan\u021bi. Secretul este distribuit astfel \u00eenc\u00e2t pentru a-l recupera, sunt suficiente M p\u0103r\u021bi din N, iar acestea pot fi orice M p\u0103r\u021bi. Pe scurt, av\u00e2nd un grafic al unei func\u021bii necunoscute, participan\u021bii schimb\u0103 puncte de pe grafic, \u0219i dup\u0103 ob\u021binerea a M puncte, \u00eentreaga func\u021bie poate fi recuperat\u0103.<br \/>\nO explica\u021bie bun\u0103 este oferit\u0103 \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Shamir%27s_Secret_Sharing\">wiki<\/a><\/noindex> \u0219i s\u0103 experimenta\u021bi practic, pentru a \u00een\u021belege protocolul mai bine, este util s\u0103 accesa\u021bi <noindex><a rel=\"nofollow\" href=\"http:\/\/point-at-infinity.org\/ssss\/demo.html\">demo<\/a><\/noindex> pagina.<\/p>\n<p><\/p>\n<p>Dac\u0103 schema FSSS (Fiat-Shamir Secret Sharing) ar fi aplicabil\u0103 \u00een forma sa pur\u0103, ar fi un PVRB imposibil de distrus. \u00cen cea mai simpl\u0103 variant\u0103, protocolul ar putea ar\u0103ta astfel:<\/p>\n<p><\/p>\n<ul>\n<li>Fiecare participant genereaz\u0103 propriul random \u0219i distribuie shares din acesta celorlal\u021bi participan\u021bi.<\/li>\n<li>Fiecare participant dezv\u0103luie partea sa din secretele celorlal\u021bi participan\u021bi.<\/li>\n<li>Dac\u0103 pentru un participant s-au acumulat mai mult de M shares, atunci num\u0103rul acestui participant poate fi calculat \u0219i va fi unic, indiferent de setul de participan\u021bi care au dezv\u0103luit informa\u021bii.<\/li>\n<li>Combina\u021bia de random-uri dezv\u0103luite este PVRB-ul dorit.<\/li>\n<\/ul>\n<p><\/p>\n<p>Aici, un participant separat nu mai influen\u021beaz\u0103 rezultatele protocolului, cu excep\u021bia cazurilor \u00een care atingerea pragului de dezv\u0103luire a random-ului depinde exclusiv de el. Prin urmare, acest protocol, av\u00e2nd procentul necesar de participan\u021bi care respect\u0103 protocolul \u0219i RP-uri disponibile, func\u021bioneaz\u0103, \u00eendeplinind cerin\u021bele de rezisten\u021b\u0103 criptografic\u0103 \u0219i fiind rezistent la problema \u201eultimului actor\u201d.<\/p>\n<p><\/p>\n<p>Aceasta ar putea fi op\u021biunea ideal\u0103, aceast\u0103 schem\u0103 PVRB bazat\u0103 pe \u00eemp\u0103r\u021birea secretului Fiat-Shamir este descris\u0103, de exemplu, \u00een <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2017\/216.pdf\">aceast\u0103<\/a><\/noindex> articol. Dar, a\u0219a cum s-a spus mai sus, dac\u0103 se \u00eencearc\u0103 aplicarea acesteia direct \u00een blockchain, apar deja limit\u0103ri tehnice. Iat\u0103 un exemplu de implementare de testare a protocolului \u00eentr-un smart contract EOS \u0219i cea mai important\u0103 parte a acestuia \u2014 verificarea share-ului publicat de participant: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/eoscraper\/blob\/master\/Proof.hh#L23\">cod<\/a><\/noindex>. Din cod, se observ\u0103 c\u0103 validarea proof-ului necesit\u0103 mai multe \u00eenmul\u021biri scalare, iar numerele folosite sunt foarte mari. Este important de \u00een\u021beles c\u0103, \u00een blockchain-uri, verificarea se \u00eent\u00e2mpl\u0103 \u00een momentul \u00een care produc\u0103torul de blocuri proceseaz\u0103 tranzac\u021bia, iar orice participant ar trebui s\u0103 poat\u0103 verifica u\u0219or corectitudinea protocolului, de aceea cerin\u021bele pentru viteza func\u021biei de verificare sunt foarte serioase. \u00cen aceast\u0103 variant\u0103, solu\u021bia s-a dovedit a fi nefunc\u021bional\u0103, deoarece verificarea nu se \u00eencadra \u00een limita de timp a tranzac\u021biei (0,5 sec).<\/p>\n<p><\/p>\n<p>Eficien\u021ba verific\u0103rii este una dintre cele mai importante cerin\u021be pentru utilizarea oric\u0103ror scheme cryptografice avansate \u00een blockchain. Crearea de proof-uri, preg\u0103tirea mesajelor \u2014 aceste proceduri pot fi efectuate off-chain pe computere de \u00eenalt\u0103 performan\u021b\u0103, dar verificarea nu poate fi ocolit\u0103 \u2014 aceasta este o alt\u0103 cerin\u021b\u0103 important\u0103 pentru PVRB. <\/p>\n<p><\/p>\n<h2 id=\"pvrb-i-threshold-signatures\">PVRB \u0219i semn\u0103turile threshold<\/h2>\n<p><\/p>\n<p>Dup\u0103 ce ne-am familiarizat cu schema de secret sharing, am descoperit o \u00eentreag\u0103 clas\u0103 de protocoale unite prin cuv\u00e2ntul cheie \u201cthreshold\u201d. Atunci c\u00e2nd pentru dezv\u0103luirea unei informa\u021bii este necesar\u0103 participarea a M participan\u021bi one\u0219ti din N, iar setul de participan\u021bi one\u0219ti poate fi orice submultime a lui N, se vorbe\u0219te despre schemele \u201cthreshold\u201d. Acestea permit solu\u021bionarea problemei \u201clast actor\u201d, astfel \u00eenc\u00e2t, dac\u0103 un atacator nu \u00ee\u0219i dezv\u0103luie partea din secret, un alt participant onest o va face \u00een locul lui. Aceste scheme permit c\u0103 acordarea unui singur \u0219i unic valorii, chiar \u0219i \u00een condi\u021biile sabot\u0103rii protocolului de c\u0103tre o parte dintre participan\u021bi. <\/p>\n<p><\/p>\n<p>Combinarea semn\u0103turilor deterministe cu schemele threshold a dus la dezvoltarea unei scheme foarte convenabile \u0219i promi\u021b\u0103toare pentru implementarea PVRB \u2014 este vorba despre semn\u0103turile threshold deterministe. Aici <noindex><a rel=\"nofollow\" href=\"https:\/\/eprint.iacr.org\/2002\/081.pdf\">articol<\/a><\/noindex> despre diversele aplica\u021bii ale semn\u0103turilor threshold, iar aici un alt exemplu bun <noindex><a rel=\"nofollow\" href=\"https:\/\/blog.dash.org\/secret-sharing-and-threshold-signatures-with-bls-954d1587b5f\">longread<\/a><\/noindex> de la Dash. <\/p>\n<p><\/p>\n<p>Articolul final descrie semn\u0103turile BLS (BLS se deosebe\u0219te prin Boneh-Lynn-Shacham, <noindex><a rel=\"nofollow\" href=\"https:\/\/www.iacr.org\/archive\/asiacrypt2001\/22480516.pdf\">iat\u0103<\/a><\/noindex> articolul ), care au o calitate foarte important\u0103 \u0219i extrem de convenabil\u0103 pentru programatori - cheile publice, secrete, cheile publice \u0219i semn\u0103turile BLS pot fi combinate \u00eentre ele prin opera\u021bii matematice simple, p\u0103str\u00e2ndu-se astfel valabilitatea lor ca chei \u0219i semn\u0103turi, permi\u021b\u00e2nd agregarea u\u0219oar\u0103 a multor semn\u0103turi \u00eentr-o singur\u0103 semn\u0103tur\u0103 \u0219i a multor chei publice \u00eentr-o singur\u0103 cheie. De asemenea, ele sunt deterministe \u0219i pentru acelea\u0219i date de intrare returneaz\u0103 acela\u0219i rezultat. Datorit\u0103 acestei calit\u0103\u021bi, combina\u021biile de semn\u0103turi BLS sunt ele \u00eensele chei valabile, ceea ce permite un scenariu \u00een care M din N participan\u021bi genereaz\u0103 o singur\u0103 semn\u0103tur\u0103, care este determinat\u0103, public verificabil\u0103 \u0219i imprevizibil\u0103 p\u00e2n\u0103 c\u00e2nd este dezv\u0103luit\u0103 de cel de-al M-lea participant.<\/p>\n<p><\/p>\n<p>\u00cen schema cu semn\u0103turi BLS cu threshold, fiecare participant semneaz\u0103 prin BLS ceva (de exemplu, un random anterior), iar semn\u0103tura total\u0103 cu threshold este randomul dorit. Propriet\u0103\u021bile criptografice ale semn\u0103turilor BLS satisfac cerin\u021bele de calitate ale randomului, partea de threshold protejeaz\u0103 \u00eempotriva \u201eultimului actor\u201d, iar combinabilitatea unic\u0103 a cheilor permite implementarea multor algoritmi interesan\u021bi care permit, de exemplu, agregarea eficient\u0103 a mesajelor protocolului.<\/p>\n<p><\/p>\n<p>A\u0219adar, dac\u0103 construie\u0219ti PVRB \u00een blockchain-ul t\u0103u, este foarte probabil s\u0103 ajungi la schema semn\u0103turilor BLS cu threshold, care este deja utilizat\u0103 de mai multe proiecte. De exemplu, DFinity (<noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/random-beacon\">aici<\/a><\/noindex> benchmark ce implementeaz\u0103 schema, \u0219i <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/dfinity\/vss\/blob\/master\/docs\/index.md\">aici<\/a><\/noindex> un exemplu de implementare a \u00eemp\u0103rt\u0103\u0219irii secrete verificabile), sau Keep.network (iat\u0103 beaconul lor random <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-yellowpaper\">yellowpaper<\/a><\/noindex>, dar iat\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/keep-network\/random-beacon-box\">exemplu<\/a><\/noindex> al contractului inteligent care administreaz\u0103 protocolul).<\/p>\n<p><\/p>\n<h2 id=\"implementaciya-pvrb\">Implementarea PVRB<\/h2>\n<p><\/p>\n<p>Din p\u0103cate, \u00eenc\u0103 nu vedem un protocol PVRB finalizat, implementat \u00een blockchain, care s\u0103-\u0219i fi demonstrat securitatea \u0219i rezilien\u021ba. De\u0219i protocoalele sunt gata, aplicarea lor tehnic\u0103 la solu\u021biile existente nu este simpl\u0103. Pentru sistemele centralizate, PVRB nu are niciun sens, iar cele descentralizate sunt strict limitate \u00een toate resursele computa\u021bionale: CPU, memorie, stocare, I\/O. Proiectarea PVRB const\u0103 \u00een combinarea diferitelor protocoale pentru a crea ceva care s\u0103 corespund\u0103 tuturor cerin\u021belor, m\u0103car pentru un blockchain viabil. Un protocol calculeaz\u0103 mai eficient, dar necesit\u0103 mai multe mesaje \u00eentre RP, iar altul necesit\u0103 extrem de pu\u021bine mesaje, dar generarea dovezii poate dura zeci de minute, dac\u0103 nu chiar ore.<\/p>\n<p><\/p>\n<p>Voi lista factorii pe care va trebui s\u0103 \u00eei iei \u00een considerare atunci c\u00e2nd alegi un PVRB de calitate:<\/p>\n<p><\/p>\n<ul>\n<li><em>Rezisten\u021ba criptografic\u0103<\/em>. PVRB-ul t\u0103u trebuie s\u0103 fie strict ne\u00eembiasabil, f\u0103r\u0103 posibilitatea de a controla un singur bit. \u00cen unele scheme, acest lucru nu este adev\u0103rat, a\u0219a c\u0103 cheam\u0103 un criptograf.<\/li>\n<li><em>Problema \u201eultimului actor\u201d<\/em>. PVRB-ul t\u0103u trebuie s\u0103 fie rezistent la atacuri \u00een care atacatorul, control\u00e2nd unul sau mai mul\u021bi RP, poate alege \u00eentre dou\u0103 rezultate posibile.<\/li>\n<li><em>Problema sabot\u0103rii protocolului<\/em>. PVRB-ul t\u0103u trebuie s\u0103 fie rezistent la atacuri \u00een care atacatorul, control\u00e2nd unul sau mai mul\u021bi RP, decid dac\u0103 s\u0103 fie aleatoriu sau nu \u0219i poate influen\u021ba garantat, sau cu o probabilitate dat\u0103, acest lucru.<\/li>\n<li><em>Problema num\u0103rului de mesaje<\/em>. RP-urile tale trebuie s\u0103 trimit\u0103 \u00een blockchain un minim de mesaje \u0219i s\u0103 evite c\u00e2t mai mult situa\u021biile de ac\u021biune sincron\u0103, cum ar fi \u201eam trimis o informa\u021bie, a\u0219tept r\u0103spuns de la un anumit participant\u201d. \u00cen re\u021belele p2p, mai ales cele geografic distribuite, nu ar trebui s\u0103 te a\u0219tep\u021bi la un r\u0103spuns rapid.<\/li>\n<li><em>Problema complexit\u0103\u021bii de calcul<\/em>. Verificarea oric\u0103rei etape a PVRB on-chain trebuie s\u0103 fie extrem de u\u0219oar\u0103, deoarece este efectuat\u0103 de toate clien\u021bii comple\u021bi din re\u021bea. Dac\u0103 implementarea se face printr-un contract inteligent, cerin\u021bele de vitez\u0103 sunt foarte stricte.<\/li>\n<li><em>Problema disponibilit\u0103\u021bii \u0219i activit\u0103\u021bii<\/em>. PVRB-ul t\u0103u trebuie s\u0103 t streven  la rezisten\u021ba \u00een situa\u021biile \u00een care o parte a re\u021belei devine inaccesibil\u0103 pentru o perioad\u0103 de timp \u0219i o parte a RP-urilor pur \u0219i simplu \u00eenceteaz\u0103 s\u0103 func\u021bioneze.<\/li>\n<li><em>Problema configur\u0103rii de \u00eencredere \u0219i distribu\u021biei ini\u021biale a cheilor<\/em>. Dac\u0103 PVRB-ul dvs. utilizeaz\u0103 configurarea protocolului principal, atunci aceasta este o poveste separat\u0103, mare \u0219i serioas\u0103. Iat\u0103 <noindex><a rel=\"nofollow\" href=\"https:\/\/z.cash\/ru\/blog\/the-design-of-the-ceremony\/\">exemplu<\/a><\/noindex>. Dac\u0103 participan\u021bii trebuie s\u0103 \u00ee\u0219i comunice cheile \u00eenainte de \u00eenceputul protocolului \u2014 aceasta este \u0219i o problem\u0103, dac\u0103 componen\u021ba participan\u021bilor se schimb\u0103<\/li>\n<li><em>Probleme de dezvoltare<\/em>. Disponibilitatea bibliotecilor \u00een limbile necesare, securitatea \u0219i performan\u021ba acestora, publicitatea, teste complexe \u0219i a\u0219a mai departe.<\/li>\n<\/ul>\n<p><\/p>\n<p>De exemplu, la semn\u0103turile BLS cu threshold exist\u0103 o problem\u0103 semnificativ\u0103 \u2014 \u00eenainte de a \u00eencepe s\u0103 lucreze, participan\u021bii trebuie neap\u0103rat s\u0103 \u00ee\u0219i distribuie cheile \u00eentre ei, organiz\u00e2nd un grup \u00een cadrul c\u0103ruia va func\u021biona threshold-ul. Asta \u00eenseamn\u0103 c\u0103 va trebui s\u0103 a\u0219tepta\u021bi cel pu\u021bin un tur de schimburi \u00eentr-o re\u021bea descentralizat\u0103, \u0219i, av\u00e2nd \u00een vedere c\u0103 num\u0103rul aleator generat, de exemplu, este necesar \u00een jocuri, aproape \u00een timp real, aceasta \u00eenseamn\u0103 c\u0103 sabotajul protocolului este posibil \u00een aceast\u0103 etap\u0103, iar avantajele schemei threshold sunt pierdute. Aceast\u0103 problem\u0103 este mai simpl\u0103 dec\u00e2t cele anterioare, dar tot necesit\u0103 dezvoltarea unei proceduri separate pentru formarea grupurilor de threshold, care va trebui protejat\u0103 din punct de vedere economic, prin depozite \u0219i prin penaliz\u0103ri (slashing) pentru participan\u021bii care nu respect\u0103 protocolul. De asemenea, verificarea BLS cu un nivel acceptabil de securitate pur \u0219i simplu nu se \u00eencadreaz\u0103, de exemplu, \u00een tranzac\u021bia standard EOS sau Ethereum \u2014 pur \u0219i simplu nu exist\u0103 suficient timp pentru verificare. Codul contractelor \u2014 este WebAssembly sau EVM, executat de o ma\u0219in\u0103 virtual\u0103. Func\u021biile criptografice nu sunt implementate nativ (\u00eenc\u0103), \u0219i func\u021bioneaz\u0103 de zeci de ori mai \u00eencet dec\u00e2t bibliotecile criptografice obi\u0219nuite. Multe protocoale nu se potrivesc cerin\u021belor pur \u0219i simplu din cauza volumului cheilor, de exemplu, acestea sunt 1024 \u0219i 2048 de bi\u021bi pentru RSA, de 4-8 ori mai mult dec\u00e2t semn\u0103tura standard a tranzac\u021biei \u00een Bitcoin \u0219i Ethereum.<\/p>\n<p><\/p>\n<p>De asemenea, joac\u0103 un rol \u0219i disponibilitatea implement\u0103rilor \u00een diferite limbaje de programare \u2014 care sunt pu\u021bine, \u00een special pentru protocoalele noi. Op\u021biunea de integrare \u00een consens necesit\u0103 scrierea protocolului \u00een limbajul platformei, astfel c\u0103 va trebui s\u0103 c\u0103uta\u021bi cod \u00een Go pentru geth, \u00een Rust pentru Parity, \u00een C++ pentru EOS. Codul \u00een JavaScript va trebui s\u0103 fie c\u0103utat de toat\u0103 lumea, iar av\u00e2nd \u00een vedere c\u0103 JavaScript \u0219i criptografia nu sunt tocmai prieteni apropia\u021bi, WebAssembly va ajuta, care acum cu siguran\u021b\u0103 aspir\u0103 la rolul de urm\u0103tor standard important \u00een internet.<\/p>\n<p><\/p>\n<h2 id=\"zaklyuchenie\">Concluzie<\/h2>\n<p><\/p>\n<p>Sper c\u0103 \u00een precedentul <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/448330\/\">pe care l-a\u021bi citit<\/a><\/noindex> Am reu\u0219it s\u0103 te conving c\u0103 generarea numerelor aleatoare pe blockchain este critic\u0103 pentru multe aspecte ale vie\u021bii re\u021belelor descentralizate, iar prin acest articol am demonstrat c\u0103 aceast\u0103 sarcin\u0103 este extrem de ambi\u021bioas\u0103 \u0219i complicat\u0103, dar solu\u021bii bune exist\u0103 deja. \u00cen general, designul final al protocolului este posibil doar dup\u0103 efectuarea unor teste masive, care iau \u00een considerare toate aspectele, de la configurare p\u00e2n\u0103 la simularea defectelor, a\u0219adar este pu\u021bin probabil s\u0103 g\u0103se\u0219ti re\u021bete gata f\u0103cute \u00een whitepaper-urile echipelor sau \u00een articole, iar noi cu siguran\u021b\u0103 nu ne vom decide s\u0103 scriem \u201eface\u021bi a\u0219a, a\u0219a este exact corect\u201d \u00een urm\u0103torii un-doi ani. <\/p>\n<p><\/p>\n<p>P\u00e2n\u0103 acum, pentru PVRB-ul nostru \u00een blockchain-ul \u00een dezvoltare <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/mixbytes\/haya\">Haya<\/a><\/noindex>, ne-am oprit la aplicarea semn\u0103turilor BLS cu prag, planific\u00e2nd implementarea PVRB la nivelul consensului, deoarece verificarea \u00een smart contracte cu un nivel de securitate acceptabil este \u00een prezent imposibil\u0103. Este posibil s\u0103 folosim dou\u0103 scheme: ini\u021bial o schem\u0103 costisitoare de secret sharing pentru a crea un random_seed pe termen lung, pe care \u00eel utiliz\u0103m ulterior ca baz\u0103 pentru generarea frecvent\u0103 a aleatoarelor prin semn\u0103turi BLS cu prag deterministice; poate ne vom limita doar la una dintre scheme. Din p\u0103cate, nu putem spune din timp cum va ar\u0103ta protocolul, dar ne bucur\u0103 c\u0103, la fel ca \u00een \u0219tiin\u021b\u0103, \u00een sarcinile inginere\u0219ti, un rezultat negativ este tot un rezultat, iar fiecare nou\u0103 \u00eencercare de a rezolva problema este o alt\u0103 treapt\u0103 pentru cercet\u0103rile tuturor celor care se ocup\u0103 de aceast\u0103 problem\u0103. Pentru a \u00eendeplini cerin\u021bele din partea afacerilor, ne concentr\u0103m pe o sarcin\u0103 practic\u0103 specific\u0103 - asigurarea aplica\u021biilor de jocuri cu o surs\u0103 de entropie fiabil\u0103, a\u0219a c\u0103 trebuie s\u0103 acord\u0103m aten\u021bie \u0219i blockchain-ului \u00een sine, \u00een special problemelor de finalitate a lan\u021bului \u0219i de guvernare a re\u021belei. <\/p>\n<p><\/p>\n<p>\u0218i, de\u0219i momentan nu vedem \u00een blockchain-uri un PVRB dovedit rezistent, care a fost utilizat suficient de mult timp pentru a trece prin teste cu aplica\u021bii reale, auditurile multiple, sarcinile de lucru \u0219i, desigur, atacurile reale, dar num\u0103rul posibilit\u0103\u021bilor confirm\u0103 c\u0103 solu\u021bia exist\u0103, iar unul dintre aceste algoritmi va rezolva \u00een cele din urm\u0103 problema. Vom fi bucuro\u0219i s\u0103 \u00eemp\u0103rt\u0103\u0219im rezultatele \u0219i mul\u021bumim altor echipe care se ocup\u0103 de aceast\u0103 problem\u0103 pentru articolele \u0219i codul care permit inginerilor s\u0103 nu calce de dou\u0103 ori pe acelea\u0219i greble. <\/p>\n<p><\/p>\n<p>A\u0219adar, atunci c\u00e2nd \u00eent\u00e2lni\u021bi un programator care proiecteaz\u0103 un randomizat descentralizat, fi\u021bi aten\u021bi \u0219i grijulii, oferi\u021bi suport psihologic dac\u0103 este necesar \ud83d\ude42<\/p>\n<p>Sursa: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/452340\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number! } \u041a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0441 \u043a\u043e\u043d\u0446\u0435\u043f\u0446\u0438\u0435\u0439 \u0430\u0431\u0441\u043e\u043b\u044e\u0442\u043d\u043e \u0441\u0442\u043e\u0439\u043a\u043e\u0433\u043e \u0448\u0438\u0444\u0440\u0430 \u0438\u0437 \u043a\u0440\u0438\u043f\u0442\u043e\u0433\u0440\u0430\u0444\u0438\u0438, \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u044b \u201cPublicly Verifiable Random Beacon\u201d (\u0434\u0430\u043b\u0435\u0435 PVRB) \u043b\u0438\u0448\u044c \u043f\u044b\u0442\u0430\u044e\u0442\u0441\u044f \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u043f\u0440\u0438\u0431\u043b\u0438\u0437\u0438\u0442\u044c\u0441\u044f \u043a \u0438\u0434\u0435\u0430\u043b\u044c\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u0435, \u0442.\u043a. \u0432 \u0440\u0435\u0430\u043b\u044c\u043d\u044b\u0445 \u0441\u0435\u0442\u044f\u0445 \u0432 \u0447\u0438\u0441\u0442\u043e\u043c \u0432\u0438\u0434\u0435 \u043e\u043d\u0430 \u043d\u0435\u043f\u0440\u0438\u043c\u0435\u043d\u0438\u043c\u0430: \u0434\u043e\u0433\u043e\u0432\u0430\u0440\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u043d\u0430\u0434\u043e \u0441\u0442\u0440\u043e\u0433\u043e \u043e\u0431 \u043e\u0434\u043d\u043e\u043c \u0431\u0438\u0442\u0435, \u0440\u0430\u0443\u043d\u0434\u043e\u0432 \u0434\u043e\u043b\u0436\u043d\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33888","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:55:15+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Numere aleatorii \u0219i re\u021bele descentralizate: implement\u0103ri | ProHoster","description":"Introducere function getAbsolutelyRandomNumer() { return 4; \/\/ returneaz\u0103 un num\u0103r complet aleator!","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0421\u043b\u0443\u0447\u0430\u0439\u043d\u044b\u0435 \u0447\u0438\u0441\u043b\u0430 \u0438 \u0434\u0435\u0446\u0435\u043d\u0442\u0440\u0430\u043b\u0438\u0437\u043e\u0432\u0430\u043d\u043d\u044b\u0435 \u0441\u0435\u0442\u0438: \u0438\u043c\u043f\u043b\u0435\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 function getAbsolutelyRandomNumer() { return 4; \/\/ returns absolutely random number!","og:url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/sluchajnye-chisla-i-detsentralizovannye-seti-implementatsii","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:55:15+00:00","article:modified_time":"2019-10-31T18:55:15+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33888","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 17:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:31:23","updated":"2026-01-21 17:06:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33888","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=33888"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/33888\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=33888"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=33888"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=33888"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}