ആമുഖം

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

ക്രിപ്‌റ്റോഗ്രാഫിയിൽ നിന്നുള്ള തികച്ചും ശക്തമായ ഒരു സൈഫർ എന്ന ആശയം പോലെ, യഥാർത്ഥ “പബ്ലിക്ലി വെരിഫയബിൾ റാൻഡം ബീക്കൺ” (ഇനി മുതൽ പിവിആർബി) പ്രോട്ടോക്കോളുകൾ അനുയോജ്യമായ സ്കീമിനോട് കഴിയുന്നത്ര അടുത്ത് എത്താൻ മാത്രമേ ശ്രമിക്കുന്നുള്ളൂ, കാരണം യഥാർത്ഥ നെറ്റ്‌വർക്കുകളിൽ ഇത് അതിൻ്റെ ശുദ്ധമായ രൂപത്തിൽ ബാധകമല്ല: ഒരു ബിറ്റ് കർശനമായി അംഗീകരിക്കേണ്ടത് ആവശ്യമാണ്, നിരവധി റൗണ്ടുകൾ ഉണ്ടായിരിക്കണം, കൂടാതെ എല്ലാ സന്ദേശങ്ങളും തികച്ചും വേഗതയുള്ളതും എല്ലായ്പ്പോഴും ഡെലിവർ ചെയ്യുന്നതുമായിരിക്കണം. തീർച്ചയായും, യഥാർത്ഥ നെറ്റ്‌വർക്കുകളിൽ ഇത് അങ്ങനെയല്ല. അതിനാൽ, ആധുനിക ബ്ലോക്ക്‌ചെയിനുകളിൽ നിർദ്ദിഷ്ട ജോലികൾക്കായി PVRB രൂപകൽപ്പന ചെയ്യുമ്പോൾ, തത്ഫലമായുണ്ടാകുന്ന ക്രമരഹിതതയും ക്രിപ്‌റ്റോഗ്രാഫിക് ശക്തിയും നിയന്ത്രിക്കാനുള്ള അസാധ്യതയ്‌ക്ക് പുറമേ, പൂർണ്ണമായും വാസ്തുവിദ്യയും സാങ്കേതികവുമായ നിരവധി പ്രശ്‌നങ്ങൾ ഉയർന്നുവരുന്നു.

PVRB-യെ സംബന്ധിച്ചിടത്തോളം, ബ്ലോക്ക്ചെയിൻ തന്നെ പ്രധാനമായും സന്ദേശങ്ങൾ = ഇടപാടുകൾ നടത്തുന്ന ഒരു ആശയവിനിമയ മാധ്യമമാണ്. നെറ്റ്‌വർക്ക് പ്രശ്‌നങ്ങൾ, സന്ദേശങ്ങൾ നൽകാത്തത്, മിഡിൽവെയറിലെ പ്രശ്നങ്ങൾ എന്നിവയിൽ നിന്ന് ഭാഗികമായി സംഗ്രഹിക്കാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു - ഈ അപകടസാധ്യതകളെല്ലാം വികേന്ദ്രീകൃത നെറ്റ്‌വർക്കാണ് അനുമാനിക്കുന്നത്, കൂടാതെ ഇതിനകം അയച്ച ഇടപാട് അസാധുവാക്കാനോ അഴിമതി ചെയ്യാനോ ഉള്ള കഴിവില്ലായ്മയാണ് PVRB-യുടെ പ്രധാന മൂല്യം. സമവായത്തിന്മേൽ വിജയകരമായ ആക്രമണം നടത്തിയില്ലെങ്കിൽ, പ്രോട്ടോക്കോളിൽ പങ്കെടുക്കാൻ വിസമ്മതിക്കാൻ പങ്കാളികളെ അനുവദിക്കരുത്. ഈ ലെവൽ സുരക്ഷ സ്വീകാര്യമാണ്, അതിനാൽ പ്രധാന ബ്ലോക്ക്ചെയിൻ ശൃംഖലയുടെ അതേ പരിധി വരെ PVRB പങ്കെടുക്കുന്നവരുടെ കൂട്ടുകെട്ടിനെ പ്രതിരോധിക്കണം. കൂടാതെ, പ്രധാന ബ്ലോക്ക്‌ചെയിനിൽ നെറ്റ്‌വർക്ക് അംഗീകരിക്കുന്നുവെങ്കിൽ PVRB സമവായത്തിൻ്റെ ഭാഗമായിരിക്കണം എന്ന് ഇത് സൂചന നൽകുന്നു, അത് ക്രമരഹിതമായി ഉണ്ടാകുന്ന ഒരേയൊരു ന്യായമായ കാര്യത്തിലും സമ്മതിക്കുന്നുവെങ്കിൽ പോലും. അല്ലെങ്കിൽ, PVRB എന്നത് ബ്ലോക്ക്ചെയിൻ, ബ്ലോക്കുകൾ എന്നിവയുമായി ബന്ധപ്പെട്ട് അസമന്വിതമായി പ്രവർത്തിക്കുന്ന ഒരു സ്മാർട്ട് കരാർ നടപ്പിലാക്കുന്ന ഒരു ഒറ്റപ്പെട്ട പ്രോട്ടോക്കോൾ ആണ്. രണ്ട് രീതികൾക്കും അവയുടെ ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്, അവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ് വളരെ നിസ്സാരമാണ്.

PVRB നടപ്പിലാക്കാൻ രണ്ട് വഴികൾ

PVRB നടപ്പിലാക്കുന്നതിനുള്ള രണ്ട് ഓപ്ഷനുകൾ നമുക്ക് കൂടുതൽ വിശദമായി വിവരിക്കാം - ബ്ലോക്ക്ചെയിനിൽ നിന്ന് സ്വതന്ത്രമായ ഒരു സ്മാർട്ട് കരാർ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന സ്റ്റാൻഡേലോൺ പതിപ്പ്, പ്രോട്ടോക്കോളിൽ നിർമ്മിച്ച സമവായ-സംയോജിത പതിപ്പ്, അതനുസരിച്ച് ബ്ലോക്ക്ചെയിനിലും നെറ്റ്‌വർക്ക് സമ്മതിക്കുന്നു. ഇടപാടുകൾ ഉൾപ്പെടുത്തണം. എല്ലാ സാഹചര്യങ്ങളിലും, ഞാൻ ഉദ്ദേശിക്കുന്നത് ജനപ്രിയ ബ്ലോക്ക്ചെയിൻ എഞ്ചിനുകളെയാണ്: Ethereum, EOS, കൂടാതെ അവയ്ക്ക് സമാനമായ എല്ലാം അവർ സ്‌മാർട്ട് കരാറുകൾ ഹോസ്റ്റുചെയ്യുകയും പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു.

ഒറ്റപ്പെട്ട കരാർ

ഈ പതിപ്പിൽ, PVRB എന്നത് ക്രമരഹിതമായ നിർമ്മാതാക്കളുടെ ഇടപാടുകൾ സ്വീകരിക്കുന്ന ഒരു സ്‌മാർട്ട് കരാറാണ് (ഇനി RP എന്ന് വിളിക്കുന്നു), അവ പ്രോസസ്സ് ചെയ്യുന്നു, ഫലങ്ങൾ സംയോജിപ്പിക്കുന്നു, അതിൻ്റെ ഫലമായി, ഈ കരാറിൽ നിന്ന് ഏതൊരു ഉപയോക്താവിനും സ്വീകരിക്കാൻ കഴിയുന്ന ഒരു നിശ്ചിത മൂല്യത്തിൽ എത്തിച്ചേരുന്നു. ഈ മൂല്യം കരാറിൽ നേരിട്ട് സംഭരിച്ചേക്കില്ല, മറിച്ച്, ഫലമായുണ്ടാകുന്ന റാൻഡത്തിൻ്റെ ഒരു മൂല്യം മാത്രമേ നിർണ്ണായകമായി ലഭിക്കുകയുള്ളൂ. ഈ സ്കീമിൽ, RP-കൾ ബ്ലോക്ക്ചെയിനിൻ്റെ ഉപയോക്താക്കളാണ്, ജനറേഷൻ പ്രക്രിയയിൽ പങ്കെടുക്കാൻ ആരെയും അനുവദിക്കാവുന്നതാണ്.

സ്വതന്ത്ര-കരാർ ഉള്ള ഓപ്ഷൻ നല്ലതാണ്:

• പോർട്ടബിലിറ്റി (കോൺട്രാക്റ്റുകൾ ബ്ലോക്ക്ചെയിനിൽ നിന്ന് ബ്ലോക്ക്ചെയിനിലേക്ക് വലിച്ചിടാം)
• നടപ്പിലാക്കുന്നതിനും പരിശോധിക്കുന്നതിനും എളുപ്പം (കരാർ എഴുതാനും പരീക്ഷിക്കാനും എളുപ്പമാണ്)
• സാമ്പത്തിക സ്കീമുകൾ നടപ്പിലാക്കുന്നതിനുള്ള സൗകര്യം (നിങ്ങളുടെ സ്വന്തം ടോക്കൺ നിർമ്മിക്കുന്നത് എളുപ്പമാണ്, അതിൻ്റെ യുക്തി പിവിആർബിയുടെ ഉദ്ദേശ്യങ്ങൾ നിറവേറ്റുന്നു)
• ഇതിനകം പ്രവർത്തിക്കുന്ന ബ്ലോക്ക്ചെയിനുകളിൽ ലോഞ്ച് ചെയ്യാനുള്ള സാധ്യത

ഇതിന് ദോഷങ്ങളുമുണ്ട്:

• കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ, ഇടപാടിൻ്റെ അളവ്, സംഭരണം എന്നിവയിൽ ശക്തമായ പരിമിതികൾ (മറ്റൊരു രീതിയിൽ പറഞ്ഞാൽ, cpu/mem/io)
• കരാറിനുള്ളിലെ പ്രവർത്തനങ്ങളുടെ നിയന്ത്രണങ്ങൾ (എല്ലാ നിർദ്ദേശങ്ങളും ലഭ്യമല്ല, ബാഹ്യ ലൈബ്രറികൾ ബന്ധിപ്പിക്കുന്നത് ബുദ്ധിമുട്ടാണ്)
• ബ്ലോക്ക്ചെയിനിൽ ഉൾപ്പെടുന്ന ഇടപാടുകളേക്കാൾ വേഗത്തിൽ സന്ദേശമയയ്‌ക്കൽ സംഘടിപ്പിക്കാനുള്ള കഴിവില്ലായ്മ

നിലവിലുള്ള ഒരു നെറ്റ്‌വർക്കിൽ പ്രവർത്തിപ്പിക്കേണ്ട, സങ്കീർണ്ണമായ ക്രിപ്‌റ്റോഗ്രാഫി അടങ്ങിയിട്ടില്ലാത്തതും ധാരാളം ഇടപെടലുകൾ ആവശ്യമില്ലാത്തതുമായ ഒരു PVRB നടപ്പിലാക്കുന്നതിന് ഈ ഓപ്ഷൻ അനുയോജ്യമാണ്.

