Кіріспе

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

Криптографияның абсолютті күшті шифры концепциясы сияқты, нақты «Қоғамдық тексерілетін кездейсоқ маяк» (бұдан әрі PVRB) хаттамалары тек идеалды схемаға мүмкіндігінше жақындауға тырысады, өйткені нақты желілерде оның таза түрінде қолданылмайды: бір бит бойынша қатаң келісу керек, көптеген раундтар болуы керек және барлық хабарламалар өте жылдам және әрқашан жеткізілуі керек. Әрине, бұл нақты желілерде болмайды. Сондықтан, заманауи блокчейндерде нақты тапсырмалар үшін PVRB құрастыру кезінде пайда болатын кездейсоқтық пен криптографиялық күшті бақылау мүмкін еместігінен басқа, көптеген таза архитектуралық және техникалық мәселелер туындайды.

PVRB үшін блокчейннің өзі негізінен хабарламалар = транзакциялар болатын байланыс құралы болып табылады. Бұл желілік мәселелерден, хабарламаларды жеткізбеуден, аралық бағдарламалық қамтамасыз ету проблемаларынан ішінара абстракциялауға мүмкіндік береді - бұл тәуекелдердің барлығын орталықтандырылмаған желі өз мойнына алады және оның PVRB үшін негізгі мәні жіберілген транзакцияны қайтарып алу немесе бұзу мүмкін еместігі болып табылады - бұл егер олар консенсусқа сәтті шабуыл жасамаса, қатысушылардың хаттамаға қатысудан бас тартуына жол бермеу. Қауіпсіздіктің бұл деңгейі қолайлы, сондықтан PVRB негізгі блокчейн тізбегі сияқты қатысушылардың сөз байласуына төзімді болуы керек. Сондай-ақ, бұл желі негізгі блокчейнге келісетін болса, PVRB консенсустың бір бөлігі болуы керек дегенді білдіреді, тіпті егер ол кездейсоқ нәтиже беретін жалғыз әділетті болса да. Немесе PVRB - бұл блокчейн мен блоктарға қатысты асинхронды түрде жұмыс істейтін смарт келісім-шарт арқылы жүзеге асырылатын жеке хаттама. Екі әдістің де артықшылықтары мен кемшіліктері бар және олардың арасындағы таңдау өте маңызды емес.

PVRB енгізудің екі жолы

PVRB енгізудің екі нұсқасын толығырақ сипаттап көрейік - блокчейнге тәуелсіз смарт келісім-шарт арқылы жұмыс істейтін автономды нұсқа және хаттамаға енгізілген консенсуспен біріктірілген нұсқа, оған сәйкес желі блокчейн мен қосылуы тиіс транзакциялар. Барлық жағдайларда мен танымал блокчейн қозғалтқыштарын айтамын: Ethereum, EOS және смарт келісімшарттарды қабылдау және өңдеу тәсілі бойынша оларға ұқсастардың барлығы.

Дербес келісім-шарт

Бұл нұсқада PVRB кездейсоқ өндірушілердің транзакцияларын (бұдан әрі - RP) қабылдайтын, оларды өңдейтін, нәтижелерді біріктіретін және нәтижесінде кез келген пайдаланушы осы келісімшарттан ала алатын белгілі бір мәнге келетін смарт келісімшарт болып табылады. Бұл мән келісім-шартта тікелей сақталмауы мүмкін, керісінше нәтижелі кездейсоқ мәннің бір және бір ғана мәнін детерминирленген түрде алуға болатын деректермен ғана ұсынылуы мүмкін. Бұл схемада РП блокчейннің пайдаланушылары болып табылады және кез келген адамға генерациялау процесіне қатысуға рұқсат етілуі мүмкін.

Дербес келісім-шартпен опция жақсы:

• портативтілік (келісімшарттарды блокчейннен блокчейнге апаруға болады)
• енгізу және тестілеудің қарапайымдылығы (келісімшарттарды жазу және тексеру оңай)
• экономикалық схемаларды жүзеге асырудың ыңғайлылығы (логикасы PVRB мақсаттарына қызмет ететін өз таңбалауышыңызды жасау оңай)
• жұмыс істеп тұрған блокчейндерде іске қосу мүмкіндігі

Оның да кемшіліктері бар:

• есептеу ресурстарына, транзакция көлеміне және сақтауға қатты шектеулер (басқаша айтқанда, cpu/mem/io)
• келісім-шарттағы операцияларға шектеулер (барлық нұсқаулар жоқ, сыртқы кітапханаларды қосу қиын)
• блокчейнге енгізілген транзакцияларға қарағанда хабар алмасуды жылдам ұйымдастыру мүмкін еместігі

Бұл опция бар желіде іске қосылуы қажет, күрделі криптографияны қамтымайтын және өзара әрекеттесулердің үлкен санын қажет етпейтін PVRB іске асыру үшін қолайлы.

