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

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

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

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

प्लाज्मा नगदमा प्रमुख प्रक्रियाहरू

1. प्रयोगकर्ताले स्मार्ट अनुबंध प्रकार्यलाई 'डिपोजिट' भन्छन्, यसमा उसले प्लाज्मा नगद टोकनमा जम्मा गर्न चाहेको ETH को रकम पास गर्दछ। स्मार्ट अनुबंध प्रकार्यले टोकन सिर्जना गर्दछ र यसको बारेमा घटना उत्पन्न गर्दछ।

2. प्लाज्मा नगद नोडहरू स्मार्ट अनुबंध घटनाहरूमा सदस्यता लिने एक निक्षेप सिर्जना गर्ने र पूलमा टोकन सिर्जना गर्ने बारे एउटा लेनदेन थप्ने घटना प्राप्त गर्दछ।

3. आवधिक रूपमा, विशेष प्लाज्मा नगद नोडहरू पूलबाट सबै लेनदेनहरू (1 मिलियन सम्म) लिन्छन् र तिनीहरूबाट ब्लक बनाउँछन्, मर्कल रूख र तदनुसार, ह्यास गणना गर्नुहोस्। यो ब्लक प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइन्छ। नोडहरूले मर्कल ह्यास वैध छ कि छैन र लेनदेनहरू वैध छन् कि छैनन् भनेर जाँच गर्दछ (उदाहरणका लागि, टोकन पठाउने व्यक्ति यसको मालिक हो कि होइन)। ब्लक प्रमाणित गरिसकेपछि, नोडले स्मार्ट सम्झौताको `सबमिटब्लक` प्रकार्यलाई कल गर्छ, जसले ब्लक नम्बर र मर्कल ह्यासलाई एज चेनमा बचत गर्छ। स्मार्ट अनुबंधले ब्लकको सफल थपको संकेत गर्ने घटना उत्पन्न गर्दछ। लेनदेन पूलबाट हटाइन्छ।

4. ब्लक सबमिशन घटना प्राप्त गर्ने नोडहरूले ब्लकमा थपिएका लेनदेनहरू लागू गर्न थाल्छन्।

5. केहि बिन्दुमा, टोकनको मालिक (वा गैर-मालिक) ले यसलाई प्लाज्मा नगदबाट फिर्ता लिन चाहन्छ। यो गर्नको लागि, उसले 'startExit' प्रकार्यलाई कल गर्छ, यसमा टोकनमा अन्तिम २ लेनदेनको बारेमा जानकारी पास गर्दछ, जसले टोकनको मालिक उहाँ नै हो भनी पुष्टि गर्छ। स्मार्ट अनुबंध, मर्कल ह्यास प्रयोग गरेर, ब्लकहरूमा लेनदेनको उपस्थिति जाँच गर्दछ र निकासीको लागि टोकन पठाउँदछ, जुन दुई हप्तामा हुनेछ।

6. यदि टोकन फिर्ता लिने कार्य उल्लङ्घनको साथ भयो (टोकन फिर्ता लिने प्रक्रिया सुरु भए पछि खर्च भएको थियो वा टोकन पहिले नै निकासी अघि अरू कसैको थियो), टोकनको मालिकले दुई हप्ता भित्र निकासीलाई अस्वीकार गर्न सक्छ।

गोपनीयता दुई तरिकामा प्राप्त गरिन्छ

1. मूल चेनलाई चाइल्ड चेन भित्र उत्पन्न र फर्वार्ड गरिएका लेनदेनको बारेमा केही थाहा हुँदैन। प्लाज्मा नगदबाट ETH कसले जम्मा गर्यो र निकाल्यो भन्ने जानकारी सार्वजनिक रहन्छ।

2. चाइल्ड चेनले zk-SNARKs प्रयोग गरेर बेनामी लेनदेनहरूलाई अनुमति दिन्छ।

टेक्नोलोजी स्ट्याक

• नोड जेएस
• Redis
• Ethereum
• सिल्ड

परीक्षण गर्दै

