පොදු පරීක්ෂණය: Ethereum මත පුද්ගලිකත්වය සහ පරිමාණය සඳහා විසඳුමක්

බ්ලොක්චේන් මිනිස් ජීවිතයේ බොහෝ අංශ වැඩිදියුණු කිරීමට පොරොන්දු වන නව්‍ය තාක්‍ෂණයකි. එය සැබෑ ක්‍රියාවලි සහ නිෂ්පාදන ඩිජිටල් අවකාශයට මාරු කරයි, මූල්‍ය ගනුදෙනුවල වේගය සහ විශ්වසනීයත්වය සහතික කරයි, ඒවායේ පිරිවැය අඩු කරයි, සහ විමධ්‍යගත ජාලවල ස්මාර්ට් කොන්ත්‍රාත්තු භාවිතයෙන් නවීන DAPP යෙදුම් නිර්මාණය කිරීමට ද ඔබට ඉඩ සලසයි.

බ්ලොක්චේන් හි බොහෝ ප්‍රතිලාභ සහ විවිධ යෙදුම් සැලකිල්ලට ගෙන, මෙම පොරොන්දු වූ තාක්‍ෂණය තවමත් සෑම කර්මාන්තයකටම පිවිසී නොමැති බව පුදුමයක් විය හැකිය. ගැටළුව වන්නේ නවීන විමධ්‍යගත බ්ලොක්චේන් පරිමාණය නොමැති වීමයි. Ethereum තත්පරයකට ගනුදෙනු 20ක් පමණ ක්‍රියාවට නංවයි, එය වර්තමාන ගතික ව්‍යාපාරවල අවශ්‍යතා සපුරාලීමට ප්‍රමාණවත් නොවේ. ඒ අතරම, බ්ලොක්චේන් තාක්‍ෂණය භාවිතා කරන සමාගම් අනවසරයෙන් ඇතුළුවීම සහ ජාල අසමත්වීම් වලින් ඉහළ ආරක්ෂාවක් හේතුවෙන් Ethereum අතහැර දැමීමට පසුබට වේ.

බ්ලොක්චේන් හි විමධ්‍යගත කිරීම, ආරක්ෂාව සහ පරිමාණය සහතික කිරීම සඳහා, සංවර්ධන කණ්ඩායම වන පරිමාණයේ ට්‍රයිලම්මා විසඳීම අවස්ථාව ප්ලාස්මා කෑෂ්, ස්මාර්ට් කොන්ත්‍රාත්තුවක් සහ Node.js මත පදනම් වූ පුද්ගලික ජාලයකින් සමන්විත අනුබද්ධ දාමයක් නිර්මාණය කරන ලදී, එය කලින් කලට එහි තත්වය මූල දාමයට (Ethereum) මාරු කරයි.

ප්ලාස්මා මුදල් වල ප්‍රධාන ක්‍රියාවලි

1. පරිශීලකයා ස්මාර්ට් කොන්ත්‍රාත්තු ශ්‍රිතය 'තැන්පතු' ලෙස හඳුන්වයි, ඔහුට ප්ලාස්මා කෑෂ් ටෝකනයට තැන්පත් කිරීමට අවශ්‍ය ETH ප්‍රමාණය එයට ලබා දෙයි. ස්මාර්ට් කොන්ත්‍රාත්තු ශ්‍රිතය ටෝකනයක් නිර්මාණය කර ඒ පිළිබඳ සිදුවීමක් ජනනය කරයි.

2. ස්මාර්ට් කොන්ත්‍රාත්තු සිදුවීම් සඳහා දායක වූ ප්ලාස්මා මුදල් නෝඩ්වලට තැන්පතුවක් සෑදීම පිළිබඳ සිදුවීමක් ලැබෙන අතර සංචිතයට ටෝකනයක් නිර්මාණය කිරීම පිළිබඳ ගනුදෙනුවක් එක් කරයි.

