Enkonduko

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

Kiel kun la koncepto de absolute forta ĉifro de kriptografio, veraj "Publike Kontrolebla Hazarda Signostango" (ĉi-poste PVRB) protokoloj nur provas alproksimiĝi kiel eble plej al la ideala skemo, ĉar en realaj retoj ĝi ne aplikeblas en sia pura formo: necesas strikte konsenti pri unu bito, devas esti multaj rondoj, kaj ĉiuj mesaĝoj devas esti perfekte rapidaj kaj ĉiam transdonitaj. Kompreneble, ĉi tio ne estas la kazo en realaj retoj. Tial, kiam oni desegnas PVRB-ojn por specifaj taskoj en modernaj blokĉenoj, krom la neeblo kontroli la rezultan hazardon kaj kriptan forton, aperas multaj pli pure arkitekturaj kaj teknikaj problemoj.

Por PVRB, la blokĉeno mem estas esence komunikilo en kiu mesaĝoj = transakcioj. Ĉi tio ebligas al vi parte abstrakti de retaj problemoj, neliverado de mesaĝoj, problemoj kun mezvaro - ĉiuj ĉi tiuj riskoj estas supozitaj de la malcentralizita reto, kaj ĝia ĉefa valoro por PVRB estas la nekapablo revoki aŭ korupti jam senditan transakcion - ĉi tio faras ne permesi al partoprenantoj rifuzi partopreni en la protokolo, krom se ili faris sukcesan atakon kontraŭ konsento. Ĉi tiu nivelo de sekureco estas akceptebla, do PVRB devus esti imuna al koluzioj de partoprenantoj ĝuste en la sama mezuro kiel la ĉefa blokĉeno. Ankaŭ ĉi tio sugestas, ke la PVRB devas esti parto de la konsento se la reto konsentas pri la ĉefa blokoĉeno, eĉ se ĝi ankaŭ konsentas pri la nura justa rezulta hazarda. Aŭ, PVRB estas simple memstara protokolo efektivigita de inteligenta kontrakto, kiu funkcias nesinkrone kun respekto al la blokĉeno kaj blokoj. Ambaŭ metodoj havas siajn avantaĝojn kaj malavantaĝojn, kaj la elekto inter ili estas ege ne-triviala.

Du manieroj efektivigi PVRB

Ni priskribu pli detale du eblojn por efektivigi PVRB - la memstara versio, kiu funkcias per inteligenta kontrakto sendependa de la blokĉeno, kaj la konsent-integra versio, konstruita en la protokolo, laŭ kiu la reto konsentas pri la blokĉeno kaj la transakcioj por esti inkluzivitaj. En ĉiuj kazoj, mi signifos popularajn blokĉenajn motorojn: Ethereum, EOS, kaj ĉiuj tiuj similaj al ili en la maniero kiel ili gastigas kaj prilaboras inteligentajn kontraktojn.

Memstara kontrakto

En ĉi tiu versio, PVRB estas inteligenta kontrakto, kiu akceptas transakciojn de hazardaj produktantoj (ĉi-poste nomataj RP), prilaboras ilin, kombinas la rezultojn kaj, kiel rezulto, alvenas al certa valoro, kiun ĉiu uzanto povas ricevi de ĉi tiu kontrakto. Ĉi tiu valoro eble ne estas stokita rekte en la kontrakto, sed prefere estas reprezentita nur per datenoj de kiuj unu kaj nur unu valoro de la rezulta hazardo povas esti determinisme akirita. En ĉi tiu skemo, RP-oj estas uzantoj de la blokĉeno, kaj iu ajn povas esti permesita partopreni en la genera procezo.

La opcio kun memstara kontrakto estas bona:

• porteblo (kontraktoj povas esti trenitaj de blokĉeno al blokĉeno)
• facileco de efektivigo kaj testado (kontraktoj estas facile verkeblaj kaj provitaj)
• komforto en efektivigado de ekonomiaj skemoj (estas facile fari vian propran ĵetonon, kies logiko servas al la celoj de PVRB)
• ebleco lanĉi sur jam laborantaj blokĉenoj

Ĝi ankaŭ havas malavantaĝojn:

• fortaj limigoj pri komputikresursoj, transakcia volumo kaj stokado (alivorte, cpu/mem/io)
• limigoj pri operacioj ene de la kontrakto (ne ĉiuj instrukcioj estas haveblaj, estas malfacile konekti eksterajn bibliotekojn)
• nekapablo organizi mesaĝojn pli rapide ol transakcioj estas inkluzivitaj en la blokĉeno

