परिचय

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

क्रिप्टोग्राफीच्या अगदी मजबूत सिफरच्या संकल्पनेप्रमाणेच, वास्तविक “सार्वजनिकपणे सत्यापित करण्यायोग्य रँडम बीकन” (यापुढे पीव्हीआरबी) प्रोटोकॉल केवळ आदर्श योजनेच्या शक्य तितक्या जवळ जाण्याचा प्रयत्न करतात, कारण वास्तविक नेटवर्कमध्ये ते त्याच्या शुद्ध स्वरूपात लागू होत नाही: एका गोष्टीवर काटेकोरपणे सहमत होणे आवश्यक आहे, तेथे अनेक फेऱ्या असणे आवश्यक आहे आणि सर्व संदेश पूर्णपणे जलद आणि नेहमी वितरित केले जाणे आवश्यक आहे. अर्थात, वास्तविक नेटवर्कमध्ये असे होत नाही. म्हणूनच, आधुनिक ब्लॉकचेनमध्ये विशिष्ट कार्यांसाठी PVRB ची रचना करताना, परिणामी यादृच्छिकता आणि क्रिप्टोग्राफिक सामर्थ्य नियंत्रित करण्याच्या अशक्यतेव्यतिरिक्त, अनेक पूर्णपणे आर्किटेक्चरल आणि तांत्रिक समस्या उद्भवतात.

PVRB साठी, ब्लॉकचेन स्वतःच एक संवाद माध्यम आहे ज्यामध्ये संदेश = व्यवहार. हे तुम्हाला नेटवर्क समस्या, संदेशांचे वितरण न करणे, मिडलवेअर मधील समस्यांपासून अंशतः अमूर्त करण्यास अनुमती देते - हे सर्व धोके विकेंद्रित नेटवर्कद्वारे गृहित धरले जातात आणि PVRB साठी त्याचे मुख्य मूल्य म्हणजे आधीच पाठवलेला व्यवहार रद्द करणे किंवा भ्रष्ट करणे अशक्य आहे - यामुळे सहभागींना प्रोटोकॉलमध्ये सहभागी होण्यास नकार देऊ नका, जोपर्यंत त्यांनी सहमतीवर यशस्वी हल्ला केला नाही. सुरक्षिततेची ही पातळी स्वीकार्य आहे, म्हणून PVRB मुख्य ब्लॉकचेन साखळीप्रमाणेच सहभागींच्या संगनमताला प्रतिरोधक असले पाहिजे. तसेच, हे सूचित करते की नेटवर्क मुख्य ब्लॉकचेनवर सहमत असल्यास PVRB सहमतीचा भाग असणे आवश्यक आहे, जरी ते एकमेव निष्पक्ष परिणामी यादृच्छिकतेवर सहमत असले तरीही. किंवा, PVRB हा एक स्मार्ट कराराद्वारे लागू केलेला एक स्वतंत्र प्रोटोकॉल आहे जो ब्लॉकचेन आणि ब्लॉक्सच्या संदर्भात असिंक्रोनसपणे कार्य करतो. दोन्ही पद्धतींचे त्यांचे फायदे आणि तोटे आहेत आणि त्यांच्यातील निवड अत्यंत क्षुल्लक आहे.

PVRB लागू करण्याचे दोन मार्ग

PVRB च्या अंमलबजावणीसाठी दोन पर्यायांचे अधिक तपशीलवार वर्णन करूया - स्वतंत्र आवृत्ती, जी ब्लॉकचेनपासून स्वतंत्र स्मार्ट कराराचा वापर करून कार्य करते आणि प्रोटोकॉलमध्ये तयार केलेली सहमती-समाकलित आवृत्ती, ज्यानुसार नेटवर्क ब्लॉकचेनवर सहमत आहे आणि व्यवहार समाविष्ट करणे. सर्व प्रकरणांमध्ये, माझा अर्थ लोकप्रिय ब्लॉकचेन इंजिन्स असा आहे: इथरियम, ईओएस आणि ते ज्या प्रकारे स्मार्ट कॉन्ट्रॅक्ट होस्ट करतात आणि त्यावर प्रक्रिया करतात त्याप्रमाणेच सर्व.

स्वतंत्र करार

या आवृत्तीमध्ये, PVRB हा एक स्मार्ट करार आहे जो यादृच्छिक उत्पादकांचे व्यवहार स्वीकारतो (यापुढे RP म्हणून संदर्भित), त्यावर प्रक्रिया करतो, परिणाम एकत्र करतो आणि परिणामी, कोणत्याही वापरकर्त्याला या करारातून मिळू शकणार्‍या विशिष्ट मूल्यापर्यंत पोहोचतो. हे मूल्य थेट करारामध्ये संग्रहित केले जाऊ शकत नाही, परंतु केवळ डेटाद्वारे प्रस्तुत केले जाऊ शकते ज्यामधून परिणामी यादृच्छिकतेचे एक आणि केवळ एक मूल्य निश्चितपणे प्राप्त केले जाऊ शकते. या योजनेत, 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 द्वारे स्वाक्षरी केलेले ब्लॉक आहेत. तसेच, अंतिमतेची खात्री करण्यासाठी एक प्रोटोकॉल बनवणे अर्थपूर्ण आहे, कारण ते ब्लॉक्सचे उत्पादन आणि प्रकाशनासह समकालिकपणे कार्य करू शकते. येथे एक चांगले आहे लेख इथरियममधील अंतिमतेबद्दल.

