व्हीलसेट के लिए वितरित रजिस्ट्री: हाइपरलेजर फैब्रिक के साथ एक अनुभव

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

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

समस्या: ब्लॉकचेन अभी तक बड़े पैमाने पर नहीं हैं

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

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

श्वेतपत्रों और मीडिया के नारे हमसे वादा करते हैं कि अगला विकास हमें प्रति सेकंड लाखों लेनदेन करने की अनुमति देगा। यह वास्तव में क्या है?

मेननेट एथेरियम वर्तमान में ~30 टीपीएस पर चल रहा है। अकेले इस वजह से, इसे किसी भी तरह से कॉर्पोरेट जरूरतों के लिए उपयुक्त ब्लॉकचेन के रूप में समझना मुश्किल है। अनुमति प्राप्त समाधानों में 2000 टीपीएस दर्शाने वाले बेंचमार्क हैं (कोरम) या 3000 टीपीएस (हाइपरलेगर फैब्रिक, प्रकाशन में थोड़ा कम है, लेकिन आपको यह ध्यान रखना होगा कि बेंचमार्क पुराने सर्वसम्मति इंजन पर किया गया था)। था रैडिकल फैब्रिक प्रोसेसिंग का एक प्रयास, जिसने सबसे खराब परिणाम नहीं दिए, 20000 टीपीएस, लेकिन अभी तक यह सिर्फ अकादमिक शोध है, इसके स्थिर कार्यान्वयन की प्रतीक्षा है। यह संभावना नहीं है कि एक निगम जो ब्लॉकचेन डेवलपर्स के एक विभाग को बनाए रखने का जोखिम उठा सकता है, ऐसे संकेतक लगाएगा। लेकिन समस्या केवल थ्रूपुट की नहीं है, विलंबता की भी है।

विलंब

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

आइए यह समझने के लिए हाइपरलेजर फैब्रिक में लेनदेन जीवनचक्र पर करीब से नज़र डालें कि समय कहाँ व्यतीत होता है और यह ब्लॉक जेनरेशन मापदंडों से कैसे संबंधित है।

यहाँ से लिया गया: हाइपरलेजर-फैब्रिक.readthedocs.io/en/release-1.4/arch-दीप-dive.html#swimlane

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

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

ब्लॉक फाइनल होने की प्रतीक्षा करने से कैसे बचें और लेनदेन की स्थिति को ट्रैक करने की क्षमता न खोएं

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

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

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

अगला कदम सिस्टम के साथ क्लाइंट के इंटरेक्शन को एसिंक्रोनस बनाना है ताकि उसे 15, 30 या 10000000 सेकंड तक इंतजार न करना पड़े, जिसे हम बैचटाइमआउट के रूप में सेट करेंगे। लेकिन साथ ही, यह सत्यापित करने की क्षमता बनाए रखना आवश्यक है कि लेनदेन द्वारा शुरू किए गए परिवर्तन ब्लॉकचेन में दर्ज किए गए हैं/नहीं हैं।
लेन-देन की स्थिति को संग्रहीत करने के लिए एक डेटाबेस का उपयोग किया जा सकता है। उपयोग में आसानी के कारण सबसे सरल विकल्प CouchDB है: डेटाबेस में बॉक्स से बाहर एक यूआई, एक REST API है, और आप इसके लिए आसानी से प्रतिकृति और शार्डिंग सेट कर सकते हैं। आप बस उसी CouchDB उदाहरण में एक अलग संग्रह बना सकते हैं जो फैब्रिक का उपयोग अपनी विश्व स्थिति को संग्रहीत करने के लिए करता है। हमें इस प्रकार के दस्तावेज़ों को संग्रहीत करने की आवश्यकता है।

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

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

इस योजना में, उपयोगकर्ता अंततः ब्लॉक बनने का इंतजार नहीं करता है, स्क्रीन पर 10 सेकंड के लिए घूमते हुए पहिये को देखता है, उसे सिस्टम से तुरंत प्रतिक्रिया मिलती है और काम करना जारी रखता है।

हमने लेनदेन स्थितियों को संग्रहीत करने के लिए बोल्टडीबी को चुना क्योंकि हमें मेमोरी को बचाने की आवश्यकता है और हम एक अलग डेटाबेस सर्वर के साथ नेटवर्क इंटरैक्शन पर समय बर्बाद नहीं करना चाहते हैं, खासकर जब यह इंटरैक्शन एक सादे पाठ प्रोटोकॉल का उपयोग करके होता है। वैसे, चाहे आप ऊपर वर्णित योजना को लागू करने के लिए CouchDB का उपयोग करें या केवल विश्व स्थिति को संग्रहीत करने के लिए, किसी भी स्थिति में CouchDB में डेटा संग्रहीत करने के तरीके को अनुकूलित करना समझ में आता है। डिफ़ॉल्ट रूप से, CouchDB में, बी-ट्री नोड्स का आकार 1279 बाइट्स है, जो डिस्क पर सेक्टर आकार से बहुत छोटा है, जिसका अर्थ है कि पेड़ को पढ़ने और पुनर्संतुलित करने के लिए डिस्क तक अधिक भौतिक पहुंच की आवश्यकता होगी। इष्टतम आकार मानक के अनुरूप है उन्नत प्रारूप और 4 किलोबाइट है. अनुकूलन के लिए हमें पैरामीटर सेट करने की आवश्यकता है btree_chunk_size 4096 के बराबर CouchDB कॉन्फ़िगरेशन फ़ाइल में। बोल्टडीबी के लिए ऐसा मैन्युअल हस्तक्षेप आवश्यक नहीं.

बैकप्रेशर: बफर रणनीति

लेकिन बहुत सारे संदेश हो सकते हैं. चित्र में दिखाई गई सेवाओं के अलावा एक दर्जन अन्य सेवाओं के साथ संसाधनों को साझा करना, सिस्टम जितना संभाल सकता है उससे अधिक - और यह सब उन मशीनों पर भी त्रुटिपूर्ण रूप से काम करना चाहिए जिन पर Intellij Idea चलाना बेहद कठिन होगा।

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

छोड़ने: हम दावा कर सकते हैं कि हम टी सेकंड में अधिकतम एक्स लेनदेन संसाधित करने में सक्षम हैं। इस सीमा से अधिक के सभी अनुरोध खारिज कर दिए जाते हैं। यह काफी सरल है, लेकिन तब आप UX के बारे में भूल सकते हैं।

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

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

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

अन्य उपकरण

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

इसके अलावा, हमारी टीम फैब्रिक के साथ काम को सरल और आनंददायक बनाने के लिए उपयोगिताओं का एक सेट विकसित कर रही है: ब्लॉकचेन एक्सप्लोरर, के लिए एक उपयोगिता स्वचालित नेटवर्क कॉन्फ़िगरेशन परिवर्तन (संगठनों, RAFT नोड्स को जोड़ना/हटाना), के लिए उपयोगिता प्रमाणपत्रों को रद्द करना और पहचान हटाना. यदि आप योगदान देना चाहते हैं तो आपका स्वागत है।

निष्कर्ष

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

मूलतः, मैं बस यही साझा करना चाहता था। मुझे खुशी होगी अगर इससे किसी को उनके काम में मदद मिलेगी।

स्रोत: www.habr.com