सार्वजनिक परीक्षण: एथेरियम में गोपनीयता और मापनीयता के लिए समाधान

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

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

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

प्लाज्मा कैश में प्रमुख प्रक्रियाएं

1. उपयोगकर्ता स्मार्ट अनुबंध `जमा` के कार्य को कॉल करता है, इसमें ईटीएच में राशि को स्थानांतरित करता है, जिसे वह प्लाज्मा कैश टोकन में डालना चाहता है। स्मार्ट कॉन्ट्रैक्ट फ़ंक्शन एक टोकन बनाता है और इसके बारे में एक घटना उत्पन्न करता है।

2. स्मार्ट अनुबंध की घटनाओं के लिए सब्सक्राइब किए गए प्लाज़्मा कैश नोड्स जमा के निर्माण के बारे में एक घटना प्राप्त करते हैं और पूल में टोकन के निर्माण के बारे में एक लेनदेन जोड़ते हैं।

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

4. वे नोड्स जो ब्लॉक को जमा करने के बारे में घटना प्राप्त करते हैं, ब्लॉक में जोड़े गए लेनदेन को लागू करना शुरू करते हैं।

5. किसी समय, टोकन का स्वामी (या गैर-मालिक) इसे प्लाज्मा कैश से निकालना चाहता है। ऐसा करने के लिए, वह `startExit` फ़ंक्शन को कॉल करता है, इसमें टोकन पर पिछले 2 लेनदेन के बारे में जानकारी देता है, जो पुष्टि करता है कि वह टोकन का मालिक है। मर्कले हैश का उपयोग करते हुए स्मार्ट अनुबंध, ब्लॉकों में लेनदेन की जांच करता है और आउटपुट को एक टोकन भेजता है, जो दो सप्ताह में होगा।

6. यदि टोकन निकासी ऑपरेशन उल्लंघन के साथ हुआ है (निकासी प्रक्रिया की शुरुआत के बाद टोकन खर्च किया गया था या टोकन वापसी से पहले ही एक अजनबी था), टोकन का मालिक दो सप्ताह के भीतर निकासी का खंडन कर सकता है।

गोपनीयता दो तरीकों से हासिल की जाती है।

1. बाल श्रृंखला के अंदर बनने वाले और अग्रेषित किए जाने वाले लेनदेन के बारे में रूट चेन को कुछ भी पता नहीं होता है। प्लाज्मा कैश से ईटीएच को किसने शुरू किया और किसने निकाला इसकी जानकारी बनी हुई है।

2. चाइल्ड चेन आपको zk-SNARKs का उपयोग करके बेनामी लेनदेन को व्यवस्थित करने की अनुमति देता है।

टेक्नोलॉजिकल स्टैक

• NodeJS
• Redis
• Etherium
• soild

परीक्षण

प्लाज्मा कैश विकसित करते समय, हमने सिस्टम की गति का परीक्षण किया और निम्नलिखित परिणाम प्राप्त किए:

• प्रति सेकंड 35,000 तक लेनदेन पूल में जोड़े जाते हैं;
• 1,000,000 तक लेनदेन ब्लॉक में संग्रहीत किया जा सकता है।

निम्नलिखित 3 सर्वरों पर टेस्ट आयोजित किए गए:

1. Intel Core i7-6700 Quad-Core Skylake incl। NVMe SSD - 512 जीबी, 64 जीबी डीडीआर 4 रैम
3 मान्य प्लाज्मा कैश नोड उठाए गए थे।

2. एएमडी राइजन 7 1700X ऑक्टा-कोर "समिट रिज" (ज़ेन), एसएटीए एसएसडी - 500 जीबी, 64 जीबी डीडीआर 4 रैम
रोपस्टेन टेस्टनेट ईटीएच नोड उठाया गया था।
3 मान्य प्लाज्मा कैश नोड उठाए गए थे।

3. इंटेल कोर i9-9900K ऑक्टा-कोर इंक। एनवीएमई एसएसडी - 1 टीबी, 64 जीबी डीडीआर 4 रैम
1 सबमिट करें प्लाज्मा कैश नोड उठाया गया था।
3 मान्य प्लाज्मा कैश नोड उठाए गए थे।
प्लाज्मा कैश नेटवर्क में लेनदेन जोड़ने के लिए एक परीक्षण शुरू किया गया था।

