Introducere

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

La fel ca în cazul conceptului de criptare absolut rezistentă din criptografie, protocoalele reale „Publicly Verifiable Random Beacon” (PVRB) încearcă doar să se apropie cât mai mult de schema ideală, deoarece în rețelele reale aceasta nu poate fi aplicată în formă pură: trebuie să ne înțelegem strict asupra unui singur bit, trebuie să fie multe runde, iar toate mesajele trebuie să fie perfect rapide și să fie livrate întotdeauna. Evident, în rețelele reale nu este așa. Prin urmare, în proiectarea PVRB pentru sarcini specifice în blockchain-urile moderne, pe lângă imposibilitatea de a controla randomul obținut și rezistența criptografică, apar multe probleme pur arhitecturale și tehnice.

Însuși blockchain-ul reprezintă pentru PVRB, în esență, un mediu de comunicare în care mesajele sunt tranzacții. Acest lucru permite o parțială abstractizare de la problemele de rețea, neînceperea mesajelor, problemele software-ului intermediar — toate aceste riscuri sunt asumate de rețeaua descentralizată, iar cea mai mare valoare pentru PVRB este imposibilitatea de a retracta sau distruge o tranzacție deja trimisă — acest lucru împiedică participanții să se retragă din protocol, cu excepția cazului în care au efectuat un atac de succes asupra consensului. Acest nivel de securitate este acceptabil, astfel că PVRB trebuie să fie rezistent la conspirările participanților la aceeași măsură ca și lanțul principal al blockchain-ului. De asemenea, aceasta sugerează că PVRB trebuie să fie parte din consens, dacă rețeaua s-a înțeles cu privire la lanțul principal de blocuri, lăsându-se în același timp să se înțeleagă și cu privire la singurul random rezultat onest. Sau, PVRB este pur și simplu un protocol standalone, realizat printr-un smart contract, funcționând asincron în raport cu blockchain-ul și blocurile. Ambele metode au avantajele și dezavantajele lor, iar alegerea între ele este extrem de non-trivială.

Cele două moduri de implementare a PVRB

Vom descrie mai în detaliu cele două variante de implementare a PVRB — versiunea standalone, care funcționează prin utilizarea unui smart contract independent de blockchain, și varianta integrată în consens — încorporată în protocolul conform căruia rețeaua se înțelege cu privire la lanțul de blocuri și tranzacțiile incluse. În toate cazurile, voi avea în vedere motoare blockchain populare: Ethereum, EOS și toate cele care sunt similare cu ele în ceea ce privește plasarea și procesarea smart contractelor.

Contract independent

În această variantă, PVRB reprezintă un contract inteligent care acceptă tranzacțiile producătorilor random (denumiți ulterior RP), le procesează, combină rezultatele și, în final, ajunge la o anumită valoare, pe care oricare utilizator o poate obține din acest contract. Această valoare nu este neapărat stocată direct în contract, ci poate fi reprezentată doar prin datele din care se poate determina clar o singură valoare a rezultatului aleatoriu. În această schemă, RP sunt utilizatorii blockchain-ului și se poate permite oricui să participe la procesul de generare.

Varianta cu contract independent este bună:

portabilitate (contractele pot fi mutate dintr-un blockchain în altul)
simplitatea implementării și testării (contractele sunt ușor de scris și testat)
conveniența în implementarea schemelor economice (este simplu să creezi un token, a cărui logică servește scopurilor PVRB)
posibilitatea de a fi lansat în blockchain-uri deja funcționale

În același timp, are și dezavantaje:

restricții severe asupra resurselor în timpul calculului, volumului de tranzacții și stocare (în termeni simpli, cpu/mem/io)
restricții asupra operațiunilor din interiorul contractului (nu toate instrucțiunile sunt disponibile, este greu să conectezi biblioteci externe)
imposibilitatea de a organiza comunicarea mai repede decât tranzacțiile sunt incluse în blockchain

Această variantă este potrivită pentru implementarea PVRB, care trebuie să fie lansată într-o rețea existentă, fără criptografie complexă și care nu necesită multe interacțiuni.

