Hyrje

function getAbsolutishtRastRandomNumer() {
        return 4; // kthen numrin absolutisht të rastësishëm!
}

Siç është rasti me konceptin e enkriptimit të rëndësishëm absolut, protokollet reale "Publicly Verifiable Random Beacon" (PVRB) përpiqen të afrohen sa më shumë me skemën ideale, pasi në rrjetet reale ajo nuk është e aplikueshme në formën e saj të pastër: duhet të dakordohet rreptësisht për një bit, duhen shumë raunde, dhe të gjitha mesazhet duhet të jenë të shpejta dhe gjithmonë të dorëzohen. Sigurisht, në rrjetet reale nuk është kështu. Prandaj, kur projektohet PVRB për detyrat specifike në blockchain-at modernë, përveç pamundësisë së kontrollit të rastësisë së marra dhe qëndrueshmërisë kriptografike, shfaqen edhe shumë probleme të tjera të ndërtimit dhe teknologjisë.

Blockchain-i në vetvete është për PVRB praktikisht një mjedis komunikimi, në të cilin mesazhet janë transaksione. Kjo lejon të përjashtohet pjesërisht problematika e rrjeteve, dërgimëve të mesazheve dhe problemeve të softuerëve ndërmjetës — të gjitha këto rreziqe pranohen nga rrjeti decentralizuar, dhe vlera kryesore e tij për PVRB është pamundësia për të tërhequr ose prishur një transaksion të dërguar tashmë — kjo nuk i lejon pjesëmarrësit të heqin dorë nga pjesëmarrja në protokoll, përveç nëse ata kryejnë një sulm të suksesshëm në konsensus. Ky nivel sigurie është i pranueshëm, ndaj PVRB duhet të jetë i qëndrueshëm ndaj komplotit të pjesëmarrësve të njëjtë me atë të zinxhirit kryesor të blockchain-it. Gjithashtu, kjo sugjeron që PVRB duhet të jetë pjesë e konsensusit, nëse rrjeti është dakorduar për zinxhirin kryesor të bllokut, le të dakordohet gjithashtu për rastësinë e vetme të ndershme. Ose, PVRB është thjesht një protokoll standalone, i implementuar nga një smart contract, që operon asinkronisht në lidhje me blockchain-in dhe blloqet. Të dyja metodat kanë përfitimet dhe disavantazhet e tyre, dhe zgjedhja mes tyre është tepër e ndërlikuar.

Dy mënyra për implementimin e PVRB

Do të përshkruaj më në detaje dy variantet e implementimit të PVRB — versionin standalone, që punon me përdorimin e një smart contract-i të pavarur nga blockchain-i, dhe mënyrën e integruar në konsensus — të integruar në protokoll, sipas të cilit rrjeti është dakorduar për zinxhirin e bllokut dhe transaksionet përfshirëse. Në të gjitha rastet, unë do të kem parasysh motorët e njohur të blockchain-it: Ethereum, EOS, dhe të gjitha ato që i ngjajnë atyre në mënyrën e vendosjes dhe procesimit të smart contract-eve.

Kontrakt i pavarur

Në këtë variant, PVRB përfaqëson një smart kontratë që pranon transaksione nga prodhuesit-rast (më pas RP), i përpunon ato, kombinon rezultatet dhe, si pasojë, arrin në një vlerë, e cila mund të merret nga çdo përdorues nga kjo kontratë. Kjo vlerë mund të mos ruhet direkt në kontratë, por të përfaqësohet vetëm me të dhëna nga të cilat mund të nxirret në mënyrë deterministe një dhe vetëm një vlerë e rastësishme rezultuese. Në këtë skemë, RP janë përdoruesit e blockchain-it dhe mund t'u lejohet të gjithë të marrin pjesë në procesin e gjenerimit.

Varianti me kontraktë të pavarur është i mirë:

