საჯარო ტესტი: გამოსავალი კონფიდენციალურობისა და მასშტაბურობისთვის Ethereum-ზე

ბლოკჩინი არის ინოვაციური ტექნოლოგია, რომელიც გვპირდება გააუმჯობესოს ადამიანის ცხოვრების მრავალი სფერო. ის გადასცემს რეალურ პროცესებსა და პროდუქტებს ციფრულ სივრცეში, უზრუნველყოფს ფინანსური ტრანზაქციების სისწრაფესა და საიმედოობას, ამცირებს მათ ღირებულებას და ასევე საშუალებას გაძლევთ შექმნათ თანამედროვე DAPP აპლიკაციები ჭკვიანი კონტრაქტების გამოყენებით დეცენტრალიზებულ ქსელებში.

ბლოკჩეინის მრავალი უპირატესობისა და მრავალფეროვანი აპლიკაციის გათვალისწინებით, შეიძლება გასაკვირი ჩანდეს, რომ ამ პერსპექტიულ ტექნოლოგიას ჯერ არ მიუღწევია ყველა ინდუსტრიაში. პრობლემა ის არის, რომ თანამედროვე დეცენტრალიზებულ ბლოკჩეინებს არ აქვთ მასშტაბურობა. Ethereum ამუშავებს დაახლოებით 20 ტრანზაქციას წამში, რაც საკმარისი არ არის დღევანდელი დინამიური ბიზნესის მოთხოვნილებების დასაკმაყოფილებლად. ამავდროულად, კომპანიები, რომლებიც იყენებენ blockchain ტექნოლოგიას, ყოყმანობენ Ethereum-ის მიტოვებაზე, ჰაკერებისგან და ქსელის უკმარისობისგან მისი მაღალი ხარისხის დაცვის გამო.

ბლოკჩეინში დეცენტრალიზაციის, უსაფრთხოებისა და მასშტაბურობის უზრუნველსაყოფად, რითაც გადაჭრის მასშტაბურობის ტრილემა, განვითარების გუნდი შესაძლებლობა შექმნა Plasma Cash, შვილობილი ჯაჭვი, რომელიც შედგება ჭკვიანი კონტრაქტისა და Node.js-ზე დაფუძნებული კერძო ქსელისგან, რომელიც პერიოდულად გადასცემს თავის მდგომარეობას root ჯაჭვში (Ethereum).

ძირითადი პროცესები Plasma Cash-ში

1. მომხმარებელი უწოდებს სმარტ კონტრაქტის ფუნქციას `დეპოზიტს` და მასში გადააქვს ETH-ის ოდენობა, რომელიც მას სურს ჩარიცხოს Plasma Cash ტოკენში. ჭკვიანი კონტრაქტის ფუნქცია ქმნის ჟეტონს და წარმოქმნის მოვლენას ამის შესახებ.

2. გონიერი კონტრაქტის ღონისძიებებზე გამოწერილი Plasma Cash კვანძები იღებენ ღონისძიებას დეპოზიტის შექმნის შესახებ და ამატებენ ტრანზაქციას აუზში ტოკენის შექმნის შესახებ.

3. პერიოდულად, სპეციალური Plasma Cash კვანძები იღებენ ყველა ტრანზაქციას აუზიდან (1 მილიონამდე) და ქმნიან მათგან ბლოკს, გამოთვლიან Merkle-ს ხეს და, შესაბამისად, ჰაშის. ეს ბლოკი გადამოწმებისთვის იგზავნება სხვა კვანძებში. კვანძები ამოწმებენ არის თუ არა Merkle-ის ჰეში ვალიდური და მართებულია თუ არა ტრანზაქციები (მაგალითად, არის თუ არა ტოკენის გამგზავნი მისი მფლობელი). ბლოკის გადამოწმების შემდეგ, კვანძი იძახებს სმარტ კონტრაქტის `submitBlock` ფუნქციას, რომელიც ინახავს ბლოკის ნომერს და Merkle ჰეშს კიდეების ჯაჭვში. ჭკვიანი კონტრაქტი წარმოქმნის მოვლენას, რომელიც მიუთითებს ბლოკის წარმატებულ დამატებაზე. ტრანზაქციები ამოღებულია აუზიდან.

4. კვანძები, რომლებიც იღებენ ბლოკის წარდგენის მოვლენას, იწყებენ ბლოკში დამატებული ტრანზაქციის გამოყენებას.

