सार्वजनिक चाचणी: इथरियमवरील गोपनीयता आणि स्केलेबिलिटीसाठी एक उपाय

ब्लॉकचेन एक अभिनव तंत्रज्ञान आहे जे मानवी जीवनातील अनेक क्षेत्रांमध्ये सुधारणा करण्याचे वचन देते. हे डिजिटल स्पेसमध्ये वास्तविक प्रक्रिया आणि उत्पादने हस्तांतरित करते, आर्थिक व्यवहारांची गती आणि विश्वासार्हता सुनिश्चित करते, त्यांची किंमत कमी करते आणि विकेंद्रित नेटवर्कमध्ये स्मार्ट कॉन्ट्रॅक्टचा वापर करून आधुनिक DAPP ऍप्लिकेशन्स तयार करण्यास देखील अनुमती देते.

ब्लॉकचेनचे अनेक फायदे आणि वैविध्यपूर्ण ऍप्लिकेशन्स पाहता, हे आश्चर्यकारक वाटू शकते की या आश्वासक तंत्रज्ञानाने अद्याप प्रत्येक उद्योगात प्रवेश केलेला नाही. समस्या अशी आहे की आधुनिक विकेंद्रित ब्लॉकचेनमध्ये स्केलेबिलिटीचा अभाव आहे. इथरियम प्रति सेकंद सुमारे 20 व्यवहारांवर प्रक्रिया करते, जे आजच्या गतिशील व्यवसायांच्या गरजा पूर्ण करण्यासाठी पुरेसे नाही. त्याच वेळी, ब्लॉकचेन तंत्रज्ञान वापरणाऱ्या कंपन्या हॅकिंग आणि नेटवर्क अयशस्वी होण्यापासून उच्च दर्जाच्या संरक्षणामुळे इथरियमचा त्याग करण्यास संकोच करतात.

ब्लॉकचेनमध्ये विकेंद्रीकरण, सुरक्षा आणि स्केलेबिलिटी सुनिश्चित करण्यासाठी, अशा प्रकारे स्केलेबिलिटी ट्रायलेम्मा, विकास संघ संधी Plasma Cash, एक स्मार्ट कॉन्ट्रॅक्ट आणि Node.js वर आधारित खाजगी नेटवर्क असलेली उपकंपनी साखळी तयार केली आहे, जी वेळोवेळी त्याची स्थिती रूट चेन (Ethereum) मध्ये हस्तांतरित करते.

प्लाझ्मा कॅश मधील प्रमुख प्रक्रिया

1. वापरकर्ता स्मार्ट कॉन्ट्रॅक्ट फंक्शनला 'डिपॉझिट' म्हणतो, त्यात त्याला प्लाझ्मा कॅश टोकनमध्ये जमा करायची असलेली ETH ची रक्कम देतो. स्मार्ट कॉन्ट्रॅक्ट फंक्शन टोकन तयार करते आणि त्याबद्दल इव्हेंट तयार करते.

2. स्मार्ट कॉन्ट्रॅक्ट इव्हेंटचे सदस्यत्व घेतलेल्या प्लाझ्मा कॅश नोड्सना डिपॉझिट तयार करण्याबद्दल आणि पूलमध्ये टोकन तयार करण्याबद्दल व्यवहार जोडण्याबद्दलचा कार्यक्रम प्राप्त होतो.

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

4. ब्लॉक सबमिशन इव्हेंट प्राप्त करणारे नोड्स ब्लॉकमध्ये जोडलेले व्यवहार लागू करण्यास सुरवात करतात.

5. काही क्षणी, टोकनचा मालक (किंवा नॉन-मालक) प्लाझ्मा कॅशमधून ते काढू इच्छितो. हे करण्यासाठी, तो 'startExit' फंक्शनला कॉल करतो, त्यात टोकनवरील शेवटच्या 2 व्यवहारांची माहिती देतो, जे टोकनचे मालक असल्याची पुष्टी करतात. स्मार्ट कॉन्ट्रॅक्ट, मर्कल हॅश वापरून, ब्लॉक्समधील व्यवहारांची उपस्थिती तपासते आणि पैसे काढण्यासाठी टोकन पाठवते, जे दोन आठवड्यांत होईल.

