тааныштыруу

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

Криптографиянын абсолюттук күчтүү шифринин концепциясы сыяктуу эле, чыныгы "Коомдук текшерилүүчү кокустук маяк" (мындан ары PVRB) протоколдору идеалдуу схемага мүмкүн болушунча жакын болууга гана аракет кылышат, анткени реалдуу тармактарда бул анын таза түрүндө колдонулбайт: бир бит боюнча катуу макулдашуу керек, көптөгөн раунддар болушу керек жана бардык билдирүүлөр эң сонун тез жана ар дайым жеткирилиши керек. Албетте, реалдуу тармактарда андай эмес. Ошондуктан, заманбап блокчейндерде конкреттүү тапшырмалар үчүн PVRBдерди долбоорлоодо, пайда болгон кокустук жана криптографиялык күчтү көзөмөлдөө мүмкүн эместигинен тышкары, көптөгөн таза архитектуралык жана техникалык көйгөйлөр пайда болот.

PVRB үчүн блокчейндин өзү негизинен билдирүүлөр = транзакциялар болгон байланыш каражаты болуп саналат. Бул тармак көйгөйлөрүнөн, билдирүүлөрдүн жеткирилбөөсүнөн, орто программадагы көйгөйлөрдөн жарым-жартылай абстракциялоого мүмкүндүк берет - бул тобокелдиктердин бардыгын борбордон ажыратылган тармак өзүнө алат жана анын PVRB үчүн негизги мааниси - буга чейин жөнөтүлгөн транзакцияны жокко чыгаруу же бузуп салуу мүмкүн эместиги. эгерде алар консенсуска ийгиликтүү чабуул жасабаса, катышуучуларга протоколго катышуудан баш тартууга жол бербөө. Коопсуздуктун бул деңгээли алгылыктуу, ошондуктан PVRB негизги блокчейн чынжырындай деңгээлде катышуучулардын тымызын келишине туруштук бериши керек. Ошондой эле, бул тармак негизги блокчейнге макул болсо, PVRB консенсустун бир бөлүгү болушу керек экендигин кыйытууда, ал тургай, ал бир гана адилеттүү натыйжага макул болсо да. Же, PVRB жөн гана блокчейнге жана блокторго карата асинхрондуу иштеген акылдуу келишим тарабынан ишке ашырылган өз алдынча протокол. Эки ыкманын тең артыкчылыктары жана кемчиликтери бар жана алардын ортосундагы тандоо өтө маанилүү эмес.

PVRB ишке ашыруунун эки жолу

Келгиле, PVRBди ишке ашыруунун эки вариантын кененирээк сүрөттөп берели - блокчейнден көз карандысыз акылдуу келишимди колдонуу менен иштеген автономдуу версия жана протоколго орнотулган консенсус менен интеграцияланган версия, ага ылайык тармак блокчейн менен макулдашылган транзакциялар киргизилет. Бардык учурларда, мен популярдуу блокчейн кыймылдаткычтарын айткым келет: Ethereum, EOS жана акылдуу контракттарды кабыл алуу жана иштетүү жолу менен аларга окшош.

Өз алдынча келишим

Бул версияда PVRB кокустук өндүрүүчүлөрдүн транзакцияларын (мындан ары - RP) кабыл алган, аларды иштетип, натыйжаларды бириктирген жана натыйжада бул келишимден каалаган колдонуучу ала турган белгилүү бир мааниге жеткен акылдуу келишим болуп саналат. Бул маани түздөн-түз келишимде сакталбашы мүмкүн, тескерисинче, натыйжада кокустуктун бир жана бир гана маанисин аныктоочу түрдө алууга мүмкүн болгон маалыматтар менен гана көрсөтүлүшү мүмкүн. Бул схемада RPs блокчейндин колдонуучулары болуп саналат жана ар кимге генерация процессине катышууга уруксат берилиши мүмкүн.

Өз алдынча келишим менен вариант жакшы:

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

Анын да кемчиликтери бар:

• эсептөө ресурстарына, транзакциянын көлөмүнө жана сактоого катуу чектөөлөр (башкача айтканда, cpu/mem/io)
• келишимдин алкагында операцияларга чектөөлөр (баардык инструкциялар жеткиликтүү эмес, тышкы китепканаларды туташтыруу кыйын)
• блокчейнге киргизилген транзакцияларга караганда билдирүүлөрдү тезирээк уюштуруу мүмкүн эместиги

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

Консенсус-интеграцияланган

