Utangulizi

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

Kama ilivyo kwa dhana ya sifa kali kabisa kutoka kwa kriptografia, itifaki halisi za "Beacon Inayoweza Kuthibitishwa Hadharani" (hapa PVRB) hujaribu tu kukaribia mpango bora iwezekanavyo, kwa sababu. katika mitandao halisi haitumiki kwa fomu yake safi: ni muhimu kukubaliana madhubuti kwa kidogo moja, kuna lazima iwe na pande nyingi, na ujumbe wote lazima uwe haraka kabisa na daima uwasilishwe. Bila shaka, hii sivyo ilivyo katika mitandao halisi. Kwa hivyo, wakati wa kubuni PVRBs kwa kazi maalum katika blockchains za kisasa, pamoja na kutowezekana kwa kudhibiti bahati nasibu na nguvu ya kriptografia, shida nyingi za usanifu na kiufundi huibuka.

Kwa PVRB, blockchain yenyewe kimsingi ni njia ya mawasiliano ambayo ujumbe = shughuli. Hii hukuruhusu kujiondoa kwa sehemu kutoka kwa shida za mtandao, kutowasilisha ujumbe, shida na vifaa vya kati - hatari hizi zote huchukuliwa na mtandao uliowekwa madarakani, na dhamana yake kuu kwa PVRB ni kutokuwa na uwezo wa kubatilisha au kupotosha shughuli iliyotumwa tayari - hii haina. usiruhusu washiriki kukataa kushiriki katika itifaki, isipokuwa walifanya shambulio la mafanikio kwenye makubaliano. Kiwango hiki cha usalama kinakubalika, kwa hivyo PVRB inapaswa kuwa sugu kwa kula njama na washiriki kwa kiwango sawa kabisa na mnyororo mkuu wa blockchain. Pia, hii inadokeza kwamba PVRB lazima iwe sehemu ya maafikiano ikiwa mtandao unakubali msururu mkuu wa kuzuia, hata kama pia unakubali matokeo ya haki tu bila mpangilio. Au, PVRB ni itifaki ya pekee inayotekelezwa na mkataba mahiri ambao hufanya kazi kwa usawa kuhusiana na blockchain na blocks. Njia zote mbili zina faida na hasara zao, na uchaguzi kati yao sio mdogo sana.

Njia mbili za kutekeleza PVRB

Wacha tueleze kwa undani zaidi chaguzi mbili za kutekeleza PVRB - toleo la pekee, ambalo linafanya kazi kwa kutumia mkataba mzuri wa kujitegemea wa blockchain, na toleo lililojumuishwa la makubaliano, lililojengwa ndani ya itifaki, kulingana na ambayo mtandao unakubaliana juu ya blockchain na shughuli zitajumuishwa. Katika hali zote, nitamaanisha injini maarufu za blockchain: Ethereum, EOS, na zote zinazofanana nazo kwa jinsi wanavyoandaa na kushughulikia mikataba mahiri.

Mkataba wa pekee

Katika toleo hili, PVRB ni mkataba mahiri ambao unakubali miamala ya watayarishaji nasibu (hapa inajulikana kama RP), huyachakata, kuchanganya matokeo, na, matokeo yake, kufikia thamani fulani ambayo mtumiaji yeyote anaweza kupokea kutoka kwa mkataba huu. Thamani hii inaweza isihifadhiwe moja kwa moja kwenye mkataba, lakini badala yake iwakilishwe tu na data ambayo thamani moja na moja pekee ya bahati nasibu inayotokana inaweza kupatikana kwa kubaini. Katika mpango huu, RPs ni watumiaji wa blockchain, na mtu yeyote anaweza kuruhusiwa kushiriki katika mchakato wa kizazi.

Chaguo na mkataba wa kujitegemea ni nzuri:

• kubebeka (mikataba inaweza kuvutwa kutoka blockchain hadi blockchain)
• urahisi wa utekelezaji na upimaji (mikataba ni rahisi kuandika na kujaribu)
• urahisi katika kutekeleza mipango ya kiuchumi (ni rahisi kutengeneza ishara yako mwenyewe, ambayo mantiki yake hutumikia madhumuni ya PVRB)
• uwezekano wa kuzindua kwenye blockchains tayari kufanya kazi

Pia ina hasara:

• vikwazo vikali kwenye rasilimali za kompyuta, kiasi cha muamala na hifadhi (kwa maneno mengine, cpu/mem/io)
• vikwazo juu ya uendeshaji ndani ya mkataba (sio maelekezo yote yanapatikana, ni vigumu kuunganisha maktaba ya nje)
• kutokuwa na uwezo wa kupanga ujumbe haraka kuliko shughuli zinavyojumuishwa kwenye blockchain

Chaguo hili linafaa kwa kutekeleza PVRB ambayo inahitaji kuendeshwa kwenye mtandao uliopo, haina cryptography tata na hauhitaji idadi kubwa ya mwingiliano.

Makubaliano-yameunganishwa

