įvedimas

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

Kaip ir kriptografijos absoliučiai stipraus šifro samprata, realūs „viešai patikrinami atsitiktiniai švyturio“ (toliau PVRB) protokolai tik stengiasi kuo labiau priartėti prie idealios schemos, nes realiuose tinkluose jis netaikomas gryna forma: reikia griežtai susitarti dėl vieno bito, turi būti daug raundų, o visi pranešimai turi būti tobulai greiti ir visada pristatomi. Žinoma, realiuose tinkluose taip nėra. Todėl projektuojant PVRB konkrečioms užduotims šiuolaikinėse blokų grandinėse, be to, kad neįmanoma kontroliuoti atsirandančio atsitiktinumo ir kriptografinio stiprumo, iškyla daug daugiau grynai architektūrinių ir techninių problemų.

PVRB atveju pati blokų grandinė iš esmės yra komunikacijos terpė, kurioje pranešimai = operacijos. Tai leidžia iš dalies abstrahuotis nuo tinklo problemų, pranešimų nepristatymo, tarpinės programinės įrangos problemų – visą šią riziką prisiima decentralizuotas tinklas, o pagrindinė jo vertė PVRB yra nesugebėjimas atšaukti ar sugadinti jau išsiųstos operacijos – tai daroma. neleisti dalyviams atsisakyti dalyvauti protokole, nebent jie sėkmingai puolė siekti sutarimo. Toks saugumo lygis yra priimtinas, todėl PVRB turėtų būti atsparus dalyvių slaptiems susitarimams lygiai taip pat, kaip ir pagrindinė blokų grandinės grandinė. Be to, tai rodo, kad PVRB turi būti sutarimo dalis, jei tinklas susitaria dėl pagrindinės blokų grandinės, net jei jis taip pat susitaria dėl vienintelio teisingo atsitiktinio atsitiktinumo. Arba PVRB yra tiesiog atskiras protokolas, įgyvendintas išmaniąja sutartimi, kuri veikia asinchroniškai blokų grandinės ir blokų atžvilgiu. Abu metodai turi savo privalumų ir trūkumų, o pasirinkimas tarp jų yra itin nereikšmingas.

Du būdai įgyvendinti PVRB

Leiskite mums išsamiau apibūdinti du PVRB diegimo variantus - atskirą versiją, kuri veikia naudojant išmaniąją sutartį, nepriklausomą nuo blokų grandinės, ir sutarimu integruotą versiją, integruotą į protokolą, pagal kurią tinklas susitaria dėl blokų grandinės ir sandoriai, kurie turi būti įtraukti. Visais atvejais turiu omenyje populiarius blokų grandinės variklius: Ethereum, EOS ir visus panašius į juos tuo, kaip jie talpina ir apdoroja išmaniąsias sutartis.

Atskira sutartis

Šioje versijoje PVRB yra išmanioji sutartis, kuri priima atsitiktinių gamintojų sandorius (toliau – RP), juos apdoroja, sujungia rezultatus ir dėl to pasiekia tam tikrą vertę, kurią iš šios sutarties gali gauti bet kuris vartotojas. Ši reikšmė negali būti saugoma tiesiogiai sutartyje, o gali būti pavaizduota tik duomenimis, iš kurių deterministiškai galima gauti vieną ir tik vieną gautos atsitiktinumo reikšmę. Šioje schemoje RP yra blokų grandinės vartotojai, todėl generavimo procese gali būti leista dalyvauti bet kam.

Pasirinkimas su atskira sutartimi yra geras:

• perkeliamumas (sutartis galima vilkti iš „blockchain“ į „blockchain“)
• diegimo ir testavimo paprastumas (sutartis lengva parašyti ir išbandyti)
• patogumas įgyvendinant ekonomines schemas (nesunku pasidaryti savo žetoną, kurio logika tarnauja PVRB tikslams)
• galimybė paleisti jau veikiančiose blokų grandinėse

Jis taip pat turi trūkumų:

• griežti skaičiavimo išteklių, operacijų apimties ir saugyklos apribojimai (kitaip tariant, cpu/mem/io)
• operacijų apribojimai pagal sutartį (ne visos instrukcijos yra, sunku prijungti išorines bibliotekas)
• nesugebėjimas organizuoti pranešimų greičiau nei operacijos įtraukiamos į blokų grandinę

Ši parinktis tinka diegti PVRB, kuris turi būti paleistas esamame tinkle, neturi sudėtingos kriptografijos ir nereikalauja daug sąveikų.

Integruotas sutarimu