5. რაღაც მომენტში, ტოკენის მფლობელს (ან არამფლობელს) სურს მისი ამოღება Plasma Cash-იდან. ამისათვის ის უწოდებს `startExit` ფუნქციას, მასში გადასცემს ინფორმაციას ტოკენზე ბოლო 2 ტრანზაქციის შესახებ, რომელიც ადასტურებს, რომ ის არის ტოკენის მფლობელი. ჭკვიანი კონტრაქტი, Merkle-ის ჰეშის გამოყენებით, ამოწმებს ტრანზაქციების არსებობას ბლოკებში და აგზავნის ტოკენს გასატანად, რაც მოხდება ორ კვირაში.

6. თუ ჟეტონის გამოტანის ოპერაცია მოხდა დარღვევებით (ჟეტონი დაიხარჯა გატანის პროცედურის დაწყების შემდეგ ან ჟეტონი უკვე სხვისი იყო გატანამდე), ჟეტონის მფლობელს შეუძლია უარყოს გატანა ორი კვირის განმავლობაში.

კონფიდენციალურობა მიიღწევა ორი გზით

1. root ჯაჭვმა არაფერი იცის იმ ტრანზაქციების შესახებ, რომლებიც წარმოიქმნება და გადაგზავნილია ბავშვის ჯაჭვის ფარგლებში. ინფორმაცია იმის შესახებ, თუ ვინ შეიტანა და ამოიღო ETH Plasma Cash-დან, რჩება საჯარო.

2. ბავშვის ჯაჭვი ანონიმური ტრანზაქციების საშუალებას იძლევა zk-SNARK-ების გამოყენებით.

ტექნოლოგიის დასტა

• NodeJS
• Redis
• ეთერიუმი
• ნიადაგი

ტესტირება

Plasma Cash-ის შემუშავებისას ჩვენ გამოვცადეთ სისტემის სიჩქარე და მივიღეთ შემდეგი შედეგები:

• აუზს ემატება 35-მდე ტრანზაქცია წამში;
• ბლოკში შესაძლებელია 1-მდე ტრანზაქციის შენახვა.

ტესტები ჩატარდა შემდეგ 3 სერვერზე:

1. Intel Core i7-6700 Quad-Core Skylake ჩათვლით. NVMe SSD – 512 GB, 64 GB DDR4 ოპერატიული მეხსიერება
გაიზარდა 3 ვალიდირებული Plasma Cash კვანძი.

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, 64 GB DDR4 ოპერატიული მეხსიერება
Ropsten ტესტის ქსელის ETH კვანძი გაიზარდა.
გაიზარდა 3 ვალიდირებული Plasma Cash კვანძი.

3. Intel Core i9-9900K Octa-Core ჩათვლით. NVMe SSD – 1 ტბ, 64 GB DDR4 ოპერატიული მეხსიერება
1 Plasma Cash წარდგენის კვანძი გაიზარდა.
გაიზარდა 3 ვალიდირებული Plasma Cash კვანძი.
დაიწყო ტესტი Plasma Cash ქსელში ტრანზაქციების დასამატებლად.

სულ: 10 Plasma Cash კვანძი კერძო ქსელში.

ტესტი 1

ბლოკზე 1 მილიონი ტრანზაქციის ლიმიტია. აქედან გამომდინარე, 1 მილიონი ტრანზაქცია იყოფა 2 ბლოკად (რადგან სისტემა ახერხებს ტრანზაქციების ნაწილის მიღებას და გაგზავნის დროს).

საწყისი მდგომარეობა: ბოლო ბლოკი #7; მონაცემთა ბაზაში ინახება 1 მილიონი ტრანზაქცია და ტოკენი.