Консенсуспен біріктірілген

Бұл нұсқада PVRB блокчейн түйін кодында енгізілген немесе блокчейн түйіндері арасында хабарлама алмасумен қатар жұмыс істейді. Протоколдың нәтижелері тікелей өндірілген блоктарға жазылады, ал протоколдық хабарламалар түйіндер арасында p2p желісі арқылы жіберіледі. Хаттама нәтижесінде блоктармен жазылатын сандар пайда болғандықтан, желі олар бойынша консенсусқа жетуі керек. Бұл транзакциялар сияқты PVRB хабарлары түйіндер арқылы тексеріліп, блоктарға қосылуы керек дегенді білдіреді, осылайша кез келген желі қатысушысы PVRB протоколына сәйкестікті тексере алады. Бұл бізді автоматты түрде айқын шешімге әкеледі - егер желі блок және ондағы транзакциялар туралы консенсусқа келіссе, онда PVRB жеке хаттама емес, консенсустың бөлігі болуы керек. Әйтпесе, консенсус тұрғысынан блок жарамды болуы мүмкін, бірақ PVRB хаттамасы сақталмайды, ал PVRB көзқарасы бойынша блокты қабылдау мүмкін емес. Сондықтан, егер «консенсуспен біріктірілген» опция таңдалса, PVRB консенсустың маңызды бөлігіне айналады.

PVRB іске асыруды желілік консенсус деңгейінде сипаттаған кезде, түпкілікті мәселелерден аулақ бола алмайсыз. Түпкіліктілік - блокты (және оған апаратын тізбекті) бекітетін детерминирленген консенсустарда қолданылатын механизм, ол түпкілікті болып табылады және тіпті параллель шанышқы пайда болса да, ешқашан тасталмайды. Мысалы, Bitcoin-де мұндай механизм жоқ - егер сіз күрделірек тізбегін жарияласаңыз, ол тізбектердің ұзындығына қарамастан кез келген аз күрделісін ауыстырады. Ал EOS-та, мысалы, соңғылары - бұл соңғы қайтымсыз блоктар, олар орташа есеппен әрбір 432 блокта пайда болады (12*21 + 12*15, алдын ала дауыс беру + алдын ала міндеттеу). Бұл процесс негізінен блок-продюсерлердің (бұдан әрі - BP) 2/3 қол қоюын күтеді. Соңғы LIB-ден ескі шанышқылар пайда болғанда, олар жай ғана жойылады. Бұл механизм транзакцияның блокчейнге енгізілгеніне және шабуылдаушы қандай ресурстарға ие болса да, ешқашан кері қайтарылмайтынына кепілдік беруге мүмкіндік береді. Сондай-ақ, соңғы блоктар Hyperledger, Tendermint және басқа pBFT негізіндегі консенсустарда 2/3 BP қол қойған блоктар болып табылады. Сондай-ақ, консенсусқа қосымша болып түпкілікті қамтамасыз ету үшін хаттама жасау мағынасы бар, өйткені ол блоктарды шығарумен және жариялаумен асинхронды түрде жұмыс істей алады. Міне, жақсысы мақала Ethereum-дағы түпкілікті туралы.

Түпкіліктілік пайдаланушылар үшін өте маңызды, олар онсыз өздерін BP блоктарды «ұстап», жақсы транзакцияны «көргеннен» кейін жариялайтын «қос шығын» шабуылының құрбанына айналдыруы мүмкін. Егер түпкілікті шешім болмаса, онда жарияланған шанышқы блокты «жақсы» транзакциямен басқасымен, «жаман» шанышқымен ауыстырады, онда сол қаражат шабуылдаушы мекенжайына аударылады. PVRB жағдайында түпкіліктілікке қойылатын талаптар одан да қатаң, өйткені PVRB үшін шанышқыларды құру шабуылдаушыға ең тиімдісін жариялау үшін бірнеше кездейсоқ нұсқаларды дайындау мүмкіндігін білдіреді, ал ықтимал шабуыл уақытын шектеу. жақсы шешім.

Сондықтан, ең жақсы нұсқа PVRB және түпкілікті бір хаттамаға біріктіру болып табылады - содан кейін аяқталған блок = қорытындыланған кездейсоқ, және дәл осы бізге қажет болды. Енді ойыншылар N секунд ішінде кепілдендірілген кездейсоқ мүмкіндік алады және оны кері айналдыру немесе қайта ойнату мүмкін емес екеніне сенімді болады.

Консенсуспен біріктірілген опция жақсы:

• блоктарды өндіруге қатысты асинхронды іске асыру мүмкіндігі - блоктар әдеттегідей шығарылады, бірақ онымен қатар PVRB протоколы жұмыс істей алады, бұл әрбір блок үшін кездейсоқтықты тудырмайды.
• ақылды келісімшарттарға қойылған шектеулерсіз тіпті ауыр криптографияны жүзеге асыру мүмкіндігі
• транзакцияларға қарағанда хабарлама алмасуды тезірек ұйымдастыру мүмкіндігі блокчейнге енгізілген, мысалы, хаттаманың бір бөлігі желі арқылы хабарламаларды таратпай түйіндер арасында жұмыс істей алады.

Оның да кемшіліктері бар:

• Тестілеу мен әзірлеудегі қиындықтар - желілік қателерді, жетіспейтін түйіндерді, желілік қатты шанышқыларды эмуляциялауға тура келеді.
• Іске асыру қателері желілік қатты форкты қажет етеді

PVRB енгізудің екі әдісі де өмір сүруге құқылы, бірақ заманауи блокчейндерде смарт келісімшарттар бойынша іске асыру есептеу ресурстарында әлі де шектеулі, ал күрделі криптографияға кез келген көшу жиі мүмкін емес. Бізге төменде көрсетілгендей күрделі криптография қажет болады. Бұл мәселе анық уақытша болса да, көптеген мәселелерді шешу үшін келісімшарттардағы күрделі криптография қажет және ол бірте-бірте пайда болады (мысалы, Ethereum-дағы zkSNARKs жүйелік келісімшарттары)

Мөлдір және сенімді хаттамалық хабар алмасу арнасын қамтамасыз ететін блокчейн мұны тегін жасамайды. Кез келген орталықтандырылмаған хаттама Sybil шабуылының мүмкіндігін ескеруі керек; кез келген әрекетті бірнеше тіркелгілердің келісілген күштері жасай алады, сондықтан жобалау кезінде шабуылдаушылардың хаттаманың ерікті санын құру мүмкіндігін ескеру қажет. сөз байласу арқылы әрекет ететін қатысушылар.

PVRB және блок айнымалылары.

Мен блокчейндерде көптеген құмар ойындарға арналған қосымшалармен сыналған жақсы PVRB-ны әлі ешкім енгізген жоқ деп айтсам өтірік айтқан жоқпын. Ethereum мен EOS-те құмар ойындарға арналған көптеген қосымшалар қайдан келеді? Бұл сізді таң қалдырғаны сияқты мені де таң қалдырады, олар толығымен детерминирленген ортада сонша «тұрақты» кездейсоқтарды қайдан алды?

Блокчейндегі кездейсоқтықты алудың сүйікті тәсілі - блоктан қандай да бір «болжауға болмайтын» ақпаратты алу және оның негізінде кездейсоқ ақпарат жасау - жай ғана бір немесе бірнеше мәндерді хэштеу арқылы. Мұндай схемалардың проблемалары туралы жақсы мақала осында. Блоктағы кез келген «болжау мүмкін емес» мәндерді, мысалы, блок хэшін, транзакциялар санын, желінің күрделілігін және алдын ала белгісіз басқа мәндерді алуға болады. Содан кейін оларды бір немесе бірнеше хэштеңіз және теориялық тұрғыдан нақты кездейсоқ алуыңыз керек. Сіз тіпті қағазға сіздің схемаңыздың «кванттықтан кейінгі қауіпсіз» екенін қосуға болады (себебі кванттық сенімді хэш функциялары бар :)).

Бірақ, өкінішке орай, пост кванттық қауіпсіз хэштер де жеткіліксіз. Құпия PVRB талаптарында жатыр, оларды алдыңғы мақаладан еске сала кетейін:

1. Нәтиже дәлелденетін біркелкі үлестірімге ие болуы керек, яғни дәлелденетін күшті криптографияға негізделген.
2. Нәтиженің кез келген биттерін басқару мүмкін емес. Нәтижесінде нәтижені алдын ала болжау мүмкін емес.
3. Сіз хаттамаға қатыспау немесе желіні шабуыл хабарламаларымен шамадан тыс жүктеу арқылы генерациялау протоколын бұза алмайсыз.
4. Жоғарыда айтылғандардың барлығы хаттамаға адал емес қатысушылардың рұқсат етілген санының сөз байласуына төзімді болуы керек (мысалы, қатысушылардың 1/3 бөлігі).

Бұл жағдайда тек 1-талап орындалады, ал 2-талап орындалмайды.Блоктан болжанбайтын мәндерді хэштеу арқылы біз біркелкі үлестірімді және жақсы кездейсоқ сандарды аламыз. Бірақ BP кем дегенде «блокты жариялау немесе жарияламау» мүмкіндігіне ие. Осылайша, BP кем дегенде ЕКІ кездейсоқ нұсқаның бірін таңдай алады: «өзінің» және блокты басқа біреу жасаса, болатынын. BP блокты жарияласа, не болатынын алдын ала «байқап» алады және оны жасау немесе жасамау туралы шешім қабылдады. Осылайша, мысалы, рулеткада «жұп-тақ» немесе «қызыл/қара» ойнаған кезде, ол жеңісті көрсе ғана блокты жариялай алады. Бұл сондай-ақ, мысалы, «болашақтан» блок хэшін пайдалану стратегиясын жұмыс істемейтін етеді. Бұл жағдайда олар «кездейсоқ пайдаланылады, ол ағымдағы деректерді хэштеу және болашақ блоктың хэшін, мысалы, N + 42 биіктігі бар, мұндағы N - ағымдағы блок биіктігі. Бұл схеманы аздап күшейтеді, бірақ бәрібір BP-ге болашақта болса да блокты ұстау немесе жариялауды таңдауға мүмкіндік береді.