3. වරින් වර, විශේෂ ප්ලාස්මා මුදල් නෝඩ් තටාකයෙන් (මිලියන 1 දක්වා) සියලුම ගනුදෙනු ලබාගෙන ඒවායින් බ්ලොක් එකක් සාදයි, මර්කල් ගස ගණනය කිරීම සහ ඒ අනුව හැෂ්. මෙම අවහිරය සත්‍යාපනය සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ. නෝඩ් විසින් මර්කල් හැෂ් වලංගුද යන්න සහ ගනුදෙනු වලංගුද යන්න පරීක්ෂා කරයි (උදාහරණයක් ලෙස, ටෝකනය යවන්නා එහි හිමිකරුද යන්න). බ්ලොක් එක සත්‍යාපනය කිරීමෙන් පසු, නෝඩය ස්මාර්ට් කොන්ත්‍රාත්තුවේ 'submitBlock' ශ්‍රිතය අමතයි, එමඟින් බ්ලොක් අංකය සහ මර්කල් හැෂ් දාමයට සුරකියි. ස්මාර්ට් කොන්ත්‍රාත්තුව මඟින් බ්ලොක් එකක් සාර්ථක ලෙස එකතු කිරීම පෙන්නුම් කරන සිදුවීමක් ජනනය කරයි. ගනුදෙනු සංචිතයෙන් ඉවත් කරනු ලැබේ.

4. වාරණ ඉදිරිපත් කිරීමේ සිදුවීම ලැබෙන නෝඩ් බ්ලොක් එකට එකතු කරන ලද ගනුදෙනු යෙදීමට පටන් ගනී.

5. යම් අවස්ථාවක දී, ටෝකනයේ හිමිකරු (හෝ හිමිකරු නොවන) එය ප්ලාස්මා කෑෂ් වෙතින් ඉවත් කර ගැනීමට අවශ්ය වේ. මෙය සිදු කිරීම සඳහා, ඔහු ටෝකනයේ හිමිකරු බව තහවුරු කරන ටෝකනයේ අවසාන ගනුදෙනු 2 පිළිබඳ තොරතුරු එයට ලබා දෙමින් `startExit` ශ්‍රිතය අමතයි. ස්මාර්ට් කොන්ත්‍රාත්තුව, මර්කල් හෑෂ් භාවිතයෙන්, බ්ලොක් වල ගනුදෙනු තිබේදැයි පරීක්ෂා කර ආපසු ගැනීම සඳහා ටෝකනය යවයි, එය සති දෙකකින් සිදුවනු ඇත.

6. ටෝකන ආපසු ගැනීමේ මෙහෙයුම සිදු වූයේ උල්ලංඝනයන් සමඟ නම් (ටෝකනය මුදල් ආපසු ගැනීමේ ක්‍රියා පටිපාටිය ආරම්භ වූ පසුව හෝ ටෝකනය දැනටමත් වෙනත් කෙනෙකුගේ මුදල් ආපසු ගැනීමට පෙර), ටෝකනයේ හිමිකරුට සති දෙකක් ඇතුළත ආපසු ගැනීම ප්‍රතික්ෂේප කළ හැකිය.

පෞද්ගලිකත්වය ආකාර දෙකකින් ලබා ගනී

1. ළමා දාමය තුළ ජනනය වන සහ ඉදිරියට යවන ගනුදෙනු ගැන මූල දාමය කිසිවක් නොදනී. ප්ලාස්මා කෑෂ් වෙතින් ETH තැන්පත් කර ඉවත් කර ගත් අය පිළිබඳ තොරතුරු ප්‍රසිද්ධව පවතී.

2. ළමා දාමය zk-SNARKs භාවිතයෙන් නිර්නාමික ගනුදෙනුවලට ඉඩ දෙයි.

තාක්ෂණික තොගය

• NodeJS
• Redis
• එතෙරියම්
• අපිරිසිදු

පරීක්ෂා කිරීම

ප්ලාස්මා කෑෂ් සංවර්ධනය කිරීමේදී, අපි පද්ධතියේ වේගය පරීක්ෂා කර පහත ප්‍රතිඵල ලබා ගත්තෙමු:

• තත්පරයකට ගනුදෙනු 35 දක්වා සංචිතයට එකතු වේ;
• ගනුදෙනු 1 දක්වා බ්ලොක් එකක ගබඩා කළ හැක.

පහත සඳහන් සේවාදායක 3 මත පරීක්ෂණ සිදු කරන ලදී:

1. Intel Core i7-6700 Quad-Core Skylake ඇතුළුව. 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 Octa-Core ඇතුළුව. NVMe SSD - 1 TB, 64 GB DDR4 RAM
1 ප්ලාස්මා මුදල් ඉදිරිපත් කිරීමේ නෝඩය ඉහළ නැංවීය.
වලංගු ප්ලාස්මා මුදල් නෝඩ් 3ක් ඉහළ නැංවීය.
ප්ලාස්මා මුදල් ජාලයට ගනුදෙනු එකතු කිරීම සඳහා පරීක්ෂණයක් දියත් කරන ලදී.

එකතුව: පුද්ගලික ජාලයක ප්ලාස්මා මුදල් නෝඩ් 10 ක්.

පරීක්ෂණය 1

බ්ලොක් එකකට ගනුදෙනු මිලියන 1ක සීමාවක් ඇත. එබැවින්, ගනුදෙනු මිලියන 1 ක් බ්ලොක් 2 කට වැටේ (පද්ධතිය ගනුදෙනු වලින් කොටසක් ලබාගෙන ඒවා යවන අතරතුර ඉදිරිපත් කිරීමට කළමනාකරණය කරන බැවින්).

ආරම්භක තත්වය: අවසාන කොටස #7; මිලියන 1 ක ගනුදෙනු සහ ටෝකන දත්ත ගබඩාවේ ගබඩා කර ඇත.