സമവായം-സംയോജിത

ഈ പതിപ്പിൽ, ബ്ലോക്ക്ചെയിൻ നോഡ് കോഡിൽ PVRB നടപ്പിലാക്കുന്നു, ബിൽറ്റ്-ഇൻ അല്ലെങ്കിൽ ബ്ലോക്ക്ചെയിൻ നോഡുകൾക്കിടയിൽ സന്ദേശങ്ങൾ കൈമാറുന്നതിന് സമാന്തരമായി പ്രവർത്തിക്കുന്നു. പ്രോട്ടോക്കോളിൻ്റെ ഫലങ്ങൾ നേരിട്ട് നിർമ്മിച്ച ബ്ലോക്കുകളിലേക്ക് എഴുതുകയും നോഡുകൾക്കിടയിൽ p2p നെറ്റ്‌വർക്കിലൂടെ പ്രോട്ടോക്കോൾ സന്ദേശങ്ങൾ അയയ്ക്കുകയും ചെയ്യുന്നു. ബ്ലോക്കുകളിൽ എഴുതേണ്ട സംഖ്യകൾക്ക് പ്രോട്ടോക്കോൾ കാരണമാകുന്നതിനാൽ, നെറ്റ്‌വർക്ക് അവയിൽ ഒരു സമവായത്തിലെത്തണം. ഇതിനർത്ഥം, ഇടപാടുകൾ പോലെയുള്ള PVRB സന്ദേശങ്ങൾ നോഡുകൾ വഴി സാധൂകരിക്കുകയും ബ്ലോക്കുകളിൽ ഉൾപ്പെടുത്തുകയും വേണം, അതിലൂടെ ഏതൊരു നെറ്റ്‌വർക്ക് പങ്കാളിക്കും PVRB പ്രോട്ടോക്കോൾ പാലിക്കുന്നത് സാധൂകരിക്കാനാകും. ഇത് സ്വയമേവ നമ്മെ വ്യക്തമായ പരിഹാരത്തിലേക്ക് നയിക്കുന്നു - നെറ്റ്‌വർക്ക് ഒരു ബ്ലോക്കിനെക്കുറിച്ചും അതിലെ ഇടപാടുകളെക്കുറിച്ചും സമവായത്തിൽ സമ്മതിക്കുകയാണെങ്കിൽ, PVRB സമവായത്തിൻ്റെ ഭാഗമായിരിക്കണം, അല്ലാതെ ഒരു സ്റ്റാൻഡ്-എലോൺ പ്രോട്ടോക്കോൾ അല്ല. അല്ലാത്തപക്ഷം, ഒരു സമവായ വീക്ഷണകോണിൽ നിന്ന് ഒരു ബ്ലോക്ക് സാധുവാകാൻ സാധ്യതയുണ്ട്, പക്ഷേ PVRB പ്രോട്ടോക്കോൾ പാലിക്കപ്പെടുന്നില്ല, കൂടാതെ PVRB കാഴ്ചപ്പാടിൽ ബ്ലോക്ക് അംഗീകരിക്കാൻ കഴിയില്ല. അതിനാൽ "സമവായ-സംയോജിത" ഓപ്ഷൻ തിരഞ്ഞെടുത്താൽ, PVRB സമവായത്തിൻ്റെ ഒരു പ്രധാന ഭാഗമായി മാറുന്നു.

നെറ്റ്‌വർക്ക് സമവായ തലത്തിൽ PVRB നടപ്പിലാക്കലുകൾ വിവരിക്കുമ്പോൾ, അന്തിമ പ്രശ്‌നങ്ങൾ ഒരു തരത്തിലും ഒഴിവാക്കാൻ കഴിയില്ല. നിർണ്ണായകമായ സമവായങ്ങളിൽ ഉപയോഗിക്കുന്ന ഒരു സംവിധാനമാണ് ഫിനാലിറ്റി, അത് ഒരു ബ്ലോക്കിൽ (അതിലേക്ക് നയിക്കുന്ന ചങ്ങല) പൂട്ടുന്നു, അത് അന്തിമവും ഒരു സമാന്തര ഫോർക്ക് സംഭവിച്ചാലും ഒരിക്കലും വലിച്ചെറിയപ്പെടില്ല. ഉദാഹരണത്തിന്, ബിറ്റ്കോയിനിൽ അത്തരമൊരു സംവിധാനം ഇല്ല - നിങ്ങൾ കൂടുതൽ സങ്കീർണ്ണതയുടെ ഒരു ശൃംഖല പ്രസിദ്ധീകരിക്കുകയാണെങ്കിൽ, അത് ചങ്ങലകളുടെ ദൈർഘ്യം പരിഗണിക്കാതെ തന്നെ സങ്കീർണ്ണമായ ഏതെങ്കിലും ഒന്ന് മാറ്റിസ്ഥാപിക്കും. EOS-ൽ, ഉദാഹരണത്തിന്, അവസാനത്തേത് അവസാനത്തെ മാറ്റാനാവാത്ത ബ്ലോക്കുകൾ എന്ന് വിളിക്കപ്പെടുന്നവയാണ്, അവ ശരാശരി ഓരോ 432 ബ്ലോക്കുകളിലും (12*21 + 12*15, പ്രീ-വോട്ട് + പ്രീ-കമ്മിറ്റ്) പ്രത്യക്ഷപ്പെടുന്നു. ഈ പ്രക്രിയ പ്രധാനമായും 2/3 ബ്ലോക്ക് പ്രൊഡ്യൂസർമാരുടെ (ഇനിമുതൽ ബിപി എന്ന് വിളിക്കപ്പെടുന്നു) ഒപ്പുകൾക്കായി കാത്തിരിക്കുന്നു. കഴിഞ്ഞ എൽഐബിയേക്കാൾ പഴക്കമുള്ള ഫോർക്കുകൾ പ്രത്യക്ഷപ്പെടുമ്പോൾ, അവ വെറുതെ ഉപേക്ഷിക്കപ്പെടും. ഇടപാട് ബ്ലോക്ക്‌ചെയിനിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ടെന്നും ആക്രമണകാരിക്ക് എന്ത് ഉറവിടങ്ങളുണ്ടെങ്കിലും അത് ഒരിക്കലും പിൻവലിക്കില്ലെന്നും ഉറപ്പ് നൽകാൻ ഈ സംവിധാനം സാധ്യമാക്കുന്നു. കൂടാതെ, അവസാന ബ്ലോക്കുകൾ ഹൈപ്പർലെഡ്ജർ, ടെൻഡർമിൻ്റ്, മറ്റ് pBFT അടിസ്ഥാനമാക്കിയുള്ള സമവായങ്ങൾ എന്നിവയിൽ 2/3 ബിപി ഒപ്പിട്ട ബ്ലോക്കുകളാണ്. കൂടാതെ, സമവായത്തിലേക്കുള്ള ഒരു ആഡ്-ഓൺ അന്തിമത ഉറപ്പാക്കുന്നതിനുള്ള ഒരു പ്രോട്ടോക്കോൾ ആക്കുന്നതിൽ അർത്ഥമുണ്ട്, കാരണം ഇതിന് ബ്ലോക്കുകളുടെ നിർമ്മാണത്തിലും പ്രസിദ്ധീകരണത്തിലും അസമന്വിതമായി പ്രവർത്തിക്കാൻ കഴിയും. ഇതാ ഒരു നല്ല കാര്യം ഒരു ലേഖനം Ethereum ലെ അന്തിമതയെക്കുറിച്ച്.

ഉപയോക്താക്കൾക്ക് ഫിനാലിറ്റി വളരെ പ്രധാനമാണ്, അതില്ലാതെ തന്നെ ഒരു "ഡബിൾ സ്‌പെൻഡ്" ആക്രമണത്തിന് ഇരയായേക്കാം, അവിടെ BP തടഞ്ഞുനിർത്തുകയും നെറ്റ്‌വർക്ക് ഒരു നല്ല ഇടപാട് "കണ്ടതിന്" ശേഷം അവ പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്നു. അന്തിമത ഇല്ലെങ്കിൽ, പ്രസിദ്ധീകരിച്ച ഫോർക്ക് ബ്ലോക്കിന് പകരം മറ്റൊരു "നല്ല" ഇടപാട്, "മോശം" ഫോർക്കിൽ നിന്ന്, അതേ ഫണ്ടുകൾ ആക്രമണകാരിയുടെ വിലാസത്തിലേക്ക് മാറ്റുന്നു. PVRB-യുടെ കാര്യത്തിൽ, അന്തിമതിനുള്ള ആവശ്യകതകൾ കൂടുതൽ കർശനമാണ്, കാരണം PVRB-യ്‌ക്ക് ഫോർക്കുകൾ നിർമ്മിക്കുന്നത് ഏറ്റവും ലാഭകരമായ ഒന്ന് പ്രസിദ്ധീകരിക്കുന്നതിന് ഒരു ആക്രമണകാരിക്ക് ക്രമരഹിതമായ നിരവധി ഓപ്ഷനുകൾ തയ്യാറാക്കാനുള്ള അവസരമാണ്, കൂടാതെ സാധ്യമായ ആക്രമണത്തിൻ്റെ സമയം പരിമിതപ്പെടുത്തുന്നത് ഒരു നല്ല പരിഹാരം.

അതിനാൽ, പിവിആർബിയും ഫിനാലിറ്റിയും ഒരു പ്രോട്ടോക്കോളിലേക്ക് സംയോജിപ്പിക്കുക എന്നതാണ് ഏറ്റവും മികച്ച ഓപ്ഷൻ - തുടർന്ന് അന്തിമമാക്കിയ ബ്ലോക്ക് = അന്തിമമാക്കിയ ക്രമരഹിതം, ഇതാണ് ഞങ്ങൾക്ക് ലഭിക്കേണ്ടത്. ഇപ്പോൾ കളിക്കാർക്ക് N സെക്കൻഡുകൾക്കുള്ളിൽ ഒരു ഗ്യാരണ്ടീഡ് റാൻഡം ലഭിക്കും, മാത്രമല്ല ഇത് വീണ്ടും റോൾ ചെയ്യുകയോ വീണ്ടും പ്ലേ ചെയ്യുകയോ ചെയ്യുന്നത് അസാധ്യമാണെന്ന് ഉറപ്പിക്കാം.

സമവായ-സംയോജിത ഓപ്ഷൻ നല്ലതാണ്:

• ബ്ലോക്കുകളുടെ ഉൽപാദനവുമായി ബന്ധപ്പെട്ട് അസിൻക്രണസ് നടപ്പിലാക്കാനുള്ള സാധ്യത - ബ്ലോക്കുകൾ പതിവുപോലെ നിർമ്മിക്കപ്പെടുന്നു, എന്നാൽ ഇതിന് സമാന്തരമായി, PVRB പ്രോട്ടോക്കോൾ പ്രവർത്തിക്കാൻ കഴിയും, ഇത് ഓരോ ബ്ലോക്കിനും ക്രമരഹിതത ഉണ്ടാക്കില്ല.
• സ്‌മാർട്ട് കരാറുകളിൽ ഏർപ്പെടുത്തിയിരിക്കുന്ന നിയന്ത്രണങ്ങളില്ലാതെ, കനത്ത ക്രിപ്‌റ്റോഗ്രഫി പോലും നടപ്പിലാക്കാനുള്ള കഴിവ്
• ഇടപാടുകളേക്കാൾ വേഗത്തിൽ സന്ദേശങ്ങളുടെ കൈമാറ്റം സംഘടിപ്പിക്കാനുള്ള കഴിവ് ബ്ലോക്ക്ചെയിനിൽ ഉൾപ്പെടുത്തിയിട്ടുണ്ട്, ഉദാഹരണത്തിന്, പ്രോട്ടോക്കോളിൻ്റെ ഒരു ഭാഗം നെറ്റ്‌വർക്കിൽ സന്ദേശങ്ങൾ വിതരണം ചെയ്യാതെ നോഡുകൾക്കിടയിൽ പ്രവർത്തിക്കാൻ കഴിയും

ഇതിന് ദോഷങ്ങളുമുണ്ട്:

• പരിശോധനയിലും വികസനത്തിലും ബുദ്ധിമുട്ടുകൾ - നിങ്ങൾ നെറ്റ്‌വർക്ക് പിശകുകൾ, നഷ്‌ടമായ നോഡുകൾ, നെറ്റ്‌വർക്ക് ഹാർഡ് ഫോർക്കുകൾ എന്നിവ അനുകരിക്കേണ്ടതുണ്ട്
• നടപ്പിലാക്കൽ പിശകുകൾക്ക് ഒരു നെറ്റ്‌വർക്ക് ഹാർഡ്ഫോർക്ക് ആവശ്യമാണ്

PVRB നടപ്പിലാക്കുന്നതിനുള്ള രണ്ട് രീതികൾക്കും ജീവിക്കാനുള്ള അവകാശമുണ്ട്, എന്നാൽ ആധുനിക ബ്ലോക്ക്ചെയിനുകളിൽ സ്മാർട്ട് കരാറുകളിൽ നടപ്പിലാക്കുന്നത് ഇപ്പോഴും കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളിൽ വളരെ പരിമിതമാണ്, മാത്രമല്ല ഗുരുതരമായ ക്രിപ്റ്റോഗ്രഫിയിലേക്കുള്ള ഏതൊരു പരിവർത്തനവും പലപ്പോഴും അസാധ്യമാണ്. താഴെ പ്രദർശിപ്പിച്ചിരിക്കുന്നതുപോലെ ഞങ്ങൾക്ക് ഗുരുതരമായ ക്രിപ്റ്റോഗ്രഫി ആവശ്യമാണ്. ഈ പ്രശ്നം വ്യക്തമായും താത്കാലികമാണെങ്കിലും, നിരവധി പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിന് കരാറുകളിൽ ഗുരുതരമായ ക്രിപ്റ്റോഗ്രഫി ആവശ്യമാണ്, അത് ക്രമേണ പ്രത്യക്ഷപ്പെടുന്നു (ഉദാഹരണത്തിന്, Ethereum ലെ zkSNARK-കൾക്കുള്ള സിസ്റ്റം കരാറുകൾ)

സുതാര്യവും വിശ്വസനീയവുമായ പ്രോട്ടോക്കോൾ സന്ദേശമയയ്‌ക്കൽ ചാനൽ നൽകുന്ന ബ്ലോക്ക്‌ചെയിൻ, അത് സൗജന്യമായി ചെയ്യുന്നില്ല. ഏതെങ്കിലും വികേന്ദ്രീകൃത പ്രോട്ടോക്കോൾ സിബിൽ ആക്രമണത്തിൻ്റെ സാധ്യത കണക്കിലെടുക്കണം, ഒന്നിലധികം അക്കൗണ്ടുകളുടെ ഏകീകൃത ശക്തികൾക്ക് ഏത് പ്രവർത്തനവും ചെയ്യാൻ കഴിയും, അതിനാൽ, രൂപകൽപ്പന ചെയ്യുമ്പോൾ, ഒരു ഏകപക്ഷീയമായ പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കുന്നതിനുള്ള ആക്രമണകാരികളുടെ കഴിവ് കണക്കിലെടുക്കേണ്ടത് ആവശ്യമാണ്; പങ്കാളികൾ കൂട്ടുകെട്ടിൽ പ്രവർത്തിക്കുന്നു.

PVRB, ബ്ലോക്ക് വേരിയബിളുകൾ.

നിരവധി ചൂതാട്ട ആപ്ലിക്കേഷനുകൾ പരീക്ഷിച്ച ഒരു നല്ല PVRB ഇതുവരെ ബ്ലോക്ക്ചെയിനുകളിൽ ആരും നടപ്പിലാക്കിയിട്ടില്ലെന്ന് ഞാൻ പറഞ്ഞപ്പോൾ ഞാൻ കള്ളം പറഞ്ഞില്ല. എന്തുകൊണ്ടാണ് Ethereum-ലും EOS-ലും ഇത്രയധികം ചൂതാട്ട ആപ്ലിക്കേഷനുകൾ ഉള്ളത്? ഇത് നിങ്ങളെ ആശ്ചര്യപ്പെടുത്തുന്നത് പോലെ എന്നെയും ആശ്ചര്യപ്പെടുത്തുന്നു, തികച്ചും നിർണ്ണായക പരിതസ്ഥിതിയിൽ അവർക്ക് ഇത്രയധികം "സ്ഥിരമായ" ക്രമക്കേടുകൾ എവിടെ നിന്ന് ലഭിച്ചു?

ബ്ലോക്ക്‌ചെയിനിൽ ക്രമരഹിതത നേടാനുള്ള പ്രിയപ്പെട്ട മാർഗം ബ്ലോക്കിൽ നിന്ന് ചിലതരം "പ്രവചനാതീതമായ" വിവരങ്ങൾ എടുത്ത് അതിനെ അടിസ്ഥാനമാക്കി ക്രമരഹിതമായ ഒന്ന് ഉണ്ടാക്കുക എന്നതാണ് - ഒന്നോ അതിലധികമോ മൂല്യങ്ങൾ ഹാഷ് ചെയ്യുന്നതിലൂടെ. അത്തരം സ്കീമുകളുടെ പ്രശ്നങ്ങളെക്കുറിച്ചുള്ള നല്ല ലേഖനം ഇവിടെ. നിങ്ങൾക്ക് ബ്ലോക്കിലെ "പ്രവചനാതീതമായ" മൂല്യങ്ങളിൽ ഏതെങ്കിലും എടുക്കാം, ഉദാഹരണത്തിന്, ബ്ലോക്ക് ഹാഷ്, ഇടപാടുകളുടെ എണ്ണം, നെറ്റ്‌വർക്ക് സങ്കീർണ്ണത, മുൻകൂട്ടി അറിയാത്ത മറ്റ് മൂല്യങ്ങൾ. തുടർന്ന് അവ ഒന്നോ അതിലധികമോ ഹാഷ് ചെയ്യുക, കൂടാതെ, സൈദ്ധാന്തികമായി, നിങ്ങൾക്ക് ഒരു യഥാർത്ഥ റാൻഡം ലഭിക്കണം. നിങ്ങളുടെ സ്കീം "പോസ്റ്റ് ക്വാണ്ടം സുരക്ഷിതം" ആണെന്ന് നിങ്ങൾക്ക് വൈറ്റ്പേപ്പറിലേക്ക് ചേർക്കാനും കഴിയും (ക്വാണ്ടം-പ്രൂഫ് ഹാഷ് ഫംഗ്ഷനുകൾ ഉള്ളതിനാൽ :)).

എന്നാൽ പോസ്‌റ്റ് ക്വാണ്ടം സെക്യൂരിറ്റി ഹാഷുകൾ പോലും പോരാ, അയ്യോ. PVRB-യുടെ ആവശ്യകതകളിലാണ് രഹസ്യം, മുമ്പത്തെ ലേഖനത്തിൽ നിന്ന് ഞാൻ അവരെ ഓർമ്മിപ്പിക്കട്ടെ:

1. ഫലത്തിന് ഒരു ഏകീകൃത വിതരണം ഉണ്ടായിരിക്കണം, അതായത് ശക്തമായ ക്രിപ്‌റ്റോഗ്രഫി അടിസ്ഥാനമാക്കിയുള്ളതായിരിക്കണം.
2. ഫലത്തിന്റെ ബിറ്റുകളൊന്നും നിയന്ത്രിക്കാൻ സാധ്യമല്ല. തൽഫലമായി, ഫലം മുൻകൂട്ടി പ്രവചിക്കാൻ കഴിയില്ല.
3. പ്രോട്ടോക്കോളിൽ പങ്കെടുക്കാതെ അല്ലെങ്കിൽ ആക്രമണ സന്ദേശങ്ങൾ ഉപയോഗിച്ച് നെറ്റ്‌വർക്ക് ഓവർലോഡ് ചെയ്തുകൊണ്ട് നിങ്ങൾക്ക് ജനറേഷൻ പ്രോട്ടോക്കോൾ അട്ടിമറിക്കാൻ കഴിയില്ല.
4. മേൽപ്പറഞ്ഞവയെല്ലാം അനുവദനീയമായ സത്യസന്ധമല്ലാത്ത പ്രോട്ടോക്കോൾ പങ്കാളികളുടെ (ഉദാഹരണത്തിന്, പങ്കെടുക്കുന്നവരുടെ 1/3) കൂട്ടുകെട്ടിനെ പ്രതിരോധിക്കണം.

