परिचय

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

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

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

PVRB लागू गर्ने दुई तरिकाहरू

PVRB लागू गर्नका लागि दुई विकल्पहरू थप विस्तारमा वर्णन गरौं - स्ट्यान्डअलोन संस्करण, जसले ब्लकचेनबाट स्वतन्त्र स्मार्ट अनुबंध प्रयोग गरेर काम गर्दछ, र प्रोटोकलमा निर्मित सहमति-एकीकृत संस्करण, जस अनुसार नेटवर्कले ब्लकचेनमा सहमति जनाउँछ। लेनदेन समावेश गर्न। सबै अवस्थामा, मेरो मतलब लोकप्रिय ब्लकचेन इन्जिनहरू: Ethereum, EOS, र तिनीहरूसँग मिल्दोजुल्दो सबै तिनीहरूले स्मार्ट अनुबंधहरू होस्ट गर्ने र प्रशोधन गर्ने तरिकामा।

स्ट्यान्डअलोन सम्झौता

यस संस्करणमा, PVRB एक स्मार्ट अनुबंध हो जसले अनियमित उत्पादकहरूको लेनदेन स्वीकार गर्दछ (यसपछि RP भनिन्छ), तिनीहरूलाई प्रशोधन गर्दछ, परिणामहरू संयोजन गर्दछ, र परिणाम स्वरूप, कुनै पनि प्रयोगकर्ताले यो सम्झौताबाट प्राप्त गर्न सक्ने निश्चित मूल्यमा पुग्छ। यो मान सिधै सम्झौतामा भण्डारण गर्न सकिँदैन, तर बरु केवल डेटा द्वारा प्रतिनिधित्व गरिन्छ जसबाट नतिजा अनियमित को एक र केवल एक मान निर्धारित रूपमा प्राप्त गर्न सकिन्छ। यस योजनामा, RPs ब्लकचेनका प्रयोगकर्ताहरू हुन्, र जो कोहीलाई पनि उत्पादन प्रक्रियामा भाग लिन अनुमति दिइन्छ।

स्ट्यान्डअलोन-अनुबंधको साथ विकल्प राम्रो छ:

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

यसमा पनि बेफाइदाहरू छन्:

• कम्प्युटिङ स्रोतहरू, लेनदेन भोल्युम र भण्डारणमा कडा सीमाहरू (अर्को शब्दमा, cpu/mem/io)
• सम्झौता भित्र सञ्चालनमा प्रतिबन्धहरू (सबै निर्देशनहरू उपलब्ध छैनन्, बाह्य पुस्तकालयहरू जडान गर्न गाह्रो छ)
• लेनदेन भन्दा छिटो सन्देश व्यवस्थित गर्न असक्षमता blockchain मा समावेश छन्

यो विकल्प PVRB लागू गर्नको लागि उपयुक्त छ जुन अवस्थित नेटवर्कमा चलाउन आवश्यक छ, जटिल क्रिप्टोग्राफी समावेश गर्दैन र ठूलो संख्यामा अन्तरक्रियाहरू आवश्यक पर्दैन।

सहमति-एकीकृत

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

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

फाइनालिटी प्रयोगकर्ताहरूका लागि अत्यन्तै महत्त्वपूर्ण छ, जसले यो बिना आफूलाई "दोहोरो खर्च" आक्रमणको शिकार भेट्टाउन सक्छ, जहाँ BP ले "होल्ड" ब्लक गर्छ, र नेटवर्कले राम्रो कारोबार "हेरे" पछि प्रकाशित गर्दछ। यदि त्यहाँ कुनै फाइनल छैन भने, तब प्रकाशित फोर्कले ब्लकलाई अर्कोसँग "राम्रो" लेनदेनको साथ बदल्छ, "खराब" फोर्कबाट, जसमा उही रकम आक्रमणकारीको ठेगानामा हस्तान्तरण गरिन्छ। PVRB को मामलामा, अन्तिमताका लागि आवश्यकताहरू अझ कडा हुन्छन्, किनकि PVRB का लागि फोर्कहरू निर्माण गर्नु भनेको सबैभन्दा लाभदायक प्रकाशित गर्नका लागि आक्रमणकारीलाई धेरै अनियमित विकल्पहरू तयार गर्ने अवसर हो, र सम्भावित आक्रमणको समय सीमित गर्नु भनेको हो। राम्रो समाधान।

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

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

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

