પરિચય

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

ક્રિપ્ટોગ્રાફીમાંથી એકદમ મજબૂત સાઇફરની વિભાવનાની જેમ, વાસ્તવિક "જાહેર રીતે ચકાસી શકાય તેવા રેન્ડમ બીકન" (ત્યારબાદ PVRB) પ્રોટોકોલ્સ માત્ર આદર્શ યોજનાની શક્ય તેટલી નજીક જવાનો પ્રયાસ કરે છે, કારણ કે વાસ્તવિક નેટવર્ક્સમાં તે તેના શુદ્ધ સ્વરૂપમાં લાગુ પડતું નથી: એક બીટ પર સખત રીતે સંમત થવું જરૂરી છે, ત્યાં ઘણા બધા રાઉન્ડ હોવા જોઈએ, અને બધા સંદેશાઓ એકદમ ઝડપી અને હંમેશા વિતરિત હોવા જોઈએ. અલબત્ત, વાસ્તવિક નેટવર્ક્સમાં આ કેસ નથી. તેથી, આધુનિક બ્લોકચેનમાં ચોક્કસ કાર્યો માટે PVRB ની રચના કરતી વખતે, પરિણામી અવ્યવસ્થિતતા અને ક્રિપ્ટોગ્રાફિક શક્તિને નિયંત્રિત કરવાની અશક્યતા ઉપરાંત, ઘણી વધુ સંપૂર્ણ રીતે સ્થાપત્ય અને તકનીકી સમસ્યાઓ ઊભી થાય છે.

PVRB માટે, બ્લોકચેન એ આવશ્યકપણે એક સંચાર માધ્યમ છે જેમાં સંદેશા = વ્યવહારો. આ તમને નેટવર્ક સમસ્યાઓ, સંદેશાઓની ડિલિવરી ન કરવી, મિડલવેર સાથેની સમસ્યાઓથી આંશિક રીતે અમૂર્ત કરવાની મંજૂરી આપે છે - આ બધા જોખમો વિકેન્દ્રિત નેટવર્ક દ્વારા ધારવામાં આવે છે, અને PVRB માટે તેનું મુખ્ય મૂલ્ય પહેલાથી મોકલેલા વ્યવહારને રદબાતલ અથવા ભ્રષ્ટ કરવાની અસમર્થતા છે - આ કરે છે. સહભાગીઓને પ્રોટોકોલમાં ભાગ લેવાનો ઇનકાર કરવાની મંજૂરી આપશો નહીં, સિવાય કે તેઓ સર્વસંમતિ પર સફળ હુમલો કરે. સુરક્ષાનું આ સ્તર સ્વીકાર્ય છે, તેથી PVRB એ મુખ્ય બ્લોકચેન સાંકળ જેટલી જ હદ સુધી સહભાગીઓની મિલીભગત સામે પ્રતિરોધક હોવું જોઈએ. ઉપરાંત, આ સંકેત આપે છે કે PVRB એ સર્વસંમતિનો ભાગ હોવો જોઈએ જો નેટવર્ક મુખ્ય બ્લોકચેન પર સંમત થાય, પછી ભલે તે એકમાત્ર વાજબી પરિણામ રેન્ડમ પર પણ સંમત હોય. અથવા, PVRB એ સ્માર્ટ કોન્ટ્રાક્ટ દ્વારા અમલમાં મૂકાયેલ એક સ્વતંત્ર પ્રોટોકોલ છે જે બ્લોકચેન અને બ્લોક્સના સંદર્ભમાં અસુમેળ રીતે કાર્ય કરે છે. બંને પદ્ધતિઓમાં તેમના ફાયદા અને ગેરફાયદા છે, અને તેમની વચ્ચેની પસંદગી અત્યંત બિન-તુચ્છ છે.

PVRB ને અમલમાં મૂકવાની બે રીતો

ચાલો PVRB ના અમલીકરણ માટેના બે વિકલ્પોનું વધુ વિગતવાર વર્ણન કરીએ - એકલ સંસ્કરણ, જે બ્લોકચેનથી સ્વતંત્ર સ્માર્ટ કોન્ટ્રાક્ટનો ઉપયોગ કરીને કામ કરે છે, અને સર્વસંમતિ-સંકલિત સંસ્કરણ, પ્રોટોકોલમાં બનેલ છે, જે મુજબ નેટવર્ક બ્લોકચેન પર સંમત થાય છે અને વ્યવહારોનો સમાવેશ કરવો. તમામ કિસ્સાઓમાં, મારો મતલબ લોકપ્રિય બ્લોકચેન એંજીન છે: Ethereum, EOS, અને તેઓ જે રીતે સ્માર્ટ કોન્ટ્રાક્ટ હોસ્ટ કરે છે અને પ્રક્રિયા કરે છે તે રીતે તેમના જેવા જ.

એકલ કરાર

આ સંસ્કરણમાં, PVRB એ એક સ્માર્ટ કોન્ટ્રાક્ટ છે જે રેન્ડમ ઉત્પાદકોના વ્યવહારો સ્વીકારે છે (ત્યારબાદ આરપી તરીકે ઓળખાય છે), તેમની પ્રક્રિયા કરે છે, પરિણામોને જોડે છે અને પરિણામે, ચોક્કસ મૂલ્ય પર પહોંચે છે જે કોઈપણ વપરાશકર્તા આ કરારમાંથી પ્રાપ્ત કરી શકે છે. આ મૂલ્ય સીધા કરારમાં સંગ્રહિત ન હોઈ શકે, પરંતુ તે ફક્ત ડેટા દ્વારા જ રજૂ કરવામાં આવે છે જેમાંથી પરિણામી રેન્ડમનું એક અને માત્ર એક મૂલ્ય નિર્ધારિત રીતે મેળવી શકાય છે. આ સ્કીમમાં, RPs બ્લોકચેનના વપરાશકારો છે, અને કોઈપણને જનરેશન પ્રક્રિયામાં ભાગ લેવાની મંજૂરી આપી શકાય છે.

એકલ-કોન્ટ્રાક્ટ સાથેનો વિકલ્પ સારો છે:

• પોર્ટેબિલિટી (કોન્ટ્રાક્ટને બ્લોકચેનથી બ્લોકચેનમાં ખેંચી શકાય છે)
• અમલીકરણ અને પરીક્ષણની સરળતા (કરાર લખવા અને પરીક્ષણ કરવા માટે સરળ છે)
• આર્થિક યોજનાઓના અમલીકરણમાં સગવડ (તમારું પોતાનું ટોકન બનાવવું સરળ છે, જેનું તર્ક PVRB ના હેતુઓને પૂર્ણ કરે છે)
• પહેલાથી કાર્યરત બ્લોકચેન પર લોન્ચ થવાની સંભાવના

તેના ગેરફાયદા પણ છે:

• કમ્પ્યુટિંગ સંસાધનો, ટ્રાન્ઝેક્શન વોલ્યુમ અને સ્ટોરેજ પર મજબૂત મર્યાદાઓ (બીજા શબ્દોમાં, cpu/mem/io)
• કરારની અંદર કામગીરી પર પ્રતિબંધો (બધી સૂચનાઓ ઉપલબ્ધ નથી, બાહ્ય પુસ્તકાલયોને કનેક્ટ કરવું મુશ્કેલ છે)
• ટ્રાન્ઝેક્શન કરતાં વધુ ઝડપથી મેસેજિંગ ગોઠવવામાં અસમર્થતા બ્લોકચેનમાં સમાવિષ્ટ છે

આ વિકલ્પ PVRB ને અમલમાં મૂકવા માટે યોગ્ય છે જેને હાલના નેટવર્ક પર ચલાવવાની જરૂર છે, તેમાં જટિલ ક્રિપ્ટોગ્રાફી શામેલ નથી અને મોટી સંખ્યામાં ક્રિયાપ્રતિક્રિયાઓની જરૂર નથી.

