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

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

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

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

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

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

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

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

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

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

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

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

1. रूट चेन को चाइल्ड चेन के भीतर बनने और भेजे जाने वाले लेनदेन के बारे में कुछ नहीं पता होता है। प्लाज़्मा कैश में ETH किसने जमा किया और निकाला, इसकी जानकारी सार्वजनिक रहती है।

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

प्रौद्योगिकी ढेर

• NodeJS
• Redis
• Etherium
• गंदा

परीक्षण

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

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

परीक्षण निम्नलिखित 3 सर्वरों पर किए गए:

1. इंटेल कोर i7-6700 क्वाड-कोर स्काईलेक शामिल। एनवीएमई एसएसडी - 512 जीबी, 64 जीबी डीडीआर4 रैम
3 मान्य प्लाज्मा कैश नोड बढ़ाए गए हैं।

2. AMD Ryzen 7 1700X ऑक्टा-कोर "समिट रिज" (ज़ेन), SATA SSD - 500 जीबी, 64 जीबी DDR4 रैम
एक रोपस्टेन टेस्टनेट ईटीएच नोड उठाया गया है।
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 बनाया। हम यह भी देखते हैं कि 320 सेकंड में 10k लेनदेन पूल में जोड़े जाते हैं
01:58 - ब्लॉक #8 पर हस्ताक्षर किए गए और सत्यापन के लिए भेजा गया
02:03 - ब्लॉक #8 मान्य है और स्मार्ट अनुबंध के `सबमिटब्लॉक` फ़ंक्शन को मर्कल हैश और ब्लॉक नंबर के साथ कॉल किया जाता है
02:10 - डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया, जिसने 1 सेकंड में 32 मिलियन लेनदेन भेजे
02:33 - नोड्स को जानकारी मिलनी शुरू हुई कि ब्लॉक #8 को रूट चेन में जोड़ा गया है, और 240k लेनदेन निष्पादित करना शुरू कर दिया है
02:40 - 240k लेनदेन पूल से हटा दिए गए, जो पहले से ही ब्लॉक # 8 में हैं
02:56 - सबमिट नोड ने पूल से शेष 760k लेनदेन लिया और मर्कल हैश और साइनिंग ब्लॉक #9 की गणना शुरू कर दी
03:20 - सभी नोड्स में 1 मिलियन 240k लेनदेन और टोकन हैं
03:35 - ब्लॉक #9 पर हस्ताक्षर किया गया है और अन्य नोड्स पर सत्यापन के लिए भेजा गया है
03:41 - एक नेटवर्क त्रुटि उत्पन्न हुई है
04:40 - समय समाप्त होने के कारण ब्लॉक #9 सत्यापन की प्रतीक्षा रुक गई
04:54 - सबमिट नोड ने पूल से शेष 760k लेनदेन लिया और मर्कल हैश और साइनिंग ब्लॉक #9 की गणना शुरू कर दी
05:32 - ब्लॉक #9 पर हस्ताक्षर किया गया है और अन्य नोड्स पर सत्यापन के लिए भेजा गया है
05:53 - ब्लॉक #9 को मान्य किया गया है और रूट चेन पर भेजा गया है
06:17 - नोड्स को जानकारी प्राप्त होनी शुरू हुई कि ब्लॉक #9 को रूट श्रृंखला में जोड़ा गया है और 760k लेनदेन निष्पादित करना शुरू कर दिया है
06:47 - पूल को उन लेनदेन से साफ़ कर दिया गया जो ब्लॉक #9 में हैं
09:06 - सभी नोड्स में 2 मिलियन लेनदेन और टोकन हैं

टेस्ट 2

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

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

00:00 - ट्रांजेक्शन जनरेशन स्क्रिप्ट पहले से ही चल रही है
00:44 - 1 मिलियन लेनदेन बनाए गए हैं और नोड को भेजना शुरू हो गया है
00:56 - सबमिट नोड ने पूल से 320k लेनदेन लिया और ब्लॉक #10 बनाया। हम यह भी देखते हैं कि 320 सेकंड में 10k लेनदेन पूल में जोड़े जाते हैं
01:12 - ब्लॉक #10 पर हस्ताक्षर किया गया है और सत्यापन के लिए अन्य नोड्स को भेजा गया है
01:18 - डेमो स्क्रिप्ट ने काम करना समाप्त कर दिया, जिसने 1 सेकंड में 34 मिलियन लेनदेन भेजे
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 मिलियन लेनदेन और टोकन हैं

टेस्ट 3

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

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

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

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

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

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

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

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

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

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

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

डेटाबेस में रिकॉर्डिंग

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

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

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

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

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

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

कई कारणों से, जिनका हम नीचे वर्णन करेंगे, हम `बफ़र` का उपयोग करके डेटा के साथ काम करते हैं और, जैसा कि यह निकला, अगर हम इसे लिखने से पहले टेक्स्ट (`buffer.toString('hex')`) में अनुवाद करते हैं, तो हम अतिरिक्त प्राप्त कर सकते हैं प्रदर्शन। इस प्रकार, गति बढ़कर 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;
• `वर्जनप्रोटोकॉल` - प्रोटोकॉल संस्करण, चूंकि विभिन्न संस्करणों वाले नोड्स को नेटवर्क में उठाया जा सकता है और वे अलग-अलग तरीके से काम कर सकते हैं;
• `सीक` - संदेश पहचानकर्ता;
• `काउंटचंक` и `चंकनंबर` बड़े संदेशों को विभाजित करने के लिए आवश्यक;
• `लंबाई` и `पेलोड` लंबाई और डेटा स्वयं।

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

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

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

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

निष्कर्ष:

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

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

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

लेख के साथ सह-लेखक था अलेक्जेंडर नाशिवान, वरिष्ठ डेवलपर चतुर समाधान इंक..

स्रोत: www.habr.com