Ներածություն

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

Ինչպես գաղտնագրությունից բացարձակապես ուժեղ գաղտնագրման հայեցակարգի դեպքում, իրական «Հանրային ստուգվող պատահական փարոս» (այսուհետ՝ PVRB) արձանագրությունները միայն փորձում են հնարավորինս մոտենալ իդեալական սխեմային, քանի որ իրական ցանցերում այն ​​կիրառելի չէ իր մաքուր ձևով. անհրաժեշտ է խստորեն համաձայնեցնել մեկ բիթ, պետք է լինեն շատ փուլեր, և բոլոր հաղորդագրությունները պետք է կատարյալ արագ և միշտ մատուցվեն: Իհարկե, իրական ցանցերում դա այդպես չէ։ Հետևաբար, ժամանակակից բլոկչեյններում հատուկ առաջադրանքների համար PVRB-ներ նախագծելիս, ի լրումն արդյունքում պատահականության և գաղտնագրման ուժի վերահսկման անհնարինության, առաջանում են շատ ավելի զուտ ճարտարապետական ​​և տեխնիկական խնդիրներ:

PVRB-ի համար բլոկչեյնն ինքնին, ըստ էության, հաղորդակցման միջոց է, որտեղ հաղորդագրություններ = գործարքներ: Սա թույլ է տալիս մասամբ հեռացնել ցանցի խնդիրներից, հաղորդագրությունների չմատակարարումից, միջին ծրագրակազմի հետ կապված խնդիրներից. թույլ չտալ մասնակիցներին հրաժարվել արձանագրությանը մասնակցելուց, եթե նրանք հաջող հարձակում չեն իրականացրել կոնսենսուսի վրա: Անվտանգության այս մակարդակը ընդունելի է, ուստի PVRB-ն պետք է դիմացկուն լինի մասնակիցների դավադրությանը ճիշտ նույն չափով, որքան հիմնական բլոկչեյն շղթան: Նաև սա հուշում է, որ PVRB-ն պետք է լինի կոնսենսուսի մի մասը, եթե ցանցը համաձայնի հիմնական բլոկչեյնին, նույնիսկ եթե այն համաձայնի նաև միակ արդար արդյունքի պատահականության վրա: Կամ, PVRB-ն պարզապես ինքնուրույն արձանագրություն է, որն իրականացվում է խելացի պայմանագրով, որն աշխատում է ասինխրոն՝ կապված բլոկչեյնի և բլոկների հետ: Երկու մեթոդներն էլ ունեն իրենց առավելություններն ու թերությունները, և նրանց միջև ընտրությունը չափազանց աննշան է:

PVRB-ի իրականացման երկու եղանակ

Եկեք ավելի մանրամասն նկարագրենք PVRB-ի ներդրման երկու տարբերակ՝ ինքնուրույն տարբերակը, որն աշխատում է բլոկչեյնից անկախ խելացի պայմանագրի միջոցով, և արձանագրության մեջ ներկառուցված կոնսենսուսով ինտեգրված տարբերակը, ըստ որի՝ ցանցը համաձայնում է բլոկչեյնին և ներառված գործարքները: Բոլոր դեպքերում ես նկատի կունենամ հանրաճանաչ բլոկչեյն շարժիչներ՝ Ethereum, EOS և բոլոր նրանց նմանները՝ խելացի պայմանագրերի ընդունման և մշակման ձևով:

Անկախ պայմանագիր

Այս տարբերակում PVRB-ն խելացի պայմանագիր է, որն ընդունում է պատահական արտադրողների գործարքները (այսուհետ՝ RP), մշակում է դրանք, համատեղում արդյունքները և արդյունքում հասնում է որոշակի արժեքի, որը ցանկացած օգտվող կարող է ստանալ այս պայմանագրից: Այս արժեքը կարող է ուղղակիորեն չպահվել պայմանագրում, այլ ավելի շուտ ներկայացված լինել միայն տվյալների միջոցով, որոնցից կարելի է որոշիչ կերպով ստանալ ստացված պատահականության մեկ և միայն մեկ արժեքը: Այս սխեմայում RP-ները բլոկչեյնի օգտագործողներ են, և յուրաքանչյուրին կարող է թույլատրվել մասնակցել գեներացման գործընթացին:

Ինքնուրույն պայմանագրով տարբերակը լավ է.

• շարժականություն (պայմանագրերը կարող են քաշվել բլոկչեյնից բլոկչեյն)
• իրականացման և փորձարկման հեշտություն (պայմանագրերը հեշտ է գրել և փորձարկել)
• հարմարավետություն տնտեսական սխեմաների իրականացման գործում (հեշտ է պատրաստել ձեր սեփական նշանը, որի տրամաբանությունը ծառայում է PVRB-ի նպատակներին)
• արդեն աշխատող բլոկչեյնների վրա գործարկման հնարավորություն

Այն ունի նաև թերություններ.

• հաշվողական ռեսուրսների, գործարքների ծավալի և պահեստավորման խիստ սահմանափակումներ (այլ կերպ ասած՝ cpu/mem/io)
• պայմանագրի շրջանակներում գործողությունների սահմանափակումներ (բոլոր հրահանգները հասանելի չեն, արտաքին գրադարանները միացնելը դժվար է)
• հաղորդագրությունների փոխանակումն ավելի արագ կազմակերպելու անկարողություն, քան գործարքները ներառված են բլոկչեյնում

Այս տարբերակը հարմար է PVRB-ի իրականացման համար, որը պետք է գործարկվի գոյություն ունեցող ցանցում, չի պարունակում բարդ գաղտնագրություն և չի պահանջում մեծ թվով փոխազդեցություններ:

Կոնսենսուս-ինտեգրված

Այս տարբերակում PVRB-ն իրականացվում է բլոկչեյն հանգույցի կոդում, ներկառուցված կամ աշխատում է բլոկչեյն հանգույցների միջև հաղորդագրությունների փոխանակմանը զուգահեռ: Արձանագրության արդյունքները ուղղակիորեն գրվում են արտադրված բլոկների մեջ, և պրոտոկոլային հաղորդագրությունները ուղարկվում են p2p ցանցով հանգույցների միջև: Քանի որ արձանագրության արդյունքում ստացվում են թվեր, որոնք պետք է գրվեն բլոկներով, ցանցը պետք է կոնսենսուսի հասնի դրանց վերաբերյալ: Սա նշանակում է, որ PVRB հաղորդագրությունները, ինչպես գործարքները, պետք է վավերացվեն հանգույցներով և ներառվեն բլոկներում, որպեսզի ցանցի ցանկացած մասնակից կարողանա հաստատել PVRB արձանագրության հետ համապատասխանությունը: Սա ինքնաբերաբար մեզ տանում է դեպի ակնհայտ լուծում. եթե ցանցը համաձայնում է բլոկի և դրանում գործարքների վերաբերյալ կոնսենսուսի շուրջ, ապա PVRB-ն պետք է լինի կոնսենսուսի մի մասը, այլ ոչ թե առանձին արձանագրություն: Հակառակ դեպքում, հնարավոր է, որ բլոկը վավեր է կոնսենսուսի տեսանկյունից, բայց PVRB արձանագրությունը չի պահպանվում, և PVRB-ի տեսանկյունից բլոկը չի կարող ընդունվել։ Այսպիսով, եթե ընտրվի «համաձայնությամբ ինտեգրված» տարբերակը, PVRB-ն դառնում է կոնսենսուսի կարևոր մասը:

Ցանցի կոնսենսուսի մակարդակով PVRB-ի իրականացումները նկարագրելիս ոչ մի կերպ չի կարելի խուսափել վերջնականության խնդիրներից: Վերջնականությունը մի մեխանիզմ է, որն օգտագործվում է դետերմինիստական ​​կոնսենսուսների մեջ, որը փակում է բլոկի մեջ (և դեպի դրան տանող շղթան), որը վերջնական է և երբեք չի նետվի, նույնիսկ եթե զուգահեռ պատառաքաղ առաջանա: Օրինակ, Bitcoin-ում նման մեխանիզմ չկա. եթե դուք հրապարակեք ավելի մեծ բարդության շղթա, այն կփոխարինի ցանկացած պակաս բարդին, անկախ շղթաների երկարությունից: Իսկ EOS-ում, օրինակ, վերջնականները, այսպես կոչված, Last Irreversible Blocks-ներն են, որոնք հայտնվում են միջինը յուրաքանչյուր 432 բլոկից (12*21 + 12*15, pre-vote + pre-commit)։ Այս գործընթացն ըստ էության սպասում է բլոկ արտադրողների 2/3-ի (այսուհետ՝ BP) ստորագրություններին։ Երբ հայտնվում են պատառաքաղներ, որոնք ավելի հին են, քան վերջին LIB-ը, դրանք պարզապես դեն են նետվում: Այս մեխանիզմը հնարավորություն է տալիս երաշխավորել, որ գործարքը ներառված է բլոկչեյնում և երբեք հետ չի գլորվի, անկախ նրանից, թե հարձակվողը ինչ ռեսուրս ունի: Նաև վերջնական բլոկները բլոկներ են, որոնք ստորագրված են 2/3 BP-ի կողմից Hyperledger, Tendermint և pBFT-ի վրա հիմնված այլ կոնսենսուսներում: Նաև իմաստ ունի վերջնականությունն ապահովելու արձանագրություն կազմել՝ որպես կոնսենսուսի հավելում, քանի որ այն կարող է ասինխրոն աշխատել բլոկների արտադրության և հրապարակման հետ: Ահա մի լավ հոդված Ethereum-ի վերջնականության մասին:

Վերջնականությունը չափազանց կարևոր է օգտատերերի համար, ովքեր առանց դրա կարող են հայտնվել «կրկնակի ծախսերի» հարձակման զոհ, որտեղ BP-ն «պահում է» արգելափակումները և դրանք հրապարակում է այն բանից հետո, երբ ցանցը լավ գործարք «տեսնի»: Եթե ​​վերջնականություն չկա, ապա հրապարակված պատառաքաղը բլոկը փոխարինում է «լավ» գործարքով մեկ այլ՝ «վատ» պատառաքաղից, որում նույն միջոցները փոխանցվում են հարձակվողի հասցեին: PVRB-ի դեպքում վերջնականության պահանջներն էլ ավելի խիստ են, քանի որ PVRB-ի համար պատառաքաղներ կառուցելը նշանակում է հարձակվողի համար մի քանի պատահական տարբերակներ պատրաստելու հնարավորություն՝ ամենաշահավետը հրապարակելու համար, և հնարավոր հարձակման ժամանակը սահմանափակելը. լավ լուծում.

Հետևաբար, լավագույն տարբերակը PVRB-ն և վերջնականությունը մեկ արձանագրության մեջ համատեղելն է. այնուհետև վերջնական բլոկը = վերջնական պատահական, և սա հենց այն է, ինչ մեզ անհրաժեշտ էր ստանալու համար: Այժմ խաղացողները կստանան երաշխավորված պատահականություն N վայրկյանում և կարող են վստահ լինել, որ անհնար է այն հետ գլորել կամ նորից վերարտադրել:

Համաձայնության ինտեգրված տարբերակը լավ է.

• բլոկների արտադրության հետ կապված ասինխրոն իրականացման հնարավորությունը - բլոկները արտադրվում են ինչպես միշտ, բայց դրան զուգահեռ կարող է աշխատել PVRB արձանագրությունը, որը պատահականություն չի առաջացնում յուրաքանչյուր բլոկի համար:
• նույնիսկ ծանր գաղտնագրություն իրականացնելու ունակություն՝ առանց խելացի պայմանագրերի վրա դրված սահմանափակումների
• հաղորդագրությունների փոխանակումն ավելի արագ կազմակերպելու ունակություն, քան գործարքները ներառված են բլոկչեյնում, օրինակ՝ արձանագրության մի մասը կարող է աշխատել հանգույցների միջև՝ առանց հաղորդագրություններ ցանցի միջոցով բաշխելու

Այն ունի նաև թերություններ.

• Փորձարկման և մշակման դժվարություններ. դուք պետք է ընդօրինակեք ցանցի սխալները, բացակայող հանգույցները, ցանցի կոշտ պատառաքաղները
• Իրականացման սխալները պահանջում են ցանցային կոշտ պատառաքաղ