સર્વસંમતિ-સંકલિત

આ સંસ્કરણમાં, PVRB બ્લોકચેન નોડ કોડમાં લાગુ કરવામાં આવે છે, બિલ્ટ-ઇન અથવા બ્લોકચેન નોડ્સ વચ્ચેના સંદેશાઓના વિનિમય સાથે સમાંતર ચાલે છે. પ્રોટોકોલના પરિણામો સીધા ઉત્પાદિત બ્લોક્સમાં લખવામાં આવે છે, અને પ્રોટોકોલ સંદેશાઓ નોડ્સ વચ્ચેના p2p નેટવર્ક પર મોકલવામાં આવે છે. કારણ કે પ્રોટોકોલ બ્લોક્સમાં લખવામાં આવતી સંખ્યાઓમાં પરિણમે છે, નેટવર્કે તેમના પર સર્વસંમતિ સુધી પહોંચવું આવશ્યક છે. આનો અર્થ એ છે કે PVRB સંદેશાઓ, જેમ કે વ્યવહારો, નોડ્સ દ્વારા માન્ય હોવા જોઈએ અને બ્લોક્સમાં શામેલ હોવા જોઈએ જેથી કરીને કોઈપણ નેટવર્ક સહભાગી PVRB પ્રોટોકોલનું પાલન માન્ય કરી શકે. આ આપમેળે અમને સ્પષ્ટ ઉકેલ તરફ દોરી જાય છે - જો નેટવર્ક બ્લોક અને તેમાં વ્યવહારો વિશે સર્વસંમતિ પર સંમત થાય, તો PVRB સર્વસંમતિનો ભાગ હોવો જોઈએ, અને એકલા પ્રોટોકોલ નહીં. અન્યથા, શક્ય છે કે બ્લોક સર્વસંમતિના દૃષ્ટિકોણથી માન્ય હોય, પરંતુ PVRB પ્રોટોકોલનું પાલન કરવામાં આવતું નથી, અને PVRB દૃષ્ટિકોણથી બ્લોક સ્વીકારી શકાતો નથી. તેથી જો "સહમતિ-સંકલિત" વિકલ્પ પસંદ કરવામાં આવે, તો PVRB સર્વસંમતિનો મહત્વપૂર્ણ ભાગ બની જાય છે.

નેટવર્ક સર્વસંમતિ સ્તરે PVRB અમલીકરણનું વર્ણન કરતી વખતે, કોઈ પણ રીતે અંતિમ મુદ્દાઓને ટાળી શકે નહીં. અંતિમતા એ નિર્ધારિત સંમતિમાં વપરાતી પદ્ધતિ છે જે બ્લોક (અને તે તરફ દોરી જતી સાંકળ) માં તાળું મારે છે જે અંતિમ છે અને સમાંતર કાંટો આવે તો પણ તેને ક્યારેય ફેંકી દેવામાં આવશે નહીં. ઉદાહરણ તરીકે, બિટકોઇનમાં આવી કોઈ પદ્ધતિ નથી - જો તમે વધુ જટિલતાની સાંકળ પ્રકાશિત કરો છો, તો તે સાંકળોની લંબાઈને ધ્યાનમાં લીધા વિના કોઈપણ ઓછી જટિલને બદલશે. અને EOS માં, ઉદાહરણ તરીકે, અંતિમ એ કહેવાતા લાસ્ટ ઈરવર્સિબલ બ્લોક્સ છે, જે સરેરાશ દર 432 બ્લોકમાં દેખાય છે (12*21 + 12*15, પ્રી-વોટ + પ્રી-કમિટ). આ પ્રક્રિયા અનિવાર્યપણે 2/3 બ્લોક-ઉત્પાદકો (ત્યારબાદ બીપી તરીકે ઓળખાય છે) સહીઓની રાહ જોઈ રહી છે. જ્યારે ફોર્ક્સ દેખાય છે જે છેલ્લા LIB કરતા જૂના હોય છે, ત્યારે તે ખાલી કાઢી નાખવામાં આવે છે. આ મિકેનિઝમ એ બાંયધરી આપવાનું શક્ય બનાવે છે કે ટ્રાન્ઝેક્શન બ્લોકચેનમાં શામેલ છે અને તે ક્યારેય પાછું ખેંચવામાં આવશે નહીં, પછી ભલે તે હુમલાખોર પાસે ગમે તે સંસાધનો હોય. ઉપરાંત, અંતિમ બ્લોક્સ હાઇપરલેજર, ટેન્ડરમિન્ટ અને અન્ય pBFT-આધારિત સર્વસંમતિમાં 2/3 BP દ્વારા હસ્તાક્ષરિત બ્લોક્સ છે. ઉપરાંત, સર્વસંમતિ માટે અંતિમતાને સુનિશ્ચિત કરવા માટે પ્રોટોકોલ બનાવવાનો અર્થ થાય છે, કારણ કે તે બ્લોક્સના ઉત્પાદન અને પ્રકાશન સાથે અસુમેળ રીતે કામ કરી શકે છે. અહીં એક સારું છે લેખ Ethereum માં અંતિમતા વિશે.

વપરાશકર્તાઓ માટે અંતિમતા અત્યંત મહત્વપૂર્ણ છે, જેઓ તેના વિના પોતાને "ડબલ ખર્ચ" હુમલાનો ભોગ બની શકે છે, જ્યાં BP "હોલ્ડ" કરે છે, અને નેટવર્ક દ્વારા સારો વ્યવહાર "જોયા" પછી તેને પ્રકાશિત કરે છે. જો ત્યાં કોઈ અંતિમતા નથી, તો પછી પ્રકાશિત ફોર્ક બ્લોકને "ખરાબ" ફોર્કથી બીજા સાથે "સારા" વ્યવહાર સાથે બદલે છે, જેમાં સમાન ભંડોળ હુમલાખોરના સરનામાં પર સ્થાનાંતરિત થાય છે. PVRB ના કિસ્સામાં, અંતિમતા માટેની આવશ્યકતાઓ વધુ કડક છે, કારણ કે PVRB માટે ફોર્ક્સ બનાવવાનો અર્થ એ છે કે હુમલાખોરને સૌથી વધુ નફાકારક એક પ્રકાશિત કરવા માટે ઘણા રેન્ડમ વિકલ્પો તૈયાર કરવાની તક, અને સંભવિત હુમલાના સમયને મર્યાદિત કરવો એ છે. સારો ઉકેલ.

તેથી, શ્રેષ્ઠ વિકલ્પ PVRB અને અંતિમતાને એક પ્રોટોકોલમાં જોડવાનો છે - પછી અંતિમ બ્લોક = અંતિમ રેન્ડમ, અને આ તે જ છે જે આપણે મેળવવાની જરૂર હતી. હવે ખેલાડીઓ N સેકન્ડમાં ગેરંટીકૃત રેન્ડમ પ્રાપ્ત કરશે, અને ખાતરી કરી શકાય છે કે તેને પાછું ફેરવવું અથવા તેને ફરીથી ચલાવવું અશક્ય છે.

સર્વસંમતિ-સંકલિત વિકલ્પ સારો છે:

• બ્લોક્સના ઉત્પાદનના સંબંધમાં અસુમેળ અમલીકરણની શક્યતા - બ્લોક્સનું ઉત્પાદન હંમેશની જેમ કરવામાં આવે છે, પરંતુ તેની સાથે સમાંતર, PVRB પ્રોટોકોલ કામ કરી શકે છે, જે દરેક બ્લોક માટે રેન્ડમનેસ ઉત્પન્ન કરતું નથી.
• સ્માર્ટ કોન્ટ્રાક્ટ પર લાદવામાં આવેલા નિયંત્રણો વિના, ભારે સંકેતલિપીનો પણ અમલ કરવાની ક્ષમતા
• ટ્રાન્ઝેક્શન કરતાં વધુ ઝડપથી સંદેશાઓના વિનિમયને ગોઠવવાની ક્ષમતા બ્લોકચેનમાં શામેલ છે, ઉદાહરણ તરીકે, પ્રોટોકોલનો ભાગ નેટવર્ક પર સંદેશાઓનું વિતરણ કર્યા વિના નોડ્સ વચ્ચે કામ કરી શકે છે.

તેના ગેરફાયદા પણ છે:

• પરીક્ષણ અને વિકાસમાં મુશ્કેલીઓ - તમારે નેટવર્ક ભૂલો, ગુમ થયેલ ગાંઠો, નેટવર્ક હાર્ડ ફોર્કનું અનુકરણ કરવું પડશે
• અમલીકરણ ભૂલોને નેટવર્ક હાર્ડફોર્કની જરૂર છે

PVRB ના અમલીકરણની બંને પદ્ધતિઓમાં જીવનનો અધિકાર છે, પરંતુ આધુનિક બ્લોકચેનમાં સ્માર્ટ કોન્ટ્રાક્ટ પર અમલીકરણ હજુ પણ કોમ્પ્યુટિંગ સંસાધનોમાં ખૂબ મર્યાદિત છે, અને ગંભીર સંકેતલિપીમાં કોઈપણ સંક્રમણ ઘણીવાર અશક્ય છે. અને અમને ગંભીર સંકેતલિપીની જરૂર પડશે, જે નીચે દર્શાવવામાં આવશે. જો કે આ સમસ્યા સ્પષ્ટપણે અસ્થાયી છે, ઘણી સમસ્યાઓ ઉકેલવા માટે કરારોમાં ગંભીર સંકેતલિપીની જરૂર છે, અને તે ધીમે ધીમે દેખાઈ રહી છે (ઉદાહરણ તરીકે, Ethereum માં zkSNARKs માટે સિસ્ટમ કરાર)

બ્લોકચેન, જે પારદર્શક અને વિશ્વસનીય પ્રોટોકોલ મેસેજિંગ ચેનલ પ્રદાન કરે છે, તે મફતમાં કરતું નથી. કોઈપણ વિકેન્દ્રિત પ્રોટોકોલમાં સિબિલ હુમલાની સંભાવનાને ધ્યાનમાં લેવી આવશ્યક છે; કોઈપણ ક્રિયા બહુવિધ એકાઉન્ટ્સના સંયુક્ત દળો દ્વારા થઈ શકે છે, તેથી, ડિઝાઇન કરતી વખતે, પ્રોટોકોલની મનસ્વી સંખ્યા બનાવવા માટે હુમલાખોરોની ક્ષમતાને ધ્યાનમાં લેવી જરૂરી છે. સહભાગીઓ મિલીભગતથી કામ કરે છે.

PVRB અને બ્લોક ચલો.

મેં જૂઠું નહોતું બોલ્યું જ્યારે મેં કહ્યું કે હજુ સુધી કોઈએ બ્લોકચેનમાં જુગારની ઘણી એપ્લિકેશનો દ્વારા ચકાસાયેલ સારા PVRBનો અમલ કર્યો નથી. તો પછી Ethereum અને EOS પર જુગારની આટલી બધી અરજીઓ ક્યાંથી આવે છે? આનાથી મને તેટલું જ આશ્ચર્ય થાય છે જેટલું તે તમને આશ્ચર્યચકિત કરે છે, તેઓને સંપૂર્ણ નિર્ધારિત વાતાવરણમાં આટલા બધા "સતત" રેન્ડમ ક્યાંથી મળ્યા?

બ્લોકચેનમાં રેન્ડમનેસ મેળવવાની મનપસંદ રીત એ છે કે બ્લોકમાંથી અમુક પ્રકારની "અણધારી" માહિતી લેવી અને તેના આધારે રેન્ડમ બનાવવી - ફક્ત એક અથવા વધુ મૂલ્યોને હેશ કરીને. આવી યોજનાઓની સમસ્યાઓ વિશે સારો લેખ અહીં. તમે બ્લોકમાં કોઈપણ "અણધારી" મૂલ્યો લઈ શકો છો, ઉદાહરણ તરીકે, બ્લોક હેશ, વ્યવહારોની સંખ્યા, નેટવર્ક જટિલતા અને અન્ય મૂલ્યો અગાઉથી અજાણ્યા છે. પછી તેમને હેશ કરો, એક અથવા વધુ, અને, સિદ્ધાંતમાં, તમારે વાસ્તવિક રેન્ડમ મેળવવું જોઈએ. તમે વ્હાઈટપેપરમાં પણ ઉમેરી શકો છો કે તમારી સ્કીમ “પોસ્ટ-ક્વોન્ટમ સુરક્ષિત” છે (કારણ કે ત્યાં ક્વોન્ટમ-પ્રૂફ હેશ ફંક્શન્સ છે :)).

પરંતુ પોસ્ટ-ક્વોન્ટમ સુરક્ષિત હેશ પણ પૂરતા નથી, અરે. PVRB માટેની આવશ્યકતાઓમાં રહસ્ય રહેલું છે, ચાલો હું તમને અગાઉના લેખમાંથી યાદ અપાવી દઉં:

1. પરિણામમાં સંભવિતપણે સમાન વિતરણ હોવું આવશ્યક છે, એટલે કે તે સંભવિતપણે મજબૂત સંકેતલિપી પર આધારિત હોવું જોઈએ.
2. પરિણામની કોઈપણ બિટ્સને નિયંત્રિત કરવી શક્ય નથી. પરિણામે, પરિણામની અગાઉથી આગાહી કરી શકાતી નથી.
3. તમે પ્રોટોકોલમાં ભાગ ન લઈને અથવા હુમલાના સંદેશાઓ સાથે નેટવર્કને ઓવરલોડ કરીને જનરેશન પ્રોટોકોલને તોડફોડ કરી શકતા નથી
4. ઉપરોક્ત તમામ અપ્રમાણિક પ્રોટોકોલ સહભાગીઓ (ઉદાહરણ તરીકે, 1/3 સહભાગીઓ) ની અનુમતિપાત્ર સંખ્યાની મિલીભગત માટે પ્રતિરોધક હોવા જોઈએ.

આ કિસ્સામાં, માત્ર જરૂરિયાત 1 પૂરી થાય છે, અને જરૂરિયાત 2 પૂરી થતી નથી. બ્લોકમાંથી અણધારી મૂલ્યોને હેશ કરીને, અમને એક સમાન વિતરણ અને સારા રેન્ડમ્સ મળશે. પરંતુ BP પાસે ઓછામાં ઓછું "બ્લોક પ્રકાશિત કરો કે નહીં" કરવાનો વિકલ્પ છે. આમ, BP ઓછામાં ઓછા બે રેન્ડમ વિકલ્પોમાંથી પસંદ કરી શકે છે: "પોતાના" અને જો કોઈ અન્ય બ્લોક બનાવે તો તે બહાર આવશે. BP અગાઉથી "સૂપ" કરી શકે છે જો તે બ્લોક પ્રકાશિત કરે તો શું થશે, અને તે કરવાનું કે નહીં તે ફક્ત નક્કી કરે છે. આમ, જ્યારે રમતા રમતા, ઉદાહરણ તરીકે, રૂલેટમાં “એક-વિષમ” અથવા “લાલ/કાળો”, તે જીત જોશે તો જ બ્લોક પ્રકાશિત કરી શકે છે. આનાથી ઉપયોગ કરવાની વ્યૂહરચના પણ બને છે, ઉદાહરણ તરીકે, બ્લોક હેશ "ભવિષ્યમાંથી" બિનકાર્યક્ષમ. આ કિસ્સામાં, તેઓ કહે છે કે “રેન્ડમનો ઉપયોગ કરવામાં આવશે, જે વર્તમાન ડેટાને હેશ કરીને અને ભવિષ્યના બ્લોકના હેશને ની ઊંચાઈ સાથે મેળવવામાં આવે છે, ઉદાહરણ તરીકે, N + 42, જ્યાં N એ વર્તમાન બ્લોકની ઊંચાઈ છે. આ યોજનાને થોડી મજબૂત બનાવે છે, પરંતુ હજુ પણ BP ને, ભલે ભવિષ્યમાં, બ્લોક રાખવા કે પ્રકાશિત કરવું તે પસંદ કરવા માટે પરવાનગી આપે છે.