Бұл жағдайда BP бағдарламалық құралы күрделене түседі, бірақ көп емес. Қарапайым ғана, транзакцияны блокқа валидациялау және қосу кезінде ұтыстың бар-жоғын білу үшін жылдам тексеру және, мүмкін, ұтудың жоғары ықтималдығын алу үшін транзакцияның бір параметрін таңдау мүмкіндігі бар. Сонымен қатар, мұндай манипуляциялар үшін ақылды қан қысымын ұстау мүмкін емес, әр жолы сіз жаңа мекенжайларды пайдалана аласыз және күдік тудырмай, бірте-бірте жеңе аласыз.

Сондықтан блоктан ақпаратты пайдаланатын әдістер PVRB әмбебап іске асыру ретінде жарамайды. Шектеулі нұсқада, ставка өлшемдеріне шектеулер, ойыншылар санына шектеулер және/немесе KYC тіркеуі (бір ойыншының бірнеше мекенжайларды пайдалануына жол бермеу үшін) бұл схемалар шағын ойындар үшін жұмыс істей алады, бірақ басқа ештеңе жоқ.

PVRB және растау.

Жарайды, хэштеу және кем дегенде блок хэшінің және басқа айнымалылардың салыстырмалы болжаусыздығы арқасында. Егер сіз алдыңғы қатардағы шахтерлердің мәселесін шешсеңіз, сізге қолайлы нәрсе алу керек. Осы схемаға пайдаланушыларды қосайық - олар да кездейсоқтыққа әсер етсін: кез келген техникалық қолдау қызметкері АТ жүйелеріндегі ең кездейсоқ нәрсе пайдаланушылардың әрекеті екенін айтады :)

Пайдаланушылар жай ғана кездейсоқ сандарды жібергенде және нәтиже, мысалы, олардың сомасының хэші ретінде есептелетін аңғал схема жарамайды. Бұл жағдайда соңғы ойыншы өзінің кездейсоқ таңдауын таңдай отырып, нәтиженің қандай болатынын басқара алады. Сондықтан өте кең қолданылатын commit-reveal үлгісі қолданылады. Қатысушылар алдымен рандомдарынан (міндеттерінен) хэштерді жібереді, содан кейін рандомдарды өздері ашады (көрсетеді). Қатысушылар дәл бұрын жіберген кездейсоқ хэшті жібере алатындай, «ашу» кезеңі қажетті міндеттемелер жиналғаннан кейін ғана басталады. Енді осының барлығын блоктың параметрлерімен біріктіріп көрейік және болашақтан алынғаннан жақсырақ (кездейсоқтық тек болашақ блоктардың бірінде болуы мүмкін) және voila - кездейсоқтық дайын! Енді кез келген ойыншы пайда болатын кездейсоқтыққа әсер етеді және зиянды BP-ны өзінің, алдын ала белгісіз, кездейсоқтығымен жеңіп, оны «жеңуге» болады... Сондай-ақ, протоколды ашу сатысында ашпау арқылы оны диверсиядан қорғауды қосуға болады - жай. мәмілені жасау кезінде белгілі бір соманы қосуды талап ету арқылы — анықтау рәсімі кезінде ғана қайтарылатын кепілдік жарна. Бұл жағдайда жасау және жарияламау тиімсіз болады.

Бұл жақсы әрекет болды және мұндай схемалар DApps ойынында да бар, бірақ өкінішке орай, бұл тағы да жеткіліксіз. Енді тек шахтер ғана емес, сонымен қатар хаттаманың кез келген қатысушысы нәтижеге әсер ете алады. Құнның өзін аз өзгергіштікпен және шығынмен басқаруға әлі де болады, бірақ шахтер жағдайындағыдай, егер ұтыс ойынының нәтижелері PVRB хаттамасына қатысу жарнасынан құндырақ болса, онда кездейсоқ -продюсер(RP) ашуды шеше алады және кем дегенде екі кездейсоқ опциядан таңдай алады.
Бірақ жасаған және ашпағандарды жазалау мүмкін болды және бұл схема пайдалы болады. Оның қарапайымдылығы маңызды артықшылық болып табылады - неғұрлым маңызды хаттамалар әлдеқайда күшті есептеулерді талап етеді.