वापरकर्त्यांसाठी अंतिमता अत्यंत महत्त्वाची आहे, जे त्याशिवाय स्वतःला “दुहेरी खर्च” हल्ल्याचे बळी ठरू शकतात, जेथे BP “होल्ड” करतो आणि नेटवर्कने चांगला व्यवहार “पाहल्यानंतर” प्रकाशित करतो. कोणतीही अंतिमता नसल्यास, प्रकाशित काटा ब्लॉकला "चांगल्या" व्यवहारासह दुसर्‍यासह बदलतो, "खराब" काट्यावरून, ज्यामध्ये समान निधी आक्रमणकर्त्याच्या पत्त्यावर हस्तांतरित केला जातो. PVRB च्या बाबतीत, अंतिमतेसाठी आवश्यकता अधिक कठोर आहेत, कारण PVRB साठी काटे तयार करणे म्हणजे आक्रमणकर्त्याला सर्वात फायदेशीर प्रकाशित करण्यासाठी अनेक यादृच्छिक पर्याय तयार करण्याची संधी आणि संभाव्य हल्ल्याची वेळ मर्यादित करणे हे आहे. चांगला उपाय.

म्हणून, PVRB आणि अंतिमता एका प्रोटोकॉलमध्ये एकत्र करणे हा सर्वोत्तम पर्याय आहे - नंतर अंतिम ब्लॉक = अंतिम यादृच्छिक, आणि आम्हाला हे मिळणे आवश्यक आहे. आता खेळाडूंना N सेकंदांमध्ये हमी दिलेली यादृच्छिकता प्राप्त होईल आणि ते परत रोल करणे किंवा ते पुन्हा प्ले करणे अशक्य आहे याची खात्री असू शकते.

एकमत-समाकलित पर्याय चांगला आहे:

• ब्लॉक्सच्या उत्पादनाच्या संदर्भात असिंक्रोनस अंमलबजावणीची शक्यता - ब्लॉक्स नेहमीप्रमाणे तयार केले जातात, परंतु याच्या समांतर, पीव्हीआरबी प्रोटोकॉल कार्य करू शकतो, जो प्रत्येक ब्लॉकसाठी यादृच्छिकता निर्माण करत नाही.
• स्मार्ट कॉन्ट्रॅक्टवर लादलेल्या निर्बंधांशिवाय अगदी जड क्रिप्टोग्राफीची अंमलबजावणी करण्याची क्षमता
• ब्लॉकचेनमध्ये व्यवहारांपेक्षा अधिक वेगाने संदेशांची देवाणघेवाण आयोजित करण्याची क्षमता समाविष्ट आहे, उदाहरणार्थ, प्रोटोकॉलचा भाग नेटवर्कवर संदेश वितरित न करता नोड्स दरम्यान कार्य करू शकतो.

त्याचे तोटे देखील आहेत:

• चाचणी आणि विकासामध्ये अडचणी - तुम्हाला नेटवर्क त्रुटी, गहाळ नोड्स, नेटवर्क हार्ड फॉर्क्सचे अनुकरण करावे लागेल
• अंमलबजावणी त्रुटींसाठी नेटवर्क हार्डफोर्क आवश्यक आहे

PVRB लागू करण्याच्या दोन्ही पद्धतींना जीवनाचा अधिकार आहे, परंतु आधुनिक ब्लॉकचेनमधील स्मार्ट करारांची अंमलबजावणी अद्याप संगणकीय संसाधनांमध्ये मर्यादित आहे आणि गंभीर क्रिप्टोग्राफीमध्ये कोणतेही संक्रमण सहसा अशक्य आहे. आणि खाली दाखवल्याप्रमाणे आम्हाला गंभीर क्रिप्टोग्राफीची आवश्यकता असेल. जरी ही समस्या स्पष्टपणे तात्पुरती असली तरी, अनेक समस्यांचे निराकरण करण्यासाठी करारांमध्ये गंभीर क्रिप्टोग्राफी आवश्यक आहे आणि ती हळूहळू दिसून येत आहे (उदाहरणार्थ, इथरियममधील zkSNARK साठी सिस्टम कॉन्ट्रॅक्ट)

ब्लॉकचेन, जे एक पारदर्शक आणि विश्वासार्ह प्रोटोकॉल मेसेजिंग चॅनेल प्रदान करते, ते विनामूल्य करत नाही. कोणत्याही विकेंद्रित प्रोटोकॉलने सिबिल हल्ल्याची शक्यता विचारात घेणे आवश्यक आहे; कोणतीही कृती एकाधिक खात्यांच्या एकत्रित शक्तींद्वारे केली जाऊ शकते, म्हणून, डिझाइन करताना, प्रोटोकॉलची अनियंत्रित संख्या तयार करण्याची आक्रमणकर्त्यांची क्षमता विचारात घेणे आवश्यक आहे. संगनमताने काम करणारे सहभागी.

PVRB आणि ब्लॉक व्हेरिएबल्स.

मी खोटे बोललो नाही जेव्हा मी म्हटलो की ब्लॉकचेनमध्ये जुगाराच्या अनेक ऍप्लिकेशन्सद्वारे चाचणी केलेले चांगले PVRB अद्याप कोणीही लागू केलेले नाही. मग इथरियम आणि ईओएसवर जुगार खेळण्याचे इतके अनुप्रयोग कोठून येतात? हे मला जितके आश्चर्यचकित करते तितकेच आश्चर्यचकित करते, पूर्णपणे निर्धारवादी वातावरणात त्यांना इतके "सतत" यादृच्छिक कोठून मिळाले?

ब्लॉकचेनमध्ये यादृच्छिकता मिळविण्याचा आवडता मार्ग म्हणजे ब्लॉकमधून काही प्रकारची "अनप्रेडिक्टेबल" माहिती घेणे आणि त्यावर आधारित एक यादृच्छिक माहिती बनवणे - फक्त एक किंवा अधिक मूल्ये हॅश करून. अशा योजनांच्या समस्यांबद्दल चांगला लेख येथे. तुम्ही ब्लॉकमधील कोणतीही “अनप्रेडिक्टेबल” व्हॅल्यू घेऊ शकता, उदाहरणार्थ, ब्लॉक हॅश, ट्रान्झॅक्शन्सची संख्या, नेटवर्क क्लिष्टता आणि इतर व्हॅल्यू अगोदर अज्ञात आहेत. नंतर त्यांना हॅश करा, एक किंवा अधिक, आणि, सिद्धांतानुसार, तुम्हाला वास्तविक यादृच्छिक मिळावे. तुम्ही व्हाईटपेपरमध्ये देखील जोडू शकता की तुमची योजना “पोस्ट-क्वांटम सुरक्षित” आहे (क्वांटम-प्रूफ हॅश फंक्शन्स असल्याने :)).