00:00 — ტრანზაქციის გენერირების სკრიპტის დაწყება
01:37 - შეიქმნა 1 მილიონი ტრანზაქცია და დაიწყო გაგზავნა კვანძში
01:46 — გაგზავნეთ კვანძმა აიღო 240 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #8. ჩვენ ასევე ვხედავთ, რომ 320 ათასი ტრანზაქცია ემატება აუზს 10 წამში
01:58 — ბლოკი #8 ხელმოწერილია და იგზავნება დასადასტურებლად
02:03 — ბლოკი #8 დამოწმებულია და სმარტ კონტრაქტის `submitBlock` ფუნქცია გამოიძახება Merkle ჰეშისა და ბლოკის ნომრით
02:10 — დაასრულა დემო სკრიპტმა, რომელმაც 1 წამში 32 მილიონი ტრანზაქცია გაგზავნა
02:33 - კვანძებმა დაიწყეს ინფორმაციის მიღება, რომ ბლოკი #8 დაემატა root ჯაჭვს და დაიწყეს 240 ათასი ტრანზაქციის შესრულება.
02:40 - აუზიდან ამოიღეს 240 ათასი ტრანზაქცია, რომლებიც უკვე #8 ბლოკშია.
02:56 — გაგზავნის კვანძმა აიღო დარჩენილი 760 ათასი ტრანზაქცია ფონდიდან და დაიწყო Merkle-ის ჰეშის გამოთვლა და #9 ბლოკის ხელმოწერა.
03:20 - ყველა კვანძი შეიცავს 1 მილიონ 240 ათასი ტრანზაქციას და ტოკენს
03:35 — ბლოკი #9 ხელმოწერილია და იგზავნება დასადასტურებლად სხვა კვანძებში
03:41 - მოხდა ქსელის შეცდომა
04:40 — ბლოკის #9 ვალიდაციის მოლოდინის დრო ამოიწურა
04:54 — გაგზავნის კვანძმა აიღო დარჩენილი 760 ათასი ტრანზაქცია ფონდიდან და დაიწყო Merkle-ის ჰეშის გამოთვლა და #9 ბლოკის ხელმოწერა.
05:32 — ბლოკი #9 ხელმოწერილია და იგზავნება დასადასტურებლად სხვა კვანძებში
05:53 — ბლოკი #9 დამოწმებულია და იგზავნება root ჯაჭვში
06:17 - კვანძებმა დაიწყეს ინფორმაციის მიღება, რომ ბლოკი #9 დაემატა root ჯაჭვს და დაიწყო 760k ტრანზაქციის შესრულება
06:47 — აუზი გაწმენდილია ტრანზაქციებისგან, რომლებიც არის #9 ბლოკში
09:06 - ყველა კვანძი შეიცავს 2 მილიონ ტრანზაქციას და ტოკენს

ტესტი 2

თითო ბლოკზე არის 350 ათასი ლიმიტი. შედეგად, ჩვენ გვაქვს 3 ბლოკი.

საწყისი მდგომარეობა: ბოლო ბლოკი #9; მონაცემთა ბაზაში ინახება 2 მილიონი ტრანზაქცია და ტოკენი

00:00 — ტრანზაქციის გენერირების სკრიპტი უკვე ამოქმედდა
00:44 - შეიქმნა 1 მილიონი ტრანზაქცია და დაიწყო გაგზავნა კვანძში
00:56 — გაგზავნეთ კვანძმა აიღო 320 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #10. ჩვენ ასევე ვხედავთ, რომ 320 ათასი ტრანზაქცია ემატება აუზს 10 წამში
01:12 — ბლოკი #10 ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
01:18 — დაასრულა დემო სკრიპტმა, რომელმაც 1 წამში 34 მილიონი ტრანზაქცია გაგზავნა
01:20 — ბლოკი #10 დამოწმებულია და იგზავნება root ჯაჭვში
01:51 - ყველა კვანძმა მიიღო ინფორმაცია root ჯაჭვიდან, რომ დაემატა ბლოკი #10 და იწყებს 320k ტრანზაქციის გამოყენებას
02:01 - აუზი გასუფთავდა 320 ათასი ტრანზაქციისთვის, რომლებიც დაემატა #10 ბლოკს
02:15 — გაგზავნეთ კვანძმა აიღო 350 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #11
02:34 — ბლოკი #11 ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
02:51 — ბლოკი #11 დამოწმებულია და იგზავნება ძირეულ ჯაჭვში
02:55 — ბოლო კვანძმა დაასრულა ტრანზაქციები #10 ბლოკიდან
10:59 — ტრანზაქციას #9 ბლოკის წარდგენით ძალიან დიდი დრო დასჭირდა root ჯაჭვში, მაგრამ ის დასრულდა და ყველა კვანძმა მიიღო ინფორმაცია ამის შესახებ და დაიწყო 350 ათასი ტრანზაქციის შესრულება.
11:05 - აუზი გასუფთავდა 320 ათასი ტრანზაქციისთვის, რომლებიც დაემატა #11 ბლოკს
12:10 - ყველა კვანძი შეიცავს 1 მილიონ 670 ათასი ტრანზაქციას და ტოკენს
12:17 — გაგზავნეთ კვანძმა აიღო 330 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #12
12:32 — ბლოკი #12 ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
12:39 — ბლოკი #12 დამოწმებულია და იგზავნება root ჯაჭვში
13:44 - ყველა კვანძმა მიიღო ინფორმაცია root ჯაჭვიდან, რომ დაემატა ბლოკი #12 და იწყებს 330 ათასი ტრანზაქციის გამოყენებას
14:50 - ყველა კვანძი შეიცავს 2 მილიონ ტრანზაქციას და ტოკენს