Integrat în consens

În această variantă, PVRB este implementat în codul nodului blockchain, fiind integrat sau lucrând paralel cu schimbul de mesaje între nodurile blockchain-ului. Rezultatele protocolului sunt înregistrate direct în blocurile produse, iar mesajele protocolului sunt trimise prin rețeaua p2p între noduri. Deoarece protocolul generează numere care trebuie înregistrate în blocuri, rețeaua trebuie să ajungă la consens asupra acestora. Asta înseamnă că mesajele PVRB, la fel ca tranzacțiile, trebuie să fie validate de noduri și incluse în blocuri, pentru ca orice participant al rețelei să poată valida respectarea protocolului PVRB. Aceasta ne conduce în mod automat la o soluție evidentă — dacă rețeaua ajunge la un consens asupra blocului și a tranzacțiilor din acesta, atunci PVRB trebuie să facă parte din consens, nu să fie un protocol separat. Altfel, ar putea apărea situația în care blocul este valid din perspectiva consensului, dar protocolul PVRB nu este respectat, iar din perspectiva PVRB, blocul nu poate fi acceptat. Așadar, dacă este ales varianta „consensus-integrated”, PVRB devine o parte importantă a consensului.

Descriind implementările PVRB la nivel de consens în rețea, nu se poate ocoli deloc problema finalității. Finalitatea este un mecanism utilizat în consensurile deterministe, care fixează un bloc (și lanțul care duce la acesta) ca fiind final, și care nu va fi niciodată eliminat, chiar dacă apare un fork paralel. De exemplu, în Bitcoin nu există un asemenea mecanism — dacă se publică un lanț cu o complexitate mai mare, acesta va înlocui orice lanț cu complexitate mai mică, indiferent de lungimea lanțurilor. În EOS, de exemplu, blocurile finale sunt numitele Last Irreversible Blocks, care apar în medie la fiecare 432 de blocuri (12*21 + 12*15, pre-vote + pre-commit). Acest proces este, în esență, așteptarea a 2/3 din semnăturile producătorilor de blocuri (BP). În cazul în care apar fork-uri care sunt mai vechi decât ultimul LIB, acestea sunt pur și simplu eliminate. Acest mecanism permite garantarea faptului că tranzacția este inclusă în blockchain și nu va fi eliminată, indiferent de resursele pe care le-ar avea atacatorul. De asemenea, blocurile finale sunt blocuri care sunt semnate de 2/3 din BP în Hyperledger, Tendermint și alte consensuri bazate pe pBFT. De asemenea, este logic ca protocolul pentru asigurarea finalității să fie implementat ca un strat deasupra consensului, deoarece poate funcționa asincron cu producția și publicarea blocurilor. articol despre finalitate în Ethereum.

Finalitatea este extrem de importantă pentru utilizatori, care, fără ea, pot deveni victime ale atacului „double spend”, când BP „reține” blocuri și le publică după ce rețeaua „vede” o tranzacție bună. Dacă nu există finalitate, atunci fork-ul publicat înlocuiește blocul cu tranzacția „bună” cu altul din fork-ul „rău”, în care aceleași fonduri sunt transferate către adresa atacatorului. În cazul PVRB, cerințele de finalitate sunt și mai stricte, deoarece construirea fork-urilor pentru PVRB dă atacatorului posibilitatea de a pregăti mai multe variante de randomizare pentru a publica cea mai avantajoasă variantă și de a limita timpul atacului posibil - o soluție bună.

Prin urmare, cea mai bună opțiune este să combinăm PVRB și finalitatea într-un singur protocol - atunci blocul finalizat = randomizarea finalizată, iar aceasta este precisamente ceea ce trebuie obținut. Acum, jucătorii vor obține o randomizare garantată în N secunde și pot fi siguri că nu este posibil să o anuleze sau să o rejoace.

Opțiunea cu consensus-integrated este bună:

cu posibilitatea implementării asincrone în raport cu producția de blocuri - blocurile sunt produse ca de obicei, dar în paralel, protocolul PVRB poate funcționa, producând randomizări nu la fiecare bloc.
cu posibilitatea de a implementa chiar și criptografie grea, fără limitări impuse de contractele inteligente.
cu posibilitatea de a organiza schimbul de mesaje mai repede decât tranzacțiile sunt incluse în blockchain, de exemplu, o parte din protocol poate funcționa între noduri fără a răspândi mesaje prin rețea.

În același timp, are și dezavantaje:

dificultăți în testare și dezvoltare - va trebui să emulăm erorile de rețea, nodurile dispărute, hard fork-urile rețelei.
erorile în implementare necesită un hard fork al rețelei.

Ambele metode de implementare a PVRB au dreptul la viață, dar implementarea pe contracte inteligente în blockchain-urile moderne este totuși destul de limitată în resursele computaționale, și orice tranziție către criptografie serioasă este adesea pur și simplu imposibilă. Iar criptografia serioasă ne va fi necesară, așa cum va fi demonstrat mai departe. Deși această problemă este evident temporară, criptografia serioasă în contracte este necesară pentru soluționarea multor probleme și, treptat, aceasta apare (de exemplu, contractele sistemice pentru zkSNARKs în Ethereum).

Blockchain-ul care asigură un canal de comunicare transparent și fiabil pentru protocol nu este gratuit. Orice protocol descentralizat trebuie să ia în considerare posibilitatea atacului Sybil, deoarece orice acțiune poate fi realizată prin forțele coordonate ale mai multor conturi, astfel că, la proiectare, trebuie să se țină cont de capabilitățile atacatorilor de a crea un număr arbitrar de participanți la protocol care acționează în conspirație.

PVRB și variabilele blocului.

Nu am mințit când am spus că un PVRB bun, verificat de numeroase aplicații de gambling, nu a fost implementat încă în blockchains. De unde provine atunci atâta număr de aplicații de gambling în Ethereum și EOS? Mă miră la fel de mult ca pe voi, dar de unde în acest mediu complet determinist au apărut atâția „randomi” „rezistenți”?

Modul favorit de a obține random în blockchain este să iei o informație „neprevăzută” din bloc și, pe baza acesteia, să generezi random — pur și simplu prin hash-area uneia sau mai multor valori. Un articol bun despre problemele acestor scheme. aici. Poți lua oricare dintre valorile „neprevăzute” din bloc, de exemplu hash-ul blocului, numărul de tranzacții, dificultatea rețelei și altele valori necunoscute dinainte. Apoi, poți să le hash-ezi, una sau mai multe, și, în teorie, ar trebui să obții un adevărat random. Poți chiar să adaugi în whitepaper că schema ta este „rezistentă post-cuantică” (deoarece există funcții hash rezistente la cuantice :)).

Dar, din păcate, chiar și funcțiile hash rezistente post-cuantic nu sunt suficiente. Secretul constă în cerințele pentru PVRB, să le reamintesc din articolul anterior:

Rezultatul trebuie să aibă o distribuție dovedit uniformă, adică să se bazeze pe criptografie dovedit rezistentă.
Nu se pot controla niciunul dintre biții rezultatului. Ca urmare, rezultatul nu poate fi prezis în avans.
Nu se poate sabota protocolul de generare prin neparticiparea la protocol sau prin supraîncărcarea rețelei cu mesaje de atac.
Toate cele menționate anterior trebuie să fie rezistente la conspirațiile unui număr permisibil de participanți necinstit (de exemplu, 1/3 din participanți).

În acest caz, se respectă doar cerința 1 și nu se respectă 2. Prin hash-uirea valorilor imprevizibile din bloc, obținem o distribuție uniformă și bune randomizări. Însă BP are cel puțin posibilitatea de a „publica blocul sau nu”. Astfel, BP poate alege din DOUĂ variante de randomizare: „a sa” și cea care ar rezulta dacă blocul ar fi publicat de altcineva. BP poate „previziona” ce va ieși dacă publică blocul și ia pur și simplu decizia de a face asta sau nu. Astfel, jucând, de exemplu, la „par/impar” sau „roșu/negru” la ruletă, el poate publica blocul doar dacă vede o victorie. Aceasta face ca strategia de utilizare a, de exemplu, hash-ului blocului „din viitor” să nu mai funcționeze. În acest caz, se spune că „va fi folosit un random generat prin hash-uirea datelor curente și hash-ului blocului din viitor cu înălțimea, de exemplu, N + 42, unde N este înălțimea curentă a blocului. Aceasta întărește ceva schema, dar tot permite BP-ului, chiar și în viitor, să aleagă să păstreze blocul sau să îl publice.