प्लाज्मा नगद विकास गर्दा, हामीले प्रणालीको गति परीक्षण गर्‍यौं र निम्न परिणामहरू प्राप्त गर्‍यौं:

• प्रति सेकेन्ड 35 लेनदेन पूल मा थपिएको छ;
• 1 लेनदेनहरू ब्लकमा भण्डारण गर्न सकिन्छ।

निम्न 3 सर्भरहरूमा परीक्षणहरू गरियो:

1. Intel Core i7-6700 Quad-Core Skylake incl। NVMe SSD - 512 GB, 64 GB DDR4 RAM
3 प्रमाणीकरण प्लाज्मा नगद नोडहरू उठाइयो।

2. AMD Ryzen 7 1700X Octa-core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 RAM
Ropsten testnet ETH नोड उठाइएको थियो।
3 प्रमाणीकरण प्लाज्मा नगद नोडहरू उठाइयो।

3. Intel Core i9-9900K अक्टा-कोर सहित। NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 प्लाज्मा नगद सबमिशन नोड उठाइएको थियो।
3 प्रमाणीकरण प्लाज्मा नगद नोडहरू उठाइयो।
प्लाज्मा नगद नेटवर्कमा लेनदेन थप्न परीक्षण सुरु गरिएको थियो।

कुल: निजी नेटवर्कमा 10 प्लाज्मा नगद नोडहरू।

परीक्षण १

प्रति ब्लक १० लाख कारोबारको सीमा छ। तसर्थ, 1 मिलियन लेनदेनहरू 1 ब्लकहरूमा पर्छन् (किनकि प्रणालीले लेनदेनको भाग लिन र पठाइरहँदा पेश गर्न प्रबन्ध गर्दछ)।

प्रारम्भिक अवस्था: अन्तिम ब्लक #7; 1 मिलियन लेनदेन र टोकनहरू डाटाबेसमा भण्डारण गरिएका छन्।

00:00 - लेनदेन जेनरेशन लिपिको सुरुवात
01:37 - 1 मिलियन लेनदेनहरू सिर्जना गरियो र नोडमा पठाउन सुरु भयो
01:46 — सबमिट नोडले पूल र फारम ब्लक #240 बाट 8k लेनदेन लियो। हामी यो पनि देख्छौं कि 320k लेनदेनहरू 10 सेकेन्डमा पूलमा थपिएका छन्
01:58 — ब्लक #8 हस्ताक्षर गरी प्रमाणीकरणको लागि पठाइएको छ
०२:०३ — ब्लक #८ प्रमाणित गरिएको छ र स्मार्ट सम्झौताको `सबमिटब्लक` प्रकार्यलाई मर्कल ह्यास र ब्लक नम्बरसँग बोलाइन्छ।
०२:१० — डेमो स्क्रिप्टले काम गरिसकेको छ, जसले ३२ सेकेन्डमा १ लाख कारोबार पठाएको छ
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 मिलियन लेनदेन र टोकनहरू छन्

परीक्षण १

प्रति ब्लक 350k को सीमा छ। नतिजाको रूपमा, हामीसँग 3 ब्लकहरू छन्।

प्रारम्भिक अवस्था: अन्तिम ब्लक #9; 2 मिलियन लेनदेन र टोकनहरू डाटाबेसमा भण्डारण गरिएका छन्