આ કિસ્સામાં બીપી સૉફ્ટવેર વધુ જટિલ બને છે, પરંતુ વધુ નહીં. સરળ રીતે, જ્યારે કોઈ બ્લોકમાં કોઈ વ્યવહારને માન્ય કરવામાં આવે છે અને તેનો સમાવેશ કરવામાં આવે છે, ત્યારે જીત થશે કે કેમ તે જોવા માટે ઝડપી તપાસ કરવામાં આવે છે, અને, સંભવતઃ, જીતવાની ઉચ્ચ સંભાવના મેળવવા માટે એક વ્યવહારના પરિમાણોની પસંદગી. તે જ સમયે, આવા મેનીપ્યુલેશન્સ માટે સ્માર્ટ બીપી પકડવું લગભગ અશક્ય છે; દરેક વખતે તમે નવા સરનામાંનો ઉપયોગ કરી શકો છો અને શંકાને ઉત્તેજિત કર્યા વિના ધીમે ધીમે જીતી શકો છો.

તેથી બ્લોકમાંથી માહિતીનો ઉપયોગ કરવાની પદ્ધતિઓ PVRB ના સાર્વત્રિક અમલીકરણ તરીકે યોગ્ય નથી. મર્યાદિત સંસ્કરણમાં, શરતના કદ પરના નિયંત્રણો, ખેલાડીઓની સંખ્યા અને/અથવા KYC નોંધણી પરના નિયંત્રણો (એક ખેલાડીને બહુવિધ સરનામાંનો ઉપયોગ કરતા અટકાવવા) સાથે, આ યોજનાઓ નાની રમતો માટે કામ કરી શકે છે, પરંતુ વધુ કંઈ નથી.

PVRB અને કમિટ-રીવીલ.

ઠીક છે, હેશિંગ માટે આભાર અને ઓછામાં ઓછા બ્લોક હેશ અને અન્ય ચલોની સંબંધિત અણધારીતા. જો તમે ફ્રન્ટ-રનિંગ માઇનર્સની સમસ્યા હલ કરો છો, તો તમારે કંઈક વધુ યોગ્ય મેળવવું જોઈએ. ચાલો વપરાશકર્તાઓને આ યોજનામાં ઉમેરીએ - તેમને પણ રેન્ડમનેસને પ્રભાવિત કરવા દો: કોઈપણ તકનીકી સપોર્ટ કર્મચારી તમને કહેશે કે IT સિસ્ટમ્સમાં સૌથી રેન્ડમ વસ્તુ વપરાશકર્તાઓની ક્રિયાઓ છે :)

નિષ્કપટ યોજના, જ્યારે વપરાશકર્તાઓ ફક્ત રેન્ડમ નંબરો મોકલે છે અને પરિણામની ગણતરી કરવામાં આવે છે, ઉદાહરણ તરીકે, તેમના સરવાળાનો હેશ, તે યોગ્ય નથી. આ કિસ્સામાં, છેલ્લો ખેલાડી, તેની પોતાની રેન્ડમ પસંદ કરીને, પરિણામ શું આવશે તે નિયંત્રિત કરી શકે છે. આ જ કારણ છે કે ખૂબ જ વ્યાપકપણે ઉપયોગમાં લેવાતી કમિટ-રીવીલ પેટર્નનો ઉપયોગ થાય છે. સહભાગીઓ પ્રથમ તેમના રેન્ડમ્સ (કમિટ) માંથી હેશ મોકલે છે, અને પછી રેન્ડમ્સ જાતે ખોલે છે (જાહેર કરે છે). "જાહેર" તબક્કો જરૂરી કમિટ એકત્રિત કર્યા પછી જ શરૂ થાય છે, તેથી સહભાગીઓ બરાબર રેન્ડમ હેશ મોકલી શકે છે જેમાંથી તેઓએ અગાઉ મોકલ્યું હતું. હવે ચાલો આ બધું બ્લોકના પરિમાણો સાથે એકસાથે મૂકીએ, અને ભવિષ્યમાંથી લેવામાં આવેલા એક કરતાં વધુ સારું (રેન્ડમનેસ ફક્ત ભાવિ બ્લોક્સમાંના એકમાં જ મળી શકે છે), અને વોઇલા - રેન્ડમનેસ તૈયાર છે! હવે કોઈપણ ખેલાડી પરિણામી અવ્યવસ્થિતતાને પ્રભાવિત કરે છે, અને દૂષિત બીપીને તેની પોતાની, અગાઉથી અજાણી, રેન્ડમનેસ વડે ઓવરરાઇડ કરીને તેને "પરાજય" કરી શકે છે... તમે પ્રોટોકોલને જાહેરના તબક્કે ન ખોલીને તોડફોડ સામે રક્ષણ પણ ઉમેરી શકો છો - સરળ રીતે કમિટ કરતી વખતે ટ્રાન્ઝેક્શન સાથે ચોક્કસ રકમ જોડવાની આવશ્યકતા દ્વારા - એક સિક્યોરિટી ડિપોઝિટ, જે ફક્ત જાહેર કરવાની પ્રક્રિયા દરમિયાન જ પરત કરવામાં આવશે. આ કિસ્સામાં, પ્રતિબદ્ધ કરવું અને જાહેર ન કરવું તે નફાકારક રહેશે.

તે એક સારો પ્રયાસ હતો, અને આવી યોજનાઓ ગેમિંગ DApps માં પણ અસ્તિત્વમાં છે, પરંતુ અફસોસ, આ ફરીથી પૂરતું નથી. હવે માત્ર ખાણિયો જ નહીં, પણ પ્રોટોકોલમાં કોઈપણ સહભાગી પરિણામને પ્રભાવિત કરી શકે છે. ઓછી પરિવર્તનશીલતા સાથે અને કિંમતે મૂલ્યને નિયંત્રિત કરવું હજી પણ શક્ય છે, પરંતુ, ખાણિયોના કિસ્સામાં, જો ડ્રોઇંગના પરિણામો PVRB પ્રોટોકોલમાં ભાગ લેવા માટેની ફી કરતાં વધુ મૂલ્યવાન હોય, તો રેન્ડમ -ઉત્પાદક(RP) નક્કી કરી શકે છે કે શું જાહેર કરવું અને હજુ પણ ઓછામાં ઓછા બે રેન્ડમ વિકલ્પોમાંથી પસંદ કરી શકે છે.
પરંતુ જેઓ આચરણ કરે છે અને જાહેર કરતા નથી તેમને સજા કરવાનું શક્ય બન્યું છે, અને આ યોજના કામમાં આવશે. તેની સરળતા એ એક ગંભીર ફાયદો છે - વધુ ગંભીર પ્રોટોકોલ્સને વધુ શક્તિશાળી ગણતરીઓની જરૂર છે.

PVRB અને નિર્ણાયક હસ્તાક્ષરો.

