परिचय

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

क्रिप्टोग्राफी से बिल्कुल मजबूत सिफर की अवधारणा के साथ, वास्तविक "सार्वजनिक रूप से सत्यापन योग्य रैंडम बीकन" (इसके बाद पीवीआरबी) प्रोटोकॉल केवल आदर्श योजना के जितना संभव हो उतना करीब पहुंचने का प्रयास करते हैं, क्योंकि वास्तविक नेटवर्क में यह अपने शुद्ध रूप में लागू नहीं होता है: एक बिट पर सख्ती से सहमत होना आवश्यक है, कई राउंड होने चाहिए, और सभी संदेश पूरी तरह से तेज़ और हमेशा वितरित होने चाहिए। बेशक, वास्तविक नेटवर्क में ऐसा नहीं है। इसलिए, आधुनिक ब्लॉकचेन में विशिष्ट कार्यों के लिए पीवीआरबी डिजाइन करते समय, परिणामी यादृच्छिकता और क्रिप्टोग्राफ़िक ताकत को नियंत्रित करने की असंभवता के अलावा, कई और विशुद्ध रूप से वास्तुशिल्प और तकनीकी समस्याएं उत्पन्न होती हैं।

पीवीआरबी के लिए, ब्लॉकचेन स्वयं अनिवार्य रूप से एक संचार माध्यम है जिसमें संदेश = लेनदेन होता है। यह आपको नेटवर्क समस्याओं, संदेशों की गैर-डिलीवरी, मिडलवेयर के साथ समस्याओं से आंशिक रूप से सार निकालने की अनुमति देता है - ये सभी जोखिम विकेंद्रीकृत नेटवर्क द्वारा ग्रहण किए जाते हैं, और पीवीआरबी के लिए इसका मुख्य मूल्य पहले से भेजे गए लेनदेन को रद्द करने या दूषित करने में असमर्थता है - यह करता है प्रतिभागियों को प्रोटोकॉल में भाग लेने से इनकार करने की अनुमति न दें, जब तक कि उन्होंने सर्वसम्मति पर सफल हमला नहीं किया हो। सुरक्षा का यह स्तर स्वीकार्य है, इसलिए पीवीआरबी को मुख्य ब्लॉकचेन श्रृंखला के समान ही प्रतिभागियों द्वारा मिलीभगत के प्रति प्रतिरोधी होना चाहिए। साथ ही, यह संकेत देता है कि यदि नेटवर्क मुख्य ब्लॉकचेन पर सहमत है तो पीवीआरबी को आम सहमति का हिस्सा होना चाहिए, भले ही वह एकमात्र निष्पक्ष परिणामी यादृच्छिक पर भी सहमत हो। या, पीवीआरबी बस एक स्मार्ट अनुबंध द्वारा कार्यान्वित एक स्टैंडअलोन प्रोटोकॉल है जो ब्लॉकचेन और ब्लॉक के संबंध में अतुल्यकालिक रूप से काम करता है। दोनों तरीकों के अपने फायदे और नुकसान हैं, और उनके बीच का चुनाव बेहद गैर-तुच्छ है।

पीवीआरबी को लागू करने के दो तरीके

आइए पीवीआरबी को लागू करने के लिए दो विकल्पों का अधिक विस्तार से वर्णन करें - स्टैंडअलोन संस्करण, जो ब्लॉकचेन से स्वतंत्र एक स्मार्ट अनुबंध का उपयोग करके काम करता है, और प्रोटोकॉल में निर्मित सर्वसम्मति-एकीकृत संस्करण, जिसके अनुसार नेटवर्क ब्लॉकचेन पर सहमत होता है और लेनदेन को शामिल किया जाना चाहिए। सभी मामलों में, मेरा मतलब लोकप्रिय ब्लॉकचेन इंजनों से होगा: एथेरियम, ईओएस, और वे सभी जिस तरह से वे स्मार्ट अनुबंधों की मेजबानी और प्रक्रिया करते हैं।

स्टैंडअलोन अनुबंध

इस संस्करण में, पीवीआरबी एक स्मार्ट अनुबंध है जो यादृच्छिक उत्पादकों (बाद में आरपी के रूप में संदर्भित) के लेनदेन को स्वीकार करता है, उन्हें संसाधित करता है, परिणामों को जोड़ता है, और परिणामस्वरूप, एक निश्चित मूल्य पर पहुंचता है जिसे कोई भी उपयोगकर्ता इस अनुबंध से प्राप्त कर सकता है। यह मान सीधे अनुबंध में संग्रहीत नहीं किया जा सकता है, बल्कि केवल डेटा द्वारा दर्शाया जा सकता है जिससे परिणामी यादृच्छिक का एक और केवल एक मान निश्चित रूप से प्राप्त किया जा सकता है। इस योजना में, आरपी ब्लॉकचेन के उपयोगकर्ता हैं, और किसी को भी उत्पादन प्रक्रिया में भाग लेने की अनुमति दी जा सकती है।

स्टैंडअलोन-कॉन्ट्रैक्ट वाला विकल्प अच्छा है:

• पोर्टेबिलिटी (अनुबंधों को ब्लॉकचेन से ब्लॉकचेन तक खींचा जा सकता है)
• कार्यान्वयन और परीक्षण में आसानी (अनुबंध लिखना और परीक्षण करना आसान है)
• आर्थिक योजनाओं को लागू करने में सुविधा (अपना खुद का टोकन बनाना आसान है, जिसका तर्क पीवीआरबी के उद्देश्यों को पूरा करता है)
• पहले से ही काम कर रहे ब्लॉकचेन पर लॉन्च करने की संभावना

इसके नुकसान भी हैं:

• कंप्यूटिंग संसाधनों, लेनदेन की मात्रा और भंडारण पर मजबूत सीमाएं (दूसरे शब्दों में, सीपीयू/मेम/आईओ)
• अनुबंध के भीतर संचालन पर प्रतिबंध (सभी निर्देश उपलब्ध नहीं हैं, बाहरी पुस्तकालयों को जोड़ना मुश्किल है)
• ब्लॉकचेन में लेनदेन को शामिल करने की तुलना में संदेशों को तेजी से व्यवस्थित करने में असमर्थता

