Introducere

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

Ca și în cazul conceptului unui cifr absolut puternic din criptografie, protocoalele reale „Publicly Verifiable Random Beacon” (denumite în continuare PVRB) încearcă doar să se apropie cât mai mult de schema ideală, deoarece în rețelele reale nu este aplicabil în forma sa pură: este necesar să fiți de acord strict pe un bit, trebuie să fie multe runde, iar toate mesajele trebuie să fie perfect rapide și întotdeauna livrate. Desigur, acest lucru nu este cazul în rețelele reale. Prin urmare, atunci când se proiectează PVRB-uri pentru sarcini specifice în blockchain-urile moderne, pe lângă imposibilitatea de a controla aleatoritatea rezultată și puterea criptografică, apar multe alte probleme pur arhitecturale și tehnice.

Pentru PVRB, blockchain-ul în sine este în esență un mediu de comunicare în care mesajele = tranzacții. Acest lucru vă permite să faceți abstracție parțială de la problemele de rețea, nelivrarea mesajelor, problemele cu middleware - toate aceste riscuri sunt asumate de rețeaua descentralizată, iar valoarea sa principală pentru PVRB este incapacitatea de a revoca sau de a corupe o tranzacție deja trimisă - acest lucru nu nu permite participanților să refuze să participe la protocol, cu excepția cazului în care au efectuat un atac cu succes la consens. Acest nivel de securitate este acceptabil, așa că PVRB ar trebui să fie rezistent la coluziune a participanților exact în aceeași măsură ca și lanțul principal de blockchain. De asemenea, acest lucru sugerează că PVRB trebuie să facă parte din consens dacă rețeaua este de acord cu blockchain-ul principal, chiar dacă este de acord și cu singurul rezultat aleatoriu corect. Sau, PVRB este pur și simplu un protocol autonom implementat printr-un contract inteligent care funcționează asincron în ceea ce privește blockchain-ul și blocurile. Ambele metode au avantajele și dezavantajele lor, iar alegerea dintre ele este extrem de nebanală.

Două moduri de implementare a PVRB

Să descriem mai detaliat două opțiuni pentru implementarea PVRB - versiunea independentă, care funcționează folosind un contract inteligent independent de blockchain, și versiunea integrată în consens, încorporată în protocol, conform căreia rețeaua este de acord cu blockchain și tranzacțiile care urmează să fie incluse. În toate cazurile, mă voi referi la motoarele blockchain populare: Ethereum, EOS și toate cele asemănătoare lor în modul în care găzduiesc și procesează contractele inteligente.

Contract autonom

În această versiune, PVRB este un contract inteligent care acceptă tranzacții ale producătorilor aleatori (denumit în continuare RP), le prelucrează, combină rezultatele și, ca urmare, ajunge la o anumită valoare pe care orice utilizator o poate primi din acest contract. Această valoare poate să nu fie stocată direct în contract, ci mai degrabă să fie reprezentată doar de date din care se poate obține în mod determinist una și o singură valoare a aleatoriei rezultate. În această schemă, RP-urile sunt utilizatori ai blockchain-ului și oricui i se poate permite să participe la procesul de generare.

Opțiunea cu contract independent este bună:

• portabilitate (contractele pot fi trase de la blockchain la blockchain)
• ușurință în implementare și testare (contractele sunt ușor de scris și testat)
• comoditate în implementarea schemelor economice (este ușor să-ți faci propriul token, a cărui logică servește scopurilor PVRB)
• posibilitatea lansării pe blockchain-uri deja funcționale

Are si dezavantaje:

• limitări puternice ale resurselor de calcul, volumului tranzacțiilor și stocării (cu alte cuvinte, cpu/mem/io)
• restricții privind operațiunile din cadrul contractului (nu toate instrucțiunile sunt disponibile, este dificil să conectați biblioteci externe)
• incapacitatea de a organiza mesajele mai repede decât tranzacțiile sunt incluse în blockchain