00:00 — ගනුදෙනු උත්පාදන පිටපත ආරම්භය
01:37 - ගනුදෙනු මිලියන 1 ක් නිර්මාණය කරන ලද අතර node වෙත යැවීම ආරම්භ විය
01:46 — submit node සංචිතයෙන් ගනුදෙනු 240k ගෙන ඇති අතර #8 වාරණ තත්පර 320 කින් 10k ගනුදෙනු සංචිතයට එකතු වන බව ද අපට පෙනේ
01:58 — අංක 8 අත්සන් කර වලංගු කිරීම සඳහා යවනු ලැබේ
02:03 — #8 වාරණ වලංගු කර ඇති අතර ස්මාර්ට් කොන්ත්‍රාත්තුවේ `submitBlock' ශ්‍රිතය Merkle හැෂ් සහ බ්ලොක් අංකය සමඟ කැඳවනු ලැබේ.
02:10 — demo script එක වැඩ අවසන්, එය තත්පර 1ක් තුළ ගනුදෙනු මිලියන 32ක් යවා ඇත
02:33 - මූල දාමයට බ්ලොක් #8 එකතු කර ඇති බවට තොරතුරු නෝඩ් වලට ලැබීමට පටන් ගත් අතර 240k ගනුදෙනු සිදු කිරීමට පටන් ගත්තේය.
02:40 - 240k ගනුදෙනු සංචිතයෙන් ඉවත් කරන ලදී, ඒවා දැනටමත් #8 කොටසේ ඇත
02:56 — submit node ඉතිරි 760k ගණුදෙණු සංචිතයෙන් ගෙන මර්කල් හැෂ් ගණනය කිරීම සහ බ්ලොක් #9 අත්සන් කිරීම ආරම්භ කළේය.
03:20 - සියලුම නෝඩ් වල මිලියන 1 ක් 240k ගනුදෙනු සහ ටෝකන අඩංගු වේ
03:35 — බ්ලොක් #9 අත්සන් කර වෙනත් නෝඩ් වෙත වලංගු කිරීම සඳහා යවනු ලැබේ
03:41 - ජාල දෝෂයක් ඇති විය
04:40 — වාරණ #9 වලංගු කිරීම සඳහා රැඳී සිටීමේ කාලය අවසන් වී ඇත
04:54 — submit node ඉතිරි 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 ක් නිර්මාණය කරන ලද අතර node වෙත යැවීම ආරම්භ විය
00:56 — submit node සංචිතයෙන් ගනුදෙනු 320k ගෙන ඇති අතර #10 වාරණ තත්පර 320 කින් 10k ගනුදෙනු සංචිතයට එකතු වන බව ද අපට පෙනේ
01:12 — බ්ලොක් #10 අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
01:18 — demo script එක වැඩ අවසන්, එය තත්පර 1ක් තුළ ගනුදෙනු මිලියන 34ක් යවා ඇත
01:20 — වාරණ #10 වලංගු කර මූල දාමයට යවනු ලැබේ
01:51 - සියලුම නෝඩ් වලට මූල දාමයෙන් තොරතුරු ලැබුණු අතර එය #10 වාරණ එකතු කර 320k ගනුදෙනු යෙදීමට පටන් ගනී.
02:01 - #320 අවහිර කිරීමට එකතු කරන ලද 10k ගනුදෙනු සඳහා සංචිතය නිෂ්කාශනය වී ඇත
02:15 — submit node සංචිතයෙන් 350k ගනුදෙනු ගෙන ඇති අතර #11 ෆෝම් බ්ලොක්
02:34 — බ්ලොක් #11 අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
02:51 — බ්ලොක් #11 වලංගු කර root දාමයට යවනු ලැබේ
02:55 — අවසාන නෝඩය අංක 10 සිට ගනුදෙනු සම්පූර්ණ කළේය
10:59 — බ්ලොක් අංක 9 ඉදිරිපත් කිරීම සමඟ ගනුදෙනුව මූල දාමයේ ඉතා දිගු කාලයක් ගත විය, නමුත් එය අවසන් වූ අතර සියලුම නෝඩ් වලට ඒ පිළිබඳ තොරතුරු ලැබී 350k ගනුදෙනු සිදු කිරීමට පටන් ගත්තේය.
11:05 - #320 අවහිර කිරීමට එකතු කරන ලද 11k ගනුදෙනු සඳහා සංචිතය නිෂ්කාශනය වී ඇත
12:10 - සියලුම නෝඩ් වල මිලියන 1 670k ගනුදෙනු සහ ටෝකන අඩංගු වේ
12:17 — submit node සංචිතයෙන් 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 — submit node #3 සංචිතයෙන් 330k ගණුදෙණු ගෙන ඇති අතර #85 ෆෝම් බ්ලොක් (f21). තත්පර 350 කින් 10k ගනුදෙනු සංචිතයට එකතු වන බව ද අපට පෙනේ
01:53 — ගනුදෙනු මිලියන 1 ක් නිර්මාණය කරන ලද අතර අංක 1 ඉදිරිපත් කිරීමට යැවීම ආරම්භ විය
01:50 — submit node #3 සංචිතයෙන් 330k ගණුදෙණු ගෙන ඇති අතර #85 ෆෝම් බ්ලොක් (f21). තත්පර 350 කින් 10k ගනුදෙනු සංචිතයට එකතු වන බව ද අපට පෙනේ
02:01 — submit node #1 සංචිතයෙන් ගණුදෙනු 250k ගෙන ඇති අතර #85 ෆෝම් බ්ලොක් (65e)
02:06 — බ්ලොක් #85 (f21) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
02:08 — තත්පර 3 කින් ගනුදෙනු මිලියන 1 ක් යැවූ සේවාදායකය #30 හි demo script, වැඩ අවසන්
02:14 — වාරණ #85 (f21) වලංගු කර මූල දාමයට යවනු ලැබේ
02:19 — බ්ලොක් #85 (65e) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
02:22 — ගනුදෙනු මිලියන 1 ක් නිර්මාණය කරන ලද අතර අංක 2 ඉදිරිපත් කිරීමට යැවීම ආරම්භ විය
02:27 — වාරණ #85 (65e) වලංගු කර මූල දාමයට යවනු ලැබේ
02:29 — submit node #2 සංචිතයෙන් ගණුදෙණු 111855ක් ගෙන #85 (256) වාරණ.
02:36 — බ්ලොක් #85 (256) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
02:36 — තත්පර 1 කින් ගනුදෙනු මිලියන 1 ක් යැවූ සේවාදායකය #42.5 හි demo script, වැඩ අවසන්
02:38 — block #85 (256) වලංගු කර මූල දාමයට යවනු ලැබේ
03:08 — සේවාදායකය #2 ස්ක්‍රිප්ට් ක්‍රියා කර අවසන්, එය තත්පර 1 කින් ගනුදෙනු මිලියනයක් යවා ඇත
03:38 - සියලුම නෝඩ් වලට #85 (f21), #86(65e), #87(256) අවහිර කරන මූල දාමයෙන් තොරතුරු ලැබී 330k, 250k, 111855 ගනුදෙනු යෙදීමට පටන් ගත්තේය.
03:49 - සංචිතය #330 (f250), #111855(85e), #21(86) කොටස් වෙත එකතු කරන ලද 65k, 87k, 256 ගනුදෙනු වලදී නිෂ්කාශනය කරන ලදී.
03:59 — submit node #1 සංචිතයෙන් ගණුදෙණු 888145ක් ගෙන ඇති අතර #88 (214) වාරණ ෆෝම් වලින් ලබාගෙන ඇත, submit node #2 සංචිතයෙන් 750k ගණුදෙණු ලබා ගත් අතර #88 (50a) ෆෝම් බ්ලොක් #3 (670a), submit node #88 වෙතින් ගනුදෙනු 3k ලබා ගෙන ඇත. තටාකය සහ ආකෘති වාරණ #XNUMX (dXNUMXb)
04:44 — බ්ලොක් #88 (d3b) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
04:58 — බ්ලොක් #88 (214) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
05:11 — බ්ලොක් #88 (50a) අත්සන් කර වලංගු කිරීම සඳහා වෙනත් නෝඩ් වෙත යවනු ලැබේ
05:11 — වාරණ #85 (d3b) වලංගු කර මූල දාමයට යවනු ලැබේ
05:36 — block #85 (214) වලංගු කර මූල දාමයට යවනු ලැබේ
05:43 - #88 (d3b), #89(214) අවහිර කරන ලද මූල දාමයෙන් සියලුම නෝඩ් වලට තොරතුරු ලැබී ඇති අතර 670k, 750k ගනුදෙනු යෙදීමට පටන් ගනී
06:50 — සන්නිවේදන අසාර්ථක වීමක් හේතුවෙන් #85 (50a) අවහිර කිරීම වලංගු නොවීය
06:55 — submit node #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 MB පමණ වන බැවින් නෝඩ් අතර ජාලයක් සංවිධානය කරන්නේ කෙසේදැයි පැහැදිලි නොවීය.

