જો આપણે એકબીજા પર વિશ્વાસ ન કરીએ તો શું રેન્ડમ નંબરો જનરેટ કરવાનું શક્ય છે? ભાગ 1

હે હબર!

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

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

જ્યારે અમે વિતરિત રેન્ડમ નંબર જનરેશન પ્રોટોકોલ ડિઝાઇન કરીએ છીએ, ત્યારે અમે ઇચ્છીએ છીએ કે તેમાં ત્રણ ગુણધર્મો હોય:

1. તેણે નિષ્પક્ષ હોવું જોઈએ. બીજા શબ્દોમાં કહીએ તો, કોઈપણ સહભાગીએ કોઈપણ રીતે રેન્ડમ નંબર જનરેટરના પરિણામને પ્રભાવિત કરવું જોઈએ નહીં.

2. તે અણધારી હોવો જોઈએ. બીજા શબ્દોમાં કહીએ તો, કોઈ પણ સહભાગી તે જનરેટ થાય તે પહેલાં કયો નંબર જનરેટ થશે (અથવા તેની કોઈપણ પ્રોપર્ટીનું અનુમાન લગાવશે) તેની આગાહી કરી શકશે નહીં.

3. પ્રોટોકોલ વ્યવહારુ હોવો જોઈએ, એટલે કે, સહભાગીઓની ચોક્કસ ટકાવારી નેટવર્કથી ડિસ્કનેક્ટ થઈ જાય છે અથવા પ્રોટોકોલને ઇરાદાપૂર્વક રોકવાનો પ્રયાસ કરે છે તે માટે પ્રતિરોધક હોવો જોઈએ.

આ લેખમાં આપણે બે અભિગમો જોઈશું: RANDAO + VDF અને ઇરેઝર કોડ્સનો અભિગમ. આગળના ભાગમાં, અમે થ્રેશોલ્ડ હસ્તાક્ષર પર આધારિત અભિગમની વિગતવાર તપાસ કરીશું.

પરંતુ પ્રથમ, ચાલો એક સરળ અને સામાન્ય રીતે ઉપયોગમાં લેવાતા અલ્ગોરિધમને જોઈએ જે વ્યવહારુ, અણધારી, પરંતુ પક્ષપાતી છે.

રાંડાઓ

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

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

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

RANDAO પાસે આપણે ઉપર વર્ણવેલ મિલકતોમાંથી કઈ મિલકતો છે? તે અણધારી છે, તે અંતર્ગત સર્વસંમતિ પ્રોટોકોલની જેમ જ જોમ ધરાવે છે, પરંતુ તે પક્ષપાતી છે. ખાસ કરીને, હુમલાખોર નેટવર્કનું અવલોકન કરી શકે છે, અને અન્ય સહભાગીઓ તેમના નંબરો જાહેર કરે તે પછી, તે તેમના XORની ગણતરી કરી શકે છે, અને પરિણામને પ્રભાવિત કરવા માટે તેનો નંબર જાહેર કરવો કે નહીં તે નક્કી કરી શકે છે. જ્યારે આ હુમલાખોરને એકલા હાથે રેન્ડમ નંબર જનરેટરનું આઉટપુટ નક્કી કરવાથી અટકાવે છે, તે હજુ પણ તેને 1 બીટ પ્રભાવ આપે છે. અને જો હુમલાખોરો ઘણા સહભાગીઓને નિયંત્રિત કરે છે, તો પછી તેમના નિયંત્રણ હેઠળના બિટ્સની સંખ્યા તેમના નિયંત્રણ હેઠળના સહભાગીઓની સંખ્યા જેટલી હશે.

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

RANDAO+VDF

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

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

આ ફંક્શનને વેરિફાઇબલ ડિલે ફંક્શન અથવા VDF કહેવામાં આવે છે. જો અંતિમ પરિણામની ગણતરી કરવામાં સંખ્યા જાહેર કરવાના તબક્કા કરતાં વધુ સમય લાગે છે, તો હુમલાખોર તેનો નંબર બતાવવા અથવા છુપાવવાની અસરની આગાહી કરી શકશે નહીં, અને તેથી તે પરિણામને પ્રભાવિત કરવાની તક ગુમાવશે.

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

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

ઉપર જણાવેલ VDF કુટુંબ માટે, સમર્પિત ASIC નું પ્રદર્શન પરંપરાગત હાર્ડવેર કરતાં 100+ ગણું વધારે હોઈ શકે છે. તેથી જો જમાવટનો તબક્કો 10 સેકન્ડ ચાલે છે, તો આવા ASIC પર ગણતરી કરેલ VDF ને 100x સલામતી માર્જિન મેળવવા માટે 10 સેકન્ડથી વધુ સમય લાગવો જોઈએ અને આમ કોમોડિટી હાર્ડવેર પર ગણતરી કરેલ સમાન VDF 100x 100 સેકન્ડ = ~3 કલાક લેવો જોઈએ.

Ethereum ફાઉન્ડેશન તેની પોતાની સાર્વજનિક રીતે ઉપલબ્ધ, મફત ASICs બનાવીને આ સમસ્યાને હલ કરવાની યોજના ધરાવે છે. એકવાર આવું થઈ જાય પછી, અન્ય તમામ પ્રોટોકોલ પણ આ ટેક્નોલોજીનો લાભ લઈ શકે છે, પરંતુ ત્યાં સુધી RANDAO+VDF અભિગમ એવા પ્રોટોકોલ માટે એટલો સધ્ધર રહેશે નહીં કે જેઓ તેમના પોતાના ASIC વિકસાવવામાં રોકાણ કરી શકતા નથી.