ഈ സാഹചര്യത്തിൽ, ആവശ്യകത 1 മാത്രം നിറവേറ്റപ്പെടുന്നു, കൂടാതെ 2 ആവശ്യകതകൾ പാലിക്കപ്പെടുന്നില്ല, ബ്ലോക്കിൽ നിന്ന് പ്രവചനാതീതമായ മൂല്യങ്ങൾ ഹാഷ് ചെയ്യുന്നതിലൂടെ, ഞങ്ങൾക്ക് ഒരു ഏകീകൃത വിതരണവും നല്ല ക്രമരഹിതവും ലഭിക്കും. എന്നാൽ ബിപിക്ക് കുറഞ്ഞത് "ബ്ലോക്ക് പ്രസിദ്ധീകരിക്കണോ വേണ്ടയോ" എന്ന ഓപ്ഷൻ ഉണ്ട്. അതിനാൽ, ബിപിക്ക് കുറഞ്ഞത് രണ്ട് റാൻഡം ഓപ്ഷനുകളിൽ നിന്ന് തിരഞ്ഞെടുക്കാനാകും: "സ്വന്തം", മറ്റാരെങ്കിലും ബ്ലോക്ക് ചെയ്താൽ അത് മാറും. ഒരു ബ്ലോക്ക് പ്രസിദ്ധീകരിക്കുകയും അത് ചെയ്യണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കുകയും ചെയ്‌താൽ എന്ത് സംഭവിക്കുമെന്ന് ബിപിക്ക് മുൻകൂട്ടി "സ്നൂപ്പ്" ചെയ്യാൻ കഴിയും. അങ്ങനെ, കളിക്കുമ്പോൾ, ഉദാഹരണത്തിന്, റൗലറ്റിൽ "ഇരട്ട-ഒറ്റ" അല്ലെങ്കിൽ "ചുവപ്പ് / കറുപ്പ്", അവൻ ഒരു വിജയം കണ്ടാൽ മാത്രമേ ഒരു ബ്ലോക്ക് പ്രസിദ്ധീകരിക്കാൻ കഴിയൂ. ഉദാഹരണത്തിന്, "ഭാവിയിൽ നിന്നുള്ള" ഒരു ബ്ലോക്ക് ഹാഷ് ഉപയോഗിക്കുന്നതിനുള്ള തന്ത്രവും ഇത് പ്രവർത്തനരഹിതമാക്കുന്നു. ഈ സാഹചര്യത്തിൽ, “റാൻഡം ഉപയോഗിക്കും, ഇത് നിലവിലെ ഡാറ്റയും ഭാവി ബ്ലോക്കിൻ്റെ ഹാഷും ഉയരത്തിൽ ഹാഷ് ചെയ്യുന്നതിലൂടെ ലഭിക്കുന്നു, ഉദാഹരണത്തിന്, N + 42, ഇവിടെ N ആണ് നിലവിലെ ബ്ലോക്ക് ഉയരം. ഇത് സ്കീമിനെ അൽപ്പം ബലപ്പെടുത്തുന്നു, എന്നാൽ ഭാവിയിലെങ്കിലും, തടയണോ പ്രസിദ്ധീകരിക്കണോ എന്ന് തിരഞ്ഞെടുക്കാൻ ബിപിയെ അനുവദിക്കുന്നു.

ഈ സാഹചര്യത്തിൽ ബിപി സോഫ്റ്റ്വെയർ കൂടുതൽ സങ്കീർണ്ണമായിത്തീരുന്നു, പക്ഷേ അത്രയൊന്നും അല്ല. ലളിതമായി, ഒരു ബ്ലോക്കിൽ ഒരു ഇടപാട് സാധൂകരിക്കുകയും ഉൾപ്പെടുത്തുകയും ചെയ്യുമ്പോൾ, ഒരു വിജയമുണ്ടോ എന്നറിയാൻ ഒരു ദ്രുത പരിശോധനയുണ്ട്, കൂടാതെ, വിജയിക്കാനുള്ള ഉയർന്ന സാധ്യത നേടുന്നതിന് ഒരു ഇടപാട് പാരാമീറ്ററുകൾ തിരഞ്ഞെടുക്കാനും സാധ്യതയുണ്ട്. അതേ സമയം, അത്തരം കൃത്രിമങ്ങൾക്കായി ഒരു സ്മാർട്ട് ബിപി പിടിക്കുന്നത് മിക്കവാറും അസാധ്യമാണ്;

അതിനാൽ ബ്ലോക്കിൽ നിന്നുള്ള വിവരങ്ങൾ ഉപയോഗിക്കുന്ന രീതികൾ PVRB യുടെ സാർവത്രിക നടപ്പാക്കൽ എന്ന നിലയിൽ അനുയോജ്യമല്ല. ഒരു പരിമിത പതിപ്പിൽ, ബെറ്റ് സൈസുകളിൽ നിയന്ത്രണങ്ങൾ, കളിക്കാരുടെ എണ്ണത്തിലും കൂടാതെ/അല്ലെങ്കിൽ KYC രജിസ്ട്രേഷനിലുമുള്ള നിയന്ത്രണങ്ങൾ (ഒന്നിലധികം വിലാസങ്ങൾ ഉപയോഗിക്കുന്നതിൽ നിന്ന് ഒരു കളിക്കാരനെ തടയുന്നതിന്), ഈ സ്കീമുകൾക്ക് ചെറിയ ഗെയിമുകൾക്കായി പ്രവർത്തിക്കാൻ കഴിയും, എന്നാൽ കൂടുതലൊന്നും.

PVRB, പ്രതിബദ്ധത-വെളിപ്പെടുത്തൽ.

ശരി, ഹാഷിംഗിനും ബ്ലോക്ക് ഹാഷിൻ്റെയും മറ്റ് വേരിയബിളുകളുടെയും ആപേക്ഷികമായ പ്രവചനാതീതതയ്ക്കും നന്ദി. മുൻനിരയിലുള്ള ഖനിത്തൊഴിലാളികളുടെ പ്രശ്നം നിങ്ങൾ പരിഹരിക്കുകയാണെങ്കിൽ, നിങ്ങൾക്ക് കൂടുതൽ അനുയോജ്യമായ എന്തെങ്കിലും ലഭിക്കണം. നമുക്ക് ഈ സ്കീമിലേക്ക് ഉപയോക്താക്കളെ ചേർക്കാം - അവർ ക്രമരഹിതമായി സ്വാധീനിക്കട്ടെ: ഐടി സിസ്റ്റങ്ങളിലെ ഏറ്റവും ക്രമരഹിതമായ കാര്യം ഉപയോക്താക്കളുടെ പ്രവർത്തനങ്ങളാണെന്ന് ഏതൊരു സാങ്കേതിക പിന്തുണ ജീവനക്കാരനും നിങ്ങളോട് പറയും :)

ഉപയോക്താക്കൾ റാൻഡം നമ്പറുകൾ അയയ്‌ക്കുകയും ഫലം കണക്കാക്കുകയും ചെയ്യുമ്പോൾ ഒരു നിഷ്‌കളങ്കമായ സ്കീം, ഉദാഹരണത്തിന്, അവരുടെ തുകയുടെ ഒരു ഹാഷ് അനുയോജ്യമല്ല. ഈ സാഹചര്യത്തിൽ, അവസാന കളിക്കാരന്, സ്വന്തം റാൻഡം തിരഞ്ഞെടുക്കുന്നതിലൂടെ, ഫലം എന്തായിരിക്കുമെന്ന് നിയന്ത്രിക്കാനാകും. അതുകൊണ്ടാണ് വളരെ വ്യാപകമായി ഉപയോഗിക്കുന്ന കമ്മിറ്റ്-വെളിപ്പെടുത്തൽ പാറ്റേൺ ഉപയോഗിക്കുന്നത്. പങ്കെടുക്കുന്നവർ ആദ്യം അവരുടെ റാൻഡമുകളിൽ നിന്ന് (കമ്മിറ്റുകൾ) ഹാഷുകൾ അയയ്ക്കുന്നു, തുടർന്ന് ക്രമരഹിതമായവ സ്വയം തുറക്കുന്നു (വെളിപ്പെടുത്തുന്നു). ആവശ്യമായ കമ്മിറ്റുകൾ ശേഖരിച്ചതിനുശേഷം മാത്രമേ "വെളിപ്പെടുത്തൽ" ഘട്ടം ആരംഭിക്കുകയുള്ളൂ, അതിനാൽ പങ്കെടുക്കുന്നവർക്ക് അവർ മുമ്പ് അയച്ച റാൻഡം ഹാഷ് കൃത്യമായി അയയ്ക്കാൻ കഴിയും. ഇപ്പോൾ നമുക്ക് ഇതെല്ലാം ഒരു ബ്ലോക്കിൻ്റെ പാരാമീറ്ററുകൾ ഉപയോഗിച്ച് ഒരുമിച്ച് ചേർക്കാം, ഭാവിയിൽ നിന്ന് എടുത്തതിനേക്കാൾ മികച്ചത് (ഭാവിയിലെ ബ്ലോക്കുകളിലൊന്നിൽ മാത്രമേ ക്രമരഹിതത കണ്ടെത്താൻ കഴിയൂ), കൂടാതെ വോയില - ക്രമരഹിതം തയ്യാറാണ്! ഇപ്പോൾ ഏതൊരു കളിക്കാരനും തത്ഫലമായുണ്ടാകുന്ന യാദൃശ്ചികതയെ സ്വാധീനിക്കുന്നു, കൂടാതെ സ്വന്തം, മുൻകൂട്ടി അറിയാത്ത, ക്രമരഹിതമായി അതിനെ അസാധുവാക്കിക്കൊണ്ട് ക്ഷുദ്രകരമായ ബിപിയെ "തോൽപ്പിക്കാൻ" കഴിയും... വെളിപ്പെടുത്തുന്ന ഘട്ടത്തിൽ അത് തുറക്കാതെ പ്രോട്ടോക്കോൾ അട്ടിമറിക്കുന്നതിൽ നിന്നും നിങ്ങൾക്ക് സംരക്ഷണം ചേർക്കാം - ലളിതമായി ഇടപാട് നടത്തുമ്പോൾ ഒരു നിശ്ചിത തുക അറ്റാച്ചുചെയ്യാൻ ആവശ്യപ്പെടുന്നതിലൂടെ - ഒരു സെക്യൂരിറ്റി ഡെപ്പോസിറ്റ്, അത് വെളിപ്പെടുത്തുന്ന നടപടിക്രമത്തിൽ മാത്രം തിരികെ നൽകും. ഈ സാഹചര്യത്തിൽ, ചെയ്യുന്നതും വെളിപ്പെടുത്താത്തതും ലാഭകരമല്ല.

ഇതൊരു നല്ല ശ്രമമായിരുന്നു, ഗെയിമിംഗ് DApps-ലും ഇത്തരം സ്കീമുകൾ നിലവിലുണ്ട്, പക്ഷേ അയ്യോ, ഇത് വീണ്ടും പര്യാപ്തമല്ല. ഇപ്പോൾ ഖനിത്തൊഴിലാളിക്ക് മാത്രമല്ല, പ്രോട്ടോക്കോളിലെ ഏതൊരു പങ്കാളിക്കും ഫലത്തെ സ്വാധീനിക്കാൻ കഴിയും. കുറഞ്ഞ വേരിയബിളിറ്റിയിലും ചിലവിലും മൂല്യം തന്നെ നിയന്ത്രിക്കുന്നത് ഇപ്പോഴും സാധ്യമാണ്, പക്ഷേ, ഖനിത്തൊഴിലാളിയുടെ കാര്യത്തിലെന്നപോലെ, ഡ്രോയിംഗിൻ്റെ ഫലങ്ങൾ PVRB പ്രോട്ടോക്കോളിൽ പങ്കെടുക്കുന്നതിനുള്ള ഫീസിനേക്കാൾ വിലപ്പെട്ടതാണെങ്കിൽ, ക്രമരഹിതം -നിർമ്മാതാവിന് (ആർപി) വെളിപ്പെടുത്തണമോ എന്ന് തീരുമാനിക്കാൻ കഴിയും കൂടാതെ കുറഞ്ഞത് രണ്ട് ക്രമരഹിതമായ ഓപ്ഷനുകളിൽ നിന്നെങ്കിലും തിരഞ്ഞെടുക്കാനാകും.
എന്നാൽ കുറ്റം ചെയ്യുന്നവരെയും വെളിപ്പെടുത്താത്തവരെയും ശിക്ഷിക്കാൻ സാധിച്ചു, ഈ പദ്ധതി ഉപയോഗപ്രദമാകും. അതിൻ്റെ ലാളിത്യം ഒരു ഗുരുതരമായ നേട്ടമാണ് - കൂടുതൽ ഗുരുതരമായ പ്രോട്ടോക്കോളുകൾക്ക് കൂടുതൽ ശക്തമായ കണക്കുകൂട്ടലുകൾ ആവശ്യമാണ്.