Šioje versijoje PVRB yra įdiegtas blokų grandinės mazgo kode, įmontuotas arba veikiantis lygiagrečiai keičiantis pranešimais tarp blokų grandinės mazgų. Protokolo rezultatai įrašomi tiesiai į pagamintus blokus, o protokolo pranešimai siunčiami per p2p tinklą tarp mazgų. Kadangi protokolas lemia skaičius, kurie turi būti rašomi blokais, tinklas turi pasiekti sutarimą dėl jų. Tai reiškia, kad PVRB pranešimus, kaip ir operacijas, turi patvirtinti mazgai ir įtraukti į blokus, kad bet kuris tinklo dalyvis galėtų patvirtinti atitiktį PVRB protokolui. Tai automatiškai veda prie akivaizdaus sprendimo – jei tinklas susitaria dėl konsensuso dėl bloko ir jame atliekamų operacijų, tai PVRB turėtų būti konsensuso dalis, o ne atskiras protokolas. Priešingu atveju gali būti, kad blokas galioja konsensuso požiūriu, tačiau nesilaikoma PVRB protokolo ir PVRB požiūriu blokas negali būti priimtas. Taigi, jei pasirenkamas „konsensuso integruotas“ variantas, PVRB tampa svarbia sutarimo dalimi.

Apibūdinant PVRB diegimus tinklo konsensuso lygiu, jokiu būdu negalima išvengti baigtinumo klausimų. Galutinumas yra mechanizmas, naudojamas deterministiniuose susitarimuose, kuris užrakina bloką (ir į jį vedančią grandinę), kuris yra galutinis ir niekada nebus išmestas, net jei atsiras lygiagreti šakutė. Pavyzdžiui, „Bitcoin“ tokio mechanizmo nėra - jei paskelbsite sudėtingesnę grandinę, ji pakeis bet kokią mažiau sudėtingą, neatsižvelgiant į grandinių ilgį. O pavyzdžiui EOS galutiniai yra vadinamieji Last Irreversible Blocks, kurie atsiranda vidutiniškai kas 432 blokus (12*21 + 12*15, išankstinis balsavimas + išankstinis įsipareigojimas). Šis procesas iš esmės laukia 2/3 blokų gamintojų (toliau – BP) parašų. Kai atsiranda šakės, kurios yra senesnės nei paskutinė LIB, jos tiesiog išmetamos. Šis mechanizmas leidžia garantuoti, kad sandoris bus įtrauktas į blokų grandinę ir niekada nebus atšauktas, nesvarbu, kokius išteklius turi užpuolikas. Be to, galutiniai blokai yra blokai, pasirašyti 2/3 BP Hyperledger, Tendermint ir kituose konsensusuose, pagrįstuose pBFT. Be to, tikslinga protokolą, skirtą užbaigtumui užtikrinti, padaryti kaip priedą prie sutarimo, nes jis gali veikti asinchroniškai su blokų gamyba ir publikavimu. Štai geras straipsnis apie baigtumą Ethereum.

Galutiškumas yra nepaprastai svarbus vartotojams, kurie be jo gali tapti „dvigubų išlaidų“ atakos aukomis, kai BP „laiko“ blokus ir paskelbia juos, tinklui „pamačius“ gerą operaciją. Jei nėra baigtumo, paskelbta šakutė pakeičia bloką „gera“ operacija kitu, iš „blogos“ šakės, kurioje tos pačios lėšos pervedamos užpuoliko adresu. PVRB atveju baigtinumo reikalavimai yra dar griežtesni, nes PVRB kūrimo šakės reiškia galimybę užpuolikui paruošti keletą atsitiktinių variantų, kad paskelbtų pelningiausią, o apriboti galimos atakos laiką yra geras sprendimas.

Todėl geriausias variantas yra sujungti PVRB ir baigtumą į vieną protokolą – tada baigtas blokas = baigtas atsitiktinis, ir būtent tai mums reikėjo gauti. Dabar žaidėjai gaus garantuotą atsitiktinį skaičių per N sekundžių ir gali būti tikri, kad jo neįmanoma atsukti ar pakartoti.

Sutarimu integruota parinktis yra gera:

• asinchroninio diegimo galimybė blokų gamybai - blokai gaminami kaip įprasta, tačiau lygiagrečiai su tuo gali veikti PVRB protokolas, kuris nesukuria atsitiktinumo kiekvienam blokui
• galimybė įdiegti net sunkią kriptografiją be apribojimų, taikomų išmaniosioms sutartims
• galimybė organizuoti apsikeitimą žinutėmis greičiau nei operacijos įtrauktos į blokų grandinę, pavyzdžiui, dalis protokolo gali veikti tarp mazgų, neplatinant pranešimų tinkle

