साझाकरण की मूल बातें

आइए शार्डिंग के सबसे सरल तरीके से शुरुआत करें। इसके बजाय इस दृष्टिकोण में एक blockchain चलाने पर, हम एकाधिक चलाएंगे, और ऐसे प्रत्येक blockchain को कॉल करेंगे "शार्द"। प्रत्येक शार्ड के पास validators का अपना सेट होगा। यहां और नीचे हम उपयोग करते हैं लेनदेन को सत्यापित करने वाले प्रतिभागियों को संदर्भित करने के लिए एक सामान्य शब्द "validator"। ब्लॉक का उत्पादन करें, या तो खनन द्वारा, जैसे कि कार्य के प्रमाण में, या मतदान-आधारित के माध्यम से 1यह अनुभाग पहले https://near.ai/shard1. पर प्रकाशित हुआ था यदि आपने इसे पहले पढ़ा है, अगले भाग पर जाएँ.

तंत्र। अभी के लिए मान लेते हैं कि शार्क कभी भी एक-दूसरे से संवाद नहीं करते हैं अन्य. यह डिज़ाइन, हालांकि सरल है, शार्डिंग में कुछ प्रारंभिक प्रमुख चुनौतियों को रेखांकित करने के लिए पर्याप्त है। 1.1 सत्यापनकर्ता विभाजन और बीकन श्रृंखलाएँ कहें कि सिस्टम में 10 टुकड़े शामिल हैं। पहली चुनौती यह है कि प्रत्येक के साथ शार्ड का अपना validators है, प्रत्येक शार्ड अब 10 गुना कम सुरक्षित है पूरी शृंखला. इसलिए यदि X validators वाली एक गैर-शार्ड श्रृंखला हार्ड-फोर्क का निर्णय लेती है एक खंडित श्रृंखला में, और X validators को 10 खंडों में विभाजित करता है, प्रत्येक खंड अब केवल X/10 validators हैं, और एक शार्ड को भ्रष्ट करने के लिए केवल भ्रष्ट करने की आवश्यकता होती है validators की कुल संख्या का 5.1% (51% / 10) (चित्र 1 देखें), चित्र 1: validators को टुकड़ों में विभाजित करना जो हमें दूसरे बिंदु पर लाता है: प्रत्येक शार्ड के लिए validator कौन चुनता है? validators के 5.1% को नियंत्रित करना केवल हानिकारक है यदि वे सभी validators के 5.1% हों एक ही हिस्से में हैं. यदि validators यह नहीं चुन सकते कि उन्हें कौन सा शार्ड मान्य करना है में, validator के 5.1% को नियंत्रित करने वाले प्रतिभागी को सभी प्राप्त होने की अत्यधिक संभावना नहीं है उनके validators एक ही हिस्से में हैं, जिससे समझौता करने की उनकी क्षमता काफी कम हो गई है प्रणाली. आज लगभग सभी शार्डिंग डिज़ाइन यादृच्छिकता के किसी न किसी स्रोत पर निर्भर करते हैं शार्ड को validators असाइन करें। blockchain पर यादृच्छिकता अपने आप में एक बहुत ही चुनौतीपूर्ण विषय है और इस दस्तावेज़ के दायरे से बाहर है। अभी के लिए मान लेते हैं कि वहाँ है यादृच्छिकता के कुछ स्रोत जिनका हम उपयोग कर सकते हैं। हम validator के असाइनमेंट को कवर करेंगे अनुभाग 2.1 में अधिक विवरण। यादृच्छिकता और validator असाइनमेंट दोनों के लिए गणना की आवश्यकता होती है जो कि नहीं है किसी विशेष शार्ड के लिए विशिष्ट। उस गणना के लिए, व्यावहारिक रूप से सभी विद्यमान हैं डिज़ाइन में एक अलग blockchain होता है जिसे संचालन करने का काम सौंपा जाता है पूरे नेटवर्क के रखरखाव के लिए आवश्यक है। यादृच्छिक उत्पन्न करने के अलावासंख्याएँ और शार्डों को validators निर्दिष्ट करना, ये ऑपरेशन अक्सर भी होते हैं इसमें शार्ड से अपडेट प्राप्त करना और उनका स्नैपशॉट लेना, प्रोसेसिंग करना शामिल है प्रूफ़-ऑफ़-स्टेक सिस्टम में हिस्सेदारी और कटौती, और उस समय टुकड़ों को पुनर्संतुलित करना सुविधा समर्थित है. ऐसी श्रृंखला को Ethereum में बीकन श्रृंखला, एक रिले कहा जाता है पोल्काडॉट में श्रृंखला, और Cosmos में Cosmos हब। इस पूरे दस्तावेज़ में हम ऐसी श्रृंखला को बीकन श्रृंखला के रूप में संदर्भित करेंगे। बीकन श्रृंखला का अस्तित्व हमें अगले दिलचस्प विषय पर लाता है द्विघात विखंडन. 1.2 द्विघात विखंडन शेयरिंग को अक्सर ऐसे समाधान के रूप में विज्ञापित किया जाता है जो संख्या के साथ अनंत रूप से बढ़ता है नेटवर्क संचालन में भाग लेने वाले नोड्स की संख्या। जबकि सैद्धांतिक रूप से ऐसा करना संभव है ऐसा शार्डिंग समाधान डिज़ाइन करें, कोई भी समाधान जिसमें बीकन की अवधारणा हो श्रृंखला में अनंत मापनीयता नहीं है। इसका कारण समझने के लिए, बीकन पर ध्यान दें श्रृंखला को कुछ बहीखाता गणना करनी होती है, जैसे validators निर्दिष्ट करना शार्ड, या स्नैपशॉटिंग शार्ड चेन ब्लॉक, जो संख्या के समानुपाती होता है सिस्टम में टुकड़ों की. चूंकि बीकन श्रृंखला स्वयं एक blockchain है, साथ में इसे संचालित करने वाले नोड्स की कम्प्यूटेशनल क्षमताओं से बंधी गणना, टुकड़ों की संख्या स्वाभाविक रूप से सीमित है। हालाँकि, एक शार्ड नेटवर्क की संरचना एक गुणक प्रदान करती है इसके नोड्स में किसी भी सुधार पर प्रभाव। उस मामले पर विचार करें जिसमें एक मनमाना नेटवर्क में नोड्स की दक्षता में सुधार किया गया है जो अनुमति देगा वे तेजी से लेनदेन प्रसंस्करण समय. यदि नेटवर्क का संचालन करने वाले नोड्स, बीकन श्रृंखला में नोड्स सहित, चार गुना तेज़ हो जाएं, तो प्रत्येक टुकड़ा चार गुना अधिक प्रक्रिया करने में सक्षम हो जाएगा लेनदेन, और बीकन श्रृंखला 4 गुना अधिक शार्क बनाए रखने में सक्षम होगी। पूरे सिस्टम में थ्रूपुट 4 × 4 = 16 के कारक से बढ़ जाएगा - इस प्रकार इसका नाम क्वाड्रैटिक शार्डिंग पड़ा। कितने टुकड़े हैं इसका सटीक माप प्रदान करना कठिन है आज व्यवहार्य है, लेकिन निकट भविष्य में थ्रूपुट की संभावना नहीं है blockchain उपयोगकर्ताओं की ज़रूरतें द्विघात शार्डिंग की सीमाओं को पार कर जाएंगी। इतनी बड़ी मात्रा में शार्क को सुरक्षित रूप से संचालित करने के लिए नोड्स की सरासर संख्या आवश्यक है संभवतः सभी को संचालित करने वाले नोड्स की संख्या से अधिक परिमाण का आदेश है blockchains आज संयुक्त। 1.3 राज्य विभाजक अब तक हम यह अच्छी तरह से परिभाषित नहीं कर पाए हैं कि वास्तव में क्या है और क्या अलग नहीं है जब किसी नेटवर्क को शार्ड में विभाजित किया जाता है। विशेष रूप से, blockchain में नोड्स तीन महत्वपूर्ण कार्य करते हैं: न केवल वे 1) लेन-देन की प्रक्रिया करते हैं, वे इसके अलावा 2) मान्य लेनदेन और पूर्ण किए गए ब्लॉक को अन्य नोड्स पर रिले करें और 3) संपूर्ण नेटवर्क बही की स्थिति और इतिहास को संग्रहीत करें। इन तीनों में से प्रत्येक कार्य नेटवर्क को संचालित करने वाले नोड्स पर बढ़ती आवश्यकता को लागू करते हैं:1. लेनदेन को संसाधित करने की आवश्यकता के लिए अधिक गणना शक्ति की आवश्यकता होती है संसाधित किए जा रहे लेनदेन की बढ़ी हुई संख्या; 2. लेन-देन और ब्लॉक को रिले करने की आवश्यकता के लिए रिले किए जाने वाले लेन-देन की बढ़ी हुई संख्या के साथ अधिक नेटवर्क बैंडविड्थ की आवश्यकता होती है; 3. जैसे-जैसे राज्य बढ़ता है डेटा को संग्रहीत करने की आवश्यकता अधिक भंडारण की आवश्यकता होती है। महत्वपूर्ण बात यह है कि प्रसंस्करण शक्ति और नेटवर्क के विपरीत, लेनदेन दर (संसाधित लेनदेन की संख्या) होने पर भी भंडारण की आवश्यकता बढ़ती है प्रति सेकंड) स्थिर रहता है। उपरोक्त सूची से ऐसा लग सकता है कि भंडारण की आवश्यकता होगी सबसे अधिक दबाव वाला, क्योंकि यह एकमात्र ऐसा है जो समय के साथ बढ़ाया जा रहा है भले ही प्रति सेकंड लेनदेन की संख्या नहीं बदलती, लेकिन व्यवहार में आज सबसे बड़ी आवश्यकता गणना शक्ति की है। का सम्पूर्ण राज्य Ethereum इस लेखन के अनुसार 100GB है, जिसे अधिकांश नोड्स द्वारा आसानी से प्रबंधित किया जा सकता है। लेकिन लेन-देन की संख्या Ethereum लगभग 20 ऑर्डर संसाधित कर सकती है कई व्यावहारिक उपयोग के मामलों के लिए आवश्यकता से कम परिमाण। Zilliqa सबसे प्रसिद्ध परियोजना है जो प्रसंस्करण को खंडित करती है लेकिन भंडारण को नहीं। प्रोसेसिंग को साझा करना एक आसान समस्या है क्योंकि प्रत्येक नोड में संपूर्ण होता है राज्य, जिसका अर्थ है कि अनुबंध स्वतंत्र रूप से अन्य अनुबंधों को लागू कर सकते हैं और किसी भी डेटा को पढ़ सकते हैं blockchain से. सुनिश्चित अपडेट करने के लिए कुछ सावधानीपूर्वक इंजीनियरिंग की आवश्यकता है राज्य के समान भागों को अद्यतन करने वाले एकाधिक शार्डों से टकराव नहीं होता है। में इस संबंध में ज़िलिक्का अपेक्षाकृत सरल दृष्टिकोण अपना रहा है2। जबकि प्रसंस्करण को विभाजित किए बिना भंडारण को विभाजित करने का प्रस्ताव किया गया था, यह है अत्यंत असामान्य. इस प्रकार व्यवहार में भंडारण का विखंडन, या राज्य विखंडन, लगभग हमेशा प्रसंस्करण और नेटवर्क के विखंडन का तात्पर्य होता है। व्यावहारिक रूप से, स्टेट शेयरिंग के तहत प्रत्येक शार्ड में नोड्स अपना निर्माण कर रहे हैं स्वयं का blockchain जिसमें लेनदेन शामिल है जो केवल स्थानीय भाग को प्रभावित करता है वैश्विक स्थिति जो उस शार्ड को सौंपी गई है। इसलिए, validators में शार्ड को केवल वैश्विक स्थिति के अपने स्थानीय हिस्से को संग्रहीत करने और केवल निष्पादित करने की आवश्यकता है, और इस तरह केवल रिले, लेनदेन जो राज्य के उनके हिस्से को प्रभावित करते हैं। यह विभाजन रैखिक रूप से सभी गणना शक्ति, भंडारण और पर आवश्यकता को कम कर देता है नेटवर्क बैंडविड्थ, लेकिन नई समस्याएं पेश करता है, जैसे डेटा उपलब्धता और क्रॉस-शार्क लेनदेन, दोनों को हम नीचे कवर करेंगे। 1.4 क्रॉस-शार्ड लेनदेन हमने अब तक जिस शार्डिंग मॉडल का वर्णन किया है वह बहुत उपयोगी नहीं है, क्योंकि यदि व्यक्तिगत टुकड़े एक दूसरे के साथ संवाद नहीं कर सकते, वे एकाधिक से बेहतर नहीं हैं स्वतंत्र blockchains। आज भी, जब शार्डिंग उपलब्ध नहीं है, तो एक है विभिन्न blockchain के बीच अंतरसंचालनीयता की भारी मांग। आइए अभी केवल साधारण भुगतान लेनदेन पर विचार करें, जहां प्रत्येक भागीदार के पास बिल्कुल एक शार्ड पर खाता है। अगर कोई पैसे ट्रांसफर करना चाहता है 2उनके दृष्टिकोण का हमारा विश्लेषण यहां पाया जा सकता है: https://medium.com/nearprotocol/ 8f9efae0ce3bएक ही शार्ड के भीतर एक खाते से दूसरे खाते में लेनदेन की प्रक्रिया की जा सकती है उस टुकड़े में पूरी तरह से validators द्वारा। यदि, तथापि, ऐलिस जो शार्ड पर रहती है

1 बॉब को पैसे भेजना चाहता है जो शार्ड #2 पर रहता है, न ही validators