പിവിആർബിയും ഡിറ്റർമിനിസ്റ്റിക് ഒപ്പുകളും.

"പ്രീമേജ്" നൽകിയാൽ സ്വാധീനിക്കാൻ കഴിയാത്ത ഒരു കപട-റാൻഡം നമ്പർ നൽകാൻ ആർപിയെ നിർബന്ധിക്കാൻ മറ്റൊരു മാർഗമുണ്ട് - ഇത് ഒരു നിർണ്ണായക ഒപ്പാണ്. അത്തരമൊരു ഒപ്പ്, ഉദാഹരണത്തിന്, RSA ആണ്, അത് ECS അല്ല. RP-ന് ഒരു ജോടി കീകൾ ഉണ്ടെങ്കിൽ: RSA, ECC, അവൻ തൻ്റെ സ്വകാര്യ കീ ഉപയോഗിച്ച് ഒരു നിശ്ചിത മൂല്യം ഒപ്പിടുകയാണെങ്കിൽ, RSA-യുടെ കാര്യത്തിൽ അയാൾക്ക് ഒരു ഒപ്പ് മാത്രമേ ലഭിക്കൂ, ECS-ൻ്റെ കാര്യത്തിൽ അയാൾക്ക് എത്ര വേണമെങ്കിലും സൃഷ്ടിക്കാൻ കഴിയും. വ്യത്യസ്ത സാധുവായ ഒപ്പുകൾ. കാരണം, ഒരു ഇസിഎസ് സിഗ്നേച്ചർ സൃഷ്‌ടിക്കുമ്പോൾ, ഒരു റാൻഡം നമ്പർ ഉപയോഗിക്കുന്നു, സൈനർ തിരഞ്ഞെടുക്കുന്നു, കൂടാതെ അത് ഏത് വിധത്തിലും തിരഞ്ഞെടുക്കാം, സൈനറിന് നിരവധി ഒപ്പുകളിൽ ഒന്ന് തിരഞ്ഞെടുക്കാനുള്ള അവസരം നൽകുന്നു. RSA-യുടെ കാര്യത്തിൽ: "ഒരു ഇൻപുട്ട് മൂല്യം" + "ഒരു കീ ജോഡി" = "ഒരു ഒപ്പ്". മറ്റൊരു ആർപിക്ക് എന്ത് ഒപ്പ് ലഭിക്കുമെന്ന് പ്രവചിക്കാൻ കഴിയില്ല, അതിനാൽ ഒരേ മൂല്യത്തിൽ ഒപ്പിട്ട നിരവധി പങ്കാളികളുടെ ആർഎസ്എ ഒപ്പുകൾ സംയോജിപ്പിച്ച് നിർണ്ണായക ഒപ്പുകളുള്ള ഒരു പിവിആർബി സംഘടിപ്പിക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, മുമ്പത്തെ ക്രമരഹിതം. ഈ സ്കീം ധാരാളം വിഭവങ്ങൾ ലാഭിക്കുന്നു, കാരണം ഒപ്പുകൾ പ്രോട്ടോക്കോൾ അനുസരിച്ച് ശരിയായ പെരുമാറ്റത്തിൻ്റെ സ്ഥിരീകരണവും ക്രമരഹിതതയുടെ ഉറവിടവുമാണ്.

എന്നിരുന്നാലും, നിർണ്ണായക ഒപ്പുകളുണ്ടെങ്കിൽപ്പോലും, "അവസാന നടൻ" എന്ന പ്രശ്നത്തിന് സ്കീം ഇപ്പോഴും ദുർബലമാണ്. അവസാനം പങ്കെടുക്കുന്നയാൾക്ക് ഒപ്പ് പ്രസിദ്ധീകരിക്കണോ വേണ്ടയോ എന്ന് തീരുമാനിക്കാം, അതുവഴി ഫലം നിയന്ത്രിക്കാം. നിങ്ങൾക്ക് സ്കീം പരിഷ്കരിക്കാനും അതിലേക്ക് ബ്ലോക്ക് ഹാഷുകൾ ചേർക്കാനും റൗണ്ടുകൾ ഉണ്ടാക്കാനും കഴിയും, അതുവഴി ഫലം മുൻകൂട്ടി പ്രവചിക്കാൻ കഴിയില്ല, എന്നാൽ ഈ സാങ്കേതികതകളെല്ലാം, നിരവധി പരിഷ്കാരങ്ങൾ കണക്കിലെടുക്കുമ്പോൾ പോലും, ഒരു പങ്കാളിയുടെ സ്വാധീനത്തിൻ്റെ പ്രശ്നം പരിഹരിക്കപ്പെടാതെ അവശേഷിക്കുന്നു. അവിശ്വസനീയമായ അന്തരീക്ഷത്തിൽ കലാശിക്കുകയും സാമ്പത്തിക, സമയ പരിമിതികൾക്ക് കീഴിൽ മാത്രമേ പ്രവർത്തിക്കാൻ കഴിയൂ. കൂടാതെ, RSA കീകളുടെ (1024, 2048 ബിറ്റുകൾ) വലിപ്പം വളരെ വലുതാണ്, കൂടാതെ ബ്ലോക്ക്ചെയിൻ ഇടപാടുകളുടെ വലുപ്പം വളരെ പ്രധാനപ്പെട്ട ഒരു പരാമീറ്ററാണ്. പ്രത്യക്ഷത്തിൽ പ്രശ്നം പരിഹരിക്കാൻ ലളിതമായ മാർഗമില്ല, നമുക്ക് മുന്നോട്ട് പോകാം.

PVRB, രഹസ്യ പങ്കിടൽ പദ്ധതികൾ

ക്രിപ്‌റ്റോഗ്രഫിയിൽ, നെറ്റ്‌വർക്കിനെ ഒരേയൊരു PVRB മൂല്യം അംഗീകരിക്കാൻ അനുവദിക്കുന്ന സ്കീമുകളുണ്ട്, അതേസമയം അത്തരം സ്കീമുകൾ ചില പങ്കാളികളുടെ ഏതെങ്കിലും ക്ഷുദ്ര പ്രവർത്തനങ്ങളെ പ്രതിരോധിക്കും. ഷമീറിൻ്റെ രഹസ്യ പങ്കിടൽ സ്കീമാണ് പരിചയപ്പെടേണ്ട ഉപയോഗപ്രദമായ ഒരു പ്രോട്ടോക്കോൾ. ഒരു രഹസ്യത്തെ (ഉദാഹരണത്തിന്, ഒരു രഹസ്യ കീ) പല ഭാഗങ്ങളായി വിഭജിക്കാനും ഈ ഭാഗങ്ങൾ N പങ്കാളികൾക്ക് വിതരണം ചെയ്യാനും ഇത് സഹായിക്കുന്നു. N-ൽ നിന്നുള്ള M ഭാഗങ്ങൾ വീണ്ടെടുക്കാൻ പര്യാപ്തമായ വിധത്തിലാണ് രഹസ്യം വിതരണം ചെയ്തിരിക്കുന്നത്, ഇവ ഏതെങ്കിലും M ഭാഗങ്ങൾ ആകാം. വിരലുകളിലാണെങ്കിൽ, ഒരു അജ്ഞാത ഫംഗ്‌ഷൻ്റെ ഗ്രാഫ് ഉണ്ടെങ്കിൽ, പങ്കെടുക്കുന്നവർ ഗ്രാഫിൽ പോയിൻ്റുകൾ കൈമാറ്റം ചെയ്യുന്നു, കൂടാതെ M പോയിൻ്റുകൾ ലഭിച്ചതിനുശേഷം, മുഴുവൻ പ്രവർത്തനവും പുനഃസ്ഥാപിക്കാൻ കഴിയും.
നല്ല വിശദീകരണം നൽകിയിട്ടുണ്ട് വിക്കി എന്നാൽ നിങ്ങളുടെ തലയിൽ പ്രോട്ടോക്കോൾ പ്ലേ ചെയ്യുന്നതിനായി ഇത് പ്രായോഗികമായി കളിക്കുന്നത് ഉപയോഗപ്രദമാണ് ഡെമോ പേജ്.

FSSS (ഫിയറ്റ്-ഷമീർ രഹസ്യ പങ്കിടൽ) സ്കീം അതിൻ്റെ ശുദ്ധമായ രൂപത്തിൽ ബാധകമാണെങ്കിൽ, അത് ഒരു നശിപ്പിക്കാനാവാത്ത PVRB ആയിരിക്കും. ഏറ്റവും ലളിതമായ രൂപത്തിൽ, പ്രോട്ടോക്കോൾ ഇതുപോലെയാകാം:

• ഓരോ പങ്കാളിയും അവരുടേതായ ക്രമരഹിതമായി സൃഷ്ടിക്കുകയും അതിൽ നിന്നുള്ള ഷെയറുകൾ മറ്റ് പങ്കാളികൾക്ക് വിതരണം ചെയ്യുകയും ചെയ്യുന്നു
• ഓരോ പങ്കാളിയും മറ്റ് പങ്കാളികളുടെ രഹസ്യങ്ങളുടെ ഭാഗം വെളിപ്പെടുത്തുന്നു
• ഒരു പങ്കാളിക്ക് M-ൽ കൂടുതൽ ഷെയറുകളുണ്ടെങ്കിൽ, ഈ പങ്കാളിയുടെ എണ്ണം കണക്കാക്കാം, വെളിപ്പെടുത്തിയ പങ്കാളികളുടെ സെറ്റ് പരിഗണിക്കാതെ തന്നെ അത് അദ്വിതീയമായിരിക്കും
• വെളിപ്പെടുത്തിയ ക്രമരഹിതങ്ങളുടെ സംയോജനമാണ് ആവശ്യമുള്ള PVRB

