परिचय

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

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

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

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

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

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

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

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

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

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

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

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

आम सहमति से एकीकृत

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

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

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

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

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

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

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

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

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

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

PVRB और ब्लॉक चर।

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

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

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

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

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

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

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

PVRB और प्रतिबद्ध-प्रकट।

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

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

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

PVRB और नियतात्मक हस्ताक्षर।

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

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

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

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

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

• प्रत्येक प्रतिभागी अपने खुद के यादृच्छिक उत्पन्न करता है और इसे अन्य प्रतिभागियों से शेयर वितरित करता है
• M shares, , ,
• random- PVRB

, , threshold- . , RP , , “last actor”.

, PVRB secret sharing - , , . , , , . - EOS — share : . , proof- , . , verify , block-producer , , verify . , (0.5 ).

— - . proof-, — off-chain , — PVRB.

PVRB threshold signatures

secret sharing, , “threshold”. M N, N, “threshold” . “last actor”, , , . , .

threshold- PVRB — threshold-. threshold-, longread Dash.

BLS (BLS Boneh-Lynn-Shacham, ), — , , BLS , , . . , BLS , , M N , , publicly verifiable, , M- .

threshold BLS signatures BLS - ( ), threshold- . BLS , threshold- “last-actor”, , , , .

, PVRB , BLS threshold signatures, . , DFinity ( , , verifiable secret sharing), Keep.network ( random beacon yellowpaper , -, ).

PVRB

, , PVRB , . , , . PVRB , : CPU, memory, storage, I/O. PVRB — , , . , RP, , proof- , .

, PVRB:

• . PVRB unbiasable, . ,
• “last actor” . PVRB , , RP .
• . PVRB , , RP , ,
• . RP “ , ”. p2p , ,
• . PVRB on-chain , . -,
• liveness . PVRB , RP
• trusted setup . PVRB setup , . . - — ,
• . , , , ..

threshold BLS — , , , threshold. , , , , , , , realtime, , , threshold . , threshold-, , (slashing) , . , BLS , , EOS Ethereum — . — WebAssembly EVM, . (), . , 1024 2048 bit RSA, 4-8 , Bitcoin Ethereum.

— , . , Go geth, Rust Parity, C++ EOS. JavaScript , JavaScript , WebAssembly, -.

निष्कर्ष

, , , , , . , , setup- , whitepaper- , - “ , ”.

, PVRB Haya , threshold BLS signatures, PVRB , - . , : secret sharing random_seed, threshold BLS , . , , , , , , — , , . — , , governance .

PVRB, , , , , , , , , , - . , , .

, , , , :)