Ĉi tiu opcio taŭgas por efektivigi PVRB, kiu devas esti rulita sur ekzistanta reto, ne enhavas kompleksan kriptografion kaj ne postulas grandan nombron da interagoj.

Interkonsento-integrita

En ĉi tiu versio, PVRB estas efektivigita en la blokĉena nodokodo, enkonstruita aŭ kurante paralele kun la interŝanĝo de mesaĝoj inter blokĉenaj nodoj. La rezultoj de la protokolo estas skribitaj rekte en la produktitajn blokojn, kaj protokolmesaĝoj estas senditaj tra la p2p reto inter nodoj. Ĉar la protokolo rezultigas nombrojn, kiuj estas skribendaj en blokoj, la reto devas atingi konsenton pri ili. Ĉi tio signifas, ke PVRB-mesaĝoj, kiel transakcioj, devas esti validigitaj per nodoj kaj inkluzivitaj en blokoj, por ke iu ajn retpartoprenanto povas validigi konformecon al la PVRB-protokolo. Ĉi tio aŭtomate kondukas nin al la evidenta solvo - se la reto konsentas pri konsento pri bloko kaj transakcioj en ĝi, tiam PVRB devus esti parto de la konsento, kaj ne memstara protokolo. Alie, eblas, ke bloko validas el konsenta vidpunkto, sed la PVRB-protokolo ne estas sekvata, kaj el la PVRB-punkto la bloko ne povas esti akceptita. Do se la "konsent-integra" opcio estas elektita, la PVRB fariĝas grava parto de la konsento.

Priskribante PVRB-efektivigojn ĉe la reto-interkonsentnivelo, oni ne povas neniel eviti temojn de fineco. Fineco estas mekanismo uzata en determinismaj interkonsentoj, kiu enŝlosas blokon (kaj la ĉenon kondukantan al ĝi) kiu estas fina kaj neniam estos forĵetita, eĉ se paralela forko okazas. Ekzemple, en Bitcoin ne ekzistas tia mekanismo - se vi publikigas ĉenon de pli granda komplekseco, ĝi anstataŭigos ajnan malpli kompleksan, sendepende de la longo de la ĉenoj. Kaj en EOS, ekzemple, la finaj estas la tiel nomataj Lastaj Nereversigeblaj Blokoj, kiuj aperas averaĝe ĉiujn 432 blokojn (12*21 + 12*15, antaŭvoĉdonado + antaŭ-engaĝiĝo). Ĉi tiu procezo esence atendas 2/3 de blok-produktantoj (ĉi-poste nomataj BP) subskriboj. Kiam aperas forkoj, kiuj estas pli malnovaj ol la lasta LIB, ili estas simple forĵetitaj. Ĉi tiu mekanismo ebligas garantii, ke la transakcio estas inkluzivita en la blokĉeno kaj neniam estos refarita, negrave kiajn rimedojn havas la atakanto. Ankaŭ, la finaj blokoj estas blokoj subskribitaj de 2/3 BP en Hyperledger, Tendermint kaj aliaj pBFT-bazitaj konsentoj. Ankaŭ, havas sencon fari protokolon por certigi finecon aldonaĵo al konsento, ĉar ĝi povas funkcii nesinkrone kun la produktado kaj publikigo de blokoj. Jen bona artikolo pri fineco en Ethereum.

Fineco estas ekstreme grava por uzantoj, kiuj sen ĝi povas trovi sin viktimoj de "duobla elspezo" atako, kie BP "tenas" blokojn, kaj publikigas ilin post kiam la reto "vidis" bonan transakcion. Se ne estas fineco, tiam la publikigita forko anstataŭigas la blokon per "bona" ​​transakcio kun alia, de "malbona" ​​forko, en kiu la samaj financoj estas translokigitaj al la adreso de la atakanto. En la kazo de PVRB, la postuloj por fineco estas eĉ pli striktaj, ĉar konstrui forkojn por PVRB signifas la ŝancon por atakanto prepari plurajn hazardajn elektojn por publikigi la plej enspeziga, kaj limigi la tempon de ebla atako estas bona solvo.

Tial, la plej bona elekto estas kombini PVRB kaj finaĵo en unu protokolon - tiam la finpretigita bloko = finpretigita hazarda, kaj ĉi tio estas ĝuste kion ni bezonis akiri. Nun ludantoj ricevos garantiitan hazardon en N sekundoj, kaj povas esti certaj, ke estas neeble refari ĝin aŭ reludi ĝin.

La konsent-integra opcio estas bona:

• la ebleco de nesinkrona efektivigo rilate al la produktado de blokoj - blokoj estas produktitaj kiel kutime, sed paralele kun ĉi tio povas funkcii la protokolo PVRB, kiu ne produktas hazardon por ĉiu bloko
• la kapablo efektivigi eĉ pezan kriptografion, sen la limigoj truditaj al inteligentaj kontraktoj
• la kapablo organizi la interŝanĝon de mesaĝoj pli rapide ol transakcioj estas inkluzivitaj en la blokĉeno, ekzemple, parto de la protokolo povas funkcii inter nodoj sen distribui mesaĝojn tra la reto

Ĝi ankaŭ havas malavantaĝojn:

• Malfacilaĵoj en testado kaj evoluo - vi devos imiti retajn erarojn, mankantajn nodojn, retajn malmolajn forkojn
• Efektivigaj eraroj postulas retan forkon

Ambaŭ metodoj de efektivigo de PVRB havas rajton al vivo, sed efektivigo sur inteligentaj kontraktoj en modernaj blokĉenoj ankoraŭ estas sufiĉe limigita en komputikaj rimedoj, kaj ajna transiro al serioza kriptografio ofte estas simple neebla. Kaj ni bezonos seriozan kriptografion, kiel estos pruvita sube. Kvankam ĉi tiu problemo estas klare provizora, serioza kriptografio en kontraktoj necesas por solvi multajn problemojn, kaj ĝi iom post iom aperas (ekzemple, sistemaj kontraktoj por zkSNARKs en Ethereum)

Blockchain, kiu provizas travideblan kaj fidindan protokolan mesaĝan kanalon, ne faras tion senpage. Ajna malcentralizita protokolo devas konsideri la eblecon de Sybil-atako; ajna ago povas esti farita de la kunordigitaj fortoj de multoblaj kontoj, tial, dum desegnado, necesas konsideri la kapablon de atakantoj krei arbitran nombron da protokolo. partoprenantoj agantaj en koluzioj.

PVRB kaj blokvariabloj.

Mi ne mensogis, kiam mi diris, ke neniu ankoraŭ efektivigis bonan PVRB, provitan de multaj hazardludaj aplikoj, en blokĉenoj. De kie do venas tiom da hazardludaj aplikoj sur Ethereum kaj EOS? Ĉi tio surprizas min tiom kiom ĝi surprizas vin, kie ili akiris tiom da "persistentaj" hazardoj en tute determinisma medio?

La plej ŝatata maniero akiri hazardon en la blokĉeno estas preni iun specon de "neantaŭvidebla" informo de la bloko kaj fari hazardan unu bazitan sur ĝi - simple per hashing unu aŭ pluraj valoroj. Bona artikolo pri la problemoj de tiaj skemoj tie. Vi povas preni iun ajn el la "neantaŭvideblaj" valoroj en la bloko, ekzemple, la bloko hash, la nombro da transakcioj, retokomplekseco, kaj aliaj valoroj nekonataj antaŭe. Tiam haŝu ilin, unu aŭ pli, kaj, en teorio, vi devus ricevi veran hazardan. Vi eĉ povas aldoni al la blankpapero, ke via skemo estas "post-kvantuma sekura" (ĉar ekzistas kvantum-pruvaj haŝfunkcioj :)).

Sed eĉ post-kvantumaj sekuraj haŝoj ne sufiĉas, ve. La sekreto kuŝas en la postuloj por PVRB, lasu min memorigi vin pri ili el la antaŭa artikolo:

1. La rezulto devas havi pruveble unuforman distribuon, t.e. esti bazita sur pruveble forta kriptografio.
2. Ne eblas kontroli iun ajn el la pecoj de la rezulto. Sekve, la rezulto ne povas esti antaŭvidita.
3. Vi ne povas saboti la generacian protokolon ne partoprenante en la protokolo aŭ troŝarĝante la reton per atakmesaĝoj
4. Ĉio ĉi-supra devas esti rezistema al koluzio de permesata nombro da malhonestaj protokolpartoprenantoj (ekzemple, 1/3 el la partoprenantoj).

En ĉi tiu kazo, nur postulo 1 estas plenumita, kaj postulo 2 ne estas plenumita. Haŝante neantaŭvideblajn valorojn de la bloko, ni ricevos unuforman distribuon kaj bonajn hazardojn. Sed BP almenaŭ havas la eblon "publikigi la blokon aŭ ne." Tiel, BP povas almenaŭ elekti el DU hazardaj opcioj: "sia" kaj tiu, kiu rezultos se iu alia faros la blokon. BP povas "snipi" anticipe, kio okazos se li publikigos blokon, kaj simple decidas fari ĝin aŭ ne. Tiel, ludante, ekzemple, "even-nepara" aŭ "ruĝa/nigra" en ruleto, li povas publikigi blokon nur se li vidas venkon. Ĉi tio ankaŭ faras la strategion uzi, ekzemple, blokan haŝiŝon "de la estonteco" nefarebla. En ĉi tiu kazo, ili diras, ke "hazarda estos uzata, kiu estas akirita per haŝado de la nunaj datumoj kaj la haŝo de estonta bloko kun alteco de, ekzemple, N + 42, kie N estas la nuna blokalteco. Ĉi tio iom plifortigas la skemon, sed ankoraŭ permesas al BP, kvankam estonte, elekti ĉu teni la blokon aŭ publikigi.