ტესტი 3

პირველ და მეორე სერვერებში ერთი დამადასტურებელი კვანძი შეიცვალა წარმდგენი კვანძით.

საწყისი მდგომარეობა: ბოლო ბლოკი #84; მონაცემთა ბაზაში შენახული 0 ტრანზაქცია და ჟეტონები

00:00 — გაშვებულია 3 სკრიპტი, რომლებიც წარმოქმნიან და აგზავნიან 1 მილიონ ტრანზაქციას
01:38 — შეიქმნა 1 მილიონი ტრანზაქცია და დაიწყო გაგზავნა #3 კვანძზე
01:50 — გაგზავნეთ #3 კვანძმა აიღო 330 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #85 (f21). ჩვენ ასევე ვხედავთ, რომ 350 ათასი ტრანზაქცია ემატება აუზს 10 წამში
01:53 — შეიქმნა 1 მილიონი ტრანზაქცია და დაიწყო გაგზავნა #1 კვანძზე
01:50 — გაგზავნეთ #3 კვანძმა აიღო 330 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #85 (f21). ჩვენ ასევე ვხედავთ, რომ 350 ათასი ტრანზაქცია ემატება აუზს 10 წამში
02:01 — გაგზავნეთ კვანძი #1, აიღო 250 ათასი ტრანზაქცია აუზიდან და აყალიბებს ბლოკს #85 (65e)
02:06 — ბლოკი #85 (f21) ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
02:08 — დაასრულა მუშაობა სერვერის #3 დემო სკრიპტმა, რომელმაც 1 მილიონი ტრანზაქცია გაგზავნა 30 წამში.
02:14 — ბლოკი #85 (f21) დამოწმებულია და იგზავნება root ჯაჭვში
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 - ყველა კვანძმა მიიღო ინფორმაცია root ჯაჭვიდან, რომელიც დაემატა #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 აიღო 750 ათასი ტრანზაქცია ფონდიდან და აფორმა ბლოკი #88 (50a), გაგზავნა კვანძი #3 აიღო 670 ათასი ტრანზაქცია. აუზი და ფორმები #88 ბლოკი (d3b)
04:44 — ბლოკი #88 (d3b) ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
04:58 — ბლოკი #88 (214) ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
05:11 — ბლოკი #88 (50a) ხელმოწერილია და იგზავნება სხვა კვანძებში დასადასტურებლად
05:11 — ბლოკი #85 (d3b) დამოწმებულია და იგზავნება ძირეულ ჯაჭვში
05:36 — ბლოკი #85 (214) დამოწმებულია და იგზავნება ძირეულ ჯაჭვში
05:43 - ყველა კვანძმა მიიღო ინფორმაცია root ჯაჭვიდან, რომელიც დაემატა #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 - ყველა კვანძმა მიიღო ინფორმაცია root ჯაჭვიდან, რომ დაემატა ბლოკი #90 (50a) და იწყებს 888145 ტრანზაქციის გამოყენებას. ამავდროულად, #3 სერვერმა უკვე გამოიყენა ტრანზაქციები ბლოკებიდან #88 (d3b), #89(214)
12:11 - ყველა აუზი ცარიელია
13:41 — სერვერის #3 ყველა კვანძი შეიცავს 3 მილიონ ტრანზაქციას და ტოკენს
14:35 — სერვერის #1 ყველა კვანძი შეიცავს 3 მილიონ ტრანზაქციას და ტოკენს
19:24 — სერვერის #2 ყველა კვანძი შეიცავს 3 მილიონ ტრანზაქციას და ტოკენს