शार्ड #1 पर (वे बॉब के खाते को क्रेडिट नहीं कर पाएंगे) और न ही validators पर शार्ड #2 (वे ऐलिस के खाते से डेबिट नहीं कर पाएंगे) संपूर्ण प्रक्रिया कर सकता है लेनदेन. क्रॉस-शार्क लेनदेन के दृष्टिकोण के दो परिवार हैं: • सिंक्रोनस: जब भी किसी क्रॉस-शार्ड लेनदेन को निष्पादित करने की आवश्यकता होती है, एकाधिक शार्डों में ब्लॉक जिनमें राज्य संक्रमण से संबंधित होता है सभी लेन-देन एक ही समय में उत्पन्न होते हैं, और एकाधिक शार्ड के validator ऐसे लेन-देन को निष्पादित करने में सहयोग करते हैं।3 • एसिंक्रोनस: एक क्रॉस-शार्क लेनदेन जो कई शार्डों को प्रभावित करता है उन शार्डों में अतुल्यकालिक रूप से निष्पादित किया जाता है, "क्रेडिट" शार्ड निष्पादित होता है इसका आधा भाग एक बार पर्याप्त सबूत हो जाने पर कि "डेबिट" शार्ड ने अपना हिस्सा निष्पादित कर दिया है। इसके कारण यह दृष्टिकोण अधिक प्रचलित होता है सरलता और समन्वय में आसानी. यह प्रणाली आज Cosmos, Ethereum सेरेनिटी, नियर, कडेना और अन्य में प्रस्तावित है। इससे एक समस्या है दृष्टिकोण यह है कि यदि ब्लॉक स्वतंत्र रूप से उत्पादित किए जाते हैं, तो एक गैर-शून्य संभावना है कि कई ब्लॉकों में से एक अनाथ हो जाएगा, इस प्रकार लेन-देन केवल आंशिक रूप से लागू किया गया। चित्र 2 पर विचार करें जो दो को दर्शाता है दोनों टुकड़ों में एक कांटा और एक क्रॉस-शार्क लेनदेन का सामना करना पड़ा इसे क्रमशः ब्लॉक ए और एक्स में दर्ज किया गया था। यदि जंजीर ए-बी और V'-X'-Y'-Z' अंततः संगत शार्डों में विहित हो जाता है लेन-देन पूरी तरह से अंतिम रूप ले चुका है। यदि A'-B'-C'-D' और V-X विहित हो जाते हैं, तो लेन-देन पूरी तरह से छोड़ दिया जाता है, जो स्वीकार्य है। लेकिन अगर, के लिए उदाहरण के लिए, ए-बी और वी-एक्स विहित हो जाते हैं, फिर लेन-देन का एक हिस्सा अंतिम हो जाता है और एक छोड़ दिया जाता है, जिससे परमाणु विफलता पैदा होती है। हम दूसरे भाग में प्रस्तावित प्रोटोकॉल में इस समस्या को कैसे संबोधित किया जाता है, इस पर चर्चा की जाएगी, जब फोर्क-चॉइस नियमों और सर्वसम्मति में परिवर्तन को कवर किया जाएगा साझा प्रोटोकॉल के लिए प्रस्तावित एल्गोरिदम। ध्यान दें कि शृंखलाओं के बीच संचार शार्ड blockchains के बाहर उपयोगी है भी. श्रृंखलाओं के बीच अंतरसंचालनीयता एक जटिल समस्या है जो कई परियोजनाओं में होती है सुलझाने का प्रयास कर रहे हैं. शार्डेड blockchains में समस्या कुछ हद तक आसान है ब्लॉक संरचना और आम सहमति सभी शार्क में समान होती है, और एक बीकन श्रृंखला होती है जिसका उपयोग समन्वय के लिए किया जा सकता है। हालाँकि, एक खंडित blockchain में, सभी शार्ड श्रृंखलाएं समान हैं, जबकि वैश्विक blockchains पारिस्थितिकी तंत्र में हैं विभिन्न लक्ष्य उपयोग के मामलों, विकेंद्रीकरण के साथ बहुत सारे अलग-अलग blockchain हैं और गोपनीयता की गारंटी। एक ऐसी प्रणाली का निर्माण करना जिसमें श्रृंखलाओं के एक सेट में अलग-अलग गुण हों पर्याप्त रूप से समान सर्वसम्मति और ब्लॉक संरचना का उपयोग करें और एक सामान्य बीकन श्रृंखला होने से विषम blockchain के पारिस्थितिकी तंत्र को सक्षम किया जा सकता है जिसमें एक 3द सबसे विस्तृत प्रस्ताव ज्ञात को द लेखक का यह दस्तावेज़ है विलय ब्लॉक, वर्णित यहाँ: https://ethresear.ch/t/ मर्ज-ब्लॉक-और-सिंक्रोनस-क्रॉस-शार्ड-स्टेट-निष्पादन/1240चित्र 2: अतुल्यकालिक क्रॉस-शार्क लेनदेन कार्यशील अंतरसंचालनीयता उपप्रणाली। ऐसी प्रणाली में validator रोटेशन की सुविधा होने की संभावना नहीं है, इसलिए सुरक्षा सुनिश्चित करने के लिए कुछ अतिरिक्त उपाय किए जाने की आवश्यकता है। दोनों Cosmos और PolkaDot प्रभावी रूप से ऐसे सिस्टम4 हैं 1.5 दुर्भावनापूर्ण व्यवहार इस अनुभाग में हम समीक्षा करेंगे कि कौन सा प्रतिकूल व्यवहार validators को दुर्भावनापूर्ण बना सकता है यदि वे किसी टुकड़े को भ्रष्ट करने में सफल हो जाते हैं तो व्यायाम करें। हम क्लासिक दृष्टिकोणों की समीक्षा करेंगे खंड 2.1 में भ्रष्ट टुकड़ों से बचने के लिए। 1.5.1 दुर्भावनापूर्ण कांटे दुर्भावनापूर्ण validators का एक सेट एक कांटा बनाने का प्रयास कर सकता है। ध्यान दें कि ऐसा नहीं है इससे कोई फर्क नहीं पड़ता कि अंतर्निहित सर्वसम्मति BFT है या नहीं, पर्याप्त संख्या को दूषित कर रही है validators से हमेशा एक कांटा बनाना संभव हो जाएगा। पूरे नेटवर्क के 50% से अधिक के दूषित होने की तुलना में एकल शार्ड के 50% से अधिक के दूषित होने की काफी अधिक संभावना है (हम करेंगे) खंड 2.1 में इन संभावनाओं पर गहराई से विचार करें)। जैसा कि खंड 1.4 में चर्चा की गई है, क्रॉस-शार्ड लेन-देन में कई शार्डों में कुछ निश्चित स्थिति परिवर्तन शामिल होते हैं, और ऐसे टुकड़ों में संबंधित ब्लॉक जो ऐसे राज्य परिवर्तन लागू करते हैं, अवश्य होने चाहिए या तो सभी को अंतिम रूप दिया जाए (अर्थात चयनित श्रृंखलाओं में उनके अनुरूप दिखाई दें)। शार्ड), या सभी अनाथ हो जाएंगे (अर्थात चयनित श्रृंखलाओं में उनके संबंधित शार्ड पर दिखाई नहीं देंगे)। चूंकि आम तौर पर शार्क के दूषित होने की संभावना होती है 4Cosmos: https://forum.cosmos.network/ से जकी मनियन द्वारा लिखित इस आलेख को देखें t/polkadot-vs-cosmos/1397/2 और इस दस्तावेज़ के पहले लेखक का यह ट्वीट-स्टॉर्म: विस्तृत तुलना के लिए https://twitter.com/AlexSkidanov/status/1129511266660126720 दोनों में से

नगण्य नहीं है, हम यह नहीं मान सकते कि कांटे नहीं होंगे, भले ही शार्ड validators के बीच एक बीजान्टिन सहमति बन गई हो, या कई ब्लॉक बनाए गए हों राज्य परिवर्तन के साथ ब्लॉक के शीर्ष पर उत्पादन किया गया। इस समस्या के कई समाधान हैं, जिनमें से सबसे आम समाधान कभी-कभार होता है नवीनतम शार्ड चेन ब्लॉक को बीकन चेन से क्रॉस-लिंक करना। कांटा फिर शार्ड श्रृंखलाओं में चयन नियम को हमेशा उस श्रृंखला को प्राथमिकता देने के लिए बदल दिया जाता है क्रॉस-लिंक्ड, और केवल उन ब्लॉकों के लिए शार्ड-विशिष्ट कांटा-पसंद नियम लागू करें जो थे अंतिम क्रॉस-लिंक के बाद से प्रकाशित। 1.5.2 अमान्य ब्लॉकों को मंजूरी देना validators का एक सेट एक ब्लॉक बनाने का प्रयास कर सकता है जो राज्य संक्रमण फ़ंक्शन को गलत तरीके से लागू करता है। उदाहरण के लिए, उस राज्य से शुरू करना जिसमें ऐलिस इसमें 10 tokens हैं और बॉब के पास 0 tokens हैं, ब्लॉक में एक लेनदेन शामिल हो सकता है ऐलिस से बॉब तक 10 tokens भेजता है, लेकिन अंत में ऐलिस जैसी स्थिति आती है 0 tokens और बॉब के पास 1000 tokens हैं, जैसा कि चित्र 3 पर दिखाया गया है। चित्र 3: अमान्य ब्लॉक का एक उदाहरण क्लासिक नॉन-शार्डेड blockchain में ऐसा हमला संभव नहीं है, सब के बाद से नेटवर्क में भागीदार सभी ब्लॉकों को मान्य करता है, और ऐसे ब्लॉक को एक अमान्य राज्य परिवर्तन को अन्य दोनों ब्लॉक उत्पादकों द्वारा अस्वीकार कर दिया जाएगा, और नेटवर्क के प्रतिभागी जो ब्लॉक नहीं बनाते हैं। भले ही दुर्भावनापूर्ण हो validators ऐसे अमान्य ब्लॉक के ऊपर तेजी से ब्लॉक बनाना जारी रखते हैं ईमानदार validator सही श्रृंखला बनाते हैं, इस प्रकार श्रृंखला अमान्य के साथ होती है ब्लॉक लंबा है, इससे कोई फर्क नहीं पड़ता, क्योंकि प्रत्येक प्रतिभागी जो इसका उपयोग कर रहा है blockchain किसी भी उद्देश्य के लिए सभी ब्लॉकों को मान्य करता है, और सभी ब्लॉकों को हटा देता है अमान्य ब्लॉक के शीर्ष पर बनाया गया. चित्र 4 पर पाँच validator हैं, जिनमें से तीन दुर्भावनापूर्ण हैं। वे एक अमान्य ब्लॉक A' बनाया, और फिर शीर्ष पर नए ब्लॉक बनाना जारी रखा इसका. दो ईमानदार validator ने A' को अमान्य मानकर खारिज कर दिया और शीर्ष पर निर्माण कर रहे थेचित्र 4: गैर-साझा blockchain में एक अमान्य ब्लॉक बनाने का प्रयास उन्हें ज्ञात अंतिम वैध ब्लॉक का, एक कांटा बनाना। चूँकि कम हैं ईमानदार कांटे में validators, उनकी श्रृंखला छोटी होती है। हालाँकि, क्लासिक नॉनशार्डेड blockchain में प्रत्येक प्रतिभागी जो किसी भी उद्देश्य के लिए blockchain का उपयोग करता है वे प्राप्त सभी ब्लॉकों को मान्य करने और राज्य की पुनर्गणना करने के लिए जिम्मेदार हैं। इस प्रकार कोई भी व्यक्ति जिसकी blockchain में कोई रुचि है, वह यह देखेगा कि A' अमान्य है, और इस प्रकार बी', सी' और डी' को तुरंत हटा दें, जैसे कि लेना वर्तमान सबसे लंबी वैध श्रृंखला के रूप में श्रृंखला ए-बी। हालाँकि, शार्ड blockchain में, कोई भी भागीदार सभी शार्ड पर सभी लेनदेन को मान्य नहीं कर सकता है, इसलिए उन्हें इसकी पुष्टि करने का कोई तरीका होना चाहिए। blockchain के किसी भी टुकड़े के इतिहास में कोई भी अमान्य ब्लॉक शामिल नहीं किया गया था। ध्यान दें कि फोर्क्स के विपरीत, बीकन श्रृंखला से क्रॉस-लिंकिंग एक पर्याप्त समाधान नहीं है, क्योंकि बीकन श्रृंखला में सत्यापन करने की क्षमता नहीं है ब्लॉक. यह केवल यह सत्यापित कर सकता है कि उस शार्ड में पर्याप्त संख्या में validators हैं ब्लॉक पर हस्ताक्षर किए (और इस प्रकार इसकी सत्यता को प्रमाणित किया गया)। हम नीचे अनुभाग 2.2 में इस समस्या के समाधान पर चर्चा करेंगे।

राज्य की वैधता और डेटा उपलब्धता

शार्डेड blockchains में मुख्य विचार यह है कि अधिकांश प्रतिभागी संचालन कर रहे हैं या नेटवर्क का उपयोग सभी शार्क में ब्लॉक को मान्य नहीं कर सकता है। वैसे तो जब भी किसी भी प्रतिभागी को एक विशेष शार्ड के साथ बातचीत करने की आवश्यकता होती है जो वे आम तौर पर नहीं कर सकते शार्ड के संपूर्ण इतिहास को डाउनलोड करें और सत्यापित करें। हालाँकि, शार्डिंग का विभाजनकारी पहलू एक महत्वपूर्ण क्षमता पैदा करता है समस्या: किसी विशेष के संपूर्ण इतिहास को डाउनलोड और सत्यापित किए बिना भाग लेने वाले को निश्चित रूप से निश्चित नहीं किया जा सकता है कि वह राज्य जिसके साथ है 5यह अनुभाग, उपधारा 2.5.3 को छोड़कर, पहले https://near.ai/ पर प्रकाशित किया गया था शार्ड2. यदि आपने इसे पहले पढ़ा है, तो अगले भाग पर जाएँ।

वे परस्पर क्रिया ब्लॉकों के कुछ वैध अनुक्रम और उस अनुक्रम का परिणाम है ब्लॉकों की संख्या वास्तव में शार्ड में विहित श्रृंखला है। एक समस्या जो नहीं है गैर-शार्ड blockchain में मौजूद है। हम सबसे पहले इस समस्या का एक सरल समाधान प्रस्तुत करेंगे जो प्रस्तावित किया गया है कई प्रोटोकॉल द्वारा और फिर विश्लेषण करें कि यह समाधान कैसे टूट सकता है और क्या इसे संबोधित करने का प्रयास किया गया है। 2.1 सत्यापनकर्ता रोटेशन वैधता बताने का सरल समाधान चित्र 5 पर दिखाया गया है: मान लीजिए कि हम मान लेते हैं पूरे सिस्टम में हजारों validators के ऑर्डर हैं, जिनमें से 20% से अधिक दुर्भावनापूर्ण नहीं हैं या अन्यथा विफल हो जाएंगे (जैसे कि होने में विफल होना)। एक ब्लॉक बनाने के लिए ऑनलाइन)। फिर यदि हम 200 validators का नमूना लेते हैं, तो संभावना 1 से अधिक का व्यावहारिक उद्देश्यों के लिए 3 विफलता को शून्य माना जा सकता है। चित्र 5: नमूनाकरण validators 1 3 एक महत्वपूर्ण सीमा है. सर्वसम्मति प्रोटोकॉल का एक परिवार है, जिसे कहा जाता है BFT सर्वसम्मति प्रोटोकॉल, जो 1 से कम समय तक इसकी गारंटी देता है 3 का प्रतिभागी विफल हो जाते हैं, या तो दुर्घटनाग्रस्त होकर या किसी ऐसे तरीके से कार्य करके जो इसका उल्लंघन करता है प्रोटोकॉल, सहमति बनेगी। ईमानदार validator प्रतिशत की इस धारणा के साथ, यदि वर्तमान सेट validators एक शार्ड में हमें कुछ ब्लॉक प्रदान करता है, अनुभवहीन समाधान मानता है कि ब्लॉक वैध है और यह validators के आधार पर बनाया गया है जब उन्होंने सत्यापन करना शुरू किया तो उस शार्ड के लिए विहित श्रृंखला। validators validators के पिछले सेट से विहित श्रृंखला सीखी, जो उसी के द्वारा ब्लॉक के शीर्ष पर बनी धारणा जो विहित श्रृंखला का प्रमुख थी उससे पहले. प्रेरण द्वारा पूरी श्रृंखला वैध है, और चूंकि validators का कोई सेट नहीं है किसी भी बिंदु पर कांटे उत्पन्न होने पर, सरल समाधान यह भी निश्चित है कि वर्तमान शृंखला शार्ड में एकमात्र श्रृंखला है। विज़ुअलाइज़ेशन के लिए चित्र 6 देखें।

