व्हीलसेटसाठी वितरित लेजर: हायपरलेजर फॅब्रिकचा अनुभव

नमस्कार, मी डीआरडी केपी प्रकल्पाच्या टीममध्ये काम करतो (व्हील सेटच्या जीवन चक्राचे निरीक्षण करण्यासाठी वितरित डेटा नोंदणी). तंत्रज्ञानाच्या मर्यादांनुसार या प्रकल्पासाठी एंटरप्राइझ ब्लॉकचेन विकसित करण्याचा आमच्या कार्यसंघाचा अनुभव मला येथे सांगायचा आहे. मी मुख्यतः हायपरलेजर फॅब्रिकबद्दल बोलत आहे, परंतु येथे वर्णन केलेला दृष्टीकोन कोणत्याही परवानगी असलेल्या ब्लॉकचेनमध्ये एक्सट्रापोलेट केला जाऊ शकतो. आमच्या संशोधनाचे अंतिम उद्दिष्ट एंटरप्राइझ ब्लॉकचेन सोल्यूशन्स तयार करणे हे आहे जेणेकरून अंतिम उत्पादन वापरण्यास आनंददायी असेल आणि देखभाल करणे फार कठीण नाही.

येथे कोणतेही शोध, अनपेक्षित निराकरणे नसतील आणि कोणत्याही अद्वितीय घडामोडी येथे हायलाइट केल्या जाणार नाहीत (कारण माझ्याकडे कोणतेही नाही). मला फक्त माझा विनम्र अनुभव सामायिक करायचा आहे, "ते शक्य आहे" हे दाखवायचे आहे आणि कदाचित, टिप्पण्यांमध्ये चांगले आणि इतके चांगले निर्णय घेण्याच्या इतर लोकांच्या अनुभवांबद्दल वाचा.

समस्या: ब्लॉकचेन अद्याप मोजलेले नाहीत

आज, अनेक विकासकांचे प्रयत्न हे ब्लॉकचेनला खरोखरच सोयीस्कर तंत्रज्ञान बनवण्याच्या उद्देशाने आहेत, आणि सुंदर रॅपरमध्ये टाइम बॉम्ब नाही. राज्य चॅनेल, आशावादी रोलअप, प्लाझ्मा आणि शार्डिंग सामान्य होऊ शकतात. काही दिवस. किंवा कदाचित TON पुन्हा सहा महिन्यांसाठी लाँच पुढे ढकलेल आणि पुढील प्लाझ्मा ग्रुप अस्तित्वात नाही. आम्ही पुढील रोडमॅपवर विश्वास ठेवू शकतो आणि रात्री चमकदार श्वेतपत्रिका वाचू शकतो, परंतु येथे आणि आता आमच्याकडे जे काही आहे त्यासह काहीतरी करणे आवश्यक आहे. बकवास करा.

सध्याच्या प्रकल्पातील आमच्या कार्यसंघासाठी सेट केलेले कार्य सर्वसाधारणपणे असे दिसते: बरेच विषय आहेत, हजारोपर्यंत पोहोचतात, ज्यांना विश्वासावर नातेसंबंध तयार करायचे नाहीत; DLT वर एक उपाय तयार करणे आवश्यक आहे जे सामान्य पीसीवर विशेष कार्यप्रदर्शन आवश्यकतांशिवाय कार्य करेल आणि वापरकर्त्याला कोणत्याही केंद्रीकृत लेखा प्रणालीपेक्षा वाईट अनुभव प्रदान करेल. सोल्यूशनमागील तंत्रज्ञानाने डेटाच्या दुर्भावनापूर्ण हाताळणीची शक्यता कमी केली पाहिजे - म्हणूनच ब्लॉकचेन येथे आहे.

श्वेतपत्रिकेतील घोषणा आणि प्रसारमाध्यमे आम्हाला वचन देतात की पुढील विकास आम्हाला प्रति सेकंद लाखो व्यवहार करू देईल. खरंच काय आहे?

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

लेटेंसी

प्रणालीद्वारे व्यवहार सुरू केल्यापासून त्याच्या अंतिम मंजुरीपर्यंत होणारा विलंब केवळ प्रमाणीकरण आणि ऑर्डरिंगच्या सर्व टप्प्यांतून संदेश कोणत्या गतीने जातो यावर अवलंबून नाही तर ब्लॉक तयार करण्याच्या पॅरामीटर्सवर देखील अवलंबून असतो. जरी आमची ब्लॉकचेन आम्हाला 1000000 tps वेगाने कमिट करण्याची परवानगी देते, परंतु 10 MB ब्लॉक तयार करण्यासाठी 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 संघर्ष होण्याची शक्यता जास्त असते. याव्यतिरिक्त, BatchTimeout जसजसा वाढत जातो, 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 सेकंद स्क्रीनवर फिरणारे चाक पाहतो, त्याला सिस्टमकडून त्वरित प्रतिसाद मिळतो आणि तो कार्य करणे सुरू ठेवतो.