यह विकल्प एक पीवीआरबी को लागू करने के लिए उपयुक्त है जिसे मौजूदा नेटवर्क पर चलाने की आवश्यकता है, इसमें जटिल क्रिप्टोग्राफी नहीं है और बड़ी संख्या में इंटरैक्शन की आवश्यकता नहीं है।

सर्वसम्मति-एकीकृत

इस संस्करण में, पीवीआरबी को ब्लॉकचेन नोड कोड में लागू किया गया है, जो ब्लॉकचेन नोड्स के बीच संदेशों के आदान-प्रदान के साथ-साथ अंतर्निहित या चल रहा है। प्रोटोकॉल के परिणाम सीधे उत्पादित ब्लॉकों में लिखे जाते हैं, और प्रोटोकॉल संदेश नोड्स के बीच पी2पी नेटवर्क पर भेजे जाते हैं। चूँकि प्रोटोकॉल के परिणामस्वरूप संख्याएँ ब्लॉक में लिखी जाती हैं, नेटवर्क को उन पर आम सहमति बनानी होगी। इसका मतलब यह है कि पीवीआरबी संदेशों को, लेनदेन की तरह, नोड्स द्वारा मान्य किया जाना चाहिए और ब्लॉक में शामिल किया जाना चाहिए ताकि कोई भी नेटवर्क भागीदार पीवीआरबी प्रोटोकॉल के अनुपालन को मान्य कर सके। यह स्वचालित रूप से हमें स्पष्ट समाधान की ओर ले जाता है - यदि नेटवर्क किसी ब्लॉक और उसमें लेनदेन के बारे में आम सहमति पर सहमत होता है, तो पीवीआरबी को आम सहमति का हिस्सा होना चाहिए, न कि एक स्टैंड-अलोन प्रोटोकॉल। अन्यथा, यह संभव है कि एक ब्लॉक सर्वसम्मति के दृष्टिकोण से वैध है, लेकिन पीवीआरबी प्रोटोकॉल का पालन नहीं किया जाता है, और पीवीआरबी के दृष्टिकोण से ब्लॉक को स्वीकार नहीं किया जा सकता है। इसलिए यदि "आम सहमति-एकीकृत" विकल्प चुना जाता है, तो पीवीआरबी आम सहमति का एक महत्वपूर्ण हिस्सा बन जाता है।

नेटवर्क सर्वसम्मति स्तर पर पीवीआरबी कार्यान्वयन का वर्णन करते समय, कोई भी किसी भी तरह से अंतिमता के मुद्दों से बच नहीं सकता है। अंतिमता एक ऐसा तंत्र है जिसका उपयोग नियतात्मक सर्वसम्मति में किया जाता है जो एक ब्लॉक (और उस तक पहुंचने वाली श्रृंखला) में लॉक हो जाता है जो अंतिम होता है और इसे कभी भी फेंका नहीं जाएगा, भले ही एक समानांतर कांटा हो। उदाहरण के लिए, बिटकॉइन में ऐसी कोई व्यवस्था नहीं है - यदि आप अधिक जटिलता की श्रृंखला प्रकाशित करते हैं, तो यह श्रृंखला की लंबाई की परवाह किए बिना, किसी भी कम जटिल श्रृंखला को प्रतिस्थापित कर देगी। और उदाहरण के लिए, ईओएस में, अंतिम तथाकथित अंतिम अपरिवर्तनीय ब्लॉक होते हैं, जो औसतन हर 432 ब्लॉक (12*21 + 12*15, प्री-वोट + प्री-कमिट) पर दिखाई देते हैं। यह प्रक्रिया अनिवार्य रूप से 2/3 ब्लॉक-निर्माताओं (बाद में बीपी के रूप में संदर्भित) के हस्ताक्षर की प्रतीक्षा कर रही है। जब ऐसे कांटे दिखाई देते हैं जो अंतिम एलआईबी से पुराने होते हैं, तो उन्हें आसानी से त्याग दिया जाता है। यह तंत्र यह गारंटी देना संभव बनाता है कि लेनदेन ब्लॉकचेन में शामिल है और इसे कभी भी वापस नहीं लिया जाएगा, चाहे हमलावर के पास कितने भी संसाधन हों। इसके अलावा, अंतिम ब्लॉक हाइपरलेजर, टेंडरमिंट और अन्य पीबीएफटी-आधारित सर्वसम्मति में 2/3 बीपी द्वारा हस्ताक्षरित ब्लॉक हैं। साथ ही, सर्वसम्मति के लिए अंतिम रूप से ऐड-ऑन सुनिश्चित करने के लिए एक प्रोटोकॉल बनाना समझ में आता है, क्योंकि यह ब्लॉक के उत्पादन और प्रकाशन के साथ अतुल्यकालिक रूप से काम कर सकता है। यहाँ एक अच्छा है लेख एथेरियम में अंतिमता के बारे में।

अंतिमता उन उपयोगकर्ताओं के लिए बेहद महत्वपूर्ण है, जो इसके बिना खुद को "दोहरे खर्च" हमले का शिकार पा सकते हैं, जहां बीपी "ब्लॉक" रखता है, और नेटवर्क द्वारा एक अच्छा लेनदेन "देखने" के बाद उन्हें प्रकाशित करता है। यदि कोई अंतिमता नहीं है, तो प्रकाशित कांटा ब्लॉक को "अच्छे" लेनदेन के साथ दूसरे "खराब" कांटे से बदल देता है, जिसमें समान धनराशि हमलावर के पते पर स्थानांतरित कर दी जाती है। पीवीआरबी के मामले में, अंतिमता की आवश्यकताएं और भी अधिक कठोर हैं, क्योंकि पीवीआरबी के लिए फोर्क बनाने का अर्थ है एक हमलावर के लिए सबसे लाभदायक विकल्प प्रकाशित करने के लिए कई यादृच्छिक विकल्प तैयार करने का अवसर, और संभावित हमले के समय को सीमित करना एक है अच्छा समाधान।

इसलिए, सबसे अच्छा विकल्प पीवीआरबी और अंतिमता को एक प्रोटोकॉल में संयोजित करना है - फिर अंतिम ब्लॉक = अंतिम रूप से यादृच्छिक, और यह वही है जो हमें प्राप्त करने की आवश्यकता है। अब खिलाड़ियों को एन सेकंड में एक गारंटीशुदा रैंडम प्राप्त होगा, और वे यह सुनिश्चित कर सकते हैं कि इसे वापस रोल करना या दोबारा खेलना असंभव है।

