ProHoster > Blogs > Administrācija > NejauÅ”i skaitļi un decentralizēti tÄ«kli: implementācijas

NejauÅ”i skaitļi un decentralizēti tÄ«kli: implementācijas

Ievads

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

Tāpat kā ar absolÅ«ti spēcÄ«ga Å”ifra jēdzienu no kriptogrāfijas, arÄ« reālie ā€œPublicly Verifiable Random Beaconā€ (turpmāk PVRB) protokoli tikai cenÅ”as maksimāli pietuvoties ideālajai shēmai, jo reālos tÄ«klos tas nav piemērojams tÄ«rā veidā: ir stingri jāvienojas par vienu bitu, jābÅ«t daudzām kārtām, un visiem ziņojumiem jābÅ«t perfekti ātriem un vienmēr piegādātiem. Protams, reālos tÄ«klos tas tā nav. Tāpēc, izstrādājot PVRB specifiskiem uzdevumiem mÅ«sdienu blokķēdēs, papildus neiespējamÄ«bai kontrolēt no tā izrietoÅ”o nejauŔību un kriptogrāfisko stiprumu, rodas vēl daudzas tÄ«ri arhitektoniskas un tehniskas problēmas.

PVRB gadÄ«jumā pati blokķēde bÅ«tÄ«bā ir saziņas lÄ«dzeklis, kurā ziņojumi = darÄ«jumi. Tas ļauj daļēji abstrahēties no tÄ«kla problēmām, ziņojumu nepiegādāŔanas, problēmām ar starpprogrammatÅ«ru - visus Å”os riskus uzņemas decentralizētais tÄ«kls, un tā galvenā vērtÄ«ba PVRB ir nespēja atsaukt vai sabojāt jau nosÅ«tÄ«tu darÄ«jumu - tas notiek neļaut dalÄ«bniekiem atteikties piedalÄ«ties protokolā, ja vien viņi nav veiksmÄ«gi uzbrukuÅ”i vienprātÄ«bai. Šāds droŔības lÄ«menis ir pieņemams, tāpēc PVRB jābÅ«t izturÄ«gam pret dalÄ«bnieku slepenu vienoÅ”anos tieÅ”i tādā paŔā mērā kā galvenajai blokķēdes ķēdei. Tas arÄ« norāda uz to, ka PVRB ir jābÅ«t daļai no vienprātÄ«bas, ja tÄ«kls vienojas par galveno blokķēdi, pat ja tas vienojas arÄ« par vienÄ«go godÄ«go iegÅ«to nejauŔību. Vai arÄ« PVRB ir vienkārÅ”i atseviŔķs protokols, kas ieviests ar viedo lÄ«gumu, kas darbojas asinhroni attiecÄ«bā uz blokķēdi un blokiem. Abām metodēm ir savas priekÅ”rocÄ«bas un trÅ«kumi, un izvēle starp tām ir ārkārtÄ«gi vienkārÅ”a.

Divi veidi, kā ieviest PVRB

SÄ«kāk aprakstÄ«sim divas PVRB ievieÅ”anas iespējas - savrupo versiju, kas darbojas, izmantojot viedo lÄ«gumu neatkarÄ«gi no blokķēdes, un vienprātÄ«gi integrēto versiju, kas iebÅ«vēta protokolā, saskaņā ar kuru tÄ«kls vienojas par blokķēdi un iekļaujamie darÄ«jumi. Visos gadÄ«jumos es domāju populāros blokķēdes dzinējus: Ethereum, EOS un visus lÄ«dzÄ«gus viedo lÄ«gumu mitināŔanas un apstrādes veidā.

AtseviŔķs līgums

Å ajā versijā PVRB ir viedais lÄ«gums, kas pieņem nejauÅ”o ražotāju (turpmāk tekstā RP) darÄ«jumus, apstrādā tos, apvieno rezultātus un rezultātā iegÅ«st noteiktu vērtÄ«bu, ko no Ŕī lÄ«guma var saņemt jebkurÅ” lietotājs. Å o vērtÄ«bu nedrÄ«kst tieÅ”i glabāt lÄ«gumā, bet gan attēlot tikai ar datiem, no kuriem deterministiski var iegÅ«t vienu un tikai vienu iegÅ«tā nejauŔības vērtÄ«bu. Å ajā shēmā RP ir blokķēdes lietotāji, un Ä£enerÄ“Å”anas procesā var ļaut piedalÄ«ties ikvienam.

Iespēja ar atseviŔķu lÄ«gumu ir laba:

  • pārnesamÄ«ba (lÄ«gumus var vilkt no blokķēdes uz blokķēdi)
  • ievieÅ”anas un testÄ“Å”anas vienkārŔība (lÄ«gumus ir viegli rakstÄ«t un pārbaudÄ«t)
  • ērtÄ«ba ekonomisko shēmu ievieÅ”anā (ir vienkārÅ”i izveidot savu marÄ·ieri, kura loÄ£ika kalpo PVRB mērÄ·iem)
  • iespēja palaist jau strādājoŔās blokķēdes

Tam ir arī trūkumi:

  • stingri ierobežojumi skaitļoÅ”anas resursiem, darÄ«jumu apjomam un krātuvei (citiem vārdiem sakot, cpu/mem/io)
  • ierobežojumi operācijām lÄ«guma ietvaros (nav pieejamas visas instrukcijas, ir grÅ«ti savienot ārējās bibliotēkas)
  • nespēja organizēt ziņojumapmaiņu ātrāk nekā darÄ«jumi tiek iekļauti blokķēdē