ഇവിടെ, ക്രമരഹിതമായ വെളിപ്പെടുത്തൽ പരിധിയുടെ നേട്ടം അവനെ മാത്രം ആശ്രയിക്കുന്ന സന്ദർഭങ്ങളിലൊഴികെ, ഒരു വ്യക്തിഗത പങ്കാളി പ്രോട്ടോക്കോളിൻ്റെ ഫലങ്ങളെ മേലിൽ സ്വാധീനിക്കുന്നില്ല. അതിനാൽ, ഈ പ്രോട്ടോക്കോൾ, പ്രോട്ടോക്കോളിൽ പ്രവർത്തിക്കുന്ന ആർപികളുടെ ആവശ്യമായ അനുപാതം ഉണ്ടെങ്കിൽ, അത് ലഭ്യമാണെങ്കിൽ, ക്രിപ്റ്റോഗ്രാഫിക് ശക്തിയുടെ ആവശ്യകതകൾ നടപ്പിലാക്കുകയും "അവസാന നടൻ" പ്രശ്നത്തെ പ്രതിരോധിക്കുകയും ചെയ്യുന്നു.

ഇതൊരു അനുയോജ്യമായ ഓപ്ഷനായിരിക്കാം, ഫിയറ്റ്-ഷമീർ രഹസ്യ പങ്കിടലിനെ അടിസ്ഥാനമാക്കിയുള്ള ഈ PVRB സ്കീം ഉദാഹരണമായി വിവരിച്ചിരിക്കുന്നത് ഇത് ലേഖനം. പക്ഷേ, മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, നിങ്ങൾ ബ്ലോക്ക്ചെയിനിൽ ഇത് പ്രയോഗിക്കാൻ ശ്രമിക്കുകയാണെങ്കിൽ, സാങ്കേതിക പരിമിതികൾ ദൃശ്യമാകും. EOS സ്മാർട്ട് കരാറിലെ പ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നതിൻ്റെ ഒരു ഉദാഹരണവും അതിൻ്റെ ഏറ്റവും പ്രധാനപ്പെട്ട ഭാഗവും ഇതാ - പ്രസിദ്ധീകരിച്ച ഷെയർ പങ്കാളിയെ പരിശോധിക്കുന്നു: കോഡ്. തെളിവ് മൂല്യനിർണ്ണയത്തിന് നിരവധി സ്കെലാർ ഗുണനങ്ങൾ ആവശ്യമാണെന്നും ഉപയോഗിക്കുന്ന സംഖ്യകൾ വളരെ വലുതാണെന്നും കോഡിൽ നിന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. ബ്ലോക്ക്-പ്രൊഡ്യൂസർ ഇടപാട് പ്രോസസ്സ് ചെയ്യുന്ന നിമിഷത്തിലാണ് ബ്ലോക്ക്ചെയിനുകളിൽ, സ്ഥിരീകരണം സംഭവിക്കുന്നതെന്ന് മനസ്സിലാക്കണം, പൊതുവേ, ഏതൊരു പങ്കാളിയും പ്രോട്ടോക്കോളിൻ്റെ കൃത്യത എളുപ്പത്തിൽ പരിശോധിക്കണം, അതിനാൽ സ്ഥിരീകരണ പ്രവർത്തനത്തിൻ്റെ വേഗതയുടെ ആവശ്യകതകൾ വളരെ ഗുരുതരമാണ്. . ഈ ഓപ്‌ഷനിൽ, ഇടപാട് പരിധിയിൽ (0.5 സെക്കൻഡ്) പരിശോധന അനുയോജ്യമല്ലാത്തതിനാൽ, ഓപ്ഷൻ ഫലപ്രദമല്ലെന്ന് തെളിഞ്ഞു.

പൊതുവെ, ബ്ലോക്ക്‌ചെയിനിലെ ഏതെങ്കിലും നൂതന ക്രിപ്‌റ്റോഗ്രാഫിക് സ്കീമുകൾ ഉപയോഗിക്കുന്നതിനുള്ള ഏറ്റവും പ്രധാനപ്പെട്ട ആവശ്യകതകളിലൊന്നാണ് സ്ഥിരീകരണ കാര്യക്ഷമത. തെളിവുകൾ സൃഷ്ടിക്കൽ, സന്ദേശങ്ങൾ തയ്യാറാക്കൽ - ഈ നടപടിക്രമങ്ങൾ ഓഫ്-ചെയിൻ എടുത്ത് ഉയർന്ന പ്രവർത്തനക്ഷമതയുള്ള കമ്പ്യൂട്ടറുകളിൽ നടത്താം, എന്നാൽ സ്ഥിരീകരണം മറികടക്കാൻ കഴിയില്ല - ഇത് PVRB-യുടെ മറ്റൊരു പ്രധാന ആവശ്യകതയാണ്.

PVRB, ത്രെഷോൾഡ് ഒപ്പുകൾ

രഹസ്യ പങ്കിടൽ സ്കീമുമായി പരിചയപ്പെടുമ്പോൾ, "ത്രെഷോൾഡ്" എന്ന കീവേഡ് ഉപയോഗിച്ച് ഏകീകരിക്കപ്പെട്ട പ്രോട്ടോക്കോളുകളുടെ ഒരു മുഴുവൻ ക്ലാസ് ഞങ്ങൾ കണ്ടെത്തി. ചില വിവരങ്ങളുടെ വെളിപ്പെടുത്തലിന് N-ൽ നിന്നുള്ള M സത്യസന്ധരായ പങ്കാളികളുടെ പങ്കാളിത്തം ആവശ്യമായി വരുമ്പോൾ, സത്യസന്ധരായ പങ്കാളികളുടെ കൂട്ടം N ൻ്റെ ഏകപക്ഷീയമായ ഉപവിഭാഗമാകുമ്പോൾ, നമ്മൾ "ത്രെഷോൾഡ്" സ്കീമുകളെ കുറിച്ച് സംസാരിക്കുന്നു. "അവസാന നടൻ" പ്രശ്നം കൈകാര്യം ചെയ്യാൻ ഞങ്ങളെ അനുവദിക്കുന്നത് അവരാണ്, ഇപ്പോൾ ആക്രമണകാരി തൻ്റെ രഹസ്യത്തിൻ്റെ ഭാഗം വെളിപ്പെടുത്തുന്നില്ലെങ്കിൽ, മറ്റൊരു, സത്യസന്ധനായ പങ്കാളി അവനുവേണ്ടി അത് ചെയ്യും. പങ്കെടുക്കുന്നവരിൽ ചിലർ പ്രോട്ടോക്കോൾ അട്ടിമറിച്ചാലും, ഈ സ്കീമുകൾ ഒരേയൊരു അർത്ഥത്തിൽ ഉടമ്പടി അനുവദിക്കുന്നു.

ഡിറ്റർമിനിസ്റ്റിക് സിഗ്നേച്ചറുകളുടെയും ത്രെഷോൾഡ് സ്കീമുകളുടെയും സംയോജനം PVRB നടപ്പിലാക്കുന്നതിന് വളരെ സൗകര്യപ്രദവും വാഗ്ദാനപ്രദവുമായ ഒരു സ്കീം വികസിപ്പിക്കുന്നത് സാധ്യമാക്കി - ഇവ ഡിറ്റർമിനിസ്റ്റിക് ത്രെഷോൾഡ് ഒപ്പുകളാണ്. ഇവിടെ ഒരു ലേഖനം ത്രെഷോൾഡ് സിഗ്നേച്ചറുകളുടെ വിവിധ ഉപയോഗങ്ങളെ കുറിച്ച്, ഇതാ മറ്റൊരു നല്ല ഒന്ന് നീണ്ട വായന ഡാഷിൽ നിന്ന്.

അവസാന ലേഖനം BLS സിഗ്നേച്ചറുകൾ വിവരിക്കുന്നു (BLS എന്നാൽ Boneh-Lynn-Shacham, നോക്കൂ ലേഖനം), പ്രോഗ്രാമർമാർക്ക് വളരെ പ്രധാനപ്പെട്ടതും വളരെ സൗകര്യപ്രദവുമായ ഗുണമേന്മയുണ്ട് - പൊതു, രഹസ്യം, പൊതു കീകൾ, BLS ഒപ്പുകൾ എന്നിവ ലളിതമായ ഗണിതശാസ്ത്ര പ്രവർത്തനങ്ങൾ ഉപയോഗിച്ച് പരസ്പരം സംയോജിപ്പിക്കാൻ കഴിയും, അതേസമയം അവയുടെ കോമ്പിനേഷനുകൾ സാധുവായ കീകളും ഒപ്പുകളും നിലനിൽക്കും, ഇത് പലതും എളുപ്പത്തിൽ സമാഹരിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഒപ്പുകൾ ഒന്നിലേക്കും നിരവധി പൊതു കീകൾ ഒന്നിലേക്കും. അവ നിർണ്ണായകവും ഒരേ ഇൻപുട്ട് ഡാറ്റയ്‌ക്ക് ഒരേ ഫലം നൽകുന്നു. ഈ ഗുണനിലവാരം കാരണം, BLS സിഗ്നേച്ചറുകളുടെ കോമ്പിനേഷനുകൾ തന്നെ സാധുവായ കീകളാണ്, ഇത് Mth തുറക്കുന്നത് വരെ നിർണ്ണായകവും പൊതുവായി പരിശോധിക്കാവുന്നതും പ്രവചനാതീതവുമായ ഒരേയൊരു ഒപ്പ് മാത്രം നിർമ്മിക്കുന്ന ഒരു ഓപ്‌ഷൻ നടപ്പിലാക്കാൻ അനുവദിക്കുന്നു. പങ്കാളി .

ത്രെഷോൾഡ് BLS ഒപ്പുകളുള്ള ഒരു സ്കീമിൽ, ഓരോ പങ്കാളിയും BLS ഉപയോഗിച്ച് എന്തെങ്കിലും ഒപ്പിടുന്നു (ഉദാഹരണത്തിന്, മുമ്പത്തെ ക്രമരഹിതം), സാധാരണ ത്രെഷോൾഡ് ഒപ്പ് ആവശ്യമുള്ള ക്രമരഹിതമാണ്. BLS സിഗ്‌നേച്ചറുകളുടെ ക്രിപ്‌റ്റോഗ്രാഫിക് പ്രോപ്പർട്ടികൾ ക്രമരഹിതമായ ഗുണനിലവാരത്തിനുള്ള ആവശ്യകതകൾ നിറവേറ്റുന്നു, ത്രെഷോൾഡ് ഭാഗം "അവസാന-നടനിൽ" നിന്ന് പരിരക്ഷിക്കുന്നു, കൂടാതെ കീകളുടെ തനതായ സംയോജനം പ്രോട്ടോക്കോൾ സന്ദേശങ്ങളുടെ കാര്യക്ഷമമായ സംയോജനം അനുവദിക്കുന്ന കൂടുതൽ രസകരമായ അൽഗോരിതങ്ങൾ നടപ്പിലാക്കുന്നത് സാധ്യമാക്കുന്നു. .

