အများသူငှာ စမ်းသပ်ခြင်း- Ethereum တွင် ကိုယ်ရေးကိုယ်တာနှင့် ကျွမ်းကျင်နိုင်မှုတို့အတွက် အဖြေတစ်ခု

ဘလောက် လူ့ဘဝနယ်ပယ်များစွာကို တိုးတက်ကောင်းမွန်လာစေရန် ကတိပြုသည့် ဆန်းသစ်တီထွင်ထားသော နည်းပညာတစ်ခုဖြစ်သည်။ ၎င်းသည် စစ်မှန်သော လုပ်ငန်းစဉ်များနှင့် ထုတ်ကုန်များကို ဒစ်ဂျစ်တယ်နေရာသို့ လွှဲပြောင်းပေးကာ၊ ငွေကြေးလွှဲပြောင်းမှုများ၏ အမြန်နှုန်းနှင့် ယုံကြည်စိတ်ချရမှုကို အာမခံပေးကာ ၎င်းတို့၏ ကုန်ကျစရိတ်များကို လျှော့ချပေးကာ၊ ဗဟိုချုပ်ကိုင်မှုလျှော့ချထားသော ကွန်ရက်များတွင် စမတ်စာချုပ်များကို အသုံးပြုကာ ခေတ်မီ DAPP အပလီကေးရှင်းများကို ဖန်တီးနိုင်စေမည်ဖြစ်သည်။

များစွာသောအကျိုးကျေးဇူးများနှင့် blockchain ၏ကွဲပြားသောအသုံးချပရိုဂရမ်များကိုပေးသောကြောင့်ဤအလားအလာရှိသောနည်းပညာသည်စက်မှုလုပ်ငန်းတိုင်းသို့မ၀င်ရောက်သေးသည်မှာ အံ့သြစရာဖြစ်နိုင်သည်။ ပြဿနာမှာ ခေတ်မီ ဗဟိုချုပ်ကိုင်မှု လျှော့ချထားသော blockchains များသည် ချဲ့ထွင်နိုင်စွမ်းမရှိခြင်းပင်ဖြစ်သည်။ Ethereum သည် တစ်စက္ကန့်လျှင် အရောင်းအ၀ယ်ပြုလုပ်မှု 20 ခန့်ကို လုပ်ဆောင်ပေးသည်၊ ၎င်းသည် ယနေ့ခေတ်၏သွက်လက်သောစီးပွားရေးလုပ်ငန်းများ၏လိုအပ်ချက်များကိုဖြည့်ဆည်းရန်မလုံလောက်ပါ။ တစ်ချိန်တည်းမှာပင်၊ blockchain နည်းပညာကိုအသုံးပြုသည့်ကုမ္ပဏီများသည်ဟက်ကာနှင့်ကွန်ရက်ပျက်ကွက်မှုမှကာကွယ်မှုမြင့်မားသောကြောင့် Ethereum ကိုစွန့်ပစ်ရန်တုံ့ဆိုင်းနေကြသည်။

blockchain တွင် ဗဟိုချုပ်ကိုင်မှုလျှော့ချရေး၊ လုံခြုံရေးနှင့် အရွယ်အစား အတိုင်းအတာကို သေချာစေရန်၊ ထို့ကြောင့် Scalability Trilemma၊ ဖွံ့ဖြိုးတိုးတက်ရေးအဖွဲ့၊ အခွင့်အလမ်း စမတ်စာချုပ်နှင့် Node.js ကိုအခြေခံ၍ ၎င်း၏ပြည်နယ်ကို အရင်းကွင်းဆက် (Ethereum) သို့ အခါအားလျော်စွာ လွှဲပြောင်းပေးသည့် စမတ်စာချုပ်နှင့် သီးသန့်ကွန်ရက်တစ်ခုပါဝင်သော Plasma Cash ကို ဖန်တီးခဲ့သည်။

Plasma Cash ရှိ အဓိကလုပ်ငန်းစဉ်များ