Бул версияда PVRB блокчейн түйүнүнүн кодунда ишке ашырылат, орнотулган же блокчейн түйүндөрүнүн ортосунда билдирүүлөрдү алмашуу менен параллелдүү иштейт. Протоколдун натыйжалары түздөн-түз өндүрүлгөн блокторго жазылат жана протоколдук билдирүүлөр түйүндөрдүн ортосунда p2p тармагы аркылуу жөнөтүлөт. Протоколдун жыйынтыгында блоктор менен жазыла турган сандар пайда болгондуктан, тармак алар боюнча консенсуска жетиши керек. Бул PVRB билдирүүлөрү транзакциялар сыяктуу түйүндөр тарабынан текшерилип, блокторго киргизилиши керек дегенди билдирет, ошондуктан ар бир тармактын катышуучусу PVRB протоколуна шайкеш келүүнү ырастай алат. Бул автоматтык түрдө бизди айкын чечимге алып барат - эгерде тармак блок жана андагы транзакциялар жөнүндө консенсуска макул болсо, анда PVRB өз алдынча протокол эмес, консенсустун бир бөлүгү болушу керек. Болбосо, блок консенсустук көз караштан жарактуу болушу мүмкүн, бирок PVRB протоколу сакталбайт жана PVRB көз карашынан алганда блокту кабыл алуу мүмкүн эмес. Ошентип, эгерде “консенсус-интеграцияланган” вариант тандалган болсо, PVRB консенсустун маанилүү бөлүгү болуп калат.

Тармактын консенсус деңгээлинде PVRB ишке ашырууларын сүрөттөп жатканда, эч кандай жол менен жыйынтыктоо маселелеринен качуу мүмкүн эмес. Аяктоо – детерминисттик консенсустарда колдонулган механизм, ал блокту (жана ага алып баруучу чынжырды) жасайт, ал акыркы болуп саналат жана параллелдүү айры пайда болсо да, эч качан ыргытылбайт. Мисалы, Биткойндо мындай механизм жок - эгер сиз татаалыраак чынжырды жарыяласаңыз, ал чынжырлардын узундугуна карабастан, азыраак татаалын алмаштырат. Ал эми 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 үчүн системалык келишимдер)

Ачык жана ишенимдүү протоколдук билдирүү каналын камсыз кылган Blockchain муну бекер кылбайт. Ар кандай децентралдаштырылган протокол Sybil чабуулунун мүмкүнчүлүгүн эске алышы керек; кандайдыр бир иш-аракет бир нече эсептердин макулдашылган күчтөрү тарабынан аткарылышы мүмкүн, ошондуктан, долбоорлоодо чабуулчулардын протоколдун ыктыярдуу санын түзө алуу мүмкүнчүлүгүн эске алуу керек. ка-тышуучулардын макулдашып аракеттениши.

PVRB жана блок өзгөрмөлөр.

Көптөгөн кумар тиркемелери тарабынан сыналган жакшы PVRBди блокчейндерде эч ким ишке ашыра элек деп айтсам, мен калп айткан жокмун. Ethereum жана EOS боюнча мынчалык көп кумар тиркемелери кайдан келет? Бул сизди таң калтырганы сыяктуу мени да таң калтырат, алар толугу менен детерминисттик чөйрөдө мынчалык көп “туруктуу” кокустуктарды кайдан алышкан?

Блокчейндеги кокустуктарды алуунун сүйүктүү жолу - блоктон кандайдыр бир "болжолдонбогон" маалыматты алуу жана анын негизинде бир же бир нече маанилерди хэширлөө аркылуу кокустук түзүү. Мындай схемалардын көйгөйлөрү жөнүндө жакшы макала бул жерде. Сиз блоктогу "болжолдонбогон" маанилердин каалаганын ала аласыз, мисалы, блок хэш, транзакциялардын саны, тармактын татаалдыгы жана башка алдын ала белгисиз баалуулуктар. Андан кийин, аларды бир же бир нече хэш, жана, теориялык жактан алганда, сиз чыныгы кокустукка ээ болушуңуз керек. Сиз атүгүл кагазга сиздин схемаңызды "кванттан кийинки коопсуз" деп кошсоңуз болот (анткени кванттык хэш-функциялар бар :)).

Бирок, атүгүл пост-кванттык коопсуз хэштер жетишсиз. Сыр PVRBге коюлган талаптарда жатат, аларды мурунку макаладан эске сала кетейин:

1. Натыйжа бир калыпта бөлүштүрүүгө ээ болушу керек, башкача айтканда, күчтүү криптографияга негизделиши керек.
2. Натыйжадагы биттердин бирин да көзөмөлдөө мүмкүн эмес. Натыйжада, алдын ала алдын ала айтуу мүмкүн эмес.
3. Протоколго катышпай туруп же тармакты чабуул билдирүүлөрү менен ашыкча жүктөө менен генерациялоо протоколун бузууга болбойт.
4. Жогоруда айтылгандардын баары протоколдун абийирсиз катышуучуларынын жол берилген санынын (мисалы, катышуучулардын 1/3 бөлүгүнүн) макулдашуусуна туруктуу болушу керек.

Бул учурда, 1-талап гана аткарылат, ал эми 2-талап аткарылбайт. Блоктон күтүлбөгөн маанилерди хэширлөө менен, биз бирдиктүү бөлүштүрүүнү жана жакшы кокустуктарды алабыз. Бирок BP жок дегенде "блокту жарыялоо же жарыялабоо" мүмкүнчүлүгүнө ээ. Ошентип, BP жок дегенде ЭКИ кокусунан тандай алат: "өзүнүн" жана блокту башка бирөө жасаса, кайсынысы чыгат. BP ал блок жарыяласа, эмне болорун алдын ала "көзөмөлдөө" мүмкүн, жана жөн гана аны же жокпу, чечет. Ошентип, мисалы, рулеткада “жуп-так” же “кызыл/кара” ойноп жатканда, ал утушту көргөндө гана блокту жарыялай алат. Бул ошондой эле, мисалы, "келечектен" блок хэшти колдонуу стратегиясын ишке ашпайт. Бул учурда, алар "кокустук колдонулат, ал учурдагы маалыматтарды жана келечектеги блоктун бийиктигин, мисалы, N + 42, мында N учурдагы блоктун бийиктигин хэштөө жолу менен алынат. Бул схеманы бир аз бекемдейт, бирок BPге келечекте болсо да, блокту кармоону же жарыялоону тандоого мүмкүндүк берет.

Бул учурда BP программалык камсыздоо татаал болуп калат, бирок көп эмес. Жөн гана, транзакцияны блокко валидациялоодо жана кошууда, утуштун болушун билүү үчүн тез текшерүү жана, балким, утуп алуу ыктымалдуулугу жогору болушу үчүн транзакциянын бир параметрин тандоо бар. Ошол эле учурда, мындай манипуляциялар үчүн акылдуу BP кармап калуу дээрлик мүмкүн эмес, ар бир жолу сиз жаңы даректерди колдонуп, шектенүүлөрдү пайда кылбастан акырындык менен утуп аласыз.

Ошентип, блоктон маалыматты колдонуу ыкмалары PVRB универсалдуу ишке ашыруу катары ылайыктуу эмес. Чектелген версияда, коюмдун өлчөмдөрүнө чектөөлөр, оюнчулардын санына чектөөлөр жана/же KYC каттоосу (бир оюнчу бир нече даректи колдонууга жол бербөө үчүн) бул схемалар кичинекей оюндар үчүн иштей алат, бирок башка эч нерсе жок.

PVRB жана милдеттенме-ачыкка.

Макул, хэшинг жана жок эле дегенде, блоктун хэшинин жана башка өзгөрмөлөрдүн салыштырмалуу күтүлбөгөндүгүнө рахмат. Эгер алдыңкы шахтерлордун көйгөйүн чечсеңиз, анда сиз дагы ылайыктуу нерсени алышыңыз керек. Келгиле, бул схемага колдонуучуларды кошолу - алар кокустукка да таасир этсин: ар бир техникалык колдоо кызматкери сизге IT тутумдарындагы эң кокус нерсе бул колдонуучулардын аракети экенин айтып берет :)