Această opțiune este potrivită pentru implementarea unui PVRB care trebuie rulat pe o rețea existentă, nu conține criptografie complexă și nu necesită un număr mare de interacțiuni.

Consens integrat

În această versiune, PVRB este implementat în codul nodului blockchain, încorporat sau rulând în paralel cu schimbul de mesaje între nodurile blockchain. Rezultatele protocolului sunt scrise direct în blocurile produse, iar mesajele de protocol sunt trimise prin rețeaua p2p între noduri. Deoarece protocolul are ca rezultat numere care urmează să fie scrise în blocuri, rețeaua trebuie să ajungă la un consens asupra lor. Aceasta înseamnă că mesajele PVRB, precum tranzacțiile, trebuie validate de noduri și incluse în blocuri, astfel încât orice participant la rețea să poată valida conformitatea cu protocolul PVRB. Acest lucru ne conduce automat la soluția evidentă - dacă rețeaua este de acord cu un consens cu privire la un bloc și tranzacțiile în acesta, atunci PVRB ar trebui să facă parte din consens, și nu un protocol de sine stătător. Altfel, este posibil ca un bloc să fie valabil din punct de vedere consensual, dar protocolul PVRB nu este respectat, iar din punct de vedere PVRB blocajul nu poate fi acceptat. Deci, dacă se alege opțiunea „integrată în consens”, PVRB devine o parte importantă a consensului.

Când descriem implementările PVRB la nivel de consens al rețelei, nu se poate evita în niciun caz problemele de finalitate. Finalitatea este un mecanism folosit în consensurile deterministe care comite un bloc (și lanțul care duce la acesta) care este definitiv și nu va fi niciodată aruncat, chiar dacă apare o bifurcătură paralelă. De exemplu, în Bitcoin nu există un astfel de mecanism - dacă publicați un lanț de complexitate mai mare, acesta îl va înlocui pe unul mai puțin complex, indiferent de lungimea lanțurilor. Iar în EOS, de exemplu, cele finale sunt așa-numitele Ultimele Blocuri Irreversibile, care apar în medie la fiecare 432 de blocuri (12*21 + 12*15, pre-vot + pre-commit). Acest proces așteaptă în esență 2/3 din semnăturile producătorilor de bloc (denumite în continuare BP). Când apar furci care sunt mai vechi decât ultimul LIB, ele sunt pur și simplu aruncate. Acest mecanism face posibilă garantarea faptului că tranzacția este inclusă în blockchain și nu va fi niciodată anulată, indiferent de resursele pe care le are atacatorul. De asemenea, blocurile finale sunt blocuri semnate de 2/3 BP în Hyperledger, Tendermint și alte consensuri bazate pe pBFT. De asemenea, are sens să se realizeze un protocol pentru asigurarea finalității, un supliment pentru consens, deoarece poate funcționa asincron cu producerea și publicarea blocurilor. Iată una bună articol despre finalitatea în Ethereum.

Finalitatea este extrem de importantă pentru utilizatori, care fără ea se pot găsi victimele unui atac de „cheltuire dublă”, în care BP „deține” blocuri și le publică după ce rețeaua a „văzut” o tranzacție bună. Dacă nu există o finalitate, atunci fork-ul publicat înlocuiește blocul cu o tranzacție „bună” cu alta, dintr-un fork „rea”, în care aceleași fonduri sunt transferate la adresa atacatorului. În cazul PVRB, cerințele de finalitate sunt și mai stricte, deoarece construirea de furcături pentru PVRB înseamnă oportunitatea ca un atacator să pregătească mai multe opțiuni aleatorii pentru a o publica pe cea mai profitabilă, iar limitarea timpului unui posibil atac este o buna solutie.

Prin urmare, cea mai bună opțiune este de a combina PVRB și finalitatea într-un singur protocol - apoi blocul finalizat = finalizat aleatoriu, și asta este exact ceea ce trebuia să obținem. Acum, jucătorii vor primi o aleatorie garantată în N secunde și pot fi siguri că este imposibil să o derulați înapoi sau să o redați din nou.