Software-ul BP în acest caz devine mai complicat, dar nu foarte mult. Pur și simplu, în timpul validării și includerii unei tranzacții în bloc, se face o verificare rapidă pentru a vedea dacă va fi o victorie și, posibil, ajustarea unuia dintre parametrii tranzacției pentru a obține o probabilitate înaltă de câștig. În acest proces, prinderea unui BP isteț prin aceste manipulări este practic imposibilă, deoarece se pot folosi mereu adrese noi și se pot câștiga sume mici fără a stârni suspiciuni.

Prin urmare, metodele care folosesc informații din bloc nu sunt adecvate ca implementație universală a PVRB. În variante limitate, cu restricții asupra dimensiunii pariu-lor, restricții asupra numărului de jucători și/sau KYC pentru a împiedica un singur jucător să folosească mai multe adrese, aceste scheme pot funcționa pentru jocuri mici, dar nu mai mult decât atât.

PVRB și commit-reveal.

Bine, mulțumim hash-u-ului și cel puțin pentru relativa imprevizibilitate a hash-ului blocului și a altor variabile. Dacă rezolvăm problema front-running-ului minerilor, ar trebui să obținem ceva mai solid. Să adăugăm utilizatorii în această schemă — să lase și ei influență asupra randomizării: oricare angajat al suportului tehnic îți va spune că cel mai random în sistemele IT sunt acțiunile utilizatorilor 🙂

Schema naivă, în care utilizatorii trimit pur și simplu numere aleatorii, iar rezultatul este calculat, de exemplu, ca hash al sumei lor, nu este adecvată. În acest caz, cel care joacă ultima dată poate controla ce rezultat va fi, alegând propria aleatorietate. De aceea este folosit un model foarte popular, commit-reveal. Participanții trimit mai întâi hash-uri ale aleatorilor lor (commit-uri), apoi dezvăluie aleatorii înșiși (reveal-uri). Faza “reveal” începe doar după colectarea commit-urilor necesare, astfel încât participanții pot trimite exact acea aleatorie, hash-ul căreia l-au trimis anterior. Acum, să combinăm toate acestea cu parametrii blocului, de preferință luați din viitor (aleatorul va fi cunoscut doar într-unul dintre blocurile viitoare), și voila — aleatorul este gata! Acum orice jucător influențează aleatorul rezultant și poate “învinge” BP-ul malefic, suprapunând aleatorul său, neștiut dinainte, peste al lui... De asemenea, se poate adăuga o protecție împotriva sabotorilor protocolului prin imposibilitatea de a dezvălui în etapa reveal — pur și simplu cerându-se, la commit, să se atașeze o anumită sumă la tranzacție — un depozit de garanție, care va fi returnat doar în timpul procedurii de reveal. În acest caz, a face commit și a nu face reveal va fi dezavantajos.

A fost o încercare bună, iar astfel de scheme există în DApp-urile de jocuri, dar din păcate, din nou, asta nu este suficient. Acum, rezultatul poate fi influențat nu doar de miner, ci și de orice participant la protocol. Controlul asupra valorii în sine este în continuare posibil, cu o variabilitate mai mică și contra cost, dar, ca și în cazul minerului, dacă rezultatele extragerii valorează mai mult decât taxa de participare în protocolul PVRB, atunci producătorul de aleator (RP) poate decide dacă să facă reveal și poate alege în continuare din minimum două opțiuni de aleator.
În schimb, a apărut posibilitatea de a penaliza pe cei care fac commit și nu fac reveal, iar această schemă va fi utilă. Simplitatea sa este un avantaj serios — protocoalele mai serioase necesită calculi mult mai puternici.