सर्वसम्मति-एकीकृत विकल्प अच्छा है:

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

इसके नुकसान भी हैं:

• परीक्षण और विकास में कठिनाइयाँ - आपको नेटवर्क त्रुटियों, लापता नोड्स, नेटवर्क हार्ड फोर्क्स का अनुकरण करना होगा
• कार्यान्वयन त्रुटियों के लिए नेटवर्क हार्डफोर्क की आवश्यकता होती है

पीवीआरबी को लागू करने के दोनों तरीकों में जीवन का अधिकार है, लेकिन आधुनिक ब्लॉकचेन में स्मार्ट अनुबंधों पर कार्यान्वयन अभी भी कंप्यूटिंग संसाधनों में काफी सीमित है, और गंभीर क्रिप्टोग्राफी में कोई भी संक्रमण अक्सर असंभव होता है। और हमें गंभीर क्रिप्टोग्राफी की आवश्यकता होगी, जैसा कि नीचे दिखाया जाएगा। हालाँकि यह समस्या स्पष्ट रूप से अस्थायी है, कई समस्याओं को हल करने के लिए अनुबंधों में गंभीर क्रिप्टोग्राफी की आवश्यकता है, और यह धीरे-धीरे प्रकट हो रही है (उदाहरण के लिए, एथेरियम में zkSNARKs के लिए सिस्टम अनुबंध)

ब्लॉकचेन, जो एक पारदर्शी और विश्वसनीय प्रोटोकॉल मैसेजिंग चैनल प्रदान करता है, मुफ्त में ऐसा नहीं करता है। किसी भी विकेन्द्रीकृत प्रोटोकॉल को सिबिल हमले की संभावना को ध्यान में रखना चाहिए; कोई भी कार्रवाई कई खातों की ठोस ताकतों द्वारा की जा सकती है, इसलिए, डिज़ाइन करते समय, हमलावरों की मनमानी संख्या में प्रोटोकॉल बनाने की क्षमता को ध्यान में रखना आवश्यक है मिलीभगत से काम कर रहे प्रतिभागी

पीवीआरबी और ब्लॉक चर।

मैंने झूठ नहीं बोला जब मैंने कहा कि किसी ने अभी तक ब्लॉकचेन में कई जुआ अनुप्रयोगों द्वारा परीक्षण किया गया एक अच्छा पीवीआरबी लागू नहीं किया है। तो फिर एथेरियम और ईओएस पर इतने सारे जुआ एप्लिकेशन कहां से आते हैं? यह मुझे उतना ही आश्चर्यचकित करता है जितना आपको आश्चर्यचकित करता है, पूरी तरह से नियतिवादी वातावरण में उन्हें इतने सारे "निरंतर" यादृच्छिकताएं कहां से मिलीं?

ब्लॉकचेन में यादृच्छिकता प्राप्त करने का पसंदीदा तरीका ब्लॉक से कुछ प्रकार की "अप्रत्याशित" जानकारी लेना और उसके आधार पर एक यादृच्छिक जानकारी बनाना है - बस एक या अधिक मानों को हैश करके। ऐसी योजनाओं की समस्याओं के बारे में अच्छा लेख यहां. आप ब्लॉक में कोई भी "अप्रत्याशित" मान ले सकते हैं, उदाहरण के लिए, ब्लॉक हैश, लेनदेन की संख्या, नेटवर्क जटिलता और पहले से अज्ञात अन्य मान। फिर उन्हें हैश करें, एक या अधिक, और, सिद्धांत रूप में, आपको एक वास्तविक यादृच्छिक प्राप्त करना चाहिए। आप व्हाइटपेपर में यह भी जोड़ सकते हैं कि आपकी योजना "पोस्ट-क्वांटम सुरक्षित" है (क्योंकि इसमें क्वांटम-प्रूफ हैश फ़ंक्शन हैं :))।

लेकिन अफ़सोस, पोस्ट-क्वांटम सुरक्षित हैश भी पर्याप्त नहीं हैं। रहस्य पीवीआरबी की आवश्यकताओं में छिपा है, मैं आपको पिछले लेख से उनकी याद दिला दूं:

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

इस मामले में, केवल आवश्यकता 1 पूरी होती है, और आवश्यकता 2 पूरी नहीं होती है। ब्लॉक से अप्रत्याशित मानों को हैश करके, हमें एक समान वितरण और अच्छे रैंडम मिलेंगे। लेकिन बीपी के पास कम से कम "ब्लॉक प्रकाशित करें या नहीं" का विकल्प है। इस प्रकार, बीपी कम से कम दो यादृच्छिक विकल्पों में से चुन सकता है: "अपना खुद का" और वह जो बाहर निकल जाएगा यदि कोई और ब्लॉक करता है। बीपी पहले से ही "जासूस" कर सकता है कि यदि वह कोई ब्लॉक प्रकाशित करता है तो क्या होगा, और बस यह तय कर लेता है कि इसे करना है या नहीं। इस प्रकार, उदाहरण के लिए, रूलेट में "सम-विषम" या "लाल/काला" खेलते समय, वह केवल तभी एक ब्लॉक प्रकाशित कर सकता है जब उसे जीत दिखाई देती है। यह, उदाहरण के लिए, "भविष्य से" ब्लॉक हैश का उपयोग करने की रणनीति को भी अव्यवहारिक बनाता है। इस मामले में, वे कहते हैं कि "यादृच्छिक का उपयोग किया जाएगा, जो वर्तमान डेटा और भविष्य के ब्लॉक के हैश को ऊंचाई के साथ प्राप्त किया जाता है, उदाहरण के लिए, एन + 42, जहां एन वर्तमान ब्लॉक ऊंचाई है। यह योजना को थोड़ा मजबूत करता है, लेकिन फिर भी बीपी को, भविष्य में, यह चुनने की अनुमति देता है कि ब्लॉक को रोकना है या प्रकाशित करना है।