5. තනි නූල් ආකාරයෙන් වැඩ කිරීම දිගු ගණනය කිරීම් සිදු වන විට නෝඩ් අතර සම්බන්ධතාවය බිඳ දමයි (උදාහරණයක් ලෙස, මර්කල් ගසක් තැනීම සහ එහි හැෂ් ගණනය කිරීම).

අපි මේ සියල්ල සමඟ කටයුතු කළේ කෙසේද?

Plasma Cash node හි පළමු අනුවාදය සෑම දෙයක්ම එකවර කළ හැකි ආකාරයේ සංයෝජනයකි: ගනුදෙනු පිළිගැනීම, වාරණ ඉදිරිපත් කිරීම සහ වලංගු කිරීම සහ දත්ත වෙත ප්‍රවේශ වීම සඳහා API සැපයීම. NodeJS ස්වදේශිකව තනි නූල් සහිත බැවින්, බර මර්කල් ගස් ගණනය කිරීමේ කාර්යය එකතු කිරීමේ ගනුදෙනු ශ්‍රිතය අවහිර කළේය. මෙම ගැටළුව විසඳීම සඳහා විකල්ප දෙකක් අපි දුටුවෙමු:

1. NodeJS ක්‍රියාවලි කිහිපයක් දියත් කරන්න, ඒ සෑම එකක්ම නිශ්චිත කාර්යයන් ඉටු කරයි.

2. Worker_threads භාවිතා කර කේතයේ කොටසක් ක්‍රියාත්මක කිරීම නූල් වලට ගෙන යන්න.

එහි ප්‍රතිඵලයක් වශයෙන්, අපි එකවර විකල්ප දෙකම භාවිතා කළෙමු: අපි තාර්කිකව එක් නෝඩයක් වෙන වෙනම ක්‍රියා කළ හැකි කොටස් 3 කට බෙදා ඇත, නමුත් ඒ සමඟම සමමුහුර්තව

1. ඉදිරිපත් කිරීමේ නෝඩය, සංචිතයට ගනුදෙනු පිළිගෙන කුට්ටි නිර්මාණය කරයි.

2. නෝඩ් වල වලංගු භාවය පරීක්ෂා කරන වලංගු නෝඩයක්.

3. API node - දත්ත වෙත ප්‍රවේශ වීම සඳහා API එකක් සපයයි.

මෙම අවස්ථාවේදී, ඔබට cli භාවිතයෙන් unix socket හරහා එක් එක් node වෙත සම්බන්ධ විය හැක.

අපි මර්කල් ගස ගණනය කිරීම වැනි බර මෙහෙයුම් වෙනම නූලකට මාරු කළෙමු.