Колдонуучулар жөн эле кокус сандарды жөнөтүп, натыйжасы, мисалы, алардын суммасынын хэштери катары эсептелген жөнөкөй схема ылайыктуу эмес. Бул учурда, акыркы оюнчу өзүнүн кокусунан тандап, натыйжасы кандай болорун көзөмөлдөй алат. Мына ушундан улам абдан кеңири колдонулган commit-açine үлгүсү колдонулат. Катышуучулар адегенде кокусунан (милдеттенмелерден) хэштерди жөнөтүшөт, андан кийин өзүлөрү кокустуктарды ачышат (ачыктайт). "Ачыкка чыгаруу" фазасы керектүү милдеттенмелер чогултулгандан кийин гана башталат, андыктан катышуучулар мурда жөнөтүлгөн кокустук хэшти так жөнөтө алышат. Эми мунун баарын блоктун параметрлери менен кошобуз жана келечекте алынгандан жакшыраак (кокустук келечектеги блоктордун биринде гана болот) жана voila - кокустук даяр! Эми каалаган оюнчу пайда болгон кокустукка таасирин тийгизет жана зыяндуу BPди өзүнүн, алдын ала белгисиз, кокустук менен жокко чыгарып, аны "жеңе алат"... Ошондой эле протоколду ачыкка чыгаруу баскычында ачпай туруп, аны саботаждан коргоону кошо аласыз - жөн гана. бүтүм жасоодо белгилүү бир сумманы кошууну талап кылуу менен — ачыкка чыгаруу жол-жобосунда гана кайтарылып берилүүчү күрөө депозити. Мындай учурда жасаган жана ачыкка чыгарбоо пайдасыз болот.

Бул жакшы аракет болду жана мындай схемалар DApps оюнунда да бар, бирок тилекке каршы, бул дагы эле жетишсиз. Эми натыйжага шахтер гана эмес, протоколдун каалаган катышуучусу да таасир эте алат. Нарктын өзүн дагы эле аз өзгөрүлмөлүүлүк менен жана чыгаша менен көзөмөлдөө мүмкүн, бирок, шахтёрдогудай, эгерде чийменин жыйынтыгы PVRB протоколуна катышуу үчүн төлөмдөн алда канча баалуу болсо, анда кокустук -producer(RP) ачыкка чыгарууну чече алат жана дагы эле жок дегенде эки кокусунан тандай алат.
Бирок жасагандарды жана ачыкка чыгарбагандарды жазалоо мүмкүн болуп калды, бул схема пайдалуу болот. Анын жөнөкөйлүгү олуттуу артыкчылык болуп саналат - олуттуу протоколдор алда канча күчтүү эсептөөлөрдү талап кылат.

PVRB жана детерминисттик кол тамгалар.

РПны псевдо-кокус санды берүүгө мажбурлоонун дагы бир жолу бар, эгерде ал "алдын ала сүрөт" менен камсыз болсо, ал таасир эте албайт - бул детерминисттик кол коюу. Мындай кол, мисалы, RSA болуп саналат жана ECS эмес. Эгерде RPтин жуп ачкычтары бар болсо: RSA жана ECC жана ал өзүнүн купуя ачкычы менен белгилүү бир мааниге кол койсо, анда RSA учурда ал БИР ЖАНА БИР ГАНА кол алат, ал эми ECS учурда ал каалаган сандагы кол тамганы түзө алат. ар кандай жарактуу кол тамгалар. Себеби, ECS кол тамгасын түзүүдө кокус кол коюучу тарабынан тандалып алынган кокус сан колдонулат жана ал каалаган жол менен тандалып алынышы мүмкүн, кол коюучуга бир нече кол тамгалардын бирин тандоо мүмкүнчүлүгүн берет. RSA учурда: "бир киргизүү мааниси" + "бир ачкыч жуп" = "бир кол". Башка РП кандай кол тамга алаарын алдын ала айтуу мүмкүн эмес, ошондуктан детерминисттик кол коюлган 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ди ишке ашыруу үчүн абдан ыңгайлуу жана келечектүү схеманы иштеп чыгууга мүмкүндүк берди - бул детерминисттик босого кол тамгалар. Бул жерде макала босого кол тамгалардын ар кандай колдонулушу жөнүндө жана бул жерде дагы бир жакшы нерсе узак окуу Dash тартып.

Акыркы макала BLS колдорун сүрөттөйт (BLS Боне-Линн-Шачам, бул жерде макала), программисттер үчүн өтө маанилүү жана өтө ыңгайлуу сапатка ээ - ачык, жашыруун, ачык ачкычтар жана BLS кол тамгалары жөнөкөй математикалык операцияларды колдонуу менен бири-бири менен айкалыштырылышы мүмкүн, ал эми алардын айкалыштары жарактуу ачкычтар жана кол тамгалар бойдон калууда, бул көптөгөн коддорду оңой бириктирүүгө мүмкүндүк берет. кол коюуларды бирге жана көп ачык ачкычтарды бирге. Алар ошондой эле детерминистикалык болуп саналат жана ошол эле киргизүү маалыматтары үчүн бирдей натыйжаны берет. Бул сапаттан улам, BLS кол тамгаларынын айкалыштары өзүлөрү жарактуу ачкычтар болуп саналат, бул Mth N катышуучулары Mth тарабынан ачылганга чейин детерминисттик, жалпыга ачык текшерилүүчү жана күтүүсүз болгон бир жана бир гана колду чыгара турган вариантты ишке ашырууга мүмкүндүк берет. катышуучу.