დაბრკოლებები

Plasma Cash-ის განვითარებისას შეგვხვდა შემდეგი პრობლემები, რომლებსაც თანდათან გადავჭრით და ვაგვარებთ:

1. კონფლიქტი სხვადასხვა სისტემის ფუნქციების ურთიერთქმედებაში. მაგალითად, აუზში ტრანზაქციების დამატების ფუნქციამ დაბლოკა ბლოკების წარდგენისა და ვალიდაციის მუშაობა და პირიქით, რამაც გამოიწვია სიჩქარის ვარდნა.

2. დაუყოვნებლივ არ იყო ნათელი, თუ როგორ უნდა გაგზავნილიყო დიდი რაოდენობით ტრანზაქცია მონაცემთა გადაცემის ხარჯების მინიმუმამდე შემცირებით.

3. გაურკვეველია, როგორ და სად უნდა შეინახოს მონაცემები მაღალი შედეგების მისაღწევად.

4. გაუგებარი იყო, თუ როგორ უნდა მოაწყოთ ქსელი კვანძებს შორის, რადგან ბლოკის ზომა 1 მილიონი ტრანზაქციის მქონე დაახლოებით 100 მბ-ს იკავებს.

5. ერთი ძაფის რეჟიმში მუშაობა წყვეტს კავშირს კვანძებს შორის, როდესაც ხდება ხანგრძლივი გამოთვლები (მაგალითად, მერკლის ხის აშენება და მისი ჰეშის გამოთვლა).

როგორ გავუმკლავდით ამ ყველაფერს?

Plasma Cash კვანძის პირველი ვერსია იყო ერთგვარი კომბაინი, რომელსაც შეეძლო ყველაფრის გაკეთება ერთდროულად: ტრანზაქციების მიღება, ბლოკების წარდგენა და დამოწმება და მონაცემთა წვდომისთვის API. ვინაიდან NodeJS ბუნებით არის ერთნაკადიანი, მძიმე Merkle-ის ხის გამოთვლის ფუნქციამ დაბლოკა ტრანზაქციის დამატების ფუნქცია. ჩვენ ვნახეთ ორი ვარიანტი ამ პრობლემის გადასაჭრელად:

1. გაუშვით რამდენიმე NodeJS პროცესი, რომელთაგან თითოეული ასრულებს კონკრეტულ ფუნქციებს.

2. გამოიყენეთ worker_threads და გადაიტანეთ კოდის ნაწილის შესრულება ძაფებში.

შედეგად, ჩვენ გამოვიყენეთ ორივე ვარიანტი ერთდროულად: ჩვენ ლოგიკურად დავყავით ერთი კვანძი 3 ნაწილად, რომლებსაც შეუძლიათ მუშაობა ცალკე, მაგრამ ამავე დროს სინქრონულად.

1. წარდგენის კვანძი, რომელიც იღებს ტრანზაქციებს აუზში და ქმნის ბლოკებს.

2. დამადასტურებელი კვანძი, რომელიც ამოწმებს კვანძების ვალიდობას.

3. API კვანძი - უზრუნველყოფს API-ს მონაცემებზე წვდომისთვის.

ამ შემთხვევაში, თქვენ შეგიძლიათ დაუკავშირდეთ თითოეულ კვანძს unix სოკეტის მეშვეობით cli-ს გამოყენებით.

მძიმე ოპერაციები, როგორიცაა მერკლის ხის გამოთვლა, ცალკე ძაფში გადავიტანეთ.

ამრიგად, ჩვენ მივაღწიეთ ყველა Plasma Cash ფუნქციის ნორმალურ ფუნქციონირებას ერთდროულად და ჩავარდნის გარეშე.

როგორც კი სისტემა ამოქმედდა, დავიწყეთ სიჩქარის ტესტირება და, სამწუხაროდ, არადამაკმაყოფილებელი შედეგები მივიღეთ: 5 ტრანზაქცია წამში და 000-მდე ტრანზაქცია ბლოკში. უნდა გამეგო, რა იყო არასწორად განხორციელებული.