Å Ä« opcija ir piemērota PVRB ievieÅ”anai, kas jādarbina esoÅ”ajā tÄ«klā, nesatur sarežģītu kriptogrāfiju un neprasa lielu mijiedarbÄ«bu skaitu.

Vienprātīgi integrēts

Å ajā versijā PVRB ir ieviests blokķēdes mezgla kodā, iebÅ«vēts vai darbojas paralēli ziņojumu apmaiņai starp blokķēdes mezgliem. Protokola rezultāti tiek ierakstÄ«ti tieÅ”i saražotajos blokos, un protokola ziņojumi tiek nosÅ«tÄ«ti pa p2p tÄ«klu starp mezgliem. Tā kā protokola rezultātā tiek iegÅ«ti skaitļi, kas jāraksta blokos, tÄ«klam par tiem ir jāpanāk vienprātÄ«ba. Tas nozÄ«mē, ka PVRB ziņojumi, tāpat kā transakcijas, ir jāapstiprina mezgliem un jāiekļauj blokos, lai jebkurÅ” tÄ«kla dalÄ«bnieks varētu apstiprināt atbilstÄ«bu PVRB protokolam. Tas automātiski noved pie acÄ«mredzamā risinājuma ā€“ ja tÄ«kls vienojas par konsensu par bloku un darÄ«jumiem tajā, tad PVRB ir jābÅ«t daļai no vienprātÄ«bas, nevis atseviŔķam protokolam. Pretējā gadÄ«jumā ir iespējams, ka bloks ir derÄ«gs no konsensa viedokļa, bet netiek ievērots PVRB protokols, un no PVRB viedokļa bloku nevar pieņemt. Tātad, ja tiek izvēlēta opcija ā€œvienprātÄ«gi integrētaā€, PVRB kļūst par svarÄ«gu vienprātÄ«bas daļu.

Aprakstot PVRB ievieÅ”anas tÄ«kla vienprātÄ«bas lÄ«menÄ«, nekādā gadÄ«jumā nevar izvairÄ«ties no galÄ«guma problēmām. GalÄ«gums ir mehānisms, ko izmanto deterministiskā vienprātÄ«bā, kas bloķē bloku (un ķēdi, kas ved uz to), kas ir galÄ«gs un nekad netiks izmests, pat ja notiek paralēla dakÅ”a. Piemēram, Bitcoin nav Ŕāda mehānisma - ja jÅ«s publicējat sarežģītāku ķēdi, tā aizstās jebkuru mazāk sarežģītu neatkarÄ«gi no ķēžu garuma. Un EOS, piemēram, galÄ«gie ir tā sauktie Last Irreversible Blocks, kas parādās vidēji ik pēc 432 blokiem (12*21 + 12*15, pre-vote + pre-commit). Å is process bÅ«tÄ«bā gaida 2/3 bloku ražotāju (turpmāk tekstā BP) parakstu. Kad parādās dakÅ”as, kas ir vecākas par pēdējo LIB, tās vienkārÅ”i tiek izmestas. Å is mehānisms ļauj garantēt, ka darÄ«jums ir iekļauts blokķēdē un nekad netiks atsaukts neatkarÄ«gi no uzbrucēja resursiem. ArÄ« pēdējie bloki ir bloki, ko paraksta 2/3 BP Hyperledger, Tendermint un citos uz pBFT balstÄ«tos konsensos. Ir arÄ« lietderÄ«gi protokolu galÄ«guma nodroÅ”ināŔanai padarÄ«t par vienprātÄ«bas papildinājumu, jo tas var darboties asinhroni ar bloku izveidi un publicÄ“Å”anu. Å eit ir labs raksts par galÄ«gumu Ethereum.

GalÄ«gums ir ārkārtÄ«gi svarÄ«gs lietotājiem, kuri bez tā var kļūt par "dubulto izdevumu" uzbrukuma upuriem, kur BP "tur" blokus un publicē tos pēc tam, kad tÄ«kls ir "redzējis" labu darÄ«jumu. Ja galÄ«guma nav, publicētā dakÅ”a aizstāj bloku ar ā€œlabuā€ darÄ«jumu ar citu, no ā€œsliktasā€ dakÅ”as, kurā tie paÅ”i lÄ«dzekļi tiek pārskaitÄ«ti uz uzbrucēja adresi. PVRB gadÄ«jumā prasÄ«bas pēc galÄ«guma ir vēl stingrākas, jo PVRB veidoÅ”anas dakÅ”as nozÄ«mē iespēju uzbrucējam sagatavot vairākus nejauÅ”us variantus, lai publicētu izdevÄ«gāko, un iespējamā uzbrukuma laika ierobežoÅ”ana ir labs risinājums.

Tāpēc labākais variants ir apvienot PVRB un galÄ«gumu vienā protokolā - tad pabeigtais bloks = finalized random, un tas ir tieÅ”i tas, ko mums vajadzēja iegÅ«t. Tagad spēlētāji saņems garantētu nejauŔību N sekundēs un var bÅ«t pārliecināti, ka to nav iespējams atgriezt vai atkārtoti atskaņot.

