عامه ازموینه: په ایتیروم کې د محرمیت او توزیع کولو لپاره حل

بلاکچین یوه نوې ټیکنالوژي ده چې د انسان د ژوند ډیری برخو ته وده ورکولو ژمنه کوي. دا ریښتینې پروسې او محصولات ډیجیټل ځای ته لیږدوي، د مالي معاملو سرعت او اعتبار تضمینوي، د دوی لګښت کموي، او همدارنګه تاسو ته اجازه درکوي چې په غیر متمرکز شبکو کې د سمارټ قراردادونو په کارولو سره د DAPP عصري غوښتنلیکونه جوړ کړئ.

د بلاکچین ډیری ګټو او متنوع غوښتنلیکونو ته په پام سره ، دا ممکن د حیرانتیا وړ بریښي چې دې ژمنې ټیکنالوژۍ لاهم په هر صنعت کې خپله لاره نه ده کړې. ستونزه دا ده چې عصري غیر متمرکز بلاکچینونه د اندازې وړتیا نلري. Ethereum په هره ثانیه کې شاوخوا 20 لیږدونه پروسس کوي، کوم چې د نن ورځې متحرک سوداګرۍ اړتیاو پوره کولو لپاره کافي ندي. په ورته وخت کې ، هغه شرکتونه چې د بلاکچین ټیکنالوژي کاروي د هیکینګ او شبکې ناکامیو څخه د لوړې کچې محافظت له امله د ایتیریم پریښودلو کې زړه نازړه دي.

په بلاکچین کې د غیر متمرکز کیدو ، امنیت او توزیع کولو ډاډ ترلاسه کولو لپاره ، پدې توګه د توزیع کولو ټریلیما حل کول ، پراختیایی ټیم فرصت پلازما کیش رامینځته کړی ، یو فرعي سلسله چې د سمارټ قرارداد او د Node.js پراساس یو خصوصي شبکه لري ، کوم چې په دوره توګه خپل حالت د ریښې سلسلې (ایتیریم) ته لیږدوي.

په پلازما کیش کې کلیدي پروسې

1. کارونکي د سمارټ قرارداد فنکشن ته 'ډیپوزینټ' وايي، په دې کې د ETH مقدار انتقالوي چې هغه غواړي د پلازما نغدو توکیو کې زیرمه کړي. د سمارټ قرارداد فعالیت یو نښه رامینځته کوي او د هغې په اړه پیښه رامینځته کوي.

2. د سمارټ قرارداد پیښو کې ګډون شوي پلازما کیش نوډونه د زیرمې رامینځته کولو په اړه پیښه ترلاسه کوي او حوض ته د نښه رامینځته کولو په اړه معامله اضافه کوي.

3. په دوره توګه، ځانګړي پلازما کیش نوډونه د پول څخه ټول لیږدونه (تر 1 ملیون پورې) اخلي او له دوی څخه یو بلاک جوړوي، د میرکل ونې محاسبه کوي او په وینا، هش. دا بلاک د تصدیق لپاره نورو نوډونو ته لیږل کیږي. نوډونه ګوري چې ایا د مرکل هش معتبر دی او ایا معاملې د اعتبار وړ دي (د مثال په توګه ، ایا د نښه لیږونکی مالک دی). د بلاک تصدیق کولو وروسته، نوډ د سمارټ قرارداد 'submitBlock' فنکشن ته زنګ وهي، کوم چې د بلاک شمیره او مرکل هش د څنډې سلسلې ته خوندي کوي. سمارټ قرارداد یوه پیښه رامینځته کوي چې د بلاک بریالي اضافه په ګوته کوي. لیږدونه د پول څخه لیرې شوي.

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 په شمول. NVMe SSD - 1 TB، 64 GB DDR4 رام
1 د پلازما نغدو سپارلو نوډ پورته شو.
3 د اعتبار وړ پلازما کیش نوډونه پورته شوي.
د پلازما کیش شبکې ته د معاملو اضافه کولو لپاره ازموینه پیل شوه.

ټول: په شخصي شبکه کې 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 - جمع کولو نوډ د پول او فارم بلاک # 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 ملیون لیږدونه او ټوکنونه لري

ازموینه 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 د پول او فارم بلاک # 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 لیږدونه اخیستي او د بلاک #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 چمتو کړي. له هغه ځایه چې نوډ جے ایس په اصلي ډول واحد تار شوی دی ، د مرکل ونې د درنې محاسبې فنکشن د اضافه لیږد فعالیت بند کړی. موږ د دې ستونزې د حل لپاره دوه اختیارونه ولیدل:

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 ځله راټیټ شو ، کوم چې دا په ګوته کوي چې OOP زموږ لپاره مناسب ندي. ما باید هرڅه په بشپړ ډول فعال چلند ته ولیکل.

په ډیټابیس کې ثبت کول

په پیل کې، ریډیس د ډیټا ذخیره کولو لپاره د یو خورا ګټور حل په توګه غوره شوی و چې زموږ اړتیاوې پوره کوي: د کلیدي ارزښت ذخیره کول، د هش میزونو سره کار کول، سیټونه. موږ ریډیس بنچمارک پیل کړ او په 80 پایپ لاین موډ کې په هره ثانیه کې ~ 1k عملیات ترلاسه کړل.

