समानांतर निष्पादन पर एक अध्ययन: वह सब कुछ जो आपको जानना आवश्यक है

प्रस्तावना

यह शोध एथेरियम के समान कार्यान्वयन प्रणालियों की तुलना करता है और लेनदेन के समानांतर निष्पादन को प्राप्त करने की कठिनाइयों और संभावनाओं का विश्लेषण करता है।

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

अनुसंधान वस्तुएँ

1. FISCO-BCOS, कंसोर्टियम ब्लॉकचेन में से एक है जो ब्लॉकों के भीतर लेनदेन सत्यापन के समानांतर निष्पादन का समर्थन करता है।

   
   

2. खीपू सार्वजनिक श्रृंखला, एथेरियम प्रोटोकॉल का स्केल कार्यान्वयन।

   
   

3. एप्टोस पब्लिक चेन, मूव वर्चुअल मशीन।

समानांतर निष्पादन के साथ कठिनाइयाँ

आइए पारंपरिक लेनदेन निष्पादन प्रक्रिया पर एक नज़र डालें।

निष्पादन मॉड्यूल प्रत्येक लेनदेन को ब्लॉक से निकालता है और इसे क्रमिक रूप से निष्पादित करता है।

नवीनतम विश्व स्थिति को निष्पादन प्रक्रिया के दौरान संशोधित किया जाएगा, और फिर ब्लॉक के पूरा होने के बाद नवीनतम विश्व स्थिति तक पहुंचने के लिए लेन-देन पूरा होने के बाद राज्य को जोड़ा जाएगा।

अगले ब्लॉक का निष्पादन वर्तमान/पिछले ब्लॉक से पूरी तरह से विश्व स्थिति पर निर्भर है, इसलिए, यह अनुक्रमिक, एकल-थ्रेडेड निष्पादन प्रक्रिया समानांतर निष्पादन के लिए बहुत उपयुक्त नहीं है।

नीचे, वर्तमान एथेरियम समानांतर निष्पादन विधियों में मुख्य संघर्ष हैं:

1. खाता संघर्ष: यदि दो धागे एक ही समय में एक पते के खाते की शेष राशि या अन्य विशेषताओं को संसाधित करते हैं, तो हम यह कैसे सुनिश्चित करते हैं कि यह अनुक्रमिक प्रसंस्करण के परिणाम के अनुरूप है, अर्थात क्या विश्व राज्य एक निश्चित परिमित राज्य मशीन है?

2. एक ही पते का भंडारण संघर्ष : जहां दोनों अनुबंधों ने एक ही वैश्विक चर के भंडारण को संशोधित किया है।

   
   

3. क्रॉस-कॉन्ट्रैक्ट कॉल कॉन्फ्लिक्ट: यदि कॉन्ट्रैक्ट ए को पहले तैनात किया जाता है, तो कॉन्ट्रैक्ट बी को कॉन्ट्रैक्ट ए की तैनाती के पूरा होने तक इंतजार करना पड़ता है।

समानांतर निष्पादन योजनाएं

फिस्को-बीसीओएस

सारांश

फिस्को-बीसीओएस 2.0 लेनदेन प्रसंस्करण में एक ग्राफ संरचना का उपयोग करता है। डेवलपर्स ने डायरेक्टेड एसाइक्लिक ग्राफ मॉडल (डीएजी) के आधार पर एक समानांतर लेनदेन निष्पादक (पीटीई) तैयार किया है।

पीटीई मल्टी-कोर प्रोसेसर के फायदों का पूरी तरह से उपयोग करने में आपकी मदद कर सकता है ताकि ब्लॉक में लेन-देन को संभव सीमा तक समानांतर में निष्पादित किया जा सके।

साथ ही, यह उपयोगकर्ता के लिए एक सरल और मैत्रीपूर्ण प्रोग्रामिंग इंटरफ़ेस प्रदान करता है, ताकि उपयोगकर्ता को समानांतर कार्यान्वयन के थकाऊ विवरणों की परवाह न करनी पड़े।

बेंचमार्क टेस्ट प्रोग्राम के प्रायोगिक परिणाम बताते हैं कि पारंपरिक सीरियल ट्रांजैक्शन एक्जीक्यूशन स्कीम की तुलना में, आदर्श परिस्थितियों में 4-कोर प्रोसेसर पर चलने वाले PTE लगभग 200% ~ 300% प्रदर्शन सुधार प्राप्त कर सकते हैं, और कम्प्यूटेशनल सुधार संख्या के अनुपात में है अवश्य ही।