यसमा पनि बेफाइदाहरू छन्:

• परीक्षण र विकासमा कठिनाइहरू - तपाईंले नेटवर्क त्रुटिहरू, हराएको नोडहरू, नेटवर्क हार्ड फोर्कहरू अनुकरण गर्नुपर्नेछ।
• कार्यान्वयन त्रुटिहरूलाई नेटवर्क हार्डफोर्क चाहिन्छ

PVRB लागू गर्ने दुवै विधिहरूमा जीवनको अधिकार छ, तर आधुनिक ब्लकचेनहरूमा स्मार्ट अनुबंधहरूमा कार्यान्वयन अझै पनि कम्प्युटिङ स्रोतहरूमा सीमित छ, र गम्भीर क्रिप्टोग्राफीमा कुनै पनि संक्रमण प्रायः असम्भव छ। र हामीलाई गम्भीर क्रिप्टोग्राफी चाहिन्छ, जस्तै तल देखाइनेछ। यद्यपि यो समस्या स्पष्ट रूपमा अस्थायी छ, धेरै समस्याहरू समाधान गर्न अनुबंधहरूमा गम्भीर क्रिप्टोग्राफी आवश्यक छ, र यो बिस्तारै देखा पर्दैछ (उदाहरणका लागि, Ethereum मा zkSNARKs को लागि प्रणाली अनुबंध)।

ब्लकचेन, जसले पारदर्शी र भरपर्दो प्रोटोकल सन्देश च्यानल प्रदान गर्दछ, त्यसो सित्तैमा गर्दैन। कुनै पनि विकेन्द्रीकृत प्रोटोकलले सिबिल आक्रमणको सम्भावनालाई ध्यानमा राख्नुपर्छ, कुनै पनि कार्य बहुविध खाताहरूको संगठित बलहरूद्वारा गर्न सकिन्छ, त्यसैले डिजाइन गर्दा, प्रोटोकलको स्वेच्छाचारी संख्या सिर्जना गर्न आक्रमणकारीहरूको क्षमतालाई ध्यानमा राख्न आवश्यक छ। सहभागीहरू मिलेर काम गरिरहेका छन्।

PVRB र ब्लक चर।

मैले झुटो बोलिन जब मैले भनें कि कसैले अझै राम्रो PVRB लागू गरेको छैन, धेरै जुवा अनुप्रयोगहरूद्वारा परीक्षण गरिएको, ब्लकचेनहरूमा। Ethereum र EOS मा यति धेरै जुवा अनुप्रयोगहरू कहाँबाट आउँछन्? यसले मलाई अचम्मित तुल्याउँछ जति यो तपाईलाई अचम्ममा पार्छ, तिनीहरूले पूर्णतया निश्चयवादी वातावरणमा यति धेरै "निरन्तर" अनियमितताहरू कहाँ पाए?

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

तर पोष्ट क्वान्टम सुरक्षित ह्यासहरू पनि पर्याप्त छैनन्, अफसोस। गोप्य PVRB को आवश्यकताहरु मा निहित छ, मलाई अघिल्लो लेख बाट सम्झना गरौं:

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

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

यस मामला मा बीपी सफ्टवेयर अधिक जटिल हुन्छ, तर धेरै छैन। साधारणतया, प्रमाणीकरण गर्दा र ब्लकमा लेनदेन समावेश गर्दा, त्यहाँ जीत हुनेछ कि भनेर हेर्नको लागि द्रुत जाँच छ, र, सम्भवतः, जित्ने उच्च सम्भावना प्राप्त गर्न एक लेनदेन प्यारामिटरहरूको चयन। एकै समयमा, यस्तो हेरफेरको लागि एक स्मार्ट बीपी समात्न लगभग असम्भव छ; प्रत्येक पटक तपाईले नयाँ ठेगानाहरू प्रयोग गर्न सक्नुहुन्छ र शंका उत्पन्न नगरी अलि-अलि जित्न सक्नुहुन्छ।