PVRB және детерминирленген қолтаңбалар.

РП-ны жалған кездейсоқ санды беруге мәжбүрлеудің тағы бір жолы бар, егер ол «алдын ала кескінмен» қамтамасыз етілсе, ол әсер ете алмайды - бұл детерминирленген қолтаңба. Мұндай қолтаңба, мысалы, RSA болып табылады және ECS емес. Егер RP-де жұп кілттер болса: RSA және ECC және ол өзінің жеке кілтімен белгілі бір мәнге қол қойса, онда RSA жағдайында ол БІР ЖӘНЕ БІР қолтаңба алады, ал ECS жағдайында ол кез келген санды генерациялай алады. әртүрлі жарамды қолдар. Себебі, ECS қолтаңбасын жасау кезінде қол қоюшы таңдаған кездейсоқ сан пайдаланылады және ол қол қоюшыға бірнеше қолтаңбаның біреуін таңдау мүмкіндігін беретін кез келген жолмен таңдалуы мүмкін. RSA жағдайында: «бір кіріс мәні» + «бір кілт жұбы» = «бір қолтаңба». Басқа RP қандай қолтаңба алатынын болжау мүмкін емес, сондықтан детерминирленген қолтаңбалары бар PVRB бірдей мәнге қол қойған бірнеше қатысушылардың RSA қолдарын біріктіру арқылы ұйымдастырылуы мүмкін. Мысалы, алдыңғы кездейсоқ. Бұл схема көптеген ресурстарды үнемдейді, өйткені қолтаңбалар хаттамаға сәйкес дұрыс әрекетті растау және кездейсоқтық көзі болып табылады.

Дегенмен, тіпті детерминирленген қолтаңбалармен схема әлі де «соңғы актер» мәселесіне осал. Соңғы қатысушы қолтаңбаны жариялау немесе жарияламау туралы шешім қабылдай алады, осылайша нәтижені бақылайды. Сіз схеманы өзгерте аласыз, оған блок хэштерін қоса аласыз, нәтижені алдын ала болжауға болмайтындай айналдыра аласыз, бірақ бұл әдістердің барлығы, тіпті көптеген модификацияларды ескере отырып, бір қатысушының ұжымға әсер ету мәселесін әлі де шешілмей қалдырады. сенімсіз ортаға әкеледі және тек экономикалық және уақыттық шектеулерде жұмыс істей алады. Сонымен қатар, RSA кілттерінің өлшемі (1024 және 2048 бит) өте үлкен және блокчейн транзакциялары үшін өлшем өте маңызды параметр болып табылады. Мәселені шешудің қарапайым жолы жоқ сияқты, әрі қарай жүрейік.

PVRB және құпия бөлісу схемалары

Криптографияда желіге бір және бір ғана PVRB мәні бойынша келісуге мүмкіндік беретін схемалар бар, ал мұндай схемалар кейбір қатысушылардың кез келген зиянды әрекеттеріне төзімді. Бір пайдалы хаттамамен танысуға тұрарлық - бұл Шамирдің құпия бөлісу схемасы. Ол құпияны (мысалы, құпия кілтті) бірнеше бөлікке бөлуге және бұл бөліктерді N қатысушыға таратуға қызмет етеді. Құпия оны қалпына келтіру үшін N бөлігінің M бөлігі жеткілікті болатындай етіп таратылады және бұл кез келген M бөлік болуы мүмкін. Егер саусақтарда белгісіз функцияның графигі болса, қатысушылар графикте нүктелермен алмасады, ал M ұпайларын алғаннан кейін бүкіл функцияны қалпына келтіруге болады.
Жақсы түсініктеме берілген уики бірақ протоколды сіздің басыңызда ойнау үшін онымен іс жүзінде ойнау пайдалы демо бет.

Егер FSSS (Fiat-Shamir Secret Sharing) схемасы таза түрінде қолданылса, ол бұзылмайтын PVRB болар еді. Ең қарапайым түрде хаттама келесідей болуы мүмкін:

• Әрбір қатысушы өзінің кездейсоқ түрін жасайды және оның үлесін басқа қатысушыларға таратады
• Әрбір қатысушы басқа қатысушылардың құпияларының өз бөлігін ашады
• Қатысушыда M акциядан артық болса, онда бұл қатысушының санын есептеуге болады және ол анықталған қатысушылардың жиынтығына қарамастан бірегей болады.
• Анықталған кездейсоқ шамалардың комбинациясы қалаған PVRB болып табылады

Мұнда жеке қатысушы бұдан былай хаттаманың нәтижелеріне әсер етпейді, кездейсоқтықты ашу шегіне жету тек өзіне байланысты болатын жағдайларды қоспағанда. Сондықтан, бұл хаттама, егер хаттамада жұмыс істейтін РП-ның қажетті үлесі болса және қол жетімді болса, жұмыс істейді, криптографиялық күшке қойылатын талаптарды жүзеге асырады және «соңғы актер» мәселесіне төзімді.