මේ අනුව, අපි සියලුම ප්ලාස්මා මුදල් ක්‍රියාකාරිත්වයන් එකවර සහ අසාර්ථකත්වයකින් තොරව සාමාන්‍ය ක්‍රියාකාරීත්වය ලබාගෙන ඇත.

පද්ධතිය ක්‍රියාත්මක වූ පසු, අපි වේගය පරීක්ෂා කිරීමට පටන් ගත් අතර, අවාසනාවන්ත ලෙස, අසතුටුදායක ප්‍රතිඵල ලැබුණි: තත්පරයකට ගනුදෙනු 5 ක් සහ බ්ලොක් එකකට ගනුදෙනු 000 දක්වා. වැරදි ලෙස ක්‍රියාත්මක කළේ කුමක්දැයි මට සොයා ගැනීමට සිදු විය.

ආරම්භ කිරීම සඳහා, අපි පද්ධතියේ උපරිම හැකියාව සොයා ගැනීම සඳහා ප්ලාස්මා කෑෂ් සමඟ සන්නිවේදන යාන්ත්‍රණය පරීක්ෂා කිරීමට පටන් ගත්තෙමු. අපි කලින් ලිව්වා Plasma Cash node එක unix socket interface එකක් සපයන බව. මුලදී එය පෙළ මත පදනම් විය. 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 ක් තුළ තත්පරයට ~1k මෙහෙයුම් ලබා ගත්තෙමු.

ඉහළ කාර්ය සාධනය සඳහා, අපි Redis වඩාත් සියුම් ලෙස සුසර කළෙමු:

• Unix socket සම්බන්ධතාවයක් ස්ථාපිත කර ඇත.
• අපි ප්රාන්තය තැටියට සුරැකීම අක්රිය කළෙමු (විශ්වසනීයත්වය සඳහා, ඔබට අනුරුවක් සකසා වෙනම Redis තුළ තැටියට සුරැකිය හැක).

Redis හි, pool එකක් යනු හැෂ් වගුවකි, මන්ද අපට සියලු ගනුදෙනු එක් විමසුමකින් ලබා ගැනීමට සහ ගනුදෙනු එකින් එක මකා දැමීමට හැකි විය යුතු බැවිනි. අපි සාමාන්‍ය ලැයිස්තුවක් භාවිතා කිරීමට උත්සාහ කළ නමුත් සම්පූර්ණ ලැයිස්තුවම බාගැනීමේදී එය මන්දගාමී වේ.

සම්මත NodeJS භාවිතා කරන විට, Redis පුස්තකාල තත්පරයකට 18k ගනුදෙනු වල කාර්ය සාධනයක් ලබා ගත්තේය. වේගය 9 වතාවක් අඩු විය.

මිණුම් ලකුණ අපට පැහැදිලිවම හැකියාවන් 5 ගුණයකින් වැඩි බව පෙන්නුම් කළ බැවින්, අපි ප්‍රශස්ත කිරීමට පටන් ගත්තෙමු. අපි පුස්තකාලය ioredis ලෙස වෙනස් කර තත්පරයට 25k කාර්ය සාධනයක් ලබා ගත්තෙමු. අපි `hset` විධානය භාවිතයෙන් ගනුදෙනු එකින් එක එකතු කළෙමු. ඉතින් අපි Redis හි බොහෝ විමසුම් ජනනය කරමින් සිටියෙමු. ගනුදෙනු කාණ්ඩවලට ඒකාබද්ධ කර ඒවා එක් විධානයකින් `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(block, Protocol).slice();` සහ `BD.decode(buffer, Protocol)` මඟින් අපි Redis හි සුරැකීමට හෝ වෙනත් node එකක් වෙත යොමු කිරීමට සහ නැවත ලබා ගැනීමට දත්ත 'Buffer' බවට පරිවර්තනය කරමු. දත්ත ආපසු.