Opțiunea integrată în consens este bună:

• posibilitatea implementării asincrone în raport cu producția de blocuri - blocurile sunt produse ca de obicei, dar în paralel cu aceasta poate funcționa și protocolul PVRB, care nu produce aleatoriu pentru fiecare bloc
• capacitatea de a implementa chiar și criptografia grea, fără restricțiile impuse contractelor inteligente
• capacitatea de a organiza schimbul de mesaje mai rapid decât tranzacțiile sunt incluse în blockchain, de exemplu, o parte a protocolului poate funcționa între noduri fără a distribui mesaje în rețea

Are si dezavantaje:

• Dificultăți în testare și dezvoltare - va trebui să emulați erori de rețea, noduri lipsă, hard fork-uri de rețea
• Erorile de implementare necesită un hardfork de rețea

Ambele metode de implementare a PVRB au drept la viață, dar implementarea pe contracte inteligente în blockchain-urile moderne este încă destul de limitată în resursele de calcul și orice tranziție la o criptografie serioasă este adesea pur și simplu imposibilă. Și vom avea nevoie de criptografie serioasă, așa cum va fi demonstrat mai jos. Deși această problemă este în mod clar temporară, este necesară o criptare serioasă în contracte pentru a rezolva multe probleme și apare treptat (de exemplu, contracte de sistem pentru zkSNARK-uri în Ethereum)

Blockchain, care oferă un canal de mesagerie prin protocol transparent și de încredere, nu face acest lucru gratuit. Orice protocol descentralizat trebuie să țină cont de posibilitatea unui atac Sybil; orice acțiune poate fi făcută de forțele concertate ale mai multor conturi, prin urmare, la proiectare, este necesar să se țină cont de capacitatea atacatorilor de a crea un număr arbitrar de protocol participanții care acționează în coluziune.

PVRB și variabile bloc.

Nu am mințit când am spus că nimeni nu a implementat încă un PVRB bun, testat de multe aplicații de jocuri de noroc, în blockchain. Atunci de unde provin atâtea aplicații de jocuri de noroc pe Ethereum și EOS? Acest lucru mă surprinde la fel de mult pe cât te surprinde pe tine, de unde au obținut atâtea aleatorii „persistente” într-un mediu complet determinist?

Modul preferat de a obține aleatorie în blockchain este să luați un fel de informații „imprevizibile” din bloc și să faceți una aleatoare pe baza acesteia - pur și simplu prin hashing una sau mai multe valori. Bun articol despre problemele unor astfel de scheme aici. Puteți lua oricare dintre valorile „imprevizibile” din bloc, de exemplu, hash-ul blocului, numărul de tranzacții, complexitatea rețelei și alte valori necunoscute în avans. Apoi, trimiți-le, unul sau mai multe, și, teoretic, ar trebui să obții o adevărată aleatorie. Puteți chiar să adăugați la hârtia liberă că schema dvs. este „securizată post-cuantică” (deoarece există funcții hash cuantice :)).

Dar nici măcar hashurile securizate post-cuantice nu sunt suficiente, din păcate. Secretul constă în cerințele pentru PVRB, permiteți-mi să vă reamintesc de ele din articolul anterior:

1. Rezultatul trebuie să aibă o distribuție uniformă dovedit, adică să se bazeze pe o criptografie puternică.
2. Nu este posibil să controlați niciunul dintre biții din rezultat. În consecință, rezultatul nu poate fi prevăzut în avans.
3. Nu puteți sabota protocolul de generare neparticipând la protocol sau supraîncărcând rețeaua cu mesaje de atac
4. Toate cele de mai sus trebuie să fie rezistente la coluziunea unui număr permis de participanți la protocol necinstiți (de exemplu, 1/3 dintre participanți).