Jis taip pat turi trūkumų:

• Bandymo ir kūrimo sunkumai - turėsite emuliuoti tinklo klaidas, trūkstamus mazgus, tinklo kietąsias šakes
• Diegimo klaidoms reikia tinklo hardfork

Abu PVRB diegimo būdai turi teisę į gyvybę, tačiau išmaniųjų sutarčių diegimas šiuolaikinėse blokų grandinėse vis dar yra gana ribotas skaičiavimo ištekliais, o bet koks perėjimas prie rimtos kriptografijos dažnai yra tiesiog neįmanomas. Ir mums reikės rimtos kriptografijos, kaip bus parodyta toliau. Nors ši problema yra akivaizdžiai laikina, norint išspręsti daugelį problemų reikia rimtos kriptografijos sutartyse, kuri palaipsniui atsiranda (pavyzdžiui, zkSNARK sistemos sutartys Ethereum).

„Blockchain“, teikiantis skaidrų ir patikimą protokolo pranešimų kanalą, to nedaro nemokamai. Bet kuriame decentralizuotame protokole turi būti atsižvelgiama į Sybil atakos galimybę; bet kokį veiksmą gali atlikti suderintos kelių paskyrų jėgos, todėl kuriant reikia atsižvelgti į užpuolikų galimybę sukurti savavališką protokolų skaičių. susitarimo dalyviai.

PVRB ir bloko kintamieji.

Nemelavau sakydamas, kad gero PVRB, išbandyto daugelio lošimų programų, blokų grandinėse dar niekas neįdiegė. Kodėl Ethereum ir EOS yra tiek daug lošimo programų? Mane tai stebina taip pat, kaip ir jus, iš kur jie gavo tiek daug „nuolatinių“ atsitiktinumų visiškai deterministinėje aplinkoje?

Mėgstamiausias būdas gauti atsitiktinumą blokų grandinėje yra paimti iš bloko kažkokią „neprognozuojamą“ informaciją ir pagal ją sudaryti atsitiktinę informaciją – tiesiog maišant vieną ar daugiau reikšmių. Geras straipsnis apie tokių schemų problemas čia. Galite paimti bet kurią iš „nenuspėjamų“ reikšmių bloke, pavyzdžiui, bloko maišą, operacijų skaičių, tinklo sudėtingumą ir kitas iš anksto nežinomas reikšmes. Tada sumaišykite juos, vieną ar daugiau, ir teoriškai turėtumėte gauti tikrą atsitiktinį skaičių. Jūs netgi galite pridėti prie dokumento, kad jūsų schema yra "post-quantum safe" (nes yra kvantiškai atsparių maišos funkcijų :)).

Tačiau net ir po kvantinės saugios maišos, deja, nepakanka. Paslaptis slypi PVRB reikalavimuose, priminsiu juos iš ankstesnio straipsnio:

1. Rezultatas turi turėti įrodytai vienodą pasiskirstymą, t. y. turi būti pagrįstas įrodomai stipria kriptografija.
2. Neįmanoma valdyti nė vieno rezultato bito. Dėl to rezultato iš anksto numatyti negalima.
3. Negalite sabotuoti generavimo protokolo nedalyvaudami protokole arba perkraudami tinklą atakos pranešimais
4. Visa tai turi būti atspari leistino skaičiaus nesąžiningų protokolo dalyvių (pvz., 1/3 dalyvių) susitarimui.

Šiuo atveju tenkinamas tik reikalavimas 1, o neįvykdytas reikalavimas 2. Sumaišę iš bloko nenuspėjamas reikšmes, gausime vienodą pasiskirstymą ir gerus atsitiktinumus. Tačiau BP bent jau turi galimybę „paskelbti bloką ar ne“. Taigi BP gali pasirinkti bent iš DVIEJŲ atsitiktinių variantų: „savo“ ir to, kuris pasirodys, jei bloką padarys kas nors kitas. BP gali iš anksto „šnipinėti“, kas atsitiks, jei jis paskelbs bloką, ir tiesiog nuspręs tai padaryti ar ne. Taigi, žaisdamas, pavyzdžiui, „lyginis-nelyginis“ arba „raudonas/juodas“ ruletėje, jis gali paskelbti bloką tik tada, kai mato laimėjimą. Dėl to taip pat neįmanoma naudoti, pavyzdžiui, bloko maišos „iš ateities“ strategijos. Šiuo atveju jie sako, kad „bus naudojamas atsitiktinis, kuris gaunamas maišant esamus duomenis ir būsimo bloko maišą, kurio aukštis, pavyzdžiui, N + 42, kur N yra dabartinis bloko aukštis. Tai šiek tiek sustiprina schemą, bet vis tiek leidžia BP, nors ir ateityje, pasirinkti, ar sustabdyti bloką, ar paskelbti.