Vienprātīgi integrētā iespēja ir laba:

  • asinhronas ievieÅ”anas iespēja saistÄ«bā ar bloku ražoÅ”anu - bloki tiek ražoti kā parasti, bet paralēli tam var darboties PVRB protokols, kas nerada nejauŔību katram blokam
  • iespēja ieviest pat smagu kriptogrāfiju bez ierobežojumiem, kas noteikti viedajiem lÄ«gumiem
  • iespēja organizēt ziņojumu apmaiņu ātrāk nekā darÄ«jumi ir iekļauti blokķēdē, piemēram, daļa protokola var darboties starp mezgliem, neizplatot ziņojumus tÄ«klā

Tam ir arī trūkumi:

  • GrÅ«tÄ«bas testÄ“Å”anā un izstrādē - jums bÅ«s jāatdarina tÄ«kla kļūdas, trÅ«kstoÅ”ie mezgli, tÄ«kla cietās dakÅ”as
  • IevieÅ”anas kļūdām ir nepiecieÅ”ama tÄ«kla cietā daļa

Abām PVRB ievieÅ”anas metodēm ir tiesÄ«bas uz dzÄ«vÄ«bu, taču viedo lÄ«gumu ievieÅ”ana mÅ«sdienu blokķēdēs joprojām ir diezgan ierobežota skaitļoÅ”anas resursos, un jebkura pāreja uz nopietnu kriptogrāfiju bieži vien ir vienkārÅ”i neiespējama. Un mums bÅ«s nepiecieÅ”ama nopietna kriptogrāfija, kā tas tiks parādÄ«ts tālāk. Lai gan Ŕī problēma nepārprotami ir Ä«slaicÄ«ga, daudzu problēmu risināŔanai ir nepiecieÅ”ama nopietna kriptogrāfija lÄ«gumos, un tā pakāpeniski parādās (piemēram, sistēmas lÄ«gumi zkSNARKs Ethereum)

Blockchain, kas nodroÅ”ina caurspÄ«dÄ«gu un uzticamu protokola ziņojumapmaiņas kanālu, to nedara bez maksas. Jebkurā decentralizētajā protokolā ir jāņem vērā Sybil uzbrukuma iespēja; jebkuru darbÄ«bu var veikt vairāku kontu saskaņoti spēki, tāpēc, izstrādājot, ir jāņem vērā uzbrucēju spēja izveidot patvaļīgu skaitu protokolu dalÄ«bnieki, kas rÄ«kojas slepenā nolÄ«gumā.

PVRB un bloku mainīgie.

Es nemeloju, sakot, ka neviens blokķēdēs vēl nav ieviesis labu PVRB, ko pārbaudÄ«juÅ”as daudzas azartspēļu lietojumprogrammas. Kāpēc tad Ethereum un EOS ir tik daudz azartspēļu lietojumprogrammu? Tas mani pārsteidz tikpat ļoti kā jÅ«s, no kurienes viņi ieguva tik daudz ā€œnoturÄ«guā€ nejauŔību pilnÄ«gi deterministiskā vidē?

IecienÄ«tākais veids, kā iegÅ«t nejauŔību blokķēdē, ir paņemt no bloka kaut kādu ā€œneprognozējamuā€ informāciju un, pamatojoties uz to, izveidot nejauÅ”u informāciju - vienkārÅ”i sajaucot vienu vai vairākas vērtÄ«bas. Labs raksts par Ŕādu shēmu problēmām Å”eit. Blokā varat ņemt jebkuru no ā€œneprognozējamāmā€ vērtÄ«bām, piemēram, bloka jaucējkodu, darÄ«jumu skaitu, tÄ«kla sarežģītÄ«bu un citas iepriekÅ” nezināmas vērtÄ«bas. Pēc tam sajauciet tos, vienu vai vairākus, un teorētiski jums vajadzētu iegÅ«t Ä«stu nejauŔību. JÅ«s pat varat pievienot papÄ«ram, ka jÅ«su shēma ir ā€œpēckvantu droÅ”aā€ (jo ir kvantu droÅ”as jaucējfunkcijas :)).

Diemžēl pat pēckvantu droŔām jaukÅ”anām nepietiek. Noslēpums slēpjas prasÄ«bās PVRB, atgādināŔu tās no iepriekŔējā raksta:

  1. Rezultātam ir jābūt pierādāmi vienmērīgam sadalījumam, t.i., tam jābūt balstītam uz pierādāmi spēcīgu kriptogrāfiju.
  2. Nav iespējams kontrolēt nevienu rezultāta bitu. Tā rezultātā iznākumu nevar paredzēt iepriekÅ”.
  3. JÅ«s nevarat sabotēt Ä£enerÄ“Å”anas protokolu, nepiedaloties protokolā vai pārslogojot tÄ«klu ar uzbrukuma ziņojumiem
  4. Visam iepriekÅ”minētajam jābÅ«t izturÄ«gam pret pieļaujamā skaita negodprātÄ«gu protokola dalÄ«bnieku (piemēram, 1/3 dalÄ«bnieku) saskaņoÅ”anu.

