Paraqitje

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

Ashtu si me konceptin e një shifrimi absolutisht të fortë nga kriptografia, protokollet reale "Publicly Verifiable Random Beacon" (në tekstin e mëtejmë PVRB) përpiqen vetëm t'i afrohen sa më shumë skemës ideale, sepse në rrjetet reale nuk është i zbatueshëm në formën e tij të pastër: është e nevojshme të bihet dakord rreptësisht për një bit, duhet të ketë shumë raunde dhe të gjitha mesazhet duhet të jenë krejtësisht të shpejta dhe të shpërndahen gjithmonë. Sigurisht, kjo nuk ndodh në rrjetet reale. Prandaj, gjatë projektimit të PVRB-ve për detyra specifike në blockchains moderne, përveç pamundësisë për të kontrolluar rastësinë dhe forcën kriptografike që rezulton, lindin shumë më tepër probleme thjesht arkitekturore dhe teknike.

Për PVRB, blockchain në vetvete është në thelb një mjet komunikimi në të cilin mesazhet = transaksionet. Kjo ju lejon të abstraktoni pjesërisht nga problemet e rrjetit, mosdorëzimi i mesazheve, problemet me programin e mesëm - të gjitha këto rreziqe merren përsipër nga rrjeti i decentralizuar, dhe vlera e tij kryesore për PVRB është pamundësia për të revokuar ose korruptuar një transaksion të dërguar tashmë - kjo ndodh të mos lejojë pjesëmarrësit të refuzojnë të marrin pjesë në protokoll, përveç nëse ata kryejnë një sulm të suksesshëm me konsensus. Ky nivel sigurie është i pranueshëm, kështu që PVRB duhet të jetë rezistent ndaj marrëveshjeve të fshehta nga pjesëmarrësit në të njëjtën masë si zinxhiri kryesor i blockchain. Gjithashtu, kjo lë të kuptohet se PVRB duhet të jetë pjesë e konsensusit nëse rrjeti bie dakord për blockchain-in kryesor, edhe nëse pajtohet gjithashtu për të vetmen rastësi që rezulton e drejtë. Ose, PVRB është thjesht një protokoll i pavarur i zbatuar nga një kontratë inteligjente që funksionon në mënyrë asinkrone në lidhje me blockchain dhe blloqet. Të dyja metodat kanë avantazhet dhe disavantazhet e tyre, dhe zgjedhja midis tyre është jashtëzakonisht jo e parëndësishme.

Dy mënyra për të zbatuar PVRB

Le të përshkruajmë më në detaje dy opsione për zbatimin e PVRB - versionin e pavarur, i cili funksionon duke përdorur një kontratë inteligjente të pavarur nga blockchain, dhe versionin e integruar me konsensus, të integruar në protokoll, sipas të cilit rrjeti bie dakord për blockchain dhe transaksionet që do të përfshihen. Në të gjitha rastet, do të nënkuptoj motorë të njohur blockchain: Ethereum, EOS dhe të gjithë ata të ngjashëm me ta në mënyrën se si ata presin dhe përpunojnë kontratat inteligjente.

Kontratë e pavarur

Në këtë version, PVRB është një kontratë inteligjente që pranon transaksione të prodhuesve të rastësishëm (në tekstin e mëtejmë RP), i përpunon ato, kombinon rezultatet dhe, si rezultat, arrin në një vlerë të caktuar që çdo përdorues mund të marrë nga kjo kontratë. Kjo vlerë mund të mos ruhet drejtpërdrejt në kontratë, por përkundrazi të përfaqësohet vetëm nga të dhënat nga të cilat mund të merret në mënyrë përcaktuese një dhe vetëm një vlerë e rastit që rezulton. Në këtë skemë, RP-të janë përdorues të blockchain dhe çdokush mund të lejohet të marrë pjesë në procesin e gjenerimit.

Opsioni me kontratë të pavarur është i mirë:

• transportueshmëri (kontratat mund të tërhiqen nga blockchain në blockchain)
• lehtësia e zbatimit dhe testimit (kontratat janë të lehta për t'u shkruar dhe testuar)
• komoditet në zbatimin e skemave ekonomike (është e lehtë të bësh shenjën tënde, logjika e të cilit i shërben qëllimeve të PVRB)
• mundësia e lançimit në blockchain tashmë që funksionojnë

Ai gjithashtu ka disavantazhe:

• kufizime të forta në burimet kompjuterike, vëllimin e transaksionit dhe ruajtjen (me fjalë të tjera, cpu/mem/io)
• kufizimet në operacionet brenda kontratës (jo të gjitha udhëzimet janë të disponueshme, është e vështirë të lidhësh bibliotekat e jashtme)
• pamundësia për të organizuar mesazhe më shpejt sesa transaksionet përfshihen në blockchain

Ky opsion është i përshtatshëm për zbatimin e një PVRB që duhet të ekzekutohet në një rrjet ekzistues, nuk përmban kriptografi komplekse dhe nuk kërkon një numër të madh ndërveprimesh.

Konsensus i integruar

Në këtë version, PVRB zbatohet në kodin e nyjës blockchain, i integruar ose funksionon paralelisht me shkëmbimin e mesazheve midis nyjeve të blockchain. Rezultatet e protokollit shkruhen direkt në blloqet e prodhuara dhe mesazhet e protokollit dërgohen përmes rrjetit p2p ndërmjet nyjeve. Meqenëse protokolli rezulton në numra që do të shkruhen në blloqe, rrjeti duhet të arrijë një konsensus mbi to. Kjo do të thotë që mesazhet PVRB, si transaksionet, duhet të vërtetohen nga nyjet dhe të përfshihen në blloqe në mënyrë që çdo pjesëmarrës i rrjetit të mund të vërtetojë pajtueshmërinë me protokollin PVRB. Kjo automatikisht na çon në zgjidhjen e dukshme - nëse rrjeti bie dakord për një konsensus për një bllok dhe transaksione në të, atëherë PVRB duhet të jetë pjesë e konsensusit, dhe jo një protokoll i pavarur. Përndryshe, është e mundur që një bllok të jetë i vlefshëm nga pikëpamja e konsensusit, por nuk respektohet protokolli PVRB dhe nga pikëpamja PVRB blloku nuk mund të pranohet. Pra, nëse zgjidhet opsioni "i integruar me konsensus", PVRB bëhet një pjesë e rëndësishme e konsensusit.

Kur përshkruhen zbatimet e PVRB në nivelin e konsensusit të rrjetit, nuk mund të shmangen në asnjë mënyrë çështjet e përfundimit. Përfundimi është një mekanizëm i përdorur në konsensuset përcaktuese që kryen një bllok (dhe zinxhirin që çon në të) që është përfundimtar dhe nuk do të hidhet kurrë, edhe nëse ndodh një pirun paralel. Për shembull, në Bitcoin nuk ekziston një mekanizëm i tillë - nëse publikoni një zinxhir me kompleksitet më të madh, ai do të zëvendësojë ndonjë më pak kompleks, pavarësisht nga gjatësia e zinxhirëve. Dhe në EOS, për shembull, ato përfundimtare janë të ashtuquajturat Blloqe të Parikthyeshme të Fundit, të cilat shfaqen mesatarisht çdo 432 blloqe (12*21 + 12*15, votim paraprak + para-komponim). Ky proces në thelb pret për nënshkrimet e 2/3 e prodhuesve të bllokut (në tekstin e mëtejmë BP). Kur duken pirunët që janë më të vjetër se LIB-i i fundit, ato thjesht hidhen. Ky mekanizëm bën të mundur garantimin që transaksioni të përfshihet në blockchain dhe nuk do të rikthehet kurrë, pavarësisht se çfarë burimesh ka sulmuesi. Gjithashtu, blloqet përfundimtare janë blloqe të nënshkruara nga 2/3 BP në Hyperledger, Tendermint dhe konsensuset e tjera të bazuara në pBFT. Gjithashtu, ka kuptim të bëhet një protokoll për sigurimin e finalitetit, një shtesë e konsensusit, pasi mund të funksionojë në mënyrë asinkrone me prodhimin dhe publikimin e blloqeve. Këtu është një e mirë artikull rreth përfundimit në Ethereum.

Finaliteti është jashtëzakonisht i rëndësishëm për përdoruesit, të cilët pa të mund ta gjejnë veten viktima të një sulmi "shpenzim të dyfishtë", ku BP "mban" blloqe dhe i publikon pasi rrjeti "ka parë" një transaksion të mirë. Nëse nuk ka finalizim, atëherë forku i publikuar zëvendëson bllokun me një transaksion "të mirë" me një tjetër, nga një pirun "i keq", në të cilin të njëjtat fonde transferohen në adresën e sulmuesit. Në rastin e PVRB, kërkesat për përfundimin janë edhe më të rrepta, pasi ndërtimi i pirunëve për PVRB nënkupton mundësinë që një sulmues të përgatisë disa opsione të rastësishme në mënyrë që të publikojë atë më fitimprurëse, dhe kufizimi i kohës së një sulmi të mundshëm është një zgjidhje e mirë.

Prandaj, opsioni më i mirë është të kombinojmë PVRB dhe finalitetin në një protokoll - pastaj blloku i finalizuar = i rastësishëm i finalizuar, dhe kjo është pikërisht ajo që na duhej të merrnim. Tani lojtarët do të marrin një rastësi të garantuar në N sekonda dhe mund të jenë të sigurt se është e pamundur ta rikthejnë atë ose ta rishikojnë përsëri.

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

• mundësia e zbatimit asinkron në lidhje me prodhimin e blloqeve - blloqet prodhohen si zakonisht, por paralelisht me këtë mund të funksionojë protokolli PVRB, i cili nuk prodhon rastësi për çdo bllok.
• aftësia për të zbatuar edhe kriptografi të rënda, pa kufizimet e vendosura në kontratat inteligjente
• aftësia për të organizuar shkëmbimin e mesazheve më shpejt sesa transaksionet përfshihen në blockchain, për shembull, një pjesë e protokollit mund të funksionojë midis nyjeve pa shpërndarë mesazhe në rrjet

Ai gjithashtu ka disavantazhe:

• Vështirësitë në testim dhe zhvillim - do t'ju duhet të imitoni gabimet e rrjetit, nyjet që mungojnë, forcat e rrjetit
• Gabimet e zbatimit kërkojnë një hardfork rrjeti

Të dyja metodat e zbatimit të PVRB kanë të drejtën e jetës, por zbatimi i kontratave inteligjente në blockchains moderne është ende mjaft i kufizuar në burimet kompjuterike dhe çdo kalim në kriptografi serioze shpesh është thjesht i pamundur. Dhe ne do të kemi nevojë për kriptografi serioze, siç do të demonstrohet më poshtë. Megjithëse ky problem është qartësisht i përkohshëm, kriptografia serioze në kontrata nevojitet për të zgjidhur shumë probleme dhe gradualisht po shfaqet (për shembull, kontratat e sistemit për zkSNARKs në Ethereum)

Blockchain, i cili ofron një kanal mesazhesh protokolli transparent dhe të besueshëm, nuk e bën këtë falas. Çdo protokoll i decentralizuar duhet të marrë parasysh mundësinë e një sulmi Sybil; çdo veprim mund të bëhet nga forcat e bashkërenduara të llogarive të shumta, prandaj, kur hartohet, është e nevojshme të merret parasysh aftësia e sulmuesve për të krijuar një numër arbitrar protokolli. pjesëmarrësit që veprojnë në bashkëpunim.

PVRB dhe variablat bllok.

Nuk gënjeva kur thashë se askush nuk ka zbatuar ende një PVRB të mirë, të testuar nga shumë aplikacione të lojërave të fatit, në blockchains. Nga vijnë atëherë kaq shumë aplikacione të lojërave të fatit në Ethereum dhe EOS? Kjo më befason aq sa të habit ty, ku i kanë gjetur kaq shumë rastësi “të vazhdueshme” në një mjedis krejtësisht determinist?

Mënyra e preferuar për të marrë rastësi në blockchain është të marrësh një lloj informacioni "të paparashikueshëm" nga blloku dhe të bësh një të rastësishëm bazuar në të - thjesht duke hash një ose më shumë vlera. Artikull i mirë për problemet e skemave të tilla këtu. Ju mund të merrni ndonjë nga vlerat "të paparashikueshme" në bllok, për shembull, hash-in e bllokut, numrin e transaksioneve, kompleksitetin e rrjetit dhe vlera të tjera të panjohura paraprakisht. Pastaj hasni ato, një ose më shumë, dhe, në teori, duhet të merrni një rastësi të vërtetë. Ju madje mund të shtoni në letrën e bardhë që skema juaj është "post-kuantike e sigurt" (pasi ka funksione hash-provash kuantike :)).

