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

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

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

समस्या: ब्लॉकचेन अभी तक स्केल नहीं हुआ है

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

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

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

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

विलंब

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

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

यहाँ से लिया गया: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

अन्य उपकरण

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

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

निष्कर्ष

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

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

स्रोत: www.habr.com