Босого BLS кол тамгалары бар схемада ар бир катышуучу BLS (мисалы, мурунку кокустук) колдонуу менен бир нерсеге кол коет жана жалпы босого кол тамгасы каалаган кокустук болуп саналат. BLS кол тамгаларынын криптографиялык касиеттери кокустук сапаттын талаптарын канааттандырат, босого бөлүгү "акыркы актердон" коргойт жана ачкычтардын уникалдуу айкалышуусу, мисалы, протоколдук билдирүүлөрдү эффективдүү бириктирүүгө мүмкүндүк берген көптөгөн кызыктуу алгоритмдерди ишке ашырууга мүмкүндүк берет. .

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

PVRB ишке ашыруу

Тилекке каршы, биз дагы эле PVRB блокчейндеринде ишке ашырылган, анын коопсуздугун жана туруктуулугун далилдеген даяр протоколду көрө элекпиз. Протоколдор өздөрү даяр болсо да, аларды техникалык жактан колдонуудагы чечимдерге колдонуу оңой эмес. Борборлоштурулган системалар үчүн PVRB мааниси жок, ал эми борбордон ажыратылгандары бардык эсептөө ресурстарында катуу чектелген: CPU, эс тутум, сактоо, киргизүү/чыгаруу. PVRBди долбоорлоо - бул, жок эле дегенде, кээ бир жашоого жөндөмдүү блокчейн үчүн бардык талаптарга жооп берген нерсени түзүү үчүн ар кандай протоколдордун айкалышы. Бир протокол натыйжалуураак эсептейт, бирок РПнын ортосунда көбүрөөк билдирүүлөрдү талап кылат, ал эми экинчиси өтө аз билдирүүлөрдү талап кылат, бирок далил түзүү ондогон мүнөттөрдү, атүгүл сааттарды талап кылган иш болушу мүмкүн.

Мен сапаттуу PVRB тандоодо эске алуу керек болгон факторлорду тизмектейм:

• Криптографиялык күч. Сиздин PVRB бир битти башкара албаган, калыс болушу керек. Кээ бир схемаларда бул андай эмес, андыктан криптографты чакырыңыз
• "Акыркы актер" көйгөйү. Сиздин PVRB чабуулдарга туруктуу болушу керек, анда бир же бир нече РПны башкарган чабуулчу эки жыйынтыктын бирин тандай алат.
• Протоколдук саботаж маселеси. Сиздин PVRB кол салууларга туруктуу болушу керек, анда бир же бир нече РПны башкарган чабуулчу кокустук болобу же жокпу чечет жана кепилденген же ага таасир эте турган ыктымалдуулук менен
• Билдирүүлөрдүн саны көйгөйү. Сиздин RP'лериңиз блокчейнге минималдуу билдирүүлөрдү жөнөтүшү керек жана мүмкүн болушунча синхрондуу аракеттерден алыс болушу керек, мисалы, "мен кээ бир маалымат жөнөттүм, мен белгилүү бир катышуучудан жооп күтүп жатам". P2p тармактарында, өзгөчө географиялык жактан чачырап кеткен тармактарда, сиз тез жооп берүүгө ишенбешиңиз керек
• Эсептөө татаалдыгы маселеси. PVRB чынжырчасынын каалаган баскычын текшерүү өтө жеңил болушу керек, анткени аны тармактын бардык толук кардарлары аткарышат. Эгерде ишке ашыруу акылдуу келишимди колдонуу менен ишке ашса, анда ылдамдык талаптары абдан катуу
• Жеткиликтүүлүк жана жандуулүк маселеси. Сиздин PVRB тармактын бир бөлүгү белгилүү бир убакытка жеткиликсиз болуп калган жана ЖПнын бир бөлүгү жөн эле иштебей калган кырдаалдарга туруктуу болууга умтулушу керек.
• Ишенимдүү орнотуу жана баштапкы ачкыч бөлүштүрүү маселеси. Эгерде сиздин PVRB протоколдун негизги орнотуусун колдонсо, анда бул өзүнчө чоң жана олуттуу окуя. Бул жерде мисал. Эгерде катышуучулар протоколду баштоодон мурун бири-бирине ачкычтарын айтышы керек болсо, катышуучулардын курамы өзгөрсө, бул дагы көйгөй жаратат.
• Өнүгүү проблемалары. Талап кылынган тилдердеги китепканалардын болушу, алардын коопсуздугу жана иштеши, жарыяланышы, комплекстүү тесттер ж.б.

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