Å ajā gadÄ«jumā ir izpildÄ«ta tikai prasÄ«ba 1, bet nav izpildÄ«ta prasÄ«ba 2. Jaukjot no bloka neparedzamas vērtÄ«bas, mēs iegÅ«sim vienmērÄ«gu sadalÄ«jumu un labus nejauŔības. Bet BP vismaz ir iespēja ā€œpublicēt bloku vai nēā€. Tādējādi BP var izvēlēties vismaz no DIVĀM nejauŔības iespējām: ā€œsavējoā€ un to, kas izrādÄ«sies, ja bloku izveidos kāds cits. BP jau iepriekÅ” var ā€œnoziegtā€, kas notiks, ja viņŔ publicēs bloku, un vienkārÅ”i izlems to darÄ«t vai nē. Tādējādi, spēlējot, piemēram, ā€œpāra nepāraā€ vai ā€œsarkans/melnsā€ ruletē, viņŔ var publicēt bloku tikai tad, ja redz laimestu. Tas arÄ« padara neÄ«stenojamu stratēģiju, piemēram, bloka hash ā€œno nākotnesā€ izmantoÅ”anas. Å ajā gadÄ«jumā viņi saka, ka ā€œtiks izmantota nejauŔība, ko iegÅ«st, jaukjot paÅ”reizējos datus un nākotnes bloka jaukÅ”anu ar augstumu, piemēram, N + 42, kur N ir paÅ”reizējais bloka augstums. Tas nedaudz pastiprina shēmu, bet tomēr ļauj BP, lai arÄ« nākotnē, izvēlēties, vai paturēt bloku vai publicēt.

BP programmatÅ«ra Å”ajā gadÄ«jumā kļūst sarežģītāka, bet ne daudz. VienkārÅ”i, apstiprinot un iekļaujot darÄ«jumu blokā, tiek ātri pārbaudÄ«ts, vai bÅ«s laimests, un, iespējams, tiek atlasÄ«ts viens darÄ«juma parametrs, lai iegÅ«tu lielu laimesta iespējamÄ«bu. Tajā paŔā laikā Ŕādām manipulācijām ir gandrÄ«z neiespējami noÄ·ert gudru BP, katru reizi var izmantot jaunas adreses un pamazām uzvarēt, neradot aizdomas.

Tātad metodes, kas izmanto informāciju no bloka, nav piemērotas kā universāla PVRB ievieÅ”ana. Ierobežotā versijā ar likmju lieluma ierobežojumiem, spēlētāju skaita ierobežojumiem un/vai KYC reÄ£istrāciju (lai viens spēlētājs nevarētu izmantot vairākas adreses), Ŕīs shēmas var darboties mazās spēlēs, bet nekas vairāk.

PVRB un apņemties-atklāt.

Labi, pateicoties jaukÅ”anai un vismaz relatÄ«vajai bloka jaukÅ”anas un citu mainÄ«go neparedzamÄ«bai. Ja atrisināsit progresÄ«vo kalnraču problēmu, jums vajadzētu iegÅ«t kaut ko piemērotāku. Pievienosim Å”ai shēmai lietotājus - lai viņi arÄ« ietekmē nejauŔību: jebkurÅ” tehniskā atbalsta darbinieks pateiks, ka IT sistēmās visnejauŔākā lieta ir lietotāju rÄ«cÄ«ba :)

Nav piemērota naiva shēma, kad lietotāji vienkārÅ”i nosÅ«ta nejauÅ”us skaitļus un rezultāts tiek aprēķināts kā, piemēram, viņu summas jaucējvārds. Å ajā gadÄ«jumā pēdējais spēlētājs, izvēloties savu nejauŔību, var kontrolēt, kāds bÅ«s rezultāts. Tāpēc tiek izmantots ļoti plaÅ”i izmantotais commit-reveal modelis. DalÄ«bnieki vispirms nosÅ«ta jaucējvērtÄ«bas no savām nejauŔībām (commits), un pēc tam paÅ”i atver nejauŔības (atklāj). ā€œAtklāŔanasā€ fāze sākas tikai pēc tam, kad ir savāktas nepiecieÅ”amās saistÄ«bas, tāpēc dalÄ«bnieki var nosÅ«tÄ«t tieÅ”i to nejauÅ”o jaucējkodu, no kura viņi sÅ«tÄ«ja iepriekÅ”. Tagad saliksim to visu kopā ar bloka parametriem, un labāk par to, kas ņemts no nākotnes (nejauŔību var atrast tikai vienā no nākotnes blokiem), un voila - nejauŔība ir gatava! Tagad jebkurÅ” spēlētājs ietekmē iegÅ«to nejauŔību un var ā€œuzveiktā€ ļaunprātÄ«go BP, ignorējot to ar savu, iepriekÅ” nezināmo nejauŔību... Varat arÄ« pievienot aizsardzÄ«bu pret protokola sabotÄ“Å”anu, neatverot to atklāŔanas stadijā - vienkārÅ”i izdarot darÄ«jumu, pieprasot pievienot noteiktu summu ā€” droŔības naudu, kas tiks atgriezta tikai atklāŔanas procedÅ«ras laikā. Å ajā gadÄ«jumā apņemÅ”anās un neizpauÅ”ana bÅ«s neizdevÄ«ga.

Tas bija labs mēģinājums, un Ŕādas shēmas pastāv arÄ« spēļu DApps, taču diemžēl ar to atkal nepietiek. Tagad ne tikai kalnracis, bet arÄ« jebkurÅ” protokola dalÄ«bnieks var ietekmēt rezultātu. Joprojām ir iespējams kontrolēt paÅ”u vērtÄ«bu, ar mazāku mainÄ«gumu un ar izmaksām, bet, tāpat kā kalnraču gadÄ«jumā, ja izlozes rezultāti ir vērtÄ«gāki par maksu par dalÄ«bu PVRB protokolā, tad izlases veidā. -producer(RP) var izlemt, vai atklāt, un joprojām var izvēlēties no vismaz divām nejauŔām iespējām.
Bet kļuva iespējams sodÄ«t tos, kas apņemas un neatklāj, un Ŕī shēma noderēs. Tā vienkārŔība ir nopietna priekÅ”rocÄ«ba ā€“ nopietnāki protokoli prasa daudz jaudÄ«gākus aprēķinus.