PVRB și semnături determinate.

Există o altă metodă de a face RP să furnizeze un număr pseudo-aleatoriu asupra căruia nu poate influența, dacă i se oferă un „exemplar” – aceasta este o semnătură deterministă. O semnătură de acest tip este, de exemplu, RSA, și nu este ECS. Dacă RP are o pereche de chei: RSA și EСC, și semnează cu cheia sa privată o anumită valoare, în cazul RSA va obține O SINGURĂ SEMNĂTURĂ, iar în cazul ECS – el poate genera un număr nelimitat de semnături valide diferite. Acest lucru se datorează faptului că, la crearea semnăturii ECS, se folosește un număr aleatoriu ales de semnatar, iar acesta poate fi ales în orice mod, dând semnatarului posibilitatea de a alege dintre mai multe semnături. În cazul RSA: „o valoare de intrare” + „o pereche de chei” = „o semnătură”. Nu se poate prezice care va fi semnătura unui alt RP, prin urmare, PVRB cu semnături deterministe poate fi organizat prin combinarea semnăturilor RSA ale mai multor participanți care au semnat aceeași valoare. De exemplu – numărul aleatoriu precedent. În acest sistem se economisesc multe resurse, deoarece semnăturile sunt simultan și o confirmare a corectitudinii comportamentului conform protocolului, și o sursă de aleatoriu.

Cu toate acestea, chiar și cu semnături deterministe, schema rămâne vulnerabilă la problema „ultimului actor”. Ultimul participant poate încă decide dacă publică semnătura sau nu, controlând astfel rezultatul. Schema poate fi îmbunătățită, adăugând hash-uri ale blocurilor, realizând runde, astfel încât rezultatul să nu poată fi prevăzut dinainte, dar toate aceste tehnici, chiar și cu numeroasele îmbunătățiri, lasă totuși nerezolvată problema influenței unui singur participant asupra rezultatului colectiv într-un mediu neîncrezător și pot funcționa doar în condiții de restricții economice și de timp. În plus, dimensiunea cheilor RSA (1024 și 2048 biți) este destul de mare, iar dimensiunea pentru tranzacțiile blockchain este un parametru extrem de important. Se pare că nu se poate rezolva problema în mod simplu, așa că mergem mai departe.

În criptografie există scheme care pot permite rețelei să ajungă la un singur și unic PVRB, aceste scheme fiind rezistente la orice acțiuni malițioase din partea participanților. Unul dintre protocoalele utile de explorat este schema de împărțire a secretului a lui Shamir. Aceasta servește pentru a împărți un secret (de exemplu, o cheie secretă) în mai multe părți, care sunt distribuite celor N participanți. Secretul este distribuit astfel încât pentru a-l recupera, sunt suficiente M părți din N, iar acestea pot fi orice M părți. Pe scurt, având un grafic al unei funcții necunoscute, participanții schimbă puncte de pe grafic, și după obținerea a M puncte, întreaga funcție poate fi recuperată.
O explicație bună este oferită în wiki și să experimentați practic, pentru a înțelege protocolul mai bine, este util să accesați demo pagina.

Dacă schema FSSS (Fiat-Shamir Secret Sharing) ar fi aplicabilă în forma sa pură, ar fi un PVRB imposibil de distrus. În cea mai simplă variantă, protocolul ar putea arăta astfel:

Fiecare participant generează propriul random și distribuie shares din acesta celorlalți participanți.
Fiecare participant dezvăluie partea sa din secretele celorlalți participanți.
Dacă pentru un participant s-au acumulat mai mult de M shares, atunci numărul acestui participant poate fi calculat și va fi unic, indiferent de setul de participanți care au dezvăluit informații.
Combinația de random-uri dezvăluite este PVRB-ul dorit.

Aici, un participant separat nu mai influențează rezultatele protocolului, cu excepția cazurilor în care atingerea pragului de dezvăluire a random-ului depinde exclusiv de el. Prin urmare, acest protocol, având procentul necesar de participanți care respectă protocolul și RP-uri disponibile, funcționează, îndeplinind cerințele de rezistență criptografică și fiind rezistent la problema „ultimului actor”.