6. टोकन विथड्रॉवल ऑपरेशनचे उल्लंघन झाल्यास (टोकन पैसे काढण्याची प्रक्रिया सुरू झाल्यानंतर खर्च केले गेले किंवा पैसे काढण्यापूर्वी टोकन आधीच दुसऱ्याचे होते), टोकनचा मालक दोन आठवड्यांच्या आत पैसे काढण्याचे खंडन करू शकतो.

गोपनीयता दोन प्रकारे साध्य केली जाते

1. चाइल्ड चेनमध्ये जे व्यवहार व्युत्पन्न आणि फॉरवर्ड केले जातात त्याबद्दल रूट चेनला काहीही माहिती नसते. प्लाझ्मा कॅशमधून ETH कोणी जमा केले आणि काढले याबद्दलची माहिती सार्वजनिक राहते.

2. चाइल्ड चेन zk-SNARKs वापरून निनावी व्यवहारांना परवानगी देते.

तंत्रज्ञान स्टॅक

• नोडजेएस
• Redis
• इथरियम
• माती

चाचणी

प्लाझ्मा कॅश विकसित करताना, आम्ही सिस्टमच्या गतीची चाचणी घेतली आणि खालील परिणाम प्राप्त केले:

• प्रति सेकंद 35 पर्यंत व्यवहार पूलमध्ये जोडले जातात;
• 1 पर्यंत व्यवहार एका ब्लॉकमध्ये साठवले जाऊ शकतात.

खालील 3 सर्व्हरवर चाचण्या घेण्यात आल्या:

1. Intel Core i7-6700 Quad-core Skylake incl. NVMe SSD - 512 GB, 64 GB DDR4 रॅम
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 रॅम
1 प्लाझ्मा कॅश सबमिशन नोड वाढवला गेला.
3 प्रमाणित प्लाझ्मा कॅश नोड्स वाढवले ​​गेले.
प्लाझ्मा कॅश नेटवर्कमध्ये व्यवहार जोडण्यासाठी चाचणी सुरू करण्यात आली.

एकूण: खाजगी नेटवर्कमध्ये 10 प्लाझ्मा कॅश नोड्स.

चाचणी १

प्रति ब्लॉक 1 दशलक्ष व्यवहारांची मर्यादा आहे. म्हणून, 1 दशलक्ष व्यवहार 2 ब्लॉक्समध्ये येतात (कारण प्रणाली व्यवहाराचा भाग घेण्यास आणि ते पाठवले जात असताना सबमिट करण्यास व्यवस्थापित करते).

प्रारंभिक स्थिती: शेवटचा ब्लॉक #7; 1 दशलक्ष व्यवहार आणि टोकन डेटाबेसमध्ये संग्रहित आहेत.

00:00 - व्यवहार निर्मिती स्क्रिप्टची सुरुवात
01:37 - 1 दशलक्ष व्यवहार तयार झाले आणि नोडवर पाठवणे सुरू झाले
01:46 — सबमिट नोडने पूल आणि फॉर्म ब्लॉक #240 मधून 8k व्यवहार केले. आम्ही हे देखील पाहतो की 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 दशलक्ष व्यवहार आणि टोकन असतात

चाचणी १

प्रति ब्लॉक 350k मर्यादा आहे. परिणामी, आमच्याकडे 3 ब्लॉक आहेत.

प्रारंभिक स्थिती: शेवटचा ब्लॉक #9; 2 दशलक्ष व्यवहार आणि टोकन डेटाबेसमध्ये संग्रहित आहेत