Ар кандай программалоо тилдеринде ишке ашыруунун болушу да роль ойнойт - алар аз, айрыкча жаңы протоколдор үчүн. Консенсуска интеграцияланган вариант платформа тилинде протокол жазууну талап кылат, андыктан Go for geth, Rust for Parity, C++ үчүн EOS үчүн код издөөгө туура келет. Ар бир адам JavaScript кодун издөөгө туура келет, жана JavaScript жана криптография өзгөчө жакын достор болбогондуктан, WebAssembly жардам берет, ал азыр сөзсүз кезектеги маанилүү Интернет стандарты деп ырастайт.

жыйынтыктоо

Мен мурункусунан үмүттөнөм макала Мен сизди блокчейнде кокус сандарды түзүү борбордон ажыратылган тармактардын жашоосунун көптөгөн аспектилери үчүн маанилүү экенине ишендире алдым жана бул макала менен бул милдет өтө дымактуу жана кыйын экенин көрсөттү, бирок жакшы чечимдер мурунтан эле бар. Жалпысынан алганда, протоколдун акыркы дизайнын орнотуудан баштап катаны эмуляциялоого чейинки бардык аспектилерди эске алган массалык тестирлөөдөн кийин гана мүмкүн болот, андыктан команданын ак кагаздарында жана макалаларында даяр рецепттерди таба албайсыз жана биз, албетте, мүмкүн эмес. кийинки бир-эки жылда чечип, "ушундай кылып жаса, так туура" деп жаз.

Кош, биздин блокчейндеги PVRB үчүн Haya, биз чектүү BLS колдорун колдонууну чечтик, биз PVRBди консенсус деңгээлинде ишке ашырууну пландаштырып жатабыз, анткени коопсуздуктун алгылыктуу деңгээли менен акылдуу келишимдерде текшерүү азырынча мүмкүн эмес. Биз бир эле учурда эки схеманы колдонушубуз мүмкүн: биринчиден, узак мөөнөттүү random_seed түзүү үчүн кымбат баалуу сыр бөлүшүү, андан кийин биз аны детерминисттик босого BLS колдорун колдонуу менен жогорку жыштыктагы кокустук генерация үчүн негиз катары колдонобуз, балким, биз өзүбүз менен гана чектелебиз. схемалардын бири. Тилекке каршы, протоколдун кандай болорун алдын ала айтуу мүмкүн эмес, бир гана жакшы нерсе, илимдегидей эле, инженердик маселелерде да терс натыйжа болуп саналат жана маселени чечүүнүн ар бир жаңы аракети дагы бир кадам болуп саналат. проблемага катышкан ар бир адамдын изилдөөсү. Бизнестин талаптарын канааттандыруу үчүн биз белгилүү бир практикалык маселени чечебиз - оюн тиркемелерин энтропиянын ишенимдүү булагы менен камсыз кылуу, ошондуктан биз блокчейндин өзүнө, атап айтканда, чынжырдын бүтүшү жана тармакты башкаруу маселелерине көңүл бурушубуз керек.

Чыныгы тиркемелер, бир нече аудиттер, жүктер жана, албетте, реалдуу чабуулдар тарабынан сыналышы үчүн жетиштүү убакыт колдонулган блокчейндерде далилденген туруктуу PVRBди көрө элекпиз, бирок мүмкүн болгон жолдордун саны муну тастыктайт. бир чечим бар жана бул алгоритмдердин кайсынысы көйгөйдү чечет. Биз натыйжалар менен бөлүшүүгө жана инженерлерге бир тырмоо эки жолу баспоого мүмкүндүк берген макалалар жана коддор үчүн ушул маселе боюнча иштеп жаткан башка командаларга ыраазычылык билдиребиз.

Ошентип, борбордон ажыратылган туш келди долбоорлоочу программистке жолукканыңызда, кунт коюп, камкор болуңуз жана керек болсо психологиялык жардам бериңиз :)

Source: www.habr.com