Por edhe hash-et e sigurta pas kuantike nuk janë të mjaftueshme, mjerisht. Sekreti qëndron në kërkesat për PVRB, më lejoni t'ju kujtoj ato nga artikulli i mëparshëm:

1. Rezultati duhet të ketë një shpërndarje uniforme të provueshme, d.m.th. të bazohet në kriptografi të provueshme të fortë.
2. Nuk është e mundur të kontrollosh asnjë nga pjesët e rezultatit. Si pasojë, rezultati nuk mund të parashikohet paraprakisht.
3. Ju nuk mund të sabotoni protokollin e gjenerimit duke mos marrë pjesë në protokoll ose duke mbingarkuar rrjetin me mesazhe sulmi
4. Të gjitha sa më sipër duhet të jenë rezistente ndaj marrëveshjeve të fshehta të një numri të lejueshëm pjesëmarrësish të pandershëm të protokollit (për shembull, 1/3 e pjesëmarrësve).

Në këtë rast plotësohet vetëm kërkesa 1 dhe nuk plotësohet kërkesa 2. Duke hash vlerat e paparashikueshme nga blloku, do të marrim një shpërndarje uniforme dhe raste të mira. Por BP të paktën ka opsionin "të publikojë bllokun ose jo". Kështu, BP mund të paktën të zgjedhë nga DY opsione të rastësishme: "të sajën" dhe atë që do të rezultojë nëse dikush tjetër e bën bllokun. BP mund të "përgjojë" paraprakisht se çfarë do të ndodhë nëse ai publikon një bllok dhe thjesht vendos ta bëjë atë apo jo. Kështu, kur luan, për shembull, "çift-tek" ose "kuq/e zi" në ruletë, ai mund të publikojë një bllok vetëm nëse sheh një fitore. Kjo gjithashtu e bën të pazbatueshme strategjinë e përdorimit, për shembull, një hash blloku "nga e ardhmja". Në këtë rast, ata thonë se “do të përdoret rastësor, i cili fitohet duke hash të dhënat aktuale dhe hash-in e një blloku të ardhshëm me një lartësi, për shembull, N + 42, ku N është lartësia aktuale e bllokut. Kjo e forcon pak skemën, por gjithsesi i lejon BP, edhe pse në të ardhmen, të zgjedhë nëse do të mbajë bllokimin apo do të publikojë.