कुल: एक निजी नेटवर्क में 10 प्लाज्मा कैश नोड्स।

परीक्षण 1

प्रति ब्लॉक 1 मिलियन लेनदेन की सीमा है। इसलिए, 1 मिलियन लेनदेन 2 ब्लॉकों में आते हैं (क्योंकि सिस्टम लेनदेन का हिस्सा लेने के लिए प्रबंधन करता है और भेजे जाने के समय जमा होता है)।


प्रारंभिक स्थिति: अंतिम ब्लॉक # 7; 1 मिलियन लेनदेन और टोकन डेटाबेस में संग्रहीत हैं।

00:00 - ट्रांजेक्शन जनरेशन स्क्रिप्ट शुरू करें
01:37 - 1 मिलियन लेनदेन बनाए गए और नोड को भेजना शुरू हुआ
01:46 - सबमिट नोड ने पूल से 240k लेनदेन किया और # 8 ब्लॉक बनाए। हम यह भी देखते हैं कि 10 सेकंड में 320k लेनदेन पूल में जुड़ जाते हैं
01:58 - ब्लॉक # 8 हस्ताक्षरित है और सत्यापन के लिए भेजा गया है
02:03 - ब्लॉक # 8 को वेरिफाई किया गया है और मर्कल हैश और ब्लॉक नंबर के साथ स्मार्ट कॉन्ट्रैक्ट के `सबमिटब्लॉक` को कहा जाता है
02:10 - डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया, जिसने 32 सेकंड में 1 मिलियन लेनदेन भेजे
02:33 - नोड्स को जानकारी प्राप्त होने लगी कि ब्लॉक # 8 को रूट चेन में जोड़ा गया, और 240k ट्रांजेक्शन करने लगे
02:40 - 240k लेनदेन को पूल से हटा दिया गया, जो पहले से ही ब्लॉक # 8 में हैं
02:56 - सबमिट नोड ने पूल से शेष 760k लेनदेन लिया और मर्कल हैश और साइन ब्लॉक # 9 की गणना करना शुरू किया
03:20 - सभी नोड्स में 1mln 240k ट्रांजेक्शन और टोकन हैं
03:35 - ब्लॉक # 9 पर हस्ताक्षर किए गए हैं और अन्य नोड्स को सत्यापन के लिए भेजा गया है
03:41 - नेटवर्क एरर हुआ है
04:40 - टाइमआउट से, ब्लॉक # 9 के सत्यापन का इंतजार बंद हो गया है
04:54 - जमा नोड ने पूल से शेष 760k लेनदेन किया और मर्कल हैश और साइन ब्लॉक की गणना करना शुरू किया
05:32 - ब्लॉक # 9 पर हस्ताक्षर किए गए हैं और अन्य नोड्स को सत्यापन के लिए भेजा गया है
05:53 - ब्लॉक # 9 को वेरिफाई किया गया है और रूट चेन को भेजा गया है
06:17 - नोड्स को जानकारी मिलनी शुरू हुई कि ब्लॉक # 9 को रूट चेन में जोड़ा गया और 760k ट्रांजेक्शन करने लगे
06:47 - पूल ने लेनदेन को मंजूरी दे दी है जो ब्लॉक # 9 में है
09:06 - सभी नोड्स में 2 मिलियन लेनदेन और टोकन हैं

परीक्षण २

प्रति ब्लॉक 350k की सीमा है। नतीजतन, हमारे पास 3 ब्लॉक हैं।


प्रारंभिक स्थिति: अंतिम ब्लॉक # 9; 2 मिलियन लेनदेन और टोकन डेटाबेस में संग्रहीत