जितने अधिक कोर, उतना बेहतर प्रदर्शन।

सामान्य योजना

एक चक्रीय-निर्देशित ग्राफ को अक्सर निर्देशित चक्रीय ग्राफ (डीएजी) के रूप में संदर्भित किया जाता है।

लेन-देन के एक बैच में, प्रत्येक लेन-देन के कब्जे वाले परस्पर अनन्य संसाधनों की पहचान की जाती है; फिर एक लेन-देन पर निर्भर डीएजी का निर्माण ब्लॉक में लेनदेन के अनुक्रम और पारस्परिक रूप से अनन्य संसाधनों के व्यवसाय संबंध के अनुसार किया जाता है।

जैसा कि नीचे दिए गए आंकड़े में दिखाया गया है, 0 की इनबाउंड डिग्री (कोई निर्भर प्रीऑर्डर कार्य नहीं) वाले सभी लेन-देन समानांतर में निष्पादित किए जा सकते हैं। बाईं ओर मूल लेनदेन सूची के क्रम के आधार पर टोपोलॉजिकल सॉर्टिंग द्वारा दाईं ओर लेनदेन डीएजी प्राप्त किया जा सकता है।

मॉड्यूलर आर्किटेक्चर

• उपयोगकर्ता SDK के माध्यम से प्रत्यक्ष या अप्रत्यक्ष रूप से लेन-देन आरंभ करते हैं।

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

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

• ब्लॉक सत्यापित होने के बाद, ब्लॉक को चेन पर अपलोड कर दिया जाता है। लेन-देन निष्पादित होने के बाद, यदि प्रत्येक नोड की स्थिति सुसंगत है, तो एक आम सहमति बन जाती है और ब्लॉक को अंतर्निहित भंडारण के लिए लिखा जाता है, जो ब्लॉकचैन पर स्थायी रूप से दर्ज किया जाता है।

लेनदेन डीएजी की निर्माण प्रक्रिया

1. पैक्ड ब्लॉक से ब्लॉक में सभी लेन-देन लें।

   
   

2. लेन-देन की संख्या के साथ एक DAG उदाहरण को अधिकतम वर्टेक्स के रूप में प्रारंभ करें।

   
   

3. क्रम में सभी लेन-देन पढ़ें। क्या लेन-देन मर्ज करने योग्य होना चाहिए, इसके विरोध क्षेत्र को हल करें और जांचें कि क्या कोई पिछला लेन-देन इसके साथ विरोध करता है। यदि ऐसा है, तो संबंधित लेन-देन के बीच एक निर्भरता किनारे का निर्माण करें। यदि लेन-देन मर्ज करने योग्य नहीं है, तो यह माना जाता है कि पिछले सभी लेन-देन निष्पादित होने के बाद इसे निष्पादित किया जाना है, इसलिए लेन-देन और उसके सभी पूर्ववर्तियों के बीच एक निर्भरता बढ़त बनाई जाती है।

नोट : एक बार सभी आश्रित किनारे बन जाने के बाद, उन्हें मर्ज नहीं किया जा सकता है और केवल क्रमिक रूप से निष्पादित किया जा सकता है।

डीएजी निष्पादन प्रक्रिया

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

   
   

2. जब DAG पूरा नहीं होता है, तो थ्रेड लूप DAG के वेटपॉप विधि से निकाले जाने के लिए 0 की इन-डिग्री के साथ तैयार लेनदेन की प्रतीक्षा करता है। यदि निष्पादित किया जाने वाला लेन-देन सफलतापूर्वक निकाला जाता है, तो लेन-देन निष्पादित किया जाएगा। यदि यह विफल रहता है, तो DAG ने निष्पादन पूरा कर लिया है और थ्रेड बाहर निकल जाता है।

समस्याएं और समाधान

1. एक ही ब्लॉक के लिए, हम कैसे सुनिश्चित करें कि सभी नोड्स ने निष्पादन पूरा कर लिया है और एक ही स्थिति में हैं (तीन रूट नोड्स मैच)?

फिस्को बीसीओएस सत्यापित करता है कि ट्रिपल, यानी, राज्य रूट, लेनदेन रूट, और रसीद रूट, यह निर्धारित करने के लिए एक दूसरे के बराबर हैं कि राज्यों पर सहमति है या नहीं। लेन-देन रूट एक हैश मान है जिसकी गणना ब्लॉक में सभी लेन-देन के आधार पर की जाती है।

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