Softueri BP në këtë rast bëhet më i ndërlikuar, por jo shumë. Thjesht, kur vërtetohet dhe përfshihet një transaksion në një bllok, bëhet një kontroll i shpejtë për të parë nëse do të ketë një fitore dhe, ndoshta, zgjedhja e një parametri transaksioni për të marrë një probabilitet të lartë për të fituar. Në të njëjtën kohë, është pothuajse e pamundur të kapësh një BP të zgjuar për manipulime të tilla; çdo herë mund të përdorësh adresa të reja dhe të fitosh pak nga pak pa ngjallur dyshime.

Pra, metodat që përdorin informacionin nga blloku nuk janë të përshtatshme si një zbatim universal i PVRB. Në një version të kufizuar, me kufizime në madhësinë e basteve, kufizime në numrin e lojtarëve dhe/ose regjistrimin në KYC (për të parandaluar që një lojtar të përdorë adresa të shumta), këto skema mund të funksionojnë për lojëra të vogla, por asgjë më shumë.

PVRB dhe angazho-zbuloj.

Në rregull, falë hashimit dhe të paktën paparashikueshmërisë relative të hash-it të bllokut dhe variablave të tjerë. Nëse e zgjidhni problemin e minatorëve të përparuar, duhet të merrni diçka më të përshtatshme. Le të shtojmë përdoruesit në këtë skemë - le të ndikojnë gjithashtu në rastësi: çdo punonjës i mbështetjes teknike do t'ju thotë se gjëja më e rastësishme në sistemet e IT janë veprimet e përdoruesve :)

Një skemë naive, kur përdoruesit thjesht dërgojnë numra të rastësishëm dhe rezultati llogaritet si, për shembull, një hash i shumës së tyre, nuk është i përshtatshëm. Në këtë rast, lojtari i fundit, duke zgjedhur rastësisht, mund të kontrollojë se cili do të jetë rezultati. Kjo është arsyeja pse përdoret modeli commit-reveal shumë i përdorur. Pjesëmarrësit së pari dërgojnë hash nga rastet e tyre (kommitimet), dhe më pas hapin vetë rastësitë (zbulon). Faza e "zbulimit" fillon vetëm pasi të jenë mbledhur detyrimet e nevojshme, kështu që pjesëmarrësit mund të dërgojnë saktësisht hash-in e rastësishëm nga i cili dërguan më herët. Tani le t'i bashkojmë të gjitha këto së bashku me parametrat e një blloku, dhe më mirë se një i marrë nga e ardhmja (rastësia mund të gjendet vetëm në një nga blloqet e ardhshme), dhe voila - rastësia është gati! Tani çdo lojtar ndikon në rastësinë që rezulton dhe mund të "mundë" BP-në keqdashëse duke e kapërcyer atë me rastësinë e tij, të panjohur paraprakisht... Ju gjithashtu mund të shtoni mbrojtje kundër sabotimit të protokollit duke mos e hapur atë në fazën e zbulimit - thjesht duke kërkuar që një shumë e caktuar t'i bashkëngjitet transaksionit gjatë kryerjes - një depozitë sigurie, e cila do të kthehet vetëm gjatë procedurës së zbulimit. Në këtë rast, kryerja dhe moszbulimi do të jetë i padobishëm.

Ishte një përpjekje e mirë, dhe skema të tilla ekzistojnë edhe në DApp-et e lojërave, por mjerisht, kjo përsëri nuk mjafton. Tani jo vetëm minatori, por edhe çdo pjesëmarrës në protokoll mund të ndikojë në rezultatin. Është ende e mundur të kontrollohet vetë vlera, me më pak ndryshueshmëri dhe me kosto, por, si në rastin e minatorit, nëse rezultatet e vizatimit janë më të vlefshme se tarifa për pjesëmarrje në protokollin PVRB, atëherë rastësia -prodhuesi (RP) mund të vendosë nëse do të zbulojë dhe ende mund të zgjedhë nga të paktën dy opsione të rastësishme.
Por u bë e mundur ndëshkimi i atyre që kryejnë dhe nuk zbulojnë, dhe kjo skemë do të vijë në ndihmë. Thjeshtësia e tij është një avantazh serioz - protokollet më serioze kërkojnë llogaritje shumë më të fuqishme.