BP-programaro ĉi-kaze fariĝas pli komplika, sed ne multe. Simple, kiam validas kaj inkluzivi transakcion en bloko, estas rapida kontrolo por vidi ĉu estos venko, kaj, eble, elekto de unu transakcia parametroj por akiri altan probablecon de gajno. Samtempe, estas preskaŭ neeble kapti inteligentan BP por tiaj manipuladoj; ĉiufoje vi povas uzi novajn adresojn kaj gajni iom post iom sen veki suspekton.

Do metodoj uzantaj informojn de la bloko ne taŭgas kiel universala efektivigo de PVRB. En limigita versio, kun restriktoj pri vetaj grandecoj, restriktoj pri la nombro da ludantoj kaj/aŭ KYC-registrado (por malhelpi unu ludanton uzi plurajn adresojn), ĉi tiuj skemoj povas funkcii por malgrandaj ludoj, sed nenio pli.

PVRB kaj kommit-reveal.

Bone, danke al hashing kaj almenaŭ la relativa neantaŭvidebleco de la bloko hash kaj aliaj variabloj. Se vi solvas la problemon de antaŭaj ministoj, vi devus akiri ion pli taŭgan. Ni aldonu uzantojn al ĉi tiu skemo - ili ankaŭ influu la hazardon: ĉiu teknika subtena dungito diros al vi, ke la plej hazarda afero en IT-sistemoj estas la agoj de uzantoj :)

Naiva skemo, kiam uzantoj simple sendas hazardajn nombrojn kaj la rezulto estas kalkulita kiel ekzemple haŝo de ilia sumo, ne taŭgas. En ĉi tiu kazo, la lasta ludanto povas, elektante sian propran hazardan, kontroli kia estos la rezulto. Jen kial la tre vaste uzata kommit-reveal ŝablono estas uzata. Partoprenantoj unue sendas haŝojn de siaj hazardoj (kommits), kaj poste malfermas la hazardojn mem (rivelas). La "malkaŝi" fazo komenciĝas nur post kiam la necesaj komitaĵoj estas kolektitaj, do partoprenantoj povas sendi precize la hazardan haŝiŝon de kiu ili sendis pli frue. Nun ni kunigu ĉion ĉi kun la parametroj de bloko, kaj pli bone ol unu prenita el la estonteco (hazardeco nur troviĝas en unu el la estontaj blokoj), kaj voila - la hazardo estas preta! Nun iu ajn ludanto influas la rezultan hazardon, kaj povas "venki" la malican BP superregante ĝin per sia propra, nekonata anticipe, hazardo... Vi ankaŭ povas aldoni protekton kontraŭ sabotado de la protokolo ne malfermante ĝin ĉe la malkaŝa stadio - simple. postulante certan kvanton esti alfiksita al la transakcio dum farado - sekureca deponejo, kiu estos resendita nur dum la malkaŝa proceduro. En ĉi tiu kazo, fari kaj ne malkaŝi estos neprofita.

Ĝi estis bona provo, kaj tiaj skemoj ankaŭ ekzistas en videoludaj DApps, sed ve, ĉi tio denove ne sufiĉas. Nun ne nur la ministo, sed ankaŭ ajna partoprenanto en la protokolo povas influi la rezulton. Ankoraŭ eblas kontroli la valoron mem, kun malpli da ŝanĝebleco kaj koste, sed, kiel en la kazo de la ministo, se la rezultoj de la desegnaĵo estas pli valoraj ol la kotizo por partopreno en la protokolo PVRB, tiam la hazarda. -produktanto (RP) povas decidi ĉu malkaŝi kaj ankoraŭ povas elekti el almenaŭ du hazardaj elektoj.
Sed fariĝis eble puni tiujn, kiuj faras kaj ne malkaŝas, kaj ĉi tiu skemo estos utila. Ĝia simpleco estas grava avantaĝo - pli seriozaj protokoloj postulas multe pli potencajn kalkulojn.

PVRB kaj determinismaj signaturoj.