चित्र 6: प्रत्येक ब्लॉक के साथ एक blockchain को BFT सर्वसम्मति के माध्यम से अंतिम रूप दिया गया यह सरल समाधान काम नहीं करता है अगर हम मान लें कि validators हो सकते हैं अनुकूल रूप से भ्रष्ट हो गया, जो एक अनुचित धारणा नहीं है6। अनुकूल रूप से 1000 शार्ड वाले सिस्टम में एक शार्ड को भ्रष्ट करना काफी सस्ता है पूरे सिस्टम को भ्रष्ट करने की तुलना में. इसलिए, प्रोटोकॉल की सुरक्षा शार्ड की संख्या के साथ रैखिक रूप से कम हो जाती है। की वैधता में निश्चितता होना एक ब्लॉक, हमें पता होना चाहिए कि इतिहास में किसी भी बिंदु पर सिस्टम में कोई भी टुकड़ा नहीं है अधिकांश validator मिलीभगत कर रहे हैं; अनुकूली प्रतिकूलताओं के साथ, अब हमारे पास नहीं है ऐसी निश्चितता. जैसा कि हमने अनुभाग 1.5 में चर्चा की, validator मिलकर व्यायाम कर सकते हैं दो बुनियादी दुर्भावनापूर्ण व्यवहार: फ़ोर्क्स बनाना, और अमान्य ब्लॉक उत्पन्न करना। दुर्भावनापूर्ण कांटों को बीकन श्रृंखला से क्रॉस-लिंक किए गए ब्लॉकों द्वारा संबोधित किया जा सकता है जिन्हें आम तौर पर तुलना में काफी अधिक सुरक्षा के लिए डिज़ाइन किया गया है शार्ड जंजीरें. हालाँकि, अमान्य ब्लॉक बनाना काफी अधिक है चुनौतीपूर्ण समस्या से निपटना। 2.2 राज्य की वैधता चित्र 7 पर विचार करें जिस पर शार्ड #1 दूषित है और एक दुर्भावनापूर्ण अभिनेता निर्माण करता है अमान्य ब्लॉक बी। मान लीजिए कि इस ब्लॉक बी में 1000 tokens को पतले से ढाला गया था ऐलिस के खाते पर प्रसारित। दुर्भावनापूर्ण अभिनेता तब वैध ब्लॉक सी (ए में) उत्पन्न करता है समझ में आता है कि सी में लेन-देन सही ढंग से लागू किया गया है) बी के शीर्ष पर, अस्पष्ट अमान्य ब्लॉक बी, और शार्ड #2 के लिए एक क्रॉस-शार्क लेनदेन शुरू करता है उन 1000 token को बॉब के खाते में स्थानांतरित करता है। इस क्षण से अनुचित रूप से निर्मित tokens शार्ड #2 में अन्यथा पूरी तरह से वैध blockchain पर रहते हैं। इस समस्या से निपटने के कुछ सरल उपाय हैं: 6पढ़ें यह आलेख के लिए विवरण पर कैसे अनुकूली भ्रष्टाचार कर सकते हैं हो ले जाया गया बाहर: https://medium.com/nearprotocol/d859adb464c8. के लिए अधिक विवरण पर अनुकूली भ्रष्टाचार, पढ़ें https://github.com/ethereum/wiki/wiki/Sharding-FAQ# वे सुरक्षा मॉडल क्या हैं जिनके तहत हम काम कर रहे हैंचित्र 7: एक श्रृंखला से एक क्रॉस-शार्क लेनदेन जिसमें एक अमान्य ब्लॉक है 1. शार्ड #2 के validators के लिए उस ब्लॉक को मान्य करने के लिए जिससे लेनदेन हुआ है आरंभ किया गया है. ब्लॉक सी के बाद से, यह उपरोक्त उदाहरण में भी काम नहीं करेगा पूर्णतः वैध प्रतीत होता है। 2. शार्ड #2 में validators के लिए उस ब्लॉक से पहले कुछ बड़ी संख्या में ब्लॉक को मान्य करना जिससे लेनदेन शुरू किया गया है। स्वाभाविक रूप से, के लिए किसी भी संख्या में ब्लॉक एन को दुर्भावनापूर्ण प्राप्तकर्ता द्वारा मान्य किया गया है validators अमान्य ब्लॉक के शीर्ष पर N+1 वैध ब्लॉक बना सकते हैं उत्पादित. इस समस्या को हल करने का एक आशाजनक विचार टुकड़ों को एक में व्यवस्थित करना होगा अप्रत्यक्ष ग्राफ़ जिसमें प्रत्येक शार्ड कई अन्य शार्डों से जुड़ा होता है, और केवल पड़ोसी शार्डों के बीच क्रॉस-शार्क लेनदेन की अनुमति दें (उदाहरण के लिए यह कैसे होता है)। व्लाद ज़म्फिर की शार्डिंग अनिवार्य रूप से काम करती है7, और इसी तरह का विचार कडेना में उपयोग किया जाता है चेनवेब [1])। यदि शार्डों के बीच क्रॉस-शार्ड लेन-देन की आवश्यकता है पड़ोसी नहीं, इस तरह का लेन-देन कई शार्डों के माध्यम से किया जाता है। इस डिज़ाइन में प्रत्येक शार्ड में एक validator से उनके शार्ड के सभी ब्लॉकों को मान्य करने की उम्मीद की जाती है साथ ही सभी पड़ोसी खंडों के सभी ब्लॉक। नीचे एक चित्र पर विचार करें 10 टुकड़ों के साथ, प्रत्येक में चार पड़ोसी होते हैं, और दो टुकड़ों के लिए अधिक की आवश्यकता नहीं होती है चित्र 8 पर दिखाए गए क्रॉस-शार्ड संचार के लिए दो हॉप से अधिक। शार्ड #2 न केवल अपने स्वयं के blockchain को मान्य कर रहा है, बल्कि blockchain को भी मान्य कर रहा है शारद #1 सहित सभी पड़ोसी। तो अगर शार्ड #1 पर एक दुर्भावनापूर्ण अभिनेता एक अमान्य ब्लॉक बी बनाने का प्रयास कर रहा है, फिर उसके ऊपर ब्लॉक सी बनाएं और एक क्रॉस-शार्क लेनदेन शुरू करें, ऐसा क्रॉस-शार्क लेनदेन नहीं चलेगा चूँकि शार्द #2 ने शार्द #1 के पूरे इतिहास को मान्य कर दिया होगा इससे यह अवैध ब्लॉक बी की पहचान कर सकेगा। 7डिज़ाइन के बारे में यहां और पढ़ें: https://medium.com/nearprotocol/37e538177ed9

चित्र 8: चेनवेब जैसी प्रणाली में एक अमान्य क्रॉस-शार्क लेनदेन जो होगा पता लगाओ जबकि एक भी टुकड़े को भ्रष्ट करना अब एक व्यवहार्य हमला नहीं है, एक को भ्रष्ट करना कुछ टुकड़े एक समस्या बने हुए हैं। चित्र 9 पर एक प्रतिद्वंद्वी दोनों शारद को भ्रष्ट कर रहा है

1 और शार्ड #2 शार्ड #3 के लिए एक क्रॉस-शार्क लेनदेन को सफलतापूर्वक निष्पादित करते हैं

अमान्य ब्लॉक बी से धन के साथ: चित्र 9: चेनवेब जैसी प्रणाली में एक अमान्य क्रॉस-शार्क लेनदेन जो होगा पता नहीं चलता शार्ड #3 शार्ड #2 में सभी ब्लॉकों को मान्य करता है, लेकिन शार्ड #1 में नहीं, और दुर्भावनापूर्ण ब्लॉक का पता लगाने का कोई तरीका नहीं है। राज्य की वैधता को ठीक से हल करने की दो प्रमुख दिशाएँ हैं: मछुआरे

और गणना के क्रिप्टोग्राफ़िक प्रमाण। 2.3 मछुआरा पहले दृष्टिकोण के पीछे का विचार निम्नलिखित है: जब भी कोई ब्लॉक हेडर किसी भी उद्देश्य के लिए श्रृंखलाओं के बीच संचार किया जाता है (जैसे कि क्रॉस-लिंकिंग)। बीकन श्रृंखला, या एक क्रॉस-शार्ड लेनदेन), के दौरान एक समयावधि होती है जिसे कोई भी ईमानदार validator यह प्रमाण दे सकता है कि ब्लॉक अमान्य है। वहाँ विभिन्न निर्माण हैं जो बहुत ही संक्षिप्त प्रमाण देते हैं कि ब्लॉक हैं अमान्य है, इसलिए प्राप्त नोड्स के लिए संचार ओवरहेड बहुत छोटा है पूर्ण ब्लॉक प्राप्त करने की तुलना में। इस दृष्टिकोण के साथ जब तक कम से कम एक ईमानदार validator है शार्ड, सिस्टम सुरक्षित है. चित्र 10: मछुआरा आज प्रस्तावित प्रोटोकॉल में यह प्रमुख दृष्टिकोण है (यह दिखावा करने के अलावा कि समस्या मौजूद नहीं है)। हालाँकि, इस दृष्टिकोण में दो हैं प्रमुख नुकसान: 1. ईमानदार validator के लिए चुनौती की अवधि काफी लंबी होनी चाहिए यह पहचानने के लिए कि कोई ब्लॉक तैयार किया गया है, इसे डाउनलोड करें, इसे पूरी तरह से सत्यापित करें और तैयार करें यदि ब्लॉक अमान्य है तो चुनौती। ऐसे कालखंड का परिचय होगा क्रॉस-शार्क लेनदेन को काफी धीमा कर दें। 2. चुनौती प्रोटोकॉल का अस्तित्व हमलों का एक नया वेक्टर बनाता है जब दुर्भावनापूर्ण नोड्स अमान्य चुनौतियों के साथ स्पैम करते हैं। एक स्पष्ट समाधान इस समस्या के लिए चुनौती देने वालों से token की कुछ राशि जमा कराना है यदि चुनौती वैध है तो लौटा दी जाती है। यह केवल एक आंशिक समाधान है, जैसा कि यह है प्रतिद्वंद्वी के लिए सिस्टम को स्पैम करना (और जलाना) अभी भी फायदेमंद हो सकता है जमा) अमान्य चुनौतियों के साथ, उदाहरण के लिए वैध को रोकने के लिएएक ईमानदार validator से गुजरने की चुनौती। ये हमले हैं दुःखदायी आक्रमण कहा जाता है। बाद वाले बिंदु से बचने के तरीके के लिए अनुभाग 3.7.2 देखें। 2.4 ज्ञान के संक्षिप्त गैर-संवादात्मक तर्क मल्टीपल-शार्ड भ्रष्टाचार का दूसरा समाधान कुछ प्रकार के क्रिप्टोग्राफ़िक निर्माणों का उपयोग करना है जो किसी को यह साबित करने की अनुमति देता है कि एक निश्चित गणना (जैसे) लेनदेन के एक सेट से एक ब्लॉक की गणना के रूप में) सही ढंग से किया गया था। ऐसे निर्माण मौजूद हैं, उदा. zk-SNARKs, zk-STARKs और कुछ अन्य, और कुछ आज निजी भुगतान के लिए blockchain प्रोटोकॉल में सक्रिय रूप से उपयोग किए जाते हैं, सबसे विशेष रूप से ZCash। ऐसे आदिम लोगों के साथ प्राथमिक समस्या यह है कि वे गणना करने में बेहद धीमे हैं। जैसे कोडा प्रोटोकॉल, जो zk-SNARKs का उपयोग करता है विशेष रूप से यह साबित करने के लिए कि blockchain में सभी ब्लॉक वैध हैं, एक में कहा गया है साक्षात्कारों में कहा गया है कि प्रमाण बनाने में प्रति लेनदेन 30 सेकंड का समय लग सकता है (यह संख्या शायद अब तक छोटी है)। दिलचस्प बात यह है कि, किसी प्रमाण की गणना किसी विश्वसनीय पक्ष द्वारा करने की आवश्यकता नहीं है प्रमाण न केवल उस गणना की वैधता को प्रमाणित करता है जिसके लिए इसे बनाया गया है, बल्कि प्रमाण की वैधता ही. इस प्रकार, ऐसे प्रमाणों की गणना को विभाजित किया जा सकता है प्रतिभागियों के एक समूह के बीच, जिनकी अतिरेकता काफी कम होगी कुछ भरोसेमंद गणना करने के लिए आवश्यक है। यह प्रतिभागियों को भी अनुमति देता है जो बिना कम किए विशेष हार्डवेयर पर चलने के लिए zk-SNARKs की गणना करते हैं व्यवस्था का विकेंद्रीकरण. प्रदर्शन के अलावा, zk-SNARKs की चुनौतियाँ हैं: 1. कम शोध और कम समय में परीक्षण किए गए क्रिप्टोग्राफ़िक प्राइमेटिव्स पर निर्भरता; 2. "विषाक्त अपशिष्ट" - zk-SNARKs एक विश्वसनीय सेटअप पर निर्भर करते हैं जिसमें एक समूह होता है लोग कुछ गणना करते हैं और फिर मध्यवर्ती को हटा देते हैं उस गणना के मान. यदि प्रक्रिया में सभी भागीदार मिलीभगत करते हैं और मध्यवर्ती मूल्यों को बनाए रखें, नकली प्रमाण बनाए जा सकते हैं; 3. सिस्टम डिज़ाइन में अतिरिक्त जटिलता पेश की गई; 4. zk-SNARKs केवल संभावित गणनाओं के सबसेट के लिए काम करते हैं, इसलिए एक प्रोटोकॉल ट्यूरिंग-पूर्ण के साथ smart contract भाषा का उपयोग नहीं किया जा सकेगा श्रृंखला की वैधता साबित करने के लिए SNARKs। 2.5 डेटा उपलब्धता दूसरी समस्या जिस पर हम बात करेंगे वह है डेटा उपलब्धता। आम तौर पर नोड्स किसी विशेष blockchain को संचालित करने को दो समूहों में विभाजित किया गया है: पूर्ण नोड्स, वे जो प्रत्येक पूर्ण ब्लॉक को डाउनलोड करते हैं और प्रत्येक लेनदेन को मान्य करते हैं, और लाइट नोड्स, वे जो केवल ब्लॉक हेडर डाउनलोड करते हैं, और भागों के लिए मर्कल प्रूफ़ का उपयोग करते हैं जिस स्थिति और लेन-देन में उनकी रुचि है, जैसा कि चित्र 11 में दिखाया गया है।