यह सर्वविदित है कि अलग-अलग सीपीयू कोर पर समानांतर में निष्पादित निर्देशों के बीच निष्पादन के क्रम का पहले से अनुमान नहीं लगाया जा सकता है, और समानांतर में निष्पादित लेनदेन के लिए भी यही सच है।

पारंपरिक लेन-देन निष्पादन योजना में, प्रत्येक लेन-देन निष्पादित होने के बाद राज्य की जड़ बदल जाती है, और परिवर्तित राज्य की जड़ को लेनदेन रसीद में लिखा जाता है।

सभी लेन-देन निष्पादित होने के बाद, अंतिम राज्य रूट ब्लॉकचैन की वर्तमान स्थिति का प्रतिनिधित्व करता है। उसी समय, रसीद रूट की गणना सभी लेनदेन प्राप्तियों के आधार पर की जाती है।

यह देखा जा सकता है कि पारंपरिक कार्यान्वयन में, राज्य रूट वैश्विक साझा चर के रूप में कार्य करता है।

जब लेन-देन को समानांतर और क्रम से बाहर निष्पादित किया जाता है, तो राज्य रूट की पारंपरिक गणना अब लागू नहीं होती है क्योंकि लेनदेन अलग-अलग मशीनों पर अलग-अलग क्रम में निष्पादित होते हैं और अंतिम राज्य रूट के अनुरूप होने की गारंटी नहीं होती है, न ही रसीद रूट की गारंटी होती है लगातार हो।

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

उसी समय, लेन-देन पावती में राज्य रूट सभी लेन-देन निष्पादित होने के बाद अंतिम राज्य रूट बन जाता है, इस प्रकार यह सुनिश्चित करता है कि आम सहमति नोड अभी भी एक समझौते पर पहुंच सकते हैं, भले ही लेन-देन समानांतर में निष्पादित हो।

2. कैसे निर्धारित करें कि दो लेनदेन निर्भर हैं?

यदि दो लेन-देन निर्भर नहीं हैं, लेकिन उन्हें आंका जाता है, तो इससे अनावश्यक प्रदर्शन हानि होगी। इसके विपरीत, यदि दोनों लेन-देन एक ही खाते की स्थिति को फिर से लिखते हैं लेकिन समानांतर में निष्पादित होते हैं, तो खाते की अंतिम स्थिति अनिश्चित हो सकती है।

इसलिए, निर्भरता का निर्धारण एक महत्वपूर्ण मुद्दा है जो प्रदर्शन को प्रभावित करता है और यह भी निर्धारित कर सकता है कि ब्लॉकचेन ठीक से काम कर सकता है या नहीं।

एक साधारण हस्तांतरण लेनदेन में, हम यह निर्धारित कर सकते हैं कि प्रेषक और प्राप्तकर्ता के पते के आधार पर दो लेनदेन निर्भर हैं या नहीं। एक उदाहरण के रूप में निम्नलिखित तीन हस्तांतरण लेनदेन लें, ए → बी, सी → डी, और डी → ई।

यह देखना आसान है कि डी → ई लेनदेन सी → डी लेनदेन के परिणाम पर निर्भर करता है, लेकिन ए → बी लेनदेन का अन्य दो लेनदेन से कोई लेना-देना नहीं है, इसलिए इसे समानांतर में निष्पादित किया जा सकता है।

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

ऐसा लगता है कि ए → बी के लेन-देन का सी और डी के खाते की स्थिति से कोई लेना-देना नहीं है, लेकिन उपयोगकर्ता के अंतर्निहित कार्यान्वयन में, ए एक विशेष खाता है, और सी के खाते से एक निश्चित शुल्क काटा जाना चाहिए ए के खाते के माध्यम से स्थानांतरित हर पैसा।

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

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

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

FISCO BCOS डेवलपर के लिए इंटरफ़ेस को उजागर करता है, जो उन संसाधनों को परिभाषित करता है जिन पर लेन-देन स्ट्रिंग्स के रूप में निर्भर करता है और निष्पादक को श्रृंखला पर सूचित करता है।

डेवलपर द्वारा निर्दिष्ट लेनदेन निर्भरता के अनुसार निष्पादक स्वचालित रूप से ब्लॉक में सभी लेनदेन को लेन-देन डीएजी में व्यवस्थित करेगा।

