ऑफ-चेन डेटा के साथ ब्लॉकचेन को स्केल करना

जब एक हैश एक लाख शब्दों के लायक है

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

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

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

गोपनीयता और मापनीयता

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

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

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

यदि हम एक आसान मामला लेते हैं, जहां प्रत्येक आइटम 100 बाइट्स की एक छोटी सी JSON संरचना है, तो समग्र डेटा थ्रूपुट 100 किलोबाइट प्रति सेकंड होगा, जिसकी गणना 500 × (100 + 100) से की जाएगी। यह 1 मेगाबिट / सेकेंड के बैंडविड्थ के अंतर्गत आता है, जो किसी भी आधुनिक इंटरनेट कनेक्शन की क्षमता के भीतर आराम से है। डेटा प्रति वर्ष लगभग 3 टेराबाइट्स की दर से जमा होता है, जो कोई छोटी राशि नहीं है। लेकिन अब 12 टेराबाइट की हार्ड ड्राइव के साथ व्यापक रूप से उपलब्ध, तथा छापे नियंत्रक जो कई भौतिक ड्राइव को एक तार्किक में जोड़ते हैं, हम बहुत अधिक परेशानी या खर्च के बिना हर नोड पर 10-20 साल के डेटा को आसानी से स्टोर कर सकते हैं।

हालाँकि, चीजें बहुत अलग दिखती हैं यदि हम सूचनाओं के बड़े टुकड़ों को संग्रहीत कर रहे हैं, जैसे स्कैन किए गए दस्तावेज़। कागज की एक ए 4 शीट की उचित गुणवत्ता वाली जेपीईजी स्कैन 500 किलोग्राम आकार की हो सकती है। इसे प्रति सेकंड 500 लेनदेन से गुणा करें, और हम 250 के माध्यम से देख रहे हैं मेगाबाइट प्रति सेकंड। यह बैंडविड्थ के 2 गीगाबिट्स / सेकंड में अनुवाद करता है, जो अधिकांश स्थानीय नेटवर्क की तुलना में तेज है, इंटरनेट से अकेले संपर्क करते हैं। Amazon Web Services पर सबसे सस्ता प्रकाशित मूल्य $ ०.०५ प्रति गीगाबाइट, इसका मतलब है कि ४००,००० डॉलर प्रति नोड का वार्षिक बैंडविड्थ बिल। और प्रत्येक नोड सालाना उत्पन्न होने वाले नए डेटा के 0.05 टेराबाइट्स कहां संग्रहीत करेगा?

यह स्पष्ट है कि, ब्लॉकचैन अनुप्रयोगों के लिए डेटा के कई बड़े टुकड़ों को संग्रहीत करना, सीधे-ऑन-चेन स्टोरेज एक व्यावहारिक विकल्प नहीं है। चोट के लिए अपमान को जोड़ने के लिए, यदि गोपनीयता की समस्या को हल करने के लिए डेटा एन्क्रिप्ट किया गया है, तो नोड्स को एक बड़ी मात्रा में जानकारी संग्रहीत करने के लिए कहा जा रहा है जिसे वे पढ़ भी नहीं सकते हैं। यह नेटवर्क के प्रतिभागियों के लिए एक आकर्षक प्रस्ताव नहीं है।

हैशिंग समाधान

तो हम डेटा स्केलेबिलिटी की समस्या को कैसे हल करते हैं? हम उस डेटा को श्रृंखला पर प्रत्येक नोड तक दोहराए बिना, डेटा के ब्लॉकचैन के विकेन्द्रीकृत नोटरीकरण का लाभ कैसे उठा सकते हैं?

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