चित्र 11: मर्कल वृक्ष अब यदि अधिकांश पूर्ण नोड्स मिलीभगत करते हैं, तो वे एक ब्लॉक, वैध या उत्पन्न कर सकते हैं अमान्य है, और इसके hash को लाइट नोड्स पर भेजें, लेकिन कभी भी पूरी सामग्री का खुलासा न करें ब्लॉक का. ऐसे कई तरीके हैं जिनसे वे इससे लाभ उठा सकते हैं। उदाहरण के लिए, चित्र 12 पर विचार करें: चित्र 12: डेटा उपलब्धता समस्या तीन ब्लॉक हैं: पिछला, ए, ईमानदार validators द्वारा निर्मित है; वर्तमान, बी, में validators की मिलीभगत है; और अगला, सी, भी निर्मित किया जाएगा ईमानदार validators द्वारा (blockchain को निचले दाएं कोने में दर्शाया गया है)। आप एक व्यापारी हैं. वर्तमान ब्लॉक (बी) के validators को ब्लॉक प्राप्त हुआ पिछले validators से A ने एक ब्लॉक की गणना की जिसमें आपको धन प्राप्त होता है,और आपको उस ब्लॉक का एक हेडर भेजा है जिसमें उस स्थिति का मर्कल प्रमाण शामिल है आपके पास पैसा है (या वैध लेनदेन का मर्कल प्रमाण जो पैसा भेजता है आपके लिए)। आश्वस्त रहें कि लेन-देन पूरा हो गया है, आप सेवा प्रदान करते हैं। हालाँकि, validators कभी भी ब्लॉक B की पूरी सामग्री वितरित नहीं करते हैं कोई भी. इस प्रकार, ब्लॉक सी के ईमानदार validators ब्लॉक को पुनः प्राप्त नहीं कर सकते हैं, और या तो सिस्टम को रोकने या ए के शीर्ष पर निर्माण करने के लिए मजबूर किया जाता है, जिससे आप वंचित रह जाते हैं पैसे का व्यापारी. जब हम उसी परिदृश्य को शार्डिंग पर लागू करते हैं, तो पूर्ण और की परिभाषाएँ लाइट नोड आम तौर पर प्रति शार्ड पर लागू होता है: प्रत्येक शार्ड डाउनलोड में validators उस शार्ड को ब्लॉक करें और उस शार्ड के प्रत्येक लेन-देन को मान्य करें, लेकिन अन्य सिस्टम में नोड्स, जिनमें स्नैपशॉट शार्ड चेन शामिल हैं बीकन श्रृंखला, केवल हेडर डाउनलोड करें। इस प्रकार शार्ड में validators हैं उस शार्ड के लिए प्रभावी रूप से पूर्ण नोड्स, जबकि सिस्टम में अन्य प्रतिभागी, बीकन श्रृंखला सहित, प्रकाश नोड्स के रूप में कार्य करें। काम करने के लिए जिस मछुआरे दृष्टिकोण की हमने ऊपर चर्चा की, उसके लिए ईमानदार validators बीकन श्रृंखला से क्रॉस-लिंक किए गए ब्लॉक डाउनलोड करने में सक्षम होने की आवश्यकता है। यदि दुर्भावनापूर्ण validators ने किसी अमान्य ब्लॉक के हेडर को क्रॉस-लिंक किया है (या इसका उपयोग किया है) एक क्रॉस-शार्ड लेन-देन शुरू करें), लेकिन कभी भी ब्लॉक वितरित नहीं किया, ईमानदार validator के पास चुनौती तैयार करने का कोई तरीका नहीं है। हम इस समस्या के समाधान के लिए तीन दृष्टिकोणों को शामिल करेंगे जो पूरक हैं एक दूसरे. 2.5.1 हिरासत के सबूत हल की जाने वाली सबसे तात्कालिक समस्या यह है कि क्या कोई ब्लॉक एक बार उपलब्ध है यह प्रकाशित हो चुकी है।. एक प्रस्तावित विचार तथाकथित नोटरी रखने का है जो घूमते रहें validators से अधिक बार शार्ड के बीच जिनका एकमात्र काम डाउनलोड करना है ब्लॉक करें और इस तथ्य की पुष्टि करें कि वे इसे डाउनलोड करने में सक्षम थे। वे हो सकते हैं अधिक बार घुमाया जाता है क्योंकि उन्हें पूरे राज्य को डाउनलोड करने की आवश्यकता नहीं होती है शार्ड का, validators के विपरीत, जिन्हें बार-बार घुमाया नहीं जा सकता है हर बार घूमने पर शार्ड की स्थिति को डाउनलोड करना होगा, जैसा कि चित्र में दिखाया गया है 13. इस अनुभवहीन दृष्टिकोण के साथ समस्या यह है कि इसे बाद में साबित करना असंभव है क्या नोटरी ब्लॉक डाउनलोड करने में सक्षम था या नहीं, इसलिए एक नोटरी वे हमेशा यह प्रमाणित करना चुन सकते हैं कि वे बिना ब्लॉक डाउनलोड करने में सक्षम थे यहां तक कि इसे पुनः प्राप्त करने का प्रयास भी किया जा रहा है। इसका एक समाधान नोटरी द्वारा प्रदान किया जाना है कुछ सबूत या tokens की कुछ राशि को दांव पर लगाने के लिए यह प्रमाणित करना कि ब्लॉक था डाउनलोड किया गया। ऐसे ही एक समाधान पर यहां चर्चा की गई है: https://ethresear.ch/t/ 1-बिट-एकत्रीकरण-अनुकूल-अभिरक्षा-बंधन/2236। 2.5.2 मिटाने के कोड जब किसी विशेष प्रकाश नोड को ब्लॉक का hash प्राप्त होता है, तो नोड की रोशनी बढ़ाने के लिए यह विश्वास करते हुए कि ब्लॉक उपलब्ध है, यह कुछ यादृच्छिक डाउनलोड करने का प्रयास कर सकता है ब्लॉक के टुकड़े. यह एक पूर्ण समाधान नहीं है, जब तक कि प्रकाश नोड्स न हों संपूर्ण ब्लॉक को सामूहिक रूप से डाउनलोड करें जिसे दुर्भावनापूर्ण ब्लॉक निर्माता चुन सकते हैं

चित्र 13: सत्यापनकर्ताओं को स्थिति डाउनलोड करने की आवश्यकता होती है और इस प्रकार उसे घुमाया नहीं जा सकता अक्सर ब्लॉक के उन हिस्सों को रोकना जो किसी भी लाइट नोड द्वारा डाउनलोड नहीं किए गए थे, इस प्रकार ब्लॉक अभी भी अनुपलब्ध है। इसे संभव बनाने के लिए एक समाधान इरेज़र कोड्स नामक निर्माण का उपयोग करना है पूर्ण ब्लॉक को पुनर्प्राप्त करने के लिए, भले ही ब्लॉक का केवल कुछ भाग उपलब्ध हो, जैसा कि दिखाया गया है चित्र 14 पर. चित्र 14: Merkle tree को इरेज़र कोडित डेटा के शीर्ष पर बनाया गया है Polkadot और Ethereum दोनों सेरेनिटी के पास इस विचार के आसपास डिज़ाइन हैं कि प्रकाश नोड्स के लिए उचित रूप से आश्वस्त होने का एक तरीका प्रदान करें कि ब्लॉक उपलब्ध हैं। Ethereum सेरेनिटी दृष्टिकोण का [2] में विस्तृत विवरण है।2.5.3 डेटा उपलब्धता के लिए Polkadot का दृष्टिकोण Polkadot में, अधिकांश शार्ड समाधानों की तरह, प्रत्येक शार्ड (जिसे पैराचेन कहा जाता है) अपने ब्लॉक को बीकन श्रृंखला (रिले चेन कहा जाता है) पर स्नैपशॉट करता है। मान लीजिए कि 2f + 1 हैं रिले श्रृंखला पर validators। पैराचेन ब्लॉकों के ब्लॉक उत्पादकों को बुलाया गया कोलेटर्स, एक बार जब पैराचेन ब्लॉक का उत्पादन हो जाता है तो ब्लॉक के इरेज़र कोडित संस्करण की गणना करें जिसमें 2f +1 भाग होते हैं जैसे कि कोई भी f भाग पर्याप्त हो ब्लॉक का पुनर्निर्माण करने के लिए. फिर वे प्रत्येक validator को एक भाग वितरित करते हैं रिले श्रृंखला. एक विशेष रिले श्रृंखला validator केवल रिले श्रृंखला पर हस्ताक्षर करेगी ब्लॉक करें यदि उनके पास स्नैपशॉट किए गए प्रत्येक पैराचेन ब्लॉक के लिए उनका हिस्सा है ऐसे रिले चेन ब्लॉक। इस प्रकार, यदि रिले चेन ब्लॉक में 2f + 1 से हस्ताक्षर हैं validators, और जब तक उनमें से f से अधिक ने प्रोटोकॉल का उल्लंघन नहीं किया, प्रत्येक पैराचेन ब्लॉक का पुनर्निर्माण validators से भागों को लाकर किया जा सकता है जो प्रोटोकॉल का पालन करें. चित्र 15 देखें। चित्र 15: Polkadot की डेटा उपलब्धता 2.5.4 दीर्घकालिक डेटा उपलब्धता ध्यान दें कि ऊपर चर्चा किए गए सभी दृष्टिकोण केवल इस तथ्य की पुष्टि करते हैं कि एक ब्लॉक बिल्कुल प्रकाशित हुआ था, और अब उपलब्ध है। ब्लॉक बाद में अनुपलब्ध हो सकते हैं विभिन्न कारणों से: नोड्स ऑफ़लाइन हो रहे हैं, नोड्स जानबूझकर ऐतिहासिक मिटा रहे हैं डेटा, और अन्य। उल्लेखनीय श्वेतपत्र जो इस मुद्दे को संबोधित करता है वह है पॉलीशर्ड [3], जो कई टुकड़ों में भी ब्लॉक उपलब्ध कराने के लिए इरेज़र कोड का उपयोग करता है शार्ड अपना डेटा पूरी तरह खो देते हैं। दुर्भाग्य से उनके विशिष्ट दृष्टिकोण की आवश्यकता है सभी शार्ड्स को अन्य सभी शार्ड्स से ब्लॉक डाउनलोड करने के लिए, जो निषेधात्मक है महँगा. दीर्घकालिक उपलब्धता किसी मुद्दे पर उतनी गंभीर नहीं है: चूँकि इसमें कोई भागीदार नहीं है सिस्टम में सभी श्रृंखलाओं को मान्य करने में सक्षम होने की उम्मीद है

शार्ड्स, शार्ड प्रोटोकॉल की सुरक्षा को इस प्रकार डिजाइन करने की आवश्यकता है इस तरह से कि सिस्टम सुरक्षित है, भले ही कुछ टुकड़ों में कुछ पुराने ब्लॉक बन जाएं पूर्णतः अनुपलब्ध.

Nightshade

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