00:00 - ट्रांजेक्शन जनरेशन स्क्रिप्ट पहले से चल रही है
00:44 - 1 मिलियन लेनदेन बनाए गए और नोड को भेजना शुरू हुआ
00:56 - सबमिट नोड ने पूल से 320k लेनदेन किया और # 10 ब्लॉक बनाए। हम यह भी देखते हैं कि 10 सेकंड में 320k लेनदेन पूल में जुड़ जाते हैं
01:12 - ब्लॉक # 10 को हस्ताक्षरित किया गया और सत्यापन के लिए अन्य नोड्स के लिए भेजा गया
01:18 - डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया, जिसने 34 सेकंड में 1 मिलियन लेनदेन भेजे
01:20 - ब्लॉक # 10 को मान्य किया गया है और रूट चेन को भेजा गया है
01:51 - सभी नोड्स को रूट चेन से जानकारी मिली कि ब्लॉक # 10 को जोड़ा गया है, और वे 320k लेनदेन को लागू करना शुरू कर रहे हैं
02:01 - पूल को 320k लेन-देन के लिए साफ़ किया गया था जिसे # 10 ब्लॉक करने के लिए जोड़ा गया था
02:15 - सबमिट नोड ने पूल से 350k ट्रांजेक्शन लिया और फॉर्म # 11 को ब्लॉक किया
02:34 - ब्लॉक # 11 को हस्ताक्षरित किया गया और सत्यापन के लिए अन्य नोड्स को भेजा गया
02:51 - ब्लॉक # 11 को मान्य किया गया है और रूट चेन को भेजा गया है
02:55 - अंतिम नोड ने ब्लॉक # 10 से लेनदेन निष्पादित किया
10:59 - रूट चेन में एक बहुत लंबे समय के लिए एक ब्लॉक # 9 सबमिशन के साथ एक लेनदेन निष्पादित किया गया था, लेकिन यह पूरा हो गया था और सभी नोड्स को इस बारे में जानकारी मिली और 350k लेनदेन को निष्पादित करना शुरू कर दिया
11:05 - 320k लेनदेन के लिए पूल को मंजूरी दे दी गई थी जिसे # 11 ब्लॉक किया गया था
12:10 - सभी नोड्स में 1 मिलियन 670k लेनदेन और टोकन हैं
12:17 - सबमिट नोड ने पूल से 330k लेनदेन किया और # 12 ब्लॉक बनाए
12:32 - ब्लॉक # 12 को हस्ताक्षरित किया गया और सत्यापन के लिए अन्य नोड्स के लिए भेजा गया
12:39 - ब्लॉक # 12 को मान्य किया गया है और रूट चेन को भेजा गया है
13:44 - सभी नोड्स को रूट चेन से जानकारी मिली कि ब्लॉक # 12 जोड़ा गया है और 330k लेनदेन को लागू करना शुरू कर रहा है
14:50 - सभी नोड्स में 2 मिलियन लेनदेन और टोकन हैं

परीक्षण ३

पहले और दूसरे सर्वर में, एक मान्य नोड को सबमिट नोड के साथ बदल दिया गया था।


प्रारंभिक स्थिति: अंतिम ब्लॉक # 84; 0 लेनदेन और टोकन डेटाबेस में संग्रहीत हैं