पण पोस्ट क्वांटम सुरक्षित हॅश देखील पुरेसे नाहीत, अरेरे. PVRB च्या आवश्यकतांमध्ये गुपित आहे, मी तुम्हाला मागील लेखातील त्यांची आठवण करून देतो:

1. परिणामाचे एकसमान वितरण असणे आवश्यक आहे, म्हणजेच ते सिद्ध क्रिप्टोग्राफीवर आधारित असावे.
2. निकालाच्या कोणत्याही बिट्सवर नियंत्रण ठेवणे शक्य नाही. परिणामी, निकालाचा आगाऊ अंदाज लावता येत नाही.
3. तुम्ही प्रोटोकॉलमध्ये सहभागी न होऊन किंवा हल्ला संदेशांसह नेटवर्क ओव्हरलोड करून जनरेशन प्रोटोकॉलची तोडफोड करू शकत नाही
4. वरील सर्व अप्रामाणिक प्रोटोकॉल सहभागींच्या (उदाहरणार्थ, 1/3 सहभागींच्या) अनुज्ञेय संख्येच्या संगनमताने प्रतिरोधक असणे आवश्यक आहे.

या प्रकरणात, फक्त आवश्यकता 1 पूर्ण केली जाते, आणि आवश्यकता 2 पूर्ण केली जात नाही. ब्लॉकमधून अप्रत्याशित मूल्ये हॅश करून, आम्हाला एकसमान वितरण आणि चांगले रँडम्स मिळतील. परंतु बीपीकडे किमान "ब्लॉक प्रकाशित करा किंवा नाही" हा पर्याय आहे. अशाप्रकारे, BP किमान दोन यादृच्छिक पर्यायांमधून निवडू शकतो: “स्वतःचा” आणि दुसरा कोणी ब्लॉक केल्यास तो बाहेर येईल. BP आगाऊ "स्नूप" करू शकतो जर त्याने ब्लॉक प्रकाशित केला तर काय होईल, आणि फक्त ते करायचे की नाही हे ठरवले. अशा प्रकारे, खेळताना, उदाहरणार्थ, रूलेटमध्ये “सम-विषम” किंवा “लाल/काळा”, तो विजय दिसला तरच ब्लॉक प्रकाशित करू शकतो. हे वापरण्याचे धोरण देखील बनवते, उदाहरणार्थ, "भविष्यातील" ब्लॉक हॅश अकार्यक्षम. या प्रकरणात, ते म्हणतात की "यादृच्छिक वापरला जाईल, जो वर्तमान डेटा आणि भविष्यातील ब्लॉकच्या हॅशच्या उंचीसह हॅश करून प्राप्त केला जातो, उदाहरणार्थ, N + 42, जेथे N ही वर्तमान ब्लॉकची उंची आहे. हे योजनेला थोडे मजबूत करते, परंतु तरीही BP ला, जरी भविष्यात, ब्लॉक ठेवायचे की प्रकाशित करायचे हे निवडण्याची परवानगी देते.

या प्रकरणात बीपी सॉफ्टवेअर अधिक क्लिष्ट होते, परंतु जास्त नाही. फक्त, ब्लॉकमध्ये व्यवहार सत्यापित करताना आणि समाविष्ट करताना, विजय होईल की नाही हे पाहण्यासाठी झटपट तपासणी केली जाते आणि, शक्यतो, जिंकण्याची उच्च संभाव्यता प्राप्त करण्यासाठी एक व्यवहार पॅरामीटर्स निवडणे आवश्यक आहे. त्याच वेळी, अशा हाताळणीसाठी स्मार्ट बीपी पकडणे जवळजवळ अशक्य आहे; प्रत्येक वेळी आपण नवीन पत्ते वापरू शकता आणि संशय न वाढवता थोडेसे जिंकू शकता.

त्यामुळे ब्लॉकमधील माहिती वापरण्याच्या पद्धती PVRB ची सार्वत्रिक अंमलबजावणी म्हणून योग्य नाहीत. मर्यादित आवृत्तीमध्ये, बेट आकारावरील निर्बंध, खेळाडूंच्या संख्येवर निर्बंध आणि/किंवा केवायसी नोंदणी (एका खेळाडूला अनेक पत्ते वापरण्यापासून रोखण्यासाठी) या योजना लहान खेळांसाठी कार्य करू शकतात, परंतु आणखी काही नाही.

PVRB आणि कमिट-रिव्हल.

ठीक आहे, हॅशिंगबद्दल धन्यवाद आणि कमीतकमी ब्लॉक हॅश आणि इतर व्हेरिएबल्सची सापेक्ष अप्रत्याशितता. जर तुम्ही समोर चालणाऱ्या खाण कामगारांची समस्या सोडवली तर तुम्हाला आणखी योग्य काहीतरी मिळायला हवे. चला या योजनेत वापरकर्ते जोडूया - त्यांना यादृच्छिकतेवर देखील प्रभाव टाकू द्या: कोणताही तांत्रिक समर्थन कर्मचारी तुम्हाला सांगेल की आयटी सिस्टममधील सर्वात यादृच्छिक गोष्ट म्हणजे वापरकर्त्यांच्या कृती :)