इस मामले में बीपी सॉफ्टवेयर अधिक जटिल हो जाता है, लेकिन ज्यादा नहीं। बस, किसी ब्लॉक में लेन-देन को मान्य और शामिल करते समय, यह देखने के लिए एक त्वरित जांच होती है कि जीत होगी या नहीं, और, संभवतः, जीतने की उच्च संभावना प्राप्त करने के लिए एक लेन-देन पैरामीटर का चयन किया जाता है। साथ ही, इस तरह के हेरफेर के लिए स्मार्ट बीपी को पकड़ना लगभग असंभव है; हर बार आप नए पते का उपयोग कर सकते हैं और संदेह पैदा किए बिना थोड़ा-थोड़ा करके जीत सकते हैं।

इसलिए ब्लॉक से जानकारी का उपयोग करने वाली विधियां पीवीआरबी के सार्वभौमिक कार्यान्वयन के रूप में उपयुक्त नहीं हैं। सीमित संस्करण में, दांव के आकार पर प्रतिबंध, खिलाड़ियों की संख्या पर प्रतिबंध और/या केवाईसी पंजीकरण (एक खिलाड़ी को एकाधिक पते का उपयोग करने से रोकने के लिए) के साथ, ये योजनाएं छोटे खेलों के लिए काम कर सकती हैं, लेकिन इससे अधिक कुछ नहीं।

पीवीआरबी और प्रतिबद्धता-प्रकटीकरण।

ठीक है, हैशिंग और कम से कम ब्लॉक हैश और अन्य चर की सापेक्ष अप्रत्याशितता के लिए धन्यवाद। यदि आप अग्रणी खनिकों की समस्या का समाधान करते हैं, तो आपको कुछ और उपयुक्त मिलना चाहिए। आइए इस योजना में उपयोगकर्ताओं को जोड़ें - उन्हें यादृच्छिकता को भी प्रभावित करने दें: कोई भी तकनीकी सहायता कर्मचारी आपको बताएगा कि आईटी सिस्टम में सबसे यादृच्छिक चीज उपयोगकर्ताओं की गतिविधियां हैं :)

एक भोली-भाली योजना, जब उपयोगकर्ता केवल यादृच्छिक संख्याएँ भेजते हैं और परिणाम की गणना इस प्रकार की जाती है, उदाहरण के लिए, उनके योग का हैश, उपयुक्त नहीं है। इस मामले में, अंतिम खिलाड़ी अपना यादृच्छिक चयन करके यह नियंत्रित कर सकता है कि परिणाम क्या होगा। यही कारण है कि बहुत व्यापक रूप से उपयोग किए जाने वाले कमिट-रिवील पैटर्न का उपयोग किया जाता है। प्रतिभागी पहले अपने रैंडम (कमिट) से हैश भेजते हैं, और फिर रैंडम को स्वयं खोलते हैं (खुलासा करते हैं)। "प्रकटीकरण" चरण आवश्यक प्रतिबद्धताएँ एकत्र होने के बाद ही शुरू होता है, इसलिए प्रतिभागी बिल्कुल वही यादृच्छिक हैश भेज सकते हैं जिससे उन्होंने पहले भेजा था। आइए अब इन सभी को एक ब्लॉक के मापदंडों के साथ एक साथ रखें, और भविष्य से लिए गए पैरामीटर से बेहतर (यादृच्छिकता केवल भविष्य के ब्लॉकों में से एक में पाई जा सकती है), और वोइला - यादृच्छिकता तैयार है! अब कोई भी खिलाड़ी परिणामी यादृच्छिकता को प्रभावित करता है, और दुर्भावनापूर्ण बीपी को अपने स्वयं के, पहले से अज्ञात, यादृच्छिकता के साथ ओवरराइड करके "पराजित" कर सकता है... आप प्रोटोकॉल को प्रकट चरण में न खोलकर तोड़फोड़ के खिलाफ सुरक्षा भी जोड़ सकते हैं - बस लेन-देन करते समय एक निश्चित राशि संलग्न करने की आवश्यकता होती है - एक सुरक्षा जमा, जो केवल खुलासा प्रक्रिया के दौरान वापस किया जाएगा। इस मामले में, प्रतिबद्ध होना और खुलासा न करना लाभहीन होगा।

यह एक अच्छा प्रयास था, और ऐसी योजनाएँ गेमिंग डीएपी में भी मौजूद हैं, लेकिन अफसोस, यह फिर से पर्याप्त नहीं है। अब न केवल खनिक, बल्कि प्रोटोकॉल में कोई भी भागीदार भी परिणाम को प्रभावित कर सकता है। कम परिवर्तनशीलता और लागत पर मूल्य को नियंत्रित करना अभी भी संभव है, लेकिन, जैसा कि खनिक के मामले में होता है, यदि ड्राइंग के परिणाम पीवीआरबी प्रोटोकॉल में भागीदारी के लिए शुल्क से अधिक मूल्यवान हैं, तो यादृच्छिक -निर्माता (आरपी) तय कर सकता है कि प्रकट करना है या नहीं और फिर भी वह कम से कम दो यादृच्छिक विकल्पों में से चुन सकता है।
लेकिन करने और न बताने वालों को सजा देना संभव हो गया और यह योजना काम आएगी। इसकी सरलता एक गंभीर लाभ है - अधिक गंभीर प्रोटोकॉल के लिए अधिक शक्तिशाली गणनाओं की आवश्यकता होती है।

पीवीआरबी और नियतात्मक हस्ताक्षर।