د لوړ فعالیت لپاره ، موږ ریډیس ډیر ښه تنظیم کړ:

• د یونیکس ساکټ پیوستون تاسیس شوی.
• موږ ډیسک ته د حالت خوندي کول غیر فعال کړل (د اعتبار لپاره ، تاسو کولی شئ یو نقل تنظیم کړئ او په جلا ریډیس کې ډیسک ته خوندي کړئ).

په ریډیس کې ، حوض د هش میز دی ځکه چې موږ اړتیا لرو د دې وړتیا ولرو چې ټولې معاملې په یوه پوښتنه کې ترلاسه کړو او یو له بل سره لیږدونه حذف کړو. موږ د منظم لیست کارولو هڅه وکړه، مګر دا ورو وي کله چې ټول لیست پورته شي.

کله چې معیاري NodeJS کاروئ، د Redis کتابتونونو په هره ثانیه کې د 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)` موږ معلومات په Redis کې د خوندي کولو یا بل نوډ ته د لیږلو او بیرته ترلاسه کولو لپاره په `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 - لیږد لیږل، 2 - لیږد ترلاسه کول؛
• `payload` - هغه معلومات چې اړتیا لري مناسب فعالیت ته انتقال شي؛
• د پیغام ID - د پیغام 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؛
• د نسخې پروتوکول - د پروتوکول نسخه، ځکه چې د مختلف نسخو سره نوډونه په شبکه کې پورته کیدی شي او دوی کولی شي په مختلف ډول کار وکړي؛
• `seq` - د پیغام پیژندونکی؛
• 'countChunk' и د ټوک شمیره د لوی پیغامونو ویشلو لپاره اړین دی؛
• اوږدوالی и `payload` اوږدوالی او پخپله ډاټا.

له هغه وخته چې موږ ډاټا دمخه ټایپ کړې، وروستی سیسټم د Ethereum د `rlp` کتابتون په پرتله خورا ګړندی دی. له بده مرغه، موږ لا تر اوسه نه دي توانیدلي چې دا رد کړو، ځکه چې دا اړینه ده چې سمارټ قرارداد نهایي کړي، کوم چې موږ په راتلونکي کې پلان کوو.

که موږ سرعت ته ورسیږو 35 000 په هره ثانیه کې لیږدونه، موږ هم اړتیا لرو چې دوی په مناسب وخت کې پروسس کړو. څرنګه چې د بلاک جوړیدو اټکل 30 ثانیې وخت نیسي، موږ باید په بلاک کې شامل کړو 1 000 000 لیږدونه، پدې معنی چې نور لیږل 100 د معلوماتو MB.

په پیل کې، موږ د نوډونو ترمنځ د خبرو اترو لپاره 'ethereumjs-devp2p' کتابتون کارولی، مګر دا دومره ډیټا نشي سمبالولی. د پایلې په توګه، موږ د ws کتابتون کارولی او د ویب ساکټ له لارې د بائنری معلوماتو لیږلو ترتیب کړی. البته ، موږ د لوی ډیټا پاکټونو لیږلو پرمهال هم له ستونزو سره مخ شو ، مګر موږ دوی په ټوټو ویشلي او اوس دا ستونزې له منځه تللي.

همدارنګه د مرکل ونې جوړول او د هش محاسبه کول 1 000 000 د راکړې ورکړې په اړه اړتیا لري 10 د دوامداره محاسبې ثانیې. د دې وخت په جریان کې، د ټولو نوډونو سره اړیکه د ماتولو اداره کوي. پریکړه وشوه چې دا محاسبه یو جلا موضوع ته ولیږدول شي.

پایلې:

په حقیقت کې، زموږ موندنې نوې نه دي، مګر د ځینو دلیلونو لپاره ډیری ماهرین د دوی په اړه هیر کوي کله چې وده کوي.

• د آبجیکٹ اورینټډ برنامه کولو پرځای د فنکشنل برنامه کارول محصول ښه کوي.
• مونولیت د تولیدي نوډ جے ایس سیسټم لپاره د خدماتو جوړښت څخه بد دی.
• د درنې محاسبې لپاره د `worker_threads` کارول د سیسټم غبرګون ته وده ورکوي، په ځانګړې توګه کله چې د i/o عملیاتو سره معامله کوي.
• د یونیکس ساکټ د http غوښتنو په پرتله خورا مستحکم او ګړندی دی.
• که تاسو اړتیا لرئ ژر تر ژره په شبکه کې لوی ډیټا لیږدئ ، نو دا به غوره وي چې ویب ساکټونه وکاروئ او بائنری ډیټا واستوئ ، په ټوټو ویشل شوي ، کوم چې د نه رسیدو په صورت کې لیږل کیدی شي ، او بیا په یو پیغام کې یوځای شي.

موږ تاسو ته بلنه درکوو چې لیدنه وکړئ GitHub پروژه: https://github.com/opporty-com/Plasma-Cash/tree/new-version

مقاله په ګډه لیکل شوې وه الکساندر ناشیوان، لوړ پوړی پراختیا کونکی Clever Solution Inc.

سرچینه: www.habr.com