00:00 — लेनदेन जेनरेशन लिपि सुरु भइसकेको छ
00:44 - 1 मिलियन लेनदेनहरू सिर्जना गरियो र नोडमा पठाउन सुरु भयो
00:56 — सबमिट नोडले पूल र फारम ब्लक #320 बाट 10k लेनदेन लियो। हामी यो पनि देख्छौं कि 320k लेनदेनहरू 10 सेकेन्डमा पूलमा थपिएका छन्
01:12 — ब्लक #10 हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ
०२:१० — डेमो स्क्रिप्टले काम गरिसकेको छ, जसले ३२ सेकेन्डमा १ लाख कारोबार पठाएको छ
01:20 — ब्लक # 10 प्रमाणित गरी रूट चेनमा पठाइन्छ
01:51 - सबै नोडहरूले रूट चेनबाट जानकारी प्राप्त गरे जुन ब्लक # 10 थपिएको थियो र 320k लेनदेनहरू लागू गर्न सुरु भयो।
02:01 - पूलले 320k लेनदेनको लागि खाली गरेको छ जुन ब्लक #10 मा थपिएको थियो
02:15 — सबमिट नोडले पूल र फारम ब्लक #350 बाट 11k लेनदेन लियो
02:34 — ब्लक #11 हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ
02:51 — ब्लक #11 मान्य हुन्छ र रूट चेनमा पठाइन्छ
02:55 — अन्तिम नोडले ब्लक #10 बाट कारोबार पूरा गर्यो
10:59 — ब्लक # 9 को सबमिशनको साथ लेनदेन रूट चेनमा धेरै लामो समय लाग्यो, तर यो पूरा भयो र सबै नोडहरूले यसको बारेमा जानकारी प्राप्त गरे र 350k लेनदेन गर्न थाले।
11:05 - पूलले 320k लेनदेनको लागि खाली गरेको छ जुन ब्लक #11 मा थपिएको थियो
12:10 - सबै नोडहरूमा 1 मिलियन 670k लेनदेन र टोकनहरू छन्
12:17 — सबमिट नोडले पूल र फारम ब्लक #330 बाट 12k लेनदेन लियो
12:32 — ब्लक #12 हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ
12:39 — ब्लक # 12 प्रमाणित गरी रूट चेनमा पठाइन्छ
13:44 - सबै नोडहरूले रूट चेनबाट जानकारी प्राप्त गर्‍यो जुन ब्लक #12 थपिएको थियो र 330k लेनदेनहरू लागू गर्न सुरु भयो।
14:50 - सबै नोडहरूमा 2 मिलियन लेनदेन र टोकनहरू छन्

परीक्षण १

पहिलो र दोस्रो सर्भरहरूमा, एउटा प्रमाणीकरण नोडलाई पेश गर्ने नोडद्वारा प्रतिस्थापन गरिएको थियो।

प्रारम्भिक अवस्था: अन्तिम ब्लक #84; ० लेनदेन र टोकनहरू डाटाबेसमा बचत गरियो