BP programinė įranga šiuo atveju tampa sudėtingesnė, bet ne daug. Paprasčiausiai, patvirtinant ir įtraukiant operaciją į bloką, greitai patikrinama, ar bus laimėjimas, ir, galbūt, pasirenkamas vienas operacijos parametras, siekiant gauti didelę laimėjimo tikimybę. Tuo pačiu metu už tokias manipuliacijas pagauti protingo BP beveik neįmanoma, kiekvieną kartą galite naudoti naujus adresus ir po truputį laimėti nesukeldami įtarimo.

Taigi metodai, naudojantys informaciją iš bloko, nėra tinkami kaip universalus PVRB įgyvendinimas. Ribotoje versijoje, su apribojimais dėl statymo dydžių, apribojimų žaidėjų skaičiui ir (arba) KYC registracijai (kad vienas žaidėjas negalėtų naudoti kelių adresų), šios schemos gali veikti mažiems žaidimams, bet nieko daugiau.

PVRB ir įsipareigoti-atskleisti.

Gerai, dėl maišos ir bent jau santykinio bloko maišos ir kitų kintamųjų nenuspėjamumo. Jei išspręsite pirmaujančių kalnakasių problemą, turėtumėte gauti ką nors tinkamesnio. Įtraukime į šią schemą vartotojus – tegul ir jie daro įtaką atsitiktinumui: bet kuris techninės pagalbos darbuotojas pasakys, kad IT sistemose atsitiktiniausias dalykas yra vartotojų veiksmai :)

Naivi schema, kai vartotojai tiesiog siunčia atsitiktinius skaičius, o rezultatas skaičiuojamas kaip, pavyzdžiui, jų sumos maiša, netinka. Tokiu atveju paskutinis žaidėjas gali, pasirinkdamas savo atsitiktinumą, kontroliuoti, koks bus rezultatas. Štai kodėl naudojamas labai plačiai naudojamas commit-reveal modelis. Dalyviai pirmiausia siunčia maišą iš savo atsitiktinių dalykų (įsipareigojimų), o tada patys atidaro atsitiktinius (atskleidžia). „Atskleidimo“ fazė prasideda tik surinkus reikiamus įsipareigojimus, todėl dalyviai gali siųsti būtent tą atsitiktinę maišą, iš kurios siuntė anksčiau. Dabar sudėkime visa tai su bloko parametrais ir geriau nei paimtu iš ateities (atsitiktinumą galima rasti tik viename iš būsimų blokų), ir voila - atsitiktinumas paruoštas! Dabar bet kuris žaidėjas daro įtaką atsiradusiam atsitiktinumui ir gali „nugalėti“ piktybinį BP, pakeisdamas jį savo, iš anksto nežinomu atsitiktinumu... Taip pat galite pridėti apsaugą nuo protokolo sabotavimo neatidarydami jo atskleidimo etape – tiesiog sudarant reikalavimą prie sandorio pridėti tam tikrą sumą – užstatą, kuris grąžinamas tik atskleidimo procedūros metu. Tokiu atveju įsipareigoti ir neatskleisti bus nenaudinga.

Tai buvo geras bandymas, tokių schemų yra ir žaidimų DApps, bet, deja, to vėl nepakanka. Dabar ne tik šachtininkas, bet ir bet kuris protokolo dalyvis gali turėti įtakos rezultatui. Vis dar galima kontroliuoti pačią vertę su mažesniu kintamumu ir brangiai, tačiau, kaip ir kalnakasio atveju, jei piešimo rezultatai yra vertingesni nei mokestis už dalyvavimą PVRB protokole, tada atsitiktinis -producer (RP) gali nuspręsti, ar atskleisti, ir vis tiek gali pasirinkti iš mažiausiai dviejų atsitiktinių parinkčių.
Bet tapo įmanoma bausti tuos, kurie įsipareigoja ir neatskleidžia, ir ši schema pravers. Jo paprastumas yra rimtas privalumas – rimtesni protokolai reikalauja daug galingesnių skaičiavimų.