आरपी को एक छद्म-यादृच्छिक संख्या प्रदान करने के लिए मजबूर करने का एक और तरीका है जिसे "प्रीइमेज" प्रदान किए जाने पर वह प्रभावित नहीं कर सकता है - यह एक नियतात्मक हस्ताक्षर है। ऐसा हस्ताक्षर, उदाहरण के लिए, आरएसए है, और ईसीएस नहीं है। यदि आरपी के पास चाबियों की एक जोड़ी है: आरएसए और ईसीसी, और वह अपनी निजी कुंजी के साथ एक निश्चित मूल्य पर हस्ताक्षर करता है, तो आरएसए के मामले में उसे एक और केवल एक हस्ताक्षर मिलेगा, और ईसीएस के मामले में वह कितनी भी संख्या उत्पन्न कर सकता है विभिन्न वैध हस्ताक्षर. ऐसा इसलिए है क्योंकि ईसीएस हस्ताक्षर बनाते समय, एक यादृच्छिक संख्या का उपयोग किया जाता है, जिसे हस्ताक्षरकर्ता द्वारा चुना जाता है, और इसे किसी भी तरह से चुना जा सकता है, जिससे हस्ताक्षरकर्ता को कई हस्ताक्षरों में से एक को चुनने का अवसर मिलता है। आरएसए के मामले में: "एक इनपुट मान" + "एक कुंजी जोड़ी" = "एक हस्ताक्षर"। यह अनुमान लगाना असंभव है कि किसी अन्य आरपी को कौन सा हस्ताक्षर मिलेगा, इसलिए समान मूल्य पर हस्ताक्षर करने वाले कई प्रतिभागियों के आरएसए हस्ताक्षरों को मिलाकर नियतात्मक हस्ताक्षर वाले एक पीवीआरबी को व्यवस्थित किया जा सकता है। उदाहरण के लिए, पिछला यादृच्छिक. यह योजना बहुत सारे संसाधनों को बचाती है, क्योंकि हस्ताक्षर प्रोटोकॉल के अनुसार सही व्यवहार की पुष्टि और यादृच्छिकता का स्रोत दोनों हैं।

हालाँकि, नियतिवादी हस्ताक्षरों के साथ भी, योजना अभी भी "अंतिम अभिनेता" समस्या के प्रति संवेदनशील है। अंतिम प्रतिभागी अभी भी यह तय कर सकता है कि हस्ताक्षर प्रकाशित करना है या नहीं, जिससे परिणाम नियंत्रित हो सके। आप योजना को संशोधित कर सकते हैं, इसमें ब्लॉक हैश जोड़ सकते हैं, राउंड बना सकते हैं ताकि परिणाम की पहले से भविष्यवाणी न की जा सके, लेकिन ये सभी तकनीकें, कई संशोधनों को ध्यान में रखते हुए भी, सामूहिक पर एक प्रतिभागी के प्रभाव की समस्या को अनसुलझा छोड़ देती हैं इसका परिणाम अविश्वसनीय वातावरण होता है और यह केवल आर्थिक और समय की कमी के तहत ही काम कर सकता है। इसके अलावा, आरएसए कुंजियों का आकार (1024 और 2048 बिट्स) काफी बड़ा है, और ब्लॉकचेन लेनदेन के लिए आकार एक अत्यंत महत्वपूर्ण पैरामीटर है। जाहिर तौर पर समस्या को हल करने का कोई आसान तरीका नहीं है, चलिए आगे बढ़ते हैं।

पीवीआरबी और गुप्त साझाकरण योजनाएँ

क्रिप्टोग्राफी में, ऐसी योजनाएं हैं जो नेटवर्क को एक और केवल एक पीवीआरबी मूल्य पर सहमत होने की अनुमति दे सकती हैं, जबकि ऐसी योजनाएं कुछ प्रतिभागियों के किसी भी दुर्भावनापूर्ण कार्यों के प्रति प्रतिरोधी हैं। एक उपयोगी प्रोटोकॉल जिससे परिचित होना जरूरी है वह है शमीर की गुप्त साझाकरण योजना। यह एक रहस्य (उदाहरण के लिए, एक गुप्त कुंजी) को कई भागों में विभाजित करने और इन भागों को एन प्रतिभागियों को वितरित करने का कार्य करता है। रहस्य को इस तरह से वितरित किया गया है कि N में से M भाग इसे पुनर्प्राप्त करने के लिए पर्याप्त हैं, और ये कोई भी M भाग हो सकते हैं। यदि उंगलियों पर, किसी अज्ञात फ़ंक्शन का ग्राफ़ होने पर, प्रतिभागी ग्राफ़ पर बिंदुओं का आदान-प्रदान करते हैं, और एम अंक प्राप्त करने के बाद, पूरे फ़ंक्शन को पुनर्स्थापित किया जा सकता है।
में एक अच्छी व्याख्या दी गई है विकि लेकिन प्रोटोकॉल को अपने दिमाग में चलाने के लिए व्यावहारिक रूप से इसके साथ खेलना उपयोगी है डेमो पृष्ठ।

यदि एफएसएसएस (फिएट-शमीर सीक्रेट शेयरिंग) योजना अपने शुद्ध रूप में लागू होती, तो यह एक अविनाशी पीवीआरबी होती। अपने सरलतम रूप में, प्रोटोकॉल इस तरह दिख सकता है:

• प्रत्येक प्रतिभागी अपना स्वयं का रैंडम उत्पन्न करता है और उसमें से अन्य प्रतिभागियों को शेयर वितरित करता है
• प्रत्येक प्रतिभागी अन्य प्रतिभागियों के अपने हिस्से के रहस्यों को उजागर करता है
• यदि किसी प्रतिभागी के पास एम से अधिक शेयर हैं, तो इस प्रतिभागी की संख्या की गणना की जा सकती है, और यह अद्वितीय होगा, चाहे प्रकट प्रतिभागियों का समूह कुछ भी हो
• प्रकट यादृच्छिकों का संयोजन वांछित पीवीआरबी है

यहां, एक व्यक्तिगत भागीदार अब प्रोटोकॉल के परिणामों को प्रभावित नहीं करता है, सिवाय उन मामलों के जहां यादृच्छिकता प्रकटीकरण सीमा की उपलब्धि पूरी तरह से उस पर निर्भर करती है। इसलिए, यह प्रोटोकॉल, यदि प्रोटोकॉल पर काम करने वाले और उपलब्ध आरपी का आवश्यक अनुपात है, तो काम करता है, क्रिप्टोग्राफ़िक ताकत के लिए आवश्यकताओं को लागू करता है, और "अंतिम अभिनेता" समस्या के प्रति प्रतिरोधी होता है।