Aceasta ar putea fi opțiunea ideală, această schemă PVRB bazată pe împărțirea secretului Fiat-Shamir este descrisă, de exemplu, în această articol. Dar, așa cum s-a spus mai sus, dacă se încearcă aplicarea acesteia direct în blockchain, apar deja limitări tehnice. Iată un exemplu de implementare de testare a protocolului într-un smart contract EOS și cea mai importantă parte a acestuia — verificarea share-ului publicat de participant: cod. Din cod, se observă că validarea proof-ului necesită mai multe înmulțiri scalare, iar numerele folosite sunt foarte mari. Este important de înțeles că, în blockchain-uri, verificarea se întâmplă în momentul în care producătorul de blocuri procesează tranzacția, iar orice participant ar trebui să poată verifica ușor corectitudinea protocolului, de aceea cerințele pentru viteza funcției de verificare sunt foarte serioase. În această variantă, soluția s-a dovedit a fi nefuncțională, deoarece verificarea nu se încadra în limita de timp a tranzacției (0,5 sec).

Eficiența verificării este una dintre cele mai importante cerințe pentru utilizarea oricăror scheme cryptografice avansate în blockchain. Crearea de proof-uri, pregătirea mesajelor — aceste proceduri pot fi efectuate off-chain pe computere de înaltă performanță, dar verificarea nu poate fi ocolită — aceasta este o altă cerință importantă pentru PVRB.

PVRB și semnăturile threshold

După ce ne-am familiarizat cu schema de secret sharing, am descoperit o întreagă clasă de protocoale unite prin cuvântul cheie “threshold”. Atunci când pentru dezvăluirea unei informații este necesară participarea a M participanți onești din N, iar setul de participanți onești poate fi orice submultime a lui N, se vorbește despre schemele “threshold”. Acestea permit soluționarea problemei “last actor”, astfel încât, dacă un atacator nu își dezvăluie partea din secret, un alt participant onest o va face în locul lui. Aceste scheme permit că acordarea unui singur și unic valorii, chiar și în condițiile sabotării protocolului de către o parte dintre participanți.

Combinarea semnăturilor deterministe cu schemele threshold a dus la dezvoltarea unei scheme foarte convenabile și promițătoare pentru implementarea PVRB — este vorba despre semnăturile threshold deterministe. Aici articol despre diversele aplicații ale semnăturilor threshold, iar aici un alt exemplu bun longread de la Dash.

Articolul final descrie semnăturile BLS (BLS se deosebește prin Boneh-Lynn-Shacham, iată articolul ), care au o calitate foarte importantă și extrem de convenabilă pentru programatori - cheile publice, secrete, cheile publice și semnăturile BLS pot fi combinate între ele prin operații matematice simple, păstrându-se astfel valabilitatea lor ca chei și semnături, permițând agregarea ușoară a multor semnături într-o singură semnătură și a multor chei publice într-o singură cheie. De asemenea, ele sunt deterministe și pentru aceleași date de intrare returnează același rezultat. Datorită acestei calități, combinațiile de semnături BLS sunt ele însele chei valabile, ceea ce permite un scenariu în care M din N participanți generează o singură semnătură, care este determinată, public verificabilă și imprevizibilă până când este dezvăluită de cel de-al M-lea participant.

În schema cu semnături BLS cu threshold, fiecare participant semnează prin BLS ceva (de exemplu, un random anterior), iar semnătura totală cu threshold este randomul dorit. Proprietățile criptografice ale semnăturilor BLS satisfac cerințele de calitate ale randomului, partea de threshold protejează împotriva „ultimului actor”, iar combinabilitatea unică a cheilor permite implementarea multor algoritmi interesanți care permit, de exemplu, agregarea eficientă a mesajelor protocolului.