3.2 आम सहमति आज blockchains में सर्वसम्मति के लिए दो प्रमुख दृष्टिकोण हैं सबसे लंबी (या सबसे भारी) श्रृंखला, जिसमें सबसे अधिक काम या हिस्सेदारी वाली श्रृंखला हो इसे बनाने के लिए उपयोग किया गया इसे विहित माना जाता है, और BFT, जिसमें प्रत्येक ब्लॉक के लिए कुछ validators का सेट BFT आम सहमति पर पहुंचता है। हाल ही में प्रस्तावित प्रोटोकॉल में उत्तरार्द्ध अधिक प्रभावी दृष्टिकोण है, चूँकि यह तत्काल अंतिमता प्रदान करता है, जबकि सबसे लंबी श्रृंखला में अधिक ब्लॉक की आवश्यकता होती है अंतिमता सुनिश्चित करने के लिए ब्लॉक के शीर्ष पर बनाया जाना है। अक्सर किसी सार्थक के लिए सुरक्षा के लिए पर्याप्त संख्या में ब्लॉक बनाने में समय लगता है घंटों का क्रम. प्रत्येक ब्लॉक पर BFT सर्वसम्मति का उपयोग करने के नुकसान भी हैं, जैसे: 1. BFT सर्वसम्मति में काफी मात्रा में संचार शामिल होता है। जबकि हाल की प्रगति से संख्या में रैखिक समय में आम सहमति तक पहुंचना संभव हो गया है प्रतिभागियों की (उदाहरण देखें [4]), यह अभी भी प्रति ब्लॉक ध्यान देने योग्य ओवरहेड है; 2. सभी नेटवर्क प्रतिभागियों के लिए BFT में भाग लेना संभव नहीं है प्रति ब्लॉक सर्वसम्मति, इस प्रकार आमतौर पर प्रतिभागियों का केवल यादृच्छिक रूप से नमूना किया गया उपसमूह ही सर्वसम्मति तक पहुंचता है। एक बेतरतीब ढंग से नमूना सेट, सिद्धांत रूप में, हो सकता है अनुकूल रूप से भ्रष्ट, और सिद्धांत में एक कांटा बनाया जा सकता है। सिस्टम या तो ऐसे आयोजन के लिए तैयार रहने के लिए मॉडल तैयार करने की आवश्यकता है, और इस प्रकार अभी भी BFT सर्वसम्मति के अलावा एक कांटा-चयन नियम रखें, या बंद करने के लिए डिज़ाइन किया जाए ऐसी घटना में नीचे. यह उल्लेखनीय है कि कुछ डिज़ाइन, जैसे कि Algorand [5], अनुकूली भ्रष्टाचार की संभावना को काफी कम कर देता है। 3. सबसे महत्वपूर्ण बात यह है कि सिस्टम रुक जाता है यदि 1 सभी प्रतिभागियों में से 3 या अधिक हैं ओफ़िन. इस प्रकार, कोई भी अस्थायी नेटवर्क गड़बड़ी या नेटवर्क विभाजन सिस्टम को पूरी तरह से ठप कर सकता है। आदर्श रूप से सिस्टम को जारी रखने में सक्षम होना चाहिए तब तक काम करें जब तक कम से कम आधे प्रतिभागी ऑनलाइन हों (सबसे भारी)। भले ही आधे से कम प्रतिभागी ऑनलाइन हों, फिर भी श्रृंखला-आधारित प्रोटोकॉल चालू रहते हैं, लेकिन इस संपत्ति की वांछनीयता अधिक विवादास्पद है समुदाय के भीतर)। एक हाइब्रिड मॉडल जिसमें सर्वसम्मति का उपयोग किया जाता है वह किसी प्रकार का सबसे भारी होता है श्रृंखला, लेकिन कुछ ब्लॉकों को समय-समय पर BFT अंतिम गैजेट का उपयोग करके अंतिम रूप दिया जाता है, जो दोनों मॉडलों के फायदे बनाए रखता है। ऐसे BFT अंतिम गैजेट हैं कैस्पर FFG [6] का उपयोग Ethereum 2.0 8, कैस्पर CBC में किया जाता है (देखें https://vitalik. ca/general/2018/12/05/cbc_casper.html) और दादाजी (https:// देखें) मीडियम.com/polkadot-network/d08a24a021b5) Polkadot में उपयोग किया जाता है। नाइटशेड सबसे भारी श्रृंखला सर्वसम्मति का उपयोग करता है। विशेष रूप से जब कोई ब्लॉक निर्माता एक ब्लॉक बनाता है (अनुभाग 3.3 देखें), वे उससे हस्ताक्षर एकत्र कर सकते हैं अन्य ब्लॉक निर्माता और validator पिछले ब्लॉक को प्रमाणित कर रहे हैं। अनुभाग देखें 3.8 विवरण के लिए कि इतनी बड़ी संख्या में हस्ताक्षर कैसे एकत्र किए जाते हैं। वजन 8कैस्पर के गहन अवलोकन के लिए जस्टिन ड्रेक के साथ व्हाइटबोर्ड सत्र भी देखें एफएफजी, और इसे GHOST की सबसे भारी श्रृंखला सर्वसम्मति के साथ कैसे एकीकृत किया गया है: https://www. youtube.com/watch?v=S262StTwkmoएक ब्लॉक का मतलब उन सभी हस्ताक्षरकर्ताओं की संचयी हिस्सेदारी है जिनके हस्ताक्षर हैं ब्लॉक में शामिल है. एक श्रृंखला का वजन ब्लॉक वजन का योग है। सबसे भारी श्रृंखला सर्वसम्मति के शीर्ष पर हम एक अंतिम गैजेट का उपयोग करते हैं जो उपयोग करता है ब्लॉकों को अंतिम रूप देने के लिए सत्यापन। सिस्टम की जटिलता को कम करने के लिए, हम एक अंतिम गैजेट का उपयोग करते हैं जो किसी भी तरह से कांटा चयन नियम को प्रभावित नहीं करता है, और इसके बजाय केवल अतिरिक्त स्लैशिंग शर्तों का परिचय देता है, जैसे कि एक बार ब्लॉक हो जाता है अंतिम गैजेट द्वारा अंतिम रूप दिया गया, एक कांटा तब तक असंभव है जब तक कि बहुत बड़ा प्रतिशत न हो कुल हिस्सेदारी में से कटौती की गई है। कैस्पर सीबीसी एक ऐसा अंतिम गैजेट है, और हम वर्तमान में कैस्पर सीबीसी को ध्यान में रखकर मॉडल तैयार किया जा रहा है। हम TxFlow नामक एक अलग BFT प्रोटोकॉल पर भी काम करते हैं। के समय इस दस्तावेज़ को लिखते समय यह स्पष्ट नहीं है कि कैस्पर के स्थान पर TxFlow का उपयोग किया जाएगा या नहीं सीबीसी. हालाँकि, हम ध्यान दें कि अंतिम गैजेट का चुनाव बाकी डिज़ाइन के लिए काफी हद तक ऑर्थोगोनल है। 3.3 ब्लॉक उत्पादन नाइटशेड में दो भूमिकाएँ हैं: ब्लॉक निर्माता और validators। किसी भी समय बिंदु पर सिस्टम में w ब्लॉक निर्माता, हमारे मॉडल में w = 100, और wv शामिल हैं validators, हमारे मॉडल में v = 100, wv = 10,000। सिस्टम प्रूफ़-ऑफ़-स्टेक है, इसका मतलब है कि ब्लॉक उत्पादकों और validators दोनों के पास कुछ संख्या में आंतरिक हैं मुद्रा (जिसे ''tokens'' कहा जाता है) इससे कहीं अधिक समय के लिए लॉक की गई है वे श्रृंखला के निर्माण और सत्यापन के अपने कर्तव्यों को निभाने में समय व्यतीत करते हैं। सभी प्रूफ़ ऑफ़ स्टेक सिस्टम की तरह, सभी डब्ल्यू ब्लॉक उत्पादकों और नहीं सभी wv validators अलग-अलग इकाइयाँ हैं, क्योंकि उन्हें लागू नहीं किया जा सकता है। प्रत्येक हालाँकि, w ब्लॉक उत्पादकों और wv validators में एक अलग है दांव. सिस्टम में हमारे मॉडल में n शार्ड, n = 1000 शामिल हैं। जैसा कि उल्लेख किया गया है सेक्शन 3.1, नाइटशेड में कोई शार्ड चेन नहीं हैं, इसके बजाय सभी ब्लॉक निर्माता और validator एक एकल blockchain का निर्माण कर रहे हैं, जिसे हम कहते हैं मुख्य श्रृंखला. मुख्य श्रृंखला की स्थिति को n शार्ड और प्रत्येक ब्लॉक में विभाजित किया गया है निर्माता और validator ने किसी भी समय स्थानीय स्तर पर केवल इसका एक उपसमूह डाउनलोड किया है वह स्थिति जो शार्ड के कुछ सबसेट से मेल खाती है, और केवल प्रक्रिया और राज्य के उन हिस्सों को प्रभावित करने वाले लेनदेन को मान्य करें। ब्लॉक निर्माता बनने के लिए, नेटवर्क का एक भागीदार कुछ बड़े को लॉक करता है tokens की राशि (एक हिस्सेदारी)। नेटवर्क का रखरखाव युगों में किया जाता है, जहाँ एक युग दिनों के क्रम में एक समयावधि है। प्रतिभागियों किसी विशेष युग की शुरुआत में सबसे बड़े दांव के साथ ब्लॉक होते हैं उस युग के निर्माता। प्रत्येक ब्लॉक निर्माता को एसडब्ल्यू शार्ड्स को सौंपा गया है, (मान लीजिए sw = 40, जो sww/n = 4 ब्लॉक उत्पादक प्रति शार्ड बना देगा)। ब्लॉक निर्माता उस शार्ड की स्थिति को डाउनलोड करता है जिसे युग से पहले सौंपा गया है शुरू होता है, और पूरे युग में उस हिस्से को प्रभावित करने वाले लेन-देन एकत्र करता है, और उन्हें राज्य पर लागू करता है। मुख्य श्रृंखला पर प्रत्येक ब्लॉक बी के लिए, और प्रत्येक शार्ड्स के लिए, इनमें से एक है एस को ब्लॉक उत्पादकों को सौंपा गया है जो बी से संबंधित भाग का उत्पादन करने के लिए जिम्मेदार है ठीकरे को. शार्ड एस से संबंधित बी के भाग को चंक कहा जाता है, और इसमें शामिल होता है शार्ड के लिए लेन-देन की सूची बी के साथ-साथ मर्कल में भी शामिल की जाएगीपरिणामी अवस्था की जड़. b में अंततः केवल एक बहुत छोटा हेडर होगा हिस्सा, अर्थात् सभी लागू लेन-देन का मर्कल रूट (अनुभाग देखें)। सटीक विवरण के लिए 3.7.1), और अंतिम स्थिति का मर्कल रूट। पूरे दस्तावेज़ में हम अक्सर ब्लॉक निर्माता का उल्लेख करते हैं जो एक विशेष टुकड़े के लिए एक विशेष समय पर एक टुकड़ा तैयार करने के लिए जिम्मेदार है एक खंड निर्माता के रूप में। चंक निर्माता हमेशा ब्लॉक उत्पादकों में से एक होता है। ब्लॉक निर्माता और चंक निर्माता प्रत्येक ब्लॉक को उसके अनुसार घुमाते हैं एक निश्चित कार्यक्रम के लिए. ब्लॉक उत्पादकों के पास ऑर्डर होता है और वे बार-बार उत्पादन करते हैं उस क्रम में ब्लॉक. जैसे यदि 100 ब्लॉक उत्पादक हैं, तो पहला ब्लॉक निर्माता ब्लॉक 1, 101, 201 आदि के उत्पादन के लिए जिम्मेदार है, दूसरा है 2, 102, 202 आदि के उत्पादन के लिए जिम्मेदार)। चूंकि खंड उत्पादन के विपरीत, खंड उत्पादन को रखरखाव की आवश्यकता होती है राज्य, और प्रत्येक शार्ड के लिए केवल sww/n ब्लॉक निर्माता ही राज्य को बनाए रखते हैं प्रति शार्ड, तदनुसार केवल वे sww/n ब्लॉक निर्माता बनाने के लिए घूमते हैं टुकड़े. जैसे उपरोक्त स्थिरांक के साथ चार ब्लॉक उत्पादकों को सौंपा गया प्रत्येक शार्ड, प्रत्येक ब्लॉक निर्माता प्रत्येक चार ब्लॉक में एक बार खंड बनाएगा। 3.4 डेटा उपलब्धता सुनिश्चित करना डेटा उपलब्धता सुनिश्चित करने के लिए हम Polkadot के समान दृष्टिकोण का उपयोग करते हैं खंड 2.5.3 में वर्णित है। एक बार जब कोई ब्लॉक निर्माता एक टुकड़ा तैयार कर लेता है, तो वे निर्माण करते हैं इष्टतम (w, ⌊w/6 + 1⌋) ब्लॉक कोड के साथ इसका एक इरेज़र कोडित संस्करण टुकड़ा. फिर वे इरेज़र कोडित खंड का एक टुकड़ा भेजते हैं (हम ऐसे टुकड़े कहते हैं प्रत्येक ब्लॉक निर्माता को टुकड़ों के हिस्से, या सिर्फ हिस्से)। हम एक मर्केल पेड़ की गणना करते हैं जिसमें पत्तियों और अन्य सभी भाग शामिल होते हैं प्रत्येक टुकड़े के शीर्षलेख में ऐसे पेड़ की मर्केल जड़ होती है। भागों को वनपार्ट संदेशों के माध्यम से validators पर भेजा जाता है। ऐसा प्रत्येक संदेश इसमें चंक हेडर, भाग का क्रमसूचक और भाग सामग्री शामिल है। द संदेश में उस ब्लॉक निर्माता के हस्ताक्षर भी शामिल हैं जिसने इसे बनाया है यह साबित करने के लिए कि भाग हेडर से मेल खाता है, खंड और मर्कल पथ और उचित ब्लॉक निर्माता द्वारा उत्पादित किया जाता है। एक बार जब ब्लॉक निर्माता को मुख्य श्रृंखला ब्लॉक प्राप्त हो जाता है, तो वे पहले जांच करते हैं कि क्या ब्लॉक में शामिल प्रत्येक भाग के लिए एक-भाग संदेश रखें। यदि नहीं, तो ब्लॉक तब तक संसाधित नहीं किया जाता जब तक कि गुम हुए वनपार्ट संदेशों को पुनः प्राप्त नहीं कर लिया जाता। एक बार जब सभी वनपार्ट संदेश प्राप्त हो जाते हैं, तो ब्लॉक निर्माता उन्हें प्राप्त कर लेता है साथियों से शेष भाग और उन हिस्सों का पुनर्निर्माण करता है जिनके लिए वे रखते हैं राज्य. यदि कम से कम एक के लिए ब्लॉक निर्माता मुख्य श्रृंखला ब्लॉक को संसाधित नहीं करता है ब्लॉक में शामिल चंक के पास संबंधित वनपार्ट संदेश नहीं है, या यदि कम से कम एक शार्ड के लिए वे उस स्थिति को बनाए रखते हैं तो वे ऐसा नहीं कर सकते पूरे हिस्से का पुनर्निर्माण करें. किसी विशेष खंड के उपलब्ध होने के लिए ब्लॉक का ⌊w/6⌋+1 होना पर्याप्त है निर्माताओं के पास अपने हिस्से हैं और वे उनकी सेवा करते हैं। इस प्रकार, जब तक की संख्या दुर्भावनापूर्ण अभिनेता ⌊w/3⌋ से अधिक नहीं है, ऐसी कोई श्रृंखला नहीं है जिसमें आधे से अधिक ब्लॉक हो इसे बनाने वाले निर्माताओं के पास अनुपलब्ध हिस्से हो सकते हैं।चित्र 17: प्रत्येक ब्लॉक में प्रति टुकड़े एक या शून्य टुकड़े होते हैं, और प्रत्येक टुकड़े में मिटाना कोडित है. इरेज़र कोडित खंड का प्रत्येक भाग एक निर्दिष्ट व्यक्ति को भेजा जाता है एक विशेष वनपार्ट संदेश के माध्यम से निर्माता को ब्लॉक करें 3.4.1 आलसी ब्लॉक उत्पादकों से निपटना यदि किसी ब्लॉक निर्माता के पास एक ब्लॉक है जिसके लिए एक भाग का संदेश गायब है, तो वे हो सकता है कि वह अभी भी इस पर हस्ताक्षर करना चुने, क्योंकि यदि ब्लॉक अंतत: श्रृंखला पर होता है ब्लॉक निर्माता के लिए अधिकतम इनाम होगा। ब्लॉक के लिए कोई जोखिम नहीं है निर्माता क्योंकि बाद में यह साबित करना असंभव है कि ब्लॉक निर्माता के पास नहीं था एक भाग का संदेश. इसका समाधान करने के लिए हम खंड बनाते समय प्रत्येक खंड को निर्माता बनाते हैं भविष्य में एन्कोड किए गए हिस्से के प्रत्येक भाग के लिए एक रंग (लाल या नीला) चुनें और स्टोर करें एन्कोड होने से पहले टुकड़े में निर्दिष्ट रंग का बिटमास्क। हर एक भाग संदेश में भाग को निर्दिष्ट रंग शामिल होता है, और जब रंग का उपयोग किया जाता है एन्कोडेड भागों के मर्कल रूट की गणना करना। यदि खंड निर्माता भटक जाता है प्रोटोकॉल से, इसे आसानी से सिद्ध किया जा सकता है, क्योंकि या तो मर्कल रूट नहीं होगा एक भाग वाले संदेशों के अनुरूप, या एक भाग वाले संदेशों में रंग मर्केल रूट के अनुरूप टुकड़े में मास्क से मेल नहीं खाएगा। जब कोई ब्लॉक निर्माता किसी ब्लॉक पर हस्ताक्षर करता है, तो उनमें सभी का एक बिटमास्क शामिल होता है ब्लॉक में शामिल टुकड़ों के लिए उन्हें लाल हिस्से मिले। एक प्रकाशन गलत बिटमास्क एक स्लैश करने योग्य व्यवहार है। यदि किसी ब्लॉक निर्माता को प्राप्त नहीं हुआ है एक भाग का संदेश, उनके पास संदेश का रंग जानने का कोई तरीका नहीं है, और इस प्रकार यदि वे बिना सोचे-समझे हस्ताक्षर करने का प्रयास करते हैं तो उन्हें नौकरी से निकाले जाने की 50% संभावना है ब्लॉक. 3.5 राज्य परिवर्तन आवेदन चंक उत्पादक केवल यह चुनते हैं कि किस लेन-देन को चंक में शामिल किया जाए जब वे एक खंड का उत्पादन करते हैं तो राज्य परिवर्तन लागू न करें। तदनुसार,

चंक हेडर में पहले की तरह मर्केलाइज़्ड अवस्था का मर्कल रूट शामिल है खंड में लेनदेन लागू होते हैं। लेन-देन केवल तभी लागू किया जाता है जब एक पूर्ण ब्लॉक जिसमें हिस्सा शामिल हो संसाधित किया जाता है. एक प्रतिभागी किसी ब्लॉक को केवल तभी संसाधित करता है यदि 1. पिछला ब्लॉक प्राप्त और संसाधित किया गया था; 2. प्रत्येक टुकड़े के लिए खिलाड़ी उस स्थिति को बरकरार नहीं रखता जो उसके पास है एक भाग का संदेश देखा; 3. प्रत्येक भाग के लिए प्रतिभागी राज्य को बनाए रखता है क्योंकि उसके पास है पूरा हिस्सा. एक बार ब्लॉक संसाधित होने के बाद, प्रत्येक शार्ड के लिए जिसके लिए प्रतिभागी राज्य को बनाए रखता है, वे लेनदेन लागू करते हैं और नए राज्य की गणना करते हैं लेन-देन लागू होने के बाद, जिसके बाद वे उत्पादन के लिए तैयार होते हैं अगले ब्लॉक के लिए टुकड़े, यदि उन्हें किसी भी टुकड़े को सौंपा गया है, क्योंकि उनके पास है नये मर्केलीकृत राज्य की मर्केल जड़। 3.6 क्रॉस-शार्क लेनदेन और रसीदें यदि किसी लेन-देन को एक से अधिक शार्ड को प्रभावित करने की आवश्यकता है, तो इसे लगातार करने की आवश्यकता है प्रत्येक शार्ड में अलग से निष्पादित। पूरा लेन-देन पहले शार्ड को भेजा जाता है प्रभावित, और एक बार लेन-देन ऐसे शार्ड के हिस्से में शामिल हो जाता है, और किसी ब्लॉक में टुकड़े को शामिल करने के बाद इसे लागू किया जाता है, यह एक तथाकथित रसीद उत्पन्न करता है लेन-देन, जिसे अगले शार्ड पर ले जाया जाता है जिसमें लेन-देन की आवश्यकता होती है निष्पादित किया जाए. यदि अधिक चरणों की आवश्यकता है, तो रसीद लेनदेन का निष्पादन एक नई रसीद लेनदेन इत्यादि उत्पन्न करता है। 3.6.1 रसीद लेनदेन जीवनकाल यह वांछनीय है कि रसीद लेनदेन उस ब्लॉक में लागू किया जाए जो उस ब्लॉक के तुरंत बाद होता है जिसमें यह उत्पन्न हुआ था। रसीद लेनदेन ही है पिछले ब्लॉक को प्राप्त करने और ब्लॉक उत्पादकों द्वारा लागू करने के बाद उत्पन्न हुआ जो मूल टुकड़े को बनाए रखता है, और उस समय तक इसे जानने की आवश्यकता होती है अगले ब्लॉक के लिए हिस्से का उत्पादन गंतव्य के ब्लॉक उत्पादकों द्वारा किया जाता है ठीकरा. इस प्रकार, रसीद को स्रोत शार्ड से सूचित किया जाना चाहिए उन दो घटनाओं के बीच कम समय सीमा में गंतव्य शार्ड। मान लीजिए A अंतिम उत्पादित ब्लॉक है जिसमें लेनदेन t शामिल है जो रसीद r उत्पन्न करता है। मान लीजिए कि B अगला निर्मित ब्लॉक है (अर्थात् एक ब्लॉक जिसमें A है इसका पिछला ब्लॉक) जिसमें हम r शामिल करना चाहते हैं। टी को शार्ड ए और आर में रहने दें शार्ड बी में रसीद का जीवनकाल, चित्र 18 में भी दर्शाया गया है, निम्नलिखित है: रसीदों का निर्माण एवं भंडारण। शार्ड के लिए चंक निर्माता सीपीए ए ब्लॉक ए प्राप्त करता है, लेनदेन टी लागू करता है और रसीद आर उत्पन्न करता है। सी.पी.ए फिर ऐसी सभी उत्पादित प्राप्तियों को अपने आंतरिक लगातार भंडारण अनुक्रमित में संग्रहीत करता है स्रोत शार्ड आईडी द्वारा।रसीदें बाँटना। एक बार सीपीए इस टुकड़े का उत्पादन करने के लिए तैयार हो जाए ब्लॉक बी के लिए शार्ड ए, वे शार्ड ए के लिए ब्लॉक ए से लेनदेन लागू करके उत्पन्न सभी रसीदें लाते हैं, और उन्हें शार्ड के लिए खंड में शामिल करते हैं ब्लॉक बी में ए। एक बार ऐसा खंड उत्पन्न हो जाने पर, सीपीए अपना इरेज़र कोड तैयार करता है संस्करण और सभी संबंधित वनपार्ट संदेश। सीपीए जानता है कि कौन से ब्लॉक निर्माता किस शार्क के लिए पूर्ण स्थिति बनाए रखते हैं। किसी विशेष ब्लॉक निर्माता के लिए बीपी सीपीए में ब्लॉक ए में लेनदेन लागू करने के परिणामस्वरूप प्राप्त रसीदें शामिल हैं शार्ड के लिए जिनके पास कोई ऐसा शार्ड है जिसकी बीपी अपने गंतव्य के रूप में परवाह करता है एक भाग के संदेश में जब उन्होंने ब्लॉक बी में शार्ड ए के लिए हिस्सा वितरित किया (चित्र 17 देखें, जो एक भाग के संदेश में शामिल रसीदें दिखाता है)। रसीदें प्राप्त करना। याद रखें कि प्रतिभागी (ब्लॉक निर्माता और validator दोनों) तब तक ब्लॉक संसाधित नहीं करते हैं जब तक उनके पास एक-भाग वाले संदेश न हों ब्लॉक में शामिल प्रत्येक टुकड़े के लिए। इस प्रकार, जब तक कोई विशेष प्रतिभागी ब्लॉक बी को लागू करता है, तब तक उनके पास सभी एक भाग के संदेश होते हैं जो इसके अनुरूप होते हैं बी में टुकड़े, और इस प्रकार उनके पास आने वाली सभी रसीदें हैं जिनमें टुकड़े हैं प्रतिभागी राज्य को अपने गंतव्य के रूप में बनाए रखता है। आवेदन करते समय किसी विशेष शार्ड के लिए राज्य संक्रमण, प्रतिभागी दोनों रसीदों को लागू करता है जिसे उन्होंने एक भाग के संदेशों के साथ-साथ सभी में भी एकत्र किया है लेन-देन खंड में ही शामिल है। चित्र 18: रसीद लेनदेन का जीवनकाल 3.6.2 बहुत सारी रसीदें संभालना यह संभव है कि प्राप्तियों की संख्या जो किसी विशेष हिस्से को लक्षित करती है विशेष ब्लॉक संसाधित होने के लिए बहुत बड़ा है। उदाहरण के लिए, चित्र 19 पर विचार करें जो प्रत्येक शार्ड में प्रत्येक लेन-देन एक रसीद उत्पन्न करता है जो शार्ड 1 को लक्षित करता है। अगले ब्लॉक तक प्राप्तियों की संख्या, जिसे शार्ड 1 को संसाधित करने की आवश्यकता है यह उस भार के बराबर है जिसे संभालते समय सभी टुकड़ों ने मिलकर संसाधित किया पिछला ब्लॉक.

चित्र 19: यदि सभी प्राप्तियां एक ही शार्ड को लक्षित करती हैं, तो शार्ड नहीं हो सकता है उन्हें संसाधित करने की क्षमता इसे संबोधित करने के लिए हम क्वार्कचेन 9 में उपयोग की गई तकनीक के समान तकनीक का उपयोग करते हैं। विशेष रूप से, प्रत्येक शार्ड के लिए अंतिम ब्लॉक बी और उसके भीतर अंतिम शार्ड होता है जिस ब्लॉक से रसीदें लागू की गई थीं, उसे दर्ज किया गया है। जब नया टुकड़ा है बनाई गई, रसीद को बी में शेष टुकड़ों से पहले क्रम में लागू किया जाता है, और फिर बी का अनुसरण करने वाले ब्लॉकों में, जब तक कि नया हिस्सा भर न जाए। सामान्य से कम संतुलित भार वाली परिस्थितियाँ आम तौर पर सभी प्राप्तियों में परिणामित होंगी लागू किया जा रहा है (और इस प्रकार अंतिम ब्लॉक का अंतिम टुकड़ा रिकॉर्ड किया जाएगा प्रत्येक टुकड़ा), लेकिन ऐसे समय में जब भार संतुलित नहीं होता है, और एक विशेष शार्ड को असंगत रूप से कई रसीदें प्राप्त होती हैं, यह तकनीक उन्हें इसकी अनुमति देती है शामिल लेनदेन की संख्या की सीमा का सम्मान करते हुए संसाधित किया जाना चाहिए। ध्यान दें कि यदि ऐसा असंतुलित भार लंबे समय तक बना रहे तो देरी हो सकती है आवेदन तक रसीद निर्माण अनिश्चित काल तक बढ़ता रह सकता है। एक इसे संबोधित करने का तरीका किसी भी लेनदेन को छोड़ना है जो एक लक्ष्यीकरण रसीद बनाता है शार्ड जिसमें प्रसंस्करण विलंब कुछ स्थिरांक (उदाहरण के लिए एक युग) से अधिक है। चित्र 20 पर विचार करें। ब्लॉक बी द्वारा शार्ड 4 सभी प्राप्तियों को संसाधित नहीं कर सकता है, इसलिए यह केवल ब्लॉक ए में शार्ड 3 तक प्राप्तियों की उत्पत्ति की प्रक्रिया करता है, और इसे रिकॉर्ड करता है. ब्लॉक सी में ब्लॉक बी में शार्ड 5 तक की रसीदें शामिल हैं, और फिर ब्लॉक डी द्वारा शार्ड पकड़ लिया जाता है, शेष सभी प्राप्तियों को संसाधित किया जाता है ब्लॉक बी और ब्लॉक सी से सभी प्राप्तियां। 3.7 टुकड़ों का सत्यापन किसी विशेष शार्ड के लिए उत्पादित खंड (या शार्ड चेन वाले मॉडल में किसी विशेष शार्ड श्रृंखला के लिए उत्पादित शार्ड ब्लॉक) को केवल इसके द्वारा मान्य किया जा सकता है 9क्वार्कचेन के साथ व्हाइटबोर्ड एपिसोड यहां देखें: https://www.youtube.com/watch? v=opEtG6NM4x4, जिसमें अन्य बातों के अलावा क्रॉस-शार्क लेनदेन के दृष्टिकोण पर चर्चा की गई है चीज़ेंचित्र 20: विलंबित रसीद प्रसंस्करण प्रतिभागी जो राज्य को बनाए रखते हैं। वे ब्लॉक निर्माता हो सकते हैं, validators, या केवल बाहरी गवाह जिन्होंने राज्य को डाउनलोड किया और शार्ड को मान्य किया जिसमें वे संपत्ति संग्रहित करते हैं। इस दस्तावेज़ में हम मानते हैं कि अधिकांश प्रतिभागी भंडारण नहीं कर सकते टुकड़ों के एक बड़े हिस्से के लिए राज्य। हालाँकि, यह उल्लेख करने योग्य है, कि ऐसे शार्प blockchains हैं जिन्हें इस धारणा के साथ डिज़ाइन किया गया है अधिकांश प्रतिभागियों के पास राज्य को संग्रहीत करने और अधिकांश को मान्य करने की क्षमता होती है टुकड़े, जैसे कि क्वार्कचेन। चूंकि प्रतिभागियों के केवल एक हिस्से के पास शार्ड को मान्य करने की स्थिति है खंडों में, केवल उन प्रतिभागियों को ही भ्रष्ट करना संभव है जिनके पास है राज्य, और एक अमान्य राज्य संक्रमण लागू करें। एकाधिक शार्डिंग डिज़ाइन प्रस्तावित किए गए थे जो हर कुछ में validators का नमूना लेते थे दिन, और एक दिन के भीतर शार्ड श्रृंखला में कोई भी ब्लॉक जिसमें 2/3 से अधिक हो ऐसे शार्ड को सौंपे गए validators के हस्ताक्षरों पर तुरंत विचार किया जाता है अंतिम. इस तरह के दृष्टिकोण के साथ एक अनुकूली प्रतिद्वंद्वी को केवल 2n/3+1 को भ्रष्ट करने की आवश्यकता होती है एक अमान्य स्थिति संक्रमण को लागू करने के लिए एक शार्ड श्रृंखला में validators का, जो, जबकि इसे हटाना कठिन हो सकता है, जनता के लिए सुरक्षा का स्तर पर्याप्त नहीं है blockchain. जैसा कि खंड 2.3 में चर्चा की गई है, सामान्य दृष्टिकोण किसी भी प्रतिभागी के लिए एक ब्लॉक बनाने के बाद समय की एक निश्चित विंडो की अनुमति देना है (चाहे वह राज्य हो) इसकी वैधता को चुनौती देने के लिए यह एक ब्लॉक निर्माता, एक validator, या एक बाहरी पर्यवेक्षक है)। ऐसे प्रतिभागियों को मछुआरे कहा जाता है। एक मछुआरे के लिए सक्षम होना किसी अमान्य ब्लॉक को चुनौती देते समय, यह सुनिश्चित किया जाना चाहिए कि ऐसा ब्लॉक उपलब्ध है उन्हें. नाइटशेड में डेटा उपलब्धता की चर्चा अनुभाग 3.4 में की गई है। नाइटशेड में एक बार एक ब्लॉक तैयार हो जाने के बाद, टुकड़ों को मान्य नहीं किया जाता था वास्तविक खंड निर्माता के अलावा कोई भी नहीं। विशेष रूप से, ब्लॉक निर्माता वह सुझाव दिया गया कि ब्लॉक में स्वाभाविक रूप से अधिकांश शार्क के लिए राज्य नहीं है, औरटुकड़ों को सत्यापित करने में सक्षम नहीं था। जब अगला ब्लॉक तैयार किया जाता है, तो इसमें कई ब्लॉक उत्पादकों और validators के सत्यापन (अनुभाग 3.2 देखें) शामिल होते हैं। लेकिन चूंकि अधिकांश ब्लॉक उत्पादक और validator राज्य का रखरखाव नहीं करते हैं अधिकांश शार्क के लिए, केवल एक अमान्य खंड वाला ब्लॉक आधे से अधिक सत्यापन एकत्र करेगा और सबसे भारी बना रहेगा श्रृंखला. इस मुद्दे को संबोधित करने के लिए, हम किसी भी प्रतिभागी को अनुमति देते हैं जो स्थिति को बनाए रखता है उसमें उत्पादित किसी भी अमान्य हिस्से के लिए ऑन-चेन चुनौती प्रस्तुत करने के लिए एक शार्ड ठीकरा. 3.7.1 राज्य वैधता चुनौती एक बार जब किसी प्रतिभागी को पता चलता है कि कोई विशेष हिस्सा अमान्य है, तो उन्हें इस बात का प्रमाण देना होगा कि वह हिस्सा अमान्य है। चूंकि अधिकांश नेटवर्क प्रतिभागी उस शार्ड की स्थिति को बनाए नहीं रखते हैं जिसमें अमान्य हिस्सा है उत्पादित, ब्लॉक की पुष्टि के लिए सबूत में पर्याप्त जानकारी होनी चाहिए राज्य के बिना अमान्य। हम एक एकल लेनदेन में राज्य की मात्रा (बाइट्स में) की एक सीमा Ls निर्धारित करते हैं संचयी रूप से पढ़ या लिख सकते हैं। कोई भी लेनदेन जो Ls से अधिक को छूता है राज्य को अमान्य माना जाता है. अनुभाग 3.5 से याद रखें कि खंड किसी विशेष ब्लॉक बी में केवल लागू किए जाने वाले लेनदेन शामिल हैं, लेकिन नहीं नया राज्य मूल. ब्लॉक बी में खंड में शामिल राज्य जड़ राज्य है ऐसे लेनदेन को लागू करने से पहले रूट करें, लेकिन लेनदेन को लागू करने के बाद ब्लॉक बी से पहले उसी टुकड़े में आखिरी टुकड़ा। एक दुर्भावनापूर्ण अभिनेता जो व्यक्ति अमान्य राज्य परिवर्तन लागू करना चाहता है, उसमें गलत राज्य रूट शामिल होगा ब्लॉक बी में यह उस राज्य रूट के अनुरूप नहीं है जो आवेदन करने से उत्पन्न होता है पिछले हिस्से में लेनदेन। हम उस जानकारी का विस्तार करते हैं जो एक चंक निर्माता चंक में शामिल करता है। सभी लेनदेन को लागू करने के बाद राज्य को शामिल करने के बजाय, इसके बजाय लेनदेन के प्रत्येक सन्निहित सेट को लागू करने के बाद एक राज्य रूट शामिल होता है राज्य के एलएस बाइट्स को सामूहिक रूप से पढ़ें और लिखें। इस जानकारी के साथ मछुआरे ने एक चुनौती पैदा की कि एक राज्य परिवर्तन गलत तरीके से लागू किया गया है इस तरह के पहले अमान्य राज्य रूट को खोजने के लिए पर्याप्त है, और इसमें केवल एलएस बाइट्स शामिल हैं वे राज्य जो अंतिम राज्य रूट (जो था) के बीच लेनदेन से प्रभावित होते हैं वैध) और वर्तमान स्थिति रूट मर्कल प्रमाणों के साथ। फिर कोई भी प्रतिभागी खंड में लेनदेन को सत्यापित कर सकता है और पुष्टि कर सकता है कि हिस्सा है अमान्य. इसी तरह, यदि खंड निर्माता ने पढ़ने वाले लेनदेन को शामिल करने का प्रयास किया और राज्य के एलएस बाइट्स से अधिक लिखें, चुनौती के लिए इसे शामिल करना पर्याप्त है पहले एलएस बाइट्स को यह मर्कल प्रूफ़ के साथ छूता है, जो पर्याप्त होगा लेन-देन लागू करें और पुष्टि करें कि एक क्षण ऐसा है जब ऐसा करने का प्रयास किया जाएगा Ls बाइट्स से परे सामग्री को पढ़ना या लिखना बनता है।

3.7.2 मछुआरे और तेज़ क्रॉस-शार्क लेनदेन जैसा कि खंड 2.3 में चर्चा की गई है, एक बार हम यह मान लेते हैं कि शार्ड विखंडन (या शार्ड शार्ड चेन वाले मॉडल में ब्लॉक) अमान्य हो सकते हैं और एक चुनौती पेश कर सकते हैं अवधि, यह अंतिमता और इस प्रकार क्रॉस-शार्क संचार को नकारात्मक रूप से प्रभावित करती है। में विशेष रूप से, किसी भी क्रॉस-शार्क लेनदेन का गंतव्य शार्ड निश्चित नहीं हो सकता है चुनौती की अवधि समाप्त होने तक मूल टुकड़ा या ब्लॉक अंतिम है (चित्र 21 देखें)। चित्र 21: रसीद लगाने से पहले चुनौती अवधि की प्रतीक्षा करें इसे इस तरह से संबोधित करने का तरीका जिससे क्रॉस-शार्क लेनदेन हो सके गंतव्य के लिए तात्कालिक यह है कि चुनौती की अवधि की प्रतीक्षा न की जाए स्रोत शार्ड लेनदेन प्रकाशित होने के बाद, रसीद लेनदेन लागू करें तुरंत, लेकिन फिर स्रोत के साथ गंतव्य शार्ड को वापस रोल करें शार्ड यदि बाद में मूल खंड या ब्लॉक अमान्य पाया गया (चित्र देखें)। 22). यह नाइटशेड डिज़ाइन पर बहुत स्वाभाविक रूप से लागू होता है जिसमें शार्ड शृंखलाएँ स्वतंत्र नहीं हैं, बल्कि सभी टुकड़े प्रकाशित होते हैं एक साथ एक ही मुख्य श्रृंखला ब्लॉक में। यदि कोई भी हिस्सा अमान्य पाया जाता है, तो उस खंड के साथ संपूर्ण ब्लॉक और उस पर बने सभी ब्लॉक अमान्य माने जाते हैं इसके शीर्ष पर. चित्र 23 देखें. उपरोक्त दोनों दृष्टिकोण चुनौती को मानकर परमाणुता प्रदान करते हैं अवधि काफी लंबी है. हम बाद वाले दृष्टिकोण का उपयोग करते हैं क्योंकि सामान्य परिस्थितियों में तेज़ क्रॉसहार्ड लेनदेन प्रदान करना असुविधा को कम करता है इनमें से किसी एक में अमान्य स्थिति परिवर्तन के कारण गंतव्य शार्ड वापस लुढ़क रहा है स्रोत के टुकड़े, जो एक अत्यंत दुर्लभ घटना है। 3.7.3 validators को छिपाया जा रहा है चुनौतियों का अस्तित्व पहले से ही इसकी संभावना को काफी कम कर देता है अनुकूली भ्रष्टाचार, एक अमान्य राज्य संक्रमण पोस्ट के साथ एक हिस्से को अंतिम रूप देने के लिएचित्र 22: तुरंत रसीदें लागू करना और गंतव्य स्थान वापस ले जाना यदि स्रोत श्रृंखला में कोई अमान्य ब्लॉक है तो श्रृंखला चित्र 23: नाइटशेड में मछुआरे की चुनौती चुनौती की अवधि अनुकूली प्रतिद्वंद्वी को सभी प्रतिभागियों को भ्रष्ट करने की आवश्यकता है जो सभी validator सहित शार्ड की स्थिति को बनाए रखता है। ऐसी घटना की संभावना का अनुमान लगाना बेहद जटिल है, क्योंकि नहीं शार्डेड blockchain ऐसे किसी भी हमले के प्रयास के लिए काफी समय से लाइव है। हमारा तर्क है कि संभावना, हालांकि बेहद कम है, फिर भी पर्याप्त है एक ऐसी प्रणाली के लिए बड़ी, जिससे बहु-मिलियन लेनदेन निष्पादित करने की उम्मीद की जाती है विश्वव्यापी वित्तीय संचालन चलाएँ। इस विश्वास के दो मुख्य कारण हैं: 1. प्रूफ़-ऑफ़-स्टेक श्रृंखलाओं और खनिकों के अधिकांश validators