În acest caz, este îndeplinită doar cerința 1, iar cerința 2 nu este îndeplinită. Prin hashing a valorilor imprevizibile din bloc, vom obține o distribuție uniformă și aleatorii bune. Dar BP are cel puțin opțiunea de a „publica blocul sau nu”. Astfel, BP poate alege cel puțin dintre DOUĂ opțiuni aleatorii: „propria” și cea care se va dovedi dacă altcineva face blocarea. BP poate „snoop” în avans ce se va întâmpla dacă publică un bloc și pur și simplu decide să o facă sau nu. Astfel, când joacă, de exemplu, „par-impar” sau „roșu/negru” la ruletă, el poate publica un bloc numai dacă vede un câștig. Acest lucru face, de asemenea, imposibilă strategia de utilizare, de exemplu, a unui bloc hash „din viitor”. În acest caz, ei spun că „se va folosi aleatoriu, care este obținut prin hașarea datelor curente și hash-ul unui bloc viitor cu o înălțime de, de exemplu, N + 42, unde N este înălțimea curentă a blocului. Acest lucru întărește puțin schema, dar îi permite totuși BP, deși în viitor, să aleagă dacă să mențină blocul sau să publice.

Software-ul BP în acest caz devine mai complicat, dar nu mult. Pur și simplu, la validarea și includerea unei tranzacții într-un bloc, există o verificare rapidă pentru a vedea dacă va exista un câștig și, eventual, selectarea parametrilor unei tranzacții pentru a obține o probabilitate mare de câștig. În același timp, este aproape imposibil să prinzi un BP inteligent pentru astfel de manipulări; de fiecare dată poți folosi adrese noi și poți câștiga încetul cu încetul fără a trezi suspiciuni.

Deci metodele care utilizează informații din bloc nu sunt potrivite ca implementare universală a PVRB. Într-o versiune limitată, cu restricții privind mărimile pariurilor, restricții privind numărul de jucători și/sau înregistrarea KYC (pentru a împiedica un jucător să folosească mai multe adrese), aceste scheme pot funcționa pentru jocuri mici, dar nimic mai mult.

PVRB și commit-reveal.

Bine, datorită hashingului și cel puțin impredictibilității relative a hash-ului blocului și a altor variabile. Dacă rezolvați problema minerilor de front, ar trebui să obțineți ceva mai potrivit. Să adăugăm utilizatori la această schemă - lăsați-i să influențeze și aleatorietatea: orice angajat al suportului tehnic vă va spune că cel mai aleatoriu lucru în sistemele IT sunt acțiunile utilizatorilor :)

O schemă naivă, când utilizatorii trimit pur și simplu numere aleatoare și rezultatul este calculat ca, de exemplu, un hash al sumei lor, nu este potrivită. În acest caz, ultimul jucător poate, alegându-și propria aleatorie, să controleze care va fi rezultatul. Acesta este motivul pentru care este utilizat modelul commit-reveal foarte utilizat. Participanții trimit mai întâi hashe-uri din random-urile lor (commit-uri), apoi deschid ei înșiși random-urile (reveles). Faza de „dezvăluire” începe numai după ce au fost colectate commit-urile necesare, astfel încât participanții pot trimite exact hash-ul aleatoriu din care au trimis mai devreme. Acum, să punem toate acestea împreună cu parametrii unui bloc și mai bine decât unul luat din viitor (aleatoriu poate fi găsit doar într-unul dintre blocurile viitoare) și voilà - aleatorietatea este gata! Acum, orice jucător influențează aleatoritatea rezultată și poate „înfrânge” BP rău intenționat, depășindu-l cu aleatorii ale sale, necunoscute în avans... Puteți adăuga, de asemenea, protecție împotriva sabotării protocolului, nedeschizându-l în stadiul de revelare - pur și simplu prin solicitarea ca o anumită sumă să fie atașată tranzacției la angajare — un depozit de garanție, care va fi returnat numai în timpul procedurii de dezvăluire. În acest caz, angajarea și nu dezvăluirea vor fi neprofitabile.