उदाहरण के लिए, एक साधारण हस्तांतरण अनुबंध में, डेवलपर केवल निर्दिष्ट करता है कि प्रत्येक हस्तांतरण लेनदेन के लिए निर्भरता {प्रेषक पता + प्राप्तकर्ता पता} है।

इसके अलावा, यदि डेवलपर स्थानांतरण तर्क में किसी अन्य तृतीय-पक्ष पते का परिचय देता है, तो निर्भरता को {प्रेषक पता + प्राप्तकर्ता पता + तृतीय-पक्ष पता} के रूप में परिभाषित करने की आवश्यकता है।

यह दृष्टिकोण सहज, सरल और सामान्य है, और सभी स्मार्ट अनुबंधों पर लागू होता है, लेकिन यह डेवलपर के कंधों पर जिम्मेदारी भी बढ़ाता है।

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

समानांतर ढांचा अनुबंध

डेवलपर्स के लिए समानांतर अनुबंधों के ढांचे का उपयोग करने के लिए, FISCO BCOS ने अनुबंध लेखन के लिए कुछ विनिर्देश निर्धारित किए हैं। विनिर्देश इस प्रकार हैं:

समानांतर पारस्परिक रूप से अनन्य

समानांतर में दो लेन-देन निष्पादित किए जा सकते हैं या नहीं, यह इस बात पर निर्भर करता है कि क्या दो लेन-देन परस्पर अनन्य हैं। म्युचुअल एक्सक्लूज़न दो लेनदेन के भंडारण चर के सेट के प्रतिच्छेदन को संदर्भित करता है।

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

• पारस्परिक रूप से अनन्य पैरामीटर: अनुबंध इंटरफ़ेस में अनुबंध भंडारण चर के "पढ़ने / लिखने" के संचालन से संबंधित पैरामीटर। उदाहरण के लिए ट्रांसफर इंटरफेस ट्रांसफर (एक्स, वाई) लें। एक्स और वाई परस्पर अनन्य पैरामीटर हैं।

  
  

• म्यूटेक्स: म्यूटेक्स मापदंडों के अनुसार लेनदेन से निकाली गई विशिष्ट म्यूटेक्स सामग्री। उदाहरण के लिए ट्रांसफर इंटरफेस ट्रांसफर (एक्स, वाई) लें। इस इंटरफ़ेस का उपयोग करते हुए एक हस्तांतरण लेनदेन में, विशिष्ट पैरामीटर स्थानांतरण (ए, बी) है, और इस ऑपरेशन का म्यूटेक्स [ए, बी] है। दूसरे लेनदेन के लिए, स्थानांतरण (ए, सी) कहा जाता है, और इस ऑपरेशन के लिए म्यूटेक्स [ए, सी] है।

यह निर्धारित करने के लिए कि क्या एक ही समय में दो लेन-देन समानांतर में निष्पादित किए जा सकते हैं, यह निर्धारित करना है कि क्या दो लेन-देन का म्यूटेक्स प्रतिच्छेद करता है। लेन-देन जिनके चौराहे खाली हैं समानांतर में निष्पादित किए जा सकते हैं।

FFISCO-BCOS समानांतर अनुबंध, पूर्व-संकलित अनुबंध और दृढ़ता अनुबंध लिखने के दो तरीके प्रदान करता है, जिनमें से केवल उत्तरार्द्ध का वर्णन यहां किया गया है। वही पूर्व-संकलित अनुबंधों के लिए जाता है।

सॉलिडिटी कॉन्ट्रैक्ट पैरेलल फ्रेमवर्क

एक समानांतर दृढ़ता अनुबंध लिखने के लिए, उसके ऊपर, बस ParallelContract.sol उन अनुबंधों के लिए आधार वर्ग बनाएं जिन्हें आप समानांतर करना चाहते हैं। TheregisterParallelFunction() विधि को उन इंटरफेस को पंजीकृत करने के लिए कहा जाता है जिन्हें समानांतर किया जा सकता है।