PVRB un deterministiskie paraksti.

Ir vēl viens veids, kā piespiest RP nodroÅ”ināt pseidogadÄ«juma skaitli, ko tas nevar ietekmēt, ja tam ir ā€œpriekÅ”attēlsā€ - tas ir deterministisks paraksts. Šāds paraksts ir, piemēram, RSA, nevis ECS. Ja RP ir atslēgu pāris: RSA un ECC, un viņŔ paraksta noteiktu vērtÄ«bu ar savu privāto atslēgu, tad RSA gadÄ«jumā viņŔ saņems VIENU UN TIKAI VIENU parakstu, un ECS gadÄ«jumā viņŔ var Ä£enerēt jebkuru skaitu dažādi derÄ«gi paraksti. Tas ir tāpēc, ka, veidojot ECS parakstu, tiek izmantots nejauÅ”s numurs, kuru izvēlas parakstÄ«tājs, un to var izvēlēties jebkurā veidā, dodot iespēju parakstÄ«tājam izvēlēties vienu no vairākiem parakstiem. RSA gadÄ«jumā: ā€œviena ievades vērtÄ«baā€ + ā€œviens atslēgu pārisā€ = ā€œviens parakstsā€. Nav iespējams paredzēt, kādu parakstu iegÅ«s cits RP, tāpēc PVRB ar deterministiskajiem parakstiem var organizēt, apvienojot vairāku dalÄ«bnieku, kuri parakstÄ«juÅ”i vienu un to paÅ”u vērtÄ«bu, RSA parakstus. Piemēram, iepriekŔējā nejauŔā. Å Ä« shēma ietaupa daudz resursu, jo paraksti ir gan apstiprinājums pareizai uzvedÄ«bai saskaņā ar protokolu, gan nejauŔības avots.

Tomēr pat ar deterministiskiem parakstiem shēma joprojām ir neaizsargāta pret ā€œpēdējā dalÄ«bniekaā€ problēmu. Pēdējais dalÄ«bnieks joprojām var izlemt, vai publicēt parakstu vai nē, tādējādi kontrolējot rezultātu. JÅ«s varat modificēt shēmu, pievienot tai bloku jaucējus, veikt apļus tā, lai rezultāts nebÅ«tu iepriekÅ” prognozējams, taču visi Å”ie paņēmieni, pat ņemot vērā daudzas modifikācijas, joprojām atstāj neatrisinātu problēmu par viena dalÄ«bnieka ietekmi uz kolektÄ«vu. rada neuzticamu vidi un var darboties tikai ar ekonomiskiem un laika ierobežojumiem. Turklāt RSA atslēgu izmērs (1024 un 2048 biti) ir diezgan liels, un blokķēdes transakciju lielums ir ārkārtÄ«gi svarÄ«gs parametrs. AcÄ«mredzot nav vienkārÅ”a veida, kā atrisināt problēmu, turpināsim.

PVRB un slepenās koplietoÅ”anas shēmas

Kriptogrāfijā ir shēmas, kas var ļaut tÄ«klam vienoties par vienu un tikai vienu PVRB vērtÄ«bu, savukārt Ŕādas shēmas ir izturÄ«gas pret jebkādām dažu dalÄ«bnieku ļaunprātÄ«gām darbÄ«bām. Viens noderÄ«gs protokols, ar kuru ir vērts iepazÄ«ties, ir Shamir slepenā koplietoÅ”anas shēma. Tas kalpo, lai sadalÄ«tu noslēpumu (piemēram, slepeno atslēgu) vairākās daļās un izplatÄ«tu Ŕīs daļas N dalÄ«bniekiem. Noslēpums tiek izplatÄ«ts tā, ka M daļas no N ir pietiekami, lai to atgÅ«tu, un tās var bÅ«t jebkuras M daļas. Ja uz pirkstiem, tad ar nezināmas funkcijas grafiku dalÄ«bnieki apmainās ar punktiem grafikā, un pēc M punktu saņemÅ”anas var atjaunot visu funkciju.
Ir sniegts labs skaidrojums Wiki bet spēlēties ar to praktiski, lai galvā nospēlētu protokolu, noder demo lappuse.

Ja FSSS (Fiat-Shamir Secret Sharing) shēma bÅ«tu piemērojama tās tÄ«rā veidā, tā bÅ«tu neiznÄ«cināma PVRB. VienkārŔākajā formā protokols varētu izskatÄ«ties Ŕādi:

  • Katrs dalÄ«bnieks Ä£enerē savu nejauŔību un izplata no tā daļas citiem dalÄ«bniekiem
  • Katrs dalÄ«bnieks atklāj savu daļu no pārējo dalÄ«bnieku noslēpumiem
  • Ja dalÄ«bniekam ir vairāk par M akcijām, tad var aprēķināt Ŕī dalÄ«bnieka skaitu, un tas bÅ«s unikāls neatkarÄ«gi no atklāto dalÄ«bnieku kopas
  • Atklāto nejauŔību kombinācija ir vēlamā PVRB

Å eit atseviŔķs dalÄ«bnieks protokola rezultātus vairs neietekmē, izņemot gadÄ«jumus, kad nejauŔības izpauÅ”anas sliekŔņa sasniegÅ”ana ir atkarÄ«ga tikai no viņa. LÄ«dz ar to Å”is protokols, ja ir vajadzÄ«gā proporcija RP, kas strādā pie protokola un ir pieejams, darbojas, ievieÅ”ot kriptogrāfijas stipruma prasÄ«bas un ir izturÄ«gs pret ā€œpēdējā dalÄ«bniekaā€ problēmu.