आम्ही व्यवहार स्थिती संग्रहित करण्यासाठी BoltDB निवडले कारण आम्हाला मेमरी वाचवायची आहे आणि वेगळ्या डेटाबेस सर्व्हरसह नेटवर्क परस्परसंवादावर वेळ वाया घालवायचा नाही, विशेषत: जेव्हा हा संवाद साधा मजकूर प्रोटोकॉल वापरून होतो. तसे, तुम्ही वर वर्णन केलेल्या योजनेची अंमलबजावणी करण्यासाठी CouchDB वापरत असलात किंवा फक्त जागतिक स्थिती संग्रहित करण्यासाठी, कोणत्याही परिस्थितीत CouchDB मध्ये डेटा कसा संग्रहित केला जातो ते ऑप्टिमाइझ करणे अर्थपूर्ण आहे. डीफॉल्टनुसार, CouchDB मध्ये, b-ट्री नोड्सचा आकार 1279 बाइट्स आहे, जो डिस्कवरील सेक्टर आकारापेक्षा खूपच लहान आहे, याचा अर्थ ट्री वाचणे आणि पुनर्संतुलित करणे या दोन्हीसाठी डिस्कवर अधिक भौतिक प्रवेश आवश्यक असेल. इष्टतम आकार मानकांशी संबंधित आहे प्रगत स्वरूप आणि 4 किलोबाइट आहे. ऑप्टिमाइझ करण्यासाठी आम्हाला पॅरामीटर सेट करणे आवश्यक आहे btree_chunk_size समान 4096 CouchDB कॉन्फिगरेशन फाइलमध्ये. BoltDB साठी अशा मॅन्युअल हस्तक्षेप आवश्यक नाही.

बॅकप्रेशर: बफर धोरण

परंतु बरेच संदेश असू शकतात. प्रणाली हाताळू शकते त्यापेक्षा जास्त, आकृतीमध्ये दर्शविल्या व्यतिरिक्त डझनभर इतर सेवांसह संसाधने सामायिक करणे - आणि हे सर्व मशीनवर देखील निर्दोषपणे कार्य केले पाहिजे ज्यावर Intellij Idea चालवणे अत्यंत त्रासदायक असेल.

संप्रेषण प्रणाली, उत्पादक आणि ग्राहक यांच्या वेगवेगळ्या क्षमतेची समस्या वेगवेगळ्या प्रकारे सोडवली जाते. आपण काय करू शकतो ते पाहूया.

सोडत आहे: आम्ही दावा करू शकतो की आम्ही T सेकंदात जास्तीत जास्त X व्यवहारांवर प्रक्रिया करण्यास सक्षम आहोत. या मर्यादेपेक्षा जास्त असलेल्या सर्व विनंत्या टाकून दिल्या आहेत. हे अगदी सोपे आहे, परंतु नंतर आपण UX बद्दल विसरू शकता.

नियंत्रित करत आहे: ग्राहकाकडे काही प्रकारचे इंटरफेस असणे आवश्यक आहे ज्याद्वारे, लोडवर अवलंबून, तो उत्पादकाचे TPS नियंत्रित करू शकतो. वाईट नाही, परंतु हे इंटरफेस लागू करण्यासाठी लोड तयार करणार्‍या क्लायंटच्या विकसकांवर बंधने लादते. हे आमच्यासाठी अस्वीकार्य आहे, कारण भविष्यात ब्लॉकचेन मोठ्या प्रमाणात अस्तित्वात असलेल्या प्रणालींमध्ये एकत्रित केले जाईल.

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

योजनेमध्ये दोन नवीन क्रिया जोडल्या गेल्या आहेत: (१) API ला विनंती आल्यानंतर, व्यवहार कॉल करण्यासाठी आवश्यक पॅरामीटर्ससह संदेश रांगेत ठेवला जातो आणि क्लायंटला संदेश प्राप्त होतो की व्यवहार स्वीकारला गेला आहे. प्रणाली, (1) बॅकएंड रांगेतून कॉन्फिगरेशनमध्ये निर्दिष्ट केलेल्या गतीने डेटा वाचतो; स्टेटस स्टोअरमध्ये व्यवहार सुरू करतो आणि डेटा अपडेट करतो.
आता तुम्ही फॉर्मेशन वेळ वाढवू शकता आणि वापरकर्त्यापासून विलंब लपवून तुम्हाला पाहिजे तितकी ब्लॉक करू शकता.

इतर साधने

चेनकोडबद्दल येथे काहीही सांगितले गेले नाही, कारण, नियमानुसार, त्यात ऑप्टिमाइझ करण्यासाठी काहीही नाही. चेनकोड शक्य तितके सोपे आणि सुरक्षित असले पाहिजे - इतकेच आवश्यक आहे. फ्रेमवर्क आम्हाला सहज आणि सुरक्षितपणे चेनकोड लिहिण्यास मदत करते CCKit S7 टेकलॅब आणि स्थिर विश्लेषक कडून ^CC पुनरुज्जीवित करा.

याव्यतिरिक्त, आमचा कार्यसंघ फॅब्रिकसह कार्य करणे सोपे आणि आनंददायक करण्यासाठी उपयुक्ततेचा एक संच विकसित करत आहे: ब्लॉकचेन एक्सप्लोरर, साठी उपयुक्तता स्वयंचलित नेटवर्क कॉन्फिगरेशन बदल (संस्था जोडणे/काढणे, RAFT नोड्स), यासाठी उपयुक्तता प्रमाणपत्रे रद्द करणे आणि ओळख काढून टाकणे. आपण योगदान देऊ इच्छित असल्यास, आपले स्वागत आहे.

निष्कर्ष

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

मुळात मला एवढेच शेअर करायचे होते. हे एखाद्याला त्यांच्या कामात मदत करत असल्यास मला आनंद होईल.

स्त्रोत: www.habr.com