A fost o încercare bună și astfel de scheme există și în DApps pentru jocuri, dar, din păcate, acest lucru nu este suficient. Acum, nu numai minerul, ci și orice participant la protocol poate influența rezultatul. Este încă posibil să se controleze valoarea în sine, cu mai puțină variabilitate și cu un cost, dar, ca și în cazul minerului, dacă rezultatele extragerii sunt mai valoroase decât taxa de participare la protocolul PVRB, atunci aleatoriu -producătorul (RP) poate decide dacă să dezvăluie și poate alege din cel puțin două opțiuni aleatorii.
Dar a devenit posibil să-i pedepsești pe cei care comit și nu dezvăluie, iar această schemă va fi utilă. Simplitatea sa este un avantaj serios - protocoalele mai serioase necesită calcule mult mai puternice.

PVRB și semnături deterministe.

Există o altă modalitate de a forța RP să furnizeze un număr pseudo-aleatoriu pe care nu îl poate influența dacă este prevăzut cu o „preimagine” - aceasta este o semnătură deterministă. O astfel de semnătură este, de exemplu, RSA și nu este ECS. Dacă RP are o pereche de chei: RSA și ECC, și semnează o anumită valoare cu cheia sa privată, atunci în cazul RSA va obține UNA ȘI O SINGĂ semnătură, iar în cazul ECS poate genera orice număr de diferite semnături valabile. Acest lucru se datorează faptului că la crearea unei semnături ECS se folosește un număr aleatoriu, ales de semnatar, și acesta poate fi ales în orice mod, oferindu-i semnatarului posibilitatea de a alege una dintre mai multe semnături. În cazul RSA: „o valoare de intrare” + „o pereche de chei” = „o semnătură”. Este imposibil de prezis ce semnătură va obține un alt RP, așa că un 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, aleatoria anterioară. Această schemă economisește o mulțime de resurse, deoarece semnăturile sunt atât o confirmare a comportamentului corect conform protocolului, cât și o sursă de aleatorie.

Cu toate acestea, chiar și cu semnături deterministe, schema este încă vulnerabilă la problema „ultimului actor”. Ultimul participant poate decide în continuare dacă publică sau nu semnătura, controlând astfel rezultatul. Puteți modifica schema, puteți adăuga hash-uri de bloc, puteți face runde astfel încât rezultatul să nu poată fi prezis în avans, dar toate aceste tehnici, chiar și ținând cont de multe modificări, încă lasă nerezolvată problema influenței unui participant asupra colectivului. rezultă într-un mediu neîncrezător și poate funcționa numai în condiț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 există o modalitate simplă de a rezolva problema, să mergem mai departe.

PVRB și scheme de partajare secretă

În criptografie, există scheme care pot permite rețelei să convină asupra unei singure valori PVRB, în timp ce astfel de scheme sunt rezistente la orice acțiuni rău intenționate ale unor participanți. Un protocol util cu care merită să vă familiarizați este schema de partajare secretă a lui Shamir. Servește pentru a împărți un secret (de exemplu, o cheie secretă) în mai multe părți și pentru a distribui aceste părți la N participanți. Secretul este distribuit în așa fel încât M părți din N sunt suficiente pentru a-l recupera, iar acestea pot fi orice M părți. Dacă pe degete, atunci având un grafic al unei funcții necunoscute, participanții fac schimb de puncte pe grafic, iar după ce primesc M puncte, întreaga funcție poate fi restaurată.
O explicație bună este dată Wiki dar jocul cu el practic pentru a reda protocolul din cap este util pt Demo pagină.

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

• Fiecare participant își generează propria lor aleatorie și distribuie acțiuni de la acesta altor participanți
• Fiecare participant își dezvăluie partea sa din secretele celorlalți participanți
• Dacă un participant are mai mult de M acțiuni, atunci numărul acestui participant poate fi calculat și va fi unic, indiferent de setul de participanți revelați
• Combinația de aleatorii revelate este PVRB dorit

Aici, un participant individual nu mai influențează rezultatele protocolului, cu excepția cazurilor în care atingerea pragului de dezvăluire ale aleatoriei depinde numai de el. Prin urmare, acest protocol, dacă există o proporție necesară de RP care lucrează pe protocol și sunt disponibile, funcționează, implementând cerințele pentru puterea criptografică și fiind rezistent la problema „ultimului actor”.