Katika toleo hili, PVRB inatekelezwa katika msimbo wa nodi ya blockchain, iliyojengwa ndani au inayoendesha sambamba na ubadilishanaji wa ujumbe kati ya nodi za blockchain. Matokeo ya itifaki yameandikwa moja kwa moja kwenye vitalu vinavyozalishwa, na ujumbe wa itifaki hutumwa kwenye mtandao wa p2p kati ya nodes. Kwa kuwa matokeo ya itifaki kwa nambari ambazo zinapaswa kuandikwa kwa vitalu, mtandao lazima ufikie makubaliano juu yao. Hii ina maana kwamba ujumbe wa PVRB, kama vile miamala, lazima uidhinishwe na nodi na ujumuishwe kwenye vizuizi ili mshiriki yeyote wa mtandao aweze kuthibitisha utii wa itifaki ya PVRB. Hii inatuongoza moja kwa moja kwenye suluhisho la dhahiri - ikiwa mtandao unakubaliana juu ya makubaliano kuhusu kuzuia na shughuli ndani yake, basi PVRB inapaswa kuwa sehemu ya makubaliano, na si itifaki ya kujitegemea. Vinginevyo, inawezekana kwamba kizuizi ni halali kutoka kwa mtazamo wa makubaliano, lakini itifaki ya PVRB haifuatwi, na kutoka kwa mtazamo wa PVRB kizuizi hakiwezi kukubalika. Kwa hivyo ikiwa chaguo la "makubaliano-jumuishi" limechaguliwa, PVRB inakuwa sehemu muhimu ya makubaliano.

Wakati wa kuelezea utekelezaji wa PVRB katika kiwango cha makubaliano ya mtandao, mtu hawezi kwa njia yoyote kuepuka masuala ya mwisho. Mwisho ni utaratibu unaotumiwa katika makubaliano ya kuamua ambayo hufanya kizuizi (na mnyororo unaoelekea) ambayo ni ya mwisho na haitatupwa kamwe, hata kama uma sambamba hutokea. Kwa mfano, katika Bitcoin hakuna utaratibu kama huo - ikiwa utachapisha mlolongo wa ugumu zaidi, utachukua nafasi yoyote isiyo ngumu, bila kujali urefu wa minyororo. Na katika EOS, kwa mfano, wale wa mwisho ni wale wanaoitwa Vitalu vya Mwisho visivyoweza kurekebishwa, vinavyoonekana kwa wastani kila vitalu 432 (12*21 + 12*15, kura ya awali + kabla ya kujitolea). Mchakato huu kimsingi unangojea 2/3 ya saini za watengenezaji block (hapa inajulikana kama saini za BP). Wakati uma zinaonekana ambazo ni za zamani kuliko LIB ya mwisho, hutupwa tu. Utaratibu huu unawezesha kuhakikisha kwamba shughuli imejumuishwa kwenye blockchain na haitarudishwa nyuma, haijalishi ni rasilimali gani mshambuliaji anayo. Pia, vitalu vya mwisho ni vitalu vilivyosainiwa na 2/3 BP katika Hyperledger, Tendermint na makubaliano mengine ya msingi wa pBFT. Pia, ni jambo la maana kufanya itifaki ya kuhakikisha kuwa mwisho ni nyongeza ya makubaliano, kwa kuwa inaweza kufanya kazi kwa usawa na uzalishaji na uchapishaji wa vitalu. Hapa kuna nzuri makala kuhusu mwisho katika Ethereum.

Mwisho ni muhimu sana kwa watumiaji, ambao bila hiyo wanaweza kujikuta wahasiriwa wa shambulio la "matumizi mara mbili", ambapo BP "inashikilia" vizuizi, na kuzichapisha baada ya mtandao "kuona" shughuli nzuri. Ikiwa hakuna mwisho, basi uma uliochapishwa hubadilisha kizuizi na shughuli "nzuri" na mwingine, kutoka kwa uma "mbaya", ambayo fedha sawa huhamishiwa kwenye anwani ya mshambuliaji. Kwa upande wa PVRB, mahitaji ya umaliziaji ni magumu zaidi, kwani ujenzi wa uma kwa PVRB unamaanisha fursa kwa mshambuliaji kuandaa chaguzi kadhaa za nasibu ili kuchapisha ile yenye faida zaidi, na kupunguza wakati wa shambulio linalowezekana. suluhisho nzuri.

Kwa hiyo, chaguo bora zaidi ni kuchanganya PVRB na mwisho katika itifaki moja - kisha kuzuia kukamilika = kukamilika kwa random, na hii ndiyo hasa tuliyohitaji kupata. Sasa wachezaji watapokea nasibu iliyohakikishwa baada ya sekunde N, na wanaweza kuwa na uhakika kwamba haiwezekani kuirudisha nyuma au kuicheza tena.

Chaguo lililojumuishwa la makubaliano ni nzuri:

• uwezekano wa utekelezaji wa asynchronous kuhusiana na utengenezaji wa vitalu - vitalu hutolewa kama kawaida, lakini sambamba na hii, itifaki ya PVRB inaweza kufanya kazi, ambayo haitoi bahati nasibu kwa kila block.
• uwezo wa kutekeleza hata cryptography nzito, bila vikwazo vilivyowekwa kwenye mikataba ya smart
• uwezo wa kupanga ubadilishanaji wa ujumbe haraka kuliko shughuli zilizojumuishwa kwenye blockchain, kwa mfano, sehemu ya itifaki inaweza kufanya kazi kati ya nodi bila kusambaza ujumbe kwenye mtandao.

Pia ina hasara:

• Ugumu katika upimaji na ukuzaji - italazimika kuiga makosa ya mtandao, nodi zilizokosekana, uma ngumu za mtandao.
• Hitilafu za utekelezaji zinahitaji hardfork ya mtandao

Mbinu zote mbili za kutekeleza PVRB zina haki ya kuishi, lakini utekelezaji wa mikataba mahiri katika minyororo ya kisasa bado ni mdogo katika rasilimali za kompyuta, na ubadilishaji wowote wa kriptografia kubwa mara nyingi hauwezekani. Na tutahitaji cryptography kubwa, kama itaonyeshwa hapa chini. Ijapokuwa tatizo hili ni la muda mfupi, cryptography kubwa katika mikataba inahitajika ili kutatua matatizo mengi, na inaonekana hatua kwa hatua (kwa mfano, mikataba ya mfumo wa zkSNARKs katika Ethereum)

Blockchain, ambayo hutoa njia ya uwazi na ya kuaminika ya ujumbe wa itifaki, haifanyi hivyo bila malipo. Itifaki yoyote ya ugatuzi lazima izingatie uwezekano wa shambulio la Sybil; hatua yoyote inaweza kufanywa na nguvu za pamoja za akaunti nyingi, kwa hivyo, wakati wa kuunda, ni muhimu kuzingatia uwezo wa washambuliaji kuunda idadi ya kiholela ya itifaki. washiriki wakiigiza kwa kushirikiana.

PVRB na vigezo vya kuzuia.

Sikusema uongo niliposema kuwa hakuna mtu bado ametekeleza PVRB nzuri, iliyojaribiwa na maombi mengi ya kamari, katika blockchains. Ni wapi basi maombi mengi ya kamari yanatoka kwenye Ethereum na EOS? Hili linanishangaza kama vile linakushangaza, walipata wapi nasibu nyingi "zinazoendelea" katika mazingira ya kuamua kabisa?

Njia pendwa ya kupata nasibu katika blockchain ni kuchukua aina fulani ya taarifa "zisizotabirika" kutoka kwenye kizuizi na kutengeneza moja kwa moja kulingana nayo - kwa kuharakisha thamani moja au zaidi. Nakala nzuri kuhusu shida za miradi kama hii hapa. Unaweza kuchukua maadili yoyote "isiyotabirika" kwenye kizuizi, kwa mfano, hashi ya kuzuia, idadi ya shughuli, ugumu wa mtandao, na maadili mengine ambayo hayajulikani mapema. Kisha heshi, moja au zaidi, na, kwa nadharia, unapaswa kupata nasibu halisi. Unaweza hata kuongeza kwenye wihitepaper kwamba mpango wako ni "salama baada ya quantum" (kwa kuwa kuna vitendaji vya heshi vinavyothibitisha kiasi :)).

Lakini hata heshi salama baada ya quantum haitoshi, ole. Siri iko katika mahitaji ya PVRB, wacha niwakumbushe kutoka kwa nakala iliyotangulia:

1. Matokeo yake lazima yawe na usambazaji sawa, yaani, msingi wa kriptografia yenye nguvu inayowezekana.
2. Haiwezekani kudhibiti sehemu yoyote ya matokeo. Kama matokeo, matokeo hayawezi kutabiriwa mapema.
3. Huwezi kuhujumu itifaki ya uzalishaji kwa kutoshiriki katika itifaki au kwa kupakia mtandao kupita ujumbe wa mashambulizi.
4. Yote yaliyo hapo juu lazima yawe sugu kwa ulaghai wa idadi inayoruhusiwa ya washiriki wa itifaki wasio waaminifu (kwa mfano, 1/3 ya washiriki).