සේවා අතර දත්ත මාරු කිරීම සඳහා අපට ද්විමය ප්‍රොටෝකෝල 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 - sendTransaction, 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` и `චන්ක් අංකය` විශාල පණිවිඩ බෙදීම සඳහා අවශ්ය;
• `දිග` и `ගෙවීම` දිග සහ දත්ත ම.

අපි දත්ත පූර්ව-ටයිප් කළ බැවින්, අවසාන පද්ධතිය Ethereum හි `rlp` පුස්තකාලයට වඩා බොහෝ වේගවත් වේ. අවාසනාවකට මෙන්, අපට එය ප්‍රතික්ෂේප කිරීමට තවමත් නොහැකි වී ඇත, මන්ද අනාගතයේදී අප කිරීමට අදහස් කරන ස්මාර්ට් කොන්ත්‍රාත්තුව අවසන් කිරීමට අවශ්‍ය බැවිනි.

අපි වේගය ළඟා කර ගැනීමට සමත් වූවා නම් 35 000 තත්පරයකට ගනුදෙනු, අපි ඒවා ප්‍රශස්ත වේලාවට සැකසීමට ද අවශ්‍ය වේ. ආසන්න වශයෙන් බ්ලොක් සෑදීමේ කාලය තත්පර 30 ක් ගත වන බැවින්, අපි බ්ලොක් එකට ඇතුළත් කළ යුතුය 1 000 000 ගනුදෙනු, එනම් වැඩිපුර යැවීමයි 100 දත්ත MB.

මුලදී, අපි නෝඩ් අතර සන්නිවේදනය කිරීමට `ethereumjs-devp2p` පුස්තකාලය භාවිතා කළ නමුත් එයට එතරම් දත්ත හැසිරවීමට නොහැකි විය. එහි ප්‍රතිඵලයක් වශයෙන්, අපි 'ws' පුස්තකාලය භාවිතා කර වෙබ්සොකට් හරහා ද්විමය දත්ත යැවීම වින්‍යාස කළෙමු. ඇත්ත වශයෙන්ම, විශාල දත්ත පැකට් යැවීමේදී අපට ද ගැටළු ඇති විය, නමුත් අපි ඒවා කැබලිවලට බෙදා දැන් මෙම ගැටළු පහව ගොස් ඇත.

එසේම මර්කල් ගසක් සාදා හෑෂ් ගණනය කිරීම 1 000 000 ගනුදෙනු සඳහා අවශ්ය වේ 10 තත්පර අඛණ්ඩ ගණනය කිරීම. මෙම කාලය තුළ, සියලු නෝඩ් සමඟ සම්බන්ධතාවය බිඳී යාමට සමත් වේ. මෙම ගණනය වෙනම නූලකට ගෙන යාමට තීරණය විය.

නිගමන:

ඇත්ත වශයෙන්ම, අපගේ සොයාගැනීම් අලුත් නොවේ, නමුත් යම් හේතුවක් නිසා බොහෝ විශේෂඥයින් සංවර්ධනය කිරීමේදී ඔවුන් ගැන අමතක කරති.

• Object-Oriented Programming වෙනුවට Functional Programming භාවිතා කිරීම ඵලදායිතාව වැඩි දියුණු කරයි.
• ඵලදායි NodeJS පද්ධතියක් සඳහා සේවා ගෘහ නිර්මාණ ශිල්පයට වඩා මොනොලිත් නරක ය.
• බර ගණනය කිරීම් සඳහා `worker_threads` භාවිතා කිරීම පද්ධති ප්‍රතිචාරය වැඩි දියුණු කරයි, විශේෂයෙන් i/o මෙහෙයුම් සමඟ කටයුතු කරන විට.
• unix socket http ඉල්ලීම් වලට වඩා ස්ථායී සහ වේගවත් වේ.
• ඔබට ඉක්මනින් ජාලය හරහා විශාල දත්ත මාරු කිරීමට අවශ්‍ය නම්, වෙබ් සොකට් භාවිතා කර ද්විමය දත්ත යැවීම වඩා හොඳය, ඒවා කුට්ටි වලට බෙදා, ඒවා නොපැමිණියේ නම් ඉදිරියට යැවිය හැකි අතර පසුව එක් පණිවිඩයකට ඒකාබද්ධ කළ හැකිය.

අපි ඔබට සංචාරය කිරීමට ආරාධනා කරනවා GitHub ව්යාපෘතිය: https://github.com/opporty-com/Plasma-Cash/tree/new-version

ලිපිය සම-ලියා ඇත ඇලෙක්සැන්ඩර් නෂිවන්, ජ්යෙෂ්ඨ සංවර්ධක Clever Solution Inc.

මූලාශ්රය: www.habr.com