Aceasta ar putea fi o opțiune ideală, această schemă PVRB bazată pe partajarea secretă Fiat-Shamir este descrisă, de exemplu, în acest articol. Dar, după cum am menționat mai sus, dacă încercați să o aplicați frontal în blockchain, apar limitări tehnice. Iată un exemplu de implementare de testare a protocolului în contractul inteligent EOS și cea mai importantă parte a acestuia - verificarea participantului la cota publicat: cod. Puteți vedea din cod că validarea dovezilor necesită mai multe înmulțiri scalare, iar numerele folosite sunt foarte mari. Trebuie înțeles că în blockchains, verificarea are loc în momentul în care producătorul de bloc procesează tranzacția și, în general, orice participant trebuie să verifice cu ușurință corectitudinea protocolului, astfel încât cerințele pentru viteza funcției de verificare sunt foarte serioase. . În această opțiune, opțiunea sa dovedit a fi ineficientă, deoarece verificarea nu s-a încadrat în limita tranzacției (0.5 secunde).

Eficiența verificării este una dintre cele mai importante cerințe pentru utilizarea, în general, a oricăror scheme criptografice avansate din blockchain. Crearea dovezilor, pregătirea mesajelor - aceste proceduri pot fi scoase din lanț și efectuate pe computere de înaltă performanță, dar verificarea nu poate fi ocolită - aceasta este o altă cerință importantă pentru PVRB.

PVRB și semnături de prag

După ce ne-am familiarizat cu schema de partajare secretă, am descoperit o întreagă clasă de protocoale unite prin cuvântul cheie „prag”. Când dezvăluirea unor informații necesită participarea a M participanți onești din N, iar setul de participanți onești poate fi un subset arbitrar al lui N, vorbim de scheme „prag”. Ei sunt cei care ne permit să ne ocupăm de problema „ultimului actor”, acum, dacă atacatorul nu dezvăluie partea sa din secret, un alt participant onest o va face pentru el. Aceste scheme permit acordul asupra unui singur sens, chiar dacă protocolul este sabotat de unii dintre participanți.

Combinația de semnături deterministe și scheme de prag a făcut posibilă dezvoltarea unei scheme foarte convenabile și promițătoare pentru implementarea PVRB - acestea sunt semnături de prag deterministe. Aici articol despre diferitele utilizări ale semnăturilor de prag și iată încă una bună longread de la Dash.

Ultimul articol descrie semnăturile BLS (BLS înseamnă Boneh-Lynn-Shacham, aici articol), care au o calitate foarte importantă și extrem de convenabilă pentru programatori - cheile publice, secrete, publice și semnăturile BLS pot fi combinate între ele folosind operații matematice simple, în timp ce combinațiile lor rămân chei și semnături valide, permițându-vă să agregați cu ușurință multe semnăturile într-una și mai multe chei publice într-una singură. Ele sunt, de asemenea, deterministe și produc același rezultat pentru aceleași date de intrare. Datorită acestei calități, combinațiile de semnături BLS sunt ele însele chei valide, ceea ce permite implementarea unei opțiuni în care M din N participanți produc una și o singură semnătură care este deterministă, verificabilă public și imprevizibilă până când este deschisă de către Mth. participant.

Într-o schemă cu semnături BLS de prag, fiecare participant semnează ceva folosind BLS (de exemplu, aleatoria anterioară), iar semnătura de prag comună este aleatoria dorită. Proprietățile criptografice ale semnăturilor BLS satisfac cerințele de calitate aleatoare, partea de prag protejează împotriva „ultimului actor”, iar combinabilitatea unică a cheilor face posibilă implementarea multor algoritmi interesanți care permit, de exemplu, agregarea eficientă a mesajelor de protocol. .