આરપીને સ્યુડો-રેન્ડમ નંબર પ્રદાન કરવા દબાણ કરવાની બીજી રીત છે કે જો તે "પ્રીઇમેજ" સાથે પ્રદાન કરવામાં આવે તો તે પ્રભાવિત કરી શકશે નહીં - આ એક નિર્ણાયક હસ્તાક્ષર છે. આવી હસ્તાક્ષર, ઉદાહરણ તરીકે, RSA છે અને તે ECS નથી. જો RP પાસે ચાવીઓની જોડી છે: RSA અને ECC, અને તે તેની ખાનગી કી વડે ચોક્કસ મૂલ્ય પર હસ્તાક્ષર કરે છે, તો RSAના કિસ્સામાં તેને એક અને માત્ર એક જ હસ્તાક્ષર મળશે, અને ECSના કિસ્સામાં તે કોઈપણ સંખ્યા જનરેટ કરી શકે છે. વિવિધ માન્ય સહીઓ. આનું કારણ એ છે કે જ્યારે ECS હસ્તાક્ષર બનાવતી વખતે, સહી કરનાર દ્વારા પસંદ કરાયેલ રેન્ડમ નંબરનો ઉપયોગ કરવામાં આવે છે, અને તે કોઈપણ રીતે પસંદ કરી શકાય છે, જે સહી કરનારને અનેક હસ્તાક્ષરોમાંથી એક પસંદ કરવાની તક આપે છે. RSA ના કિસ્સામાં: "એક ઇનપુટ મૂલ્ય" + "એક કી જોડી" = "એક સહી". અન્ય RPને કઈ સહી મળશે તે અનુમાન લગાવવું અશક્ય છે, તેથી સમાન મૂલ્ય પર હસ્તાક્ષર કરનારા કેટલાક સહભાગીઓની RSA સહીઓ સાથે જોડીને નિર્ધારિત હસ્તાક્ષર સાથે PVRB ગોઠવી શકાય છે. ઉદાહરણ તરીકે, અગાઉના રેન્ડમ. આ યોજના ઘણા સંસાધનોની બચત કરે છે, કારણ કે સહીઓ પ્રોટોકોલ અનુસાર યોગ્ય વર્તનની પુષ્ટિ અને રેન્ડમનેસનો સ્ત્રોત છે.

જો કે, નિર્ધારિત હસ્તાક્ષરો સાથે પણ, યોજના હજુ પણ "છેલ્લા અભિનેતા" સમસ્યા માટે સંવેદનશીલ છે. છેલ્લો સહભાગી હજી પણ નક્કી કરી શકે છે કે સહી પ્રકાશિત કરવી કે નહીં, ત્યાંથી પરિણામને નિયંત્રિત કરી શકાય છે. તમે યોજનાને સંશોધિત કરી શકો છો, તેમાં બ્લોક હેશ ઉમેરી શકો છો, રાઉન્ડ બનાવી શકો છો જેથી પરિણામની અગાઉથી આગાહી કરી શકાય નહીં, પરંતુ આ બધી તકનીકો, ઘણા ફેરફારોને ધ્યાનમાં લેતા, હજી પણ સામૂહિક પર એક સહભાગીના પ્રભાવની સમસ્યાને વણઉકેલાયેલી છોડી દે છે. અવિશ્વસનીય વાતાવરણમાં પરિણમે છે અને માત્ર આર્થિક અને સમય મર્યાદાઓ હેઠળ કામ કરી શકે છે. વધુમાં, RSA કી (1024 અને 2048 બિટ્સ)નું કદ ઘણું મોટું છે, અને બ્લોકચેન વ્યવહારો માટેનું કદ અત્યંત મહત્વપૂર્ણ પરિમાણ છે. દેખીતી રીતે સમસ્યા હલ કરવાની કોઈ સરળ રીત નથી, ચાલો આગળ વધીએ.

PVRB અને ગુપ્ત શેરિંગ યોજનાઓ

ક્રિપ્ટોગ્રાફીમાં, એવી યોજનાઓ છે જે નેટવર્કને એક અને માત્ર એક PVRB મૂલ્ય પર સંમત થવાની મંજૂરી આપી શકે છે, જ્યારે આવી યોજનાઓ કેટલાક સહભાગીઓની કોઈપણ દૂષિત ક્રિયાઓ માટે પ્રતિરોધક છે. એક ઉપયોગી પ્રોટોકોલ જે તમારી જાતને પરિચિત કરવા યોગ્ય છે તે છે શમીરની ગુપ્ત શેરિંગ યોજના. તે ગુપ્ત (ઉદાહરણ તરીકે, ગુપ્ત કી) ને કેટલાક ભાગોમાં વિભાજીત કરવા અને આ ભાગોને N સહભાગીઓને વિતરિત કરવા માટે સેવા આપે છે. રહસ્યને એવી રીતે વિતરિત કરવામાં આવે છે કે N માંથી M ભાગો તેને પુનઃપ્રાપ્ત કરવા માટે પૂરતા છે, અને આ કોઈપણ M ભાગો હોઈ શકે છે. જો આંગળીઓ પર હોય, તો અજાણ્યા કાર્યનો ગ્રાફ ધરાવતા, સહભાગીઓ ગ્રાફ પર પોઈન્ટનું વિનિમય કરે છે, અને M પોઈન્ટ પ્રાપ્ત કર્યા પછી, સમગ્ર કાર્ય પુનઃસ્થાપિત કરી શકાય છે.
એક સરસ સમજૂતી આપવામાં આવી છે વિકી પરંતુ તમારા માથામાં પ્રોટોકોલ રમવા માટે વ્યવહારીક રીતે તેની સાથે રમવું ઉપયોગી છે ડેમો પાનું.

જો FSSS (ફિયાટ-શમીર સિક્રેટ શેરિંગ) સ્કીમ તેના શુદ્ધ સ્વરૂપમાં લાગુ થાય, તો તે અવિનાશી PVRB હશે. તેના સરળ સ્વરૂપમાં, પ્રોટોકોલ આના જેવો દેખાઈ શકે છે:

• દરેક સહભાગી પોતાનું રેન્ડમ જનરેટ કરે છે અને તેમાંથી અન્ય સહભાગીઓને શેરનું વિતરણ કરે છે
• દરેક સહભાગી અન્ય સહભાગીઓના રહસ્યોના તેના ભાગને જાહેર કરે છે
• જો કોઈ સહભાગી પાસે M કરતાં વધુ શેર હોય, તો આ સહભાગીની સંખ્યાની ગણતરી કરી શકાય છે, અને તે અનન્ય હશે, જાહેર કરાયેલા સહભાગીઓના સમૂહને ધ્યાનમાં લીધા વિના.
• જાહેર કરાયેલ રેન્ડમનું સંયોજન ઇચ્છિત PVRB છે

અહીં, વ્યક્તિગત સહભાગી હવે પ્રોટોકોલના પરિણામોને પ્રભાવિત કરતું નથી, સિવાય કે એવા કિસ્સાઓ કે જ્યાં રેન્ડમનેસ ડિસ્ક્લોઝર થ્રેશોલ્ડની સિદ્ધિ ફક્ત તેના પર નિર્ભર હોય છે. તેથી, આ પ્રોટોકોલ, જો પ્રોટોકોલ પર કામ કરતા RP નું જરૂરી પ્રમાણ હોય અને ઉપલબ્ધ હોય, તો કાર્ય કરે છે, ક્રિપ્ટોગ્રાફિક શક્તિ માટેની આવશ્યકતાઓને અમલમાં મૂકે છે અને "છેલ્લા અભિનેતા" સમસ્યા સામે પ્રતિરોધક છે.