त्यसैले ब्लकबाट जानकारी प्रयोग गर्ने विधिहरू PVRB को विश्वव्यापी कार्यान्वयनको रूपमा उपयुक्त छैनन्। सीमित संस्करणमा, बाजी आकारमा प्रतिबन्धहरू, खेलाडीहरूको संख्यामा प्रतिबन्धहरू र/वा KYC दर्ता (एउटा खेलाडीलाई धेरै ठेगानाहरू प्रयोग गर्नबाट रोक्न), यी योजनाहरूले साना खेलहरूको लागि काम गर्न सक्छन्, तर अरू केही छैन।

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

ठीक छ, ह्यासिङको लागि धन्यवाद र कम्तिमा ब्लक ह्यास र अन्य चरहरूको सापेक्ष अप्रत्याशितता। यदि तपाईंले अगाडि-दौडिरहेका खानीहरूको समस्या समाधान गर्नुभयो भने, तपाईंले अझ उपयुक्त कुरा प्राप्त गर्नुपर्छ। यस योजनामा ​​प्रयोगकर्ताहरू थपौं - तिनीहरूलाई अनियमिततालाई पनि प्रभाव पार्न दिनुहोस्: कुनै पनि प्राविधिक समर्थन कर्मचारीले तपाईंलाई बताउनेछन् कि IT प्रणालीहरूमा सबैभन्दा अनियमित चीज प्रयोगकर्ताहरूको कार्य हो :)

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

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

PVRB र निर्धारणात्मक हस्ताक्षर।

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

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

PVRB र गोप्य साझेदारी योजनाहरू

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

यदि FSSS (फियाट-शमिर गोप्य साझेदारी) योजना यसको शुद्ध रूपमा लागू भएको थियो भने, यो एक अविनाशी PVRB हुनेछ। यसको सरल रूप मा, प्रोटोकल यस्तो देखिन सक्छ:

• प्रत्येक सहभागीले आफ्नै अनियमित उत्पन्न गर्दछ र यसबाट अन्य सहभागीहरूलाई साझाहरू वितरण गर्दछ।
• प्रत्येक सहभागीले अन्य सहभागीहरूको रहस्यको आफ्नो अंश प्रकट गर्दछ
• यदि एक सहभागीसँग M भन्दा बढी शेयरहरू छन् भने, यस सहभागीको संख्या गणना गर्न सकिन्छ, र यो अनौठो हुनेछ, खुलासा गरिएका सहभागीहरूको सेटको पर्वाह नगरी।
• प्रकट गरिएको अनियमितताको संयोजन चाहिने PVRB हो

यहाँ, एक व्यक्तिगत सहभागीले प्रोटोकलको नतिजाहरूलाई प्रभाव पार्दैन, बाहेक जहाँ अनियमितता प्रकटीकरण थ्रेसहोल्डको उपलब्धि उहाँमा मात्र निर्भर हुन्छ। तसर्थ, यो प्रोटोकल, यदि प्रोटोकलमा काम गर्ने RPs को आवश्यक अनुपात छ र उपलब्ध छ भने, कार्य गर्दछ, क्रिप्टोग्राफिक शक्तिका लागि आवश्यकताहरू लागू गर्दै, र "अन्तिम अभिनेता" समस्याको लागि प्रतिरोधी हुन्छ।

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

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

PVRB र थ्रेसहोल्ड हस्ताक्षरहरू

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

नियतात्मक हस्ताक्षर र थ्रेसहोल्ड योजनाहरूको संयोजनले PVRB लागू गर्नको लागि एक धेरै सुविधाजनक र आशाजनक योजना विकास गर्न सम्भव बनायो - यी निर्धारणात्मक थ्रेसहोल्ड हस्ताक्षरहरू हुन्। यहाँ लेख थ्रेसहोल्ड हस्ताक्षरहरूको विभिन्न प्रयोगहरूको बारेमा, र यहाँ अर्को राम्रो छ लामो पढाइ ड्यासबाट।

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