Estas alia maniero devigi la RP provizi pseŭdo-hazardan nombron, kiun ĝi ne povas influi, se ĝi estas provizita per "antaŭbildo" - ĉi tio estas determinisma subskribo. Tia subskribo estas, ekzemple, RSA, kaj ne estas ECS. Se RP havas paron da ŝlosiloj: RSA kaj ECC, kaj li subskribas certan valoron per sia privata ŝlosilo, tiam en la kazo de RSA li ricevos UNU KAJ NUR UNU subskribon, kaj en la kazo de ECS li povas generi ajnan nombron da malsamaj validaj subskriboj. Ĉi tio estas ĉar dum kreado de ECS-signaturo, hazarda nombro estas uzata, elektita de la subskribinto, kaj ĝi povas esti elektita iel ajn, donante al la subskribinto la ŝancon elekti unu el pluraj subskriboj. En la kazo de RSA: "unu eniga valoro" + "unu ŝlosilparo" = "unu subskribo". Estas maleble antaŭdiri kian subskribon ricevos alia RP, do PVRB kun determinismaj signaturoj povas esti organizita kombinante la RSA-signaturojn de pluraj partoprenantoj kiuj subskribis la saman valoron. Ekzemple, la antaŭa hazarda. Ĉi tiu skemo ŝparas multajn rimedojn, ĉar subskriboj estas kaj konfirmo de la ĝusta konduto laŭ la protokolo kaj fonto de hazardo.

Tamen, eĉ kun determinismaj signaturoj, la skemo daŭre estas vundebla al la "lasta aktoro-" problemo. La lasta partoprenanto ankoraŭ povas decidi ĉu publikigi la subskribon aŭ ne, tiel kontrolante la rezulton. Vi povas modifi la skemon, aldoni blokajn haŝojn al ĝi, fari rondojn por ke la rezulto ne estu antaŭvidebla anticipe, sed ĉiuj ĉi tiuj teknikoj, eĉ konsiderante multajn modifojn, ankoraŭ lasas nesolvita la problemo de la influo de unu partoprenanto sur la kolektivo. rezultas en nefidinda medio kaj povas funkcii nur sub ekonomiaj kaj tempolimoj. Krome, la grandeco de RSA-ŝlosiloj (1024 kaj 2048 bitoj) estas sufiĉe granda, kaj la grandeco por blokĉenaj transakcioj estas ekstreme grava parametro. Ŝajne ne ekzistas simpla maniero solvi la problemon, ni pluiru.

PVRB kaj sekretaj kundividaj skemoj

En kriptografio, ekzistas skemoj, kiuj povas permesi al la reto konsenti pri unu kaj nur unu PVRB-valoro, dum tiaj skemoj estas rezistemaj al iuj malicaj agoj de iuj partoprenantoj. Unu utila protokolo, kun kiu indas konatiĝi, estas la sekreta kundivida skemo de Shamir. Ĝi servas por dividi sekreton (ekzemple sekreta ŝlosilo) en plurajn partojn, kaj distribui tiujn partojn al N partoprenantoj. La sekreto estas distribuita tiel ke M partoj el N sufiĉas por reakiri ĝin, kaj ĉi tiuj povas esti iuj M partoj. Se sur fingroj, tiam havante grafeon de nekonata funkcio, la partoprenantoj interŝanĝas punktojn sur la grafeo, kaj post ricevado de M poentoj, la tuta funkcio povas esti restarigita.
Bona klarigo estas donita vikio sed ludi kun ĝi praktike por ludi la protokolon en via kapo estas utila por demo paĝo.

Se la skemo FSSS (Fiat-Shamir Secret Sharing) estus aplikebla en sia pura formo, ĝi estus nedetruebla PVRB. En ĝia plej simpla formo, la protokolo povus aspekti jene:

• Ĉiu partoprenanto generas sian propran hazardan kaj distribuas akciojn de ĝi al aliaj partoprenantoj
• Ĉiu partoprenanto malkaŝas sian parton de la sekretoj de la aliaj partoprenantoj
• Se partoprenanto havas pli ol M-akciojn, tiam la nombro de ĉi tiu partoprenanto povas esti kalkulita, kaj ĝi estos unika, sendepende de la aro de malkaŝitaj partoprenantoj.
• La kombinaĵo de malkaŝitaj hazardoj estas la dezirata PVRB

Ĉi tie, individua partoprenanto ne plu influas la rezultojn de la protokolo, krom en kazoj kie la atingo de la hazarda malkaŝa sojlo dependas nur de li. Sekve, ĉi tiu protokolo, se ekzistas bezonata proporcio de RPs laborantaj pri la protokolo kaj disponeblaj, funkcias, efektivigante la postulojn por kripta forto, kaj estante imuna al la "lasta aktoro" problemo.