Katika kesi hii, hitaji la 1 pekee ndilo linalotimizwa, na hitaji la 2 halijafikiwa. Kwa kuharakisha maadili yasiyotabirika kutoka kwa kizuizi, tutapata usambazaji sawa na bahati nasibu nzuri. Lakini BP angalau ina chaguo la "kuchapisha kizuizi au la." Kwa hivyo, BP inaweza angalau kuchagua kutoka kwa chaguzi MBILI za nasibu: "yake" na moja ambayo itatokea ikiwa mtu mwingine atafanya kizuizi. BP inaweza "kuchunguza" mapema nini kitatokea ikiwa atachapisha kizuizi, na anaamua tu kufanya hivyo au la. Kwa hiyo, wakati wa kucheza, kwa mfano, "hata-isiyo ya kawaida" au "nyekundu / nyeusi" katika roulette, anaweza kuchapisha kuzuia tu ikiwa anaona kushinda. Hii pia hufanya mkakati wa kutumia, kwa mfano, heshi ya kuzuia "kutoka siku zijazo" kutofanya kazi. Katika kesi hii, wanasema kwamba "random itatumika, ambayo hupatikana kwa hashing data ya sasa na hash ya block ya baadaye na urefu wa, kwa mfano, N + 42, ambapo N ni urefu wa sasa wa kuzuia. Hii inaimarisha mpango kidogo, lakini bado inaruhusu BP, ingawa katika siku zijazo, kuchagua ikiwa itashikilia kizuizi au kuchapisha.

Programu ya BP katika kesi hii inakuwa ngumu zaidi, lakini sio sana. Kwa urahisi, wakati wa kuhalalisha na kujumuisha shughuli kwenye kizuizi, kuna ukaguzi wa haraka ili kuona ikiwa kutakuwa na ushindi, na, ikiwezekana, uteuzi wa vigezo vya shughuli moja ili kupata uwezekano mkubwa wa kushinda. Wakati huo huo, karibu haiwezekani kupata BP smart kwa udanganyifu kama huo; kila wakati unaweza kutumia anwani mpya na kushinda hatua kwa hatua bila kuibua tuhuma.

Kwa hivyo njia za kutumia habari kutoka kwa kizuizi hazifai kama utekelezaji wa jumla wa PVRB. Katika toleo dogo, lenye vikwazo vya ukubwa wa dau, vikwazo kwa idadi ya wachezaji na/au usajili wa KYC (ili kuzuia mchezaji mmoja kutumia anwani nyingi), mipango hii inaweza kufanya kazi kwa michezo midogo, lakini hakuna zaidi.

PVRB na kujitolea-fichua.

Sawa, shukrani kwa hashing na angalau kutotabirika kwa jamaa kwa heshi ya kuzuia na vigeu vingine vingine. Ikiwa unatatua tatizo la wachimbaji wa mbele, unapaswa kupata kitu kinachofaa zaidi. Wacha tuongeze watumiaji kwenye mpango huu - waache pia waathiri ubahatishaji: mfanyakazi yeyote wa usaidizi wa kiufundi atakuambia kuwa jambo la nasibu zaidi katika mifumo ya TEHAMA ni vitendo vya watumiaji :)

Mpango wa kutojua, wakati watumiaji hutuma nambari za nasibu na matokeo huhesabiwa kama, kwa mfano, heshi ya jumla yao, haifai. Katika kesi hii, mchezaji wa mwisho anaweza, kwa kuchagua random yake mwenyewe, kudhibiti nini matokeo yatakuwa. Hii ndiyo sababu muundo unaotumika sana wa kudhihirisha ahadi hutumiwa. Washiriki kwanza hutuma heshi kutoka kwa nasibu zao (kujitolea), na kisha kufungua nasibu wenyewe (inafunua). Awamu ya "fichua" huanza tu baada ya ahadi zinazohitajika kukusanywa, kwa hivyo washiriki wanaweza kutuma haswa heshi nasibu ambayo walituma mapema. Sasa wacha tuweke haya yote pamoja na vigezo vya kizuizi, na bora kuliko ile iliyochukuliwa kutoka siku zijazo (nasibu inaweza kupatikana tu katika moja ya vizuizi vya siku zijazo), na voila - bahati nasibu iko tayari! Sasa mchezaji yeyote huathiri bahati nasibu inayotokea, na anaweza "kushinda" BP hasidi kwa kuibatilisha na yake mwenyewe, isiyojulikana mapema, bahati nasibu... Unaweza pia kuongeza ulinzi dhidi ya kuhujumu itifaki kwa kutoifungua katika hatua ya udhihirisho - kwa urahisi. kwa kuhitaji kiasi fulani cha kuunganishwa kwenye shughuli wakati wa kufanya - amana ya usalama, ambayo itarejeshwa tu wakati wa utaratibu wa kufichua. Katika kesi hii, kujitolea na kutofunua hakutakuwa na faida.

Ilikuwa ni jaribio zuri, na mipango kama hiyo pia ipo katika DApps za michezo ya kubahatisha, lakini ole, hii haitoshi tena. Sasa sio tu mchimbaji, lakini pia mshiriki yeyote katika itifaki anaweza kushawishi matokeo. Bado inawezekana kudhibiti thamani yenyewe, kwa kutofautiana kidogo na kwa gharama, lakini, kama ilivyo kwa mchimbaji, ikiwa matokeo ya kuchora ni ya thamani zaidi kuliko ada ya kushiriki katika itifaki ya PVRB, basi bila mpangilio. -producer(RP) anaweza kuamua kufichua na bado anaweza kuchagua kutoka angalau chaguo mbili nasibu.
Lakini ikawa inawezekana kuwaadhibu wale wanaofanya na hawafichui, na mpango huu utakuja kwa manufaa. Unyenyekevu wake ni faida kubwa - itifaki kubwa zaidi zinahitaji mahesabu yenye nguvu zaidi.