დასაწყისისთვის, ჩვენ დავიწყეთ Plasma Cash-თან კომუნიკაციის მექანიზმის ტესტირება სისტემის მაქსიმალური შესაძლებლობის გასარკვევად. ადრე დავწერეთ, რომ Plasma Cash კვანძი უზრუნველყოფს unix სოკეტის ინტერფეისს. თავდაპირველად ის ტექსტზე იყო დაფუძნებული. 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 ჩვენთვის არ არის შესაფერისი. მე მომიწია ყველაფრის გადაწერა წმინდა ფუნქციონალური მიდგომით.

ჩაწერა მონაცემთა ბაზაში

თავდაპირველად, Redis შეირჩა მონაცემთა შესანახად, როგორც ერთ-ერთი ყველაზე პროდუქტიული გადაწყვეტა, რომელიც აკმაყოფილებს ჩვენს მოთხოვნებს: გასაღები-მნიშვნელობის შენახვა, ჰეშ ცხრილებთან მუშაობა, კომპლექტი. ჩვენ გავუშვით redis-benchmark და მივიღეთ ~80 ათასი ოპერაცია წამში 1 მილსადენის რეჟიმში.

მაღალი შესრულებისთვის, ჩვენ უფრო დეტალურად დავაკონფიგურირეთ Redis:

• შეიქმნა unix სოკეტის კავშირი.
• ჩვენ გამორთეთ მდგომარეობის შენახვა დისკზე (სანდოობისთვის შეგიძლიათ დააყენოთ რეპლიკა და შეინახოთ დისკზე ცალკე Redis-ში).

Redis-ში პულტი არის ჰეშის ცხრილი, რადგან ჩვენ უნდა შევძლოთ ყველა ტრანზაქციის აღდგენა ერთ მოთხოვნაში და წაშალოთ ტრანზაქციები სათითაოდ. ჩვენ ვცადეთ ჩვეულებრივი სიის გამოყენება, მაგრამ ეს უფრო ნელია მთელი სიის გადმოტვირთვისას.

სტანდარტული NodeJS-ის გამოყენებისას, Redis ბიბლიოთეკებმა მიაღწიეს 18 ათასი ტრანზაქციის შესრულებას წამში. სიჩქარე 9-ჯერ დაეცა.

ვინაიდან ეტალონმა გვაჩვენა, რომ შესაძლებლობები აშკარად 5-ჯერ მეტი იყო, დავიწყეთ ოპტიმიზაცია. ჩვენ შევცვალეთ ბიბლიოთეკა ioredis-ზე და მივიღეთ შესრულება 25k წამში. ჩვენ დავამატეთ ტრანზაქციები სათითაოდ `hset` ბრძანების გამოყენებით. ასე რომ, ჩვენ ვქმნიდით უამრავ შეკითხვას Redis-ში. გაჩნდა იდეა, რომ გაერთიანდეს ტრანზაქციები პარტიებად და გაგზავნილიყო ერთი ბრძანებით `hmset`. შედეგი არის 32 ათასი წამში.

რამდენიმე მიზეზის გამო, რომლებსაც ქვემოთ აღვწერთ, ჩვენ ვმუშაობთ მონაცემებთან `ბუფერის~ გამოყენებით და, როგორც ირკვევა, თუ დაწერამდე მას ტექსტად გადააქცევთ (`buffer.toString('hex')`), შეგიძლიათ მიიღოთ დამატებითი შესრულება. ამრიგად, სიჩქარე გაიზარდა 35 კმ-მდე წამში. ამ დროისთვის, ჩვენ გადავწყვიტეთ შემდგომი ოპტიმიზაციის შეჩერება.

ჩვენ მოგვიწია ორობით პროტოკოლზე გადასვლა, რადგან:

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)` ჩვენ გადავიყვანთ მონაცემებს `Buffer` Redis-ში შესანახად ან სხვა კვანძში გადასატანად და ამოსაღებად. მონაცემების დაბრუნება.

ჩვენ ასევე გვაქვს 2 ორობითი პროტოკოლი სერვისებს შორის მონაცემთა გადაცემისთვის:

— პლაზმურ კვანძთან ურთიერთქმედების პროტოკოლი unix სოკეტის საშუალებით

  ```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 — sendTransaction, 2 — getTransaction;
• `სატვირთო~ — მონაცემები, რომლებიც უნდა გადაეცეს შესაბამის ფუნქციას;
• `messageId` — შეტყობინების ID, რათა პასუხის იდენტიფიცირება მოხდეს.