PVRB dhe nënshkrimet deterministe.

Ekziston një mënyrë tjetër për të detyruar RP-në të sigurojë një numër pseudo-rastësor që nuk mund të ndikojë nëse i jepet një "preimazh" - ky është një nënshkrim përcaktues. Një nënshkrim i tillë është, për shembull, RSA, dhe nuk është ECS. Nëse RP ka një palë çelësa: RSA dhe ECC, dhe ai nënshkruan një vlerë të caktuar me çelësin e tij privat, atëherë në rastin e RSA ai do të marrë NJË DHE VETËM NJË nënshkrim, dhe në rastin e ECS ai mund të gjenerojë çdo numër nënshkrime të ndryshme të vlefshme. Kjo ndodh sepse kur krijohet një nënshkrim ECS, përdoret një numër i rastësishëm, i zgjedhur nga nënshkruesi dhe ai mund të zgjidhet në çdo mënyrë, duke i dhënë mundësinë nënshkruesit të zgjedhë një nga disa nënshkrime. Në rastin e RSA: "një vlerë hyrëse" + "një palë çelësash" = "një nënshkrim". Është e pamundur të parashikohet se çfarë nënshkrimi do të marrë një RP tjetër, kështu që një PVRB me nënshkrime përcaktuese 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, rastësia e mëparshme. Kjo skemë kursen shumë burime, sepse nënshkrimet janë edhe konfirmim i sjelljes së saktë sipas protokollit dhe një burim rastësie.

Megjithatë, edhe me nënshkrime përcaktuese, skema është ende e pambrojtur ndaj problemit të “aktorit të fundit”. Pjesëmarrësi i fundit ende mund të vendosë nëse do ta publikojë nënshkrimin apo jo, duke kontrolluar kështu rezultatin. Ju mund të modifikoni skemën, të shtoni hash blloku në të, të bëni raunde në mënyrë që rezultati të mos mund të parashikohet paraprakisht, por të gjitha këto teknika, edhe duke marrë parasysh shumë modifikime, ende e lënë të pazgjidhur problemin e ndikimit të një pjesëmarrësi në kolektiv. rezulton në një mjedis të pabesueshëm dhe mund të funksionojë vetëm nën kufizime ekonomike dhe kohore. Për më tepër, madhësia e çelësave RSA (1024 dhe 2048 bit) është mjaft e madhe, dhe madhësia për transaksionet blockchain është një parametër jashtëzakonisht i rëndësishëm. Me sa duket nuk ka asnjë mënyrë të thjeshtë për të zgjidhur problemin, le të vazhdojmë.

PVRB dhe skemat e ndarjes së fshehtë

Në kriptografi, ekzistojnë skema që mund të lejojnë rrjetin të bie dakord për një dhe vetëm një vlerë PVRB, ndërsa skema të tilla janë rezistente ndaj çdo veprimi keqdashës të disa pjesëmarrësve. Një protokoll i dobishëm me të cilin ia vlen të njiheni është skema e ndarjes së fshehtë të Shamirit. Shërben për të ndarë një sekret (për shembull, një çelës sekret) në disa pjesë dhe për t'i shpërndarë këto pjesë tek N pjesëmarrës. Sekreti shpërndahet në atë mënyrë që M pjesë nga N të mjaftojnë për ta rikuperuar atë, dhe këto mund të jenë çdo pjesë M. Nëse në gishta, atëherë duke pasur një grafik të një funksioni të panjohur, pjesëmarrësit shkëmbejnë pikë në grafik, dhe pas marrjes së pikëve M, i gjithë funksioni mund të rikthehet.
Një shpjegim i mirë është dhënë në wiki por të luash me të praktikisht për të luajtur protokollin në kokën tënde është e dobishme për demo faqe.

Nëse skema FSSS (Fiat-Shamir Secret Sharing) do të ishte e zbatueshme në formën e saj të pastër, do të ishte një PVRB e pathyeshme. Në formën e tij më të thjeshtë, protokolli mund të duket si ky:

• Secili pjesëmarrës gjeneron rastësinë e tij dhe shpërndan aksione prej tij tek pjesëmarrësit e tjerë
• Secili pjesëmarrës zbulon pjesën e tij të sekreteve të pjesëmarrësve të tjerë
• Nëse një pjesëmarrës ka më shumë se M aksione, atëherë numri i këtij pjesëmarrësi mund të llogaritet dhe ai do të jetë unik, pavarësisht nga grupi i pjesëmarrësve të zbuluar
• Kombinimi i rastësive të zbuluara është PVRB e dëshiruar