PVRB na saini za kuamua.

Kuna njia nyingine ya kulazimisha RP kutoa nambari isiyo ya kawaida ambayo haiwezi kuathiri ikiwa imetolewa na "picha" - hii ni saini ya kuamua. Sahihi kama hiyo ni, kwa mfano, RSA, na sio ECS. Ikiwa RP ina jozi ya funguo: RSA na ECC, na anasaini thamani fulani na ufunguo wake wa kibinafsi, basi katika kesi ya RSA atapata saini MOJA NA MOJA TU, na katika kesi ya ECS anaweza kuzalisha idadi yoyote ya saini tofauti halali. Hii ni kwa sababu wakati wa kuunda saini ya ECS, nambari ya nasibu hutumiwa, iliyochaguliwa na saini, na inaweza kuchaguliwa kwa njia yoyote, kumpa saini fursa ya kuchagua moja ya saini kadhaa. Katika kesi ya RSA: "thamani moja ya pembejeo" + "jozi moja ya ufunguo" = "saini moja". Haiwezekani kutabiri saini nyingine itapata RP, kwa hivyo PVRB iliyo na saini za kuamua inaweza kupangwa kwa kuchanganya sahihi za RSA za washiriki kadhaa ambao walitia saini thamani sawa. Kwa mfano, nasibu iliyopita. Mpango huu unaokoa rasilimali nyingi, kwa sababu saini zote ni uthibitisho wa tabia sahihi kulingana na itifaki na chanzo cha bahati nasibu.

Walakini, hata kwa saini za kuamua, mpango bado uko katika hatari ya shida ya "mwigizaji wa mwisho". Mshiriki wa mwisho bado anaweza kuamua kuchapisha saini au la, na hivyo kudhibiti matokeo. Unaweza kurekebisha mpango huo, kuongeza kasi ya kuzuia kwake, kufanya raundi ili matokeo yasiweze kutabiriwa mapema, lakini mbinu hizi zote, hata kwa kuzingatia marekebisho mengi, bado huacha kusuluhishwa kwa shida ya ushawishi wa mshiriki mmoja kwenye pamoja. kusababisha mazingira yasiyoaminika na inaweza tu kufanya kazi chini ya vikwazo vya kiuchumi na wakati. Kwa kuongezea, saizi ya funguo za RSA (1024 na 2048 bits) ni kubwa kabisa, na saizi ya shughuli za blockchain ni paramu muhimu sana. Inaonekana hakuna njia rahisi ya kutatua tatizo, hebu tuendelee.

PVRB na mipango ya kugawana siri

Katika cryptography, kuna mipango ambayo inaweza kuruhusu mtandao kukubaliana juu ya thamani moja na moja tu ya PVRB, wakati mipango kama hiyo ni sugu kwa vitendo vyovyote vibaya vya baadhi ya washiriki. Itifaki moja muhimu ambayo inafaa kujijulisha nayo ni mpango wa kushiriki kwa siri wa Shamir. Inatumika kugawanya siri (kwa mfano, ufunguo wa siri) katika sehemu kadhaa, na kusambaza sehemu hizi kwa washiriki wa N. Siri hiyo inasambazwa kwa njia ambayo sehemu za M kati ya N zinatosha kuirejesha, na hizi zinaweza kuwa sehemu yoyote ya M. Ikiwa kwenye vidole, basi kuwa na grafu ya kazi isiyojulikana, washiriki wanabadilishana pointi kwenye grafu, na baada ya kupokea pointi za M, kazi nzima inaweza kurejeshwa.
Ufafanuzi mzuri unatolewa wiki lakini kucheza nayo kivitendo ili kucheza itifaki katika kichwa chako ni muhimu kwa onyesho ukurasa.

Ikiwa mpango wa FSSS (Fiat-Shamir Secret Sharing) ungetumika kwa fomu yake safi, itakuwa PVRB isiyoweza kuharibika. Kwa fomu yake rahisi, itifaki inaweza kuonekana kama hii:

• Kila mshiriki huzalisha nasibu yake na kusambaza hisa kutoka kwayo kwa washiriki wengine
• Kila mshiriki anaonyesha sehemu yake ya siri za washiriki wengine
• Ikiwa mshiriki ana hisa zaidi ya M, basi nambari ya mshiriki huyu inaweza kuhesabiwa, na itakuwa ya kipekee, bila kujali seti ya washiriki waliofichuliwa.
• Mchanganyiko wa nasibu zilizofunuliwa ni PVRB inayotakiwa