PVRB ir deterministiniai parašai.

Yra dar vienas būdas priversti RP pateikti pseudoatsitiktinį skaičių, kuriam jis negali turėti įtakos, jei jam pateikiamas „preimage“ - tai deterministinis parašas. Toks parašas yra, pavyzdžiui, RSA, o ne ECS. Jei RP turi raktų porą: RSA ir ECC, ir jis pasirašo tam tikrą reikšmę savo privačiu raktu, tai RSA atveju jis gaus VIENĄ IR VIENĄ parašą, o ECS atveju gali sugeneruoti bet kokį skaičių. skirtingi galiojantys parašai. Taip yra todėl, kad kuriant ECS parašą yra naudojamas atsitiktinis skaičius, kurį pasirenka pasirašantis asmuo, ir jį galima pasirinkti bet kokiu būdu, suteikiant pasirašančiajam galimybę pasirinkti vieną iš kelių parašų. RSA atveju: „viena įvesties reikšmė“ + „viena raktų pora“ = „vienas parašas“. Neįmanoma nuspėti, kokį parašą gaus kitas RP, todėl PVRB su deterministiniais parašais galima organizuoti sujungus kelių tą pačią vertę pasirašiusių dalyvių RSA parašus. Pavyzdžiui, ankstesnė atsitiktinė. Ši schema sutaupo daug išteklių, nes parašai yra ir teisingo elgesio pagal protokolą patvirtinimas, ir atsitiktinumo šaltinis.

Tačiau net ir turint deterministinius parašus, schema vis dar yra pažeidžiama „paskutinio veikėjo“ problemai. Paskutinis dalyvis vis tiek gali nuspręsti, ar paskelbti parašą, ar ne, taip kontroliuodamas rezultatą. Galite modifikuoti schemą, pridėti prie jos blokų maišos, atlikti ratus, kad rezultato nebūtų galima numatyti iš anksto, tačiau visi šie metodai, net ir atsižvelgiant į daugybę modifikacijų, vis tiek palieka neišspręstą vieno dalyvio įtakos kolektyvui problemą. dėl to susidaro nepatikima aplinka ir gali veikti tik esant ekonominiams ir laiko apribojimams. Be to, RSA raktų dydis (1024 ir 2048 bitai) yra gana didelis, o blokų grandinės operacijų dydis yra nepaprastai svarbus parametras. Matyt, nėra paprasto būdo išspręsti problemą, eikime toliau.

PVRB ir slapto dalijimosi schemos

Kriptografijoje yra schemų, kurios gali leisti tinklui susitarti dėl vienos ir tik vienos PVRB reikšmės, tuo tarpu tokios schemos yra atsparios bet kokiems kai kurių dalyvių piktybiniams veiksmams. Vienas naudingas protokolas, su kuriuo verta susipažinti, yra Shamir slapto dalijimosi schema. Jis skirtas paslapčiai (pavyzdžiui, slaptajam raktui) padalinti į kelias dalis ir paskirstyti šias dalis N dalyviams. Paslaptis paskirstoma taip, kad jai atkurti pakaktų M dalių iš N, ir tai gali būti bet kuri M dalis. Jei ant pirštų, tai turėdami nežinomos funkcijos grafiką dalyviai keičiasi taškais grafike, o gavę M taškų, galima atkurti visą funkciją.
Pateikiamas geras paaiškinimas wiki bet žaisti su juo praktiškai tam, kad paleistumėte protokolą galvoje, naudinga Demo puslapį.

Jei FSSS (Fiat-Shamir Secret Sharing) schema būtų taikoma gryna forma, tai būtų nesunaikinamas PVRB. Paprasčiausia forma protokolas gali atrodyti taip:

• Kiekvienas dalyvis sugeneruoja savo atsitiktinį atvejį ir iš jo išdalina akcijas kitiems dalyviams
• Kiekvienas dalyvis atskleidžia savo dalį kitų dalyvių paslapčių
• Jei dalyvis turi daugiau nei M akcijų, tada galima apskaičiuoti šio dalyvio skaičių ir jis bus unikalus, neatsižvelgiant į atskleistų dalyvių skaičių
• Atskleistų atsitiktinumų derinys yra norimas PVRB

Čia atskiras dalyvis nebedaro įtakos protokolo rezultatams, išskyrus atvejus, kai atsitiktinumo atskleidimo ribos pasiekimas priklauso tik nuo jo. Todėl šis protokolas, jei yra reikiama dalis pagal protokolą dirbančių ir prieinamų RP, veikia, įgyvendina kriptografinio stiprumo reikalavimus ir yra atsparus „paskutinio veikėjo“ problemai.

