پبلڪ ٽيسٽ: ايٿيروم تي پرائيويسي ۽ اسڪالبلٽي لاءِ هڪ حل

بلاڪچين هڪ جديد ٽيڪنالاجي آهي جيڪا انساني زندگي جي ڪيترن ئي شعبن کي بهتر ڪرڻ جو واعدو ڪري ٿي. اهو حقيقي عملن ۽ پروڊڪٽس کي ڊجيٽل اسپيس ۾ منتقل ڪري ٿو، مالي ٽرانزيڪشن جي رفتار ۽ اعتبار کي يقيني بڻائي ٿو، انهن جي قيمت گھٽائي ٿو، ۽ پڻ توهان کي اجازت ڏئي ٿو ته جديد ڊي اي پي پي ايپليڪيشنون ٺاهڻ لاءِ سمارٽ ٺيڪيدار استعمال ڪندي غير مرڪزي نيٽ ورڪن ۾.

بلاڪچين جي ڪيترن ئي فائدن ۽ متنوع ايپليڪيشنن کي ڏنو ويو، اهو حيران ٿي سگھي ٿو ته هي ترقي يافته ٽيڪنالاجي اڃا تائين هر صنعت ۾ پنهنجو رستو نه ٺاهيو آهي. مسئلو اهو آهي ته جديد غير مرڪزي بلاڪچين ۾ اسڪاليبلٽي جي کوٽ آهي. Ethereum تقريبا 20 ٽرانزيڪشن في سيڪنڊ تي عمل ڪري ٿو، جيڪو اڄ جي متحرڪ ڪاروبار جي ضرورتن کي پورو ڪرڻ لاء ڪافي ناهي. ساڳي ئي وقت، بلاڪ چين ٽيڪنالاجي استعمال ڪندي ڪمپنيون ايٿيروم کي ڇڏي ڏيڻ لاء حساس آهن ان جي اعلي درجي جي حفاظت جي ڪري هيڪنگ ۽ نيٽورڪ ناڪامي کان.

بلاڪچين ۾ غير مرڪزيت کي يقيني بڻائڻ، سيڪيورٽي ۽ اسڪاليبلٽي، اهڙيء طرح حل ڪرڻ واري اسڪيبلبلٽي ٽريلما، ترقياتي ٽيم موقعو پلازما ڪيش ٺاهيو، هڪ ذيلي زنجير جنهن ۾ سمارٽ معاهدي ۽ هڪ نجي نيٽ ورڪ تي مشتمل آهي Node.js، جيڪو وقتي طور تي پنهنجي رياست کي روٽ چين (Ethereum) ڏانهن منتقل ڪري ٿو.

پلازما ڪيش ۾ اهم عمل

1. استعمال ڪندڙ سمارٽ ڪانٽريڪٽ فنڪشن کي سڏي ٿو ’ڊپوزٽ‘، ان ۾ پاس ڪري ETH جي رقم جيڪا هو پلازما ڪيش ٽوڪن ۾ جمع ڪرائڻ چاهي ٿو. سمارٽ معاهدو فنڪشن هڪ ٽوڪن ٺاهي ٿو ۽ ان بابت هڪ واقعو ٺاهي ٿو.

2. سمارٽ ڪانٽريڪٽ جي واقعن لاءِ سبسڪرائب ٿيل پلازما ڪيش نوڊس هڪ ايونٽ وصول ڪن ٿا جمع ٺاهڻ بابت ۽ هڪ ٽرانزيڪشن شامل ڪريو پول ۾ ٽوڪن ٺاهڻ بابت.

3. وقتي طور تي، خاص پلازما ڪيش نوڊس پول مان سڀئي ٽرانزيڪشن وٺي (1 ملين تائين) ۽ انهن مان هڪ بلاڪ ٺاهي، مرڪل وڻ جي حساب سان ۽، مطابق، هيش. هي بلاڪ تصديق لاءِ ٻين نوڊس ڏانهن موڪليو ويو آهي. نوڊس چيڪ ڪن ٿا ته ڇا Merkle hash صحيح آهي ۽ ڇا ٽرانزيڪشن صحيح آهن (مثال طور، ڇا ٽوڪن موڪليندڙ ان جو مالڪ آهي). بلاڪ جي تصديق ڪرڻ کان پوء، نوڊ سمارٽ معاهدي جي 'submitBlock' فنڪشن کي سڏي ٿو، جيڪو بلاڪ نمبر ۽ Merkle hash کي کنڊ جي زنجير ڏانهن محفوظ ڪري ٿو. سمارٽ معاهدو هڪ واقعو ٺاهي ٿو جيڪو هڪ بلاڪ جي ڪامياب اضافو کي ظاهر ڪري ٿو. ٽرانزيڪشن پول مان ڪڍيا ويا آهن.