Këtu, një pjesëmarrës individual nuk ndikon më në rezultatet e protokollit, përveç në rastet kur arritja e pragut të zbulimit të rastësisë varet vetëm nga ai. Prandaj, ky protokoll, nëse ekziston një proporcion i kërkuar i RP-ve që punojnë në protokoll dhe i disponueshëm, funksionon, duke zbatuar kërkesat për forcën kriptografike dhe duke qenë rezistent ndaj problemit të "aktorit të fundit".

Ky mund të jetë një opsion ideal, kjo skemë PVRB e bazuar në ndarjen e fshehtë të Fiat-Shamir përshkruhet për shembull në kjo artikull. Por, siç u përmend më lart, nëse përpiqeni ta aplikoni atë kokë më kokë në blockchain, shfaqen kufizime teknike. Këtu është një shembull i një zbatimi testues të protokollit në kontratën inteligjente EOS dhe pjesa më e rëndësishme e saj - kontrollimi i pjesëmarrësit të aksionit të publikuar: kod. Ju mund të shihni nga kodi se vërtetimi i provës kërkon disa shumëzime skalare dhe numrat e përdorur janë shumë të mëdhenj. Duhet të kuptohet se në blockchains, verifikimi ndodh në momentin kur prodhuesi i bllokut përpunon transaksionin dhe në përgjithësi, çdo pjesëmarrës duhet të verifikojë lehtësisht korrektësinë e protokollit, kështu që kërkesat për shpejtësinë e funksionit të verifikimit janë shumë serioze. . Në këtë opsion, opsioni doli të ishte joefektiv, pasi verifikimi nuk përshtatej brenda kufirit të transaksionit (0.5 sekonda).

Efikasiteti i verifikimit është një nga kërkesat më të rëndësishme për përdorimin, në përgjithësi, të çdo skeme kriptografike të avancuar në blockchain. Krijimi i provave, përgatitja e mesazheve - këto procedura mund të hiqen jashtë zinxhirit dhe të kryhen 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 e pragut

Pasi u njohëm me skemën e ndarjes së fshehtë, ne zbuluam një klasë të tërë protokollesh të bashkuar me fjalën kyçe "pragu". Kur zbulimi i disa informacioneve kërkon pjesëmarrjen e M pjesëmarrësve të ndershëm nga N, dhe grupi i pjesëmarrësve të ndershëm mund të jetë një nëngrup arbitrar i N, ne flasim për skema "pragu". Janë ata që na lejojnë të merremi me problemin e "aktorit të fundit", tani nëse sulmuesi nuk zbulon pjesën e tij të sekretit, një pjesëmarrës tjetër, i ndershëm do ta bëjë atë për të. Këto skema lejojnë marrëveshjen për një kuptim të vetëm, edhe nëse protokolli sabotohet nga disa prej pjesëmarrësve.

Kombinimi i nënshkrimeve përcaktuese dhe skemave të pragut bëri të mundur zhvillimin e një skeme shumë të përshtatshme dhe premtuese për zbatimin e PVRB - këto janë nënshkrime të pragut përcaktues. Këtu artikull në lidhje me përdorimet e ndryshme të nënshkrimeve të pragut, dhe këtu është një tjetër e mirë longread nga Dash.

Artikulli i fundit përshkruan nënshkrimet BLS (BLS qëndron për Boneh-Lynn-Sacham, këtu artikull), të cilat kanë një cilësi shumë të rëndësishme dhe jashtëzakonisht të përshtatshme për programuesit - çelësat publikë, sekretë, publikë dhe nënshkrimet BLS mund të kombinohen me njëri-tjetrin duke përdorur operacione të thjeshta matematikore, ndërsa kombinimet e tyre mbeten çelësa dhe nënshkrime të vlefshme, duke ju lejuar të grumbulloni lehtësisht shumë nënshkrimet në një dhe shumë çelësa publikë në një. Ato janë gjithashtu deterministe dhe prodhojnë 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ë në vetvete çelësa të vlefshëm, gjë që lejon zbatimin e një opsioni në të cilin M nga N pjesëmarrësit prodhojnë një dhe vetëm një nënshkrim që është përcaktues, i verifikueshëm publikisht dhe i paparashikueshëm derisa të hapet nga Mth. pjesëmarrës .

Në një skemë me nënshkrime të pragut BLS, secili pjesëmarrës nënshkruan diçka duke përdorur BLS (për shembull, rastësia e mëparshme), dhe nënshkrimi i pragut të përbashkët është rastësia e dëshiruar. Karakteristikat kriptografike të nënshkrimeve BLS plotësojnë kërkesat për cilësi të rastësishme, pjesa e pragut mbron nga "aktori i fundit" dhe kombinueshmëria unike e çelësave bën të mundur zbatimin e shumë algoritmeve më interesante që lejojnë, për shembull, grumbullimin efikas të mesazheve të protokollit. .