00:00 — ट्रान्झॅक्शन जनरेशन स्क्रिप्ट आधीच लाँच झाली आहे
00:44 - 1 दशलक्ष व्यवहार तयार झाले आणि नोडवर पाठवणे सुरू झाले
00:56 — सबमिट नोडने पूल आणि फॉर्म ब्लॉक #320 मधून 10k व्यवहार केले. आम्ही हे देखील पाहतो की 320 सेकंदात 10k व्यवहार पूलमध्ये जोडले जातात
01:12 — ब्लॉक #10 वर स्वाक्षरी केली आहे आणि प्रमाणीकरणासाठी इतर नोड्सना पाठवले आहे
01:18 — डेमो स्क्रिप्टने काम पूर्ण केले, ज्याने 1 सेकंदात 34 दशलक्ष व्यवहार पाठवले
01:20 — ब्लॉक #10 प्रमाणित केला जातो आणि रूट चेनला पाठवला जातो
01:51 - सर्व नोड्सला रूट साखळीकडून माहिती मिळाली की ब्लॉक #10 जोडला गेला आणि 320k व्यवहार लागू करण्यास सुरुवात केली.
02:01 - ब्लॉक #320 मध्ये जोडलेल्या 10k व्यवहारांसाठी पूल साफ झाला आहे
02:15 — सबमिट नोडने पूल आणि फॉर्म ब्लॉक #350 मधून 11k व्यवहार केले
02:34 — ब्लॉक #11 वर स्वाक्षरी केली आहे आणि प्रमाणीकरणासाठी इतर नोड्सना पाठवले आहे
02:51 — ब्लॉक #11 प्रमाणित केला जातो आणि रूट चेनला पाठवला जातो
02:55 — शेवटच्या नोडने ब्लॉक #10 वरून व्यवहार पूर्ण केले
10:59 — ब्लॉक #9 च्या सबमिशनसह व्यवहाराला रूट चेनमध्ये बराच वेळ लागला, परंतु तो पूर्ण झाला आणि सर्व नोड्सना त्याबद्दल माहिती मिळाली आणि 350k व्यवहार करण्यास सुरुवात झाली.
11:05 - ब्लॉक #320 मध्ये जोडलेल्या 11k व्यवहारांसाठी पूल साफ झाला आहे
12:10 - सर्व नोड्समध्ये 1 दशलक्ष 670k व्यवहार आणि टोकन असतात
12:17 — सबमिट नोडने पूल आणि फॉर्म ब्लॉक #330 मधून 12k व्यवहार केले
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 ने पूल आणि फॉर्म ब्लॉक #330 (f85) मधून 21k व्यवहार केले. आम्ही हे देखील पाहतो की 350 सेकंदात 10k व्यवहार पूलमध्ये जोडले जातात
01:53 — 1 दशलक्ष व्यवहार तयार झाले आणि नोड #1 सबमिट करण्यासाठी पाठवणे सुरू झाले
01:50 — सबमिट नोड #3 ने पूल आणि फॉर्म ब्लॉक #330 (f85) मधून 21k व्यवहार केले. आम्ही हे देखील पाहतो की 350 सेकंदात 10k व्यवहार पूलमध्ये जोडले जातात
02:01 — सबमिट नोड #1 ने पूल आणि फॉर्म ब्लॉक #250 (85e) मधून 65k व्यवहार केले
02:06 — ब्लॉक #85 (f21) वर स्वाक्षरी केली आहे आणि प्रमाणीकरणासाठी इतर नोड्सना पाठवले आहे.
02:08 — सर्व्हर #3 ची डेमो स्क्रिप्ट, ज्याने 1 सेकंदात 30 दशलक्ष व्यवहार पाठवले, काम पूर्ण झाले
02:14 — ब्लॉक #85 (f21) प्रमाणित केले आहे आणि रूट चेनला पाठवले आहे.
02:19 — ब्लॉक #85 (65e) वर स्वाक्षरी केली आहे आणि प्रमाणीकरणासाठी इतर नोड्सवर पाठवले आहे.
02:22 — 1 दशलक्ष व्यवहार तयार झाले आणि नोड #2 सबमिट करण्यासाठी पाठवणे सुरू झाले
02:27 — ब्लॉक #85 (65e) प्रमाणित केले आणि रूट चेनला पाठवले
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 (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) वर स्वाक्षरी केली आहे आणि प्रमाणीकरणासाठी इतर नोड्सना पाठवले आहे.
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 (90a) वरून 50 व्यवहार केले.
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 प्रदान करणे. NodeJS नेटिव्हली सिंगल-थ्रेडेड असल्याने, हेवी मर्कल ट्री कॅल्क्युलेशन फंक्शनने ॲड ट्रान्झॅक्शन फंक्शन ब्लॉक केले. या समस्येचे निराकरण करण्यासाठी आम्ही दोन पर्याय पाहिले:

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 इंजिन चांगले ऑप्टिमाइझ केलेले असणे आवश्यक आहे.