അതിനാൽ, നിങ്ങൾ നിങ്ങളുടെ ബ്ലോക്ക്ചെയിനിൽ PVRB നിർമ്മിക്കുകയാണെങ്കിൽ, നിങ്ങൾ മിക്കവാറും BLS ത്രെഷോൾഡ് സിഗ്നേച്ചർ സ്കീമിൽ അവസാനിക്കും, നിരവധി പ്രോജക്റ്റുകൾ ഇതിനകം ഇത് ഉപയോഗിക്കുന്നു. ഉദാഹരണത്തിന്, DFinity (ഇവിടെ സർക്യൂട്ട് നടപ്പിലാക്കുന്ന ബെഞ്ച്മാർക്ക്, കൂടാതെ ഇവിടെ പരിശോധിക്കാവുന്ന രഹസ്യ പങ്കിടലിൻ്റെ ഉദാഹരണം നടപ്പിലാക്കൽ), അല്ലെങ്കിൽ Keep.network (അവരുടെ റാൻഡം ബീക്കൺ ഇതാ മഞ്ഞപേപ്പർ, ഇവിടെ ഉദാഹരണം പ്രോട്ടോക്കോൾ നൽകുന്ന സ്മാർട്ട് കരാർ).

PVRB നടപ്പിലാക്കൽ

നിർഭാഗ്യവശാൽ, PVRB ബ്ലോക്ക്ചെയിനുകളിൽ നടപ്പിലാക്കിയ ഒരു റെഡിമെയ്ഡ് പ്രോട്ടോക്കോൾ അതിൻ്റെ സുരക്ഷയും സ്ഥിരതയും തെളിയിച്ചതായി ഞങ്ങൾ ഇപ്പോഴും കാണുന്നില്ല. പ്രോട്ടോക്കോളുകൾ തന്നെ തയ്യാറാണെങ്കിലും, നിലവിലുള്ള പരിഹാരങ്ങളിൽ സാങ്കേതികമായി അവ പ്രയോഗിക്കുന്നത് എളുപ്പമല്ല. കേന്ദ്രീകൃത സിസ്റ്റങ്ങൾക്ക്, PVRB അർത്ഥമാക്കുന്നില്ല, കൂടാതെ വികേന്ദ്രീകൃതമായവ എല്ലാ കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങളിലും കർശനമായി പരിമിതപ്പെടുത്തിയിരിക്കുന്നു: CPU, മെമ്മറി, സംഭരണം, I/O. ഒരു PVRB രൂപകൽപന ചെയ്യുന്നത്, ചുരുങ്ങിയത് ചില പ്രായോഗിക ബ്ലോക്ക്ചെയിനുകൾക്കെങ്കിലും എല്ലാ ആവശ്യകതകളും നിറവേറ്റുന്ന എന്തെങ്കിലും സൃഷ്ടിക്കുന്നതിന് വ്യത്യസ്ത പ്രോട്ടോക്കോളുകളുടെ സംയോജനമാണ്. ഒരു പ്രോട്ടോക്കോൾ കൂടുതൽ കാര്യക്ഷമമായി കണക്കാക്കുന്നു, എന്നാൽ ആർപികൾക്കിടയിൽ കൂടുതൽ സന്ദേശങ്ങൾ ആവശ്യമാണ്, മറ്റൊന്നിന് വളരെ കുറച്ച് സന്ദേശങ്ങൾ ആവശ്യമാണ്, എന്നാൽ ഒരു തെളിവ് സൃഷ്ടിക്കുന്നത് പതിനായിരക്കണക്കിന് മിനിറ്റുകളോ മണിക്കൂറുകളോ എടുക്കുന്ന ഒരു ജോലിയാണ്.

ഗുണനിലവാരമുള്ള PVRB തിരഞ്ഞെടുക്കുമ്പോൾ നിങ്ങൾ പരിഗണിക്കേണ്ട ഘടകങ്ങൾ ഞാൻ പട്ടികപ്പെടുത്തും:

• ക്രിപ്റ്റോഗ്രാഫിക് ശക്തി. നിങ്ങളുടെ PVRB ഒരു ബിറ്റ് പോലും നിയന്ത്രിക്കാനുള്ള കഴിവില്ലാതെ, കർശനമായി നിഷ്പക്ഷമായിരിക്കണം. ചില സ്കീമുകളിൽ ഇത് അങ്ങനെയല്ല, അതിനാൽ ഒരു ക്രിപ്റ്റോഗ്രാഫറെ വിളിക്കുക
• "അവസാന നടൻ" പ്രശ്നം. ഒന്നോ അതിലധികമോ ആർപികളെ നിയന്ത്രിക്കുന്ന ഒരു ആക്രമണകാരിക്ക് രണ്ട് ഫലങ്ങളിൽ ഒന്ന് തിരഞ്ഞെടുക്കാൻ കഴിയുന്ന ആക്രമണങ്ങളെ നിങ്ങളുടെ PVRB പ്രതിരോധിക്കണം.
• പ്രോട്ടോക്കോൾ അട്ടിമറി പ്രശ്നം. ഒന്നോ അതിലധികമോ ആർപികളെ നിയന്ത്രിക്കുന്ന ആക്രമണകാരി ക്രമരഹിതമാണോ അല്ലയോ എന്ന് തീരുമാനിക്കുന്ന ആക്രമണങ്ങളെ നിങ്ങളുടെ PVRB പ്രതിരോധിക്കണം
• സന്ദേശങ്ങളുടെ എണ്ണം പ്രശ്നം. നിങ്ങളുടെ ആർപികൾ ബ്ലോക്ക്ചെയിനിലേക്ക് ചുരുങ്ങിയത് സന്ദേശങ്ങൾ അയയ്‌ക്കുകയും "ഞാൻ കുറച്ച് വിവരങ്ങൾ അയച്ചു, ഒരു നിർദ്ദിഷ്‌ട പങ്കാളിയിൽ നിന്നുള്ള പ്രതികരണത്തിനായി ഞാൻ കാത്തിരിക്കുകയാണ്" എന്നതുപോലുള്ള സാഹചര്യങ്ങൾ കഴിയുന്നത്ര സിൻക്രണസ് പ്രവർത്തനങ്ങൾ ഒഴിവാക്കുകയും വേണം. p2p നെറ്റ്‌വർക്കുകളിൽ, പ്രത്യേകിച്ച് ഭൂമിശാസ്ത്രപരമായി ചിതറിക്കിടക്കുന്നവയിൽ, നിങ്ങൾ പെട്ടെന്നുള്ള പ്രതികരണം കണക്കാക്കരുത്
• കമ്പ്യൂട്ടേഷണൽ സങ്കീർണ്ണത പ്രശ്നം. PVRB ഓൺ-ചെയിനിൻ്റെ ഏത് ഘട്ടവും പരിശോധിക്കുന്നത് വളരെ എളുപ്പമായിരിക്കണം, കാരണം ഇത് നെറ്റ്‌വർക്കിലെ എല്ലാ ക്ലയൻ്റുകളും നിർവ്വഹിക്കുന്നു. ഒരു സ്മാർട്ട് കരാർ ഉപയോഗിച്ചാണ് നടപ്പിലാക്കുന്നതെങ്കിൽ, വേഗത ആവശ്യകതകൾ വളരെ കർശനമാണ്
• പ്രവേശനക്ഷമതയുടെയും സജീവതയുടെയും പ്രശ്നം. നെറ്റ്‌വർക്കിൻ്റെ ഒരു ഭാഗം കുറച്ച് സമയത്തേക്ക് ലഭ്യമല്ലാത്ത സാഹചര്യത്തിലും ആർപിയുടെ ഒരു ഭാഗം പ്രവർത്തിക്കുന്നത് നിർത്തുന്ന സാഹചര്യത്തിലും നിങ്ങളുടെ PVRB പ്രതിരോധം നിലനിർത്താൻ ശ്രമിക്കണം.
• വിശ്വസനീയമായ സജ്ജീകരണത്തിൻ്റെയും പ്രാരംഭ കീ വിതരണത്തിൻ്റെയും പ്രശ്നം. നിങ്ങളുടെ PVRB പ്രോട്ടോക്കോളിൻ്റെ പ്രാഥമിക സജ്ജീകരണമാണ് ഉപയോഗിക്കുന്നതെങ്കിൽ, ഇത് വലിയതും ഗൗരവമുള്ളതുമായ ഒരു പ്രത്യേക സ്റ്റോറിയാണ്. ഇവിടെ ഉദാഹരണം. പ്രോട്ടോക്കോൾ ആരംഭിക്കുന്നതിന് മുമ്പ് പങ്കാളികൾ പരസ്പരം അവരുടെ കീകൾ പറയണം എങ്കിൽ, പങ്കെടുക്കുന്നവരുടെ ഘടന മാറുകയാണെങ്കിൽ ഇതും ഒരു പ്രശ്നമാണ്
• വികസന പ്രശ്നങ്ങൾ. ആവശ്യമായ ഭാഷകളിലുള്ള ലൈബ്രറികളുടെ ലഭ്യത, അവയുടെ സുരക്ഷയും പ്രകടനവും, പബ്ലിസിറ്റി, സങ്കീർണ്ണമായ പരിശോധനകൾ തുടങ്ങിയവ.

ഉദാഹരണത്തിന്, ത്രെഷോൾഡ് BLS ഒപ്പുകൾക്ക് കാര്യമായ പ്രശ്‌നമുണ്ട് - ജോലി ആരംഭിക്കുന്നതിന് മുമ്പ്, പങ്കെടുക്കുന്നവർ പരസ്പരം കീകൾ വിതരണം ചെയ്യണം, പരിധിക്കുള്ളിൽ പ്രവർത്തിക്കുന്ന ഒരു ഗ്രൂപ്പ് സംഘടിപ്പിക്കണം. ഇതിനർത്ഥം, ഒരു വികേന്ദ്രീകൃത നെറ്റ്‌വർക്കിൽ കുറഞ്ഞത് ഒരു റൗണ്ട് എക്സ്ചേഞ്ചെങ്കിലും കാത്തിരിക്കേണ്ടി വരും, ഉദാഹരണത്തിന്, ഗെയിമുകളിൽ ജനറേറ്റ് ചെയ്ത റാൻഡ് ആവശ്യമാണ്, മിക്കവാറും തത്സമയം, ഇതിനർത്ഥം ഈ ഘട്ടത്തിൽ പ്രോട്ടോക്കോളിൻ്റെ അട്ടിമറി സാധ്യമാണ് എന്നാണ്. , കൂടാതെ ത്രെഷോൾഡ് സ്കീമിൻ്റെ പ്രയോജനങ്ങൾ നഷ്ടപ്പെടുന്നു. ഈ പ്രശ്നം മുമ്പത്തേതിനേക്കാൾ ലളിതമാണ്, പക്ഷേ ഇപ്പോഴും ത്രെഷോൾഡ് ഗ്രൂപ്പുകളുടെ രൂപീകരണത്തിനായി ഒരു പ്രത്യേക നടപടിക്രമം വികസിപ്പിക്കേണ്ടതുണ്ട്, അത് സാമ്പത്തികമായി സംരക്ഷിക്കേണ്ടതുണ്ട്, നിക്ഷേപങ്ങളിലൂടെയും ഫണ്ട് പിൻവലിക്കലിലൂടെയും (സ്ലാഷിംഗ്) പിന്തുടരാത്ത പങ്കാളികളിൽ നിന്ന്. പ്രോട്ടോക്കോൾ. കൂടാതെ, സ്വീകാര്യമായ തലത്തിലുള്ള സുരക്ഷയുള്ള BLS പരിശോധന അനുയോജ്യമല്ല, ഉദാഹരണത്തിന്, ഒരു സാധാരണ EOS അല്ലെങ്കിൽ Ethereum ഇടപാടിലേക്ക് - സ്ഥിരീകരണത്തിന് മതിയായ സമയമില്ല. ഒരു വെർച്വൽ മെഷീൻ നിർവ്വഹിക്കുന്ന WebAssembly അല്ലെങ്കിൽ EVM ആണ് കരാർ കോഡ്. ക്രിപ്‌റ്റോഗ്രാഫിക് ഫംഗ്‌ഷനുകൾ നേറ്റീവ് ആയി നടപ്പിലാക്കിയിട്ടില്ല (ഇതുവരെ), കൂടാതെ പരമ്പരാഗത ക്രിപ്‌റ്റോഗ്രാഫിക് ലൈബ്രറികളേക്കാൾ പതിനായിരക്കണക്കിന് മടങ്ങ് വേഗത കുറവാണ്. പല പ്രോട്ടോക്കോളുകളും കേവലം കീ വോളിയം അടിസ്ഥാനമാക്കി ആവശ്യകതകൾ നിറവേറ്റുന്നില്ല, ഉദാഹരണത്തിന് RSA-യ്‌ക്കുള്ള 1024, 2048 ബിറ്റുകൾ, ബിറ്റ്‌കോയിനിലെയും Ethereum ലെയും സാധാരണ ഇടപാട് ഒപ്പിനേക്കാൾ 4-8 മടങ്ങ് വലുതാണ്.

