ह्वीलसेटहरूको लागि वितरित खाता: हाइपरलेजर कपडाको साथ अनुभव

नमस्ते, म DRD KP परियोजनाको टोलीमा काम गर्छु (ह्वील सेटहरूको जीवन चक्र निगरानीको लागि वितरित डाटा रजिस्ट्री)। यहाँ म टेक्नोलोजीको अवरोध अन्तर्गत यस परियोजनाको लागि इन्टरप्राइज ब्लकचेन विकास गर्ने हाम्रो टोलीको अनुभव साझा गर्न चाहन्छु। म प्रायः हाइपरलेजर कपडाको बारेमा कुरा गर्नेछु, तर यहाँ वर्णन गरिएको दृष्टिकोण कुनै पनि अनुमति प्राप्त ब्लकचेनमा एक्स्ट्रापोलेट गर्न सकिन्छ। हाम्रो अनुसन्धानको अन्तिम लक्ष्य भनेको इन्टरप्राइज ब्लकचेन समाधानहरू तयार गर्नु हो ताकि अन्तिम उत्पादन प्रयोग गर्न रमाइलो होस् र मर्मत गर्न धेरै गाह्रो नहोस्।

त्यहाँ कुनै आविष्कारहरू, अप्रत्याशित समाधानहरू हुनेछैनन्, र कुनै अनौठो घटनाक्रमहरू यहाँ हाइलाइट गरिने छैनन् (किनभने मसँग कुनै छैन)। म केवल मेरो मामूली अनुभव साझा गर्न चाहन्छु, "यो सम्भव थियो" देखाउन चाहन्छु र, हुनसक्छ, टिप्पणीहरूमा राम्रो र नराम्रो निर्णयहरू गर्ने अन्य व्यक्तिहरूको अनुभवहरू पढ्नुहोस्।

समस्या: ब्लकचेन अझै मापन गर्दैन

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

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

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

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

विलम्बता

प्रणाली द्वारा यसको अन्तिम स्वीकृतिको लागि लेनदेन प्रारम्भ भएको क्षणबाट ढिलाइ सन्देश प्रमाणीकरण र अर्डरिंगका सबै चरणहरू पार गर्ने गतिमा मात्र होइन, तर ब्लक गठन प्यारामिटरहरूमा पनि निर्भर गर्दछ। यदि हाम्रो ब्लकचेनले हामीलाई 1000000 tps को गतिमा कमिट गर्न अनुमति दिन्छ, तर 10 MB ब्लक उत्पन्न गर्न 488 मिनेट चाहिन्छ, के यो हाम्रो लागि सजिलो हुनेछ?

समय कहाँ खर्च हुन्छ र यो कसरी ब्लक जेनेरेशन प्यारामिटरहरूसँग सम्बन्धित छ भनेर बुझ्न Hyperledger Fabric मा लेनदेन जीवनचक्रलाई नजिकबाट हेरौं।

यहाँबाट लिइयो: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(१) क्लाइन्टले लेनदेन सिर्जना गर्छ, यसलाई अनुमोदन गर्ने साथीहरूलाई पठाउँछ, पछिल्लो लेनदेनको नक्कल गर्छ (चेनकोडद्वारा हालको स्थितिमा परिवर्तनहरू लागू गर्नुहोस्, तर खातामा प्रतिबद्ध नगर्नुहोस्) र RWSet - मुख्य नामहरू, संस्करणहरू र मानहरू प्राप्त गर्नुहोस्। CouchDB मा संग्रहबाट लिइएको, (1) अनुमोदनकर्ताहरूले ग्राहकलाई हस्ताक्षरित RWSet फिर्ता पठाउँछन्, (2) ग्राहकले या त सबै आवश्यक साथीहरू (समर्थकहरू) को हस्ताक्षरहरूको उपस्थितिको लागि जाँच गर्दछ, र त्यसपछि लेनदेन अर्डर सेवामा पठाउँदछ। , वा प्रमाणीकरण बिना पठाउँछ (जाँच अझै पछि हुनेछ), अर्डरिङ सेवाले ब्लक बनाउँछ र (3) सबै साथीहरूलाई फिर्ता पठाउँछ, केवल समर्थनकर्ताहरूलाई मात्र होइन; साथीहरू जाँच गर्नुहोस् कि पढ्ने सेटका मुख्य संस्करणहरू डाटाबेसका संस्करणहरूसँग मेल खान्छ, कि सबै अनुमोदकहरूसँग हस्ताक्षरहरू छन्, र अन्तमा ब्लक कमिट गर्नुहोस्।

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

कसरी ब्लक फाइनलाइजेसनको प्रतीक्षा गर्नबाट बच्न र लेनदेन स्थिति ट्र्याक गर्ने क्षमता गुमाउनु हुँदैन

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

पहिले, हामीले कुनै न कुनै रूपमा ठूलो ब्लक साइजको कारणले गर्दा भएको MVCC विवादहरू समाधान गर्न आवश्यक छ, जसमा एउटै संस्करणमा फरक RWSets समावेश हुन सक्छ। स्पष्ट रूपमा, ग्राहक पक्षमा (ब्लकचेन नेटवर्कको सम्बन्धमा, यो राम्रोसँग ब्याकइन्ड हुन सक्छ, र मेरो मतलब यो हो) तपाईंलाई आवश्यक छ। MVCC विवाद ह्यान्डलर, जुन कि त छुट्टै सेवा वा कल माथिको नियमित डेकोरेटर हुन सक्छ जसले पुन: प्रयास तर्कको साथ लेनदेन सुरु गर्छ।