आम्ही वर्गांद्वारे व्यवहार, टोकन आणि ब्लॉकसह काम केले. असे वर्ग तयार करताना, कामगिरी 2 पट कमी झाली, जे सूचित करते की OOP आमच्यासाठी योग्य नाही. मला सर्व काही पूर्णपणे कार्यात्मक दृष्टिकोनावर पुन्हा लिहावे लागले.

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

सुरुवातीला, आमच्या गरजा पूर्ण करणाऱ्या सर्वात उत्पादक उपायांपैकी एक म्हणून डेटा स्टोरेजसाठी रेडिसची निवड केली गेली: की-व्हॅल्यू स्टोरेज, हॅश टेबलसह कार्य करणे, सेट. आम्ही रेडिस-बेंचमार्क लाँच केले आणि 80 पाइपलाइनिंग मोडमध्ये प्रति सेकंद ~1k ऑपरेशन्स मिळाले.

उच्च कार्यक्षमतेसाठी, आम्ही Redis अधिक बारीकपणे ट्यून केले:

• युनिक्स सॉकेट कनेक्शन स्थापित केले आहे.
• आम्ही डिस्कवर स्टेट सेव्ह करणे अक्षम केले आहे (विश्वसनीयतेसाठी, तुम्ही प्रतिकृती सेट करू शकता आणि वेगळ्या रेडिसमध्ये डिस्कवर जतन करू शकता).

रेडिसमध्ये, पूल हे हॅश टेबल आहे कारण आम्हाला सर्व व्यवहार एका क्वेरीमध्ये पुनर्प्राप्त करण्यात आणि एक-एक करून व्यवहार हटवण्यास सक्षम असणे आवश्यक आहे. आम्ही नियमित सूची वापरण्याचा प्रयत्न केला, परंतु संपूर्ण सूची अनलोड करताना ती हळू होते.

मानक NodeJS वापरताना, Redis लायब्ररींनी प्रति सेकंद 18k व्यवहारांची कामगिरी साध्य केली. वेग 9 वेळा कमी झाला.

बेंचमार्कने आम्हाला शक्यता स्पष्टपणे 5 पट जास्त असल्याचे दर्शविल्यामुळे, आम्ही ऑप्टिमाइझ करणे सुरू केले. आम्ही लायब्ररी आयओरेडिसमध्ये बदलली आणि प्रति सेकंद 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(बफर, Protocol)` या नेहमीच्या कमांड्ससह आम्ही रेडिसमध्ये सेव्ह करण्यासाठी किंवा दुसऱ्या नोडवर फॉरवर्ड करण्यासाठी आणि पुनर्प्राप्त करण्यासाठी डेटा `बफर` मध्ये रूपांतरित करतो. डेटा परत.

आमच्याकडे सेवांमध्ये डेटा हस्तांतरित करण्यासाठी 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 — getTransaction;
• `पेलोड` — योग्य फंक्शनमध्ये पास करणे आवश्यक असलेला डेटा;
• `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;
• `आवृत्ती प्रोटोकॉल` — प्रोटोकॉल आवृत्ती, कारण नेटवर्कवर भिन्न आवृत्त्यांसह नोड्स उभे केले जाऊ शकतात आणि ते वेगळ्या पद्धतीने कार्य करू शकतात;
• `seq` - संदेश ओळखकर्ता;
• `countChunk` и `खंडसंख्या` मोठे संदेश विभाजित करण्यासाठी आवश्यक;
• `लांबी` и `पेलोड` लांबी आणि डेटा स्वतः.