समानांतर अनुबंध कोड इस प्रकार है:

 pragma solidity ^0.4.25; //Precompile the contract interface contract ParallelConfigPrecompiled { function registerParallelFunctionInternal(address, string, uint256) public returns (int); function unregisterParallelFunctionInternal(address, string) public returns (int); } //The parallel contract base class needs to be registered and the subcontract needs to be implement enable or disable interface contract ParallelContract { ParallelConfigPrecompiled precompiled = ParallelConfigPrecompiled(0x1006); function registerParallelFunction(string functionName, uint256 criticalSize) public { precompiled.registerParallelFunctionInternal(address(this), functionName, criticalSize); } function unregisterParallelFunction(string functionName) public { precompiled.unregisterParallelFunctionInternal(address(this), functionName); } function enableParallel() public; function disableParallel() public; }

निम्नलिखित उदाहरण समानांतर ढांचे के अनुबंध के आधार पर लिखित एक हस्तांतरण अनुबंध है:

 pragma solidity ^0.4.25; import "./ParallelContract.sol"; // Introduce ParallelContract.sol contract ParallelOk is ParallelContract // useParallelContract as a base class { // Contract implementation mapping (string => uint256) _balance; // Global mapping // The mutually exclusive variables from and to are the first two parameters at the beginning of transfer (). It can be seen that the contract requirements are still very strict, which will make users uncomfortable to write function transfer(string from, string to, uint256 num) public { _balance[from] -= num; // From is the key of the global mapping, and is a mutually exclusive parameter _balance[to] += num; //// To is the key of the global mapping, and is a mutually exclusive parameter } // The mutex variable name comes first as an argument to the beginning of set() function set(string name, uint256 num) public { _balance[name] = num; } function balanceOf(string name) public view returns (uint256) { return _balance[name]; } // Register contract interfaces that can be parallel function enableParallel() public { // The function definition string (note that there are no Spaces after ",") and the first few arguments are mutex arguments (mutex arguments must be first when designing a function) //The number 2 indicates that the first two are mutex parameters, and the system decodes the mutex according to the function signature and abi registerParallelFunction("transfer(string,string,uint256)", 2); // critical: string string // registerParallelFunction("set(string,uint256)", 1); // critical: string } // Deregister the parallel contract interface function disableParallel() public { unregisterParallelFunction("transfer(string,string,uint256)"); unregisterParallelFunction("set(string,uint256)"); } }

निर्धारित करें कि क्या इंटरफ़ेस समानांतर हो सकता है

एक समानांतर अनुबंध इंटरफ़ेस को संतुष्ट करना चाहिए:

• कोई बाहरी अनुबंध नहीं कहा जाता है।
• कोई अन्य फ़ंक्शन इंटरफ़ेस नहीं कहा जाता है।

म्यूटेक्स पैरामीटर निर्धारित करें

इंटरफ़ेस प्रोग्रामिंग करने से पहले, इंटरफ़ेस के पारस्परिक रूप से अनन्य पैरामीटर निर्धारित करें। इंटरफ़ेस के पारस्परिक रूप से अनन्य पैरामीटर वैश्विक चर के लिए परस्पर अनन्य हैं। परस्पर अनन्य मापदंडों को निर्धारित करने के नियम इस प्रकार हैं:

• यदि इंटरफ़ेस द्वारा वैश्विक मानचित्रण का उपयोग किया जाता है, तो मानचित्रण की कुंजी परस्पर अनन्य पैरामीटर है।

• यदि इंटरफ़ेस द्वारा वैश्विक सरणी का उपयोग किया जाता है, तो सरणी का सबस्क्रिप्ट पारस्परिक रूप से अनन्य पैरामीटर है।

• यदि इंटरफ़ेस एक साधारण प्रकार के वैश्विक चर तक पहुँचता है। एक साधारण प्रकार के सभी वैश्विक चर एक म्यूटेक्स पैरामीटर साझा करते हैं और म्यूटेक्स ऑब्जेक्ट के रूप में विभिन्न चर नामों का उपयोग करते हैं।

पैरामीटर प्रकार और क्रम निर्धारित करें

पारस्परिक रूप से अनन्य पैरामीटर निर्धारित करने के बाद, नियमों के अनुसार पैरामीटर प्रकार और ऑर्डर निर्धारित करें। नियम इस प्रकार हैं:

• इंटरफ़ेस पैरामीटर स्ट्रिंग, पता, uint256 और int256 तक सीमित हैं (भविष्य में समर्थित होने के लिए और प्रकार)।

• पारस्परिक रूप से अनन्य पैरामीटर सभी इंटरफ़ेस पैरामीटर में दिखाई देने चाहिए।

• सभी पारस्परिक रूप से अनन्य पैरामीटर इंटरफ़ेस पैरामीटर के पहले स्थान पर हैं।