4. نوڊس جيڪي وصول ڪن ٿا بلاڪ جمع ڪرائڻ وارو واقعو انهن ٽرانزيڪشن کي لاڳو ڪرڻ شروع ڪن ٿا جيڪي بلاڪ ۾ شامل ڪيا ويا.

5. ڪجهه نقطي تي، ٽوڪن جو مالڪ (يا غير مالڪ) ان کي پلازما ڪيش مان ڪڍڻ چاهي ٿو. هن کي ڪرڻ لاء، هو سڏي ٿو 'startExit' فنڪشن، ان ۾ داخل ڪندي ٽوڪن تي آخري 2 ٽرانزيڪشن بابت معلومات، جيڪا تصديق ڪري ٿي ته هو ٽوڪن جو مالڪ آهي. سمارٽ معاهدو، مرڪل هيش استعمال ڪندي، بلاڪ ۾ ٽرانزيڪشن جي موجودگي کي چيڪ ڪري ٿو ۽ واپسي لاءِ ٽوڪن موڪلي ٿو، جيڪو ٻن هفتن ۾ ٿيندو.

6. جيڪڏهن ٽوڪن ڪڍڻ وارو عمل خلاف ورزين سان ٿيو (ٽوڪن ڪڍڻ جو عمل شروع ٿيڻ کان پوءِ خرچ ڪيو ويو يا ٽوڪن ڪڍڻ کان اڳ ۾ ئي ڪنهن ٻئي جي هئي)، ٽوڪن جو مالڪ ٻن هفتن اندر واپسي کي رد ڪري سگهي ٿو.

رازداري ٻن طريقن سان حاصل ڪئي ويندي آهي

1. روٽ زنجير انهن ٽرانزيڪشن جي باري ۾ ڪجھ به نه ڄاڻي ٿو جيڪي ٻار جي زنجير جي اندر ٺاهيل ۽ اڳتي وڌا ويا آهن. پلازما ڪيش مان ETH ڪير جمع ۽ واپس ورتو بابت معلومات عوامي رهي ٿي.

2. ٻارن جو سلسلو zk-SNARKs استعمال ڪندي گمنام ٽرانزيڪشن جي اجازت ڏئي ٿو.

ٽيڪنالاجي اسٽيڪ

• NodeJS
• 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 رام
Ropsten testnet ETH نوڊ بلند ڪيو ويو.
3 تصديق ڪندڙ پلازما ڪيش نوڊس بلند ڪيا ويا.

3. Intel Core i9-9900K Octa-Core incl. NVMe SSD - 1 TB، 64 GB DDR4 رام
1 پلازما ڪيش جمع ڪرائڻ جو نوڊ وڌايو ويو.
3 تصديق ڪندڙ پلازما ڪيش نوڊس بلند ڪيا ويا.
پلازما ڪيش نيٽ ورڪ ۾ ٽرانزيڪشن شامل ڪرڻ لاءِ هڪ ٽيسٽ شروع ڪئي وئي.

Total: 10 پلازما ڪيش نوڊس هڪ خانگي نيٽ ورڪ ۾.

ٽيسٽ 1

هر بلاڪ ۾ 1 ملين ٽرانزيڪشن جي حد آهي. تنهن ڪري، 1 ملين ٽرانزيڪشن 2 بلاڪن ۾ اچي ٿو (جيئن ته سسٽم ٽرانزيڪشن جو حصو وٺڻ ۽ موڪلڻ دوران جمع ڪرڻ جو انتظام ڪري ٿو).

شروعاتي حالت: آخري بلاڪ # 7؛ 1 ملين ٽرانزيڪشن ۽ ٽوڪن ڊيٽابيس ۾ محفوظ ٿيل آهن.