00:00 - 3 स्क्रिप्ट लॉन्च किए गए हैं जो 1 मिलियन लेनदेन उत्पन्न करते हैं और भेजते हैं
01:38 - 1 मिलियन ट्रांजेक्शन बनाए गए और नोड # 3 भेजने के लिए शुरू हुआ
01:50 - # नोड प्रस्तुत करें # 3 ने पूल से 330k लेनदेन किया और # 85 (f21) ब्लॉक बनाए। हम यह भी देखते हैं कि पूल में 10 सेकंड में 350k लेनदेन जोड़ा जाता है
01:53 - नोड 1 जमा करने के लिए 1 मिलियन लेनदेन बनाए गए और भेजना शुरू हुआ
01:50 - # नोड प्रस्तुत करें # 3 ने पूल से 330k लेनदेन किया और # 85 (f21) ब्लॉक बनाए। हम यह भी देखते हैं कि पूल में 10 सेकंड में 350k लेनदेन जोड़ा जाता है
02:01 - नोड # 1 जमा करें और पूल से 250k ट्रांजेक्शन लिया और # 85 (65e) ब्लॉक बनाए।
02:06 - ब्लॉक # 85 (f21) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
02:08 - सर्वर # 3 डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया है, जिसने 30 सेकंड में 1ml लेनदेन भेजा है
02:14 - ब्लॉक # 85 (f21) को वेरिफाई किया गया है और रूट चेन को भेजा गया है
02:19 - ब्लॉक # 85 (65e) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
02:22 - 1 मिलियन लेनदेन बनाए गए और नोड # 2 भेजने के लिए शुरू हुआ
02:27 - ब्लॉक # 85 (65e) को मान्य किया गया है और रूट चेन को भेजा गया है
02:29 - नोड 11 जमा करें, पूल 111855 से लिया गया और फॉर्म # 85 (256) को ब्लॉक करता है।
02:36 - ब्लॉक # 85 (256) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
02:36 - सर्वर # 1 की डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया, जिसने 42.5 सेकंड में 1ml लेनदेन भेजा
02:38 - ब्लॉक # 85 (256) को वेरिफाई किया गया है और रूट चेन को भेजा गया है
03:08 - सर्वर स्क्रिप्ट # 2, जिसने 47 सेकंड में 1 मिलियन लेनदेन भेजे, काम करना समाप्त कर दिया
03:38 - सभी नोड्स को रूट चेन से जानकारी मिली कि ब्लॉक # 85 (f21), # 86 (65e), # 87 (256) जोड़े गए और 330k, 250k, 111855 लेनदेन को लागू करना शुरू कर रहे हैं।
03:49 - पूल को 330k, 250k, 111855 लेनदेन पर क्लीयर किया गया, जो ब्लॉक # 85 (f21), # 86 (65e), # 87 (256) में जोड़े गए थे
03:59 - पूल 888145 लेन-देन से लिया गया नोड # 1 जमा करें और फॉर्म # 88 (214) ब्लॉक करें, नोड # 2 जमा करें 750k लेनदेन से लिया और फॉर्म # 88 (50 ए) ब्लॉक करें, नोड # 3 जमा करें 6kk लेनदेन और फॉर्म ब्लॉक # 88 (d3b)
04:44 - ब्लॉक # 88 (d3b) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
04:58 - ब्लॉक # 88 (214) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
05:11 - ब्लॉक # 88 (50a) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
05:11 - ब्लॉक # 85 (d3b) को वेरिफाई किया गया है और रूट चेन को भेजा गया है
05:36 - ब्लॉक # 85 (214) को मान्य किया गया है और रूट चेन को भेजा गया है
05:43 - सभी नोड्स ने रूट चेन से जानकारी प्राप्त की जो # 88 (d3b) को ब्लॉक करती है, # 89 (214) जोड़े गए और 670k, 750k लेनदेन को लागू करना शुरू किया
06:50 - एक वियोग के कारण, ब्लॉक # 85 (50a) को मान्य नहीं किया गया था
06:55 - नोड # 2 जमा करें पूल से 888145 ट्रांजेक्शन लिया और फॉर्म # 90 (50a) ब्लॉक करें
08:14 - ब्लॉक # 90 (50a) पर हस्ताक्षर किए गए हैं और सत्यापन के लिए अन्य नोड्स को भेजे गए हैं
09:04 - ब्लॉक # 90 (50a) को मान्य किया गया है और रूट चेन को भेजा गया है
11:23 - सभी नोड्स को रूट चेन से जानकारी मिली कि ब्लॉक # 90 (50a) जोड़ा गया था, और 888145 लेनदेन लागू होने लगे। इसी समय, सर्वर # 3 ने ब्लॉक # 88 (d3b), # 89 (214) से लंबे समय तक लेनदेन किया है
12:11 - सभी पूल खाली हैं
13:41 - सभी सर्वर नोड्स # 3 में 3 मिलियन ट्रांजेक्शन और टोकन हैं
14:35 - सभी सर्वर नोड्स # 1 में 3 मिलियन लेनदेन और टोकन हैं
19:24 - सभी सर्वर नोड्स # 2 में 3 मिलियन लेनदेन और टोकन हैं

बाधाओं

प्लाज्मा कैश के विकास के दौरान, हमें निम्नलिखित समस्याओं का सामना करना पड़ा, जिन्हें हमने धीरे-धीरे हल किया और हल कर रहे हैं:

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

2. यह तुरंत स्पष्ट नहीं था कि बड़ी संख्या में लेनदेन कैसे भेजा जाए और साथ ही साथ डेटा ट्रांसफर की लागत को कम से कम किया जाए।

3. यह स्पष्ट नहीं था कि उच्च परिणाम प्राप्त करने के लिए डेटा को कैसे और कहाँ संग्रहीत किया जाए।

4. यह स्पष्ट नहीं था कि नोड्स के बीच नेटवर्क को कैसे व्यवस्थित किया जाए, क्योंकि 1 मिलियन लेनदेन वाले ब्लॉक का आकार लगभग 100 एमबी है।

5. एकल-थ्रेडेड मोड में काम करने से नोड्स के बीच संबंध टूट जाता है जब लंबी गणना होती है (उदाहरण के लिए, एक मर्कल ट्री का निर्माण और उसके हैश की गणना)।