एक साधी योजना, जेव्हा वापरकर्ते फक्त यादृच्छिक संख्या पाठवतात आणि परिणाम म्हणून गणना केली जाते, उदाहरणार्थ, त्यांच्या बेरीजचा हॅश, योग्य नाही. या प्रकरणात, शेवटचा खेळाडू, स्वतःची यादृच्छिक निवड करून, परिणाम काय होईल यावर नियंत्रण ठेवू शकतो. म्हणूनच मोठ्या प्रमाणावर वापरलेला कमिट-रिव्हल पॅटर्न वापरला जातो. सहभागी प्रथम त्यांच्या यादृच्छिक (कमिट) मधून हॅश पाठवतात आणि नंतर यादृच्छिक स्वतः उघडतात (प्रकट करतात). आवश्यक कमिट गोळा केल्यावरच “रिव्हल” टप्पा सुरू होतो, त्यामुळे सहभागी नेमके यादृच्छिक हॅश पाठवू शकतात ज्यावरून त्यांनी आधी पाठवले होते. आता हे सर्व ब्लॉकच्या पॅरामीटर्ससह एकत्र ठेवूया आणि भविष्यातून घेतलेल्यापेक्षा चांगले (यादृच्छिकता केवळ भविष्यातील एका ब्लॉकमध्ये आढळू शकते), आणि व्होइला - यादृच्छिकता तयार आहे! आता कोणताही खेळाडू परिणामी यादृच्छिकतेवर प्रभाव टाकतो आणि दुर्भावनापूर्ण बीपीला त्याच्या स्वत:च्या, आगाऊ अज्ञात, यादृच्छिकतेने ओव्हरराइड करून "पराभव" करू शकतो... तुम्ही प्रोटोकॉलची तोडफोड करण्यापासून संरक्षण देखील जोडू शकता ते उघड करण्याच्या टप्प्यावर न उघडता - फक्त व्यवहार करताना विशिष्ट रक्कम जोडणे आवश्यक आहे - एक सुरक्षा ठेव, जी केवळ प्रकट प्रक्रियेदरम्यान परत केली जाईल. या प्रकरणात, वचन देणे आणि प्रकट न करणे फायदेशीर नाही.

हा एक चांगला प्रयत्न होता, आणि अशा योजना गेमिंग DApps मध्ये देखील अस्तित्वात आहेत, परंतु अरेरे, हे पुन्हा पुरेसे नाही. आता केवळ खाण कामगारच नाही तर प्रोटोकॉलमधील कोणताही सहभागी देखील निकालावर प्रभाव टाकू शकतो. कमी परिवर्तनशीलतेसह आणि खर्चासह मूल्य स्वतः नियंत्रित करणे अद्याप शक्य आहे, परंतु, खाण कामगाराच्या बाबतीत, जर रेखांकनाचे परिणाम पीव्हीआरबी प्रोटोकॉलमध्ये सहभागी होण्याच्या शुल्कापेक्षा अधिक मौल्यवान असतील, तर यादृच्छिक -उत्पादक (RP) प्रकट करायचे की नाही हे ठरवू शकतो आणि तरीही किमान दोन यादृच्छिक पर्यायांमधून निवडू शकतो.
परंतु जे पाप करतात आणि उघड करत नाहीत त्यांना शिक्षा करणे शक्य झाले आणि ही योजना उपयुक्त ठरेल. त्याची साधेपणा हा एक गंभीर फायदा आहे - अधिक गंभीर प्रोटोकॉलसाठी अधिक शक्तिशाली गणना आवश्यक आहे.

PVRB आणि निर्धारक स्वाक्षरी.

RP ला एक छद्म-यादृच्छिक क्रमांक प्रदान करण्यास भाग पाडण्याचा आणखी एक मार्ग आहे ज्यावर "प्रीइमेज" प्रदान केल्यास ते प्रभावित करू शकत नाही - ही एक निर्धारक स्वाक्षरी आहे. अशी स्वाक्षरी, उदाहरणार्थ, RSA आहे आणि ती ECS नाही. जर RP कडे कीची जोडी असेल: RSA आणि ECC, आणि त्याने त्याच्या खाजगी कीसह विशिष्ट मूल्यावर स्वाक्षरी केली, तर RSA च्या बाबतीत त्याला एक आणि फक्त एकच स्वाक्षरी मिळेल आणि ECS च्या बाबतीत तो कितीही संख्या तयार करू शकतो. भिन्न वैध स्वाक्षर्या. कारण ECS स्वाक्षरी तयार करताना, स्वाक्षरीकर्त्याद्वारे निवडलेला एक यादृच्छिक क्रमांक वापरला जातो आणि तो कोणत्याही प्रकारे निवडला जाऊ शकतो, स्वाक्षरीकर्त्याला अनेक स्वाक्षरींपैकी एक निवडण्याची संधी देते. RSA च्या बाबतीत: “एक इनपुट मूल्य” + “एक की जोडी” = “एक स्वाक्षरी”. दुसर्‍या RP ला कोणती स्वाक्षरी मिळेल हे सांगणे अशक्य आहे, म्हणून समान मूल्यावर स्वाक्षरी करणार्‍या अनेक सहभागींच्या RSA स्वाक्षरी एकत्र करून निश्चित स्वाक्षरी असलेले PVRB आयोजित केले जाऊ शकते. उदाहरणार्थ, मागील यादृच्छिक. ही योजना भरपूर संसाधने वाचवते, कारण स्वाक्षरी म्हणजे प्रोटोकॉलनुसार योग्य वर्तनाची पुष्टी आणि यादृच्छिकतेचा स्त्रोत.

तथापि, निर्धारवादी स्वाक्षरी असूनही, योजना अजूनही "अंतिम अभिनेता" समस्येसाठी असुरक्षित आहे. शेवटचा सहभागी अद्याप स्वाक्षरी प्रकाशित करायची की नाही हे ठरवू शकतो, ज्यामुळे परिणाम नियंत्रित होईल. आपण योजनेत बदल करू शकता, त्यात ब्लॉक हॅश जोडू शकता, गोल करू शकता जेणेकरून निकालाचा आगाऊ अंदाज लावता येणार नाही, परंतु ही सर्व तंत्रे, अनेक बदल विचारात घेऊन, तरीही सामूहिक वर एका सहभागीच्या प्रभावाची समस्या सोडवलेली नाही. अविश्वासू वातावरणात परिणाम होतो आणि केवळ आर्थिक आणि वेळेच्या मर्यादेत काम करू शकते. याव्यतिरिक्त, RSA की (1024 आणि 2048 bits) चा आकार बराच मोठा आहे आणि ब्लॉकचेन व्यवहारांसाठी आकार हा एक अत्यंत महत्त्वाचा पॅरामीटर आहे. वरवर पाहता समस्या सोडवण्याचा कोणताही सोपा मार्ग नाही, चला पुढे जाऊया.