വ്യത്യസ്ത പ്രോഗ്രാമിംഗ് ഭാഷകളിലെ നിർവ്വഹണങ്ങളുടെ സാന്നിധ്യവും ഒരു പങ്ക് വഹിക്കുന്നു - അവയിൽ ചിലത്, പ്രത്യേകിച്ച് പുതിയ പ്രോട്ടോക്കോളുകൾക്ക്. സമവായത്തിലേക്കുള്ള സമന്വയത്തോടുകൂടിയ ഓപ്ഷന് പ്ലാറ്റ്ഫോം ഭാഷയിൽ ഒരു പ്രോട്ടോക്കോൾ എഴുതേണ്ടതുണ്ട്, അതിനാൽ നിങ്ങൾ Go for goth, Rust for Parity, C++ ൽ EOS എന്നിവയിൽ കോഡ് തിരയേണ്ടതുണ്ട്. എല്ലാവരും ജാവാസ്ക്രിപ്റ്റ് കോഡിനായി നോക്കേണ്ടതുണ്ട്, കൂടാതെ ജാവാസ്ക്രിപ്റ്റും ക്രിപ്റ്റോഗ്രഫിയും പ്രത്യേകിച്ച് അടുത്ത സുഹൃത്തുക്കളല്ലാത്തതിനാൽ, WebAssembly സഹായിക്കും, അത് ഇപ്പോൾ തീർച്ചയായും അടുത്ത പ്രധാന ഇൻ്റർനെറ്റ് സ്റ്റാൻഡേർഡ് ആണെന്ന് അവകാശപ്പെടുന്നു.

തീരുമാനം

മുമ്പത്തേതിൽ ഞാൻ പ്രതീക്ഷിക്കുന്നു ലേഖനം വികേന്ദ്രീകൃത നെറ്റ്‌വർക്കുകളുടെ ജീവിതത്തിൻ്റെ പല വശങ്ങൾക്കും ബ്ലോക്ക്‌ചെയിനിൽ ക്രമരഹിതമായ നമ്പറുകൾ സൃഷ്ടിക്കുന്നത് നിർണായകമാണെന്ന് നിങ്ങളെ ബോധ്യപ്പെടുത്താൻ എനിക്ക് കഴിഞ്ഞു, ഈ ടാസ്‌ക് അങ്ങേയറ്റം അഭിലഷണീയവും ബുദ്ധിമുട്ടുള്ളതുമാണെന്ന് ഈ ലേഖനത്തിലൂടെ ഞാൻ കാണിച്ചു, പക്ഷേ നല്ല പരിഹാരങ്ങൾ ഇതിനകം നിലവിലുണ്ട്. പൊതുവേ, പ്രോട്ടോക്കോളിൻ്റെ അന്തിമ രൂപകൽപ്പന സാധ്യമാകുന്നത് സജ്ജീകരണം മുതൽ തെറ്റ് എമുലേഷൻ വരെയുള്ള എല്ലാ വശങ്ങളും കണക്കിലെടുത്ത് വൻതോതിലുള്ള പരിശോധനകൾ നടത്തിയതിന് ശേഷമാണ്, അതിനാൽ ടീം വൈറ്റ്പേപ്പറുകളിലും ലേഖനങ്ങളിലും നിങ്ങൾക്ക് റെഡിമെയ്ഡ് പാചകക്കുറിപ്പുകൾ കണ്ടെത്താൻ സാധ്യതയില്ല, ഞങ്ങൾ തീർച്ചയായും ചെയ്യില്ല. അടുത്ത ഒന്നോ രണ്ടോ വർഷത്തിനുള്ളിൽ തീരുമാനിക്കുക "ഇത് ഇങ്ങനെ ചെയ്യുക, കൃത്യമായി ചെയ്യുക."

ബൈ, വികസിപ്പിച്ചുകൊണ്ടിരിക്കുന്ന ബ്ലോക്ക്ചെയിനിലെ ഞങ്ങളുടെ PVRB-ക്ക് ഹയ, ത്രെഷോൾഡ് BLS സിഗ്നേച്ചറുകൾ ഉപയോഗിക്കുന്നതിൽ ഞങ്ങൾ തീർപ്പാക്കി, സ്വീകാര്യമായ തലത്തിലുള്ള സുരക്ഷയുള്ള സ്‌മാർട്ട് കരാറുകളിലെ സ്ഥിരീകരണം ഇതുവരെ സാധ്യമല്ലാത്തതിനാൽ, സമവായ തലത്തിൽ PVRB നടപ്പിലാക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു. ഞങ്ങൾ ഒരേസമയം രണ്ട് സ്കീമുകൾ ഉപയോഗിക്കുന്നത് സാധ്യമാണ്: ആദ്യം, ദീർഘകാല റാൻഡം_സീഡ് സൃഷ്ടിക്കാൻ ചെലവേറിയ രഹസ്യ പങ്കിടൽ, തുടർന്ന് ഡിറ്റർമിനിസ്റ്റിക് ത്രെഷോൾഡ് BLS സിഗ്നേച്ചറുകൾ ഉപയോഗിച്ച് ഉയർന്ന ഫ്രീക്വൻസി റാൻഡം ജനറേഷൻ്റെ അടിസ്ഥാനമായി ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു, ഒരുപക്ഷേ ഞങ്ങൾ സ്വയം പരിമിതപ്പെടുത്തിയേക്കാം. പദ്ധതികളിൽ ഒന്ന്. നിർഭാഗ്യവശാൽ, പ്രോട്ടോക്കോൾ എന്തായിരിക്കുമെന്ന് മുൻകൂട്ടി പറയുക അസാധ്യമാണ്, ശാസ്ത്രത്തിലെന്നപോലെ, എഞ്ചിനീയറിംഗ് പ്രശ്നങ്ങളിൽ, ഒരു നെഗറ്റീവ് ഫലവും ഒരു ഫലമാണ്, കൂടാതെ പ്രശ്നം പരിഹരിക്കാനുള്ള ഓരോ പുതിയ ശ്രമവും മറ്റൊരു ഘട്ടമാണ്; പ്രശ്നത്തിൽ ഉൾപ്പെട്ട എല്ലാവരുടെയും ഗവേഷണം. ബിസിനസ്സ് ആവശ്യകതകൾ നിറവേറ്റുന്നതിന്, ഞങ്ങൾ ഒരു നിർദ്ദിഷ്ട പ്രായോഗിക പ്രശ്നം പരിഹരിക്കുന്നു - ഗെയിമിംഗ് ആപ്ലിക്കേഷനുകൾക്ക് വിശ്വസനീയമായ എൻട്രോപ്പി ഉറവിടം നൽകുന്നു, അതിനാൽ ഞങ്ങൾ ബ്ലോക്ക്ചെയിനിൽ തന്നെ ശ്രദ്ധിക്കേണ്ടതുണ്ട്, പ്രത്യേകിച്ച് ചെയിൻ ഫിനാലിറ്റി, നെറ്റ്‌വർക്ക് ഗവേണൻസ് എന്നിവ.

യഥാർത്ഥ ആപ്ലിക്കേഷനുകൾ, ഒന്നിലധികം ഓഡിറ്റുകൾ, ലോഡുകൾ, തീർച്ചയായും യഥാർത്ഥ ആക്രമണങ്ങൾ എന്നിവയാൽ പരീക്ഷിക്കുന്നതിന് മതിയായ സമയം ഉപയോഗിക്കാമായിരുന്ന ബ്ലോക്ക്ചെയിനുകളിൽ തെളിയിക്കപ്പെട്ട പ്രതിരോധശേഷിയുള്ള PVRB ഞങ്ങൾ ഇതുവരെ കണ്ടിട്ടില്ലെങ്കിലും, സാധ്യമായ പാതകളുടെ എണ്ണം അത് സ്ഥിരീകരിക്കുന്നു. ഒരു പരിഹാരം നിലവിലുണ്ട്, ഈ അൽഗോരിതങ്ങളിൽ ഏതാണ് പ്രശ്നം ഒടുവിൽ പരിഹരിക്കും. ഫലങ്ങൾ പങ്കിടുന്നതിലും എഞ്ചിനീയർമാരെ ഒരേ റേക്കിൽ രണ്ടുതവണ കാലുകുത്താതിരിക്കാൻ അനുവദിക്കുന്ന ലേഖനങ്ങൾക്കും കോഡിനും ഈ വിഷയത്തിൽ പ്രവർത്തിക്കുന്ന മറ്റ് ടീമുകൾക്ക് നന്ദി പറയുന്നതിൽ ഞങ്ങൾക്ക് സന്തോഷമുണ്ട്.

അതിനാൽ, വികേന്ദ്രീകൃത ക്രമരഹിതമായി രൂപകൽപ്പന ചെയ്യുന്ന ഒരു പ്രോഗ്രാമറെ നിങ്ങൾ കാണുമ്പോൾ, ശ്രദ്ധയും കരുതലും ഉള്ളവരായിരിക്കുക, ആവശ്യമെങ്കിൽ മാനസിക സഹായം നൽകുക :)

അവലംബം: www.habr.com