Tai galėtų būti idealus pasirinkimas, pavyzdžiui, ši PVRB schema, pagrįsta „Fiat-Shamir“ slaptu pasidalijimu, aprašyta tai straipsnis. Tačiau, kaip minėta aukščiau, jei bandysite tai tiesiogiai pritaikyti blokų grandinėje, atsiranda techninių apribojimų. Pateikiame EOS išmaniojoje sutartyje protokolo testavimo pavyzdį ir svarbiausią jo dalį – paskelbto dalinimosi dalyvio patikrinimą: kodas. Iš kodo matote, kad įrodymo patvirtinimui reikia kelių skaliarinių dauginių, o naudojami skaičiai yra labai dideli. Reikėtų suprasti, kad blokų grandinėse patikrinimas įvyksta tuo metu, kai blokų gamintojas apdoroja operaciją, ir apskritai kiekvienas dalyvis turi lengvai patikrinti protokolo teisingumą, todėl tikrinimo funkcijos greičio reikalavimai yra labai rimti. . Pasirinkus šią parinktį, parinktis pasirodė neveiksminga, nes patikrinimas netilpo į operacijos limitą (0.5 sekundės).

Patvirtinimo efektyvumas yra vienas iš svarbiausių reikalavimų apskritai naudojant visas pažangias kriptografines schemas blokų grandinėje. Įrodymų kūrimas, pranešimų ruošimas – šios procedūros gali būti išjungtos iš grandinės ir atliekamos didelio našumo kompiuteriuose, tačiau patikrinimo negalima apeiti – tai dar vienas svarbus PVRB reikalavimas.

PVRB ir slenksčio parašai

Susipažinę su slapto dalinimosi schema, atradome visą klasę protokolų, kuriuos vienija raktinis žodis „slenkstis“. Kai tam tikros informacijos atskleidimas reikalauja M sąžiningų dalyvių iš N, o sąžiningų dalyvių rinkinys gali būti savavališkas N poaibis, kalbame apie „slenksčio“ schemas. Būtent jie leidžia mums spręsti „paskutinio veikėjo“ problemą, dabar, jei užpuolikas neatskleis savo paslapties dalies, už jį tai padarys kitas, sąžiningas dalyvis. Šios schemos leidžia susitarti dėl vienos ir tik vienos reikšmės, net jei kai kurie dalyviai sabotuoja protokolą.

Deterministinių parašų ir slenkstinių schemų derinys leido sukurti labai patogią ir perspektyvią PVRB diegimo schemą – tai deterministiniai slenksčio parašai. Čia straipsnis apie įvairius slenkstinių parašų panaudojimo būdus, o štai dar vienas geras seniai skaitytas iš Dash.

Paskutiniame straipsnyje aprašomi BLS parašai (BLS reiškia Boneh-Lynn-Shacham, čia straipsnis), kurie pasižymi itin svarbia ir programišiams itin patogia kokybe – viešieji, slaptieji, viešieji raktai ir BLS parašai gali būti derinami tarpusavyje, atliekant paprastas matematines operacijas, o jų deriniai išlieka galiojantys raktai ir parašai, leidžiantys lengvai sujungti daugybę parašus į vieną ir daug viešųjų raktų į vieną. Jie taip pat yra deterministiniai ir duoda tą patį rezultatą tiems patiems įvesties duomenims. Dėl šios kokybės BLS parašų deriniai patys yra galiojantys raktai, leidžiantys įgyvendinti parinktį, kai M iš N dalyvių sukuria vieną ir tik vieną parašą, kuris yra deterministinis, viešai patikrinamas ir nenuspėjamas, kol jį atidarys Mth. dalyvis.

Schemoje su slenksčio BLS parašais kiekvienas dalyvis ką nors pasirašo naudodamas BLS (pavyzdžiui, ankstesnį atsitiktinį), o bendras slenksčio parašas yra norimas atsitiktinis. BLS parašų kriptografinės savybės atitinka atsitiktinės kokybės reikalavimus, slenkstinė dalis apsaugo nuo „paskutinio veikėjo“, o unikalus raktų derinimas leidžia įgyvendinti daug įdomesnių algoritmų, leidžiančių, pavyzdžiui, efektyviai agreguoti protokolo pranešimus. .