PVRB आणि गुप्त शेअरिंग योजना

क्रिप्टोग्राफीमध्ये, अशा योजना आहेत ज्या नेटवर्कला एक आणि फक्त एक PVRB मूल्यावर सहमती देऊ शकतात, तर अशा योजना काही सहभागींच्या कोणत्याही दुर्भावनापूर्ण कृतींना प्रतिरोधक असतात. एक उपयुक्त प्रोटोकॉल जो स्वतःला परिचित करून घेण्यासारखा आहे तो म्हणजे शामीरची गुप्त सामायिकरण योजना. हे गुप्त (उदाहरणार्थ, एक गुप्त की) अनेक भागांमध्ये विभाजित करते आणि हे भाग N सहभागींना वितरित करते. गुपित अशा प्रकारे वितरीत केले जाते की N मधील M भाग ते पुनर्प्राप्त करण्यासाठी पुरेसे आहेत आणि हे कोणतेही M भाग असू शकतात. बोटांवर असल्यास, अज्ञात फंक्शनचा आलेख असल्यास, सहभागी ग्राफवरील पॉइंट्सची देवाणघेवाण करतात आणि एम पॉइंट प्राप्त केल्यानंतर, संपूर्ण कार्य पुनर्संचयित केले जाऊ शकते.
मध्ये एक चांगले स्पष्टीकरण दिले आहे विकी परंतु आपल्या डोक्यात प्रोटोकॉल खेळण्यासाठी व्यावहारिकपणे त्याच्याशी खेळणे उपयुक्त आहे डेमो पृष्ठ

जर FSSS (फियाट-शमीर सिक्रेट शेअरिंग) योजना त्याच्या शुद्ध स्वरूपात लागू असेल, तर ती एक अविनाशी PVRB असेल. त्याच्या सर्वात सोप्या स्वरूपात, प्रोटोकॉल यासारखे दिसू शकते:

• प्रत्येक सहभागी स्वतःचे यादृच्छिक व्युत्पन्न करतो आणि त्यातील शेअर्स इतर सहभागींना वितरित करतो
• प्रत्येक सहभागी इतर सहभागींच्या रहस्यांचा त्याचा भाग प्रकट करतो
• जर एखाद्या सहभागीकडे M पेक्षा जास्त शेअर्स असतील, तर या सहभागीची संख्या मोजली जाऊ शकते आणि प्रकट झालेल्या सहभागींच्या संचाकडे दुर्लक्ष करून ते अद्वितीय असेल.
• प्रकट केलेल्या यादृच्छिकांचे संयोजन इच्छित PVRB आहे

येथे, यादृच्छिकता प्रकटीकरण थ्रेशोल्डची उपलब्धी केवळ त्याच्यावर अवलंबून असते अशा प्रकरणांशिवाय, वैयक्तिक सहभागी प्रोटोकॉलच्या परिणामांवर यापुढे प्रभाव टाकत नाही. म्हणून, हा प्रोटोकॉल, प्रोटोकॉलवर काम करणार्‍या RP चे आवश्यक प्रमाण आणि उपलब्ध असल्यास, कार्य करते, क्रिप्टोग्राफिक सामर्थ्याच्या आवश्यकतांची अंमलबजावणी करते आणि "अंतिम अभिनेता" समस्येस प्रतिरोधक असते.

हा एक आदर्श पर्याय असू शकतो, फियाट-शमीर गुप्त सामायिकरणावर आधारित ही PVRB योजना उदाहरणार्थ मध्ये वर्णन केली आहे हे लेख. परंतु, वर नमूद केल्याप्रमाणे, जर तुम्ही ब्लॉकचेनमध्ये ते लागू करण्याचा प्रयत्न केला तर, तांत्रिक मर्यादा दिसून येतात. येथे EOS स्मार्ट कॉन्ट्रॅक्टमधील प्रोटोकॉलच्या चाचणी अंमलबजावणीचे उदाहरण आहे आणि त्याचा सर्वात महत्वाचा भाग - प्रकाशित शेअर सहभागी तपासणे: कोड. तुम्ही कोडवरून पाहू शकता की पुराव्याच्या प्रमाणीकरणासाठी अनेक स्केलर गुणाकार आवश्यक आहेत आणि वापरलेली संख्या खूप मोठी आहे. हे समजले पाहिजे की ब्लॉकचेनमध्ये, जेव्हा ब्लॉक-निर्माता व्यवहारावर प्रक्रिया करतो तेव्हा पडताळणी होते आणि सर्वसाधारणपणे, कोणत्याही सहभागीने सहजपणे प्रोटोकॉलची शुद्धता सत्यापित करणे आवश्यक आहे, म्हणून सत्यापन कार्याच्या गतीसाठी आवश्यकता खूप गंभीर आहेत. . या पर्यायामध्ये, पडताळणी व्यवहार मर्यादेत (०.५ सेकंद) बसत नसल्यामुळे हा पर्याय कुचकामी ठरला.

सर्वसाधारणपणे, ब्लॉकचेनमधील कोणत्याही प्रगत क्रिप्टोग्राफिक योजनांच्या वापरासाठी पडताळणी कार्यक्षमता ही सर्वात महत्त्वाची आवश्यकता आहे. पुरावे तयार करणे, संदेश तयार करणे - या प्रक्रिया ऑफ-चेन घेतल्या जाऊ शकतात आणि उच्च-कार्यक्षमता असलेल्या संगणकांवर केल्या जाऊ शकतात, परंतु सत्यापन बायपास केले जाऊ शकत नाही - PVRB साठी ही आणखी एक महत्त्वाची आवश्यकता आहे.