Бұл тамаша нұсқа болуы мүмкін, Fiat-Shamir құпия бөлісуіне негізделген бұл PVRB схемасы, мысалы бұл мақала. Бірақ, жоғарыда айтылғандай, егер сіз оны блокчейнде тікелей қолдануға тырыссаңыз, техникалық шектеулер пайда болады. Мұнда EOS смарт келісімшартындағы хаттаманы сынақтан өткізудің мысалы және оның ең маңызды бөлігі - жарияланған үлес қатысушысын тексеру: код. Кодтан дәлелдеу валидациясы бірнеше скалярлық көбейтуді қажет ететінін және пайдаланылған сандар өте үлкен екенін көруге болады. Блокчейндерде тексеру блок-продюсер транзакцияны өңдейтін сәтте орын алатынын түсіну керек және тұтастай алғанда кез келген қатысушы хаттаманың дұрыстығын оңай тексеруі керек, сондықтан тексеру функциясының жылдамдығына қойылатын талаптар өте маңызды. . Бұл опцияда опция тиімсіз болып шықты, өйткені тексеру транзакция шегіне сәйкес келмеді (0.5 секунд).

Тексеру тиімділігі блокчейндегі кез келген жетілдірілген криптографиялық схемаларды пайдаланудың ең маңызды талаптарының бірі болып табылады. Дәлелдеулерді жасау, хабарламаларды дайындау – бұл процедураларды тізбектен тыс алуға және өнімділігі жоғары компьютерлерде орындауға болады, бірақ тексеруді айналып өтуге болмайды – бұл PVRB үшін тағы бір маңызды талап.

PVRB және шекті қолтаңбалар

Құпия бөлісу схемасымен танысқаннан кейін біз «табалдырық» кілт сөзімен біріктірілген хаттамалардың тұтас класын таптық. Кейбір ақпаратты ашу үшін N-ден M адал қатысушылардың қатысуы қажет болғанда және адал қатысушылардың жиыны N-нің ерікті жиыны болуы мүмкін болса, біз «шекті» схемалар туралы айтамыз. Дәл солар бізге «соңғы актер» мәселесін шешуге мүмкіндік береді, енді шабуылдаушы құпияның бір бөлігін ашпаса, оны басқа, адал қатысушы жасайды. Бұл схемалар хаттамаға қатысушылардың кейбірі тарапынан саботаж жасалса да, бір ғана мағына бойынша келісімге мүмкіндік береді.

Детерминирленген қолтаңбалар мен шекті схемалардың үйлесімі PVRB енгізу үшін өте ыңғайлы және перспективалық схеманы әзірлеуге мүмкіндік берді - бұл детерминирленген шекті қолтаңбалар. Мұнда мақала шекті қолтаңбалардың әртүрлі қолданылуы туралы және міне, тағы бір жақсысы ұзақ оқу Даштан.

Соңғы мақалада BLS қолтаңбалары сипатталған (BLS Боне-Линн-Шачам, қараңыз мақала), бағдарламашылар үшін өте маңызды және өте ыңғайлы сапаға ие - ашық, құпия, ашық кілттер және BLS қолтаңбалары қарапайым математикалық операцияларды қолдана отырып, бір-бірімен біріктірілуі мүмкін, ал олардың комбинациясы жарамды кілттер мен қолтаңбалар болып қалады, бұл көптеген файлдарды оңай біріктіруге мүмкіндік береді. қолтаңбаларды бір, ал көптеген ашық кілттерді біреуге. Олар сондай-ақ детерминирленген және бірдей кіріс деректері үшін бірдей нәтиже береді. Осы сапаның арқасында BLS қолтаңбаларының комбинациясы жарамды кілттер болып табылады, бұл N қатысушысы Mth ашқанға дейін детерминирленген, жалпы тексерілетін және болжауға болмайтын бір және бір ғана қолды жасайтын опцияны жүзеге асыруға мүмкіндік береді. қатысушы .

Шекті BLS қолтаңбалары бар схемада әрбір қатысушы BLS көмегімен бір нәрсеге қол қояды (мысалы, алдыңғы кездейсоқ) және ортақ шекті қолтаңба қалаған кездейсоқ қолтаңба болып табылады. BLS қолтаңбаларының криптографиялық қасиеттері кездейсоқ сапаға қойылатын талаптарды қанағаттандырады, шекті бөлігі «соңғы әрекеттен» қорғайды және кілттердің бірегей біріктіру мүмкіндігі, мысалы, протоколдық хабарламаларды тиімді біріктіруге мүмкіндік беретін көптеген қызықты алгоритмдерді енгізуге мүмкіндік береді. .