Așadar, dacă construiești PVRB în blockchain-ul tău, este foarte probabil să ajungi la schema semnăturilor BLS cu threshold, care este deja utilizată de mai multe proiecte. De exemplu, DFinity (aici benchmark ce implementează schema, și aici un exemplu de implementare a împărtășirii secrete verificabile), sau Keep.network (iată beaconul lor random yellowpaper, dar iată exemplu al contractului inteligent care administrează protocolul).

Implementarea PVRB

Din păcate, încă nu vedem un protocol PVRB finalizat, implementat în blockchain, care să-și fi demonstrat securitatea și reziliența. Deși protocoalele sunt gata, aplicarea lor tehnică la soluțiile existente nu este simplă. Pentru sistemele centralizate, PVRB nu are niciun sens, iar cele descentralizate sunt strict limitate în toate resursele computaționale: CPU, memorie, stocare, I/O. Proiectarea PVRB constă în combinarea diferitelor protocoale pentru a crea ceva care să corespundă tuturor cerințelor, măcar pentru un blockchain viabil. Un protocol calculează mai eficient, dar necesită mai multe mesaje între RP, iar altul necesită extrem de puține mesaje, dar generarea dovezii poate dura zeci de minute, dacă nu chiar ore.

Voi lista factorii pe care va trebui să îi iei în considerare atunci când alegi un PVRB de calitate:

Rezistența criptografică. PVRB-ul tău trebuie să fie strict neîmbiasabil, fără posibilitatea de a controla un singur bit. În unele scheme, acest lucru nu este adevărat, așa că cheamă un criptograf.
Problema „ultimului actor”. PVRB-ul tău trebuie să fie rezistent la atacuri în care atacatorul, controlând unul sau mai mulți RP, poate alege între două rezultate posibile.
Problema sabotării protocolului. PVRB-ul tău trebuie să fie rezistent la atacuri în care atacatorul, controlând unul sau mai mulți RP, decid dacă să fie aleatoriu sau nu și poate influența garantat, sau cu o probabilitate dată, acest lucru.
Problema numărului de mesaje. RP-urile tale trebuie să trimită în blockchain un minim de mesaje și să evite cât mai mult situațiile de acțiune sincronă, cum ar fi „am trimis o informație, aștept răspuns de la un anumit participant”. În rețelele p2p, mai ales cele geografic distribuite, nu ar trebui să te aștepți la un răspuns rapid.
Problema complexității de calcul. Verificarea oricărei etape a PVRB on-chain trebuie să fie extrem de ușoară, deoarece este efectuată de toate clienții compleți din rețea. Dacă implementarea se face printr-un contract inteligent, cerințele de viteză sunt foarte stricte.
Problema disponibilității și activității. PVRB-ul tău trebuie să t streven la rezistența în situațiile în care o parte a rețelei devine inaccesibilă pentru o perioadă de timp și o parte a RP-urilor pur și simplu încetează să funcționeze.
Problema configurării de încredere și distribuției inițiale a cheilor. Dacă PVRB-ul dvs. utilizează configurarea protocolului principal, atunci aceasta este o poveste separată, mare și serioasă. Iată exemplu. Dacă participanții trebuie să își comunice cheile înainte de începutul protocolului — aceasta este și o problemă, dacă componența participanților se schimbă
Probleme de dezvoltare. Disponibilitatea bibliotecilor în limbile necesare, securitatea și performanța acestora, publicitatea, teste complexe și așa mai departe.

De exemplu, la semnăturile BLS cu threshold există o problemă semnificativă — înainte de a începe să lucreze, participanții trebuie neapărat să își distribuie cheile între ei, organizând un grup în cadrul căruia va funcționa threshold-ul. Asta înseamnă că va trebui să așteptați cel puțin un tur de schimburi într-o rețea descentralizată, și, având în vedere că numărul aleator generat, de exemplu, este necesar în jocuri, aproape în timp real, aceasta înseamnă că sabotajul protocolului este posibil în această etapă, iar avantajele schemei threshold sunt pierdute. Această problemă este mai simplă decât cele anterioare, dar tot necesită dezvoltarea unei proceduri separate pentru formarea grupurilor de threshold, care va trebui protejată din punct de vedere economic, prin depozite și prin penalizări (slashing) pentru participanții care nu respectă protocolul. De asemenea, verificarea BLS cu un nivel acceptabil de securitate pur și simplu nu se încadrează, de exemplu, în tranzacția standard EOS sau Ethereum — pur și simplu nu există suficient timp pentru verificare. Codul contractelor — este WebAssembly sau EVM, executat de o mașină virtuală. Funcțiile criptografice nu sunt implementate nativ (încă), și funcționează de zeci de ori mai încet decât bibliotecile criptografice obișnuite. Multe protocoale nu se potrivesc cerințelor pur și simplu din cauza volumului cheilor, de exemplu, acestea sunt 1024 și 2048 de biți pentru RSA, de 4-8 ori mai mult decât semnătura standard a tranzacției în Bitcoin și Ethereum.