Hashes सभी ब्लॉकचेन में एक महत्वपूर्ण भूमिका निभाते हैं, विशिष्ट रूप से लेनदेन और ब्लॉकों की पहचान करके। वे बिटकॉइन जैसी प्रूफ-ऑफ-वर्क प्रणालियों में कम्प्यूटेशनल चुनौती से गुजरते हैं। कई अलग-अलग हैश फ़ंक्शन विकसित किए गए हैं, जिनमें BLAKE2, MD5 और RIPEME160 जैसे gobbledygook नाम हैं। लेकिन किसी भी हैश फ़ंक्शन पर भरोसा करने के लिए, इसे व्यापक शैक्षणिक समीक्षा और परीक्षण को सहन करना होगा। ये परीक्षण प्रयास के हमलों के रूप में आते हैं, जैसे कि "प्रीइमेज" (दिए गए हैश के साथ एक इनपुट खोजना), "दूसरा प्रिमिमेज" (दिए गए इनपुट के समान हैश के साथ दूसरा इनपुट खोजना) और "टक्कर" (कोई भी खोज करना) एक ही हैश के साथ दो अलग-अलग इनपुट)। इस गैंलेट को बचाना आसान है, जिसमें प्रसिद्ध हैसीम को साबित करने वाले टूटे हुए हैश कार्यों का एक लंबा और दुखद इतिहास है: "अपने स्वयं के क्रिप्टो रोल न करें।"

अपनी मूल समस्या पर वापस जाने के लिए, हम डेटा के बजाय लेनदेन के भीतर डेटा के बड़े टुकड़ों की हैश को एम्बेड करके ब्लॉकचेन में डेटा स्केलेबिलिटी को हल कर सकते हैं। प्रत्येक हैश अपने इनपुट डेटा के लिए "प्रतिबद्धता" के रूप में कार्य करता है, जिसमें डेटा स्वयं ब्लॉकचैन या "ऑफ-चेन" के बाहर संग्रहीत किया जाता है। उदाहरण के लिए, लोकप्रिय SHA256 हैश फ़ंक्शन का उपयोग करके, 500 किलोबाइट JPEG छवि को 32-बाइट संख्या, 15,000 × से अधिक की कमी के द्वारा दर्शाया जा सकता है। यहां तक ​​कि प्रति सेकंड 500 छवियों की दर से, यह हमें चेन पर ही संग्रहीत डेटा के संदर्भ में, आराम से संभव बैंडविड्थ और भंडारण आवश्यकताओं के क्षेत्र में वापस रखता है।

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

प्रसव का प्रश्न

अब तक सब ठीक है। मूल डेटा के बजाय एक ब्लॉकचेन में हैश को एम्बेड करके, हमारे पास स्केलेबिलिटी की समस्या का आसान समाधान है। बहरहाल, एक महत्वपूर्ण सवाल यह है:

हम उन नोड्स को मूल ऑफ-चेन सामग्री कैसे वितरित करते हैं, जिन्हें इसकी आवश्यकता होती है, यदि श्रृंखला के माध्यम से नहीं?

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

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

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

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

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

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

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

मल्टीचैन 2.0 में ऑफ-चेन डेटा

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

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