यह देखा जा सकता है कि FISCO-BCOS का समानांतर लेन-देन काफी हद तक उपयोगकर्ताओं द्वारा लिखे गए अनुबंधों की विशिष्टताओं पर निर्भर करता है।

यदि उपयोगकर्ताओं द्वारा लिखे गए अनुबंधों के विनिर्देश मानकीकृत नहीं हैं, तो सिस्टम जल्दबाजी में समानांतर निष्पादन करता है, जो खाता बही की मूल असंगति का कारण हो सकता है।

खीपू

सारांश

खीपू का मानना ​​है कि उपयोगकर्ताओं के लिए उन पतों की श्रेणी को पहचानना और लेबल करना अवास्तविक है जो त्रुटि के बिना अनुबंध लिखते समय स्थिर संघर्ष पैदा करेगा। यह FISCO-BCOS के दृष्टिकोण के विपरीत है।

क्या, कहाँ, और किन परिस्थितियों में दौड़ की स्थिति दिखाई देगी, इसका अंदाजा तभी लगाया जा सकता है जब निश्चितता अधिग्रहण में वर्तमान स्थिति शामिल हो।

इस तरह का निर्णय, वर्तमान अनुबंध प्रोग्रामिंग भाषाओं के साथ, कोड के स्थिर विश्लेषण के लिए पूरी तरह से सही और बेमिसाल परिणाम प्राप्त करना लगभग असंभव बना देता है।

खीपू ने इस मुद्दे को हल करने के लिए एक अधिक व्यापक प्रयास किया है और इसे लागू करने के लिए एक प्रक्रिया पूरी कर ली है।

सामान्य योजना

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

समांतर निष्पादन चरण के बाद विलय चरण होता है, जब समांतर विश्व राज्यों को एक-एक करके विलय कर दिया जाता है। किसी लेन-देन को मर्ज करते समय, पहले यह निर्धारित करें कि रिकॉर्ड की गई स्थिर स्थितियों से पहले मर्ज की गई रेस स्थितियों के साथ आपका विरोध है या नहीं।

यदि नहीं, तो सीधे मर्ज करें। यदि ऐसा है, तो लेन-देन को फिर से दुनिया की पिछली स्थिति से शुरू करके निष्पादित किया जाता है जिसे विलय कर दिया गया है।

ब्लॉक के हैश के विरुद्ध अंतिम मर्ज किए गए विश्व राज्य की जाँच की जाती है। यह रक्षा की अंतिम पंक्ति है। यदि चेक गलत है, तो पिछले मर्ज को छोड़ दिया जाता है और ब्लॉक को फिर से निष्पादित किया जाता है।

समानता सूचकांक

यहाँ, खीपू समानता का एक सूचकांक प्रस्तुत करता है, जो एक ब्लॉक में लेनदेन के अनुपात को संदर्भित करता है जो फिर से निष्पादित किए बिना परिणामों को सीधे जोड़ सकता है।

क्रिएशन ब्लॉक से लेकर लेटेस्ट ब्लॉक तक कई दिनों तक एथेरियम रीप्ले के खीपू के अवलोकन से पता चलता है कि यह अनुपात (समानता) औसतन 80% तक पहुंच सकता है।

सामान्य तौर पर, यदि कंप्यूटिंग कार्यों को पूरी तरह से समानांतर किया जा सकता है, तो एकल श्रृंखला की मापनीयता अनंत होती है। क्योंकि आप हमेशा एक नोड में अधिक CPU कोर जोड़ सकते हैं। यदि ऐसा नहीं है, तो अधिकतम सैद्धांतिक दर अंडाल प्रमेय द्वारा सीमित है:

जिस सीमा तक आप सिस्टम को गति दे सकते हैं वह उन हिस्सों के पारस्परिक पर निर्भर करता है जिन्हें समानांतर नहीं किया जा सकता है। इसलिए, यदि आप 99% समानांतर कर सकते हैं, तो आप 100 गुना तक गति कर सकते हैं। लेकिन अगर आप केवल 95% समांतरता प्राप्त कर सकते हैं, तो आप केवल 20 गुना तेजी से प्राप्त कर सकते हैं।

एथेरियम पर सभी लेन-देन में, लगभग 80% समानांतर हो सकते हैं और 20% नहीं हो सकते हैं, इसलिए खीपू की गति सीमा लगभग 5 गुना है।

