🍿 💕 🔝 डिस्ट्रिब्यूटेड व्हीसेट रजिस्ट्री: हाइपरलेगर फैब्रिक के साथ अनुभव 🚰 💇🏼 ⛳️

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

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

समस्या: ब्लॉकचेन को अभी तक छोटा नहीं किया गया है

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

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

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

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

विलंब

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

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

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

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

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

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

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

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

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

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

{
 Status string //  : "pending", "done", "failed"
 TxID: string // ID 
 Error: string // optional,   
}

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

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

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

Backpressure: बफर रणनीति

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

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

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

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

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

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

अन्य उपकरण

चिनकोड के बारे में यहां कुछ नहीं कहा गया, क्योंकि, एक नियम के रूप में, इसमें अनुकूलन करने के लिए कुछ भी नहीं है। चिनकोड को जितना संभव हो उतना सरल और सुरक्षित होना चाहिए - यह सब इसके लिए आवश्यक है। Cheynkod सरल और सुरक्षित रूप से S7 Techlab और स्थैतिक विश्लेषक Revive ^ CC से SSKit की रूपरेखा तैयार करने में हमारी मदद करता है । इसके अलावा, हमारी टीम फैब्रिक को सरल और सुखद बनाने के लिए उपयोगिताओं का एक समूह विकसित कर रही है: एक ब्लॉकचेन एक्सप्लोरर , नेटवर्क कॉन्फ़िगरेशन को स्वचालित रूप से बदलने (संगठनों को जोड़ने / हटाने, RAFT नोड्स) के लिए एक उपयोगिता, प्रमाण पत्र को वापस लाने और पहचान को हटाने के लिए एक उपयोगिता । यदि आप योगदान करना चाहते हैं - स्वागत है।

निष्कर्ष

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

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