PVRB-ի ներդրման երկու մեթոդներն էլ կյանքի իրավունք ունեն, սակայն ժամանակակից բլոկչեյններում խելացի պայմանագրերի իրականացումը դեռևս բավականին սահմանափակ է հաշվողական ռեսուրսներում, և ցանկացած անցում լուրջ ծածկագրության հաճախ պարզապես անհնար է: Եվ մեզ անհրաժեշտ կլինի լուրջ ծածկագրություն, ինչպես կցուցադրվի ստորև: Չնայած այս խնդիրն ակնհայտորեն ժամանակավոր է, շատ խնդիրներ լուծելու համար անհրաժեշտ է լուրջ ծածկագրություն պայմանագրերում, և այն աստիճանաբար ի հայտ է գալիս (օրինակ՝ Ethereum-ում zkSNARK-ների համար համակարգային պայմանագրեր)

Բլոկչեյնը, որն ապահովում է թափանցիկ և հուսալի պրոտոկոլային հաղորդագրությունների ալիք, դա անվճար չի անում: Ցանկացած ապակենտրոնացված արձանագրություն պետք է հաշվի առնի 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 և պարտավորվել-բացահայտել:

Լավ, հաշինգի և բլոկի հեշի և այլ փոփոխականների առնվազն հարաբերական անկանխատեսելիության շնորհիվ: Եթե ​​դուք լուծում եք առջևում աշխատող հանքագործների խնդիրը, դուք պետք է ավելի հարմար բան ստանաք: Եկեք այս սխեմային ավելացնենք օգտվողներին. թող նրանք նույնպես ազդեն պատահականության վրա. տեխնիկական աջակցության ցանկացած աշխատակից ձեզ կասի, որ ՏՏ համակարգերում ամենապատահականը օգտատերերի գործողություններն են :)