00:00 - ٽرانزيڪشن نسل جي اسڪرپٽ جي شروعات
01:37 - 1 ملين ٽرانزيڪشن ٺاهيا ويا ۽ نوڊ ڏانهن موڪلڻ شروع ڪيو
01:46 — جمع ڪرايل نوڊ پول ۽ فارم بلاڪ #240 مان 8k ٽرانزيڪشن ورتو. اسان اهو پڻ ڏسون ٿا ته 320k ٽرانزيڪشن 10 سيڪنڊن ۾ پول ۾ شامل ڪيا ويا آهن
01:58 — بلاڪ #8 سائن ڪيو ويو آهي ۽ تصديق لاءِ موڪليو ويو آهي
02:03 — بلاڪ #8 جي تصديق ڪئي وئي آهي ۽ سمارٽ معاهدي جي 'submitBlock' فنڪشن کي مرڪل هيش ۽ بلاڪ نمبر سان سڏيو ويندو آهي
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 — جمع ڪرايل نوڊ پول ۽ فارم بلاڪ #320 مان 10k ٽرانزيڪشن ورتو. اسان اهو پڻ ڏسون ٿا ته 320k ٽرانزيڪشن 10 سيڪنڊن ۾ پول ۾ شامل ڪيا ويا آهن
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 پول ۽ فارم بلاڪ #330 (f85) مان 21k ٽرانزيڪشن ورتو. اسان اهو پڻ ڏسون ٿا ته 350k ٽرانزيڪشن 10 سيڪنڊن ۾ پول ۾ شامل ڪيا ويا آهن
01:53 — 1 ملين ٽرانزيڪشنز ٺاهيا ويا ۽ موڪلڻ شروع ڪيو نوڊ #1
01:50 — جمع ڪرايو نوڊ #3 پول ۽ فارم بلاڪ #330 (f85) مان 21k ٽرانزيڪشن ورتو. اسان اهو پڻ ڏسون ٿا ته 350k ٽرانزيڪشن 10 سيڪنڊن ۾ پول ۾ شامل ڪيا ويا آهن
02:01 — جمع ڪرايو نوڊ #1 پول مان 250k ٽرانزيڪشن ورتو ۽ فارم بلاڪ #85 (65e)
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 ٽرانزيڪشن ورتو ۽ فارم بلاڪ #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. سنگل ٿريڊ موڊ ۾ ڪم ڪرڻ نوڊس جي وچ ۾ ڪنيڪشن ٽوڙي ٿو جڏهن ڊگھي حساب سان ٿئي ٿي (مثال طور، مرڪل جي وڻ جي تعمير ۽ ان جي هش کي ڳڻڻ).

اسان اهو سڀ ڪجهه ڪيئن ڪيو؟

پلازما ڪيش نوڊ جو پهريون نسخو هڪ قسم جو ٺهيل هو جيڪو هڪ ئي وقت ۾ سڀ ڪجهه ڪري سگهي ٿو: ٽرانزيڪشن قبول ڪريو، بلاڪ جمع ڪريو ۽ تصديق ڪريو، ۽ ڊيٽا تائين رسائي لاءِ API مهيا ڪريو. جيئن ته NodeJS مقامي طور تي واحد ڌاڳو آهي، هيري مرڪل وڻ حساب ڪتاب شامل ڪرڻ واري فعل کي بلاڪ ڪيو. اسان هن مسئلي کي حل ڪرڻ لاء ٻه آپشن ڏٺا:

1. ڪيترن ئي NodeJS عملن کي لانچ ڪريو، جن مان ھر ھڪ مخصوص ڪم انجام ڏئي ٿو.

2. worker_threads استعمال ڪريو ۽ ڪوڊ جي ھڪڙي حصي جي عمل کي موضوعن ۾ منتقل ڪريو.

نتيجي طور، اسان ساڳئي وقت ٻنهي اختيارن کي استعمال ڪيو: اسان منطقي طور تي هڪ نوڊ کي 3 حصن ۾ ورهايو جيڪي الڳ الڳ ڪم ڪري سگهن ٿا، پر ساڳئي وقت هم وقت سازي سان.

1. جمع ڪرڻ جو نوڊ، جيڪو پول ۾ ٽرانزيڪشن کي قبول ڪري ٿو ۽ بلاڪ ٺاهي ٿو.

2. هڪ تصديق ڪندڙ نوڊ جيڪو چيڪ ڪري ٿو نوڊس جي صحيحيت.

3. API نوڊ - ڊيٽا تائين رسائي لاءِ API مهيا ڪري ٿي.

انهي حالت ۾، توهان ڪلائي استعمال ڪندي يونڪس ساکٽ ذريعي هر نوڊ سان ڳنڍي سگهو ٿا.