आम्ही डेटा प्री-टाइप केल्याने, अंतिम सिस्टम इथरियमच्या `rlp' लायब्ररीपेक्षा खूप वेगवान आहे. दुर्दैवाने, आम्ही अद्याप त्यास नकार देऊ शकलो नाही, कारण स्मार्ट कराराला अंतिम रूप देणे आवश्यक आहे, जे आम्ही भविष्यात करण्याची योजना आखत आहोत.

जर आम्ही वेग गाठण्यात यशस्वी झालो 35 000 प्रति सेकंद व्यवहार, आम्ही त्यांना इष्टतम वेळेत प्रक्रिया करणे देखील आवश्यक आहे. अंदाजे ब्लॉक तयार होण्यासाठी 30 सेकंद लागतात, आम्हाला ब्लॉकमध्ये समाविष्ट करणे आवश्यक आहे 1 000 000 व्यवहार, ज्याचा अर्थ अधिक पाठवणे 100 MB डेटा.

सुरुवातीला, आम्ही नोड्स दरम्यान संवाद साधण्यासाठी `ethereumjs-devp2p` लायब्ररी वापरली, परंतु ती इतका डेटा हाताळू शकली नाही. परिणामी, आम्ही `ws` लायब्ररी वापरली आणि वेबसॉकेटद्वारे बायनरी डेटा पाठवणे कॉन्फिगर केले. अर्थात, मोठ्या डेटा पॅकेट्स पाठवताना देखील आम्हाला समस्या आल्या, परंतु आम्ही ते भागांमध्ये विभागले आणि आता या समस्या दूर झाल्या आहेत.

तसेच मर्कल ट्री बनवणे आणि हॅशची गणना करणे 1 000 000 बद्दल व्यवहार आवश्यक आहे 10 सतत मोजणीचे सेकंद. या वेळी, सर्व नोड्ससह कनेक्शन खंडित होण्यास व्यवस्थापित करते. ही गणना वेगळ्या धाग्यावर हलवण्याचे ठरले.

निष्कर्ष:

खरं तर, आमचे निष्कर्ष नवीन नाहीत, परंतु काही कारणास्तव अनेक तज्ञ विकसित करताना त्यांच्याबद्दल विसरतात.

• ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंगऐवजी फंक्शनल प्रोग्रामिंग वापरल्याने उत्पादकता सुधारते.
• उत्पादक नोडजेएस प्रणालीसाठी मोनोलिथ सेवा आर्किटेक्चरपेक्षा वाईट आहे.
• भारी गणनेसाठी `वर्कर_थ्रेड्स` वापरल्याने सिस्टीमची प्रतिसादक्षमता सुधारते, विशेषत: i/o ऑपरेशन्स हाताळताना.
• युनिक्स सॉकेट HTTP विनंत्यांपेक्षा अधिक स्थिर आणि वेगवान आहे.
• जर तुम्हाला नेटवर्कवर त्वरीत मोठा डेटा हस्तांतरित करायचा असेल तर, वेबसॉकेट वापरणे आणि बायनरी डेटा पाठवणे चांगले आहे, भागांमध्ये विभागले गेले आहे, ते न आल्यास अग्रेषित केले जाऊ शकतात आणि नंतर एका संदेशात एकत्र केले जाऊ शकतात.

आम्ही तुम्हाला भेट देण्यासाठी आमंत्रित करतो GitHub प्रकल्प: https://github.com/opporty-com/Plasma-Cash/tree/new-version

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

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