për portabilitetin (kontratë të cilat mund të transferohen nga një blockchain në një tjetër)
për thjeshtësinë në realizim dhe testim (kontratë të cilat janë të lehta për t'u shkruar dhe testuar)
për lehtësinë në realizimin e skemave ekonomike (e lehtë për të krijuar token-in tuaj, logjika e të cilit shërben për qëllimet e PVRB)
për mundësinë e fillimit në blockchain-e që janë tashmë në funksion

Por ka dhe disavantazhe:

kufizime të forta mbi burimet gjatë llogaritjeve, vëllimi i transaksioneve dhe ruajtjes (thjesht, cpu/mem/io)
kufizime mbi operacionet brenda kontratës (jo të gjitha instruksionet janë të disponueshme, e vështirë për t'u lidhur me biblioteka të jashtme)
pamundësia për të organizuar shkëmbimin e mesazheve më shpejt se sa transaksionet përfshihen në blockchain

Ky variant është i përshtatshëm për realizimin e PVRB, i cili duhet të fillohet në një rrjet ekzistues, pa përfshirë kriptografi të komplikuar dhe që nuk kërkon shumë ndërveprime.

Konsensusi i integruar

Në këtë variant, PVRB është realizuar në kodin e nodit të blockchain-it, i integruar ose punon paralelisht me shkëmbimin e mesazheve ndërmjet nodave të blockchain-it. Rezultatet e protokollit regjistrohen direkt në blloqet që prodhohen, ndërsa mesazhet e protokollit dërgohen përmes rrjetit p2p midis nodave. Meqenëse protokolli përmban numra që duhet të regjistrohen në blloqe, rrjeti duhet të arrijë konsensus për ta. Kështu, mesazhet PVRB, ashtu si transaksionet, duhet të validohen nga nodet dhe të përfshihen në blloqe, që çdo pjesëmarrës i rrjetit të mund të validonte përmbushjen e protokollit PVRB. Kjo automatikisht na çon në një zgjidhje të qartë — nëse rrjeti arin një konsensus rreth bllokut dhe transaksioneve në të, atëherë PVRB duhet të jetë pjesë e konsensusit dhe jo një protokoll i shkëputur. Ndryshe mund të ndodhi që një bllok të jetë valid nga pikëpamja e konsensusit, por protokolli PVRB të mos jetë respektuar, dhe nga pikëpamja e PVRB, blloku nuk mund të pranohet. Pra, nëse zgjedhet varianti “integruar në konsensus”, PVRB bëhet një pjesë e rëndësishme e konsensusit.

Duke përshkruar implementimet e PVRB në nivelin e konsensusit në rrjet, asnjëherë nuk duhet të injorohen çështjet e finalitetit. Finaliteti është një mekanizëm që përdoret në consensus të determinuara, i cili evidenton një bllok (dhe zinxhirin që e çon atje) që është final, dhe kurrë nuk do të hidhet poshtë, madje edhe nëse ndodhet një fork paralel. Për shembull, në Bitcoin nuk ka një mekanizëm të tillë — nëse publikohet një zinxhir me komplekse më të madhe, ai do të zëvendësojë çfarëdo zinxhiri më pak kompleks, pavarësisht nga gjatësi e zinxhirëve. Ndërsa në EOS, blloqet përfundimtare janë të ashtuquajturat Last Irreversible Blocks, që shfaqen në mesatarisht çdo 432 blloqe (12*21 + 12*15, pre-vote + pre-commit). Ky proces është në thelb një pritje për 2/3 të nënshkrimeve nga prodhuesit e blloqeve (më pas BP). Kur ndodhin fork, që janë më të vjetër se LIB-i më i fundit, ato thjesht hidhen poshtë. Ky mekanizëm lejon që të konfirmohet se një transaksion është përfshirë në bllokçenin dhe kurrë nuk do të tërhiqet, pavarësisht nga burimet që ka sulmuesi. Po ashtu, blloqet përfundimtare janë blloqet e nënshkruara nga 2/3 BP në Hyperledger, Tendermint dhe konsensuse të tjera të bazuara në pBFT. Gjithashtu, protokolli për sigurimin e finalitetit ka kuptim të jetë një shtesë mbi konsensusin, pasi ai mund të funksionojë asinkronisht me prodhimin dhe publikimin e blloqeve. Këtu ka një të mirë artikulli për përfundimin në Ethereum.

Përfundimi është tejet i rëndësishëm për përdoruesit, të cilët pa të mund të bëhen viktima të sulmit 'double spend', kur BP 'mban' blloqet dhe i publikojnë pasi rrjeti 'ka parë' një transaksion të mirë. Nëse nuk ka përfundim, forka e publikuar zëvendëson bllokun me transaksionin 'e mirë' me një tjetër nga forka 'e keqe', në të cilën të njëjtat fonde kalojnë në adresën e sulmuesit. Në rastin e PVRB, kërkesat për përfundim bëhen edhe më të rrepta, pasi ndërtimi i forkeve për PVRB do të thotë mundësinë për sulmuesin të përgatisë disa variante të rastësisë me qëllim që të publikojë atë më të favorshme për të, dhe të kufizojë kohën e mundshme të sulmit — një zgjidhje e mirë.

Prandaj, opsioni më i mirë është të bashkohen PVRB dhe përfundimi në një protokoll — atëherë blloku i përfunduar = rastësia e përfunduar, dhe kjo është pikërisht ajo që duhej të merrej. Tani lojtarët do të marrin një rastësi të garantuar për N sekonda, dhe mund të jenë të sigurt se nuk është e mundur ta kthejnë pas atë ose ta rigrupojnë.

Opsioni me konsensus-të integruar është i mirë:

me mundësinë e realizimit asinkron në lidhje me prodhimin e blloqeve — blloqet prodhohen si zakonisht, por paralelisht me këtë protokolli PVRB mund të punojë, i cili prodhon rastësi jo çdo bllok
me mundësinë për të implementuar madje kriptografinë e rëndë, pa kufizime të vendosura nga kontratat inteligente
me mundësinë për të organizuar shkëmbime mesazhe më shpejt se sa transaksionet përfshihen në blockchain, për shembull një pjesë e protokollit mund të punojë mes nodave pa përhapjen e mesazheve në rrjet

Por ka dhe disavantazhe:

vështirësitë gjatë testimit dhe zhvillimit — do të duhet të imitojmë gabimet në rrjet, nodet që humbasin, hardforcat e rrjetit
gabimet në implementim kërkojnë hardfork të rrjetit

Të dy mënyrat e implementimit të PVRB kanë të drejtën e jetës, por implementimi në kontratat inteligente në blockchain-et moderne megjithatë ka kufizime të forta në resurset computacionale, dhe çdo kalim në kriptografinë serioze shpesh është thjesht i pamundur. Dhe kriptografia serioze na nevojitet, si do të demonstrohet më tej. Megjithatë, ky problem është padyshim temporal, kriptografia serioze në kontrata është e nevojshme për zgjidhjen e shumë problemeve, dhe gradualisht po shfaqet (për shembull, kontratat sistemore për zkSNARKs në Ethereum)

Blockchain, which provides a transparent and reliable messaging exchange channel for the protocol, does not do this for free. Any decentralized protocol must consider the possibility of a Sybil attack; any action can be made consistent by colluding forces from multiple accounts, so when designing, one must take into account the attackers' capabilities to create an arbitrary number of protocol participants acting in collusion.

PVRB and block variables.

I wasn't lying when I said that a good PVRB, tested by many gambling applications, has not yet been implemented in blockchains. So where does all this number of gambling applications in Ethereum and EOS come from? It surprises me just as much as it does you; how did they find so many ‘resilient’ randoms in a completely deterministic environment?

The preferred way to extract randomness in blockchain is to take some ‘unpredictable’ information from the block and use it to create randomness—simply by hashing one or more values. A good article on the issues of such schemes. këtuOne can take any of the ‘unpredictable’ values in the block, for example, the block hash, the number of transactions, the network difficulty, and other values that are not known in advance. Then hash them, one or several, and ideally, it should result in true randomness. One could even state in the whitepaper that your scheme is ‘post-quantum secure’ (as there are quantum-proof hash functions :)).

But even post-quantum secure hashes are not enough, unfortunately. The secret lies in the requirements for PVRB; let me remind you of them from the previous article:

Rezultati duhet të ketë një shpërndarje të vërtetë të barabartë, domethënë të bazohet në kriptografi të qëndrueshme dhe të provuar.
Nuk është e mundur të kontrolloni asnjë bit të rezultatit. Si pasojë, rezultati nuk mund të parashikohet paraprakisht.
Nuk është e mundur të sabotosh protokollin e gjenerimit përmes mosmarrjes pjesë në protokoll ose duke mbingarkuar rrjetin me mesazhe sulmuese.
Të gjitha të mësipërmet duhet të jenë të qëndrueshme ndaj komplotit të një numri të pranueshëm të pjesëmarrësve të pandershëm të protokollit (p.sh. 1/3 e pjesëmarrësve).

Në këtë rast zbatohet vetëm kërkesa 1, dhe nuk respektohet 2. Duke hash-uar vlera të papritura nga blloku, ne do të marrim një shpërndarje të barabartë dhe të mira rastësishmërie. Por BP ka të paktën mundësinë "të publikojë bllokun, ose jo". Kështu, BP mund të zgjedhë nga DY mundësi rastësishmërie: "të tijin" dhe atë që do të rezultonte, nëse bllokun e publikonte dikush tjetër. BP mund të "shikojë paraprakisht" se çfarë do të rezultonte, nëse do ta publikonte bllokun, dhe thjesht merr vendimin të bëjë ose jo këtë. Kështu, duke luajtur për shembull në "çift-tekë" ose "të kuqe/zeze" në ruletë, mund të publikojë bllokun vetëm nëse sheh fitimin. Kjo gjithashtu e bën strategjinë e përdorimit, për shembull, të hash-it të bllokut "nga e ardhmja" jo funksionale. Në këtë rast, thuhet se "do të përdoret rastësia që rezulton nga hash-imi i të dhënave aktuale dhe hash-i i bllokut të ardhshëm në lartësinë, për shembull, N + 42, ku N është lartësia aktuale e bllokut. Kjo e forcon pak skemën, por përsëri i lejon BP-së, ndonëse në të ardhmen, të zgjedhë, të mbajë bllokun ose ta publikojë.

Software-i i BP-së në këtë rast bëhet më i komplikuar, por jo shumë. Thjesht gjatë validimit dhe përfshirjes së transaksionit në bllok, bëhet një kontroll i shpejtë, nëse do të ketë fitim, dhe ndoshta rregullimi i një nga parametrave të transaksionit, për të marrë një mundësi të lartë për fitim. Në këtë mënyrë, kapja e BP-së së mençur, pas këtyre manovrimeve është pothuajse e pamundur, çdo herë mund të përdoren adresa të reja dhe të fitojnë pak nga pak, pa ngjallur dyshime.

Pra, mënyrat që përdorin informacionin nga blloku nuk janë të përshtatshme për të shërbyer si një implementim universale të PVRB. Në një variant të kufizuar, me kufizime mbi përmasat e basteve, kufizime në numrin e lojtarëve dhe/ose regjistrim KYC (për të mos e lejuar një lojtar të përdorë disa adresa), këto skema mund të funksionojnë për lojra të vogla, por jo më tepër.

PVRB dhe commit-reveal.

Mirë, falë hash-imit dhe së paku parashikueshmërisë relative të hash-it të bllokut dhe variablave të tjerë. Nëse zgjidhet problemi i front-running-ut të minatorëve, duhet të dalë diçka më e vlefshme. Le të shtojmë në këtë skemë përdoruesit — le të ndikojnë edhe ata në rastësinë: çdo punonjës i mbështetjes teknike do t'ju thotë se më e rastësishmja në sistemet IT është veprimi i përdoruesve 🙂

Skema naive, ku përdoruesit thjesht dërgojnë numra të rastësishëm dhe rezultati llogaritet, për shembull, si hash nga shuma e tyre, nuk është e pranueshme. Në këtë rast, lojtari i fundit mund të kontrollojë rezultatin duke zgjedhur rastësisht numrin e tij. Prandaj, përdoret një model shumë të njohur commit-reveal. Pjesëmarrësit në fillim dërgojnë hash-at e rastësive të tyre (commit-et), dhe më pas zbulojnë vetë rastësitë (reveal-et). Fazën 'reveal' e nis vetëm pasi të kenë grumbulluar commit-et e nevojshme, kështu që pjesëmarrësit mund të dërgojnë saktësisht rastësinë që hash-i i të cilës është dërguar më parë. Tani të gjitha këto i kombinojmë me parametrat e bllokut, duke i marrë më mirë nga e ardhmja (rastësia mund të mësohet vetëm në një nga blloqet e ardhshme), dhe voilà — rastësia është gati! Tani çdo lojtar ndikon në rastësinë rezultante dhe mund të 'fitonte' BP-in e keq, duke e mbuluar rastësinë e tij me rastësinë e pa njohur më parë... Gjithashtu mund të shtojmë mbrojtje nga sabotimi i protokollit në fazën e zbuluar, thjesht duke kërkuar që gjatë commit-it të bashkëngjitet me transaksionin një shifër — një depozitë sigurie, e cila do të kthehet vetëm gjatë procedurës së zbuluar. Në këtë rast, të bësh commit dhe të mos bësh reveal do të jetë e pa avantazh.

Ishte një përpjekje e mirë, dhe ka skema të tilla në DApp-t e lojërave, por fatkeqësisht, edhe kjo nuk është e mjaftueshme. Tani rezultati mund të ndikojë jo vetëm mineari, por edhe çdo pjesëmarrës tjetër të protokollit. Vlera e kontrolluar mund të vazhdojë të jetë e mundur, me një shkallë më të ulët variacioni dhe për para, por, siç ndodh me minearin, nëse rezultatet e hedhjes janë më të vlefshme se shuma për pjesëmarrjen në protokollin PVRB, atëherë prodhuesi i rastësive (RP) mund të vendosë nëse do të bëjë reveal dhe gjithashtu mund të zgjedhë nga të paktën dy opsione të rastësisë.
Megjithatë, tani ka mundësi për të ndëshkuar ata që bëjnë commit dhe nuk bëjnë reveal, dhe kjo skemë do të jetë e dobishme. Thjeshtësia e saj është një avantazh i rëndësishëm — protokollet më serioze kërkojnë llogaritje shumë më të fuqishme.

PVRB dhe nënshkrime të përcaktuara.

Ekziston edhe një mënyrë për ta bërë RP të ofrojë një numër pseudorasional mbi të cilin ai nuk mund të ndikojë, nëse i jepet "prototipi" — kjo është një nënshkrim deterministik. Një nënshkrim i tillë është, për shembull, RSA, dhe nuk është ECS. Nëse RP ka një çift çelësash: RSA dhe ECC, dhe ai nënshkruan një vlerë me çelësin e tij privat, atëherë në rastin e RSA ai do të marrë NJË DHE VETËM NJË nënshkrim, ndërsa në rastin e ECS — ai mund të gjenerojë një numër të madh nënshkrimesh të vlefshme të ndryshme. Kjo ndodh sepse, gjatë krijimit të nënshkrimit ECS, përdoret një numër i rastësishëm, i zgjedhur nga nënshkruesi, dhe ai mund të zgjidhet si të dojë, duke i dhënë mundësinë nënshkruesit të zgjedhë ndërmjet disa nënshkrimesh. Në rastin e RSA: "një vlerë hyrëse" + "një çift çelësash" = "një nënshkrim". Nuk është e mundur të parashikohet se cili do të jetë nënshkrimi i një RP tjetër, prandaj PVRB me nënshkrime deterministike mund të organizohet duke kombinuar nënshkrimet RSA të disa pjesëmarrësve që kanë nënshkruar të njëjtën vlerë. Për shembull — numri i rastësishëm i mëparshëm. Në një skemë të tillë kursehen shumë burime, sepse nënshkrimet janë njëkohësisht edhe konfirmim të sjelljes së saktë sipas protokollit, edhe burim rastësie.

Megjithatë, edhe me nënshkrime deterministike, skema mbetet e ndjeshme ndaj problemit "aktorit të fundit". Pjesëmarrësi i fundit ende mund të vendosë nëse ta publikojë nënshkrimin apo jo, duke kontrolluar kështu rezultatin. Mund të përmirësohet skema, duke shtuar hash-e të blloqeve, duke bërë runda, që rezultati të mos parashikohet paraprakisht, por të gjitha këto teknikë, edhe duke marrë parasysh shumë përmirësime, gjithsesi e lënë të pazgjidhur problemin e ndikimit të një pjesëmarrësi në rezultatin kolektiv në një ambient të paqartë dhe mund të funksionojnë vetëm në kushte të kufizimeve ekonomike dhe temporale. Përveç kësaj, madhësia e çelësave RSA (1024 dhe 2048 bit) është mjaft e madhe, dhe madhësia për transaksionet në blockchain është një parametër tepër i rëndësishëm. Duket se nuk do të jetë e mundur të zgjidhet problemi në një mënyrë të thjeshtë, prandaj po vazhdojmë përpara.

Në kriptografi, ekzistojnë skema që mundësojnë që rrjeti të arrijë një vlerë të vetme PVRB, ndërsa këto skema janë të qëndrueshme ndaj çdo veprimi të keq nga një pjesë e pjesëmarrësve. Një nga protokollet e dobishme që duhet njohur është skema e ndarjes së sekreteve të Shamir. Ajo është e destinuar për të ndarë një sekret (për shembull, një çelës sekret) në disa pjesë dhe për ta shpërndarë atë te N pjesëmarrës. Sekreti shpërndahet në mënyrë që për t'u rikuperuar, mjafton M pjesë nga N, dhe këto mund të jenë çfarëdo M pjesësh. Nëse e shpjegojmë thjesht, pasi të kemi grafikën e një funksioni të panjohur, pjesëmarrësit shkëmbejnë pika mbi grafikë, dhe pas marrjes së M pikave, e gjithë funksioni mund të rikuperohet.
Një shpjegim i mirë është dhënë në wiki dhe për ta provuar atë në praktikë, është e dobishme të luash protokollin në mendje në demo faqen.

Nëse skema FSSS (Fiat-Shamir Secret Sharing) do të mund të aplikohej në një formë të pastër — do të ishte një PVRB i pakapshëm. Në variantin më të thjeshtë, protokolli mund të duket kështu:

Çdo pjesëmarrës gjeneron random-in e vet dhe shpërndan shares nga ai te pjesëmarrësit e tjerë.
Çdo pjesëmarrës zbulohet pjesën e sekreteve të pjesëmarrësve të tjerë.
Nëse për një pjesëmarrës janë mbledhur më shumë M shares, atëherë numri i atij pjesëmarrësi mund të llogaritet dhe do të jetë unik, pa marrë parasysh grupin e pjesëmarrësve që janë zbuluar.
Kombinimi i random-ëve të zbuluar është PVRB i kërkuar.

Këtu, një pjesëmarrës i veçantë nuk ndikon në rezultatet e protokollit, përveç rasteve kur arritja e kufirit të zbërthimit të random-it varet vetëm nga ai. Prandaj, ky protokoll, nëse ka pjesëmarrësit e nevojshëm që punojnë sipas protokollit dhe RP të disponueshëm, funksionon për të përmbushur kërkesat e qëndrueshmërisë kriptografike dhe është i qëndrueshëm ndaj problemës "aktori i fundit".

Kjo mund të ishte opsioni ideal, kjo skemë PVRB mbi bazën e ndarjes së sekreteve të Fiat-Shamir është e përshkruar, për shembull, në këtë artikull. Por, siç u përmend më arriba, nëse përpiqesh ta aplikosh atë drejtpërdrejt në blockchain, shfaqen kufizime teknike. Ja një shembull i një realizimi testues të protokollit në smart contractin EOS dhe pjesa më e rëndësishme e tij — verifikimi i share të publikuar nga një pjesëmarrës: kodDuke për kodin, verifikimi i proof-it kërkon disa shumëzim të skalarëve, dhe numrat përdoren janë shumë të mëdhenj. Në këtë kontekst, duhet të kuptohet se në blockchain verifikimi ndodh kur block-producer përpunon transaksionin, dhe çdo pjesëmarrës duhet të jetë në gjendje ta verifikojë lehtësisht saktësinë e protokollit, prandaj kërkesat për shpejtësinë e funksionit të verifikimit janë shumë serioze. Në këtë variant, opsioni doli të ishte jo-funksional, pasi verifikimi nuk përputhej me kufizimin mbi transaksionin (0.5 sekondë).

Efektiviteti i verifikimit është një nga kërkesat më të rëndësishme për përdorimin e çdo skeme të avancuar kriptografike në blockchain. Krijimi i proof-ave, përgatitja e mesazheve - këto procedura mund të kryhen off-chain në kompjuterë me performancë të lartë, por verifikimi nuk mund të anashkalohet - kjo është një kërkesë tjetër e rëndësishme për PVRB.

PVRB dhe nënshkrimet threshold

Duke u njohur me skemën e ndarjes së sekretit, zbuluam një grup të tërë protokollesh të bashkuara me fjalën kyçe “threshold”. Kur për të zbuluar disa informacione kërkohet pjesëmarrja e M pjesëmarrësve të ndershëm nga N, dhe grupi i pjesëmarrësve të ndershëm mund të jetë një nënset të rastësishëm nga N, flitet për skemat “threshold”. Ato lejojnë të zgjidhet problemi “aktorit të fundit”, tani nëse sulmuesi nuk e zbulon pjesën e tij të sekretit, një pjesëmarrës tjetër i ndershëm do ta bëjë atë. Këto skema lejojnë r agreement për një vlerë të vetme, edhe në rast të sabotimit të protokollit nga disa pjesëmarrës.

Kombinimi i nënshkrimeve determinuese dhe skemave threshold ka mundësuar zhvillimin e një skeme shumë të përshtatshme dhe premtuese për implementimin e PVRB - këto janë nënshkrimet determinuese threshold. Ja artikulli për aplikime të ndryshme të nënshkrimeve threshold, dhe ja një tjetër i mirë longread nga Dash.

Në artikullin e fundit përshkruhen nënshkrimet BLS (BLS dekodohesh si Boneh-Lynn-Shacham, ja artikulli ), të cilat kanë një cilësi shumë të rëndësishme dhe jashtëzakonisht të dobishme për programuesit - çelësat publikë, çelësat sekretë dhe nënshkrimet BLS mund të kombinohen me njëri-tjetrin përmes operacioneve të thjeshta matematikore, duke mbajtur kështu kombinimet si çelësa dhe nënshkrime valide, duke lejuar agregimin e shumë nënshkrimeve në një dhe shumë çelësa publikë në një. Ato gjithashtu kanë një caktueshmëri dhe japin të njëjtin rezultat për të njëjtat të dhëna hyrëse. Falë kësaj cilësie, kombinimet e nënshkrimeve BLS janë vetë çelësa validë, që lejon realizimin e një versioni ku M nga N pjesëmarrës prodhojnë një dhe vetëm një nënshkrim, i cili është i caktuar, publikisht i verifikueshëm, dhe i paparashikueshëm deri sa të zbulohet nga pjesëmarrësi M.

Në skemën me nënshkrime BLS threshold, çdo pjesëmarrës nënshkruan me BLS diçka (për shembull, një random të mëparshëm), dhe nënshkrimi total threshold është random-i që ne kërkojmë. Vetitë kriptografike të nënshkrimeve BLS plotësojnë kërkesat për cilësi të random-it, pjesa threshold mbron nga “aktorin e fundit”, dhe kombinueshmëria unike e çelësave lejon realizimin e shumë algorive interesante, të cilat lehtësojnë agregimin efikas të mesazheve të protokollit.

Pra, nëse jeni duke ndërtuar PVRB në blockchain-in tuaj, ka shumë gjasa të kaloni në skemën e nënshkrimeve BLS threshold, e cila tashmë po përdoret nga disa projekte. Për shembull, DFinity (këtu benchmark, që implementon skemën, dhe këtu shembulli i implementimit të ndarjes sekrete verifikueshme), ose Keep.network (kjo është beacon-i i tyre random yellowpaper, dhe këtu është kontraktës inteligjente, që shërben protokollin).

Implementimi i PVRB

Fatkeq, ne ende nuk shohim një protokoll të gatshëm, i zbatuar në blockchainet PVRB, që ka provuar sigurinë dhe qëndrueshmërinë e tij. Megjithëse protokollet vetë janë të gatshme, aplikimi teknik i tyre në zgjidhjet ekzistuese është i vështirë. Për sistemet e centralizuara, PVRB nuk ka kuptim, ndërsa ato të decentralizuara janë të kufizuara ndjeshëm në të gjitha burimet kompjuterike: CPU, memorie, ruajtje, I/O. Projektimi i PVRB është një kombinim i protokolleve të ndryshme për të krijuar diçka që të përmbushë të gjitha kërkesat për një blockchain të jetueshëm. Një protokoll llogarit më efektivisht, por kërkon më shumë mesazhe midis RP, ndërsa tjetri kërkon shumë pak mesazhe, por krijimi i proof-it mund të jetë një detyrë që zgjat dhjetëra minuta, madje orë.

Do të përmend faktorët që duhet të keni parasysh kur zgjidhni një PVRB cilësor:

Qëndrueshmëria kriptografike. PVRB juaj duhet të jetë plotësisht unbiasable, pa mundësi për të kontrolluar asnjë bit. Në disa skema kjo nuk është kështu, prandaj thirrni një kriptograf.
Problemi "aktori i fundit". PVRB juaj duhet të jetë i qëndrueshëm ndaj sulmeve, kur sulmuesi, që kontrollon një ose disa RP mund të zgjedhë një nga dy mundësitë e rezultatit.
Problemi i sabotazhit të protokollit. PVRB juaj duhet të jetë i qëndrueshëm ndaj sulmeve, kur sulmuesi, që kontrollon një ose disa RP vendos, nëse do të ketë rastësi apo jo dhe mund të ndikojë në këtë me siguri ose me një probabilitet të caktuar.
Problemi i numrit të mesazheve. RP-të tuaja duhet të dërgojnë në blockchain sa më pak mesazhe dhe maksimalisht të shmangin veprime sinkronike si situatat "dëshiroj të dërgoj disa të dhëna, pres përgjigje nga një pjesëmarrës të caktuar". Në rrjetet p2p, veçanërisht ato gjeografiisht të shpërndara, nuk duhet të pritet një përgjigje e shpejtë.
Problemi i kompleksitetit të llogaritjes. Verifikimi i çdo faze të PVRB on-chain duhet të jetë jashtëzakonisht i lehtë, pasi ndodh nga të gjithë klientët e plotë të rrjetit. Nëse implementimi bëhet përmes një smart kontrate, kërkesat për shpejtësinë janë shumë strikte.
Problemi i доступности dhe liveness. PVRB juaj duhet të përpiqet të jetë i qëndrueshëm ndaj situatave kur një pjesë e rrjetit është bërë e paarritshme për një kohë të caktuar dhe disa RP thjesht kanë ndaluar së punuari.
Problemi i vendosjes së besuar dhe shpërndarjes fillestare të çelsave. Nëse PVRB juaj përdor konfigurimin fillestar të protokolit, kjo është një histori tjetër e madhe dhe serioze. Ja është. Nëse pjesëmarrësit duhet të njoftojnë njëri-tjetrin për çelësat e tyre para fillimit të protokolit, kjo është gjithashtu një problem, nëse grupi i pjesëmarrësve ndryshon
Problemet e zhvillimit. Prania e bibliotekave në gjuhët e nevojshme, siguria dhe performanca e tyre, publikimi, testet e komplikuara etj.

Për shembull, në lidhje me nënshkrimet BLS me prag, ka një problem të rëndësishëm - para se të fillojnë punën, pjesëmarrësit patjetër duhet t'i shpërndajnë njëri-tjetrit çelësat, duke organizuar një grup, në kuadër të cilit do të punojë prag. Kjo do të thotë se të paktën një raund shkëmbimi në një rrjet të decentralizuar duhet të pritet, dhe, duke marrë parasysh se rastësia e gjeneruar, për shembull, është e nevojshme në lojëra, praktikisht në kohë reale, kjo do të thotë se sabotimi i protokollit është i mundshëm në këtë fazë dhe përfitimet e skemës prag humbasin. Ky problem është tashmë më i lehtë se të mëparshmi, por ndalon për zhvillimin e një procedure të veçantë për formimin e grupeve prag, të cilat do të duhet të mbrohen ekonomikisht, përmes depozitave dhe konfiskimit të fondeve (slashing) nga pjesëmarrësit që nuk ndjekin protokollin. Gjithashtu, verifikimi BLS me një nivel të pranueshëm sigurie thjesht nuk vendoset, për shembull, në një transaksion standard EOS ose Ethereum - thjesht nuk ka mjaft kohë për verifikim. Kodi i kontratave është WebAssembly ose EVM, ekzekutohet nga makina virtuale. Funksionet kriptografike nuk realizohen native (për momentin), dhe punojnë disa herë më ngadalë se bibliotekat kriptografike standarde. Shumë protokolle nuk janë të përshtatshme në përputhje me kërkesat thjesht nga sasia e çelësave, për shembull, në 1024 dhe 2048 bit për RSA, 4-8 herë më shumë se nënshkrimi standard i transaksionit në Bitcoin dhe Ethereum.

Luajnë një rol edhe realizimet në gjuhë të ndryshme programimi - të cilat janë të pakta, sidomos për protokollet e reja. Opcioni me integrim në konsensus kërkon të shkruhet protokolli në gjuhën e platformës, kështu që do të duhet të kërkoni kod në Go për geth, në Rust për Parity, në C++ për EOS. Kodi në JavaScript do të duhet të kërkohet nga të gjithë, dhe për sa kohë që JavaScript dhe kriptografia nuk janë veçanërisht shokë të mirë, WebAssembly do të ndihmojë, i cili tani është përfundimisht duke pretenduar për rolin e standardit të rëndësishëm të internetit të ardhshëm.

Përfundim

Shpresoj, në të kaluarën artikulli ynë Unë arrita të ju bind se gjenerimi i numrave të rastësishëm në blockchain është kritik për shumë aspekte të jetës së rrjeteve të decentralizuara, dhe me këtë artikull tregova se kjo është një detyrë jashtëzakonisht ambicioze dhe e vështirë, por zgjidhje të mira tashmë ekzistojnë. Në përgjithësi, dizajni përfundimtar i protokollit mund të arrihet vetëm pas kryerjes së testeve të gjera që do të marrin parasysh të gjitha aspektet nga konfigurimi deri te simulimi i dështimeve, prandaj nuk do të gjeni receta gati në whitepaper-t e grupeve dhe në artikuj, as ne në vitet e ardhshme nuk do të guxojmë të shkruajmë “bëni kështu, kështu është saktësisht e drejtë”.

Derisa, për PVRB-në tonë në blockchain-in që po zhvillohet Haya, ne u ndalëm në aplikimin e nënshkrimeve threshold BLS, planifikojmë të implementojmë PVRB-në në nivelin e konsensusit, pasi verifikimi në smart kontrakta me një nivel të pranueshëm sigurie për momentin është i pamundur. Mund të ndodhë që ne të përdorim dy skema menjëherë: së pari, një ndarje sekrete të shtrenjtë për krijimin e random_seed të gjatë, dhe më pas ta përdorim atë si bazë për gjenerimin e shpeshtë të rastësishëm duke përdorur nënshkrime të determinuara threshold BLS, ndoshta do të kufizohemi vetëm në një nga skemat. Të parashikosh se si do të jetë protokolli, fatkeqësisht, është e pamundur, por vetëm se si në shkencë, edhe në detyrat inxhinierike, rezultati negativ është gjithashtu një rezultat, dhe çdo përpjekje e re për të zgjidhur problemin është një shkallë tjetër për hulumtimet e të gjithëve që merren me këtë çështje. Për të përmbushur kërkesat nga ana e biznesit, ne po zgjidhim një detyrë praktike specifike — sigurimin e aplikacioneve lojëre me një burim të besueshëm të entropisë, prandaj na detyron të kushtojmë vëmendje gjithashtu blockchain-it vetë, veçanërisht çështjeve të përfundimit të zinxhirit dhe qeverisjes së rrjetit.

Edhe pse për momentin nuk shohim në blockchain të provuar PVRB që është përdorur mjaft gjatë për të përballuar provat e aplikacioneve reale, auditeve të shumta, ngarkesave, dhe sigurisht, sulmeve reale, numri i mundësive të rrugëve konfirmon se zgjidhja ekziston, dhe ndonjë nga këto algoritme në fund do ta zgjidhë problemin. Ne do të kemos me kënaqësi rezultatet dhe falënderojmë ekipet e tjera që gjithashtu po merren me këtë çështje për artikujt dhe kodin që u lejojnë inxhinierëve të mos bien dy herë mbi të njëjtat gropa.

Nëse takoni një programues që projektin një rastësi decentralizuar, jini të kujdeshëm dhe të vëmendshëm, ofroni ndihmën psikologjike në rast nevoje 🙂

Burimi: habr.com