1. သုံးစွဲသူသည် ပလာစမာငွေသား တိုကင်သို့ အပ်နှံလိုသော ETH ပမာဏသို့ ဖြတ်သွားသော စမတ်စာချုပ်လုပ်ဆောင်ချက်ကို `အပ်ငွေ´ ဟုခေါ်ဆိုသည်။ စမတ်ကန်ထရိုက်လုပ်ဆောင်ချက်သည် တိုကင်တစ်ခုကို ဖန်တီးပြီး ၎င်းနှင့်ပတ်သက်သည့် ဖြစ်ရပ်တစ်ခုကို ထုတ်ပေးသည်။

2. စမတ်ကန်ထရိုက်ဖြစ်ရပ်များတွင် စာရင်းသွင်းထားသော Plasma Cash node များသည် အပ်ငွေတစ်ခုဖန်တီးခြင်းနှင့် ရေကူးကန်သို့ တိုကင်ဖန်တီးခြင်းဆိုင်ရာ ငွေပေးငွေယူတစ်ခုကို ပေါင်းထည့်ခြင်းအကြောင်း အဖြစ်အပျက်တစ်ခုကို လက်ခံရရှိသည် ။

3. အခါအားလျော်စွာ၊ အထူး Plasma Cash node များသည် ရေကူးကန် (1 သန်းအထိ) မှ ငွေပေးငွေယူအားလုံးကို ယူကာ ၎င်းတို့ထံမှ ဘလောက်တစ်ခုဖွဲ့စည်းကာ Merkle သစ်ပင်ကို တွက်ချက်ပြီး လျော်ညီစွာ hash ကို ပြုလုပ်သည်။ ဤပိတ်ဆို့ခြင်းကို အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်။ node များသည် Merkle hash သည် တရားဝင်ခြင်းရှိ၊ ပိတ်ဆို့ခြင်းကို စစ်ဆေးပြီးနောက်၊ node သည် ပိတ်ဆို့နံပါတ်ကို သိမ်းဆည်းပေးပြီး Merkle hash ကို အစွန်းကွင်းဆက်သို့ ဖြတ်ပေးသည့် စမတ်စာချုပ်၏ `submitBlock` လုပ်ဆောင်ချက်ကို ခေါ်သည်။ စမတ်ကျသော စာချုပ်သည် ပိတ်ဆို့ခြင်း၏ အောင်မြင်သော ထပ်တိုးမှုကို ညွှန်ပြသည့် ဖြစ်ရပ်တစ်ခု ထုတ်ပေးသည်။ ငွေလွှဲမှုများကို အစုအဝေးမှ ဖယ်ရှားသည်။

4. ပိတ်ဆို့တင်သွင်းမှုဖြစ်ရပ်ကို လက်ခံရရှိသည့် ဆုံမှတ်များသည် ဘလောက်ထဲသို့ ထည့်ထားသည့် ငွေပေးငွေယူများကို စတင်အသုံးပြုသည်။

5. တစ်ချိန်ချိန်တွင်၊ တိုကင်၏ပိုင်ရှင် (သို့မဟုတ် ပိုင်ရှင်မဟုတ်သော) သည် ၎င်းကို Plasma Cash မှ ထုတ်ယူလိုပါသည်။ ၎င်းကိုလုပ်ဆောင်ရန်၊ သူသည် တိုကင်၏ပိုင်ရှင်ဖြစ်ကြောင်း အတည်ပြုသည့် တိုကင်ရှိ နောက်ဆုံး ငွေပေးငွေယူ 2 ခုနှင့်ပတ်သက်သည့် အချက်အလက်ကို ပေးပို့ကာ `startExit` လုပ်ဆောင်ချက်ကို ခေါ်သည်။ Merkle hash ကို အသုံးပြု၍ စမတ်စာချုပ်သည် လုပ်ကွက်များတွင် ငွေပေးငွေယူများ ရှိနေခြင်းကို စစ်ဆေးပြီး နှစ်ပတ်အတွင်း ဖြစ်ပေါ်လာမည့် ငွေထုတ်ရန်အတွက် တိုကင်ကို ပေးပို့သည်။

6. တိုကင်ငွေထုတ်ခြင်းလုပ်ငန်းသည် ချိုးဖောက်မှုများကြောင့် ဖြစ်ပွားပါက (ငွေထုတ်ခြင်းလုပ်ငန်းစဉ်စတင်ပြီးနောက် တိုကင်ကိုသုံးစွဲခဲ့သည် သို့မဟုတ် တိုကင်သည် အခြားသူတစ်ဦးဦး၏ငွေထုတ်ခြင်းမပြုမီ) ဖြစ်ပါက၊ တိုကင်၏ပိုင်ရှင်သည် ထုတ်ယူမှုကို နှစ်ပတ်အတွင်း ပြန်လည်ချေပနိုင်သည်။

ကိုယ်ရေးကိုယ်တာအား နည်းလမ်းနှစ်မျိုးဖြင့် ရရှိသည်။

1. အရင်းကွင်းဆက်သည် ကလေးကွင်းဆက်အတွင်း ထုတ်လုပ်ပြီး ထပ်ဆင့်ပို့သည့် လွှဲပြောင်းမှုများအကြောင်း ဘာမှမသိပါ။ Plasma Cash မှ ETH အပ်နှံသူနှင့် နုတ်ထွက်သူများအကြောင်း အချက်အလက်များသည် အများသူငှာ ရှိနေပါသည်။

2. ကလေးကွင်းဆက်သည် zk-SNARKs ကို အသုံးပြု၍ အမည်မသိ ငွေလွှဲမှုများကို ခွင့်ပြုသည်။

နည်းပညာအစု

• NodeJS
• Redis
• အီသီရီယမ်
• ညစ်ပတ်သည်။

စမ်းသပ်ခြင်း

Plasma Cash ကိုတီထွင်နေစဉ်တွင်၊ ကျွန်ုပ်တို့သည် စနစ်၏အမြန်နှုန်းကို စမ်းသပ်ခဲ့ပြီး အောက်ပါရလဒ်များကို ရရှိခဲ့သည်-

• တစ်စက္ကန့်လျှင် ငွေပေးငွေယူ 35 အထိ ရေကန်ထဲသို့ ပေါင်းထည့်ထားသည်။
• ဘလောက်တစ်ခုတွင် ငွေပေးငွေယူ 1 အထိ သိမ်းဆည်းနိုင်သည်။

စမ်းသပ်မှုများကို အောက်ပါ ဆာဗာ 3 ခုတွင် ပြုလုပ်ခဲ့ပါသည်။

1. Intel Core i7-6700 Quad-Core Skylake ပါဝင်သည်။ NVMe SSD – 512 GB၊ 64 GB DDR4 RAM
Plasma Cash node 3 ခုကို အတည်ပြုခဲ့သည်။

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB၊ 64 GB DDR4 RAM
Ropsten testnet ETH node ကို မြှင့်ထားသည်။
Plasma Cash node 3 ခုကို အတည်ပြုခဲ့သည်။

3. Intel Core i9-9900K Octa-Core ပါဝင်သည်။ NVMe SSD – 1 TB၊ 64 GB DDR4 RAM
1 Plasma Cash တင်သွင်းမှု Node ကို မြှင့်ထားသည်။
Plasma Cash node 3 ခုကို အတည်ပြုခဲ့သည်။
Plasma Cash ကွန်ရက်သို့ ငွေပေးငွေယူများထည့်ရန် စမ်းသပ်မှုတစ်ခု စတင်ခဲ့သည်။

စုစုပေါင်း: သီးသန့်ကွန်ရက်ရှိ Plasma Cash node 10 ခု။

စမ်းသပ်မှု ၁

တစ်တုံးလျှင် ငွေပေးငွေယူ ၁ သန်း ကန့်သတ်ချက် ရှိသည်။ ထို့ကြောင့်၊ ငွေပေးငွေယူ 1 သန်းသည် 1 blocks အတွင်းသို့ ကျရောက်သည် (စနစ်သည် ငွေပေးငွေယူ၏ တစ်စိတ်တစ်ပိုင်းကို စီမံခန့်ခွဲပြီး ၎င်းတို့ကို ပေးပို့နေချိန်တွင် တင်ပြနိုင်သောကြောင့်)။

ကနဦးအခြေအနေ- နောက်ဆုံးအကွက် #7; ငွေပေးငွေယူ ၁ သန်းနှင့် တိုကင်များကို ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသည်။

00:00 — ငွေပေးငွေယူ မျိုးဆက် script စတင်ခြင်း။
01:37 - လွှဲပြောင်းမှု 1 သန်းကို ဖန်တီးပြီး node သို့ စတင်ပေးပို့ခဲ့သည်။
01:46 — ပေးပို့ရန် node သည် ရေကူးကန်မှ အရောင်းအ၀ယ်ပေါင်း 240k ကိုယူခဲ့ပြီး ဖောင်များပိတ်ဆို့ခြင်း #8။ 320k အရောင်းအ၀ယ်များကို 10 စက္ကန့်အတွင်း ရေကူးကန်သို့ ပေါင်းထည့်သည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။
01:58 — block #8 ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် ပေးပို့ပါသည်။
02:03 — block #8 ကို အတည်ပြုပြီး စမတ်စာချုပ်၏ `submitBlock` လုပ်ဆောင်ချက်ကို Merkle hash နှင့် block နံပါတ်ဖြင့် ခေါ်သည်
02:10 — သရုပ်ပြဇာတ်ညွှန်းသည် ပြီးဆုံးခဲ့ပြီး ၃၂ စက္ကန့်အတွင်း ငွေပေးငွေယူ ၁ သန်းကို ပေးပို့ခဲ့သည်။
02:33 - ပိတ်ဆို့နံပါတ် 8 ကို အရင်းကွင်းဆက်သို့ ပေါင်းထည့်လိုက်သည်နှင့် 240k အရောင်းအ၀ယ်များကို စတင်လုပ်ဆောင်ခဲ့သည်
02:40 - 240k အရောင်းအ၀ယ်များကို ပိတ်ဆို့နံပါတ် 8 တွင်ရှိပြီးသားဖြစ်သည့် pool မှဖယ်ရှားခဲ့သည်
02:56 — ပေးပို့ရန် node သည် ရေကူးကန်မှကျန်ရှိသော 760k အရောင်းအ၀ယ်များကိုယူကာ Merkle hash ကို တွက်ချက်ပြီး ဆိုင်းဘုတ်နံပါတ် 9 ကိုစတင်ခဲ့သည်။
03:20 - node အားလုံးတွင် ငွေပေးငွေယူ ၁ ဒသမ ၂၄၀k နှင့် တိုကင်များ ပါရှိသည်။
03:35 — ပိတ်ဆို့နံပါတ် 9 ကို လက်မှတ်ရေးထိုးပြီး အခြား node များသို့ တရားဝင်ခွင့်ပြုရန် ပေးပို့ထားသည်။
03:41 - ကွန်ရက် အမှားဖြစ်သွားသည်။
04:40 — ပိတ်ဆို့ #9 အတည်ပြုချက်ကို စောင့်ဆိုင်းရင်း အချိန်ကုန်သွားပါပြီ။
04:54 — ပေးပို့ရန် node သည် ရေကူးကန်မှကျန်ရှိသော 760k အရောင်းအ၀ယ်များကိုယူကာ Merkle hash ကို တွက်ချက်ပြီး ဆိုင်းဘုတ်နံပါတ် 9 ကိုစတင်ခဲ့သည်။
05:32 — ပိတ်ဆို့နံပါတ် 9 ကို လက်မှတ်ရေးထိုးပြီး အခြား node များသို့ တရားဝင်ခွင့်ပြုရန် ပေးပို့ထားသည်။
05:53 — block #9 ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
06:17 - ပိတ်ဆို့နံပါတ် 9 ကို အမြစ်ကွင်းဆက်တွင် ထည့်သွင်းပြီး 760k အရောင်းအ၀ယ်ပြုလုပ်လာသည်ဟူသော သတင်းအချက်အလက်ကို ဆုံမှတ်များ စတင်လက်ခံရရှိခဲ့သည်။
06:47 — ရေကူးကန်သည် နံပါတ် ၉ တွင်ရှိသော ငွေပေးငွေယူများကို ရှင်းလင်းထားသည်။
09:06 - node အားလုံးတွင် ငွေပေးငွေယူ 2 သန်းနှင့် တိုကင်များ ပါရှိသည်။

စမ်းသပ်မှု ၁

တစ်တုံးလျှင် 350k ကန့်သတ်ချက်ရှိပါသည်။ ရလဒ်အနေနဲ့ ကျွန်တော်တို့မှာ လုပ်ကွက် ၃ ခုရှိတယ်။

ကနဦးအခြေအနေ- နောက်ဆုံးအကွက် #9; ငွေပေးငွေယူ 2 သန်းနှင့် တိုကင်များကို ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသည်။

00:00 — ငွေပေးငွေယူမျိုးဆက် script ကို စတင်ပြီးဖြစ်သည်။
00:44 - လွှဲပြောင်းမှု 1 သန်းကို ဖန်တီးပြီး node သို့ စတင်ပေးပို့ခဲ့သည်။
00:56 — ပေးပို့ရန် node သည် ရေကူးကန်မှ အရောင်းအ၀ယ်ပေါင်း 320k ကိုယူခဲ့ပြီး ဖောင်များပိတ်ဆို့ခြင်း #10။ 320k အရောင်းအ၀ယ်များကို 10 စက္ကန့်အတွင်း ရေကူးကန်သို့ ပေါင်းထည့်သည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။
01:12 — block #10 ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node များသို့ ပေးပို့သည်။
01:18 — သရုပ်ပြဇာတ်ညွှန်းသည် ပြီးဆုံးခဲ့ပြီး ၃၂ စက္ကန့်အတွင်း ငွေပေးငွေယူ ၁ သန်းကို ပေးပို့ခဲ့သည်။
01:20 — block #10 ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
01:51 - ပိတ်ဆို့နံပါတ် 10 ကိုထည့်သွင်းပြီး 320k အရောင်းအ၀ယ်ပြုလုပ်သည့် အမြစ်ကွင်းဆက်မှ အချက်အလက်အားလုံးကို လက်ခံရရှိပြီး XNUMXk အရောင်းအ၀ယ်များ စတင်ရန်။
02:01 - ပိတ်ဆို့ #320 တွင်ထည့်ထားသော 10k အရောင်းအ၀ယ်များအတွက် ရေကူးကန်မှရှင်းလင်းသွားသည်
02:15 — submit node သည် pool မှ 350k အရောင်းအ၀ယ်ပြုလုပ်ပြီး forms block #11
02:34 — block #11 ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား nodeများသို့ ပေးပို့သည်။
02:51 — block #11 ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
02:55 — ပိတ်ဆို့နံပါတ် 10 မှ နောက်ဆုံး node သည် ငွေပေးငွေယူများ ပြီးသွားသည်။
10:59 — block #9 ၏တင်ပြမှုနှင့်အတူ ငွေပေးငွေယူသည် အရင်းကွင်းဆက်တွင် အချိန်အတော်အတန်ကြာခဲ့သော်လည်း ပြီးမြောက်ခဲ့ပြီး node များအားလုံးသည် ၎င်းနှင့်ပတ်သက်သည့်အချက်အလက်များကိုလက်ခံရရှိပြီး 350k အရောင်းအ၀ယ်များကိုစတင်လုပ်ဆောင်ခဲ့သည်။
11:05 - ပိတ်ဆို့ #320 တွင်ထည့်ထားသော 11k အရောင်းအ၀ယ်များအတွက် ရေကူးကန်မှရှင်းလင်းသွားသည်
12:10 - node များအားလုံးတွင် ငွေပေးငွေယူ 1 ဒသမ 670k နှင့် တိုကင်များပါရှိသည်။
12:17 — submit node သည် pool မှ 330k အရောင်းအ၀ယ်ပြုလုပ်ပြီး forms block #12
12:32 — block #12 ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား nodeများသို့ ပေးပို့သည်။
12:39 — block #12 ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
13:44 - ပိတ်ဆို့နံပါတ် 12 ကိုထည့်သွင်းပြီး 330k အရောင်းအ၀ယ်ပြုလုပ်သည့် အမြစ်ကွင်းဆက်မှ ဆုံမှတ်အားလုံးမှ သတင်းအချက်အလက်ကို ရရှိခဲ့သည်။
14:50 - node အားလုံးတွင် ငွေပေးငွေယူ 2 သန်းနှင့် တိုကင်များ ပါရှိသည်။

စမ်းသပ်မှု ၁

ပထမနှင့် ဒုတိယ ဆာဗာများတွင်၊ မှန်ကန်သည့် ကုဒ်တစ်ခုအား တင်သွင်းသည့် ကုဒ်ဖြင့် အစားထိုးခဲ့သည်။

ကနဦးအခြေအနေ- နောက်ဆုံးပိတ်ဆို့ #84; ဒေတာဘေ့စ်တွင် သိမ်းဆည်းထားသော ၀င်ငွေများနှင့် တိုကင်များ

00:00 — တစ်ခုလျှင် ငွေပေးငွေယူ 3 သန်းကို ထုတ်လုပ်ပြီး ပေးပို့သည့် script 1 ခုကို စတင်လိုက်ပါပြီ။
01:38 — လွှဲပြောင်းမှု 1 သန်းကို ဖန်တီးပြီး node #3 ကို စတင်တင်သွင်းရန် ပေးပို့ခဲ့သည်။
01:50 — ပေးပို့ရန် node နံပါတ် 3 သည် ရေကူးကန်မှ ငွေပေးငွေယူ 330k ကို ရယူပြီး ပုံစံများ ပိတ်ဆို့ခြင်း #85 (f21)။ 350k အရောင်းအ၀ယ်များကို 10 စက္ကန့်အတွင်း ရေကူးကန်သို့ ပေါင်းထည့်သည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။
01:53 — လွှဲပြောင်းမှု 1 သန်းကို ဖန်တီးပြီး node #1 ကို စတင်တင်သွင်းရန် ပေးပို့ခဲ့သည်။
01:50 — ပေးပို့ရန် node နံပါတ် 3 သည် ရေကူးကန်မှ ငွေပေးငွေယူ 330k ကို ရယူပြီး ပုံစံများ ပိတ်ဆို့ခြင်း #85 (f21)။ 350k အရောင်းအ၀ယ်များကို 10 စက္ကန့်အတွင်း ရေကူးကန်သို့ ပေါင်းထည့်သည်ကိုလည်း ကျွန်ုပ်တို့တွေ့မြင်ရပါသည်။
02:01 — ပေးပို့ရန် node #1 သည် ရေကူးကန်မှ ငွေပေးငွေယူ 250k ကို ရယူပြီး ဖောင်များ ပိတ်ဆို့ခြင်း #85 (65e)
02:06 — ပိတ်ဆို့ #85 (f21) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်
02:08 — စက္ကန့် 3 အတွင်း ငွေပေးငွေယူ 1 သန်းကို ပေးပို့ခဲ့သော ဆာဗာ #30 ၏သရုပ်ပြ script သည် အလုပ်ပြီးသွားသည်
02:14 — ပိတ်ဆို့ #85 (f21) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
02:19 — ပိတ်ဆို့ #85 (65e) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်
02:22 — လွှဲပြောင်းမှု 1 သန်းကို ဖန်တီးပြီး node #2 ကို စတင်တင်သွင်းရန် ပေးပို့ခဲ့သည်။
02:27 — block #85 (65e) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပို့လိုက်သည်။
02:29 — ပေးပို့ရန် node နံပါတ် 2 သည် ရေကူးကန်မှ ငွေပေးငွေယူ 111855 ကို ရယူပြီး forms block #85 (256)။
02:36 — ပိတ်ဆို့ #85 (256) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်
02:36 — စက္ကန့် 1 အတွင်း ငွေပေးငွေယူ 1 သန်းကို ပေးပို့ခဲ့သော ဆာဗာ #42.5 ၏သရုပ်ပြ script သည် အလုပ်ပြီးသွားသည်
02:38 — ပိတ်ဆို့ #85 (256) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
03:08 — ဆာဗာနံပါတ် 2 ဇာတ်ညွှန်းသည် အလုပ်ပြီးသွားကာ 1 စက္ကန့်အတွင်း ငွေပေးချေမှု 47 သန်းကို ပေးပို့ခဲ့သည်။
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 သည် pool မှ ငွေပေးငွေယူပေါင်း 888145 ကို ရယူပြီး forms block #88 (214)၊ submit node #2 သည် pool မှ 750k အရောင်းအ၀ယ်ပြုလုပ်ပြီး forms block #88 (50a)၊ submit node #3 မှ 670k အရောင်းအ၀ယ်ပြုလုပ်ခဲ့ပါသည်။ ရေကူးကန်နှင့် ဖောင်တုံး #88 (d3b)
04:44 — ပိတ်ဆို့ #88 (d3b) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်
04:58 — ပိတ်ဆို့ #88 (214) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node သို့ ပေးပို့သည်
05:11 — block #88 (50a) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node များသို့ ပို့လိုက်သည်
05:11 — ပိတ်ဆို့ #85 (d3b) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
05:36 — ပိတ်ဆို့ #85 (214) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
05:43 - #88 (d3b)၊ #89(214) ကို ပိတ်ဆို့ထားသည့် အမြစ်ကွင်းဆက်မှ အချက်အလက်အားလုံးကို လက်ခံရရှိပြီး 670k၊ 750k အရောင်းအ၀ယ်များကို စတင်အသုံးပြုနေပြီဖြစ်သည်။
06:50 — ဆက်သွယ်ရေး ချို့ယွင်းမှုကြောင့် ပိတ်ဆို့ #85 (50a) ကို အတည်ပြုမထားပါ။
06:55 — ပေးပို့ရန် node #2 သည် ရေကူးကန်မှ ငွေပေးငွေယူ 888145 ကို ရယူပြီး ပုံစံ 90 (50a)
08:14 — block #90 (50a) ကို လက်မှတ်ရေးထိုးပြီး အတည်ပြုရန်အတွက် အခြား node များသို့ ပို့လိုက်သည်
09:04 — ပိတ်ဆို့ #90 (50a) ကို အတည်ပြုပြီး အမြစ်ကွင်းဆက်သို့ ပေးပို့သည်။
11:23 - ပိတ်ဆို့ #90 (50a) ကို ထည့်သွင်းထားသည့် အမြစ်ကွင်းဆက်မှ အချက်အလက်အားလုံးကို ရရှိပြီး 888145 အရောင်းအ၀ယ်များကို စတင်အသုံးပြုပါ။ တစ်ချိန်တည်းမှာပင်၊ ဆာဗာ #3 သည် blocks #88 (d3b)၊ #89(214) မှ ငွေပေးငွေယူများကို အသုံးပြုထားပြီးဖြစ်သည်
12:11 - ရေကန်များအားလုံး လွတ်နေပါသည်။
13:41 — ဆာဗာ #3 ၏ node အားလုံးတွင် ငွေပေးငွေယူ 3 သန်းနှင့် တိုကင်များ ပါရှိသည်။
14:35 — ဆာဗာ #1 ၏ node အားလုံးတွင် ငွေပေးငွေယူ 3 သန်းနှင့် တိုကင်များ ပါရှိသည်။
19:24 — ဆာဗာ #2 ၏ node အားလုံးတွင် ငွေပေးငွေယူ 3 သန်းနှင့် တိုကင်များ ပါရှိသည်။

အတားအဆီးများ

Plasma Cash ၏ဖွံ့ဖြိုးတိုးတက်မှုအတွင်း၊ ကျွန်ုပ်တို့သည် ဖြည်းဖြည်းချင်းဖြေရှင်းပြီး ဖြေရှင်းနေသော အောက်ပါပြဿနာများကို ကြုံတွေ့ခဲ့ရသည်-

1. အမျိုးမျိုးသောစနစ်လုပ်ဆောင်ချက်များ၏အပြန်အလှန်တွင်ပဋိပက္ခ။ ဥပမာအားဖြင့်၊ ရေကူးကန်တွင် ငွေပေးငွေယူများထည့်ခြင်း၏လုပ်ဆောင်ချက်သည် လုပ်ကွက်များတင်သွင်းခြင်းနှင့် မှန်ကန်ကြောင်းအတည်ပြုခြင်းလုပ်ငန်းကို ပိတ်ဆို့စေပြီး အရှိန်ကျဆင်းသွားစေသည်။

2. ဒေတာလွှဲပြောင်းမှုကုန်ကျစရိတ်ကို လျှော့ချနေစဉ် များပြားလှသော ငွေပေးငွေယူပမာဏကို မည်သို့ပေးပို့ရမည်ကို ချက်ချင်းရှင်းလင်းစွာ မသိရသေးပါ။

3. မြင့်မားသောရလဒ်များရရှိရန် ဒေတာကို မည်သည့်နေရာတွင် သိမ်းဆည်းရမည်ကို မရှင်းလင်းပါ။

4. ငွေပေးငွေယူ 1 သန်းရှိသော ဘလောက်တစ်ခု၏အရွယ်အစားသည် 100 MB ခန့်နေရာယူသောကြောင့် node များကြားတွင် ကွန်ရက်တစ်ခုကို မည်သို့စုစည်းရမည်ကို ရှင်းရှင်းလင်းလင်းမသိရသေးပါ။

5. single-threaded မုဒ်တွင် အလုပ်လုပ်ခြင်းသည် ရှည်လျားသော တွက်ချက်မှုများ ဖြစ်ပေါ်လာသောအခါ (ဥပမာ၊ Merkle သစ်ပင်ကို တည်ဆောက်ခြင်းနှင့် ၎င်း၏ hash တွက်ချက်ခြင်း) အကြား ချိတ်ဆက်မှုကို ဖြတ်တောက်ပေးပါသည်။

ဤအရာအားလုံးကို ကျွန်ုပ်တို့ မည်သို့ဖြေရှင်းခဲ့သနည်း။

Plasma Cash node ၏ ပထမဗားရှင်းသည် တစ်ချိန်တည်းတွင် အရာအားလုံးကို လုပ်ဆောင်နိုင်သည့် ပေါင်းစပ်တစ်မျိုးဖြစ်သည်- ငွေပေးငွေယူများကို လက်ခံခြင်း၊ ပိတ်ဆို့ခြင်းများကို တင်သွင်းခြင်းနှင့် အတည်ပြုခြင်းနှင့် ဒေတာဝင်ရောက်ခြင်းအတွက် API ကို ပံ့ပိုးပေးခြင်း။ NodeJS သည် မူလရင်းမြစ်တစ်ခုတည်း-ချည်မျှင်ဖြစ်သောကြောင့်၊ လေးလံသော Merkle သစ်ပင် တွက်ချက်မှုလုပ်ဆောင်ချက်သည် ပေါင်းထည့်ငွေပေးငွေယူလုပ်ဆောင်ချက်ကို ပိတ်ဆို့ခဲ့သည်။ ဤပြဿနာကိုဖြေရှင်းရန် ရွေးချယ်စရာနှစ်ခုကို ကျွန်ုပ်တို့တွေ့ခဲ့ရသည်-

1. NodeJS လုပ်ငန်းစဉ်များစွာကို စတင်ပါ၊ တစ်ခုစီသည် သီးခြားလုပ်ဆောင်ချက်များကို လုပ်ဆောင်သည်။

2. worker_threads ကိုသုံး၍ ကုဒ်၏အစိတ်အပိုင်း၏လုပ်ဆောင်မှုကို စာတွဲများအဖြစ် ရွှေ့ပါ။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် ရွေးချယ်စရာနှစ်ခုလုံးကို တစ်ချိန်တည်းတွင် အသုံးပြုခဲ့သည်- ကျွန်ုပ်တို့သည် သီးခြားစီလုပ်ဆောင်နိုင်သော node တစ်ခုကို အပိုင်း 3 ခုအဖြစ် ယုတ္တိနည်းကျကျ ပိုင်းခြားထားသော်လည်း တစ်ချိန်တည်းတွင် တစ်ပြိုင်နက်တည်း လုပ်ဆောင်နိုင်သည်

1. ရေကူးကန်သို့ ငွေပေးငွေယူများကို လက်ခံပြီး ဘလောက်များကို ဖန်တီးပေးသည့် တင်သွင်းမှု Node။

2. node များ၏တရားဝင်မှုကိုစစ်ဆေးသော validating node တစ်ခု။

3. API node - ဒေတာရယူရန်အတွက် API ကို ပံ့ပိုးပေးသည်။

ဤကိစ္စတွင်၊ သင်သည် cli ကို အသုံးပြု၍ unix socket မှတဆင့် node တစ်ခုစီသို့ ချိတ်ဆက်နိုင်သည်။

Merkle သစ်ပင်ကို တွက်ချက်ခြင်းကဲ့သို့သော လေးလံသောလုပ်ဆောင်မှုများကို သီးခြားကြိုးတစ်ခုအဖြစ်သို့ ရွှေ့ထားပါသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် Plasma Cash လုပ်ဆောင်ချက်အားလုံးကို တပြိုင်နက် ပျက်ကွက်ခြင်းမရှိဘဲ ပုံမှန်လုပ်ဆောင်နိုင်ခဲ့ပါသည်။

စနစ်အလုပ်လုပ်ပြီးသည်နှင့်၊ ကျွန်ုပ်တို့သည် အမြန်နှုန်းကို စတင်စမ်းသပ်ခဲ့ပြီး ကံမကောင်းစွာပဲ၊ တစ်စက္ကန့်လျှင် ငွေပေးငွေယူ ၅၀၀၀ နှင့် တစ်တုံးလျှင် ငွေလွှဲခ 5 အထိ ရရှိခဲ့သည်။ လွဲမှားစွာ အကောင်အထည်ဖော်ခဲ့တာတွေကို အဖြေရှာခဲ့ရတယ်။

စတင်ရန်၊ ကျွန်ုပ်တို့သည် စနစ်၏ အထွတ်အထိပ် စွမ်းဆောင်ရည်ကို သိရှိနိုင်ရန် Plasma Cash နှင့် ဆက်သွယ်မှု ယန္တရားကို စတင်စမ်းသပ်ခဲ့ပါသည်။ 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 အင်ဂျင်ကို ကောင်းမွန်စွာ ပြုပြင်ရပါမည်။

ကျွန်ုပ်တို့သည် အတန်းများမှတစ်ဆင့် ငွေပေးငွေယူများ၊ တိုကင်များနှင့် ဘလောက်များနှင့်အတူ လုပ်ဆောင်ခဲ့သည်။ ထိုသို့သောအတန်းများကိုဖန်တီးသည့်အခါ OOP သည် ကျွန်ုပ်တို့အတွက် မသင့်လျော်ကြောင်း ညွှန်ပြသော စွမ်းဆောင်ရည် 2 ဆ ကျဆင်းသွားသည်။ အရာအားလုံးကို သပ်သပ်ရပ်ရပ် လုပ်ဆောင်တဲ့ ချဉ်းကပ်မှုတစ်ခုအဖြစ် ပြန်ရေးခဲ့ရတယ်။

ဒေတာဘေ့စ်တွင်မှတ်တမ်းတင်ခြင်း။

အစပိုင်းတွင်၊ Redis သည် ကျွန်ုပ်တို့၏လိုအပ်ချက်များကို ဖြည့်ဆည်းပေးသည့် အထိရောက်ဆုံးဖြေရှင်းချက်တစ်ခုအဖြစ် ဒေတာသိုလှောင်မှုအတွက် ရွေးချယ်ခံခဲ့ရသည်- သော့တန်ဖိုးသိုလှောင်မှု၊ hash tables၊ sets များနှင့်အလုပ်လုပ်သည်။ ကျွန်ုပ်တို့သည် redis-benchmark ကို စတင်ခဲ့ပြီး 80 ပိုက်လိုင်းမုဒ်တွင် တစ်စက္ကန့်လျှင် ~ 1k လည်ပတ်မှုများ ရရှိခဲ့သည်။

မြင့်မားသောစွမ်းဆောင်ရည်အတွက်၊ ကျွန်ုပ်တို့သည် Redis ကို ပိုမိုတိကျစွာ ချိန်ညှိထားသည်-

• unix socket ချိတ်ဆက်မှုတစ်ခုကို တည်ဆောက်ပြီးပါပြီ။
• ကျွန်ုပ်တို့သည် အခြေအနေအား ဒစ်တွင်သိမ်းဆည်းခြင်းကို ပိတ်ထားသည် (ယုံကြည်စိတ်ချရမှုအတွက်၊ သင်သည် ပုံတူတစ်ခုတည်ဆောက်ပြီး သီးခြား Redis တွင် disk သို့သိမ်းဆည်းနိုင်သည်)။

Redis တွင်၊ ရေကူးကန်သည် hash table တစ်ခုဖြစ်ပြီး ကျွန်ုပ်တို့သည် စုံစမ်းမေးမြန်းမှုတစ်ခုတွင် ငွေပေးငွေယူအားလုံးကို ပြန်လည်ရယူရန်နှင့် တစ်ခုပြီးတစ်ခု လွှဲပြောင်းမှုများကို ဖျက်ရန် လိုအပ်သောကြောင့်ဖြစ်သည်။ ကျွန်ုပ်တို့သည် ပုံမှန်စာရင်းကို အသုံးပြုရန် ကြိုးစားသော်လည်း စာရင်းတစ်ခုလုံးကို ပြန်ဖွင့်သောအခါတွင် နှေးကွေးပါသည်။

စံ NodeJS ကိုအသုံးပြုသောအခါ၊ Redis စာကြည့်တိုက်များသည် တစ်စက္ကန့်လျှင် 18k အရောင်းအ၀ယ်ပြုလုပ်မှု၏စွမ်းဆောင်ရည်ကိုရရှိခဲ့သည်။ အရှိန်က ၉ ဆ ကျဆင်းသွားတယ်။

စံသတ်မှတ်ချက်သည် ဖြစ်နိုင်ခြေများကို ရှင်းရှင်းလင်းလင်း 5 ဆ ပိုကြီးသည်ကို ပြသသောကြောင့်၊ ကျွန်ုပ်တို့သည် အကောင်းဆုံးဖြစ်အောင်လုပ်ခဲ့သည်။ ကျွန်ုပ်တို့သည် စာကြည့်တိုက်ကို ioredis အဖြစ်ပြောင်းပြီး တစ်စက္ကန့်လျှင် 25k နှုန်းဖြင့် စွမ်းဆောင်နိုင်ခဲ့သည်။ `hset` အမိန့်ကို အသုံးပြု၍ ငွေပေးငွေယူများကို တစ်ခုပြီးတစ်ခု ပေါင်းထည့်ပါသည်။ ထို့ကြောင့် ကျွန်ုပ်တို့သည် Redis တွင် မေးခွန်းများစွာကို ဖန်တီးနေပါသည်။ ငွေပေးငွေယူများကို အစုအဝေးများအဖြစ် ပေါင်းစပ်ကာ `hmset` တစ်ခုတည်းဖြင့် ပေးပို့ရန် စိတ်ကူးပေါ်လာသည်။ ရလဒ်သည် တစ်စက္ကန့်လျှင် 32k ဖြစ်သည်။

အောက်တွင်ဖော်ပြထားသော အကြောင်းရင်းများစွာအတွက်၊ ကျွန်ုပ်တို့သည် `Buffer` ကိုအသုံးပြု၍ ဒေတာဖြင့်အလုပ်လုပ်ပြီး ၎င်းကို စာသား (`buffer.toString('hex')`) သို့ မရေးမီတွင် အပိုထပ်ဆောင်းရနိုင်သည် ။ စွမ်းဆောင်ရည်။ ထို့ကြောင့် တစ်စက္ကန့်လျှင် 35k အထိ အရှိန်မြှင့်ခဲ့သည်။ လောလောဆယ်တွင်၊ ကျွန်ုပ်တို့သည် နောက်ထပ် optimization ကို ရပ်ဆိုင်းရန် ဆုံးဖြတ်ခဲ့သည်။

ကျွန်ုပ်တို့သည် binary protocol သို့ပြောင်းရသောကြောင့်-

1. စနစ်သည် မကြာခဏ ဟက်ရှ်များ၊ လက်မှတ်များ စသည်တို့ကို တွက်ချက်ပြီး ၎င်းအတွက် `Buffer တွင် ဒေတာ လိုအပ်သည်။