संघर्ष मार्कर

evm कोड में दिए गए निर्देशों को समझकर, यह पाया गया कि सीमित संख्या में निर्देशों ने भंडारण के लिए पढ़ने और लिखने की प्रक्रियाएँ बनाई थीं, इसलिए इन पढ़ने और लिखने की प्रक्रियाओं को रिकॉर्ड करना और पढ़ने और लिखने का संग्रह बनाना संभव था, लेकिन स्थिर कोड विश्लेषण यह सुनिश्चित नहीं कर सका कि ये प्रक्रियाएँ रिकॉर्ड की गई थीं।

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

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

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

इससे निपटने का सही तरीका यह है कि दूसरे अनुबंध के निष्पादन के बाद रीडसेट और राइटसेट के साथ पहले लेनदेन के निष्पादन के बाद रीडसेट और राइटसेट की तुलना करें, और देखें कि क्या उन्होंने एक ही खाते या भंडारण को पढ़ा और लिखा है।

अगर ऐसा है, तो इसका मतलब है कि दोनों सौदे संघर्ष में हैं। फिर दूसरा लेन-देन पहले लेन-देन के पूरा होने के बाद शुरू होगा और फिर से निष्पादित किया जाएगा।

इसी तरह, जैसा कि मर्ज स्टेट मशीन जारी रहती है, संघर्ष सेट जमा होता रहेगा, और जब तक बाद के लेनदेन पिछले लेनदेन के साथ संघर्ष करते हैं, तब तक उन्हें क्रमिक रूप से निष्पादित किया जाएगा जब तक कि सभी लेनदेन निष्पादित नहीं हो जाते।

एथेरियम के मेननेट पर लेन-देन की पुनरावृत्ति के माध्यम से, यह पाया जाता है कि जहां बहुत अधिक संघर्ष होते हैं, अधिकांश मामले एक ही ब्लॉक में परस्पर लेनदेन के साथ आदान-प्रदान होते हैं, जो इस प्रक्रिया के अनुरूप भी है।

सामान्य प्रक्रिया

विशिष्ट समानांतर प्रक्रिया

एप्टोस

सारांश

Aptos Diem की मूव लैंग्वेज और MoveVM पर बनाया गया है ताकि एक उच्च-थ्रूपुट श्रृंखला बनाई जा सके जो समानांतर निष्पादन को सक्षम बनाती है। Aptos का दृष्टिकोण उपयोगकर्ताओं/डेवलपर्स के लिए पारदर्शी रहते हुए संघों का पता लगाना है।

यही है, लेन-देन को स्पष्ट रूप से यह बताने की आवश्यकता नहीं है कि वे किस राज्य (स्मृति स्थान) का उपयोग करते हैं।

सामान्य योजना

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

ब्लॉक-एसटीएम लिखने-लिखने के विरोध से बचने के लिए एमवीसीसी (बहु-संस्करण समवर्ती नियंत्रण) का उपयोग करता है। सभी एक ही स्थान पर लिखे गए उनके संस्करणों के साथ संग्रहीत किए जाते हैं, जिसमें उनकी TX-ID होती है और tx लिखने की संख्या को फिर से निष्पादित किया जाता है।

जब एक लेन-देन (टीएक्स) एक स्मृति स्थान के लिए एक मान पढ़ता है, तो यह एमवीसीसी से उस स्थान पर लिखा गया मान प्राप्त करता है जो संबंधित संस्करण के साथ टीएक्स से पहले होता है ताकि यह निर्धारित किया जा सके कि कोई पढ़ने/लिखने का विरोध है या नहीं।

ब्लॉक-एसटीएम में, लेन-देन ब्लॉक के भीतर पूर्व-क्रमबद्ध होते हैं और निष्पादन के दौरान समानांतर निष्पादन के लिए प्रोसेसर थ्रेड्स के बीच विभाजित होते हैं। समानांतर निष्पादन में, यह माना जाता है कि लेन-देन को निष्पादित करने के लिए कोई निर्भरता नहीं है।

लेन-देन द्वारा संशोधित स्मृति स्थान रिकॉर्ड किए जाते हैं। निष्पादन के बाद, सभी लेनदेन परिणामों को सत्यापित करें। सत्यापन के दौरान, यदि कोई लेन-देन पिछले लेन-देन द्वारा संशोधित स्मृति स्थान तक पहुँचने के लिए पाया जाता है, तो लेन-देन अमान्य है।

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