प्रूफ़-ऑफ़-वर्क श्रृंखलाओं को मुख्य रूप से वित्तीय लाभ द्वारा प्रोत्साहित किया जाता है। यदि एक अनुकूली विरोधी उन्हें अपेक्षित रिटर्न से अधिक धन प्रदान करता है ईमानदारी से काम करने से, कई validators की अपेक्षा करना उचित है प्रस्ताव स्वीकार करेंगे. 2. कई संस्थाएं पेशेवर रूप से प्रूफ-ऑफ-स्टेक श्रृंखलाओं का सत्यापन करती हैं, और यह उम्मीद की जाती है कि किसी भी श्रृंखला में हिस्सेदारी का एक बड़ा प्रतिशत होगा ऐसी संस्थाओं से. ऐसी संस्थाओं की संख्या काफी कम है उनमें से अधिकांश को व्यक्तिगत रूप से जानने और एक अनुकूली प्रतिद्वंद्वी प्राप्त करने के लिए भ्रष्ट होने की उनकी प्रवृत्ति की अच्छी समझ। हम यह छिपाकर अनुकूली भ्रष्टाचार की संभावना को कम करने की दिशा में एक कदम आगे बढ़ाते हैं कि किस validator को किस शार्ड को सौंपा गया है। विचार यह है Algorand [5] validator को छुपाने के तरीके के समान ही। यह ध्यान रखना महत्वपूर्ण है कि भले ही validator छुपाए गए हों, जैसा कि Algorand में है या जैसा कि नीचे वर्णित है, अनुकूली भ्रष्टाचार अभी भी सैद्धांतिक रूप से संभव है। जबकि अनुकूली प्रतिद्वंद्वी उन प्रतिभागियों को नहीं जानता जो निर्माण या सत्यापन करेंगे एक ब्लॉक या एक हिस्सा, प्रतिभागियों को स्वयं पता होता है कि वे प्रदर्शन करेंगे ऐसा कार्य और इसका क्रिप्टोग्राफ़िक प्रमाण होना चाहिए। इस प्रकार, विरोधी ऐसा कर सकता है भ्रष्ट करने के अपने इरादे को प्रसारित करें, और जो भी भागीदार प्रदान करेगा उसे भुगतान करें ऐसा क्रिप्टोग्राफ़िक प्रमाण। हालाँकि, हम ध्यान दें कि चूंकि प्रतिद्वंद्वी ऐसा नहीं करता है वे validator को जानते हैं जो उस शार्ड को सौंपे गए हैं जिन्हें वे भ्रष्ट करना चाहते हैं किसी विशेष हिस्से को भ्रष्ट करने के अपने इरादे को प्रसारित करने के अलावा उनके पास कोई अन्य विकल्प नहीं है संपूर्ण समुदाय. उस समय यह किसी भी ईमानदार के लिए आर्थिक रूप से फायदेमंद है प्रतिभागी को एक पूर्ण नोड को स्पिन करना होगा जो उस शार्ड को मान्य करता है, क्योंकि वहां एक उच्च है उस शार्ड में एक अमान्य ब्लॉक दिखाई देने की संभावना, जो एक अवसर है एक चुनौती बनाएं और संबंधित इनाम इकट्ठा करें। किसी विशेष शार्ड को सौंपे गए validator को प्रकट न करने के लिए, हम ऐसा करते हैं निम्नलिखित (चित्र 24 देखें): असाइनमेंट प्राप्त करने के लिए वीआरएफ का उपयोग करना। प्रत्येक युग की शुरुआत में प्रत्येक validator validator को सौंपे गए शार्ड का बिटमास्क प्राप्त करने के लिए VRF का उपयोग करता है। प्रत्येक validator के बिटमास्क में Sw बिट्स होंगे (परिभाषा के लिए अनुभाग 3.3 देखें) स्व का) validator फिर संबंधित शार्क की स्थिति प्राप्त करता है, और प्राप्त प्रत्येक ब्लॉक के लिए युग के दौरान संबंधित हिस्सों को मान्य किया जाता है उन शार्डों के लिए जिन्हें validator सौंपा गया है। टुकड़ों के बजाय ब्लॉकों पर हस्ताक्षर करें। चूँकि टुकड़ों का असाइनमेंट छिपा हुआ है, validator टुकड़ों पर हस्ताक्षर नहीं कर सकता। इसके बजाय यह हमेशा संपूर्ण पर हस्ताक्षर करता है ब्लॉक, इस प्रकार यह प्रकट नहीं करता कि यह किन टुकड़ों को मान्य करता है। विशेष रूप से, जब validator एक ब्लॉक प्राप्त करता है और सभी खंडों को मान्य करता है, तो यह या तो एक संदेश बनाता है यह प्रमाणित करता है कि validator को सौंपे गए सभी टुकड़ों में सभी टुकड़े हैं वैध (किसी भी तरह से यह बताए बिना कि वे टुकड़े क्या हैं), या कोई संदेश यदि कोई हिस्सा अमान्य है तो इसमें अमान्य स्थिति परिवर्तन का प्रमाण शामिल है। देखें ऐसे संदेशों को कैसे एकत्रित किया जाता है, इसके विवरण के लिए अनुभाग 3.8, इसके लिए अनुभाग 3.7.4 संदेशों पर validators को गुल्लक से रोकने के तरीके के बारे में विवरण अन्य validators, और अनुभाग 3.7.5 विवरण के लिए कि कैसे पुरस्कार और दंड दिया जाए validators को एक सफल अमान्य राज्य परिवर्तन चुनौती वास्तव में होनी चाहिए।चित्र 24: नाइटशेड में validator को छुपाना 3.7.4 प्रतिबद्ध-प्रकटीकरण validators के साथ आम समस्याओं में से एक यह है कि validator राज्य को डाउनलोड करना और वास्तव में टुकड़ों और ब्लॉकों को मान्य करना छोड़ सकता है, और इसके बजाय नेटवर्क का निरीक्षण करें, देखें कि अन्य validators क्या सबमिट करते हैं और अपना दोहराएँ संदेश. ऐसी रणनीति का पालन करने वाला validator कोई अतिरिक्त प्रदान नहीं करता है नेटवर्क के लिए सुरक्षा, लेकिन पुरस्कार एकत्र करता है। इस समस्या का एक सामान्य समाधान प्रत्येक validator के लिए एक प्रमाण प्रदान करना है कि उन्होंने वास्तव में ब्लॉक को मान्य किया है, उदाहरण के लिए एक अद्वितीय ट्रेस प्रदान करके राज्य परिवर्तन को लागू करने के लिए, लेकिन ऐसे प्रमाण लागत में उल्लेखनीय वृद्धि करते हैं सत्यापन का. चित्र 25: प्रतिबद्ध-प्रकटीकरण