Ĉi tio povus esti ideala opcio, ĉi tiu PVRB-skemo bazita sur Fiat-Shamir sekreta kundivido estas priskribita ekzemple en ĉi tio artikolo. Sed, kiel menciite supre, se vi provas apliki ĝin rekte en la blokĉeno, aperas teknikaj limigoj. Jen ekzemplo de prova efektivigo de la protokolo en la inteligenta kontrakto de EOS kaj ĝia plej grava parto - kontrolante la eldonitan partoprenanton: kodo. Vi povas vidi el la kodo, ke pruvvalidigo postulas plurajn skalarajn multiplikojn, kaj la nombroj uzataj estas tre grandaj. Oni devas kompreni, ke en blokĉenoj, kontroli okazas en la momento, kiam la blok-produktanto prilaboras la transakcion, kaj ĝenerale, ĉiu partoprenanto devas facile kontroli la ĝustecon de la protokolo, do la postuloj por la rapideco de la kontrola funkcio estas tre seriozaj. . En ĉi tiu opcio, la opcio montriĝis neefika, ĉar la konfirmo ne konvenis en la transakcia limo (0.5 sekundoj).

Konfirma efikeco estas unu el la plej gravaj postuloj por la uzo de, ĝenerale, iuj altnivelaj kriptaj skemoj en la blokĉeno. Krei pruvojn, prepari mesaĝojn - ĉi tiuj proceduroj povas esti prenitaj eksterĉene kaj plenumitaj sur alt-efikecaj komputiloj, sed kontrolo ne povas esti preterpasita - ĉi tio estas alia grava postulo por PVRB.

PVRB kaj sojlaj subskriboj

Konatiĝinte kun la sekreta kundivida skemo, ni malkovris tutan klason da protokoloj kunigitaj per la ŝlosilvorto "sojlo". Kiam la malkaŝo de iuj informoj postulas la partoprenon de M honestaj partoprenantoj el N, kaj la aro de honestaj partoprenantoj povas esti arbitra subaro de N, oni parolas pri "sojlaj" skemoj. Estas ili, kiuj permesas al ni trakti la problemon de "lasta aktoro", nun se la atakanto ne malkaŝas sian parton de la sekreto, alia honesta partoprenanto faros ĝin por li. Tiuj ĉi skemoj permesas interkonsenton pri unu kaj nur unu signifo, eĉ se la protokolo estas sabotita de kelkaj el la partoprenantoj.

La kombinaĵo de determinismaj subskriboj kaj sojlaj skemoj ebligis evoluigi tre oportunan kaj promesplenan skemon por efektivigi PVRB - ĉi tiuj estas determinismaj sojlaj subskriboj. Jen artikolo pri la diversaj uzoj de sojlaj subskriboj, kaj jen alia bona longe legita de Dash.

La lasta artikolo priskribas BLS-subskribojn (BLS signifas Boneh-Lynn-Shacham, jen artikolo), kiuj havas tre gravan kaj ege oportunan kvaliton por programistoj - publikaj, sekretaj, publikaj ŝlosiloj kaj BLS-subskriboj povas esti kombinitaj unu kun la alia per simplaj matematikaj operacioj, dum iliaj kombinaĵoj restas validaj ŝlosiloj kaj subskriboj, ebligante al vi facile kunigi multajn. subskriboj en unu kaj multajn publikajn ŝlosilojn en unu. Ili ankaŭ estas determinismaj kaj produktas la saman rezulton por la samaj enirdatenoj. Pro tiu kvalito, kombinaĵoj de BLS-signaturoj estas sin validaj ŝlosiloj, kio enkalkulas la efektivigon de opcio en kiu M de N partoprenantoj produktas unu kaj nur unu subskribon kiu estas determinisma, publike kontrolebla kaj neantaŭvidebla ĝis ĝi estas malfermita de la Mth. partoprenanto.

En skemo kun sojlaj BLS-signaturoj, ĉiu partoprenanto subskribas ion uzante BLS (ekzemple, la antaŭa hazarda), kaj la ofta sojlo-signaturo estas la dezirata hazarda. La kriptografiaj propraĵoj de BLS-signaturoj kontentigas la postulojn por hazarda kvalito, la sojla parto protektas kontraŭ "lasta aktoro", kaj la unika kombineblo de ŝlosiloj ebligas efektivigi multajn pli interesajn algoritmojn, kiuj ebligas, ekzemple, efikan agregadon de protokolaj mesaĝoj. .