1. प्रकाशन मल्टीचैन नोड अपने स्थानीय भंडारण में नया डेटा लिखता है, आसान पाचन और वितरण के लिए बड़ी वस्तुओं को विखंडू में बदल देता है।
2. ऑफ-चेन स्ट्रीम आइटम प्रकाशित करने के लिए लेनदेन स्वचालित रूप से बनाया गया है, जिसमें बंक में चंक हैश (एस) और आकार (एस) हैं।
3. यह लेनदेन नेटवर्क पर हस्ताक्षरित और प्रसारित होता है, नोड्स के बीच प्रचार करता है और सामान्य तरीके से ब्लॉकचेन में प्रवेश करता है।
4. जब किसी स्ट्रीम में सब्सक्राइब किया गया नोड कुछ ऑफ-चेन डेटा का संदर्भ देखता है, तो यह उस डेटा के लिए chunk हैश को अपनी पुनर्प्राप्ति कतार में जोड़ता है। (जब एक पुरानी धारा की सदस्यता ली जाती है, तो नोड भी पुनर्प्राप्ति के लिए पहले से प्रकाशित ऑफ-चेन आइटमों को कतारबद्ध करता है।)
5. एक पृष्ठभूमि प्रक्रिया के रूप में, यदि नोड की पुनर्प्राप्ति कतार में विखंडन होते हैं, तो उन चंक्स को खोजने के लिए नेटवर्क पर प्रश्न भेजे जाते हैं, जैसा कि उनके हैश द्वारा पहचाना जाता है।
6. इन चुटकुले प्रश्नों को नेटवर्क में अन्य नोड्स के लिए एक सहकर्मी से सहकर्मी फैशन में प्रचारित किया जाता है (अभी के लिए दो हॉप तक - नीचे तकनीकी विवरण देखें)।
7. किसी भी नोड के पास एक चंक के लिए डेटा है जो प्रतिक्रिया दे सकता है, और यह प्रतिक्रिया सब्सक्राइबर को क्वेरी के समान पथ के साथ वापस भेज दी जाती है।
8. यदि कोई नोड chunk क्वेरी का उत्तर नहीं देता है, तो chunk को बाद में पुनः प्रयास करने के लिए कतार में वापस भेज दिया जाता है।
9. अन्यथा, ग्राहक चंक (हॉप्स और प्रतिक्रिया समय के आधार पर) के लिए सबसे होनहार स्रोत चुनता है, और इसे उस चंक के डेटा के लिए एक अनुरोध भेजता है, फिर से पिछली प्रतिक्रिया के रूप में उसी पीयर-टू-पीयर पथ के साथ।
10. स्रोत नोड अनुरोधित डेटा को फिर से उसी पथ का उपयोग करके वितरित करता है।
11. ग्राहक डेटा के आकार और मूल अनुरोध के खिलाफ हैश की पुष्टि करता है।
12. यदि सब कुछ बाहर की जाँच करता है, तो ग्राहक डेटा को अपने स्थानीय स्टोरेज में लिखता है, जो स्ट्रीम एपीआई के माध्यम से पुनर्प्राप्ति के लिए तुरंत उपलब्ध कराता है।
13. यदि अनुरोधित सामग्री नहीं आई, या वांछित हैश या आकार से मेल नहीं खाती है, तो एक अलग स्रोत से भविष्य की पुनर्प्राप्ति के लिए चंक को वापस कतार में लाया जाता है।

सबसे महत्वपूर्ण बात, यह सब बहुत जल्दी होता है। कम विलंबता वाले नेटवर्क में, ऑफ-चेन डेटा के छोटे टुकड़े ग्राहकों के पास लेनदेन के दूसरे भाग में पहुंचेंगे जो उन्हें संदर्भित करते हैं। और उच्च भार अनुप्रयोगों के लिए, हमारे परीक्षण से पता चलता है कि मल्टीचैन 2.0 अल्फा 3 1000 से अधिक ऑफ-चेन आइटम या 25 एमबी ऑफ-चेन डेटा प्रति सेकंड, एक मध्यम श्रेणी के सर्वर (कोर आई 7) पर एक सभ्य के साथ बनाए रख सकता है। इंटरनेट कनेक्शन। ऑन-चेन डेटा के लिए 1 एमबी की सीमा से परे, आकार में 64 जीबी तक ऑफ-चेन आइटम के साथ सब कुछ ठीक काम करता है। बेशक, हम इन नंबरों को और बेहतर बनाने की उम्मीद करते हैं क्योंकि हम अपने बीटा चरण के दौरान मल्टीचैन 2.0 के अनुकूलन में समय बिताते हैं।

धाराओं में ऑन-चेन डेटा के बजाय ऑफ-चेन का उपयोग करते समय, मल्टीचैन एप्लिकेशन डेवलपर्स को वास्तव में दो काम करने होते हैं:

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

बेशक, प्रत्येक नोड को प्रत्येक ऑफ-चेन आइटम को पुनर्प्राप्त करने से रोकने के लिए, आइटम को एक उचित तरीके से धाराओं में एक साथ समूहीकृत किया जाना चाहिए, प्रत्येक नोड के साथ ब्याज की उन धाराओं की सदस्यता होती है।

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