Hapa, mshiriki binafsi haathiri tena matokeo ya itifaki, isipokuwa katika hali ambapo mafanikio ya kizingiti cha ufichuzi wa randomness inategemea yeye tu. Kwa hiyo, itifaki hii, ikiwa kuna uwiano unaohitajika wa RPs wanaofanya kazi kwenye itifaki na inapatikana, hufanya kazi, kutekeleza mahitaji ya nguvu ya cryptographic, na kuwa na upinzani kwa tatizo la "mwigizaji wa mwisho".

Hii inaweza kuwa chaguo bora, mpango huu wa PVRB kulingana na ushiriki wa siri wa Fiat-Shamir umeelezewa kwa mfano katika hii makala. Lakini, kama ilivyoelezwa hapo juu, ikiwa utajaribu kuitumia kwenye blockchain, mapungufu ya kiufundi yanaonekana. Hapa kuna mfano wa utekelezaji wa jaribio la itifaki katika mkataba mahiri wa EOS na sehemu yake muhimu zaidi - kuangalia mshiriki aliyechapishwa: code. Unaweza kuona kutoka kwa msimbo kwamba uthibitisho wa uthibitisho unahitaji kuzidisha mara kadhaa, na nambari zinazotumiwa ni kubwa sana. Inapaswa kueleweka kuwa katika blockchains, uthibitisho hufanyika wakati mtayarishaji wa block anashughulikia shughuli hiyo, na kwa ujumla, mshiriki yeyote lazima athibitishe kwa urahisi usahihi wa itifaki, kwa hivyo mahitaji ya kasi ya kazi ya uthibitishaji ni mbaya sana. . Katika chaguo hili, chaguo liligeuka kuwa lisilofaa, kwani uthibitishaji haukufaa ndani ya kikomo cha shughuli (sekunde 0.5).

Ufanisi wa uthibitishaji ni mojawapo ya mahitaji muhimu zaidi kwa matumizi ya, kwa ujumla, mipango yoyote ya juu ya cryptographic katika blockchain. Kuunda uthibitisho, kuandaa ujumbe - taratibu hizi zinaweza kuondolewa kwenye mnyororo na kufanywa kwenye kompyuta zenye utendaji wa juu, lakini uthibitishaji hauwezi kupuuzwa - hili ni hitaji lingine muhimu kwa PVRB.

PVRB na saini za kizingiti

Baada ya kufahamiana na mpango wa kushiriki kwa siri, tuligundua darasa zima la itifaki zilizounganishwa na neno kuu "kizingiti". Wakati ufichuaji wa baadhi ya taarifa unahitaji ushiriki wa M washiriki waaminifu kati ya N, na seti ya washiriki waaminifu inaweza kuwa kitengo kidogo cha N, tunazungumza juu ya mipango ya "kizingiti". Ndio wanaoturuhusu kushughulika na shida ya "mwigizaji wa mwisho", sasa ikiwa mshambuliaji haonyeshi sehemu yake ya siri, mshiriki mwingine, mwaminifu atamfanyia. Mipango hii inaruhusu makubaliano juu ya maana moja na moja tu, hata kama itifaki inahujumiwa na baadhi ya washiriki.

Mchanganyiko wa saini za kuamua na mipango ya kizingiti ilifanya iwezekanavyo kuendeleza mpango rahisi sana na wa kuahidi wa kutekeleza PVRB - hizi ni saini za kizingiti cha kuamua. Hapa makala kuhusu matumizi mbalimbali ya saini za kizingiti, na hapa kuna nyingine nzuri muda mrefu kutoka Dash.

Nakala ya mwisho inaelezea saini za BLS (BLS inasimamia Boneh-Lynn-Shacham, tazama makala), ambayo ina ubora muhimu sana na rahisi sana kwa waandaaji wa programu - funguo za umma, za siri, za umma na saini za BLS zinaweza kuunganishwa kwa kila mmoja kwa kutumia shughuli rahisi za hisabati, wakati mchanganyiko wao unabaki funguo halali na saini, hukuruhusu kukusanya kwa urahisi nyingi. saini kwenye funguo moja na nyingi za umma kuwa moja. Pia ni za kuamua na hutoa matokeo sawa kwa data sawa ya uingizaji. Kwa sababu ya ubora huu, michanganyiko ya saini za BLS zenyewe ni funguo halali, ambayo inaruhusu utekelezaji wa chaguo ambalo washiriki wa M kati ya N watatoa saini moja tu ambayo ni ya kubainisha, kuthibitishwa kwa umma, na isiyotabirika hadi itakapofunguliwa na Mth. mshiriki.

Katika mpango ulio na saini za kiwango cha juu cha BLS, kila mshiriki hutia saini kitu kwa kutumia BLS (kwa mfano, nasibu iliyotangulia), na sahihi ya kiwango cha kawaida ni bahati nasibu inayotakikana. Sifa za kriptografia za saini za BLS zinakidhi mahitaji ya ubora wa nasibu, sehemu ya kizingiti inalinda dhidi ya "mwigizaji wa mwisho", na mchanganyiko wa kipekee wa funguo hufanya iwezekane kutekeleza algorithms nyingi za kupendeza ambazo huruhusu, kwa mfano, ujumuishaji mzuri wa ujumbe wa itifaki. .