इसके बजाय हम validators को पहले सत्यापन परिणाम के लिए प्रतिबद्ध करते हैं (या तो वह संदेश जो खंडों की वैधता, या अमान्य के प्रमाण को प्रमाणित करता है राज्य परिवर्तन), एक निश्चित अवधि तक प्रतीक्षा करें, और उसके बाद ही वास्तविक सत्यापन परिणाम प्रकट करें, जैसा कि चित्र 25 पर दिखाया गया है। प्रतिबद्ध अवधि इसके साथ प्रतिच्छेद नहीं करती है प्रकटीकरण अवधि, और इस प्रकार एक आलसी validator ईमानदार validators की नकल नहीं कर सकता। इसके अलावा, यदि कोई बेईमान validator किसी ऐसे संदेश के प्रति प्रतिबद्ध है जो इसकी पुष्टि करता है निर्दिष्ट खंडों की वैधता, और एक बार ऐसा होने पर कम से कम एक खंड अमान्य था दिखाया गया है कि हिस्सा अमान्य है validator स्लैशिंग से बच नहीं सकता, क्योंकि, जैसा कि हम अनुभाग 3.7.5 में दिखाते हैं, ऐसी स्थिति में कटौती से बचने का एकमात्र तरीका है एक संदेश प्रस्तुत करना है जिसमें अमान्य स्थिति परिवर्तन का प्रमाण शामिल है प्रतिबद्धता से मेल खाता है. 3.7.5 चुनौतियों से निपटना जैसा कि ऊपर चर्चा की गई है, एक बार validator को एक अमान्य खंड वाला ब्लॉक प्राप्त होता है, फिर वे पहले अमान्य स्थिति परिवर्तन का प्रमाण तैयार करते हैं (धारा 3.7.1 देखें)। ऐसे प्रमाण के लिए प्रतिबद्ध रहें (3.7.4 देखें), और कुछ अवधि के बाद चुनौती का खुलासा करें। एक बार जब प्रकट चुनौती को किसी ब्लॉक में शामिल कर लिया जाता है, तो निम्नलिखित होता है: 1. सभी राज्य परिवर्तन जो युक्त ब्लॉक से हुए अमान्य खंड तब तक है जब तक कि वह ब्लॉक जिसमें प्रकट चुनौती शामिल है, प्राप्त न हो जाए निरस्त कर दिया गया। ब्लॉक से पहले की स्थिति जिसमें प्रकट चुनौती शामिल है इसे उस ब्लॉक से पहले की स्थिति के समान माना जाता है जिसमें शामिल है अमान्य हिस्सा. 2. एक निश्चित अवधि के भीतर प्रत्येक validator को अपना बिटमास्क प्रकट करना होगा वे जिन टुकड़ों को मान्य करते हैं। चूंकि बिटमास्क वीआरएफ के माध्यम से बनाया गया है, यदि उन्हें उस शार्ड को सौंपा गया था जिसमें अमान्य राज्य परिवर्तन था, वे इसका खुलासा करने से बच नहीं सकते. कोई भी validator जो बिटमास्क को प्रकट करने में विफल रहता है यह माना जाता है कि इसे शार्ड को सौंपा गया है। 3. प्रत्येक validator को ऐसी अवधि के बाद शार्ड को सौंपा जाना पाया जाता है, जिसमें शामिल ब्लॉक के लिए कुछ सत्यापन परिणाम दिए गए थे अमान्य खंड और इससे अमान्य राज्य परिवर्तन का प्रमाण प्रकट नहीं हुआ जो उनकी प्रतिबद्धता से मेल खाता है उसे काट दिया गया है। 4. प्रत्येक validator को एक नया शार्ड असाइनमेंट मिलता है, और एक नया युग निर्धारित किया जाता है सभी validators को डाउनलोड करने के लिए पर्याप्त समय के बाद प्रारंभ करें स्थिति, जैसा कि चित्र 26 में दिखाया गया है। ध्यान दें कि उस क्षण से validators उन टुकड़ों को प्रकट करते हैं जिन्हें उन्हें सौंपा गया है जब तक नया युग शुरू नहीं हो जाता तब तक सिस्टम की सुरक्षा कम हो जाती है शार्ड्स असाइनमेंट का पता चला है। नेटवर्क के प्रतिभागियों को इसे रखना होगा ऐसी अवधि के दौरान नेटवर्क का उपयोग करते समय ध्यान रखें। 3.8 हस्ताक्षर एकत्रीकरण सुरक्षित रूप से संचालित करने के लिए सैकड़ों टुकड़ों वाली प्रणाली के लिए, हम इसे चालू रखना चाहते हैं 10,000 या अधिक validators का ऑर्डर। जैसा कि खंड 3.7 में चर्चा की गई है, हम प्रत्येक चाहते हैंचित्र 26: चुनौती को संभालना validator औसतन एक निश्चित संदेश और एक हस्ताक्षर के लिए प्रतिबद्धता प्रकाशित करने के लिए प्रति ब्लॉक एक बार. भले ही प्रतिबद्ध संदेश समान हों, ऐसे को एकत्रित करना बीएलएस-हस्ताक्षर और इसे मान्य करना अत्यधिक महंगा होता। लेकिन स्वाभाविक रूप से प्रतिबद्ध और प्रकट संदेश validators में समान नहीं हैं, और इस प्रकार हमें ऐसे संदेशों और हस्ताक्षरों को एक में एकत्रित करने के लिए किसी तरीके की आवश्यकता है वह तरीका जो बाद में तेजी से सत्यापन की अनुमति देता है। हमारे द्वारा उपयोग किया जाने वाला विशिष्ट दृष्टिकोण निम्नलिखित है: सत्यापनकर्ता ब्लॉक उत्पादकों से जुड़ रहे हैं। ब्लॉक उत्पादक ज्ञात हैं युग शुरू होने से कुछ समय पहले, क्योंकि उन्हें डाउनलोड करने के लिए कुछ समय चाहिए युग शुरू होने से पहले की स्थिति, और validators के विपरीत ब्लॉक निर्माता हैं छुपाया नहीं गया. प्रत्येक ब्लॉक निर्माता के पास v validator स्लॉट हैं। सत्यापनकर्ता प्रस्तुत करते हैं ब्लॉक उत्पादकों को उनके वी में से एक के रूप में शामिल करने के लिए ऑफ-चेन प्रस्ताव validators. यदि कोई ब्लॉक निर्माता validator को शामिल करना चाहता है, तो वे एक सबमिट करते हैं लेन-देन जिसमें validator से प्रारंभिक ओff-श्रृंखला अनुरोध शामिल है, और ब्लॉक निर्माता का हस्ताक्षर जो validator को ब्लॉक निर्माता से जोड़ता है। ध्यान दें कि ब्लॉक उत्पादकों को सौंपा गया validator जरूरी नहीं है उन्हीं टुकड़ों को मान्य करें जिनके लिए ब्लॉक निर्माता टुकड़ों का उत्पादन करता है। यदि ए validator ने कई ब्लॉक उत्पादकों से जुड़ने के लिए आवेदन किया, केवल लेनदेन से पहला ब्लॉक निर्माता सफल होगा। ब्लॉक निर्माता कमिट एकत्र करते हैं। ब्लॉक निर्माता लगातार कमिट एकत्र करता है और validators से संदेश प्रकट करता है। एक बार जब ऐसे संदेशों की एक निश्चित संख्या जमा हो जाती है, तो ब्लॉक निर्माता एक मर्कल की गणना करता है इन संदेशों का वृक्ष, और प्रत्येक validator को मर्केल रूट और भेजता है उनके संदेश के लिए मर्कल पथ। validator पथ को मान्य करता है और उस पर हस्ताक्षर करता है मर्केल जड़. ब्लॉक निर्माता तब बीएलएस हस्ताक्षर जमा करता है validators से मर्कल रूट, और केवल मर्कल रूट और प्रकाशित करता है संचित हस्ताक्षर. ब्लॉक निर्माता भी इसकी वैधता पर हस्ताक्षर करता है सस्ते ईसीडीएसए हस्ताक्षर का उपयोग करते हुए बहुहस्ताक्षर। यदि बहुहस्ताक्षरकर्ता ऐसा नहीं करता है सबमिट किए गए मर्कल रूट या भाग लेने वाले validators के बिटमास्क से मिलान करें, यह एक स्लैश करने योग्य व्यवहार है। श्रृंखला को सिंक्रनाइज़ करते समय, एक भागीदार validators से सभी BLS हस्ताक्षरों को मान्य करना चुन सकते हैं (जो बेहद महंगा है क्योंकि इसमें validators सार्वजनिक कुंजी एकत्र करना शामिल है), या केवलब्लॉक उत्पादकों से ईसीडीएमए हस्ताक्षर और इस तथ्य पर भरोसा करते हैं कि ब्लॉक निर्माता को चुनौती नहीं दी गई और उसे काट दिया गया। चुनौतियों के लिए ऑन-चेन लेनदेन और मर्कल प्रमाणों का उपयोग करना। यह यह ध्यान दिया जा सकता है कि यदि नहीं, तो validators से संदेशों को प्रकट करने का कोई महत्व नहीं है अमान्य स्थिति परिवर्तन का पता चला. केवल वे संदेश जिनमें वास्तविक तथ्य शामिल हैं अमान्य स्थिति परिवर्तन के प्रमाण प्रकट करने की आवश्यकता है, और केवल ऐसे संदेशों के लिए यह दिखाने की ज़रूरत है कि वे पूर्व प्रतिबद्धता से मेल खाते हैं। संदेश की जरूरत है दो उद्देश्यों के लिए प्रकट किया जाना: 1. वास्तव में चेन के रोलबैक को उस क्षण से पहले आरंभ करना अमान्य स्थिति परिवर्तन (अनुभाग 3.7.5 देखें)। 2. यह साबित करने के लिए कि validator ने इसकी वैधता को प्रमाणित करने का प्रयास नहीं किया अमान्य हिस्सा. किसी भी स्थिति में हमें दो मुद्दों पर ध्यान देने की आवश्यकता है: 1. वास्तविक प्रतिबद्धता को श्रृंखला में शामिल नहीं किया गया था, केवल मर्कल रूट को शामिल किया गया था अन्य संदेशों के साथ एकत्रित प्रतिबद्धता। validator का उपयोग करने की आवश्यकता है ब्लॉक निर्माता द्वारा प्रदान किया गया मर्कल पथ और उनकी मूल प्रतिबद्धता साबित करें कि वे चुनौती के प्रति प्रतिबद्ध हैं। 2. यह संभव है कि शार्ड को सौंपे गए सभी validator अमान्य हों राज्य परिवर्तन भ्रष्ट ब्लॉक उत्पादकों को सौंपा जाना है उन्हें सेंसर कर रहे हैं. इससे निजात पाने के लिए हम उन्हें अपने खुलासे प्रस्तुत करने की अनुमति देते हैं श्रृंखला पर एक नियमित लेनदेन के रूप में और एकत्रीकरण को बायपास करें। उत्तरार्द्ध को केवल अमान्य राज्य संक्रमण के प्रमाण के लिए अनुमति दी गई है, जो हैं अत्यंत दुर्लभ, और इस प्रकार ब्लॉकों को स्पैम करने का परिणाम नहीं होना चाहिए। अंतिम मुद्दा जिसे संबोधित करने की आवश्यकता है वह यह है कि ब्लॉक निर्माता ऐसा कर सकते हैं संदेश एकत्रीकरण में भाग न लेने या जानबूझकर विशेष validators को सेंसर न करने का चयन करें। ब्लॉक बनाकर हम इसे आर्थिक रूप से अलाभकारी बनाते हैं निर्माता का इनाम उन्हें सौंपी गई validator की संख्या के अनुपात में होता है। हम यह भी ध्यान दें कि चूंकि युगों के बीच ब्लॉक उत्पादक बड़े पैमाने पर प्रतिच्छेद करते हैं (तब से)। यह हमेशा उच्चतम हिस्सेदारी वाले शीर्ष w प्रतिभागी होते हैं), validators कर सकते हैं बड़े पैमाने पर समान ब्लॉक उत्पादकों के साथ काम करने पर अड़े रहते हैं, और इस प्रकार जोखिम कम हो जाता है एक ऐसे ब्लॉक निर्माता को सौंपे जाने का, जिसने अतीत में उन्हें सेंसर किया था। 3.9 स्नैपशॉट श्रृंखला चूंकि मुख्य श्रृंखला पर ब्लॉक बहुत बार डाउनलोड किए जाते हैं पूरा इतिहास बहुत जल्दी महंगा हो सकता है। इसके अलावा, प्रत्येक के बाद से ब्लॉक में बड़ी संख्या में प्रतिभागियों के बीएलएस हस्ताक्षर हैं, हस्ताक्षर की जांच करने के लिए सार्वजनिक कुंजी का एकत्रीकरण निषेधात्मक हो सकता है महंगा भी. अंततः, चूंकि किसी भी निकट भविष्य में Ethereum 1.0 संभवतः एक ही रहेगा सबसे अधिक उपयोग किए जाने वाले blockchains में से, संपत्तियों को स्थानांतरित करने का एक सार्थक तरीका है

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

निष्कर्ष

इस दस्तावेज़ में हमने शार्प्ड blockchains और के निर्माण के तरीकों पर चर्चा की मौजूदा दृष्टिकोणों के साथ दो प्रमुख चुनौतियों को कवर किया गया, अर्थात् राज्य की वैधता और डेटा उपलब्धता। फिर हमने नाइटशेड प्रस्तुत किया, जो एक शानदार डिज़ाइन है शक्तियाँ NEAR प्रोटोकॉल। यदि आपके पास टिप्पणियाँ, प्रश्न या प्रतिक्रिया है तो डिज़ाइन पर काम चल रहा है इस दस्तावेज़ पर, कृपया https://near.chat. पर जाएँ