2. ဝန်ဆောင်မှုများကြားတွင် ပေးပို့သည့်အခါ၊ ဒွိဒေတာသည် စာသားထက် အလေးချိန်နည်းသည်။ ဥပမာအားဖြင့်၊ ငွေပေးငွေယူ ၁ သန်းဖြင့် ဘလောက်တစ်ခုကို ပို့သောအခါ၊ စာသားပါဒေတာသည် 1 megabytes ထက်ပိုယူနိုင်သည်။

3. ဒေတာကို အဆက်မပြတ်ပြောင်းလဲခြင်းသည် စွမ်းဆောင်ရည်အပေါ် သက်ရောက်မှုရှိသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် အံ့သြဖွယ်ကောင်းသော `binary-data` စာကြည့်တိုက်ကို အခြေခံ၍ တီထွင်ထားသည့် ကျွန်ုပ်တို့၏ကိုယ်ပိုင် ဒွိပရိုတိုကောကို သိမ်းဆည်းခြင်းနှင့် ပို့လွှတ်ခြင်းအတွက် အခြေခံအဖြစ် ယူခဲ့သည်။

ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် အောက်ပါဒေတာဖွဲ့စည်းပုံများကို ရရှိခဲ့ပါသည်။

- ငွေပေးငွေယူ

  ```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` သို့ ပြောင်းလဲပေးပါသည်။ data တွေကို ပြန်ပေးတယ်။