हमने यह सब कैसे निपटा?

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

1. कई NodeJS प्रक्रियाओं को चलाएं, जिनमें से प्रत्येक कुछ कार्य करता है।

2. कार्यकर्ता_थ्रेड्स का उपयोग करें और कोड के निष्पादन को थ्रेड्स में डालें।

परिणामस्वरूप, हमने एक ही समय में दोनों विकल्पों का उपयोग किया: तार्किक रूप से एक नोड को 3 भागों में विभाजित किया, जो अलग-अलग काम कर सकते हैं, लेकिन एक ही समय में समान रूप से

1. एक नोड प्रस्तुत करें जो पूल में लेनदेन स्वीकार करता है और ब्लॉक बनाता है।

2. वैध नोड जो नोड्स की वैधता की पुष्टि करता है।

3. नोड एपीआई - डेटा तक पहुँचने के लिए एक एपीआई प्रदान करता है।

उसी समय, आप cli का उपयोग करके एक यूनिक्स सॉकेट के माध्यम से प्रत्येक नोड से कनेक्ट कर सकते हैं।

भारी परिचालन, जैसे कि मर्कल ट्री की गणना, हमने एक अलग स्ट्रीम में किया।

इस प्रकार, हमने सभी प्लाज्मा कैश फ़ंक्शंस के सामान्य संचालन को एक साथ और विफलताओं के बिना प्राप्त किया।

जैसे ही सिस्टम ने कार्यात्मक रूप से काम किया, हमने गति का परीक्षण करना शुरू कर दिया और दुर्भाग्य से, असंतोषजनक परिणाम मिले: एक ब्लॉक में प्रति सेकंड 5,000 लेनदेन और 50,000 तक लेनदेन। मुझे यह पता लगाना था कि क्या गलत तरीके से लागू किया गया था।

शुरू करने के लिए, हमने सिस्टम की चरम क्षमता का पता लगाने के लिए प्लाज्मा कैश के साथ संचार के तंत्र का परीक्षण शुरू किया। इससे पहले हमने लिखा था कि प्लाज्मा कैश नोड एक यूनिक्स सॉकेट इंटरफ़ेस प्रदान करता है। यह मूल रूप से शाब्दिक था। json ऑब्जेक्ट को 'JSON.parse ()' और 'JSON.stringify ()' का उपयोग करके भेजा गया था।

```json { "action": "sendTransaction", "payload":{ "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0", "prevBlock": 41, "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445", "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4", "type": "pay", "data": "", "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c" } } ``` 

हमने ऐसी वस्तुओं के हस्तांतरण की गति को मापा और ~ 130k प्रति सेकंड प्राप्त किया। उन्होंने मानक कार्यों को जसन के साथ बदलने की कोशिश की, लेकिन प्रदर्शन में सुधार नहीं हुआ। इन कार्यों के लिए अच्छी तरह से अनुकूलित V8 इंजन होना चाहिए।

वर्गों के माध्यम से लेनदेन, टोकन के साथ काम किया गया। ऐसी कक्षाएं बनाते समय, प्रदर्शन 2 बार फिसल गया, जो इंगित करता है: OOP हमारे लिए उपयुक्त नहीं है। मुझे विशुद्ध रूप से कार्यात्मक दृष्टिकोण पर सब कुछ फिर से लिखना पड़ा।

डेटाबेस में लिखें

प्रारंभ में, Redis को सबसे अधिक उत्पादक समाधानों में से एक के रूप में डेटा स्टोरेज के लिए चुना गया था, जो हमारी आवश्यकता को पूरा करता है: हैश टेबल के साथ की-वैल्यू स्टोरेज, और कई। हमने रेडिस-बेंचमार्क लॉन्च किया और ~ 1 पाईपलाइनिंग मोड में प्रति सेकंड ~ 80k संचालन मिला।

उच्च प्रदर्शन के लिए, हमने रेडिस को अधिक सूक्ष्मता से ट्यून किया:

• एक यूनिक्स सॉकेट कनेक्शन स्थापित किया।
• डिस्क के लिए राज्य की बचत को अक्षम करें (विश्वसनीयता के लिए, आप प्रतिकृति को कॉन्फ़िगर कर सकते हैं और पहले से ही डिस्क को अलग रेडिस में सहेज सकते हैं)।

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