આ એક આદર્શ વિકલ્પ હોઈ શકે છે, ફિઆટ-શમીર સિક્રેટ શેરિંગ પર આધારિત આ PVRB સ્કીમ ઉદાહરણ તરીકે વર્ણવવામાં આવી છે. આ લેખ પરંતુ, ઉપર જણાવ્યા મુજબ, જો તમે તેને બ્લોકચેનમાં હેડ-ઓન લાગુ કરવાનો પ્રયાસ કરો છો, તો તકનીકી મર્યાદાઓ દેખાય છે. અહીં ઇઓએસ સ્માર્ટ કોન્ટ્રાક્ટમાં પ્રોટોકોલના પરીક્ષણ અમલીકરણનું ઉદાહરણ અને તેનો સૌથી મહત્વપૂર્ણ ભાગ છે - પ્રકાશિત શેર સહભાગીને તપાસવું: કોડ. તમે કોડ પરથી જોઈ શકો છો કે પ્રૂફ વેલિડેશન માટે ઘણા સ્કેલર ગુણાકારની જરૂર પડે છે, અને વપરાયેલી સંખ્યાઓ ખૂબ મોટી છે. તે સમજવું જોઈએ કે બ્લોકચેનમાં, વેરિફિકેશન તે સમયે થાય છે જ્યારે બ્લોક-ઉત્પાદક ટ્રાન્ઝેક્શનની પ્રક્રિયા કરે છે, અને સામાન્ય રીતે, કોઈપણ સહભાગીએ સરળતાથી પ્રોટોકોલની શુદ્ધતા ચકાસવી જોઈએ, તેથી વેરિફાઈ ફંક્શનની ઝડપ માટેની આવશ્યકતાઓ ખૂબ ગંભીર છે. . આ વિકલ્પમાં, વિકલ્પ બિનઅસરકારક હોવાનું બહાર આવ્યું, કારણ કે ચકાસણી વ્યવહાર મર્યાદા (0.5 સેકન્ડ) માં બંધબેસતી ન હતી.

સામાન્ય રીતે, બ્લોકચેનમાં કોઈપણ અદ્યતન ક્રિપ્ટોગ્રાફિક યોજનાઓના ઉપયોગ માટે ચકાસણી કાર્યક્ષમતા એ સૌથી મહત્વપૂર્ણ આવશ્યકતાઓમાંની એક છે. પુરાવાઓ બનાવવા, સંદેશાઓ તૈયાર કરવા - આ પ્રક્રિયાઓ ઑફ-ચેન લઈ શકાય છે અને ઉચ્ચ-પ્રદર્શન કમ્પ્યુટર્સ પર કરી શકાય છે, પરંતુ ચકાસણીને બાયપાસ કરી શકાતી નથી - PVRB માટે આ બીજી મહત્વપૂર્ણ આવશ્યકતા છે.

PVRB અને થ્રેશોલ્ડ સહીઓ

ગુપ્ત વહેંચણી યોજનાથી પરિચિત થયા પછી, અમે કીવર્ડ “થ્રેશોલ્ડ” દ્વારા એકીકૃત પ્રોટોકોલનો આખો વર્ગ શોધી કાઢ્યો. જ્યારે કેટલીક માહિતી જાહેર કરવા માટે Nમાંથી M પ્રમાણિક સહભાગીઓની ભાગીદારીની આવશ્યકતા હોય છે, અને પ્રમાણિક સહભાગીઓનો સમૂહ N નો મનસ્વી સબસેટ હોઈ શકે છે, ત્યારે અમે "થ્રેશોલ્ડ" યોજનાઓની વાત કરીએ છીએ. તે તેઓ છે જે અમને "છેલ્લા અભિનેતા" સમસ્યાનો સામનો કરવાની મંજૂરી આપે છે, હવે જો હુમલાખોર તેના રહસ્યનો ભાગ જાહેર ન કરે, તો અન્ય, પ્રામાણિક સહભાગી તેના માટે તે કરશે. આ યોજનાઓ એક અને માત્ર એક જ અર્થ પર કરાર કરવાની મંજૂરી આપે છે, પછી ભલેને કેટલાક સહભાગીઓ દ્વારા પ્રોટોકોલને તોડફોડ કરવામાં આવી હોય.

નિર્ણાયક હસ્તાક્ષરો અને થ્રેશોલ્ડ યોજનાઓના સંયોજનથી PVRB ના અમલીકરણ માટે ખૂબ જ અનુકૂળ અને આશાસ્પદ યોજના વિકસાવવાનું શક્ય બન્યું - આ નિર્ધારિત થ્રેશોલ્ડ હસ્તાક્ષરો છે. અહીં લેખ થ્રેશોલ્ડ હસ્તાક્ષરના વિવિધ ઉપયોગો વિશે, અને અહીં એક બીજું સારું છે લાંબા વાંચન ડૅશમાંથી.

છેલ્લો લેખ BLS સહીઓનું વર્ણન કરે છે (BLS નો અર્થ બોનેહ-લિન-શચમ, જોયેલું લેખ), જે પ્રોગ્રામરો માટે ખૂબ જ મહત્વપૂર્ણ અને અત્યંત અનુકૂળ ગુણવત્તા ધરાવે છે - સાર્વજનિક, ગુપ્ત, સાર્વજનિક કીઓ અને BLS સહીઓ સરળ ગાણિતિક ક્રિયાઓનો ઉપયોગ કરીને એકબીજા સાથે જોડી શકાય છે, જ્યારે તેમના સંયોજનો માન્ય કી અને હસ્તાક્ષર રહે છે, જે તમને સરળતાથી એકત્ર કરવા દે છે. એકમાં સહીઓ અને એકમાં ઘણી સાર્વજનિક કી. તેઓ નિર્ણાયક પણ છે અને સમાન ઇનપુટ ડેટા માટે સમાન પરિણામ ઉત્પન્ન કરે છે. આ ગુણવત્તા માટે આભાર, BLS હસ્તાક્ષરોના સંયોજનો પોતે જ માન્ય કી છે, જે એક વિકલ્પના અમલીકરણ માટે પરવાનગી આપે છે જેમાં M ના N સહભાગીઓ એક અને માત્ર એક જ હસ્તાક્ષર ઉત્પન્ન કરે છે જે નિર્ધારિત, સાર્વજનિક રીતે ચકાસી શકાય તેવું અને અણધારી છે જ્યાં સુધી તે Mth દ્વારા ખોલવામાં ન આવે ત્યાં સુધી. સહભાગી

થ્રેશોલ્ડ BLS સહીઓવાળી યોજનામાં, દરેક સહભાગી BLS (ઉદાહરણ તરીકે, અગાઉની રેન્ડમ) નો ઉપયોગ કરીને કંઈક સહી કરે છે અને સામાન્ય થ્રેશોલ્ડ હસ્તાક્ષર ઇચ્છિત રેન્ડમ છે. BLS હસ્તાક્ષરોના ક્રિપ્ટોગ્રાફિક ગુણધર્મો રેન્ડમ ગુણવત્તા માટેની આવશ્યકતાઓને સંતોષે છે, થ્રેશોલ્ડ ભાગ "છેલ્લા-અભિનેતા" સામે રક્ષણ આપે છે, અને કીઓની અનન્ય સંયોજનતા ઘણા વધુ રસપ્રદ અલ્ગોરિધમ્સને અમલમાં મૂકવાનું શક્ય બનાવે છે જે પરવાનગી આપે છે, ઉદાહરણ તરીકે, પ્રોટોકોલ સંદેશાઓનું કાર્યક્ષમ એકત્રીકરણ. .