पुन: प्रयास घातीय रणनीतिको साथ लागू गर्न सकिन्छ, तर त्यसपछि विलम्बता घातीय रूपमा घट्नेछ। त्यसोभए तपाईंले या त केही साना सीमाहरूमा अनियमित पुन: प्रयास प्रयोग गर्नुपर्छ, वा एक स्थिर। पहिलो विकल्पमा सम्भावित टक्करहरूमा आँखाको साथ।

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

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

यो कागजातलाई लेनदेन साथीहरूलाई पठाउनु अघि डाटाबेसमा लेखिएको छ, इकाई ID प्रयोगकर्तालाई फिर्ता गरिन्छ (एउटै ID कुञ्जीको रूपमा प्रयोग गरिन्छ) यदि यो सिर्जना सञ्चालन हो, र त्यसपछि स्थिति, TxID र त्रुटि क्षेत्रहरू हुन्। सान्दर्भिक जानकारी साथीहरूबाट प्राप्त भएको रूपमा अद्यावधिक गरियो।

यस योजनामा, प्रयोगकर्ताले अन्तमा ब्लक बन्नको लागि पर्खदैन, 10 सेकेन्डको लागि स्क्रिनमा स्पिनिङ व्हील हेर्दै, उसले प्रणालीबाट तत्काल प्रतिक्रिया प्राप्त गर्दछ र काम गर्न जारी राख्छ।

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

ब्याकप्रेसर: बफर रणनीति

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

सञ्चार प्रणाली, उत्पादक र उपभोक्ताको फरक क्षमताको समस्या विभिन्न तरिकाले समाधान हुन्छ। हामी के गर्न सक्छौं हेरौं।

छोड्दै: हामी दाबी गर्न सक्छौं कि हामी T सेकेन्डमा धेरै X लेनदेनहरू प्रशोधन गर्न सक्षम छौं। यो सीमा नाघेका सबै अनुरोधहरू खारेज गरिएका छन्। यो एकदम सरल छ, तर त्यसपछि तपाईं UX बिर्सन सक्नुहुन्छ।

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

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

योजनामा ​​दुई नयाँ कार्यहरू थपिएका छन्: (१) API मा अनुरोध आएपछि, लेनदेन कल गर्न आवश्यक प्यारामिटरहरू सहितको सन्देश लाइनमा राखिएको छ, र ग्राहकले लेनदेन स्वीकार गरेको सन्देश प्राप्त गर्दछ। प्रणाली, (२) ब्याकइन्डले लामबाट कन्फिगरेसनमा निर्दिष्ट गतिमा डाटा पढ्छ; लेनदेन प्रारम्भ गर्दछ र स्थिति स्टोरमा डाटा अपडेट गर्दछ।
अब तपाइँ गठन समय बढाउन सक्नुहुन्छ र प्रयोगकर्ताबाट ढिलाइ लुकाएर, तपाइँले चाहानु भएसम्म ब्लक क्षमता।

अन्य उपकरणहरू

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

थप रूपमा, हाम्रो टोलीले कपडासँग काम गर्न सरल र रमाइलो बनाउन उपयोगिताहरूको सेट विकास गर्दैछ: blockchain अन्वेषक, को लागि एक उपयोगिता स्वचालित नेटवर्क कन्फिगरेसन परिवर्तनहरू (संगठनहरू थप्दै/हटाउँदै, RAFT नोडहरू), उपयोगिता प्रमाणपत्रहरू रद्द गर्ने र पहिचान हटाउने। यदि तपाईं योगदान गर्न चाहनुहुन्छ भने, तपाईंलाई स्वागत छ।

निष्कर्षमा

यस दृष्टिकोणले तपाईंलाई सजिलैसँग हाइपरलेजर फेब्रिकलाई कोरम, अन्य निजी इथरियम नेटवर्कहरू (PoA वा PoW) को साथ बदल्न अनुमति दिन्छ, वास्तविक थ्रुपुटलाई उल्लेखनीय रूपमा घटाउँछ, तर एकै समयमा सामान्य UX (ब्राउजरमा प्रयोगकर्ताहरू र एकीकृत प्रणालीहरूको लागि दुवै) कायम राख्छ। योजनामा ​​फेब्रिकलाई Ethereum ले प्रतिस्थापन गर्दा, तपाईंले MVCC द्वन्द्वहरू प्रशोधन गर्ने र पुनः पठाउने प्रक्रियाबाट पुन: प्रयास सेवा/डेकोरेटरको तर्क मात्र परिवर्तन गर्न आवश्यक छ। बफरिङ र स्थिति भण्डारणले ब्लक गठन समयबाट प्रतिक्रिया समय दोहोर्याउन सम्भव बनायो। अब तपाइँ हजारौं अर्डर नोडहरू थप्न सक्नुहुन्छ र डराउनु पर्दैन कि ब्लकहरू प्रायः बन्छन् र अर्डर सेवा लोड गर्नुहोस्।

मूलतः, मैले साझा गर्न चाहेको सबै हो। यदि यसले कसैलाई उनीहरूको काममा मद्दत गर्छ भने म खुसी हुनेछु।

स्रोत: www.habr.com