Kwa hivyo, ikiwa unaunda PVRB kwenye blockchain yako, kuna uwezekano mkubwa ukaishia na mpango wa sahihi wa kiwango cha juu cha BLS, miradi kadhaa tayari inautumia. Kwa mfano, DFinity (hapa alama inayotekelezea mzunguko, na hapa mfano utekelezaji wa kushiriki kwa siri kunakoweza kuthibitishwa), au Keep.network (hii hapa ni kiashiria chao cha nasibu karatasi ya njanona hapa mfano mkataba mzuri unaohudumia itifaki).

Utekelezaji wa PVRB

Kwa bahati mbaya, bado hatuoni itifaki iliyo tayari kutekelezwa katika blockchains ya PVRB ambayo imethibitisha usalama na uthabiti wake. Ingawa itifaki zenyewe ziko tayari, kuzitumia kitaalam kwa suluhu zilizopo si rahisi. Kwa mifumo ya kati, PVRB haileti maana, na iliyogatuliwa ina mipaka madhubuti katika rasilimali zote za kompyuta: CPU, kumbukumbu, hifadhi, I/O. Kubuni PVRB ni mchanganyiko wa itifaki mbalimbali ili kuunda kitu ambacho kinakidhi mahitaji yote kwa angalau blockchain fulani inayoweza kutumika. Itifaki moja huhesabu kwa ufanisi zaidi, lakini inahitaji ujumbe zaidi kati ya RPs, wakati nyingine inahitaji ujumbe chache sana, lakini kuunda uthibitisho inaweza kuwa kazi inayochukua makumi ya dakika, au hata saa.

Nitaorodhesha mambo ambayo utalazimika kuzingatia wakati wa kuchagua PVRB ya ubora:

• Nguvu ya kriptografia. PVRB yako lazima isiwe na upendeleo wowote, bila uwezo wa kudhibiti hata kidogo. Katika miradi mingine hii sivyo, kwa hivyo piga kriptografia
• Tatizo la "mwigizaji wa mwisho".. PVRB yako lazima iwe sugu kwa mashambulizi ambapo mshambulizi anayedhibiti RP moja au zaidi anaweza kuchagua moja ya matokeo mawili.
• Tatizo la uhujumu wa itifaki. PVRB yako lazima iwe sugu kwa mashambulizi ambapo mshambulizi anayedhibiti RPs moja au zaidi ataamua iwe bila mpangilio au la na anaweza kuhakikishiwa au kwa uwezekano fulani wa kuathiri hili.
• Idadi ya tatizo la ujumbe. RPs zako zinapaswa kutuma kiwango cha chini cha ujumbe kwa blockchain na kuepuka vitendo vya kusawazisha iwezekanavyo kama vile hali kama vile "Nilituma taarifa fulani, nasubiri jibu kutoka kwa mshiriki mahususi." Katika mitandao ya p2p, haswa iliyotawanywa kijiografia, haupaswi kutegemea majibu ya haraka
• Tatizo la utata wa hesabu. Uthibitishaji wa hatua yoyote ya PVRB kwenye mnyororo unapaswa kuwa rahisi sana, kwa kuwa unafanywa na wateja wote kamili wa mtandao. Ikiwa utekelezaji unafanywa kwa kutumia mkataba wa smart, basi mahitaji ya kasi ni kali sana
• Tatizo la upatikanaji na uhai. PVRB yako inapaswa kujitahidi kustahimili hali ambapo sehemu ya mtandao haipatikani kwa muda na sehemu ya RP inaacha kufanya kazi.
• Tatizo la usanidi unaoaminika na usambazaji wa ufunguo wa awali. Ikiwa PVRB yako itatumia usanidi msingi wa itifaki, basi hii ni hadithi tofauti kubwa na mbaya. Hapa mfano. Ikiwa washiriki lazima waambizane funguo zao kabla ya kuanza itifaki, hili pia ni tatizo ikiwa muundo wa washiriki utabadilika.
• Matatizo ya maendeleo. Upatikanaji wa maktaba katika lugha zinazohitajika, usalama na utendaji wao, utangazaji, majaribio changamano, n.k.