यह देखा जा सकता है कि Aptos द्वारा उपयोग की जाने वाली योजना मोटे तौर पर ऊपर उल्लिखित Kipu के समान है, लेकिन कार्यान्वयन में कुछ अंतर हैं, जो इस प्रकार हैं:

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

• चूंकि मूव ग्लोबल रिसोर्स एड्रेसिंग को मूल रूप से सपोर्ट करता है, इसलिए एप्टोस लेनदेन को फिर से व्यवस्थित करेगा, यहां तक ​​कि ब्लॉकों में भी, जब यह समानांतर निष्पादन के लिए अनुकूल होगा। Aptos का दावा है कि यह योजना न केवल समानांतर की दक्षता में सुधार कर सकती है बल्कि MEV समस्या को भी हल कर सकती है। हालाँकि, क्या यह उपयोगकर्ता के अनुभव को प्रभावित करेगा, इस पर विचार किया जाना बाकी है।

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

बेंचमार्क टेस्ट

एप्टोस ने ब्लॉक-एसटीएम एकीकरण के बाद एक संबंधित बेंचमार्क बनाया और 10k लेनदेन के ब्लॉक के अनुक्रमिक निष्पादन और समानांतर निष्पादन के बीच तुलना की। तुलना परिणाम निम्नानुसार दिखाया गया है:

यह उपरोक्त आंकड़े से देखा जा सकता है कि ब्लॉक एसटीएम समानांतर में 32 थ्रेड्स के साथ अनुक्रमिक निष्पादन की तुलना में 16 गुना तेजी से और उच्च विवाद के तहत 8 गुना तेजी से प्राप्त करता है।

निष्कर्ष

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

सोलाना और सुई समान योजनाओं का उपयोग करते हैं, लेकिन उपयोगकर्ता की धारणा अलग है। बेहतर विश्लेषण परिणाम प्राप्त करने के लिए यह योजना अनिवार्य रूप से एक भंडारण मॉडल परिवर्तन है।

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

वर्चुअल मशीन गतिशील रूप से निष्पादन से पहले निर्भरता संबंधों का विश्लेषण करती है, इस प्रकार निर्भरता संबंधों के बिना समानांतर निष्पादन को लागू करती है।

इसे लागू करना मुश्किल है, और समानांतरता की डिग्री कुछ हद तक लेन-देन के खाता विभाजन पर निर्भर करती है। जब बहुत सारे लेन-देन विवाद होते हैं, तो प्रदर्शन लगातार पुन: निष्पादित करने से महत्वपूर्ण रूप से बिगड़ जाता है।

Aptos ने उल्लेख किया कि वे निर्भरताओं का बेहतर विश्लेषण करने के लिए उपयोगकर्ता-लेखित अनुबंधों का भविष्य अनुकूलन करेंगे और इस प्रकार तेजी से निष्पादन प्राप्त करेंगे।

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

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

संदर्भ

1. FISCO-BCOS Github, FISCO-BCOS
2. खीपू गिटहब, गिटहब - खीपू-आईओ/खिपू: एथेरियम पर आधारित एक उद्यम ब्लॉकचैन मंच
3. Aptos GitHub, GitHub - aptos-labs/aptos-core: Aptos एक लेयर 1 ब्लॉकचेन है जिसे बेहतर तकनीक और उपयोगकर्ता अनुभव के माध्यम से ब्लॉकचेन के व्यापक उपयोग का समर्थन करने के लिए बनाया गया है।

हमारे बारे में

2021 में स्थापित और शीर्ष-पायदान ब्लॉकचेन डेवलपर्स द्वारा संचालित, Sin7y एक प्रोजेक्ट इनक्यूबेटर और ब्लॉकचेन टेक्नोलॉजी रिसर्च टीम है, जो EVM, Layer2, क्रॉस-चेन, प्राइवेसी कंप्यूटिंग, ऑटोनॉमस पेमेंट सॉल्यूशंस आदि सहित सबसे महत्वपूर्ण और अत्याधुनिक तकनीकों की पड़ताल करती है। .

वर्तमान में हम ओलावीएम नामक एक ईवीएम-संगत, तेज़ और स्केलेबल जेडकेवीएम पर काम कर रहे हैं। यदि आप हमारे साथ बात करने में रुचि रखते हैं, तो बेझिझक हमारे टीजी समूह में शामिल हों या हमें [email protected] पर ईमेल करें।