اسان بھاري عملن کي منتقل ڪيو، جيئن مرڪل جي وڻ کي ڳڻڻ، ھڪڙي الڳ سلسلي ۾.

اهڙيء طرح، اسان سڀني پلازما ڪيش ڪمن جي عام آپريشن کي هڪ ئي وقت ۽ ناڪامي کان سواء حاصل ڪيو آهي.

هڪ دفعو سسٽم فعال ٿي ويو، اسان رفتار کي جانچڻ شروع ڪيو ۽، بدقسمتي سان، غير اطمينان بخش نتيجا مليا: 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 ڀيرا گهٽجي وئي، جنهن مان ظاهر ٿئي ٿو ته او او پي اسان لاءِ مناسب ناهي. مون کي هر شي کي ٻيهر لکڻو پوندو خالص فنڪشنل طريقي سان.

ڊيٽابيس ۾ رڪارڊنگ

شروعاتي طور تي، ريڊيس کي ڊيٽا اسٽوريج لاءِ چونڊيو ويو ھڪڙو سڀ کان وڌيڪ پيداواري حلن مان جيڪو اسان جي ضرورتن کي پورو ڪري ٿو: ڪي-ويل اسٽوريج، ھيش ٽيبل سان ڪم ڪرڻ، سيٽ. اسان redis-benchmark شروع ڪيو ۽ حاصل ڪيو ~ 80k آپريشن في سيڪنڊ ۾ 1 پائپ لائننگ موڊ ۾.

اعليٰ ڪارڪردگيءَ لاءِ، اسان ريڊس کي وڌيڪ نفاست سان ڏٺو:

• ھڪڙو يونڪس ساکٽ ڪنيڪشن قائم ڪيو ويو آھي.
• اسان رياست کي ڊسڪ ۾ محفوظ ڪرڻ کي بند ڪري ڇڏيو (اعتماد لاءِ، توهان هڪ ريپليڪا سيٽ ڪري سگهو ٿا ۽ ڊسڪ کي الڳ ريڊس ۾ محفوظ ڪري سگهو ٿا).

ريڊس ۾، هڪ پول هڪ هيش ٽيبل آهي ڇو ته اسان کي هڪ سوال ۾ سڀني ٽرانزيڪشن کي ٻيهر حاصل ڪرڻ ۽ هڪ هڪ ذريعي ٽرانزيڪشن کي ختم ڪرڻ جي ضرورت آهي. اسان هڪ باقاعده لسٽ استعمال ڪرڻ جي ڪوشش ڪئي، پر اهو سست آهي جڏهن پوري لسٽ کي لوڊ ڪندي.

جڏهن معياري NodeJS استعمال ڪندي، ريڊس لائبريرين في سيڪنڊ 18k ٽرانزيڪشن جي ڪارڪردگي حاصل ڪئي. رفتار 9 ڀيرا گهٽجي وئي.

جيئن ته معيار اسان کي ڏيکاريا ته امڪان واضح طور تي 5 ڀيرا وڌيڪ هئا، اسان کي بهتر ڪرڻ شروع ڪيو. اسان لائبريري کي ioredis ۾ تبديل ڪيو ۽ 25k في سيڪنڊ جي ڪارڪردگي حاصل ڪئي. اسان 'hset' ڪمانڊ استعمال ڪندي هڪ هڪ ڪري ٽرانزيڪشن شامل ڪيو. تنهنڪري اسان ريڊس ۾ ڪيترائي سوال پيدا ڪري رهيا هئاسين. اهو خيال پيدا ٿيو ته ٽرانزيڪشن کي بيچ ۾ گڏ ڪيو وڃي ۽ انهن کي هڪ حڪم سان موڪليو `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();` and `BD.decode(buffer, Protocol)` اسان ڊيٽا کي `Buffer` ۾ تبديل ڪريون ٿا Redis ۾ محفوظ ڪرڻ يا ٻئي نوڊ ڏانهن فارورڊ ڪرڻ ۽ ٻيهر حاصل ڪرڻ لاءِ. ڊيٽا واپس.

اسان وٽ پڻ آهن 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 - ٽرانزيڪشن حاصل ڪريو؛
• `payload` - ڊيٽا جيڪا مناسب فنڪشن ڏانهن منتقل ٿيڻ جي ضرورت آهي؛
• پيغام آئي ڊي - پيغام جي سڃاڻپ ته جيئن جواب جي سڃاڻپ ڪري سگهجي.