Tas varētu bÅ«t ideāls risinājums, Ŕī PVRB shēma, kuras pamatā ir Fiat-Shamir slepenā koplietoÅ”ana, ir aprakstÄ«ta, piemēram, Å”is rakstu. Bet, kā minēts iepriekÅ”, ja mēģināt to pielietot blokķēdē, parādās tehniski ierobežojumi. Å eit ir EOS viedā lÄ«guma protokola testa ievieÅ”anas piemērs un tā svarÄ«gākā daļa - publicētā koplietoÅ”anas dalÄ«bnieka pārbaude: kods. No koda var redzēt, ka pierādÄ«jumu validācijai ir nepiecieÅ”ami vairāki skalāri reizinājumi, un izmantotie skaitļi ir ļoti lieli. Jāsaprot, ka blokķēdēs verifikācija notiek brÄ«dÄ«, kad bloku ražotājs apstrādā darÄ«jumu, un kopumā jebkuram dalÄ«bniekam ir viegli jāpārbauda protokola pareizÄ«ba, tāpēc prasÄ«bas verifikācijas funkcijas ātrumam ir ļoti nopietnas. . Å ajā opcijā opcija izrādÄ«jās neefektÄ«va, jo pārbaude neietilpa darÄ«jumu limitā (0.5 sekundes).

Pārbaudes efektivitāte ir viena no vissvarÄ«gākajām prasÄ«bām, lai vispārēji izmantotu visas uzlabotās kriptogrāfijas shēmas blokķēdē. PierādÄ«jumu veidoÅ”ana, ziņojumu sagatavoÅ”ana - Ŕīs procedÅ«ras var izņemt no ķēdes un veikt augstas veiktspējas datoros, bet verifikāciju nevar apiet - tā ir vēl viena svarÄ«ga PVRB prasÄ«ba.

PVRB un sliekŔņa paraksti

IepazÄ«stoties ar slepenās koplietoÅ”anas shēmu, mēs atklājām veselu protokolu klasi, ko vieno atslēgvārds ā€œslieksnisā€. Ja kādas informācijas izpauÅ”anai ir nepiecieÅ”ama M godÄ«gu dalÄ«bnieku no N lÄ«dzdalÄ«ba, un godÄ«go dalÄ«bnieku kopa var bÅ«t patvaļīga N apakÅ”kopa, mēs runājam par ā€œsliekŔņaā€ shēmām. TieÅ”i viņi ļauj mums tikt galā ar ā€œpēdējā aktieraā€ problēmu, tagad, ja uzbrucējs neatklās savu noslēpuma daļu, viņa vietā to izdarÄ«s cits, godÄ«gs dalÄ«bnieks. Å Ä«s shēmas ļauj vienoties par vienu un tikai vienu nozÄ«mi, pat ja daži dalÄ«bnieki ir sabotējuÅ”i protokolu.

Deterministisko parakstu un sliekŔņa shēmu kombinācija ļāva izstrādāt ļoti ērtu un daudzsoloÅ”u shēmu PVRB ievieÅ”anai - tie ir deterministiski sliekŔņa paraksti. Å eit raksts par dažādiem sliekŔņa parakstu lietojumiem, un Å”eit ir vēl viens labs sen lasÄ«ts no Dash.

Pēdējā rakstā ir aprakstÄ«ti BLS paraksti (BLS apzÄ«mē Boneh-Lynn-Shacham, Å”eit rakstu), kurām ir ļoti svarÄ«ga un programmētājiem ārkārtÄ«gi ērta kvalitāte ā€“ publiskās, slepenās, publiskās atslēgas un BLS parakstus var kombinēt savā starpā, izmantojot vienkārÅ”as matemātiskas darbÄ«bas, savukārt to kombinācijas paliek derÄ«gas atslēgas un paraksti, ļaujot ērti apkopot daudzas. parakstus vienā un daudzas publiskās atslēgas vienā. Tie ir arÄ« deterministiski un tiem paÅ”iem ievades datiem rada vienu un to paÅ”u rezultātu. Pateicoties Å”ai kvalitātei, BLS parakstu kombinācijas paÅ”as ir derÄ«gas atslēgas, kas ļauj realizēt opciju, kurā M no N dalÄ«bniekiem rada vienu un tikai vienu parakstu, kas ir deterministisks, publiski pārbaudāms un neprognozējams lÄ«dz brÄ«dim, kad to atver Mth. dalÄ«bnieks.

Shēmā ar sliekŔņa BLS parakstiem katrs dalÄ«bnieks paraksta kaut ko, izmantojot BLS (piemēram, iepriekŔējo nejauŔību), un kopējais sliekŔņa paraksts ir vēlamais nejauÅ”s. BLS parakstu kriptogrāfiskās Ä«paŔības atbilst izlases kvalitātes prasÄ«bām, sliekŔņa daļa aizsargā pret ā€œpēdējo dalÄ«bniekuā€, un unikālā atslēgu kombinējamÄ«ba ļauj realizēt daudz interesantākus algoritmus, kas ļauj, piemēram, efektÄ«vi apkopot protokola ziņojumus. .