थ्रेसहोल्ड BLS हस्ताक्षर भएको योजनामा, प्रत्येक सहभागीले BLS (उदाहरणका लागि, अघिल्लो अनियमित) प्रयोग गरेर केही हस्ताक्षर गर्छ र साझा थ्रेसहोल्ड हस्ताक्षर वांछित अनियमित हुन्छ। BLS हस्ताक्षरहरूको क्रिप्टोग्राफिक गुणहरूले अनियमित गुणस्तरका लागि आवश्यकताहरू पूरा गर्दछ, थ्रेसहोल्ड भागले "अन्तिम-अभिनेता" विरुद्ध सुरक्षा गर्दछ, र कुञ्जीहरूको अद्वितीय संयोजनले धेरै धेरै रोचक एल्गोरिदमहरू लागू गर्न सम्भव बनाउँदछ जसले अनुमति दिन्छ, उदाहरणका लागि, प्रोटोकल सन्देशहरूको कुशल एकत्रीकरण। ।

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

PVRB को कार्यान्वयन

दुर्भाग्यवश, हामीले अझै पनि PVRB ब्लकचेनहरूमा लागू गरिएको रेडिमेड प्रोटोकल देख्दैनौं जसले यसको सुरक्षा र स्थिरता प्रमाणित गरेको छ। यद्यपि प्रोटोकलहरू आफैं तयार छन्, प्राविधिक रूपमा तिनीहरूलाई अवस्थित समाधानहरूमा लागू गर्न सजिलो छैन। केन्द्रीकृत प्रणालीहरूको लागि, PVRB को अर्थ छैन, र विकेन्द्रीकृतहरू कडा रूपमा सबै कम्प्युटिङ स्रोतहरूमा सीमित छन्: CPU, मेमोरी, भण्डारण, I/O। PVRB डिजाइन गर्नु भनेको कम्तिमा केही व्यवहार्य ब्लकचेनको लागि सबै आवश्यकताहरू पूरा गर्ने कुरा सिर्जना गर्न विभिन्न प्रोटोकलहरूको संयोजन हो। एउटा प्रोटोकलले धेरै कुशलतापूर्वक गणना गर्दछ, तर RPs बीच थप सन्देशहरू चाहिन्छ, जबकि अर्कोलाई धेरै थोरै सन्देशहरू चाहिन्छ, तर प्रमाण सिर्जना गर्न दशौं मिनेट, वा घण्टा पनि लाग्ने कार्य हुन सक्छ।

गुणस्तरीय PVRB छनोट गर्दा तपाईंले विचार गर्नुपर्ने कारकहरू म सूचीबद्ध गर्नेछु:

• क्रिप्टोग्राफिक शक्ति। तपाइँको PVRB कडाई निष्पक्ष हुनुपर्छ, एक बिट नियन्त्रण गर्ने क्षमता बिना। केही योजनाहरूमा यो मामला होइन, त्यसैले क्रिप्टोग्राफरलाई कल गर्नुहोस्
• "अन्तिम अभिनेता" समस्या। तपाईंको PVRB आक्रमणहरूको प्रतिरोधी हुनुपर्छ जहाँ एक वा बढी RPs नियन्त्रण गर्ने आक्रमणकारीले दुई परिणामहरू मध्ये एउटा छनौट गर्न सक्छ।
• प्रोटोकल तोडफोड समस्या। तपाईंको PVRB आक्रमणहरूको प्रतिरोधी हुनुपर्छ जहाँ एक वा बढी RPs नियन्त्रण गर्ने आक्रमणकारीले यादृच्छिक हुने वा नगर्ने निर्णय गर्छ र यसलाई प्रभाव पार्ने ग्यारेन्टी वा दिइएको सम्भाव्यतासँग।
• सन्देशहरूको संख्या समस्या। तपाईंका RPs ले ब्लकचेनमा न्यूनतम सन्देशहरू पठाउनुपर्छ र "मैले केही जानकारी पठाएको छु, म एक विशिष्ट सहभागीबाट प्रतिक्रियाको लागि पर्खिरहेको छु" जस्ता परिस्थितिहरू जस्ता सम्भव भएसम्म सिंक्रोनस कार्यहरूबाट बच्नुपर्छ। p2p नेटवर्कहरूमा, विशेष गरी भौगोलिक रूपमा फैलिएकाहरूमा, तपाईंले द्रुत प्रतिक्रियामा भरोसा गर्नु हुँदैन।
• कम्प्यूटेशनल जटिलता को समस्या। PVRB अन-चेनको कुनै पनि चरणको प्रमाणीकरण अत्यन्तै सजिलो हुनुपर्छ, किनकि यो नेटवर्कका सबै पूर्ण ग्राहकहरूद्वारा गरिन्छ। यदि कार्यान्वयन स्मार्ट अनुबंध प्रयोग गरी गरिन्छ भने, गति आवश्यकताहरू धेरै सख्त छन्
• पहुँच र जीवन्तताको समस्या। तपाईको PVRB ले नेटवर्कको एक भाग समयको लागि अनुपलब्ध हुने र RP को भागले काम गर्न छोड्ने अवस्थाहरूमा लचिलो हुन प्रयास गर्नुपर्छ।
• विश्वसनीय सेटअप र प्रारम्भिक कुञ्जी वितरणको समस्या। यदि तपाईंको PVRB ले प्रोटोकलको प्राथमिक सेटअप प्रयोग गर्छ भने, यो एउटा छुट्टै ठूलो र गम्भीर कथा हो। यहाँ एक उदाहरण। यदि सहभागीहरूले प्रोटोकल सुरु गर्नु अघि आफ्नो कुञ्जीहरू एकअर्कालाई बताउनुपर्छ भने, यो पनि समस्या हो यदि सहभागीहरूको संरचना परिवर्तन हुन्छ।
• विकास समस्याहरू। आवश्यक भाषाहरूमा पुस्तकालयहरूको उपलब्धता, तिनीहरूको सुरक्षा र प्रदर्शन, प्रचार, जटिल परीक्षणहरू, आदि।

उदाहरणका लागि, थ्रेसहोल्ड BLS हस्ताक्षरहरूमा महत्त्वपूर्ण समस्या छ - काम गर्न सुरु गर्नु अघि, सहभागीहरूले एक अर्कालाई कुञ्जीहरू वितरण गर्नुपर्छ, एक समूह व्यवस्थित गर्नुहोस् जुन सीमा भित्र काम गर्नेछ। यसको मतलब यो हो कि विकेन्द्रीकृत नेटवर्कमा कम्तिमा एक राउन्ड एक्सचेन्जको लागि पर्खनु पर्छ, र उत्पन्न गरिएको र्यान्ड, उदाहरणका लागि, खेलहरूमा आवश्यक छ, लगभग वास्तविक समयमा, यसको मतलब यो हो कि प्रोटोकलको तोडफोड यस चरणमा सम्भव छ। , र थ्रेसहोल्ड योजनाका फाइदाहरू हराए। यो समस्या पहिलेको भन्दा पहिले नै सरल छ, तर अझै पनि थ्रेसहोल्ड समूहहरूको गठनको लागि छुट्टै प्रक्रियाको विकास आवश्यक छ, जसलाई आर्थिक रूपमा सुरक्षित गर्नुपर्दछ, जम्मा र कोषको निकासी (स्ल्याशिंग) मार्फत सहभागीहरू जसले पालन नगर्ने। प्रोटोकल। साथै, सुरक्षाको स्वीकार्य स्तरको साथ BLS प्रमाणिकरण मात्र फिट हुँदैन, उदाहरणका लागि, मानक EOS वा Ethereum लेनदेनमा - त्यहाँ प्रमाणीकरणको लागि पर्याप्त समय छैन। सम्झौता कोड WebAssembly वा EVM हो, भर्चुअल मेसिनद्वारा कार्यान्वयन गरिन्छ। क्रिप्टोग्राफिक प्रकार्यहरू नेटिभ रूपमा लागू गरिएको छैन (अझैसम्म), र परम्परागत क्रिप्टोग्राफिक पुस्तकालयहरू भन्दा दशौं गुणा ढिलो काम गर्दछ। धेरै प्रोटोकलहरूले कुञ्जी भोल्युममा आधारित आवश्यकताहरू पूरा गर्दैनन्, उदाहरणका लागि RSA का लागि 1024 र 2048 बिटहरू, Bitcoin र Ethereum मा मानक लेनदेन हस्ताक्षर भन्दा 4-8 गुणा ठूलो।