- نوڊس جي وچ ۾ رابطي لاء پروٽوڪول

  ```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' и `ٽڪن نمبر` وڏي پيغامن کي ورهائڻ لاءِ ضروري آهي؛
• ڊگھائي и `payload` ڊيگهه ۽ ڊيٽا پاڻ.

جيئن ته اسان ڊيٽا کي اڳ ۾ ٽائيپ ڪيو آهي، فائنل سسٽم ايٿيروم جي `rlp` لائبريري کان تمام گهڻو تيز آهي. بدقسمتي سان، اسان اڃا تائين ان کي رد ڪرڻ جي قابل نه آهيون، ڇو ته اهو سمارٽ معاهدي کي حتمي شڪل ڏيڻ ضروري آهي، جيڪو اسان مستقبل ۾ ڪرڻ جو منصوبو آهي.

جيڪڏهن اسان رفتار تائين پهچڻ جو انتظام ڪيو 35 000 ٽرانزيڪشن في سيڪنڊ، اسان کي انهن کي بهتر وقت ۾ پروسيس ڪرڻ جي ضرورت آهي. جيئن ته لڳ ڀڳ بلاڪ ٺهڻ وقت 30 سيڪنڊن جو وقت وٺندو آهي، اسان کي بلاڪ ۾ شامل ڪرڻ جي ضرورت آهي 1 000 000 ٽرانزيڪشن، جنهن جو مطلب آهي وڌيڪ موڪلڻ 100 MB ڊيٽا.

شروعات ۾، اسان استعمال ڪيو 'ethereumjs-devp2p' لائبريري نوڊس جي وچ ۾ رابطي لاء، پر اهو ايترو گهڻو ڊيٽا کي هٿ نه ڪري سگهيو. نتيجي طور، اسان استعمال ڪيو `ws` لائبريري ۽ ترتيب ڏنل بائنري ڊيٽا موڪلڻ ويب ساکٽ ذريعي. يقينن، وڏي ڊيٽا پيڪيٽ موڪلڻ وقت اسان کي به مشڪلاتون پيش آيون، پر اسان انهن کي ٽڪرن ۾ ورهايو ۽ هاڻي اهي مسئلا ختم ٿي ويا آهن.

مرڪل جي وڻ کي پڻ ٺاهيندي ۽ هش جي حساب سان 1 000 000 ٽرانزيڪشن جي ضرورت آهي 10 مسلسل حساب ڪتاب جا سيڪنڊ. هن عرصي دوران، سڀني نوڊس سان ڪنيڪشن کي ٽوڙڻ جو انتظام ڪري ٿو. اهو فيصلو ڪيو ويو ته هن حساب کي هڪ الڳ موضوع ڏانهن منتقل ڪيو وڃي.

نتيجو:

حقيقت ۾، اسان جا نتيجا نوان نه آهن، پر ڪجهه سببن لاء ڪيترن ئي ماهرن جي ترقي دوران انهن جي باري ۾ وساريو.

• Object-Oriented Programming جي بدران فنڪشنل پروگرامنگ استعمال ڪرڻ پيداوار کي بهتر بڻائي ٿو.
• monolith هڪ پيداوار NodeJS نظام لاء هڪ خدمت فن تعمير کان بدتر آهي.
• 'worker_threads' استعمال ڪرڻ بھاري ڪمپيوٽيشن لاءِ سسٽم جي ردعمل کي بھتر بڻائي ٿو، خاص طور تي جڏھن i/o آپريشنز سان معاملو ڪيو وڃي.
• يونڪس ساکٽ HTTP درخواستن کان وڌيڪ مستحڪم ۽ تيز آهي.
• جيڪڏهن توهان کي جلدي نيٽ ورڪ تي وڏي ڊيٽا کي منتقل ڪرڻ جي ضرورت آهي، اهو بهتر آهي ته ويب ساکٽ استعمال ڪريو ۽ بائنري ڊيٽا موڪلي، حصن ۾ ورهايو وڃي، جيڪي اڳتي هلي سگهجن ٿيون جيڪڏهن اهي پهچي نه وڃن، ۽ پوء هڪ پيغام ۾ گڏيل.

اسان توهان کي گهمڻ جي دعوت ڏيون ٿا GitHub پروجيڪٽ: https://github.com/opporty-com/Plasma-Cash/tree/new-version

مضمون گڏيل پاران لکيل هو اليگزينڊر نيشيوان، سينئر ڊولپر Clever Solution Inc.

جو ذريعو: www.habr.com