Tātad, ja jÅ«s veidojat PVRB savā blokķēdē, jÅ«s, visticamāk, nonāksit pie BLS sliekŔņa parakstu shēmas, un vairāki projekti jau to izmanto. Piemēram, DFinity (Å”eit etalons, kas ievieÅ” ķēdi, un Å”eit pārbaudāmas slepenās koplietoÅ”anas ievieÅ”anas piemērs) vai Keep.network (Å”eit ir viņu izlases bāka). dzeltenais papÄ«rs, Bet piemērs viedais lÄ«gums, kas apkalpo protokolu).

PVRB ievieŔana

Diemžēl joprojām neredzam PVRB blokķēdēs ieviestu gatavu protokolu, kas bÅ«tu pierādÄ«jis savu droŔību un stabilitāti. Lai arÄ« paÅ”i protokoli ir gatavi, tehniski tos piemērot esoÅ”ajiem risinājumiem nav viegli. Centralizētām sistēmām PVRB nav jēgas, un decentralizētās ir stingri ierobežotas visos skaitļoÅ”anas resursos: CPU, atmiņā, krātuvē, I/O. PVRB projektÄ“Å”ana ir dažādu protokolu kombinācija, lai izveidotu kaut ko tādu, kas atbilst visām prasÄ«bām vismaz kādai dzÄ«votspējÄ«gai blokķēdei. Viens protokols aprēķina efektÄ«vāk, bet prasa vairāk ziņojumu starp RP, bet otrs prasa ļoti maz ziņojumu, bet pierādÄ«juma izveide var bÅ«t uzdevums, kas aizņem desmitiem minÅ«Å”u vai pat stundu.

Es uzskaitÄ«Å”u faktorus, kas jums bÅ«s jāņem vērā, izvēloties kvalitatÄ«vu PVRB:

  • Kriptogrāfiskais spēks. JÅ«su PVRB ir jābÅ«t stingri objektÄ«vam, bez iespējas kontrolēt nevienu bitu. Dažās shēmās tas tā nav, tāpēc zvaniet kriptogrāfam
  • ā€œPēdējā aktieraā€ problēma. JÅ«su PVRB ir jābÅ«t izturÄ«gam pret uzbrukumiem, kad uzbrucējs, kas kontrolē vienu vai vairākus RP, var izvēlēties vienu no diviem rezultātiem.
  • Protokola sabotāžas problēma. JÅ«su PVRB ir jābÅ«t izturÄ«gam pret uzbrukumiem, kad uzbrucējs, kurÅ” kontrolē vienu vai vairākus RP, izlemj, vai tas ir nejauÅ”s vai nē, un tas var tikt garantēts vai ar noteiktu varbÅ«tÄ«bu to ietekmēt.
  • Ziņojumu skaita problēma. JÅ«su RP ir jānosÅ«ta minimālais skaits ziņojumu blokķēdei un pēc iespējas jāizvairās no sinhronām darbÄ«bām, piemēram, tādām situācijām kā ā€œEs nosÅ«tÄ«ju informāciju, gaidu atbildi no konkrēta dalÄ«bniekaā€. P2p tÄ«klos, Ä«paÅ”i Ä£eogrāfiski izkliedētajos, nevajadzētu paļauties uz ātru atbildi
  • Aprēķinu sarežģītÄ«bas problēma. Jebkura PVRB ķēdes posma pārbaudei jābÅ«t ārkārtÄ«gi vienkārÅ”ai, jo to veic visi tÄ«kla pilnie klienti. Ja ievieÅ”ana tiek veikta, izmantojot viedo lÄ«gumu, tad ātruma prasÄ«bas ir ļoti stingras
  • PieejamÄ«bas un dzÄ«vÄ«guma problēma. JÅ«su PVRB jācenÅ”as bÅ«t noturÄ«gam pret situācijām, kad daļa tÄ«kla kādu laiku kļūst nepieejama un daļa RP vienkārÅ”i pārstāj darboties.
  • Uzticamas iestatÄ«Å”anas un sākotnējās atslēgas izplatÄ«Å”anas problēma. Ja jÅ«su PVRB izmanto protokola primāro iestatÄ«jumu, tas ir atseviŔķs liels un nopietns stāsts. Å eit piemērs. Ja dalÄ«bniekiem pirms protokola sākÅ”anas jāpasaka viens otram savas atslēgas, tā ir problēma arÄ« tad, ja mainās dalÄ«bnieku sastāvs
  • AttÄ«stÄ«bas problēmas. Bibliotēku pieejamÄ«ba nepiecieÅ”amajās valodās, to droŔība un veiktspēja, publicitāte, kompleksie testi u.c.