De asemenea, joacă un rol și disponibilitatea implementărilor în diferite limbaje de programare — care sunt puține, în special pentru protocoalele noi. Opțiunea de integrare în consens necesită scrierea protocolului în limbajul platformei, astfel că va trebui să căutați cod în Go pentru geth, în Rust pentru Parity, în C++ pentru EOS. Codul în JavaScript va trebui să fie căutat de toată lumea, iar având în vedere că JavaScript și criptografia nu sunt tocmai prieteni apropiați, WebAssembly va ajuta, care acum cu siguranță aspiră la rolul de următor standard important în internet.

Concluzie

Sper că în precedentul pe care l-ați citit Am reușit să te conving că generarea numerelor aleatoare pe blockchain este critică pentru multe aspecte ale vieții rețelelor descentralizate, iar prin acest articol am demonstrat că această sarcină este extrem de ambițioasă și complicată, dar soluții bune există deja. În general, designul final al protocolului este posibil doar după efectuarea unor teste masive, care iau în considerare toate aspectele, de la configurare până la simularea defectelor, așadar este puțin probabil să găsești rețete gata făcute în whitepaper-urile echipelor sau în articole, iar noi cu siguranță nu ne vom decide să scriem „faceți așa, așa este exact corect” în următorii un-doi ani.

Până acum, pentru PVRB-ul nostru în blockchain-ul în dezvoltare Haya, ne-am oprit la aplicarea semnăturilor BLS cu prag, planificând implementarea PVRB la nivelul consensului, deoarece verificarea în smart contracte cu un nivel de securitate acceptabil este în prezent imposibilă. Este posibil să folosim două scheme: inițial o schemă costisitoare de secret sharing pentru a crea un random_seed pe termen lung, pe care îl utilizăm ulterior ca bază pentru generarea frecventă a aleatoarelor prin semnături BLS cu prag deterministice; poate ne vom limita doar la una dintre scheme. Din păcate, nu putem spune din timp cum va arăta protocolul, dar ne bucură că, la fel ca în știință, în sarcinile inginerești, un rezultat negativ este tot un rezultat, iar fiecare nouă încercare de a rezolva problema este o altă treaptă pentru cercetările tuturor celor care se ocupă de această problemă. Pentru a îndeplini cerințele din partea afacerilor, ne concentrăm pe o sarcină practică specifică - asigurarea aplicațiilor de jocuri cu o sursă de entropie fiabilă, așa că trebuie să acordăm atenție și blockchain-ului în sine, în special problemelor de finalitate a lanțului și de guvernare a rețelei.

Și, deși momentan nu vedem în blockchain-uri un PVRB dovedit rezistent, care a fost utilizat suficient de mult timp pentru a trece prin teste cu aplicații reale, auditurile multiple, sarcinile de lucru și, desigur, atacurile reale, dar numărul posibilităților confirmă că soluția există, iar unul dintre aceste algoritmi va rezolva în cele din urmă problema. Vom fi bucuroși să împărtășim rezultatele și mulțumim altor echipe care se ocupă de această problemă pentru articolele și codul care permit inginerilor să nu calce de două ori pe aceleași greble.

Așadar, atunci când întâlniți un programator care proiectează un randomizat descentralizat, fiți atenți și grijulii, oferiți suport psihologic dacă este necesar 🙂

Sursa: habr.com