यदि आप ऑफ-चेन स्ट्रीम आइटम देना चाहते हैं, तो मल्टीचैन के नियमित पालन करें Getting Started ट्यूटोरियल, और सुनिश्चित करें कि धारा 5 को छोड़ें नहीं।

अब अगला क्या होगा?

ऑफ-चेन डेटा के लिए निर्बाध समर्थन के साथ, मल्टीचैन 2.0 ब्लॉकचेन एप्लिकेशन के लिए बड़े कदम की पेशकश करेगा, जो बड़े पैमाने पर डेटा टाइमस्टैम्पिंग और नोटरीकरण पर केंद्रित है। लंबी अवधि में, हम पहले से ही मल्टीप्लेयर के सामुदायिक और / या एंटरप्राइज़ संस्करणों के लिए इस सुविधा के भविष्य के संभावित संवर्द्धन के एक टन के बारे में सोच रहे हैं:

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

हम पसंद करेंगे आपकी प्रतिक्रिया सुनें ऊपर की सूची के साथ-साथ सामान्य रूप से ऑफ-चेन आइटम। मल्टीचैन 2.0 के साथ अभी भी आधिकारिक तौर पर अल्फा में है, इसके अंतिम रिलीज से पहले इस सुविधा को बढ़ाने के लिए बहुत समय है।

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

कृपया कोई टिप्पणी पोस्ट करें लिंक्डइन पर.

टेक्निकल डिटेल

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