यह एक आदर्श विकल्प हो सकता है, फिएट-शमीर गुप्त साझाकरण पर आधारित यह पीवीआरबी योजना उदाहरण के लिए वर्णित है यह लेख। लेकिन, जैसा कि ऊपर बताया गया है, यदि आप इसे ब्लॉकचेन में सीधे लागू करने का प्रयास करते हैं, तो तकनीकी सीमाएँ दिखाई देती हैं। यहां ईओएस स्मार्ट अनुबंध में प्रोटोकॉल के परीक्षण कार्यान्वयन और इसके सबसे महत्वपूर्ण भाग - प्रकाशित शेयर भागीदार की जांच का एक उदाहरण दिया गया है: कोड. आप कोड से देख सकते हैं कि प्रमाण सत्यापन के लिए कई अदिश गुणन की आवश्यकता होती है, और उपयोग की गई संख्याएँ बहुत बड़ी हैं। यह समझा जाना चाहिए कि ब्लॉकचेन में, सत्यापन उस समय होता है जब ब्लॉक-निर्माता लेनदेन की प्रक्रिया करता है, और सामान्य तौर पर, किसी भी प्रतिभागी को प्रोटोकॉल की शुद्धता को आसानी से सत्यापित करना होगा, इसलिए सत्यापित फ़ंक्शन की गति की आवश्यकताएं बहुत गंभीर हैं . इस विकल्प में, विकल्प अप्रभावी साबित हुआ, क्योंकि सत्यापन लेनदेन सीमा (0.5 सेकंड) के भीतर फिट नहीं था।

सामान्य तौर पर, ब्लॉकचेन में किसी भी उन्नत क्रिप्टोग्राफ़िक योजनाओं के उपयोग के लिए सत्यापन दक्षता सबसे महत्वपूर्ण आवश्यकताओं में से एक है। सबूत बनाना, संदेश तैयार करना - इन प्रक्रियाओं को ऑफ-चेन किया जा सकता है और उच्च-प्रदर्शन वाले कंप्यूटरों पर निष्पादित किया जा सकता है, लेकिन सत्यापन को नजरअंदाज नहीं किया जा सकता है - यह पीवीआरबी के लिए एक और महत्वपूर्ण आवश्यकता है।

पीवीआरबी और थ्रेशोल्ड हस्ताक्षर

गुप्त साझाकरण योजना से परिचित होने के बाद, हमने "थ्रेसहोल्ड" कीवर्ड द्वारा एकजुट प्रोटोकॉल की एक पूरी श्रेणी की खोज की। जब कुछ जानकारी के प्रकटीकरण के लिए एन में से एम ईमानदार प्रतिभागियों की भागीदारी की आवश्यकता होती है, और ईमानदार प्रतिभागियों का सेट एन का एक मनमाना उपसमूह हो सकता है, तो हम "सीमा" योजनाओं की बात करते हैं। यह वे हैं जो हमें "अंतिम अभिनेता" समस्या से निपटने की अनुमति देते हैं, अब यदि हमलावर अपने हिस्से के रहस्य का खुलासा नहीं करता है, तो कोई अन्य, ईमानदार भागीदार उसके लिए यह करेगा। ये योजनाएं एक और केवल एक ही अर्थ पर सहमति की अनुमति देती हैं, भले ही कुछ प्रतिभागियों द्वारा प्रोटोकॉल में तोड़फोड़ की गई हो।

नियतात्मक हस्ताक्षरों और थ्रेशोल्ड योजनाओं के संयोजन ने पीवीआरबी को लागू करने के लिए एक बहुत ही सुविधाजनक और आशाजनक योजना विकसित करना संभव बना दिया - ये नियतात्मक थ्रेशोल्ड हस्ताक्षर हैं। यहाँ लेख थ्रेशोल्ड हस्ताक्षरों के विभिन्न उपयोगों के बारे में, और यहाँ एक और अच्छा है longread डैश से.

अंतिम लेख में बीएलएस हस्ताक्षरों का वर्णन किया गया है (बीएलएस का अर्थ बोनेह-लिन-शाचम है, यहां लेख), जिसमें प्रोग्रामर के लिए एक बहुत ही महत्वपूर्ण और बेहद सुविधाजनक गुणवत्ता है - सार्वजनिक, गुप्त, सार्वजनिक कुंजी और बीएलएस हस्ताक्षर को सरल गणितीय संचालन का उपयोग करके एक दूसरे के साथ जोड़ा जा सकता है, जबकि उनके संयोजन वैध कुंजी और हस्ताक्षर बने रहते हैं, जिससे आप आसानी से कई एकत्र कर सकते हैं एक में हस्ताक्षर और एक में कई सार्वजनिक कुंजियाँ। वे नियतात्मक भी हैं और समान इनपुट डेटा के लिए समान परिणाम उत्पन्न करते हैं। इस गुणवत्ता के लिए धन्यवाद, बीएलएस हस्ताक्षरों का संयोजन स्वयं वैध कुंजी है, जो एक विकल्प के कार्यान्वयन की अनुमति देता है जिसमें एन प्रतिभागियों में से एम एक और केवल एक हस्ताक्षर उत्पन्न करता है जो नियतात्मक, सार्वजनिक रूप से सत्यापन योग्य और अप्रत्याशित होता है जब तक कि इसे एमटीएच द्वारा नहीं खोला जाता है। प्रतिभागी.

थ्रेशोल्ड बीएलएस हस्ताक्षर वाली एक योजना में, प्रत्येक प्रतिभागी बीएलएस (उदाहरण के लिए, पिछला यादृच्छिक) का उपयोग करके कुछ पर हस्ताक्षर करता है, और सामान्य थ्रेशोल्ड हस्ताक्षर वांछित यादृच्छिक होता है। बीएलएस हस्ताक्षरों के क्रिप्टोग्राफ़िक गुण यादृच्छिक गुणवत्ता की आवश्यकताओं को पूरा करते हैं, थ्रेशोल्ड भाग "अंतिम-अभिनेता" से बचाता है, और कुंजियों की अद्वितीय संयोजनता कई और दिलचस्प एल्गोरिदम को लागू करना संभव बनाती है जो अनुमति देते हैं, उदाहरण के लिए, प्रोटोकॉल संदेशों का कुशल एकत्रीकरण .

इसलिए, यदि आप अपने ब्लॉकचेन पर पीवीआरबी का निर्माण कर रहे हैं, तो संभवतः आप बीएलएस थ्रेशोल्ड हस्ताक्षर योजना के साथ समाप्त हो जाएंगे, कई परियोजनाएं पहले से ही इसका उपयोग कर रही हैं। उदाहरण के लिए, डीफ़िनिटी (यहां बेंचमार्क जो सर्किट को लागू करता है, और यहां सत्यापन योग्य गुप्त साझाकरण का उदाहरण कार्यान्वयन), या Keep.network (यहां उनका यादृच्छिक बीकन है android, लेकिन उदाहरण प्रोटोकॉल परोसने वाला स्मार्ट अनुबंध)।