Pra, nëse po ndërtoni PVRB në blockchain tuaj, me shumë mundësi do të përfundoni me skemën e nënshkrimeve të pragut BLS, disa projekte tashmë po e përdorin atë. Për shembull, DFinity (këtu pikë referimi që zbaton qarkun, dhe këtu shembull zbatimi i ndarjes së sekretit të verifikueshëm), ose Keep.network (këtu është feneri i tyre i rastësishëm letër e verdhë, Por shembull kontratë inteligjente që shërben protokollin).

Zbatimi i PVRB

Fatkeqësisht, ne ende nuk shohim një protokoll të gatshëm të zbatuar në zinxhirët e bllokut PVRB që ka vërtetuar sigurinë dhe stabilitetin e tij. Edhe pse vetë protokollet janë gati, zbatimi teknik i tyre në zgjidhjet ekzistuese nuk është i lehtë. Për sistemet e centralizuara, PVRB nuk ka kuptim, dhe ato të decentralizuara janë rreptësisht të kufizuara në të gjitha burimet kompjuterike: CPU, memorie, memorie, I/O. Projektimi i një PVRB është një kombinim i protokolleve të ndryshme në mënyrë që të krijohet diçka që plotëson të gjitha kërkesat për të paktën disa blockchain të zbatueshëm. Një protokoll llogarit në mënyrë më efikase, por kërkon më shumë mesazhe midis RP-ve, ndërsa tjetri kërkon shumë pak mesazhe, por krijimi i një prove mund të jetë një detyrë që kërkon dhjetëra minuta, apo edhe orë.

Unë do të listoj faktorët që duhet të keni parasysh kur zgjidhni një PVRB cilësore:

• Forca kriptografike. PVRB-ja juaj duhet të jetë rreptësisht e paanshme, pa aftësi për të kontrolluar një bit të vetëm. Në disa skema nuk është kështu, prandaj telefononi një kriptograf
• Problemi i "aktorit të fundit".. PVRB juaj duhet të jetë rezistent ndaj sulmeve ku një sulmues që kontrollon një ose më shumë RP mund të zgjedhë një nga dy rezultatet.
• Problemi i sabotimit të protokollit. PVRB juaj duhet të jetë rezistent ndaj sulmeve ku një sulmues që kontrollon një ose më shumë RP vendos nëse do të jetë i rastësishëm apo jo dhe mund të garantohet ose me një probabilitet të caktuar për të ndikuar në këtë
• Problemi me numrin e mesazheve. RP-të tuaja duhet të dërgojnë një minimum mesazhesh në blockchain dhe të shmangin veprimet sinkrone sa më shumë që të jetë e mundur, të tilla si situata si "Kam dërguar disa informacione, jam duke pritur për një përgjigje nga një pjesëmarrës specifik". Në rrjetet p2p, veçanërisht ato të shpërndara gjeografikisht, nuk duhet të mbështeteni në një përgjigje të shpejtë
• Problemi i kompleksitetit llogaritës. Verifikimi i çdo faze të zinxhirit PVRB duhet të jetë jashtëzakonisht i lehtë, pasi kryhet nga të gjithë klientët e plotë të rrjetit. Nëse zbatimi bëhet duke përdorur një kontratë inteligjente, atëherë kërkesat e shpejtësisë janë shumë strikte
• Problemi i aksesueshmërisë dhe gjallërisë. PVRB juaj duhet të përpiqet të jetë elastike ndaj situatave kur një pjesë e rrjetit bëhet e padisponueshme për një periudhë kohore dhe një pjesë e RP thjesht ndalon së punuari
• Problemi i konfigurimit të besuar dhe shpërndarjes fillestare të çelësit. Nëse PVRB-ja juaj përdor konfigurimin primar të protokollit, atëherë kjo është një histori më vete e madhe dhe serioze. Këtu shembull. Nëse pjesëmarrësit duhet t'i tregojnë njëri-tjetrit çelësat e tyre përpara fillimit të protokollit, ky është gjithashtu një problem nëse përbërja e pjesëmarrësve ndryshon
• Problemet e zhvillimit. Disponueshmëria e bibliotekave në gjuhët e kërkuara, siguria dhe performanca e tyre, publiciteti, testet komplekse, etj.