Do, se vi konstruas PVRB sur via blokĉeno, vi plej verŝajne finos kun la BLS-sojla subskriba skemo, pluraj projektoj jam uzas ĝin. Ekzemple, DFinity (tie komparnormo kiu efektivigas la cirkviton, kaj tie ekzemplo efektivigo de kontrolebla sekreta kundivido), aŭ Keep.network (ĉi tie estas ilia hazarda signostango flava papero, sed ekzemplo inteligenta kontrakto servanta la protokolon).

Efektivigo de PVRB

Bedaŭrinde, ni ankoraŭ ne vidas pretan protokolon efektivigitan en PVRB-blokĉenoj, kiu pruvis sian sekurecon kaj stabilecon. Kvankam la protokoloj mem estas pretaj, teknike apliki ilin al ekzistantaj solvoj ne estas facila. Por centralizitaj sistemoj, PVRB ne havas sencon, kaj malcentralizitaj estas strikte limigitaj en ĉiuj komputikaj rimedoj: CPU, memoro, stokado, I/O. Desegni PVRB estas kombinaĵo de malsamaj protokoloj por krei ion, kiu plenumas ĉiujn postulojn por almenaŭ iu realigebla blokĉeno. Unu protokolo kalkulas pli efike, sed postulas pli da mesaĝoj inter RP-oj, dum la alia postulas tre malmultajn mesaĝojn, sed krei pruvon povas esti tasko kiu daŭras dekojn da minutoj, aŭ eĉ horojn.

Mi listigos la faktorojn, kiujn vi devos konsideri kiam vi elektas kvalitan PVRB:

• Kriptografia forto. Via PVRB devas esti strikte neprejugebla, sen kapablo kontroli eĉ unu pecon. En iuj skemoj tio ne estas la kazo, do voku kriptografon
• La "lasta aktoro" problemo. Via PVRB devas esti imuna al atakoj kie atakanto kontrolanta unu aŭ plurajn RP-ojn povas elekti unu el du rezultoj.
• Problemo pri sabotado de protokolo. Via PVRB devas esti imuna al atakoj kie atakanto kontrolanta unu aŭ plurajn RP-ojn decidas ĉu esti hazarda aŭ ne kaj povas aŭ esti garantiita aŭ kun donita probablo influi ĉi tion.
• Problemo de nombro da mesaĝoj. Viaj RP-oj devus sendi minimumon da mesaĝoj al la blokĉeno kaj eviti sinkronajn agojn kiel eble plej multe kiel situacioj kiel "Mi sendis iujn informojn, mi atendas respondon de specifa partoprenanto." En p2p-retoj, precipe geografie disigitaj, vi ne devus kalkuli je rapida respondo
• La problemo de komputila komplekseco. Kontrolo de iu ajn etapo de la ĉeno PVRB devus esti ekstreme facila, ĉar ĝi estas farita de ĉiuj plenaj klientoj de la reto. Se la efektivigo estas farita per inteligenta kontrakto, tiam la rapidpostuloj estas tre striktaj
• La problemo de alirebleco kaj viveco. Via PVRB devus strebi esti rezistema al situacioj kie parto de la reto fariĝas neatingebla dum tempodaŭro kaj parto de la RP simple ĉesas funkcii.
• La problemo de fidinda aranĝo kaj komenca ŝlosila distribuo. Se via PVRB uzas la ĉefan aranĝon de la protokolo, tiam ĉi tio estas aparta granda kaj serioza rakonto. Jen ekzemplo. Se partoprenantoj devas diri al unu la alian siajn ŝlosilojn antaŭ ol komenci la protokolon, tio ankaŭ estas problemo se la konsisto de partoprenantoj ŝanĝiĝas
• Disvolvaj problemoj. Havebleco de bibliotekoj en la bezonataj lingvoj, ilia sekureco kaj agado, publikeco, kompleksaj testoj, ktp.