Միամիտ սխեման, երբ օգտվողները պարզապես պատահական թվեր են ուղարկում, և արդյունքը հաշվարկվում է որպես, օրինակ, դրանց գումարի հեշ, հարմար չէ: Այս դեպքում վերջին խաղացողը կարող է, ընտրելով իր պատահականությունը, վերահսկել, թե ինչ արդյունք կունենա: Սա է պատճառը, որ օգտագործվում է շատ լայնորեն օգտագործվող commit-reveal օրինաչափությունը: Մասնակիցները սկզբում ուղարկում են հեշեր իրենց պատահականներից (կոմիտացիաներ), իսկ հետո իրենք բացում են պատահականները (բացահայտում): «Բացահայտման» փուլը սկսվում է միայն անհրաժեշտ պարտավորությունները հավաքելուց հետո, այնպես որ մասնակիցները կարող են ուղարկել հենց պատահական հեշը, որից նրանք ավելի վաղ ուղարկել են: Հիմա եկեք այս ամենը միասին դնենք բլոկի պարամետրերի հետ, և ավելի լավ, քան ապագայից վերցվածը (պատահականությունը կարելի է գտնել միայն ապագա բլոկներից մեկում), իսկ վոյլա - պատահականությունը պատրաստ է: Այժմ ցանկացած խաղացող ազդում է ստացված պատահականության վրա և կարող է «հաղթել» չարամիտ BP-ին` հաղթահարելով այն իր, նախապես անհայտ, պատահականությամբ... Կարող եք նաև պաշտպանություն ավելացնել արձանագրությունը սաբոտաժից՝ չբացելով այն բացահայտման փուլում. Պահանջելով, որ գործարքին կցվի որոշակի գումար՝ երաշխիքային ավանդ, որը կվերադարձվի միայն բացահայտման ընթացակարգի ընթացքում։ Այս դեպքում կատարելն ու չբացահայտելը անշահավետ կլինի։

Լավ փորձ էր, և նման սխեմաներ կան նաև խաղային DApp-ներում, բայց ավաղ, սա կրկին բավարար չէ։ Այժմ ոչ միայն հանքափորը, այլեւ արձանագրության ցանկացած մասնակից կարող է ազդել արդյունքի վրա։ Դեռևս հնարավոր է վերահսկել արժեքը ինքնին, ավելի քիչ փոփոխականությամբ և գնով, բայց, ինչպես հանքագործի դեպքում, եթե խաղարկության արդյունքներն ավելի արժեքավոր են, քան 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 միավորներ ստանալուց հետո ամբողջ ֆունկցիան կարող է վերականգնվել։
Լավ բացատրություն է տրված Վիքիփեդիա, ազատ հանրագիտարան բայց դրա հետ խաղալը գործնականում ձեր գլխում արձանագրությունը խաղալու համար օգտակար է Demo էջ.

Եթե ​​FSSS (Fiat-Shamir Secret Sharing) սխեման կիրառելի լիներ իր մաքուր տեսքով, այն կլիներ անխորտակելի PVRB: Իր ամենապարզ ձևով արձանագրությունը կարող է այսպիսի տեսք ունենալ.

• Յուրաքանչյուր մասնակից ստեղծում է իր սեփական պատահականությունը և դրանից բաժնետոմսերը բաշխում է մյուս մասնակիցներին
• Յուրաքանչյուր մասնակից բացահայտում է մյուս մասնակիցների գաղտնիքների իր մասը
• Եթե ​​մասնակիցն ունի M-ից ավելի բաժնետոմսեր, ապա այս մասնակցի թիվը կարող է հաշվարկվել, և այն կլինի եզակի՝ անկախ բացահայտված մասնակիցների շարքից։
• Բացահայտված պատահականությունների համադրությունը ցանկալի PVRB է

Այստեղ անհատ մասնակիցն այլևս չի ազդում արձանագրության արդյունքների վրա, բացառությամբ այն դեպքերի, երբ պատահականության բացահայտման շեմի ձեռքբերումը կախված է բացառապես նրանից: Հետևաբար, այս արձանագրությունը, եթե առկա է արձանագրության վրա աշխատող և հասանելի RP-ների պահանջվող համամասնությունը, աշխատում է՝ իրականացնելով կրիպտոգրաֆիկ ուժի պահանջները և դիմացկուն լինելով «վերջին դերակատարի» խնդրին:

Սա կարող է լինել իդեալական տարբերակ, այս PVRB սխեման, որը հիմնված է Fiat-Shamir գաղտնի փոխանակման վրա, նկարագրված է օրինակ. սա է հոդված. Բայց, ինչպես նշվեց վերևում, եթե դուք փորձեք այն կիրառել բլոկչեյնում, տեխնիկական սահմանափակումներ են հայտնվում: Ահա EOS խելացի պայմանագրում արձանագրության թեստային ներդրման օրինակ և դրա ամենակարևոր մասը՝ հրապարակված բաժնետոմսի մասնակցի ստուգումը. կոդը. Կոդից կարող եք տեսնել, որ ապացույցի վավերացումը պահանջում է մի քանի սկալային բազմապատկումներ, և օգտագործված թվերը շատ մեծ են: Պետք է հասկանալ, որ բլոկչեյններում ստուգումը տեղի է ունենում այն ​​պահին, երբ բլոկ արտադրողը մշակում է գործարքը, և ընդհանրապես, ցանկացած մասնակից պետք է հեշտությամբ ստուգի արձանագրության ճիշտությունը, ուստի ստուգման գործառույթի արագության պահանջները շատ լուրջ են: . Այս տարբերակում տարբերակն անարդյունավետ էր, քանի որ ստուգումը չէր տեղավորվում գործարքի սահմանաչափի մեջ (0.5 վայրկյան):

Ստուգման արդյունավետությունը բլոկչեյնում, ընդհանուր առմամբ, գաղտնագրման առաջադեմ սխեմաների օգտագործման կարևորագույն պահանջներից մեկն է: Ապացույցների ստեղծում, հաղորդագրությունների պատրաստում. այս ընթացակարգերը կարող են իրականացվել շղթայից դուրս և կատարել բարձր արդյունավետությամբ համակարգիչներում, սակայն ստուգումը հնարավոր չէ շրջանցել. սա ևս մեկ կարևոր պահանջ է PVRB-ի համար:

PVRB և շեմային ստորագրություններ

Ծանոթանալով գաղտնի փոխանակման սխեմային՝ մենք հայտնաբերեցինք արձանագրությունների մի ամբողջ դաս՝ միավորված «շեմ» բանալի բառով։ Երբ որոշ տեղեկատվության բացահայտումը պահանջում է N-ից M ազնիվ մասնակիցների մասնակցություն, իսկ ազնիվ մասնակիցների բազմությունը կարող է լինել N-ի կամայական ենթաբազմություն, մենք խոսում ենք «շեմային» սխեմաների մասին: Հենց նրանք են մեզ թույլ տալիս զբաղվել «վերջին դերակատարի» խնդրով, հիմա եթե հարձակվողը չբացահայտի գաղտնիքի իր մասը, նրա փոխարեն դա կանի մեկ այլ, ազնիվ մասնակից։ Այս սխեմաները թույլ են տալիս համաձայնություն մեկ և միայն մեկ իմաստի շուրջ, նույնիսկ եթե արձանագրությունը սաբոտաժի ենթարկվի որոշ մասնակիցների կողմից:

Դետերմինիստական ​​ստորագրությունների և շեմերի սխեմաների համադրությունը հնարավորություն տվեց մշակել PVRB-ի իրականացման համար շատ հարմար և խոստումնալից սխեմա. սրանք դետերմինիստական ​​շեմային ստորագրություններ են: Այստեղ հոդված շեմային ստորագրությունների տարբեր օգտագործման մասին, և ահա ևս մեկ լավը վաղուց կարդացած Dash-ից։

Վերջին հոդվածը նկարագրում է BLS ստորագրությունները (BLS նշանակում է Boneh-Lynn-Sacham, այստեղ հոդված), որոնք ունեն ծրագրավորողների համար շատ կարևոր և չափազանց հարմար որակ՝ հանրային, գաղտնի, հանրային բանալիներ և BLS ստորագրությունները կարող են համակցվել միմյանց հետ՝ օգտագործելով պարզ մաթեմատիկական գործողություններ, մինչդեռ դրանց համակցությունները մնում են վավեր բանալիներ և ստորագրություններ՝ թույլ տալով հեշտությամբ համախմբել շատերը։ ստորագրությունները մեկում և շատ հանրային բանալիներ մեկի մեջ: Դրանք նաև դետերմինիստական ​​են և նույն արդյունքն են տալիս նույն մուտքային տվյալների համար: Այս որակի շնորհիվ BLS ստորագրությունների համակցություններն ինքնին վավեր բանալիներ են, ինչը թույլ է տալիս իրականացնել մի տարբերակ, որտեղ N մասնակիցներից M-ն արտադրում է մեկ և միայն մեկ ստորագրություն, որը որոշիչ է, հրապարակայնորեն ստուգելի և անկանխատեսելի, մինչև այն բացվի 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 է, որը կատարվում է վիրտուալ մեքենայի միջոցով: Կրիպտոգրաֆիկ գործառույթները չեն իրականացվում բնիկ (դեռևս), և աշխատում են տասնյակ անգամ ավելի դանդաղ, քան սովորական գաղտնագրային գրադարանները: Շատ արձանագրություններ չեն բավարարում պահանջներին՝ հիմնվելով միայն առանցքային ծավալի վրա, օրինակ՝ 1024 և 2048 բիթ RSA-ի համար, 4-8 անգամ ավելի մեծ, քան ստանդարտ գործարքի ստորագրությունը Bitcoin-ում և Ethereum-ում:

Իրականացումների առկայությունը ծրագրավորման տարբեր լեզուներում նույնպես դեր է խաղում, որոնցից քիչ են, հատկապես նոր արձանագրությունների համար: Համաձայնության մեջ ինտեգրվելու տարբերակը պահանջում է պլատֆորմի լեզվով արձանագրություն գրել, այնպես որ դուք պետք է ծածկագիր փնտրեք Go-ում` geth-ում, Rust-ում` Parity-ում, C++-ում` EOS-ում: Բոլորը ստիպված կլինեն փնտրել JavaScript-ի կոդը, և քանի որ JavaScript-ն ու գաղտնագրությունը առանձնապես մտերիմ ընկերներ չեն, WebAssembly-ն կօգնի, որն այժմ հաստատ հավակնում է լինել ինտերնետի հաջորդ կարևոր ստանդարտը:

Ամփոփում

Հուսով եմ նախորդում Հոդված Ինձ հաջողվեց համոզել ձեզ, որ բլոկչեյնի վրա պատահական թվեր ստեղծելը կարևոր է ապակենտրոնացված ցանցերի կյանքի շատ ասպեկտների համար, և այս հոդվածով ես ցույց տվեցի, որ այս խնդիրը չափազանց հավակնոտ է և բարդ, բայց լավ լուծումներ արդեն կան: Ընդհանուր առմամբ, արձանագրության վերջնական ձևավորումը հնարավոր է միայն զանգվածային թեստեր անցկացնելուց հետո, որոնք հաշվի են առնում բոլոր ասպեկտները՝ կարգավորումից մինչև անսարքության էմուլյացիա, այնպես որ դուք դժվար թե պատրաստի բաղադրատոմսեր գտնեք թիմային սպիտակ թղթերում և հոդվածներում, և մենք, իհարկե, չենք անի: Որոշեք հաջորդ կամ երկու տարվա ընթացքում, գրեք «արա դա այս կերպ, ճիշտ ճիշտ»:

Ցտեսություն, մեր PVRB-ի համար մշակվող բլոկչեյնում Հայա, մենք որոշեցինք օգտագործել շեմային BLS ստորագրությունները, մենք նախատեսում ենք PVRB-ն իրականացնել կոնսենսուսի մակարդակով, քանի որ խելացի պայմանագրերում ստուգումը անվտանգության ընդունելի մակարդակով դեռ հնարավոր չէ: Հնարավոր է, որ մենք միանգամից երկու սխեմա օգտագործենք. նախ՝ թանկարժեք գաղտնի փոխանակում երկարաժամկետ random_seed ստեղծելու համար, այնուհետև մենք այն օգտագործում ենք որպես հիմք բարձր հաճախականության պատահական գեներացիայի համար՝ օգտագործելով որոշիչ շեմային BLS ստորագրությունները, գուցե մենք սահմանափակվենք միայն սխեմաներից մեկը. Ցավոք, նախօրոք հնարավոր չէ ասել, թե ինչպիսին կլինի արձանագրությունը, միակ լավն այն է, որ ինչպես գիտության մեջ, այնպես էլ ինժեներական խնդիրներում, արդյունք է նաև բացասական արդյունքը, և խնդրի լուծման յուրաքանչյուր նոր փորձ ևս մեկ քայլ է։ խնդրի հետ կապված բոլորի հետազոտությունը: Բիզնեսի պահանջները բավարարելու համար մենք լուծում ենք կոնկրետ գործնական խնդիր՝ տրամադրելով խաղային հավելվածներին էնտրոպիայի հուսալի աղբյուր, այնպես որ մենք պետք է ուշադրություն դարձնենք նաև բուն բլոկչեյնին, մասնավորապես՝ շղթայի վերջնականության և ցանցի կառավարման հարցերին:

Եվ չնայած մենք դեռ չենք տեսնում ապացուցված դիմացկուն PVRB բլոկչեյններում, որը բավական ժամանակ կօգտագործվեր իրական հավելվածների, բազմաթիվ աուդիտների, բեռների և, իհարկե, իրական հարձակումների միջոցով փորձարկվելու համար, բայց հնարավոր ուղիների քանակը հաստատում է, որ կա լուծում, և այս ալգորիթմներից որն ի վերջո կլուծի խնդիրը: Մենք ուրախ կլինենք կիսվել արդյունքներով և շնորհակալություն հայտնել մյուս թիմերին, որոնք նույնպես աշխատում են այս հարցի վրա, հոդվածների և կոդի համար, որոնք թույլ են տալիս ինժեներներին երկու անգամ չոտք դնել նույն փոցխի վրա:

Այսպիսով, երբ հանդիպում եք ապակենտրոնացված պատահական նախագծող ծրագրավորողի, եղեք ուշադիր և հոգատար և անհրաժեշտության դեպքում հոգեբանական օգնություն ցուցաբերեք :)

Source: www.habr.com