00:00 — 3 स्क्रिप्टहरू सुरु गरिएको छ जसले प्रत्येक 1 मिलियन लेनदेनहरू उत्पन्न गर्दछ र पठाउँछ।
01:38 — 1 मिलियन लेनदेनहरू सिर्जना गरियो र नोड # 3 पेश गर्न पठाउन सुरु भयो
01:50 — सबमिट गर्नुहोस् नोड # 3 ले पूल र फारम ब्लक # 330 (f85) बाट 21k लेनदेन लिएको छ। हामी यो पनि देख्छौं कि 350k लेनदेनहरू 10 सेकेन्डमा पूलमा थपिएका छन्
01:53 — 1 मिलियन लेनदेनहरू सिर्जना गरियो र नोड # 1 पेश गर्न पठाउन सुरु भयो
01:50 — सबमिट गर्नुहोस् नोड # 3 ले पूल र फारम ब्लक # 330 (f85) बाट 21k लेनदेन लिएको छ। हामी यो पनि देख्छौं कि 350k लेनदेनहरू 10 सेकेन्डमा पूलमा थपिएका छन्
०२:०१ — सबमिट गर्नुहोस् नोड #१ ले पोखरीबाट २५० हजार लेनदेन लियो र ब्लक #८५ (६५e) फारम बनाउनुहोस्।
02:06 — ब्लक # 85 (f21) हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ।
०२:०८ — सर्भर #३ को डेमो स्क्रिप्ट, जसले ३० सेकेन्डमा १० लाख लेनदेनहरू पठायो, काम सकियो
02:14 — ब्लक #85 (f21) प्रमाणित गरी रूट चेनमा पठाइयो
02:19 — ब्लक # 85 (65e) हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ।
02:22 — 1 मिलियन लेनदेनहरू सिर्जना गरियो र नोड # 2 पेश गर्न पठाउन सुरु भयो
02:27 — block #85 (65e) प्रमाणित गरी रूट चेनमा पठाइयो
02:29 — सबमिट गर्नुहोस् नोड #2 ले पूलबाट 111855 लेनदेन लियो र ब्लक #85 (256) बनाउँछ।
०२:३६ — ब्लक #८५ (२५६) हस्ताक्षर गरी प्रमाणीकरणका लागि अन्य नोडहरूमा पठाइयो
०२:०८ — सर्भर #३ को डेमो स्क्रिप्ट, जसले ३० सेकेन्डमा १० लाख लेनदेनहरू पठायो, काम सकियो
०२:३८ — ब्लक #८५ (२५६) प्रमाणित गरी रूट चेनमा पठाइयो
०३:०८ — सर्भर #२ स्क्रिप्टले काम गरिसकेको छ, जसले ४७ सेकेन्डमा १ लाख कारोबार पठाएको छ
03:38 - सबै नोडहरूले रूट चेनबाट जानकारी प्राप्त गर्यो जसले #85 (f21), #86(65e), #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 (50a) बनाउँछ, नोड #3 सबमिट गर्नुहोस् बाट 670k लेनदेन भयो। पूल र फारम ब्लक #88 (d3b)
04:44 — ब्लक #88 (d3b) हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ।
०२:३६ — ब्लक #८५ (२५६) हस्ताक्षर गरी प्रमाणीकरणका लागि अन्य नोडहरूमा पठाइयो
05:11 — ब्लक # 88 (50a) हस्ताक्षर गरिएको छ र प्रमाणीकरणको लागि अन्य नोडहरूमा पठाइएको छ।
05:11 — ब्लक # 85 (d3b) प्रमाणित गरी रूट चेनमा पठाइयो
०२:३८ — ब्लक #८५ (२५६) प्रमाणित गरी रूट चेनमा पठाइयो
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. एकल-थ्रेडेड मोडमा काम गर्दा लामो गणनाहरू हुँदा नोडहरू बीचको जडान तोड्छ (उदाहरणका लागि, मर्कल रूख निर्माण गर्दै र यसको ह्यास गणना गर्दै)।

हामीले यो सबैसँग कसरी व्यवहार गर्यौं?

प्लाज्मा नगद नोडको पहिलो संस्करण एक प्रकारको संयोजन थियो जसले एकै समयमा सबै काम गर्न सक्छ: लेनदेनहरू स्वीकार गर्नुहोस्, ब्लकहरू पेश गर्नुहोस् र प्रमाणीकरण गर्नुहोस्, र डाटा पहुँच गर्नको लागि API प्रदान गर्नुहोस्। नोडजेएस मूल रूपमा एकल-थ्रेडेड भएकोले, भारी मर्कल ट्री गणना प्रकार्यले लेनदेन कार्यलाई रोकेको छ। हामीले यो समस्या समाधान गर्न दुई विकल्प देख्यौं:

1. धेरै NodeJS प्रक्रियाहरू लन्च गर्नुहोस्, जसमध्ये प्रत्येकले विशिष्ट कार्यहरू गर्दछ।

2. Worker_threads प्रयोग गर्नुहोस् र थ्रेडहरूमा कोडको अंशको कार्यान्वयन सार्नुहोस्।

नतिजाको रूपमा, हामीले एकै समयमा दुबै विकल्पहरू प्रयोग गर्‍यौं: हामीले तार्किक रूपमा एउटा नोडलाई 3 भागहरूमा विभाजित गर्यौं जुन छुट्टै काम गर्न सक्छ, तर एकै समयमा सिंक्रोनस रूपमा।

1. सबमिशन नोड, जसले पूलमा लेनदेन स्वीकार गर्छ र ब्लकहरू सिर्जना गर्दछ।

2. एक प्रमाणीकरण नोड जसले नोडहरूको वैधता जाँच गर्दछ।

3. API नोड - डाटा पहुँच गर्न API प्रदान गर्दछ।