Сонымен, егер сіз блокчейніңізде PVRB құрып жатсаңыз, сіз BLS шекті қол қою схемасымен аяқталуыңыз мүмкін, оны бірнеше жобалар пайдаланып жатыр. Мысалы, DFinity (осында схеманы жүзеге асыратын эталон және осында тексерілетін құпия бөлісуді іске асыру мысалы) немесе Keep.network (міне, олардың кездейсоқ шамы сары қағаз, ал міне мысал хаттамаға қызмет көрсететін смарт келісімшарт).

PVRB енгізу

Өкінішке орай, біз PVRB блокчейндерінде енгізілген, оның қауіпсіздігі мен тұрақтылығын дәлелдеген дайын хаттаманы әлі көрмейміз. Хаттамалардың өзі дайын болса да, оларды бар шешімдерге техникалық қолдану оңай емес. Орталықтандырылған жүйелер үшін PVRB мағынасы жоқ, ал орталықтандырылмағандары барлық есептеу ресурстарында қатаң шектелген: процессор, жад, сақтау, енгізу/шығару. PVRB жобалау - кем дегенде кейбір өміршең блокчейнге қойылатын барлық талаптарға жауап беретін нәрсені жасау үшін әртүрлі хаттамалардың тіркесімі. Бір хаттама тиімдірек есептейді, бірақ RP арасында көбірек хабарларды қажет етеді, ал екіншісі өте аз хабарларды қажет етеді, бірақ дәлелдеуді жасау ондаған минуттарды, тіпті сағаттарды қажет ететін тапсырма болуы мүмкін.

Мен сапалы PVRB таңдау кезінде ескеру қажет факторларды тізімдеймін:

• Криптографиялық күш. Сіздің PVRB бір битті басқару мүмкіндігі жоқ, қатаң бейтарап болуы керек. Кейбір схемаларда бұлай емес, сондықтан криптографты шақырыңыз
• «Соңғы актер» мәселесі. PVRB бір немесе бірнеше RP басқаратын шабуылдаушы екі нәтиженің бірін таңдай алатын шабуылдарға төзімді болуы керек.
• Протоколды саботаж мәселесі. Сіздің PVRB шабуылдарға төзімді болуы керек, онда бір немесе бірнеше RP-ні басқаратын шабуылдаушы кездейсоқ немесе жоқ екенін шешеді және оған кепілдік беру немесе оған әсер ету ықтималдығы бар.
• Хабарламалар саны мәселесі. Сіздің RP-теріңіз блокчейнге ең аз хабарлама жіберуі керек және «Мен кейбір ақпаратты жібердім, нақты қатысушыдан жауап күтемін» сияқты жағдайлар сияқты синхронды әрекеттерден мүмкіндігінше аулақ болу керек. P2p желілерінде, әсіресе географиялық тұрғыдан шашыраңқы желілерде, сіз жылдам жауапқа сенбеуіңіз керек
• Есептеу күрделілігі мәселесі. PVRB желісінің кез келген сатысын тексеру өте оңай болуы керек, өйткені оны желінің барлық толық клиенттері орындайды. Егер іске асыру смарт келісімшарт арқылы жасалса, жылдамдық талаптары өте қатаң
• Қолжетімділік пен жандылық мәселесі. Сіздің PVRB желінің бір бөлігі белгілі бір уақыт ішінде қолжетімсіз болатын және RP бөлігі жұмысын тоқтататын жағдайларға төзімді болуға ұмтылуы керек.
• Сенімді орнату және бастапқы кілтті тарату мәселесі. Егер сіздің PVRB протоколдың бастапқы орнатуын пайдаланса, бұл бөлек үлкен және маңызды оқиға. Мұнда мысал. Қатысушылар протоколды бастамас бұрын бір-біріне кілттерін айтуы керек болса, қатысушылардың құрамы өзгерсе, бұл мәселе де болады.
• Даму проблемалары. Қажетті тілдердегі кітапханалардың болуы, олардың қауіпсіздігі мен өнімділігі, жариялылығы, кешенді тестілері және т.б.

Мысалы, шекті BLS қолтаңбаларында маңызды мәселе бар - жұмысты бастамас бұрын қатысушылар шек жұмыс істейтін топты ұйымдастыра отырып, бір-біріне кілттерді таратуы керек. Бұл орталықтандырылмаған желіде айырбастаудың кем дегенде бір раунды күтуге тура келетінін білдіреді және генерацияланған ранд, мысалы, ойындарда дерлік нақты уақытта қажет екенін ескере отырып, бұл осы кезеңде хаттаманың саботажы мүмкін екенін білдіреді. , ал шекті схеманың артықшылықтары жоғалады. Бұл мәселе бұрынғыға қарағанда оңайырақ, бірақ әлі де талаптарды орындамаған қатысушылардан депозиттер салу және қаражатты алу (қию) арқылы экономикалық тұрғыдан қорғалуы тиіс шекті топтарды қалыптастырудың жеке тәртібін әзірлеуді талап етеді. хаттама. Сондай-ақ, қолайлы қауіпсіздік деңгейімен BLS тексеруі, мысалы, стандартты EOS немесе Ethereum транзакциясына сәйкес келмейді - тексеруге уақыт жеткіліксіз. Келісімшарт коды виртуалды машинамен орындалатын WebAssembly немесе EVM болып табылады. Криптографиялық функциялар жергілікті түрде (әлі) жүзеге асырылмайды және кәдімгі криптографиялық кітапханаларға қарағанда ондаған есе баяу жұмыс істейді. Көптеген хаттамалар жай ғана негізгі көлемге негізделген талаптарға сәйкес келмейді, мысалы, RSA үшін 1024 және 2048 бит, Bitcoin және Ethereum-дағы стандартты транзакция қолтаңбасынан 4-8 есе үлкен.