તેથી, જો તમે તમારા બ્લોકચેન પર PVRB બનાવી રહ્યા છો, તો તમે મોટા ભાગે BLS થ્રેશોલ્ડ સિગ્નેચર સ્કીમ સાથે સમાપ્ત થશો, ઘણા પ્રોજેક્ટ્સ પહેલેથી જ તેનો ઉપયોગ કરી રહ્યાં છે. ઉદાહરણ તરીકે, DFinity (અહીં બેન્ચમાર્ક કે જે સર્કિટનો અમલ કરે છે, અને અહીં ચકાસી શકાય તેવા ગુપ્ત શેરિંગનું ઉદાહરણ અમલીકરણ), અથવા Keep.network (અહીં તેમનું રેન્ડમ બીકન છે પીળો કાગળઅને અહીં ઉદાહરણ પ્રોટોકોલની સેવા આપતો સ્માર્ટ કોન્ટ્રાક્ટ).

PVRB નો અમલ

કમનસીબે, અમે હજુ પણ PVRB બ્લોકચેનમાં અમલમાં મૂકાયેલો તૈયાર પ્રોટોકોલ જોતા નથી જેણે તેની સુરક્ષા અને સ્થિરતા સાબિત કરી હોય. પ્રોટોકોલ પોતે તૈયાર હોવા છતાં, તકનીકી રીતે તેમને હાલના ઉકેલો પર લાગુ કરવું સરળ નથી. કેન્દ્રીયકૃત સિસ્ટમો માટે, PVRB નો અર્થ નથી, અને વિકેન્દ્રિત લોકો તમામ કમ્પ્યુટિંગ સંસાધનોમાં સખત રીતે મર્યાદિત છે: CPU, મેમરી, સ્ટોરેજ, I/O. PVRB ડિઝાઇન કરવું એ ઓછામાં ઓછા કેટલાક વ્યવહારુ બ્લોકચેન માટેની તમામ આવશ્યકતાઓને પૂર્ણ કરે તેવું કંઈક બનાવવા માટે વિવિધ પ્રોટોકોલનું સંયોજન છે. એક પ્રોટોકોલ વધુ કાર્યક્ષમ રીતે ગણતરી કરે છે, પરંતુ RPs વચ્ચે વધુ સંદેશાઓની જરૂર પડે છે, જ્યારે બીજાને બહુ ઓછા સંદેશાઓની જરૂર હોય છે, પરંતુ સાબિતી બનાવવી એ એક કાર્ય હોઈ શકે છે જેમાં દસ મિનિટ અથવા તો કલાકો પણ લાગે છે.

ગુણવત્તાયુક્ત PVRB પસંદ કરતી વખતે તમારે ધ્યાનમાં લેવાના પરિબળોની હું સૂચિ બનાવીશ:

• ક્રિપ્ટોગ્રાફિક તાકાત. તમારું PVRB સખત નિષ્પક્ષ હોવું જોઈએ, જેમાં એક પણ બીટને નિયંત્રિત કરવાની ક્ષમતા નથી. કેટલીક યોજનાઓમાં આ કેસ નથી, તેથી ક્રિપ્ટોગ્રાફરને કૉલ કરો
• "છેલ્લા અભિનેતા"ની સમસ્યા. તમારું PVRB એ હુમલાઓ માટે પ્રતિરોધક હોવું આવશ્યક છે જ્યાં એક અથવા વધુ RP ને નિયંત્રિત કરતો હુમલાખોર બેમાંથી એક પરિણામ પસંદ કરી શકે છે.
• પ્રોટોકોલ તોડફોડ સમસ્યા. તમારું PVRB એ હુમલાઓ માટે પ્રતિરોધક હોવું જોઈએ જ્યાં એક અથવા વધુ RPs ને નિયંત્રિત કરતો હુમલાખોર નક્કી કરે છે કે રેન્ડમ હોવું જોઈએ કે નહીં અને કાં તો ખાતરી આપી શકાય અથવા આને પ્રભાવિત કરવાની આપેલ સંભાવના સાથે
• સંદેશાઓની સંખ્યાની સમસ્યા. તમારા RP એ બ્લોકચેન પર ન્યૂનતમ સંદેશાઓ મોકલવા જોઈએ અને શક્ય તેટલી સિંક્રનસ ક્રિયાઓ ટાળવી જોઈએ જેમ કે "મેં કેટલીક માહિતી મોકલી છે, હું ચોક્કસ સહભાગીના પ્રતિસાદની રાહ જોઈ રહ્યો છું." p2p નેટવર્ક્સમાં, ખાસ કરીને ભૌગોલિક રીતે વિખરાયેલા, તમારે ઝડપી પ્રતિસાદ પર વિશ્વાસ ન કરવો જોઈએ
• કોમ્પ્યુટેશનલ જટિલતાની સમસ્યા. PVRB ઓન-ચેઈનના કોઈપણ તબક્કાની ચકાસણી અત્યંત સરળ હોવી જોઈએ, કારણ કે તે નેટવર્કના તમામ સંપૂર્ણ ગ્રાહકો દ્વારા કરવામાં આવે છે. જો અમલીકરણ સ્માર્ટ કોન્ટ્રાક્ટનો ઉપયોગ કરીને કરવામાં આવે છે, તો ઝડપની આવશ્યકતાઓ ખૂબ કડક છે
• સુલભતા અને જીવંતતાની સમસ્યા. તમારા પીવીઆરબીએ એવી પરિસ્થિતિઓમાં સ્થિતિસ્થાપક બનવાનો પ્રયત્ન કરવો જોઈએ કે જ્યાં નેટવર્કનો ભાગ અમુક સમય માટે અનુપલબ્ધ થઈ જાય અને આરપીનો ભાગ કામ કરવાનું બંધ કરી દે.
• વિશ્વસનીય સેટઅપ અને પ્રારંભિક કી વિતરણની સમસ્યા. જો તમારું PVRB પ્રોટોકોલના પ્રાથમિક સેટઅપનો ઉપયોગ કરે છે, તો આ એક અલગ મોટી અને ગંભીર વાર્તા છે. અહીં ઉદાહરણ. જો પ્રોટોકોલ શરૂ કરતા પહેલા સહભાગીઓએ એકબીજાને તેમની ચાવીઓ જણાવવી જ જોઈએ, તો આ પણ એક સમસ્યા છે જો સહભાગીઓની રચના બદલાય છે
• વિકાસ સમસ્યાઓ. જરૂરી ભાષાઓમાં પુસ્તકાલયોની ઉપલબ્ધતા, તેમની સુરક્ષા અને કામગીરી, પ્રચાર, જટિલ પરીક્ષણો વગેરે.