विभिन्न प्रोग्रामिङ भाषाहरूमा कार्यान्वयनको उपस्थितिले पनि भूमिका खेल्छ - जसमध्ये केही छन्, विशेष गरी नयाँ प्रोटोकलहरूको लागि। सहमतिमा एकीकरणको विकल्पलाई प्लेटफर्मको भाषामा प्रोटोकल लेख्न आवश्यक छ, त्यसैले तपाईंले Go for गेथ, Rust for Parity मा, C++ मा EOS का लागि कोड खोज्नुपर्छ। सबैले जाभास्क्रिप्ट कोड खोज्नुपर्नेछ, र जाभास्क्रिप्ट र क्रिप्टोग्राफी विशेष गरी नजिकका साथीहरू नभएकोले, WebAssembly ले मद्दत गर्नेछ, जसले अब निश्चित रूपमा अर्को महत्त्वपूर्ण इन्टरनेट मानक भएको दाबी गर्दछ।

निष्कर्षमा

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

अलविदा, विकास भइरहेको ब्लकचेनमा हाम्रो PVRB को लागी Haya, हामीले थ्रेसहोल्ड BLS हस्ताक्षरहरू प्रयोग गरेर बस्यौं, हामी सहमति स्तरमा PVRB लागू गर्ने योजना बनाउँछौं, किनकि स्वीकार्य स्तरको सुरक्षाको साथ स्मार्ट अनुबंधहरूमा प्रमाणीकरण अझै सम्भव छैन। यो सम्भव छ कि हामीले एकैचोटि दुई योजनाहरू प्रयोग गर्छौं: पहिलो, महँगो गोप्य साझेदारी दीर्घकालीन random_seed सिर्जना गर्न, र त्यसपछि हामी यसलाई उच्च-फ्रिक्वेन्सी अनियमित जेनरेशनको लागि आधारको रूपमा प्रयोग गर्छौं नियतात्मक थ्रेसहोल्ड BLS हस्ताक्षरहरू प्रयोग गरेर, सायद हामी आफूलाई मात्र सीमित गर्नेछौं। योजनाहरु मध्ये एक। दुर्भाग्यवश, यो प्रोटोकल के हुनेछ भनेर पहिले नै भन्न असम्भव छ, एकमात्र राम्रो कुरा यो हो कि, विज्ञानमा जस्तै, ईन्जिनियरिङ् समस्याहरूमा, एक नकारात्मक परिणाम पनि हुन्छ, र समस्या समाधान गर्न प्रत्येक नयाँ प्रयास अर्को चरण हो। समस्यामा संलग्न सबैको अनुसन्धान। व्यापार आवश्यकताहरू पूरा गर्न, हामी एक विशेष व्यावहारिक समस्या समाधान गर्छौं - एन्ट्रोपीको भरपर्दो स्रोतको साथ गेमिङ अनुप्रयोगहरू उपलब्ध गराउने, त्यसैले हामीले ब्लकचेनमा पनि ध्यान दिनुपर्छ, विशेष गरी चेन फाइनल र नेटवर्क गभर्नेन्सका मुद्दाहरूमा।

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

त्यसोभए, जब तपाइँ विकेन्द्रीकृत अनियमित डिजाइन गर्ने प्रोग्रामरलाई भेट्नुहुन्छ, ध्यान दिनुहोस् र हेरचाह गर्नुहोस्, र आवश्यक भएमा मनोवैज्ञानिक मद्दत प्रदान गर्नुहोस् :)

स्रोत: www.habr.com