पीवीआरबी का कार्यान्वयन

दुर्भाग्य से, हम अभी भी पीवीआरबी ब्लॉकचेन में लागू कोई तैयार प्रोटोकॉल नहीं देखते हैं जिसने इसकी सुरक्षा और स्थिरता साबित की हो। भले ही प्रोटोकॉल स्वयं तैयार हैं, तकनीकी रूप से उन्हें मौजूदा समाधानों पर लागू करना आसान नहीं है। केंद्रीकृत सिस्टम के लिए, पीवीआरबी का कोई मतलब नहीं है, और विकेन्द्रीकृत सिस्टम सभी कंप्यूटिंग संसाधनों में सख्ती से सीमित हैं: सीपीयू, मेमोरी, स्टोरेज, आई/ओ। पीवीआरबी को डिज़ाइन करना कुछ ऐसा बनाने के लिए विभिन्न प्रोटोकॉल का संयोजन है जो कम से कम कुछ व्यवहार्य ब्लॉकचेन के लिए सभी आवश्यकताओं को पूरा करता है। एक प्रोटोकॉल अधिक कुशलता से गणना करता है, लेकिन आरपी के बीच अधिक संदेशों की आवश्यकता होती है, जबकि दूसरे को बहुत कम संदेशों की आवश्यकता होती है, लेकिन प्रमाण बनाना एक ऐसा कार्य हो सकता है जिसमें दसियों मिनट या घंटे भी लग सकते हैं।

मैं उन कारकों की सूची बनाऊंगा जिन पर आपको गुणवत्तापूर्ण पीवीआरबी चुनते समय विचार करना होगा:

• क्रिप्टोग्राफ़िक ताकत. आपका पीवीआरबी पूरी तरह से निष्पक्ष होना चाहिए, जिसमें एक भी बिट को नियंत्रित करने की क्षमता नहीं होनी चाहिए। कुछ योजनाओं में ऐसा नहीं है, इसलिए क्रिप्टोग्राफर को बुलाएँ
• "अंतिम अभिनेता" समस्या. आपका पीवीआरबी उन हमलों के प्रति प्रतिरोधी होना चाहिए जहां एक या अधिक आरपी को नियंत्रित करने वाला हमलावर दो परिणामों में से एक चुन सकता है।
• प्रोटोकॉल तोड़फोड़ की समस्या. आपका पीवीआरबी उन हमलों के प्रति प्रतिरोधी होना चाहिए जहां एक या अधिक आरपी को नियंत्रित करने वाला हमलावर यह निर्णय लेता है कि यादृच्छिक होना है या नहीं और इसे प्रभावित करने के लिए या तो गारंटी दी जा सकती है या दी गई संभावना के साथ।
• संदेशों की संख्या की समस्या. आपके आरपी को ब्लॉकचेन पर कम से कम संदेश भेजना चाहिए और जितना संभव हो समकालिक कार्यों से बचना चाहिए जैसे कि "मैंने कुछ जानकारी भेजी है, मैं एक विशिष्ट भागीदार से प्रतिक्रिया की प्रतीक्षा कर रहा हूं।" पी2पी नेटवर्क में, विशेष रूप से भौगोलिक रूप से फैले हुए नेटवर्क में, आपको त्वरित प्रतिक्रिया पर भरोसा नहीं करना चाहिए
• कम्प्यूटेशनल जटिलता की समस्या. पीवीआरबी ऑन-चेन के किसी भी चरण का सत्यापन बेहद आसान होना चाहिए, क्योंकि यह नेटवर्क के सभी पूर्ण ग्राहकों द्वारा किया जाता है। यदि कार्यान्वयन स्मार्ट अनुबंध का उपयोग करके किया जाता है, तो गति की आवश्यकताएं बहुत सख्त हैं
• पहुंच और जीवंतता की समस्या. आपके पीवीआरबी को उन स्थितियों के प्रति लचीला होने का प्रयास करना चाहिए जहां नेटवर्क का एक हिस्सा कुछ समय के लिए अनुपलब्ध हो जाता है और आरपी का एक हिस्सा काम करना बंद कर देता है।
• विश्वसनीय सेटअप और प्रारंभिक कुंजी वितरण की समस्या. यदि आपका पीवीआरबी प्रोटोकॉल के प्राथमिक सेटअप का उपयोग करता है, तो यह एक अलग बड़ी और गंभीर कहानी है। यहाँ उदाहरण. यदि प्रतिभागियों को प्रोटोकॉल शुरू करने से पहले एक-दूसरे को अपनी चाबियाँ बतानी होंगी, तो प्रतिभागियों की संरचना में परिवर्तन होने पर यह भी एक समस्या है
• विकास की समस्याएं. आवश्यक भाषाओं में पुस्तकालयों की उपलब्धता, उनकी सुरक्षा और प्रदर्शन, प्रचार, जटिल परीक्षण आदि।

उदाहरण के लिए, थ्रेशोल्ड बीएलएस हस्ताक्षरों में एक महत्वपूर्ण समस्या है - काम शुरू करने से पहले, प्रतिभागियों को एक दूसरे को चाबियाँ वितरित करनी होंगी, एक समूह का आयोजन करना होगा जिसके भीतर थ्रेशोल्ड काम करेगा। इसका मतलब यह है कि विकेन्द्रीकृत नेटवर्क में विनिमय के कम से कम एक दौर के लिए इंतजार करना होगा, और यह देखते हुए कि उत्पन्न रैंड, उदाहरण के लिए, गेम में आवश्यक है, लगभग वास्तविक समय में, इसका मतलब है कि इस स्तर पर प्रोटोकॉल में तोड़फोड़ संभव है , और थ्रेशोल्ड योजना के लाभ खो गए हैं . यह समस्या पिछले वाले की तुलना में पहले से ही सरल है, लेकिन अभी भी थ्रेसहोल्ड समूहों के गठन के लिए एक अलग प्रक्रिया के विकास की आवश्यकता है, जिसे उन प्रतिभागियों से धन की जमा और निकासी (कटौती) के माध्यम से आर्थिक रूप से संरक्षित करना होगा जो इसका पालन नहीं करते हैं। शिष्टाचार। इसके अलावा, सुरक्षा के स्वीकार्य स्तर के साथ बीएलएस सत्यापन बस फिट नहीं होता है, उदाहरण के लिए, मानक ईओएस या एथेरियम लेनदेन में - सत्यापन के लिए पर्याप्त समय नहीं है। अनुबंध कोड वेबअसेंबली या ईवीएम है, जिसे वर्चुअल मशीन द्वारा निष्पादित किया जाता है। क्रिप्टोग्राफ़िक फ़ंक्शंस मूल रूप से (अभी तक) लागू नहीं किए गए हैं, और पारंपरिक क्रिप्टोग्राफ़िक लाइब्रेरीज़ की तुलना में दसियों गुना धीमी गति से काम करते हैं। कई प्रोटोकॉल केवल कुंजी वॉल्यूम के आधार पर आवश्यकताओं को पूरा नहीं करते हैं, उदाहरण के लिए आरएसए के लिए 1024 और 2048 बिट्स, बिटकॉइन और एथेरियम में मानक लेनदेन हस्ताक्षर से 4-8 गुना बड़ा।