Deci, dacă construiți PVRB pe blockchain-ul dvs., cel mai probabil veți ajunge cu schema de semnături de prag BLS, mai multe proiecte îl folosesc deja. De exemplu, DFinity (aici benchmark care implementează circuitul și aici exemplu de implementare a partajării secrete verificabile) sau Keep.network (aici este farul lor aleatoriu hârtie galbenă, Dar exemplu contract inteligent care servește protocolul).

Implementarea PVRB

Din păcate, încă nu vedem un protocol gata implementat în blockchain-urile PVRB care să-și fi dovedit securitatea și stabilitatea. Chiar dacă protocoalele în sine sunt gata, aplicarea lor tehnic la soluțiile existente nu este ușoară. Pentru sistemele centralizate, PVRB nu are sens, iar cele descentralizate sunt strict limitate în toate resursele de calcul: CPU, memorie, stocare, I/O. Proiectarea unui PVRB este o combinație de protocoale diferite pentru a crea ceva care să îndeplinească toate cerințele pentru cel puțin un blockchain viabil. Un protocol calculează mai eficient, dar necesită mai multe mesaje între RP-uri, în timp ce celălalt necesită foarte puține mesaje, dar crearea unei dovezi poate fi o sarcină care durează zeci de minute sau chiar ore.

Voi enumera factorii pe care va trebui să îi luați în considerare atunci când alegeți un PVRB de calitate:

• Puterea criptografică. PVRB dvs. trebuie să fie strict imparțial, fără posibilitatea de a controla un singur bit. În unele scheme, acest lucru nu este cazul, așa că sunați la un criptograf
• Problema „ultimului actor”.. PVRB trebuie să fie rezistent la atacuri în care un atacator care controlează unul sau mai multe RP-uri poate alege unul dintre cele două rezultate.
• Problemă de sabotare a protocolului. PVRB trebuie să fie rezistent la atacuri în care un atacator care controlează unul sau mai multe RP-uri decide dacă să fie aleatoriu sau nu și poate fi garantat sau cu o probabilitate dată să influențeze acest lucru.
• Problemă cu numărul de mesaje. RP-urile dvs. ar trebui să trimită un minim de mesaje către blockchain și să evite pe cât posibil acțiunile sincrone, cum ar fi situații precum „Am trimis câteva informații, aștept un răspuns de la un anumit participant”. În rețelele p2p, în special în cele dispersate geografic, nu ar trebui să contați pe un răspuns rapid
• Problema complexității computaționale. Verificarea oricărei etape a PVRB în lanț ar trebui să fie extrem de ușoară, deoarece este efectuată de toți clienții completi ai rețelei. Dacă implementarea se face folosind un contract inteligent, atunci cerințele de viteză sunt foarte stricte
• Problema accesibilității și a vieții. PVRB ar trebui să se străduiască să fie rezistent la situațiile în care o parte a rețelei devine indisponibilă pentru o perioadă de timp și o parte din RP pur și simplu nu mai funcționează
• Problema setării de încredere și distribuției inițiale a cheilor. Dacă PVRB dvs. utilizează configurația principală a protocolului, atunci aceasta este o poveste separată mare și serioasă. Aici exemplu. Dacă participanții trebuie să-și spună reciproc cheile înainte de a începe protocolul, aceasta este și o problemă dacă compoziția participanților se schimbă
• Probleme de dezvoltare. Disponibilitatea bibliotecilor în limbile solicitate, securitatea și performanța acestora, publicitate, teste complexe etc.