ઉદાહરણ તરીકે, થ્રેશોલ્ડ BLS હસ્તાક્ષરોમાં નોંધપાત્ર સમસ્યા છે - કામ કરવાનું શરૂ કરતા પહેલા, સહભાગીઓએ એકબીજાને ચાવીઓનું વિતરણ કરવું જોઈએ, એક જૂથનું આયોજન કરવું જોઈએ જેમાં થ્રેશોલ્ડ કાર્ય કરશે. આનો અર્થ એ છે કે વિકેન્દ્રિત નેટવર્કમાં વિનિમયના ઓછામાં ઓછા એક રાઉન્ડ માટે રાહ જોવી પડશે, અને આપેલ છે કે જનરેટેડ રેન્ડ, ઉદાહરણ તરીકે, રમતોમાં જરૂરી છે, લગભગ વાસ્તવિક સમયમાં, આનો અર્થ એ છે કે આ તબક્કે પ્રોટોકોલનો તોડફોડ શક્ય છે. , અને થ્રેશોલ્ડ યોજનાના લાભો ખોવાઈ ગયા છે. આ સમસ્યા પહેલાની સમસ્યાઓ કરતા પહેલાથી જ સરળ છે, પરંતુ હજી પણ થ્રેશોલ્ડ જૂથોની રચના માટે એક અલગ પ્રક્રિયાના વિકાસની જરૂર છે, જેનું પાલન ન કરતા સહભાગીઓ પાસેથી થાપણો અને ભંડોળના ઉપાડ (સ્લેશિંગ) દ્વારા આર્થિક રીતે સુરક્ષિત થવું પડશે. પ્રોટોકોલ ઉપરાંત, સ્વીકાર્ય સ્તરની સુરક્ષા સાથે BLS ચકાસણી ફક્ત બંધબેસતી નથી, ઉદાહરણ તરીકે, પ્રમાણભૂત EOS અથવા Ethereum વ્યવહારમાં - ચકાસણી માટે પૂરતો સમય નથી. કોન્ટ્રાક્ટ કોડ વેબ એસેમ્બલી અથવા EVM છે, જે વર્ચ્યુઅલ મશીન દ્વારા ચલાવવામાં આવે છે. ક્રિપ્ટોગ્રાફિક ફંક્શન્સ નેટીવલી (હજી સુધી) અમલમાં મૂકવામાં આવ્યાં નથી અને પરંપરાગત ક્રિપ્ટોગ્રાફિક લાઈબ્રેરીઓ કરતાં દસ ગણી ધીમી કામગીરી કરે છે. ઘણા પ્રોટોકોલ ફક્ત કી વોલ્યુમ પર આધારિત જરૂરિયાતોને પૂર્ણ કરતા નથી, ઉદાહરણ તરીકે RSA માટે 1024 અને 2048 બિટ્સ, Bitcoin અને Ethereum માં સ્ટાન્ડર્ડ ટ્રાન્ઝેક્શન સિગ્નેચર કરતા 4-8 ગણા મોટા.

વિવિધ પ્રોગ્રામિંગ ભાષાઓમાં અમલીકરણની હાજરી પણ ભૂમિકા ભજવે છે - જેમાંથી થોડા છે, ખાસ કરીને નવા પ્રોટોકોલ્સ માટે. સર્વસંમતિમાં એકીકરણ સાથેના વિકલ્પ માટે પ્લેટફોર્મ ભાષામાં પ્રોટોકોલ લખવાની જરૂર છે, તેથી તમારે ગો ફોર ગેથમાં, રસ્ટ ફોર પેરિટીમાં, EOS માટે C++ માં કોડ જોવો પડશે. દરેક વ્યક્તિએ JavaScript કોડ શોધવો પડશે, અને JavaScript અને ક્રિપ્ટોગ્રાફી ખાસ કરીને નજીકના મિત્રો નથી, તેથી WebAssembly મદદ કરશે, જે હવે ચોક્કસપણે આગામી મહત્વપૂર્ણ ઇન્ટરનેટ ધોરણ હોવાનો દાવો કરે છે.

નિષ્કર્ષ

હું પાછલા એકમાં આશા રાખું છું લેખ હું તમને સમજાવવામાં સફળ થયો કે બ્લોકચેન પર રેન્ડમ નંબરો જનરેટ કરવા એ વિકેન્દ્રિત નેટવર્ક્સના જીવનના ઘણા પાસાઓ માટે મહત્વપૂર્ણ છે, અને આ લેખ દ્વારા મેં બતાવ્યું કે આ કાર્ય અત્યંત મહત્વાકાંક્ષી અને મુશ્કેલ છે, પરંતુ સારા ઉકેલો પહેલેથી જ અસ્તિત્વમાં છે. સામાન્ય રીતે, પ્રોટોકોલની આખરી રચના મોટાપાયે પરીક્ષણો હાથ ધર્યા પછી જ શક્ય બને છે જે સેટઅપથી ફોલ્ટ ઈમ્યુલેશન સુધીના તમામ પાસાઓને ધ્યાનમાં લે છે, તેથી તમને ટીમના વ્હાઇટપેપર અને લેખોમાં તૈયાર રેસિપી મળવાની શક્યતા નથી, અને અમે ચોક્કસપણે તે જોઈશું નહીં. આગામી એક કે બે વર્ષમાં નક્કી કરો "આ રીતે કરો, બરાબર."

બાય, બ્લોકચેનમાં અમારા PVRB માટે ડેવલપ થઈ રહી છે Haya, અમે થ્રેશોલ્ડ BLS હસ્તાક્ષરોનો ઉપયોગ કરવાનું નક્કી કર્યું, અમે સર્વસંમતિ સ્તરે PVRB ને અમલમાં મૂકવાની યોજના બનાવીએ છીએ, કારણ કે સલામતીના સ્વીકાર્ય સ્તર સાથે સ્માર્ટ કોન્ટ્રાક્ટમાં ચકાસણી હજુ સુધી શક્ય નથી. શક્ય છે કે અમે એકસાથે બે યોજનાઓનો ઉપયોગ કરીએ: પ્રથમ, લાંબા ગાળાની રેન્ડમ_સીડ બનાવવા માટે ખર્ચાળ ગુપ્ત શેરિંગ, અને પછી અમે નિર્ધારિત થ્રેશોલ્ડ બીએલએસ હસ્તાક્ષરોનો ઉપયોગ કરીને ઉચ્ચ-આવર્તન રેન્ડમ જનરેશન માટેના આધાર તરીકે તેનો ઉપયોગ કરીએ છીએ, કદાચ અમે ફક્ત અમારી જાતને મર્યાદિત કરીશું. યોજનાઓમાંથી એક. કમનસીબે, પ્રોટોકોલ શું હશે તે અગાઉથી કહેવું અશક્ય છે; એકમાત્ર સારી બાબત એ છે કે, વિજ્ઞાનની જેમ, એન્જિનિયરિંગ સમસ્યાઓમાં, નકારાત્મક પરિણામ પણ આવે છે, અને સમસ્યાને હલ કરવાનો દરેક નવો પ્રયાસ એ બીજું પગલું છે. સમસ્યામાં સામેલ દરેક વ્યક્તિનું સંશોધન. વ્યવસાયની આવશ્યકતાઓને પહોંચી વળવા માટે, અમે ચોક્કસ વ્યવહારિક સમસ્યાનું નિરાકરણ કરીએ છીએ - એન્ટ્રોપીના વિશ્વસનીય સ્ત્રોત સાથે ગેમિંગ એપ્લિકેશન પ્રદાન કરવી, તેથી અમારે બ્લોકચેન પર પણ ધ્યાન આપવું પડશે, ખાસ કરીને ચેઇન ફાઇનાલિટી અને નેટવર્ક ગવર્નન્સના મુદ્દાઓ પર.

અને તેમ છતાં આપણે હજી સુધી બ્લોકચેનમાં સાબિત પ્રતિરોધક PVRB જોતા નથી, જેનો વાસ્તવિક એપ્લિકેશન, બહુવિધ ઓડિટ, લોડ અને અલબત્ત, વાસ્તવિક હુમલાઓ દ્વારા પરીક્ષણ કરવા માટે પૂરતા સમય માટે ઉપયોગ કરવામાં આવ્યો હશે, પરંતુ સંભવિત માર્ગોની સંખ્યા તેની પુષ્ટિ કરે છે. એક ઉકેલ અસ્તિત્વમાં છે, અને આમાંથી શું-શું ગાણિતીક નિયમો આખરે સમસ્યાને હલ કરશે. અમને પરિણામો શેર કરવામાં આનંદ થશે અને અન્ય ટીમોનો પણ આભાર માનીશું જેઓ આ મુદ્દા પર લેખો અને કોડ માટે પણ કામ કરી રહી છે જે એન્જિનિયરોને એક જ રેક પર બે વાર પગ ન મૂકવા દે છે.

તેથી, જ્યારે તમે વિકેન્દ્રિત રેન્ડમ ડિઝાઇન કરતા પ્રોગ્રામરને મળો, ત્યારે સચેત અને કાળજી રાખો અને જો જરૂરી હોય તો મનોવૈજ્ઞાનિક મદદ આપો :)

સોર્સ: www.habr.com