ဝန်ဆောင်မှုများအကြား ဒေတာလွှဲပြောင်းခြင်းအတွက် binary protocol 2 ခုလည်း ရှိပါသည်။

- Unix socket မှတစ်ဆင့် Plasma Node နှင့် အပြန်အလှန်ဆက်ဆံရန်အတွက် ပရိုတိုကော

  ```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` — တုံ့ပြန်မှုကို ဖော်ထုတ်နိုင်စေရန် မက်ဆေ့ခ်ျအိုင်ဒီ။

- node များကြား အပြန်အလှန်အကျိုးသက်ရောက်မှုအတွက် ပရိုတိုကော

  ```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;
• `ဗားရှင်းပရိုတိုကော` — ပရိုတိုကောဗားရှင်း၊ မတူညီသောဗားရှင်းများပါရှိသော node များကို network ပေါ်တွင်တင်နိုင်ပြီး ကွဲပြားစွာအလုပ်လုပ်နိုင်သောကြောင့်၊
• `seq` - မက်ဆေ့ချ်သတ်မှတ်စနစ်;
• `countChunk` и `အတုံးနံပါတ်` ကြီးမားသောစာတိုများကိုခွဲခြမ်းရန်အတွက်လိုအပ်သော၊
• `အရှည်` и `ဝန်ဆောင်ခ` အရှည်နှင့် ဒေတာ ကိုယ်တိုင်။

ဒေတာကို ကျွန်ုပ်တို့ ကြိုတင်ရိုက်ထားသောကြောင့် နောက်ဆုံးစနစ်သည် Ethereum ၏ `rlp` စာကြည့်တိုက်ထက် ပိုမိုမြန်ဆန်ပါသည်။ ကံမကောင်းစွာဖြင့်၊ ကျွန်ုပ်တို့သည် အနာဂတ်တွင် လုပ်ဆောင်ရန် စီစဉ်ထားသည့် စမတ်စာချုပ်ကို အပြီးသတ်ရန် လိုအပ်သောကြောင့် ၎င်းကို ကျွန်ုပ်တို့ မငြင်းဆိုနိုင်သေးပါ။

အရှိန်အဟုန်နဲ့ ရောက်အောင် ထိန်းနိုင်ခဲ့ရင် 35 000 စက္ကန့်အလိုက် ငွေပေးငွေယူများ၊ ကျွန်ုပ်တို့သည်လည်း ၎င်းတို့ကို အကောင်းဆုံးအချိန်အတွင်း လုပ်ဆောင်ရန် လိုအပ်ပါသည်။ ခန့်မှန်းခြေအားဖြင့် ဘလောက်ဖွဲ့စည်းချိန်သည် စက္ကန့် 30 ကြာသောကြောင့်၊ ကျွန်ုပ်တို့သည် ဘလောက်ထဲတွင် ထည့်သွင်းရန် လိုအပ်ပါသည်။ 1 000 000 ငွေပေးငွေယူ ဆိုသည်မှာ များများပို့ခြင်းကို ဆိုလိုသည်။ 100 ဒေတာ MB

အစပိုင်းတွင်၊ ကျွန်ုပ်တို့သည် node များကြား ဆက်သွယ်ရန် `ethereumjs-devp2p` စာကြည့်တိုက်ကို အသုံးပြုခဲ့သော်လည်း ဒေတာများစွာကို မကိုင်တွယ်နိုင်ပါ။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် `ws` စာကြည့်တိုက်ကို အသုံးပြုပြီး websocket မှတစ်ဆင့် binary data ပေးပို့ခြင်းကို စီစဉ်သတ်မှတ်ထားပါသည်။ ဟုတ်ပါတယ်၊ ဒေတာပက်ကေ့ခ်ျကြီးတွေကို ပို့တဲ့အခါ ပြဿနာတွေလည်း ကြုံခဲ့ရပေမယ့် အဲဒါတွေကို အတုံးလိုက် ခွဲလိုက်တဲ့အတွက် အခု ဒီပြဿနာတွေ ပျောက်သွားပါပြီ။

Merkle သစ်ပင်တစ်ပင်ကိုဖွဲ့စည်းပြီး hash ကိုတွက်ချက်သည်။ 1 000 000 အရောင်းအ ၀ ယ်များအကြောင်းလိုအပ်သည်။ 10 စက္ကန့်များကို ဆက်တိုက် တွက်ချက်သည်။ ဤအချိန်အတောအတွင်း၊ node အားလုံးနှင့် ချိတ်ဆက်မှု ပျက်သွားနိုင်သည်။ ဤတွက်ချက်မှုကို သီးခြားချည်တစ်ခုသို့ ရွှေ့ရန် ဆုံးဖြတ်ခဲ့သည်။

ကောက်ချက်:

တကယ်တော့၊ ကျွန်တော်တို့ရဲ့ တွေ့ရှိချက်တွေဟာ အသစ်အဆန်းမဟုတ်ပေမယ့် ပညာရှင်တော်တော်များများက တီထွင်ဖန်တီးတဲ့အခါ အဲဒါတွေကို မေ့သွားကြပါတယ်။

• Object-Oriented Programming အစား Functional Programming ကိုအသုံးပြုခြင်းသည် ကုန်ထုတ်စွမ်းအားကို တိုးတက်စေသည်။
• Monolith သည် ဖြစ်ထွန်းသော NodeJS စနစ်အတွက် ဝန်ဆောင်မှုဗိသုကာတစ်ခုထက် ပိုဆိုးသည်။
• လေးလံသောတွက်ချက်မှုအတွက် `worker_threads` ကိုအသုံးပြုခြင်းသည် အထူးသဖြင့် i/o လုပ်ဆောင်ချက်များကို ကိုင်တွယ်သောအခါတွင် စနစ်၏တုံ့ပြန်မှုကို ပိုမိုကောင်းမွန်စေသည်။
• unix socket သည် http တောင်းဆိုမှုများထက် ပိုမိုတည်ငြိမ်ပြီး ပိုမြန်သည်။
• အကယ်၍ သင်သည် ကွန်ရက်ပေါ်တွင် ကြီးမားသောဒေတာကို လျင်မြန်စွာလွှဲပြောင်းရန် လိုအပ်ပါက၊ websockets များကို အသုံးပြုပြီး binary data များကို အပိုင်းများခွဲ၍ ပေးပို့ခြင်းသည် ပိုကောင်းသည်၊ ၎င်းတို့ရောက်လာပါက ထပ်ဆင့်ပေးပို့နိုင်ပြီး မက်ဆေ့ချ်တစ်ခုသို့ ပေါင်းစပ်နိုင်သည်။

လာရောက်လည်ပတ်ဖို့ ဖိတ်ခေါ်ပါတယ်။ GitHub ပရောဂျက်- https://github.com/opporty-com/Plasma-Cash/tree/new-version

ဆောင်းပါးကို ပူးတွဲရေးသားခဲ့သည်။ Alexander Nashivanအကြီးတန်းပြုစုသူ Clever Solution Inc.

source: www.habr.com