PVRB आणि थ्रेशोल्ड स्वाक्षर्या

गुप्त सामायिकरण योजनेशी परिचित झाल्यानंतर, आम्हाला "थ्रेशोल्ड" कीवर्डद्वारे एकत्रित प्रोटोकॉलचा संपूर्ण वर्ग सापडला. जेव्हा काही माहितीच्या प्रकटीकरणासाठी N मधील M प्रामाणिक सहभागींचा सहभाग आवश्यक असतो आणि प्रामाणिक सहभागींचा संच N चा अनियंत्रित उपसंच असू शकतो, तेव्हा आम्ही “थ्रेशोल्ड” योजनांबद्दल बोलतो. त्यांनीच आम्हाला "अंतिम अभिनेता" समस्येचा सामना करण्याची परवानगी दिली, आता जर हल्लेखोराने त्याचे रहस्य उघड केले नाही तर दुसरा, प्रामाणिक सहभागी त्याच्यासाठी करेल. काही सहभागींनी प्रोटोकॉलची तोडफोड केली असली तरीही या योजना एक आणि फक्त एकाच अर्थावर करार करण्यास परवानगी देतात.

निर्धारक स्वाक्षरी आणि थ्रेशोल्ड योजनांच्या संयोजनामुळे PVRB च्या अंमलबजावणीसाठी एक अतिशय सोयीस्कर आणि आश्वासक योजना विकसित करणे शक्य झाले - या निर्धारक थ्रेशोल्ड स्वाक्षरी आहेत. येथे लेख थ्रेशोल्ड स्वाक्षरीच्या विविध उपयोगांबद्दल आणि येथे आणखी एक चांगला आहे लांब वाचन डॅश पासून.

शेवटचा लेख बीएलएस स्वाक्षरींचे वर्णन करतो (बीएलएस म्हणजे बोनेह-लिन-शाचम, पाहा, पाहा लेख), ज्यात प्रोग्रामरसाठी एक अतिशय महत्त्वाची आणि अत्यंत सोयीस्कर गुणवत्ता आहे - सार्वजनिक, गुप्त, सार्वजनिक की आणि BLS स्वाक्षरी साध्या गणितीय ऑपरेशन्स वापरून एकमेकांशी एकत्र केल्या जाऊ शकतात, तर त्यांचे संयोजन वैध की आणि स्वाक्षर्या राहतील, ज्यामुळे तुम्हाला अनेक सहजपणे एकत्रित करता येतील. एका मध्‍ये स्वाक्षर्‍या आणि एकामध्‍ये अनेक सार्वजनिक कळा. ते निर्धारक देखील आहेत आणि समान इनपुट डेटासाठी समान परिणाम देतात. या गुणवत्तेबद्दल धन्यवाद, बीएलएस स्वाक्षरींचे संयोजन स्वतःच वैध की आहेत, जे एक पर्याय लागू करण्यास अनुमती देते ज्यामध्ये M पैकी N सहभागी एक आणि फक्त एक स्वाक्षरी तयार करतात जी निर्धारक, सार्वजनिकपणे सत्यापित करण्यायोग्य आणि Mth द्वारे उघडेपर्यंत अप्रत्याशित असते. सहभागी

थ्रेशोल्ड BLS स्वाक्षरी असलेल्या योजनेमध्ये, प्रत्येक सहभागी BLS वापरून काहीतरी स्वाक्षरी करतो (उदाहरणार्थ, मागील रँडम), आणि सामान्य थ्रेशोल्ड स्वाक्षरी इच्छित यादृच्छिक आहे. BLS स्वाक्षरीचे क्रिप्टोग्राफिक गुणधर्म यादृच्छिक गुणवत्तेसाठी आवश्यकता पूर्ण करतात, थ्रेशोल्ड भाग "अंतिम-अभिनेता" पासून संरक्षण करते आणि कीजच्या अद्वितीय संयोजनामुळे अनेक मनोरंजक अल्गोरिदम लागू करणे शक्य होते जे उदाहरणार्थ, प्रोटोकॉल संदेशांचे कार्यक्षम एकत्रीकरण करण्यास अनुमती देतात. .

म्हणून, जर तुम्ही तुमच्या ब्लॉकचेनवर PVRB तयार करत असाल, तर तुम्हाला बीएलएस थ्रेशोल्ड स्वाक्षरी योजना पूर्ण होईल, अनेक प्रकल्प आधीच ते वापरत आहेत. उदाहरणार्थ, DFinity (येथे बेंचमार्क जो सर्किट लागू करतो, आणि येथे सत्यापित करण्यायोग्य गुप्त शेअरिंगची उदाहरणे अंमलबजावणी), किंवा Keep.network (येथे त्यांचे यादृच्छिक बीकन आहे पिवळा कागद, आणि येथे उदाहरण प्रोटोकॉलची सेवा करणारे स्मार्ट करार).

PVRB ची अंमलबजावणी

दुर्दैवाने, आम्हाला अजूनही PVRB ब्लॉकचेनमध्ये तयार केलेला प्रोटोकॉल दिसत नाही ज्याने तिची सुरक्षितता आणि स्थिरता सिद्ध केली आहे. जरी प्रोटोकॉल स्वतः तयार आहेत, तांत्रिकदृष्ट्या ते विद्यमान उपायांवर लागू करणे सोपे नाही. केंद्रीकृत प्रणालींसाठी, PVRB ला अर्थ नाही, आणि विकेंद्रीकृत सर्व संगणकीय संसाधनांमध्ये कठोरपणे मर्यादित आहेत: CPU, मेमरी, स्टोरेज, I/O. किमान काही व्यवहार्य ब्लॉकचेनसाठी सर्व आवश्यकता पूर्ण करणारे काहीतरी तयार करण्यासाठी PVRB डिझाइन करणे हे वेगवेगळ्या प्रोटोकॉलचे संयोजन आहे. एक प्रोटोकॉल अधिक कार्यक्षमतेने गणना करतो, परंतु RPs दरम्यान अधिक संदेशांची आवश्यकता असते, तर दुसर्‍याला खूप कमी संदेशांची आवश्यकता असते, परंतु पुरावा तयार करणे हे एक कार्य असू शकते ज्यासाठी दहा मिनिटे किंवा तास लागतात.