Taigi, jei kuriate PVRB savo blokų grandinėje, greičiausiai turėsite BLS slenksčio parašų schemą, keli projektai jau ją naudoja. Pavyzdžiui, DFinity (čia etalonas, įgyvendinantis grandinę, ir čia patikrinamo slapto bendrinimo įgyvendinimo pavyzdys) arba Keep.network (čia yra jų atsitiktinis švyturys). geltonas popierius, Bet pavyzdys išmanioji sutartis, aptarnaujanti protokolą).

PVRB įgyvendinimas

Deja, PVRB blokų grandinėse vis dar nematome paruošto protokolo, kuris būtų įrodęs savo saugumą ir stabilumą. Nors patys protokolai yra paruošti, techniškai juos pritaikyti esamiems sprendimams nėra lengva. Centralizuotoms sistemoms PVRB nėra prasmės, o decentralizuotose yra griežtai ribojami visi skaičiavimo ištekliai: CPU, atmintis, saugykla, I/O. PVRB kūrimas yra skirtingų protokolų derinys, siekiant sukurti kažką, kas atitiktų visus reikalavimus, keliamus bent kai kuriai gyvybingai blokų grandinei. Vienas protokolas skaičiuoja efektyviau, bet reikalauja daugiau pranešimų tarp RP, o kitas – labai nedaug pranešimų, tačiau įrodymo sukūrimas gali užtrukti keliasdešimt minučių ar net valandų.

Išvardinsiu veiksnius, į kuriuos turėsite atsižvelgti renkantis kokybišką PVRB:

• Kriptografinis stiprumas. Jūsų PVRB turi būti griežtai nešališkas, be galimybės valdyti nė vieno bito. Kai kuriose schemose taip nėra, todėl kvieskite kriptografą
• „Paskutinio veikėjo“ problema. Jūsų PVRB turi būti atsparus atakoms, kai užpuolikas, valdantis vieną ar daugiau RP, gali pasirinkti vieną iš dviejų rezultatų.
• Protokolo sabotažo problema. Jūsų PVRB turi būti atsparus atakoms, kai užpuolikas, valdantis vieną ar daugiau RP, nusprendžia, ar jis yra atsitiktinis, ar ne, ir gali būti garantuotas arba su tam tikra tikimybe tai paveikti.
• Pranešimų skaičiaus problema. Jūsų RP turėtų siųsti mažiausiai pranešimų į blokų grandinę ir kiek įmanoma vengti sinchroninių veiksmų, tokių kaip „išsiunčiau šiek tiek informacijos, laukiu atsakymo iš konkretaus dalyvio“. P2p tinkluose, ypač geografiškai išsklaidytuose, neturėtumėte tikėtis greito atsakymo
• Skaičiavimo sudėtingumo problema. Bet kurio PVRB grandinės etapo patikrinimas turėtų būti labai paprastas, nes jį atlieka visi pilni tinklo klientai. Jei diegimas atliekamas naudojant išmaniąją sutartį, greičio reikalavimai yra labai griežti
• Prieinamumo ir gyvumo problema. Jūsų PVRB turėtų stengtis būti atsparus situacijoms, kai dalis tinklo tam tikrą laiką tampa nepasiekiama, o dalis RP tiesiog nustoja veikti.
• Patikimos sąrankos ir pradinio rakto paskirstymo problema. Jei jūsų PVRB naudoja pirminę protokolo sąranką, tai yra atskira didelė ir rimta istorija. Čia pavyzdys. Jei prieš pradėdami protokolą dalyviai turi pasakyti vienas kitam savo raktus, tai taip pat yra problema, jei pasikeičia dalyvių sudėtis
• Vystymosi problemos. Bibliotekų prieinamumas reikalingomis kalbomis, jų saugumas ir veikimas, viešinimas, kompleksiniai testai ir kt.