यस अवस्थामा, तपाइँ cli प्रयोग गरेर युनिक्स सकेट मार्फत प्रत्येक नोडमा जडान गर्न सक्नुहुन्छ।

हामीले भारी कार्यहरू, जस्तै मर्कल रूख गणना गर्ने, छुट्टै थ्रेडमा सारियो।

यसरी, हामीले सबै प्लाज्मा नगद प्रकार्यहरू एकै साथ र विफलता बिना सामान्य सञ्चालन हासिल गरेका छौं।

प्रणाली कार्यात्मक भएपछि, हामीले गति परीक्षण गर्न थाल्यौं र दुर्भाग्यवश, असंतोषजनक परिणामहरू प्राप्त गर्‍यौं: प्रति सेकेन्ड 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 इन्जिन यी सञ्चालनहरूको लागि राम्रोसँग अनुकूलित हुनुपर्छ।

हामीले कक्षाहरू मार्फत लेनदेन, टोकन र ब्लकहरूसँग काम गर्यौं। त्यस्ता कक्षाहरू सिर्जना गर्दा, कार्यसम्पादन २ गुणाले घट्यो, जसले OOP हाम्रो लागि उपयुक्त छैन भनी सङ्केत गर्छ। मैले विशुद्ध कार्यात्मक दृष्टिकोणमा सबै कुरा पुन: लेख्नुपर्‍यो।

डाटाबेसमा रेकर्डिङ

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

उच्च प्रदर्शनको लागि, हामीले रेडिसलाई अझ राम्रोसँग ट्युन गर्यौं:

• युनिक्स सकेट जडान स्थापित गरिएको छ।
• हामीले डिस्कमा राज्य बचत गर्न असक्षम पार्यौं (विश्वसनीयताको लागि, तपाईंले प्रतिकृति सेटअप गर्न सक्नुहुन्छ र डिस्कमा छुट्टै Redis मा बचत गर्न सक्नुहुन्छ)।

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

मानक NodeJS प्रयोग गर्दा, Redis पुस्तकालयहरूले प्रति सेकेन्ड 18k लेनदेनको प्रदर्शन हासिल गरे। गति 9 पटक घट्यो।

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