दर्जेदार पीव्हीआरबी निवडताना तुम्हाला कोणत्या घटकांचा विचार करावा लागेल याची मी यादी करेन:

• क्रिप्टोग्राफिक ताकद. तुमचा PVRB काटेकोरपणे निःपक्षपाती असणे आवश्यक आहे, एक बिट नियंत्रित करण्याची क्षमता नाही. काही योजनांमध्ये असे होत नाही, म्हणून क्रिप्टोग्राफरला कॉल करा
• "शेवटचा अभिनेता" समस्या. तुमचा PVRB अशा हल्ल्यांना प्रतिरोधक असणे आवश्यक आहे जेथे एक किंवा अधिक RPs नियंत्रित करणारा आक्रमणकर्ता दोन परिणामांपैकी एक निवडू शकतो.
• प्रोटोकॉल तोडफोड समस्या. तुमचा PVRB अशा हल्ल्यांना प्रतिरोधक असणे आवश्यक आहे जेथे एक किंवा अधिक RPs नियंत्रित करणारा आक्रमणकर्ता यादृच्छिक आहे की नाही हे ठरवतो आणि त्यावर प्रभाव टाकण्याची हमी दिली जाऊ शकते किंवा दिलेल्या संभाव्यतेसह.
• संदेशांची संख्या समस्या. तुमच्या RPs ने ब्लॉकचेनला कमीत कमी मेसेज पाठवले पाहिजेत आणि "मी काही माहिती पाठवली आहे, मी एका विशिष्ट सहभागीच्या प्रतिसादाची वाट पाहत आहे." p2p नेटवर्कमध्ये, विशेषत: भौगोलिकदृष्ट्या विखुरलेल्या नेटवर्कमध्ये, तुम्ही त्वरित प्रतिसादावर अवलंबून राहू नये.
• संगणकीय जटिलतेची समस्या. PVRB ऑन-चेनच्या कोणत्याही टप्प्याचे सत्यापन अत्यंत सोपे असले पाहिजे, कारण ते नेटवर्कच्या सर्व पूर्ण ग्राहकांद्वारे केले जाते. जर अंमलबजावणी स्मार्ट कॉन्ट्रॅक्टचा वापर करून केली गेली असेल, तर वेगाची आवश्यकता खूप कठोर आहे
• प्रवेशयोग्यता आणि जिवंतपणाची समस्या. तुमच्या PVRB ने अशा परिस्थितीत लवचिक राहण्याचा प्रयत्न केला पाहिजे जिथे नेटवर्कचा काही भाग काही कालावधीसाठी अनुपलब्ध होतो आणि RP चा काही भाग काम करणे थांबवतो.
• विश्वसनीय सेटअप आणि प्रारंभिक की वितरणाची समस्या. जर तुमचा PVRB प्रोटोकॉलचा प्राथमिक सेटअप वापरत असेल, तर ही एक वेगळी मोठी आणि गंभीर गोष्ट आहे. येथे उदाहरण. प्रोटोकॉल सुरू करण्यापूर्वी सहभागींनी एकमेकांना त्यांच्या कळा सांगणे आवश्यक असल्यास, सहभागींची रचना बदलल्यास ही देखील एक समस्या आहे
• विकास समस्या. आवश्यक भाषांमध्ये ग्रंथालयांची उपलब्धता, त्यांची सुरक्षा आणि कार्यप्रदर्शन, प्रसिद्धी, जटिल चाचण्या इ.

उदाहरणार्थ, थ्रेशोल्ड बीएलएस स्वाक्षरींमध्ये एक महत्त्वपूर्ण समस्या आहे - कार्य करण्यास प्रारंभ करण्यापूर्वी, सहभागींनी एकमेकांना की वितरीत करणे आवश्यक आहे, एक गट आयोजित करणे आवश्यक आहे ज्यामध्ये थ्रेशोल्ड कार्य करेल. याचा अर्थ असा की विकेंद्रित नेटवर्कमध्ये एक्सचेंजच्या किमान एक फेरीसाठी प्रतीक्षा करावी लागेल आणि व्युत्पन्न केलेले रँड, उदाहरणार्थ, गेममध्ये आवश्यक आहे, जवळजवळ वास्तविक वेळेत, याचा अर्थ असा की या टप्प्यावर प्रोटोकॉलची तोडफोड शक्य आहे. , आणि थ्रेशोल्ड योजनेचे फायदे गमावले आहेत. मागील समस्यांपेक्षा ही समस्या आधीच सोपी आहे, परंतु तरीही थ्रेशोल्ड गटांच्या निर्मितीसाठी स्वतंत्र प्रक्रिया विकसित करणे आवश्यक आहे, ज्याचे पालन न करणार्‍या सहभागींकडून ठेवी आणि निधी काढणे (स्लॅशिंग) द्वारे आर्थिकदृष्ट्या संरक्षित केले जावे. प्रोटोकॉल तसेच, सुरक्षिततेच्या स्वीकारार्ह पातळीसह BLS सत्यापन फक्त बसत नाही, उदाहरणार्थ, मानक EOS किंवा Ethereum व्यवहारात - सत्यापनासाठी पुरेसा वेळ नाही. कॉन्ट्रॅक्ट कोड WebAssembly किंवा EVM आहे, व्हर्च्युअल मशीनद्वारे अंमलात आणला जातो. क्रिप्टोग्राफिक फंक्शन्स स्थानिकरित्या (अद्याप) अंमलात आणल्या जात नाहीत आणि पारंपारिक क्रिप्टोग्राफिक लायब्ररींच्या तुलनेत दहापट हळू काम करतात. अनेक प्रोटोकॉल फक्त की व्हॉल्यूमवर आधारित आवश्यकता पूर्ण करत नाहीत, उदाहरणार्थ RSA साठी 1024 आणि 2048 बिट, Bitcoin आणि Ethereum मधील मानक व्यवहार स्वाक्षरीपेक्षा 4-8 पट मोठे.