मानक NodeJS पुस्तकालय का उपयोग करते हुए, Redis पुस्तकालयों ने प्रति सेकंड प्रदर्शन में 18k लेनदेन हासिल किया। 9 बार स्पीड गिरी।

चूंकि बेंचमार्क ने हमें संभावनाओं को स्पष्ट रूप से 5 गुना अधिक दिखाया, इसलिए उन्होंने अनुकूलन करना शुरू कर दिया। हमने लाइब्रेरी को आइओर्डिस में बदल दिया और प्रति सेकंड 25k का प्रदर्शन किया। हमने 'hset' कमांड का उपयोग करके एक-एक करके लेनदेन जोड़ा। इस प्रकार, हमने रेडिस में कई अनुरोध उत्पन्न किए। बंडलों में लेनदेन को मर्ज करने और उन्हें एक hmset कमांड के साथ भेजने का विचार था। परिणाम 32k प्रति सेकंड है।

कई कारणों से, जिन्हें नीचे वर्णित किया गया है, हम `बफ़र` का उपयोग कर डेटा के साथ काम करते हैं, और जैसा कि यह निकला, यदि आप इसे पाठ में अनुवाद करते हैं (` बफर.टोस्ट्रिंग ('हेक्स') `) लिखने से पहले, आप अतिरिक्त प्रदर्शन प्राप्त कर सकते हैं। इस प्रकार, गति को बढ़ाकर 35k प्रति सेकंड कर दिया गया। फिलहाल, हमने आगे अनुकूलन को निलंबित करने का फैसला किया।

हमें बाइनरी प्रोटोकॉल पर स्विच करना पड़ा क्योंकि:

1. प्रणाली अक्सर हैश, हस्ताक्षर आदि की गणना करती है, और इसके लिए `बफर में डेटा की आवश्यकता होती है।

2. जब सेवाओं के बीच स्थानांतरण होता है, तो बाइनरी डेटा का वजन पाठ से कम होता है। उदाहरण के लिए, 1 मिलियन लेनदेन के साथ ब्लॉक भेजते समय, पाठ में डेटा 300 मेगाबाइट से अधिक हो सकता है।

3. निरंतर डेटा रूपांतरण प्रदर्शन को प्रभावित करता है।

इसलिए, हमने अपने आधार के रूप में डेटा को संग्रहीत करने और प्रसारित करने के लिए अपने स्वयं के द्विआधारी प्रोटोकॉल के रूप में लिया, अद्भुत बाइनरी-डेटा लाइब्रेरी के आधार पर विकसित किया।

परिणामस्वरूप, हमारे पास निम्नलिखित डेटा संरचनाएँ हैं:

- लेन-देन

  ```json { prevHash: BD.types.buffer(20), prevBlock: BD.types.uint24le, tokenId: BD.types.string(null), type: BD.types.uint8, newOwner: BD.types.buffer(20), dataLength: BD.types.uint24le, data: BD.types.buffer(({current}) => current.dataLength), signature: BD.types.buffer(65), hash: BD.types.buffer(32), blockNumber: BD.types.uint24le, timestamp: BD.types.uint48le, } ``` 

- टोकन

  ```json { id: BD.types.string(null), owner: BD.types.buffer(20), block: BD.types.uint24le, amount: BD.types.string(null), } ``` 

- ब्लॉक

  ```json { number: BD.types.uint24le, merkleRootHash: BD.types.buffer(32), signature: BD.types.buffer(65), countTx: BD.types.uint24le, transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx), timestamp: BD.types.uint48le, } ``` 

सामान्य आदेशों द्वारा `BD.encode (ब्लॉक, प्रोटोकॉल) .slice ();` और `BD.decode (बफर, प्रोटोकॉल)`, हम रेडिस को बचाने या किसी अन्य नोड को भेजने और डेटा वापस प्राप्त करने के लिए डेटा को `बफ़र` में परिवर्तित करते हैं।

हमारे पास सेवाओं के बीच डेटा स्थानांतरित करने के लिए 2 बाइनरी प्रोटोकॉल भी हैं:

- यूनिक्स सॉकेट के माध्यम से प्लाज्मा नोड के साथ बातचीत के लिए प्रोटोकॉल

  ```json { type: BD.types.uint8, messageId: BD.types.uint24le, error: BD.types.uint8, length: BD.types.uint24le, payload: BD.types.buffer(({node}) => node.length) } ``` 

जहां:

• `टाइप` - प्रदर्शन की जाने वाली कार्रवाई, उदाहरण के लिए, 1 - सेंडट्रांसलेशन, 2 - गेटट्रांसक्शन;
• `पेलोड` - संबंधित फ़ंक्शन में स्थानांतरित किया जाने वाला डेटा;
• `messageId` - संदेश आईडी ताकि प्रतिक्रिया की पहचान की जा सके।

- नोड्स के बीच बातचीत का प्रोटोकॉल

  ```json { code: BD.types.uint8, versionProtocol: BD.types.uint24le, seq: BD.types.uint8, countChunk: BD.types.uint24le, chunkNumber: BD.types.uint24le, length: BD.types.uint24le, payload: BD.types.buffer(({node}) => node.length) } ``` 

जहां:

• `कोड` - संदेश कोड, उदाहरण के लिए 6 - PREPARE_NEW_BLOCK, 7 - BLOCK_VALID, 8 - BLOCK_COMMIT;
• `versionProtocol` - प्रोटोकॉल संस्करण, चूंकि विभिन्न संस्करणों के नोड्स को नेटवर्क पर उठाया जा सकता है और वे अलग-अलग तरीकों से काम कर सकते हैं;
• `seq` - संदेश पहचानकर्ता;
• `countChunk` और` chunkNumber` बड़े संदेशों को विभाजित करने के लिए आवश्यक हैं ;
• `लंबाई` और` पेलोड` लंबाई और डेटा ही।

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

यदि हम प्रति सेकंड 35,000 लेनदेन की गति प्राप्त करने में कामयाब रहे, तो हमें उन्हें इष्टतम समय में संसाधित करने की भी आवश्यकता है। चूँकि ब्लॉक के अनुमानित गठन के समय में 30 सेकंड लगते हैं, इसलिए हमें ब्लॉक में 1,000,000 लेनदेन को शामिल करना होगा, जिसका मतलब है कि 100 एमबी से अधिक डेटा भेजना।

प्रारंभ में, हमने नोड्स को संप्रेषित करने के लिए `Ethereumjs-devp2p` लाइब्रेरी का उपयोग किया, लेकिन यह बहुत अधिक डेटा के साथ सामना नहीं कर सका। परिणामस्वरूप, हमने `ws` लाइब्रेरी का उपयोग किया और वेबसैट पर बाइनरी डेटा ट्रांसफर सेट किया। बेशक, हमें बड़े डेटा पैकेट भेजते समय भी समस्याओं का सामना करना पड़ा, लेकिन हमने उन्हें विखंडू में विभाजित किया और अब ऐसी कोई समस्या नहीं है।

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

निष्कर्ष:

वास्तव में, हमारे निष्कर्ष नए नहीं हैं, लेकिन किसी कारण से, कई विशेषज्ञ विकास के दौरान उनके बारे में भूल जाते हैं।

• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के बजाय कार्यात्मक प्रोग्रामिंग का उपयोग प्रदर्शन को बढ़ाता है।
• एक मोनोलिथ NodeJS पर एक उत्पादन प्रणाली के लिए एक सेवा वास्तुकला से भी बदतर है।
• भारी कंप्यूटिंग के लिए `कार्यकर्ता_थ्रेड्स 'का उपयोग करना प्रणाली की जवाबदेही में सुधार करता है, खासकर जब मैं / ओ संचालन के साथ काम कर रहा हूं।
• यूनिक्स सॉकेट http अनुरोधों की तुलना में अधिक स्थिर और तेज है।
• यदि आपको नेटवर्क पर बड़े डेटा को जल्दी से स्थानांतरित करने की आवश्यकता है, तो वेबस्कैट का उपयोग करना बेहतर है और बाइनरी डेटा भेजना, विखंडू में टूट गया, जिसे आगे नहीं पहुंचाया जा सकता है, और फिर एक संदेश में विलय हो जाता है।

हम आपको GitHub प्रोजेक्ट पर जाने के लिए आमंत्रित करते हैं: https://github.com/opporty-com/Plasma-Cash/tree/new-version

इस लेख का सह-लेखन अलेक्जेंडर नाशिवन ने किया था , जो कि क्लेवर सॉल्यूशन इंक के वरिष्ठ डेवलपर हैं ।