Әртүрлі бағдарламалау тілдеріндегі енгізулердің болуы да маңызды рөл атқарады - олардың саны аз, әсіресе жаңа хаттамалар үшін. Консенсусқа біріктіру опциясы платформа тілінде протокол жазуды талап етеді, сондықтан Go for geth, Rust for Parity, EOS үшін C++ ішінде кодты іздеуге тура келеді. Барлығы JavaScript кодын іздеуге мәжбүр болады және JavaScript және криптография өте жақын достар болмағандықтан, WebAssembly көмектеседі, ол енді келесі маңызды Интернет стандарты болып табылады.

қорытынды

Мен алдыңғысынан үміттенемін мақала Мен сізді блокчейнде кездейсоқ сандарды генерациялау орталықтандырылмаған желілер өмірінің көптеген аспектілері үшін өте маңызды екеніне сендіре алдым және осы мақаламен мен бұл тапсырманың өте өршіл және қиын екенін көрсеттім, бірақ жақсы шешімдер қазірдің өзінде бар. Жалпы, хаттаманың түпкілікті дизайны орнатудан бастап ақауды эмуляциялауға дейінгі барлық аспектілерді ескеретін ауқымды сынақтарды өткізгеннен кейін ғана мүмкін болады, сондықтан командалық ақпарақтар мен мақалалардан дайын рецепттерді табу екіталай, және біз, әрине, таппаймыз. келесі бір-екі жылда шешіңіз, «осылай жасаңыз, дәл солай».

Сәлеметсіз бе, біздің блокчейндегі PVRB үшін Хая, біз шекті BLS қолтаңбаларын пайдалануды шештік, біз PVRB консенсус деңгейінде енгізуді жоспарлап отырмыз, өйткені рұқсат етілген қауіпсіздік деңгейі бар смарт келісімшарттарда тексеру әлі мүмкін емес. Біз бірден екі схеманы қолдануымыз мүмкін: біріншіден, ұзақ мерзімді random_seed жасау үшін қымбат құпия бөлісу, содан кейін біз оны детерминирленген шекті BLS қолтаңбалары арқылы жоғары жиілікті кездейсоқ генерациялау үшін негіз ретінде пайдаланамыз, мүмкін, біз өзімізді тек осымен ғана шектейтін боламыз. схемаларының бірі. Өкінішке орай, хаттаманың қандай болатынын алдын ала айту мүмкін емес, жалғыз жақсы нәрсе - ғылымдағы сияқты, инженерлік мәселелерде де теріс нәтиже нәтиже болып табылады, ал мәселені шешудің әрбір жаңа әрекеті оның тағы бір қадамы болып табылады. мәселеге қатысы бар әрбір адамның зерттеуі. Бизнес талаптарын қанағаттандыру үшін біз белгілі бір практикалық мәселені шешеміз - ойын қосымшаларын сенімді энтропия көзімен қамтамасыз ету, сондықтан біз блокчейннің өзіне, атап айтқанда, тізбектің аяқталуы мен желіні басқару мәселелеріне назар аударуымыз керек.

Біз блокчейндерде дәлелденген төзімді PVRB-ді әлі көрмесек те, ол нақты қосымшалар, бірнеше аудиттер, жүктемелер және, әрине, нақты шабуылдар арқылы сынау үшін жеткілікті уақыт пайдаланылған еді, бірақ мүмкін болатын жолдардың саны растайды. шешім бар және осы алгоритмдердің қайсысы мәселені шешеді. Нәтижелермен бөлісуге және инженерлерге бір рейканы екі рет баспауға мүмкіндік беретін мақалалар мен кодтар үшін осы мәселемен жұмыс істеп жатқан басқа топтарға алғысымызды білдіреміз.

Сонымен, орталықтандырылмаған кездейсоқ жобаны жасайтын бағдарламашыны кездестіргенде, мұқият және қамқор болыңыз және қажет болған жағдайда психологиялық көмек көрсетіңіз :)

Ақпарат көзі: www.habr.com