De exemplu, semnăturile de prag BLS au o problemă semnificativă - înainte de a începe să lucreze, participanții trebuie să-și distribuie cheile unul altuia, organizând un grup în care va funcționa pragul. Aceasta înseamnă că cel puțin o rundă de schimb într-o rețea descentralizată va trebui să aștepte și, având în vedere că randul generat, de exemplu, este necesar în jocuri, aproape în timp real, asta înseamnă că sabotarea protocolului este posibilă în această etapă. , iar avantajele schemei de prag se pierd . Această problemă este deja mai simplă decât cele anterioare, dar necesită totuși dezvoltarea unei proceduri separate de formare a grupurilor de prag, care vor trebui protejate economic, prin depuneri și retrageri de fonduri (slashing) de la participanții care nu respectă protocol. De asemenea, verificarea BLS cu un nivel acceptabil de securitate pur și simplu nu se potrivește, de exemplu, într-o tranzacție standard EOS sau Ethereum - pur și simplu nu este suficient timp pentru verificare. Codul contractului 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 lent decât bibliotecile criptografice convenționale. Multe protocoale nu îndeplinesc cerințele pur și simplu bazate pe volumul cheilor, de exemplu 1024 și 2048 de biți pentru RSA, de 4-8 ori mai mare decât semnătura standard a tranzacției în Bitcoin și Ethereum.

Prezența implementărilor în diferite limbaje de programare joacă, de asemenea, un rol - dintre care sunt puține, în special pentru noile protocoale. Opțiunea cu integrare în consens necesită scrierea unui protocol în limbajul platformei, așa că va trebui să cauți cod în Go for geth, în Rust for Parity, în C++ pentru EOS. Toată lumea va trebui să caute cod JavaScript și, deoarece JavaScript și criptografia nu sunt prieteni deosebit de apropiați, WebAssembly va ajuta, care acum se pretinde cu siguranță a fi următorul standard important de internet.

Concluzie

sper in cea precedenta articol Am reușit să vă conving că generarea de numere aleatoare pe blockchain este critică pentru multe aspecte ale vieții rețelelor descentralizate, iar cu acest articol am arătat că această sarcină este extrem de ambițioasă și dificilă, dar soluții bune există deja. În general, proiectarea finală a protocolului este posibilă numai după efectuarea unor teste masive care iau în considerare toate aspectele, de la configurare la emularea erorilor, așa că este puțin probabil să găsiți rețete gata făcute în documentele și articolele echipei și cu siguranță nu vom găsi. decideți în următorul an sau doi scrieți „fă-o așa, exact corect”.

Pa, pentru PVRB-ul nostru din blockchain-ul în curs de dezvoltare Haya, ne-am hotărât să folosim semnături BLS de prag, intenționăm să implementăm PVRB la nivel de consens, deoarece verificarea în contractele inteligente cu un nivel acceptabil de securitate nu este încă posibilă. Este posibil să folosim două scheme simultan: în primul rând, partajarea secretă costisitoare pentru a crea semințe aleatoare pe termen lung și apoi să o folosim ca bază pentru generarea aleatorie de înaltă frecvență folosind semnături BLS cu prag determinist, poate ne vom limita doar la una dintre scheme. Din păcate, este imposibil să spunem în avans care va fi protocolul; singurul lucru bun este că, la fel ca în știință, în problemele de inginerie, un rezultat negativ este și un rezultat, iar fiecare nouă încercare de a rezolva problema este un alt pas pentru cercetarea tuturor celor implicați în problemă. Pentru a îndeplini cerințele de afaceri, rezolvăm o problemă practică specifică - furnizarea aplicațiilor de jocuri cu o sursă fiabilă de entropie, așa că trebuie să acordăm atenție și blockchain-ului în sine, în special problemelor legate de finalitatea lanțului și guvernanța rețelei.

Și chiar dacă nu vedem încă un PVRB rezistent dovedit în blockchain, care ar fi fost folosit suficient timp pentru a fi testat de aplicații reale, audituri multiple, încărcări și, bineînțeles, atacuri reale, dar numărul de căi posibile confirmă că o soluție există și care dintre acești algoritmi vor rezolva în cele din urmă problema. Vom fi bucuroși să împărtășim rezultatele și să mulțumim altor echipe care lucrează, de asemenea, la această problemă, pentru articole și coduri care le permit inginerilor să nu calce de două ori pe același rake.

Deci, atunci când întâlniți un programator care proiectează aleatoriu descentralizat, fiți atenți și grijulii și oferiți ajutor psihologic dacă este necesar :)

Sursa: www.habr.com