VDF વિશે ઘણા લેખો, વીડિયો અને અન્ય માહિતી એકત્ર કરવામાં આવી છે આ સાઇટ.

અમે ઇરેઝર કોડ્સનો ઉપયોગ કરીએ છીએ

આ વિભાગમાં, અમે રેન્ડમ નંબર જનરેશન પ્રોટોકોલ જોઈશું જે વાપરે છે કોડ્સ ભૂંસી રહ્યા છે. તે સધ્ધર રહીને ⅓ હુમલાખોરો સુધી સહન કરી શકે છે અને પરિણામની આગાહી અથવા પ્રભાવિત કરી શકે તે પહેલા ⅔ હુમલાખોરોને અસ્તિત્વમાં રહેવાની મંજૂરી આપે છે.

પ્રોટોકોલનો મુખ્ય વિચાર નીચે મુજબ છે. સરળતા માટે, ચાલો ધારીએ કે ત્યાં બરાબર 100 સહભાગીઓ છે. ચાલો આપણે એ પણ માની લઈએ કે તમામ સહભાગીઓ પાસે સ્થાનિક રીતે કેટલીક ખાનગી કી હોય છે, અને તમામ સહભાગીઓની સાર્વજનિક ચાવીઓ બધા સહભાગીઓને જાણીતી હોય છે:

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

2. સહભાગીઓ ચોક્કસ 67 સહભાગીઓ પાસેથી કોડેડ સેટ પર કરાર સુધી પહોંચવા માટે અમુક પ્રકારની સર્વસંમતિનો ઉપયોગ કરે છે.

3. એકવાર સર્વસંમતિ પહોંચી ગયા પછી, દરેક સહભાગી તેમની સાર્વજનિક કી વડે એનક્રિપ્ટ કરાયેલા 67 સેટમાંથી દરેકમાં એન્કોડેડ શેર્સ લે છે, આવા તમામ શેરને ડિક્રિપ્ટ કરે છે અને આવા તમામ ડિક્રિપ્ટેડ શેર પ્રકાશિત કરે છે.

4. એકવાર 67 સહભાગીઓએ પગલું (3) પૂર્ણ કરી લીધા પછી, બધા સંમત સેટ ઇરેઝર કોડના ગુણધર્મોને કારણે સંપૂર્ણપણે ડીકોડ અને પુનઃનિર્માણ કરી શકાય છે, અને અંતિમ સંખ્યા પ્રારંભિક પંક્તિઓના XOR તરીકે મેળવી શકાય છે જે સહભાગીઓએ (1) માં શરૂ કરી હતી. .

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

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

જ્યારે સ્ટેપ (4) માં સહભાગી ચોક્કસ સ્ટ્રિંગ માટે 67 બીટ્સ ડિસિફર કરે છે અને તેમાંથી મૂળ સ્ટ્રિંગને ફરીથી બનાવવાનો પ્રયાસ કરે છે, ત્યારે વિકલ્પોમાંથી એક શક્ય છે:

1. શબ્દમાળા પુનઃસ્થાપિત કરવામાં આવે છે, અને જો તે ફરીથી ભૂંસી નાખવામાં આવે છે, અને મર્કલ વૃક્ષની ગણતરી સ્થાનિક રીતે ગણતરી કરાયેલા શેર માટે કરવામાં આવે છે, તો રુટ તેની સાથે એકરુપ થાય છે જેના પર સર્વસંમતિ પહોંચી હતી.

2. પંક્તિ પુનઃસ્થાપિત કરવામાં આવી છે, પરંતુ સ્થાનિક રીતે ગણતરી કરેલ રુટ જેની પર સર્વસંમતિ પહોંચી હતી તેની સાથે મેળ ખાતી નથી.

3. પંક્તિ પુનઃસ્થાપિત નથી.

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

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

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

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

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

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

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

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

અંતમા

આ લેખ તકનીકી બ્લોગ લેખોની શ્રેણીમાં પ્રથમ છે NEAR. NEAR એ બ્લોકચેન પ્રોટોકોલ અને અંતિમ વપરાશકર્તાઓ માટે વિકાસની સરળતા અને ઉપયોગમાં સરળતા પર ભાર સાથે વિકેન્દ્રિત એપ્લિકેશનો વિકસાવવા માટેનું પ્લેટફોર્મ છે.

પ્રોટોકોલ કોડ ખુલ્લો છે, અમારું અમલીકરણ રસ્ટમાં લખાયેલું છે, તે શોધી શકાય છે અહીં.

તમે NEAR માટે વિકાસ કેવો દેખાય છે તે જોઈ શકો છો અને ઓનલાઈન IDE માં પ્રયોગ કરી શકો છો અહીં.

તમે રશિયનમાંના તમામ સમાચારને અહીં અનુસરી શકો છો ટેલિગ્રામ જૂથ અને અંદર VKontakte પર જૂથ, અને સત્તાવારમાં અંગ્રેજીમાં પક્ષીએ.

ફરી મળ્યા!

સોર્સ: www.habr.com