वेगवेगळ्या प्रोग्रामिंग भाषांमध्ये अंमलबजावणीची उपस्थिती देखील भूमिका बजावते - त्यापैकी काही आहेत, विशेषत: नवीन प्रोटोकॉलसाठी. सहमतीमध्ये एकत्रीकरणासह पर्यायासाठी प्लॅटफॉर्म भाषेत प्रोटोकॉल लिहिणे आवश्यक आहे, त्यामुळे तुम्हाला गो फॉर गेथ, रस्ट फॉर पॅरिटीमध्ये, EOS साठी C++ मध्ये कोड शोधावा लागेल. प्रत्येकाला JavaScript कोड शोधावा लागेल, आणि JavaScript आणि क्रिप्टोग्राफी विशेषतः जवळचे मित्र नसल्यामुळे, WebAssembly मदत करेल, जे आता निश्चितपणे पुढील महत्त्वाचे इंटरनेट मानक असल्याचा दावा करते.

निष्कर्ष

मी मागील एक आशा लेख विकेंद्रित नेटवर्क्सच्या जीवनातील अनेक पैलूंसाठी ब्लॉकचेनवर यादृच्छिक संख्या निर्माण करणे महत्त्वाचे आहे हे मी तुम्हाला पटवून देण्यात व्यवस्थापित केले आणि या लेखाद्वारे मी हे दाखवून दिले की हे कार्य अत्यंत महत्त्वाकांक्षी आणि कठीण आहे, परंतु चांगले उपाय आधीच अस्तित्वात आहेत. सर्वसाधारणपणे, प्रोटोकॉलची अंतिम रचना सेटअपपासून फॉल्ट इम्युलेशनपर्यंतच्या सर्व बाबींचा विचार करणार्‍या मोठ्या चाचण्या घेतल्यानंतरच शक्य आहे, त्यामुळे तुम्हाला टीम व्हाईटपेपर आणि लेखांमध्ये तयार पाककृती सापडण्याची शक्यता नाही आणि आम्ही नक्कीच करणार नाही. पुढच्या एक-दोन वर्षात ठरवा “अशा प्रकारे करा, अगदी बरोबर”.

अलविदा, विकसित होत असलेल्या ब्लॉकचेनमधील आमच्या PVRB साठी होय, आम्ही थ्रेशोल्ड BLS स्वाक्षरी वापरण्यावर सेटल झालो, आम्ही PVRB सर्वसहमतीच्या स्तरावर लागू करण्याची योजना आखत आहोत, कारण सुरक्षिततेच्या स्वीकार्य स्तरासह स्मार्ट करारांमध्ये पडताळणी करणे अद्याप शक्य नाही. हे शक्य आहे की आम्ही एकाच वेळी दोन योजना वापरतो: प्रथम, दीर्घकालीन यादृच्छिक_सीड तयार करण्यासाठी महाग गुप्त सामायिकरण, आणि नंतर आम्ही निर्धारवादी थ्रेशोल्ड बीएलएस स्वाक्षरी वापरून उच्च-फ्रिक्वेंसी यादृच्छिक निर्मितीसाठी आधार म्हणून वापरतो, कदाचित आम्ही स्वतःला फक्त मर्यादित करू. योजनांपैकी एक. दुर्दैवाने, प्रोटोकॉल काय असेल हे आगाऊ सांगणे अशक्य आहे; फक्त चांगली गोष्ट म्हणजे, विज्ञानाप्रमाणे, अभियांत्रिकी समस्यांमध्ये, नकारात्मक परिणाम देखील होतो आणि समस्येचे निराकरण करण्याचा प्रत्येक नवीन प्रयत्न हा दुसरा टप्पा असतो. समस्येमध्ये गुंतलेल्या प्रत्येकाचे संशोधन. व्यवसायाच्या गरजा पूर्ण करण्यासाठी, आम्ही एक विशिष्ट व्यावहारिक समस्या सोडवतो - गेमिंग ऍप्लिकेशन्सला एन्ट्रॉपीचा विश्वासार्ह स्त्रोत प्रदान करणे, म्हणून आम्हाला ब्लॉकचेनवर देखील लक्ष द्यावे लागेल, विशेषतः साखळी अंतिमता आणि नेटवर्क गव्हर्नन्सच्या समस्यांकडे.

आणि जरी आम्हाला ब्लॉकचेनमध्ये अद्याप सिद्ध प्रतिरोधक PVRB दिसत नाही, ज्याचा वापर वास्तविक अनुप्रयोग, एकाधिक ऑडिट, लोड आणि अर्थातच वास्तविक हल्ल्यांद्वारे चाचणी करण्यासाठी पुरेसा वेळ वापरला गेला असेल, परंतु संभाव्य मार्गांची संख्या याची पुष्टी करते. एक उपाय अस्तित्वात आहे, आणि यापैकी कोणते अल्गोरिदम शेवटी समस्येचे निराकरण करतील. आम्हाला परिणाम सामायिक करण्यात आनंद होईल आणि अभियंत्यांना एकाच रेकवर दोनदा पाऊल ठेवू न देणार्‍या लेख आणि कोडसाठी या समस्येवर काम करणार्‍या इतर संघांचे आभार मानू.

म्हणून, जेव्हा तुम्ही विकेंद्रित यादृच्छिक डिझाइन करणाऱ्या प्रोग्रामरला भेटता तेव्हा लक्ष द्या आणि काळजी घ्या आणि आवश्यक असल्यास मानसिक मदत द्या :)

स्त्रोत: www.habr.com