— კვანძებს შორის ურთიერთქმედების პროტოკოლი

  ```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;
• `ვერსიის პროტოკოლი` — პროტოკოლის ვერსია, ვინაიდან სხვადასხვა ვერსიის მქონე კვანძები შეიძლება გაიზარდოს ქსელში და მათ შეუძლიათ განსხვავებულად იმუშაონ;
• `შემდეგი~ - შეტყობინების იდენტიფიკატორი;
• `countChunk` и `ცალი ნომერი` აუცილებელია დიდი შეტყობინებების გასაყოფად;
• `სიგრძე~ и `სატვირთო~ სიგრძე და თავად მონაცემები.

ვინაიდან ჩვენ წინასწარ აკრიფეთ მონაცემები, საბოლოო სისტემა ბევრად უფრო სწრაფია, ვიდრე Ethereum-ის `rlp` ბიბლიოთეკა. სამწუხაროდ, ამაზე უარის თქმა ჯერ ვერ მოვახერხეთ, რადგან აუცილებელია სმარტ კონტრაქტის დასრულება, რასაც მომავალში ვგეგმავთ.

თუ ჩვენ მოვახერხეთ სიჩქარეს 35 000 ტრანზაქციები წამში, ჩვენ ასევე გვჭირდება მათი დამუშავება ოპტიმალურ დროში. იმის გამო, რომ ბლოკის ფორმირების სავარაუდო დრო 30 წამს სჭირდება, ჩვენ უნდა შევიტანოთ ბლოკში 1 000 000 ტრანზაქციები, რაც ნიშნავს მეტის გაგზავნას 100 MB მონაცემები.

თავდაპირველად, ჩვენ ვიყენებდით `ethereumjs-devp2p` ბიბლიოთეკას კვანძებს შორის კომუნიკაციისთვის, მაგრამ მას არ შეეძლო ამდენი მონაცემების დამუშავება. შედეგად, ჩვენ გამოვიყენეთ `ws` ბიბლიოთეკა და დავაყენეთ ორობითი მონაცემების გაგზავნა websocket-ით. რა თქმა უნდა, ჩვენ ასევე შეგვხვდა პრობლემები დიდი მონაცემთა პაკეტების გაგზავნისას, მაგრამ ჩვენ დავყავით ისინი ნაწილებად და ახლა ეს პრობლემები გაქრა.

ასევე მერკლის ხის ფორმირება და ჰეშის გამოთვლა 1 000 000 ტრანზაქციები მოითხოვს დაახლოებით 10 უწყვეტი გაანგარიშების წამი. ამ დროის განმავლობაში, კავშირი ყველა კვანძთან ახერხებს გაწყვეტას. გადაწყდა, რომ ეს გამოთვლა ცალკე თემაში გადაიტანა.

დასკვნები:

სინამდვილეში, ჩვენი აღმოჩენები არ არის ახალი, მაგრამ რატომღაც ბევრი ექსპერტი ივიწყებს მათ განვითარებისას.

• ფუნქციური პროგრამირების გამოყენება ობიექტზე ორიენტირებული პროგრამირების ნაცვლად აუმჯობესებს პროდუქტიულობას.
• მონოლითი უარესია, ვიდრე მომსახურების არქიტექტურა პროდუქტიული NodeJS სისტემისთვის.
• მძიმე გამოთვლებისთვის `worker_threads`-ის გამოყენება აუმჯობესებს სისტემის რეაგირებას, განსაკუთრებით მაშინ, როდესაც საქმე გვაქვს i/o ოპერაციებთან.
• unix სოკეტი უფრო სტაბილური და სწრაფია ვიდრე http მოთხოვნები.
• თუ თქვენ გჭირდებათ დიდი მონაცემების სწრაფად გადატანა ქსელში, უმჯობესია გამოიყენოთ ვებსოკეტები და გაგზავნოთ ორობითი მონაცემები, დაყოფილი ნაწილებად, რომელთა გადაგზავნა შესაძლებელია, თუ ისინი არ ჩამოდიან და შემდეგ გაერთიანდებიან ერთ შეტყობინებაში.

გეპატიჟებით ეწვიეთ GitHub პროექტი: https://github.com/opporty-com/Plasma-Cash/tree/new-version

სტატიის თანადამწერი იყო ალექსანდრე ნაშივანი, უფროსი დეველოპერი Clever Solution Inc.

წყარო: www.habr.com