• प्रति-स्ट्रीम नीतियां। जब एक मल्टीचैन स्ट्रीम बनाई जाती है, तो इसे केवल ऑन-चेन या ऑफ-चेन डेटा की अनुमति देने के लिए वैकल्पिक रूप से प्रतिबंधित किया जा सकता है। ऐसा करने के कई संभावित कारण हैं, बजाय प्रत्येक प्रकाशक को अपने लिए निर्णय लेने की अनुमति देना। उदाहरण के लिए, ऑन-चेन आइटम एक आयरनक्लेड की उपलब्धता की गारंटी देते हैं, जबकि पुरानी ऑफ-चेन आइटम अपरिवर्तनीय हो सकती हैं यदि उनके प्रकाशक और अन्य ग्राहक नेटवर्क बंद कर दें। दूसरी तरफ, ब्लॉकचेन को संशोधित किए बिना ऑन-चेन आइटम को "भुलाया" नहीं जा सकता है, जबकि ऑफ-चेन आइटम अधिक लचीले हैं। यह डेटा गोपनीयता नियमों के संदर्भ में महत्वपूर्ण हो सकता है, जैसे कि यूरोप के नए जीडीपीआर नियम।
• ऑन-चेन मेटाडेटा। ऑफ-चेन आइटम के लिए, ऑन-चेन लेनदेन में अभी भी आइटम के प्रकाशक (एस), कुंजी (एस), प्रारूप (जेएसएन, पाठ या बाइनरी) और कुल आकार शामिल हैं। यह सब बहुत कम जगह लेता है, और एप्लिकेशन डेवलपर्स को यह निर्धारित करने में मदद करता है कि किसी विशेष स्ट्रीम क्वेरी के लिए ऑफ-चेन आइटम की अनुपलब्धता चिंता का विषय है या नहीं।
• दो-हॉप की सीमा। जब सहकर्मी से सहकर्मी नेटवर्क में रंक प्रश्नों को रिले किया जाता है, तो रीचैबिलिटी और प्रदर्शन के बीच व्यापार बंद हो जाता है। हालांकि यह हर क्वेरी के लिए हर एक पथ के साथ प्रचारित होना अच्छा होगा, यह नेटवर्क को अनावश्यक "बकवास" से रोक सकता है। तो अब के लिए चंक क्वेरी दो हॉप्स तक सीमित हैं, जिसका अर्थ है कि एक नोड अपने साथियों के किसी भी साथी से ऑफ-चेन डेटा को पुनः प्राप्त कर सकता है। 1000 से कम नोड्स के छोटे नेटवर्क में, जो एंटरप्राइज़ ब्लॉकचेन को चिह्नित करते हैं, हमारा मानना ​​है कि यह ठीक काम करेगा, लेकिन अगर हम गलत हो जाते हैं तो हमारे लिए इस बाधा को समायोजित करना आसान है (या इसे एक पैरामीटर के रूप में पेश करना)।
• स्थानीय भंडार। प्रत्येक मल्टीचैनल नोड एक कुशल बाइनरी प्रारूप और LevelDB इंडेक्स का उपयोग करके अपने नियमित ब्लॉकचेन डायरेक्टरी की "विखंडू" निर्देशिका के भीतर ऑफ-चेन डेटा संग्रहीत करता है। सब्स्क्राइब्ड स्ट्रीम में से प्रत्येक में आइटम के लिए एक अलग उपनिर्देशिका का उपयोग किया जाता है, साथ ही नोड द्वारा प्रकाशित किया जाता है। इन उपनिर्देशिकाओं में से प्रत्येक के भीतर, डुप्लिकेट चंक्स (एक ही हैश के साथ) केवल एक बार संग्रहीत किए जाते हैं। जब कोई नोड स्ट्रीम से अनसब्सक्राइब करता है, तो यह चुन सकता है कि उस स्ट्रीम के लिए पुनर्प्राप्त ऑफ-चेन डेटा को शुद्ध करना है या नहीं।
• बाइनरी कैश। बाइनरी डेटा के बड़े टुकड़ों को प्रकाशित करते समय, चाहे ऑन-चेन या ऑफ-चेन, यह एप्लिकेशन डेवलपर्स के लिए एकल JSON-RPC अनुरोध में मल्टीचैन्स एपीआई को उस डेटा को भेजने के लिए व्यावहारिक नहीं हो सकता है। इसलिए मल्टीचैन 2.0 एक बाइनरी कैश को लागू करता है, जो डेटा के बड़े टुकड़ों को कई एपीआई कॉल के ऊपर बनाया जा सकता है, और फिर एक संक्षिप्त अंतिम चरण में प्रकाशित किया जाता है। बाइनरी कैश में प्रत्येक आइटम को ब्लॉकचैन निर्देशिका के "कैश" उपनिर्देशिका में एक साधारण फ़ाइल के रूप में संग्रहीत किया जाता है, जिससे गीगाबाइट डेटा को भी फ़ाइल सिस्टम के माध्यम से सीधे धक्का दिया जा सकता है।
• एपीआई की निगरानी। मल्टीचैन 2.0 अल्फा 3 ऑफ-चेन डेटा की अतुल्यकालिक पुनर्प्राप्ति की निगरानी के लिए दो नए एपीआई जोड़ता है। पहली API कतार की वर्तमान स्थिति का वर्णन करती है, जिसमें दर्शाया गया है कि कितने विखंडू (और कितना डेटा) प्रतीक्षा कर रहे हैं या उन्हें पुनः प्राप्त किया जा रहा है। दूसरी एपीआई विभिन्न प्रकार की विफलता की गणना सहित नोड शुरू होने के बाद से भेजे गए सभी प्रकार के प्रश्नों और अनुरोधों के लिए कुल आँकड़े प्रदान करती है।
• प्रकाशित होने पर भड़क जाते हैं। ऑफ-चेन आइटम प्रकाशित करते समय, मल्टीचैइन यह सुनिश्चित करता है कि डेटा की अपनी स्थानीय प्रतिलिपि पूरी तरह से (या "फ्लश") लेनदेन को संदर्भित करने से पहले भौतिक डिस्क ड्राइव पर लिखी जाती है जो डेटा नेटवर्क पर प्रसारित होती है। अन्यथा, यदि नोड लेनदेन को प्रसारित करने के तुरंत बाद बिजली खोने के लिए पर्याप्त नहीं था, तो ऑफ-चेन डेटा स्थायी रूप से खो सकता है। यह मल्टीचैनल के लिए कोई समस्या नहीं है, क्योंकि समय के साथ एक चंक की पुनर्प्राप्ति प्रयासों के बीच देरी स्वचालित रूप से बढ़ती है। लेकिन यह एप्लिकेशन स्तर पर समस्याएं पैदा कर सकता है, जहां हर कोई कुछ डेटा के अस्तित्व के बारे में जानता है, लेकिन कोई भी इसे खोजने में सक्षम नहीं है।
• प्रकाशन प्रदर्शन। इस तरह से डिस्क पर ऑफ-चेन डेटा फ्लश करके, मल्टीचैन एक प्रदर्शन जुर्माना लगा सकता है, क्योंकि भौतिक डिस्क धीमी हैं। उदाहरण के लिए, एक मिड-रेंज 7200 आरपीएम हार्ड ड्राइव केवल लगभग 100 यादृच्छिक डेटा प्रति सेकंड प्रदर्शन कर सकता है, इस दर को सीमित करता है जिस पर एक अलग नोड ऑफ-चेन आइटम प्रकाशित कर सकता है। इस समस्या के लिए तीन संभावित समाधान हैं। सबसे पहले और सबसे सरल रूप से, नोड्स एक नियमित हार्ड ड्राइव के बजाय एक ठोस राज्य डिवाइस (एसएसडी) ड्राइव का उपयोग कर सकते हैं, जो प्रति सेकंड यादृच्छिक लेखन संचालन के 10,000s का समर्थन करता है। दूसरा, कई ऑफ-चेन आइटम "craitawsendfrom" API का उपयोग करके एकल लेनदेन में प्रकाशित किए जा सकते हैं। इस मामले में, मल्टीचेन एकल डिस्क ऑपरेशन में लेनदेन द्वारा संदर्भित सभी ऑफ-चेन डेटा लिखता है। अंत में, मल्टीचैइन को उस लेन-देन को प्रसारित करने से पहले डिस्क से चेन-डेटा को फ्लश करने के लिए कॉन्फ़िगर नहीं किया जा सकता है जो इसे संदर्भित करता है। इस विकल्प का उपयोग सावधानी से करें।
• मूल मुद्रा एकीकरण। उपयोग के मामलों के लिए जिसकी आवश्यकता होती है, मल्टीचैइन ने हमेशा लेनदेन स्पैम को रोकने और / या ब्लॉक सत्यापनकर्ताओं ("खनिक") को प्रोत्साहित करने के लिए एक ब्लॉकचैन पर एक देशी मुद्रा का उपयोग करने का विकल्प पेश किया है। इन मामलों में, लेन-देन को न्यूनतम शुल्क देना चाहिए जो कि बाइट्स में उनके आकार के अनुपात में होता है, ताकि चेन पर रिले और पुष्टि की जा सके। एक लेनदेन में संदर्भित ऑफ-चेन डेटा के प्रति किलोबाइट के न्यूनतम अतिरिक्त शुल्क की आवश्यकता के द्वारा ऑफ-चेन स्पैम को रोकने के लिए इस तंत्र को बढ़ाया गया है।
• पुरालेख नोड्स। यदि कोई नोड हर स्ट्रीम की सदस्यता लेना चाहता है, और इसलिए प्रकाशित प्रत्येक ऑफ-चेन आइटम को पुनर्प्राप्त और संग्रहीत करता है, तो इसे "ऑटोसबस" रनटाइम पैरामीटर का उपयोग करके ऐसा करने के लिए कॉन्फ़िगर किया जा सकता है। ऐसा कोई भी नोड पूरे नेटवर्क के लिए एक बैकअप के रूप में कार्य करेगा, यह गारंटी देता है कि ऑफ-चेन आइटम खो या अनुपलब्ध नहीं होंगे, कोई फर्क नहीं पड़ता कि अन्य नोड गायब हो जाते हैं। एक तीसरे पक्ष की कंपनियों की कल्पना कर सकते हैं कि यह एक वाणिज्यिक सेवा के रूप में पेश करती है।

सभी प्रासंगिक एपीआई कॉल और मापदंडों का पूरा विवरण मिल सकता है मल्टीचैन 2.0 पूर्वावलोकन पृष्ठ.