Kwa mfano, saini za kizingiti cha BLS zina shida kubwa - kabla ya kuanza kufanya kazi, washiriki lazima wasambaze funguo kwa kila mmoja, wakipanga kikundi ambacho kizingiti kitafanya kazi. Hii ina maana kwamba angalau mzunguko mmoja wa kubadilishana katika mtandao wa madaraka itabidi kusubiri, na kutokana na kwamba rand inayozalishwa, kwa mfano, ni muhimu katika michezo, karibu katika muda halisi, hii ina maana kwamba hujuma ya itifaki inawezekana katika hatua hii. , na faida za mpango wa kizingiti hupotea. Tatizo hili tayari ni rahisi zaidi kuliko zile zilizopita, lakini bado inahitaji maendeleo ya utaratibu tofauti wa kuunda vikundi vya kizingiti, ambavyo vitapaswa kulindwa kiuchumi, kupitia amana na uondoaji wa fedha (kufyeka) kutoka kwa washiriki ambao hawafuati itifaki. Pia, uthibitishaji wa BLS na kiwango kinachokubalika cha usalama hauingii, kwa mfano, katika shughuli ya kawaida ya EOS au Ethereum - hakuna wakati wa kutosha wa uthibitishaji. Msimbo wa mkataba ni WebAssembly au EVM, unaotekelezwa na mashine pepe. Vitendaji vya kriptografia havitekelezwi kienyeji (bado), na hufanya kazi makumi ya mara polepole kuliko maktaba za kriptografia za kawaida. Itifaki nyingi hazikidhi mahitaji kulingana na kiasi muhimu, kwa mfano 1024 na 2048 bits kwa RSA, mara 4-8 kubwa kuliko saini ya kawaida ya shughuli katika Bitcoin na Ethereum.

Uwepo wa utekelezaji katika lugha tofauti za programu pia una jukumu - ambalo ni chache, haswa kwa itifaki mpya. Chaguo na ujumuishaji katika makubaliano inahitaji kuandika itifaki katika lugha ya jukwaa, kwa hivyo itabidi utafute msimbo katika Go for geth, katika Rust for Parity, katika C++ kwa EOS. Kila mtu atalazimika kutafuta msimbo wa JavaScript, na kwa kuwa JavaScript na cryptography sio marafiki wa karibu sana, WebAssembly itasaidia, ambayo sasa inadai kuwa kiwango muhimu kinachofuata cha Mtandao.

Hitimisho

Natumaini katika uliopita Ibara ya Niliweza kukushawishi kuwa kutoa nambari za nasibu kwenye blockchain ni muhimu kwa nyanja nyingi za maisha ya mitandao iliyopitishwa, na kwa nakala hii nilionyesha kuwa kazi hii ni ya kutamani sana na ngumu, lakini suluhisho nzuri tayari zipo. Kwa ujumla, muundo wa mwisho wa itifaki unawezekana tu baada ya kufanya majaribio makubwa ambayo yanazingatia nyanja zote kutoka kwa usanidi hadi uigaji wa makosa, kwa hivyo hakuna uwezekano wa kupata mapishi yaliyotengenezwa tayari katika karatasi nyeupe na vifungu vya timu, na hakika hatutaweza. amua katika mwaka mmoja au miwili ijayo andika "fanya hivi, sawa kabisa."

Kwaheri, kwa PVRB yetu katika blockchain inayoendelezwa Haya, tulitulia kwa kutumia saini za BLS za kiwango cha juu, tunapanga kutekeleza PVRB katika kiwango cha makubaliano, kwa kuwa uthibitishaji katika mikataba mahiri yenye kiwango cha usalama kinachokubalika bado haujawezekana. Inawezekana kwamba tunatumia mipango miwili kwa wakati mmoja: kwanza, kushiriki kwa siri kwa gharama kubwa ili kuunda random_seed ya muda mrefu, na kisha tunaitumia kama msingi wa uzalishaji nasibu wa masafa ya juu kwa kutumia saini za kizingiti cha kuamua za BLS, labda tutajiwekea kikomo pekee. moja ya skimu. Kwa bahati mbaya, haiwezekani kusema mapema itifaki itakuwa nini; jambo zuri tu ni kwamba, kama katika sayansi, katika shida za uhandisi, matokeo mabaya pia ni matokeo, na kila jaribio jipya la kutatua shida ni hatua nyingine kwa utafiti wa kila mtu aliyehusika katika tatizo hilo. Ili kukidhi mahitaji ya biashara, tunatatua tatizo maalum la vitendo - kutoa maombi ya michezo ya kubahatisha na chanzo cha kuaminika cha entropy, kwa hiyo tunapaswa pia kuzingatia blockchain yenyewe, hasa masuala ya mwisho wa mnyororo na utawala wa mtandao.

Na ingawa bado hatuoni PVRB sugu iliyothibitishwa katika blockchains, ambayo ingetumika kwa muda wa kutosha kujaribiwa na programu halisi, ukaguzi mwingi, mizigo, na kwa kweli, mashambulio ya kweli, lakini idadi ya njia zinazowezekana zinathibitisha hilo. suluhisho lipo, na ni nini -ya algorithms haya hatimaye itasuluhisha shida. Tutafurahi kushiriki matokeo na kuzishukuru timu zingine ambazo pia zinashughulikia suala hili kwa makala na msimbo unaoruhusu wahandisi kutokanyaga reki moja mara mbili.

Kwa hivyo, unapokutana na mpangaji programu anayebuni bila mpangilio maalum, kuwa mwangalifu na kujali, na utoe msaada wa kisaikolojia ikiwa ni lazima :)

Chanzo: mapenzi.com