Për shembull, nënshkrimet e pragut BLS kanë një problem të rëndësishëm - përpara se të fillojnë të punojnë, pjesëmarrësit duhet t'i shpërndajnë çelësat njëri-tjetrit, duke organizuar një grup brenda të cilit pragu do të funksionojë. Kjo do të thotë që të paktën një raund shkëmbimi në një rrjet të decentralizuar do të duhet të presë, dhe duke pasur parasysh që rand-i i gjeneruar, për shembull, është i nevojshëm në lojëra, pothuajse në kohë reale, kjo do të thotë se sabotimi i protokollit është i mundur në këtë fazë. , dhe avantazhet e skemës së pragut humbasin. Ky problem është tashmë më i thjeshtë se ai i mëparshmi, por gjithsesi kërkon zhvillimin e një procedure të veçantë për formimin e grupeve të pragut, të cilët do të duhet të mbrohen ekonomikisht, nëpërmjet depozitave dhe tërheqjes së fondeve (slashing) nga pjesëmarrësit që nuk ndjekin protokoll. Gjithashtu, verifikimi BLS me një nivel të pranueshëm sigurie thjesht nuk përshtatet, për shembull, në një transaksion standard EOS ose Ethereum - thjesht nuk ka kohë të mjaftueshme për verifikim. Kodi i kontratës është WebAssembly ose EVM, i ekzekutuar nga një makinë virtuale. Funksionet kriptografike nuk janë zbatuar në mënyrë origjinale (ende), dhe punojnë dhjetëra herë më ngadalë se bibliotekat kriptografike konvencionale. Shumë protokolle nuk i plotësojnë kërkesat thjesht bazuar në vëllimin e çelësit, për shembull 1024 dhe 2048 bit për RSA, 4-8 herë më të mëdha se nënshkrimi standard i transaksionit në Bitcoin dhe Ethereum.

Prania e zbatimeve në gjuhë të ndryshme programimi luan gjithashtu një rol - nga të cilat ka pak, veçanërisht për protokollet e reja. Opsioni me integrimin në konsensus kërkon shkrimin e një protokolli në gjuhën e platformës, kështu që do të duhet të kërkoni kodin në Go për geth, në Rust për Parity, në C++ për EOS. Të gjithë do të duhet të kërkojnë kodin JavaScript, dhe meqenëse JavaScript dhe kriptografia nuk janë miq veçanërisht të ngushtë, WebAssembly do të ndihmojë, i cili tani definitivisht pretendon të jetë standardi tjetër i rëndësishëm i Internetit.

Përfundim

Shpresoj në të mëparshmen artikull 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 detyrë është jashtëzakonisht ambicioze dhe e vështirë, por zgjidhje të mira tashmë ekzistojnë. Në përgjithësi, dizajni përfundimtar i protokollit është i mundur vetëm pas kryerjes së testeve masive që marrin parasysh të gjitha aspektet nga konfigurimi deri tek emulimi i gabimeve, kështu që nuk ka gjasa të gjeni receta të gatshme në letrat e bardha dhe artikujt e ekipit, dhe sigurisht që nuk do të vendosni në një ose dy vitet e ardhshme, shkruani "bëjeni në këtë mënyrë, saktësisht siç duhet".

Mirupafshim, për PVRB-në tonë në blockchain që po zhvillohet Haya, ne vendosëm të përdorim nënshkrimet e pragut BLS, planifikojmë të zbatojmë PVRB në nivel konsensusi, pasi verifikimi në kontratat inteligjente me një nivel të pranueshëm sigurie nuk është ende i mundur. Është e mundur që ne të përdorim dy skema njëherësh: së pari, ndarjen e shtrenjtë të sekretit për të krijuar random_seed afatgjatë, dhe më pas ne e përdorim atë si bazë për gjenerimin e rastësishëm me frekuencë të lartë duke përdorur nënshkrimet e pragut përcaktues BLS, mbase do të kufizohemi vetëm në një nga skemat. Fatkeqësisht, është e pamundur të thuhet paraprakisht se cili do të jetë protokolli; e vetmja gjë e mirë është se, si në shkencë, në problemet inxhinierike, një rezultat negativ është gjithashtu rezultat, dhe çdo përpjekje e re për të zgjidhur problemin është një hap tjetër për hulumtimin e të gjithëve të përfshirë në këtë problem. Për të përmbushur kërkesat e biznesit, ne zgjidhim një problem specifik praktik - sigurimin e aplikacioneve të lojërave me një burim të besueshëm entropie, kështu që duhet t'i kushtojmë vëmendje edhe vetë blockchain-it, në veçanti çështjeve të finalitetit të zinxhirit dhe qeverisjes së rrjetit.

Dhe edhe pse ne nuk shohim ende një PVRB rezistente të provuar në blockchains, i cili do të ishte përdorur për një kohë të mjaftueshme për t'u testuar nga aplikacione reale, auditime të shumta, ngarkesa dhe sigurisht, sulme reale, por numri i shtigjeve të mundshme konfirmon se ekziston një zgjidhje, dhe cili nga këto algoritme do ta zgjidhë përfundimisht problemin. Ne do të jemi të lumtur të ndajmë rezultatet dhe të falënderojmë ekipet e tjera që po punojnë gjithashtu në këtë çështje për artikujt dhe kodin që lejojnë inxhinierët të mos shkelin dy herë në të njëjtën grabujë.

Pra, kur takoni një programues që dizajnon rastësisht të decentralizuar, jini të vëmendshëm dhe të kujdesshëm dhe jepni ndihmë psikologjike nëse është e nevojshme :)

Burimi: www.habr.com