Ekzemple, sojlaj BLS-subskriboj havas gravan problemon - antaŭ ol komenci labori, partoprenantoj devas distribui ŝlosilojn unu al la alia, organizante grupon ene de kiu sojlo funkcios. Ĉi tio signifas, ke almenaŭ unu rondo de interŝanĝo en malcentralizita reto devos atendi, kaj konsiderante ke la generita rand, ekzemple, estas necesa en ludoj, preskaŭ en reala tempo, tio signifas, ke sabotado de la protokolo eblas en ĉi tiu etapo. , kaj la avantaĝoj de la sojla skemo estas perditaj . Ĉi tiu problemo jam estas pli simpla ol la antaŭaj, sed ankoraŭ postulas la disvolviĝon de aparta proceduro por la formado de sojlaj grupoj, kiuj devos esti protektitaj ekonomie, per deponejoj kaj forigo de financoj (tranĉado) de partoprenantoj, kiuj ne sekvas la protokolo. Ankaŭ, BLS-konfirmo kun akceptebla nivelo de sekureco simple ne taŭgas, ekzemple, en norma EOS aŭ Ethereum-transakcio - simple ne estas sufiĉe da tempo por konfirmo. La kontraktokodo estas WebAssembly aŭ EVM, ekzekutita de virtuala maŝino. Kriptografiaj funkcioj ne estas realigitaj denaske (ankoraŭ), kaj funkcias dekoble pli malrapide ol konvenciaj kriptaj bibliotekoj. Multaj protokoloj ne plenumas la postulojn simple bazitajn sur ŝlosila volumo, ekzemple 1024 kaj 2048 bitoj por RSA, 4-8 fojojn pli grandaj ol la norma transakcia subskribo en Bitcoin kaj Ethereum.

La ĉeesto de efektivigoj en malsamaj programlingvoj ankaŭ ludas rolon - el kiuj estas malmultaj, precipe por novaj protokoloj. La opcio kun integriĝo en konsenton postulas verki protokolon en la platformlingvo, do vi devos serĉi kodon en Go for geth, en Rust for Parity, en C++ por EOS. Ĉiuj devos serĉi JavaScript-kodon, kaj ĉar JavaScript kaj kriptografio ne estas precipe proksimaj amikoj, WebAssembly helpos, kiu nun certe asertas esti la sekva grava Interreta normo.

konkludo

Mi esperas en la antaŭa artikolo Mi sukcesis konvinki vin, ke generi hazardajn nombrojn sur la blokĉeno estas kritika por multaj aspektoj de la vivo de malcentralizitaj retoj, kaj per ĉi tiu artikolo mi montris, ke ĉi tiu tasko estas ege ambicia kaj malfacila, sed bonaj solvoj jam ekzistas. Ĝenerale, la fina desegno de la protokolo eblas nur post farado de amasaj testoj, kiuj konsideras ĉiujn aspektojn de aranĝo ĝis misfunkciado, do vi verŝajne ne trovos pretajn receptojn en teamaj blankpaperoj kaj artikoloj, kaj ni certe ne trovos. decidu en la venontaj jaroj aŭ du skribu "faru ĝin tiel, ĝuste ĝuste."

Adiaŭ, por nia PVRB en la blokĉeno evoluanta Haya, ni decidis uzi sojlon BLS-subskribojn, ni planas efektivigi PVRB ĉe la konsenta nivelo, ĉar konfirmo en inteligentaj kontraktoj kun akceptebla nivelo de sekureco ankoraŭ ne eblas. Eblas, ke ni uzas du skemojn samtempe: unue, multekostan sekretan kundividon por krei longdaŭran hazardan_semon, kaj poste ni uzas ĝin kiel bazon por altfrekvenca hazarda generacio uzante determinisman sojlon BLS-subskribojn, eble ni limigos nin nur nur. unu el la skemoj. Bedaŭrinde, estas neeble anticipe diri, kia estos la protokolo; la sola bona afero estas ke, kiel en scienco, en inĝenieraj problemoj, ankaŭ negativa rezulto estas rezulto, kaj ĉiu nova provo solvi la problemon estas alia paŝo por la esplorado de ĉiuj implikitaj en la problemo. Por plenumi komercajn postulojn, ni solvas specifan praktikan problemon - provizante videoludadajn aplikaĵojn per fidinda fonto de entropio, do ni ankaŭ devas atenti la blokĉenon mem, precipe la aferojn de ĉena fineco kaj reto-regado.

Kaj kvankam ni ankoraŭ ne vidas pruvitan rezisteman PVRB en blokĉenoj, kiu estus uzata dum sufiĉe da tempo por esti provita per realaj aplikoj, multoblaj auditoroj, ŝarĝoj, kaj kompreneble, realaj atakoj, sed la nombro da eblaj vojoj konfirmas tion. solvo ekzistas, kaj kio el tiuj ĉi algoritmoj finfine solvos la problemon. Ni ĝojos kundividi la rezultojn kaj danki aliajn teamojn, kiuj ankaŭ laboras pri ĉi tiu afero por artikoloj kaj kodoj, kiuj permesas al inĝenieroj ne treti la saman rastilon dufoje.

Do, kiam vi renkontas programiston desegnanta malcentralizitan hazardan, estu atenta kaj zorgema, kaj provu psikologian helpon se necese :)

fonto: www.habr.com