विभिन्न प्रोग्रामिंग भाषाओं में कार्यान्वयन की उपस्थिति भी एक भूमिका निभाती है - जिनमें से कुछ हैं, खासकर नए प्रोटोकॉल के लिए। आम सहमति में एकीकरण के विकल्प के लिए प्लेटफ़ॉर्म भाषा में एक प्रोटोकॉल लिखने की आवश्यकता होती है, इसलिए आपको गो के लिए गो में, रस्ट फॉर पैरिटी में, ईओएस के लिए सी ++ में कोड की तलाश करनी होगी। हर किसी को जावास्क्रिप्ट कोड की तलाश करनी होगी, और चूंकि जावास्क्रिप्ट और क्रिप्टोग्राफी विशेष रूप से करीबी दोस्त नहीं हैं, WebAssembly मदद करेगा, जो अब निश्चित रूप से अगला महत्वपूर्ण इंटरनेट मानक होने का दावा करता है।

निष्कर्ष

मुझे पिछले वाले से आशा है लेख मैं आपको यह समझाने में कामयाब रहा कि विकेंद्रीकृत नेटवर्क के जीवन के कई पहलुओं के लिए ब्लॉकचेन पर यादृच्छिक संख्याएँ उत्पन्न करना महत्वपूर्ण है, और इस लेख के साथ मैंने दिखाया कि यह कार्य बेहद महत्वाकांक्षी और कठिन है, लेकिन अच्छे समाधान पहले से मौजूद हैं। सामान्य तौर पर, प्रोटोकॉल का अंतिम डिज़ाइन बड़े पैमाने पर परीक्षण करने के बाद ही संभव है जो सेटअप से लेकर गलती अनुकरण तक सभी पहलुओं को ध्यान में रखता है, इसलिए आपको टीम के श्वेतपत्रों और लेखों में तैयार व्यंजनों को खोजने की संभावना नहीं है, और हम निश्चित रूप से नहीं पाएंगे। तय करें कि अगले एक या दो साल में लिखें "इसे इस तरह से करो, बिल्कुल सही।"

अलविदा, विकसित किए जा रहे ब्लॉकचेन में हमारे पीवीआरबी के लिए हया, हम सीमा बीएलएस हस्ताक्षरों का उपयोग करने पर सहमत हुए, हम सर्वसम्मति स्तर पर पीवीआरबी को लागू करने की योजना बना रहे हैं, क्योंकि सुरक्षा के स्वीकार्य स्तर के साथ स्मार्ट अनुबंधों में सत्यापन अभी तक संभव नहीं है। यह संभव है कि हम एक साथ दो योजनाओं का उपयोग करें: पहला, लंबी अवधि के रैंडम_सीड बनाने के लिए महंगी गुप्त साझेदारी, और फिर हम इसे नियतात्मक सीमा बीएलएस हस्ताक्षरों का उपयोग करके उच्च-आवृत्ति यादृच्छिक पीढ़ी के आधार के रूप में उपयोग करते हैं, शायद हम खुद को केवल तक ही सीमित रखेंगे योजनाओं में से एक. दुर्भाग्य से, पहले से यह कहना असंभव है कि प्रोटोकॉल क्या होगा; एकमात्र अच्छी बात यह है कि, विज्ञान की तरह, इंजीनियरिंग समस्याओं में, एक नकारात्मक परिणाम भी एक परिणाम है, और समस्या को हल करने का प्रत्येक नया प्रयास एक और कदम है समस्या में शामिल प्रत्येक व्यक्ति का अनुसंधान। व्यावसायिक आवश्यकताओं को पूरा करने के लिए, हम एक विशिष्ट व्यावहारिक समस्या का समाधान करते हैं - गेमिंग अनुप्रयोगों को एन्ट्रापी के विश्वसनीय स्रोत के साथ प्रदान करना, इसलिए हमें ब्लॉकचेन पर भी ध्यान देना होगा, विशेष रूप से श्रृंखला की अंतिमता और नेटवर्क प्रशासन के मुद्दों पर।

और भले ही हमने अभी तक ब्लॉकचेन में एक सिद्ध प्रतिरोधी पीवीआरबी नहीं देखा है, जिसका उपयोग वास्तविक अनुप्रयोगों, एकाधिक ऑडिट, लोड और निश्चित रूप से वास्तविक हमलों द्वारा परीक्षण के लिए पर्याप्त समय के लिए किया गया होगा, लेकिन संभावित पथों की संख्या इसकी पुष्टि करती है एक समाधान मौजूद है, और इनमें से कौन सा एल्गोरिदम अंततः समस्या का समाधान करेगा। हमें परिणाम साझा करने में खुशी होगी और अन्य टीमों को भी धन्यवाद देना होगा जो इस मुद्दे पर लेखों और कोड के लिए काम कर रहे हैं जो इंजीनियरों को एक ही रेक पर दो बार कदम नहीं रखने की अनुमति देते हैं।

इसलिए, जब आप विकेन्द्रीकृत रैंडम डिजाइन करने वाले किसी प्रोग्रामर से मिलें, तो सावधान रहें और देखभाल करें, और यदि आवश्यक हो तो मनोवैज्ञानिक सहायता प्रदान करें :)

स्रोत: www.habr.com