धेरै कारणहरूका लागि, जसलाई हामी तल वर्णन गर्नेछौं, हामी `Buffer` प्रयोग गरेर डेटासँग काम गर्छौं र, यदि तपाईंले यसलाई लेख्नु अघि पाठ (`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(block, Protocol).slice();` र `BD.decode(buffer, Protocol)` सँग हामी डाटालाई Redis मा बचत गर्न वा अर्को नोडमा फर्वार्ड गर्न र पुनः प्राप्त गर्नको लागि `Buffer` मा रूपान्तरण गर्छौं। डाटा फिर्ता।

सेवाहरू बीच डाटा स्थानान्तरण गर्न हामीसँग २ बाइनरी प्रोटोकलहरू पनि छन्:

- युनिक्स सकेट मार्फत प्लाज्मा नोडसँग अन्तर्क्रियाको लागि प्रोटोकल

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

कहाँ:

• 'प्रकार' - गर्नु पर्ने कार्य, उदाहरणका लागि, १ — पठाउने लेनदेन, २ — गेट लेनदेन;
• 'पेलोड' - उपयुक्त प्रकार्यमा पास गर्न आवश्यक डेटा;
• '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)
  }
  ```

कहाँ:

• 'कोड' — सन्देश कोड, उदाहरणका लागि ६ — PREPARE_NEW_BLOCK, 6 — BLOCK_VALID, 7 — BLOCK_COMMIT;
• `संस्करण प्रोटोकल` - प्रोटोकल संस्करण, किनकि विभिन्न संस्करणहरूसँग नोडहरू नेटवर्कमा उठाउन सकिन्छ र तिनीहरूले फरक काम गर्न सक्छन्;
• 'seq' - सन्देश पहिचानकर्ता;
• 'countChunk' и `chunkNumber` ठूला सन्देशहरू विभाजन गर्न आवश्यक छ;
• 'लम्बाइ' и 'पेलोड' लम्बाइ र डेटा आफैं।

हामीले डेटा पूर्व-टाइप गरिसकेपछि, अन्तिम प्रणाली Ethereum को `rlp` पुस्तकालय भन्दा धेरै छिटो छ। दुर्भाग्यवश, हामीले यसलाई अस्वीकार गर्न सकेका छैनौं, किनकि स्मार्ट सम्झौतालाई अन्तिम रूप दिन आवश्यक छ, जुन हामी भविष्यमा गर्ने योजना गर्छौं।

यदि हामीले गतिमा पुग्न सफल भयौं 35 000 प्रति सेकेन्ड लेनदेन, हामीले तिनीहरूलाई इष्टतम समयमा प्रशोधन गर्न आवश्यक छ। अनुमानित ब्लक गठन समयले 30 सेकेन्ड लिन्छ, हामीले ब्लकमा समावेश गर्न आवश्यक छ 1 000 000 लेनदेन, जसको अर्थ थप पठाउनु हो 100 MB डाटा।

सुरुमा, हामीले नोडहरू बीच सञ्चार गर्न `ethereumjs-devp2p` पुस्तकालय प्रयोग गर्यौं, तर यसले यति धेरै डाटा ह्यान्डल गर्न सकेन। नतिजाको रूपमा, हामीले `ws` पुस्तकालय प्रयोग गर्यौं र वेबसकेट मार्फत बाइनरी डेटा पठाउने कन्फिगर गर्यौं। निस्सन्देह, हामीले ठूला डाटा प्याकेटहरू पठाउँदा समस्याहरू पनि सामना गर्यौं, तर हामीले तिनीहरूलाई टुक्राहरूमा विभाजित गर्यौं र अब यी समस्याहरू हटेका छन्।

मर्कल रूख पनि बनाउँदै र ह्यास गणना गर्दै 1 000 000 लेनदेनको बारेमा आवश्यक छ 10 लगातार गणना को सेकेन्ड। यस समयमा, सबै नोडहरूसँग जडान तोड्न प्रबन्ध गर्दछ। यो गणनालाई छुट्टै थ्रेडमा सार्ने निर्णय गरियो।

निष्कर्ष:

वास्तवमा, हाम्रा खोजहरू नयाँ छैनन्, तर केही कारणका लागि धेरै विशेषज्ञहरूले विकास गर्दा तिनीहरूको बारेमा बिर्सन्छन्।

• वस्तु-उन्मुख प्रोग्रामिङको सट्टा कार्यात्मक प्रोग्रामिङ प्रयोग गर्दा उत्पादकता सुधार हुन्छ।
• मोनोलिथ उत्पादक NodeJS प्रणालीको लागि सेवा वास्तुकला भन्दा खराब छ।
• भारी गणनाको लागि `worker_threads` प्रयोग गर्नाले प्रणालीको उत्तरदायित्वमा सुधार हुन्छ, विशेष गरी i/o सञ्चालनहरूसँग व्यवहार गर्दा।
• युनिक्स सकेट HTTP अनुरोधहरू भन्दा बढी स्थिर र छिटो छ।
• यदि तपाईंलाई नेटवर्कमा ठूला डाटा द्रुत रूपमा स्थानान्तरण गर्न आवश्यक छ भने, वेबसकेटहरू प्रयोग गर्नु र बाइनरी डाटा पठाउनु राम्रो हुन्छ, टुक्राहरूमा विभाजन गरी, जुन नपुगेको खण्डमा फर्वार्ड गर्न सकिन्छ, र त्यसपछि एक सन्देशमा मिलाएर।

हामी तपाईंलाई भ्रमण गर्न आमन्त्रित गर्दछौं GitHub परियोजना: https://github.com/opporty-com/Plasma-Cash/tree/new-version

लेख सह-लेखन गरिएको थियो अलेक्जेन्डर नाशिवान, वरिष्ठ विकासकर्ता Clever Solution Inc.

स्रोत: www.habr.com