Piemēram, sliekŔņa BLS parakstiem ir bÅ«tiska problēma ā€“ pirms darba uzsākÅ”anas dalÄ«bniekiem ir jāizdala atslēgas vienam otram, organizējot grupu, kurā darbosies slieksnis. Tas nozÄ«mē, ka vismaz viena apmaiņas kārta decentralizētā tÄ«klā bÅ«s jāgaida, un, ņemot vērā, ka Ä£enerētais rands, piemēram, ir nepiecieÅ”ams spēlēs, gandrÄ«z reāllaikā, tas nozÄ«mē, ka Å”ajā posmā ir iespējama protokola sabotāža. , un tiek zaudētas sliekŔņa shēmas priekÅ”rocÄ«bas. Å Ä« problēma jau ir vienkārŔāka nekā iepriekŔējās, taču joprojām ir jāizstrādā atseviŔķa kārtÄ«ba sliekŔņu grupu veidoÅ”anai, kas bÅ«s jāaizsargā ekonomiski, izmantojot noguldÄ«jumus un lÄ«dzekļu izņemÅ”anu (slashing) no dalÄ«bniekiem, kuri neievēro noteikumus. protokols. ArÄ« BLS verifikācija ar pieņemamu droŔības lÄ«meni vienkārÅ”i neiederas, piemēram, standarta EOS vai Ethereum darÄ«jumā - verifikācijai vienkārÅ”i nepietiek laika. LÄ«guma kods ir WebAssembly vai EVM, ko izpilda virtuālā maŔīna. Kriptogrāfiskās funkcijas nav ieviestas sākotnēji (vēl), un tās darbojas desmitiem reižu lēnāk nekā parastās kriptogrāfijas bibliotēkas. Daudzi protokoli neatbilst prasÄ«bām, vienkārÅ”i pamatojoties uz atslēgas apjomu, piemēram, 1024 un 2048 biti RSA, kas ir 4ā€“8 reizes lielāks nekā standarta darÄ«juma paraksts Bitcoin un Ethereum.

Savu lomu spēlē arÄ« implementāciju klātbÅ«tne dažādās programmÄ“Å”anas valodās, kuru ir maz, it Ä«paÅ”i jauniem protokoliem. Opcijai ar integrāciju konsensā ir nepiecieÅ”ams protokols rakstÄ«t platformas valodā, tāpēc jums bÅ«s jāmeklē kods Go for geth, Rust for Parity, C++ EOS. Katram bÅ«s jāmeklē JavaScript kods, un, tā kā JavaScript un kriptogrāfija nav Ä«paÅ”i tuvi draugi, palÄ«dzēs WebAssembly, kas tagad noteikti pretendē uz nākamo svarÄ«go interneta standartu.

Secinājums

Ceru, ka iepriekŔējā raksts Man izdevās jÅ«s pārliecināt, ka nejauÅ”u skaitļu Ä£enerÄ“Å”ana blokķēdē ir ļoti svarÄ«ga daudzos decentralizēto tÄ«klu dzÄ«ves aspektos, un ar Å”o rakstu es parādÄ«ju, ka Å”is uzdevums ir ārkārtÄ«gi ambiciozs un grÅ«ts, taču labi risinājumi jau pastāv. Kopumā protokola galÄ«gais dizains ir iespējams tikai pēc masveida testu veikÅ”anas, kas ņem vērā visus aspektus, sākot no iestatÄ«Å”anas lÄ«dz kļūdu emulācijai, tāpēc jÅ«s, visticamāk, neatradÄ«sit gatavas receptes komandu dokumentos un rakstos, un mēs noteikti to neatradÄ«sim. izlemiet tuvākā gada vai divu laikā un uzrakstiet ā€œdari tā, tieÅ”i tāā€.

Čau, mÅ«su PVRB blokķēdē, kas tiek izstrādāta Haya, mēs apņēmāmies izmantot sliekŔņa BLS parakstus, mēs plānojam ieviest PVRB konsensa lÄ«menÄ«, jo viedajos lÄ«gumos ar pieņemamu droŔības lÄ«meni verifikācija vēl nav iespējama. Iespējams, ka mēs izmantojam divas shēmas vienlaikus: pirmkārt, dārgu slepeno koplietoÅ”anu, lai izveidotu ilgtermiņa random_seed, un pēc tam mēs to izmantojam kā pamatu augstfrekvences nejauŔības Ä£enerÄ“Å”anai, izmantojot deterministiskus sliekŔņa BLS parakstus, iespējams, aprobežosimies ar tikai viena no shēmām. Diemžēl iepriekÅ” pateikt, kāds bÅ«s protokols, nav iespējams, vienÄ«gais labums ir tas, ka, tāpat kā zinātnē, arÄ« inženiertehniskajās problēmās rezultāts ir negatÄ«vs, un katrs jauns problēmas risināŔanas mēģinājums ir vēl viens solis. visu problēmu iesaistÄ«to personu izpēte. Lai apmierinātu biznesa prasÄ«bas, mēs risinām konkrētu praktisku problēmu - spēļu aplikāciju nodroÅ”ināŔanu ar uzticamu entropijas avotu, tāpēc mums ir jāpievērÅ” uzmanÄ«ba arÄ« paÅ”ai blokķēdei, jo Ä«paÅ”i ķēdes galÄ«guma un tÄ«kla pārvaldÄ«bas jautājumiem.

Un, lai gan mēs blokķēdēs vēl neredzam pārbaudÄ«tu izturÄ«gu PVRB, kas bÅ«tu izmantots pietiekami ilgu laiku, lai to pārbaudÄ«tu reālas lietojumprogrammas, vairākas pārbaudes, slodzes un, protams, reāli uzbrukumi, taču iespējamo ceļu skaits apstiprina, ka risinājums pastāv, un kāds no Å”iem algoritmiem galu galā atrisinās problēmu. Mēs labprāt dalÄ«simies ar rezultātiem un pateicamies citām komandām, kas arÄ« strādā pie Ŕī jautājuma, par rakstiem un kodu, kas ļauj inženieriem divreiz neuzkāpt uz viena grābekļa.

Tāpēc, satiekot programmētāju, kurÅ” izstrādā decentralizētu nejauŔību, esiet uzmanÄ«gs un gādÄ«gs, un vajadzÄ«bas gadÄ«jumā sniedziet psiholoÄ£isku palÄ«dzÄ«bu :)

Avots: www.habr.com

Pievieno komentāru