Pavyzdžiui, slenksčio BLS parašai turi didelę problemą – prieš pradėdami dirbti dalyviai turi išdalinti vienas kitam raktus, suorganizuodami grupę, kurioje veiks slenkstis. Tai reiškia, kad decentralizuotame tinkle teks palaukti bent vieno keitimo raundo, o atsižvelgiant į tai, kad, pavyzdžiui, sugeneruotas randas yra būtinas žaidimuose, beveik realiu laiku, tai reiškia, kad šiame etape galimas protokolo sabotavimas. , ir prarandami slenkstinės schemos privalumai . Ši problema jau paprastesnė nei ankstesnės, tačiau vis dar reikalauja sukurti atskirą slenkstinių grupių formavimo tvarką, kurią teks apsaugoti ekonomiškai per indėlius ir lėšų išėmimą (slashing) iš dalyvių, kurie nesilaiko taisyklių. protokolas. Be to, BLS patvirtinimas su priimtinu saugumo lygiu tiesiog netelpa, pavyzdžiui, į standartinę EOS ar Ethereum operaciją – patikrinimui tiesiog neužtenka laiko. Sutarties kodas yra WebAssembly arba EVM, vykdomas virtualioje mašinoje. Kriptografinės funkcijos nėra įdiegtos natūraliai (dar) ir veikia dešimtis kartų lėčiau nei įprastos kriptografinės bibliotekos. Daugelis protokolų neatitinka reikalavimų vien tik pagal rakto tūrį, pavyzdžiui, 1024 ir 2048 bitai RSA, 4–8 kartus didesnis nei standartinis operacijos parašas Bitcoin ir Ethereum.

Diegimų buvimas skirtingomis programavimo kalbomis taip pat vaidina svarbų vaidmenį - jų yra nedaug, ypač naujiems protokolams. Galimybė su integravimu į konsensusą reikalauja rašyti protokolą platformos kalba, todėl kodo turėsite ieškoti Go for geth, Rust for Parity, C++, EOS. Kiekvienas turės ieškoti JavaScript kodo, o kadangi JavaScript ir kriptografija nėra itin artimi draugai, tai padės WebAssembly, kuri dabar neabejotinai pretenduoja į kitą svarbų interneto standartą.

išvada

Tikiuosi, kad ankstesniame straipsnis Man pavyko jus įtikinti, kad atsitiktinių skaičių generavimas blokų grandinėje yra labai svarbus daugeliui decentralizuotų tinklų gyvenimo aspektų, ir šiuo straipsniu parodžiau, kad ši užduotis yra labai ambicinga ir sudėtinga, tačiau gerų sprendimų jau yra. Apskritai, galutinis protokolo dizainas yra įmanomas tik atlikus didžiulius testus, kuriuose atsižvelgiama į visus aspektus nuo sąrankos iki gedimų emuliacijos, todėl vargu ar rasite paruoštų receptų komandos informaciniuose dokumentuose ir straipsniuose, o mes tikrai to nerasime. nuspręskite per ateinančius metus ar dvejus parašykite „daryk taip, tiksliai teisingai“.

Sveiki, mūsų PVRB kuriamoje blokų grandinėje Haya, apsisprendėme naudoti slenksčius BLS parašus, planuojame PVRB diegti konsensuso lygmeniu, nes išmaniosiose sutartyse su priimtinu saugumo lygiu patvirtinimas dar neįmanomas. Gali būti, kad vienu metu naudojame dvi schemas: pirma, brangų paslapčių pasidalijimą, kad sukurtume ilgalaikį random_seed, o tada naudosime jį kaip pagrindą aukšto dažnio atsitiktiniam generavimui naudojant deterministinius slenksčio BLS parašus, galbūt apsiribosime tik viena iš schemų. Deja, iš anksto pasakyti, koks bus protokolas, neįmanoma, geras dalykas yra tai, kad, kaip ir moksle, taip ir inžinerinėse problemose, rezultatas yra ir neigiamas rezultatas, o kiekvienas naujas bandymas išspręsti problemą yra dar vienas žingsnis visų, susijusių su problema, tyrimai. Siekdami patenkinti verslo reikalavimus, sprendžiame konkrečią praktinę problemą – žaidimų programoms suteikti patikimą entropijos šaltinį, todėl turime atkreipti dėmesį ir į pačią blokų grandinę, ypač grandinės užbaigtumo ir tinklo valdymo klausimus.

Ir nors blokų grandinėse kol kas nematome įrodyto atsparaus PVRB, kuris būtų buvęs naudojamas pakankamai ilgai, kad būtų išbandytas realiomis programomis, daugkartiniais auditais, apkrovomis ir, žinoma, realiomis atakomis, tačiau galimų kelių skaičius patvirtina, kad sprendimas egzistuoja, ir kuris iš šių algoritmų galiausiai išspręs problemą. Džiaugiamės galėdami pasidalinti rezultatais ir padėkoti kitoms komandoms, kurios taip pat dirba su šiuo klausimu, už straipsnius ir kodą, leidžiantį inžinieriams du kartus neužlipti ant to paties grėblio.

Taigi, susitikę su programuotoju, projektuojančiu decentralizuotą atsitiktinumą, būkite dėmesingi ir rūpestingi, o prireikus suteikite psichologinę pagalbą :)

Šaltinis: www.habr.com