ការធ្វើតេស្តសាធារណៈ៖ ដំណោះស្រាយសម្រាប់ភាពឯកជន និងការធ្វើមាត្រដ្ឋាននៅលើ Ethereum

blockchain គឺជាបច្ចេកវិទ្យាច្នៃប្រឌិតថ្មីដែលសន្យាថានឹងធ្វើឱ្យប្រសើរឡើងនូវវិស័យជាច្រើននៃជីវិតមនុស្ស។ វាផ្ទេរដំណើរការ និងផលិតផលពិតៗទៅក្នុងលំហឌីជីថល ធានានូវល្បឿន និងភាពជឿជាក់នៃប្រតិបត្តិការហិរញ្ញវត្ថុ កាត់បន្ថយការចំណាយរបស់ពួកគេ ហើយក៏អនុញ្ញាតឱ្យអ្នកបង្កើតកម្មវិធី DAPP ទំនើបដោយប្រើកិច្ចសន្យាឆ្លាតវៃនៅក្នុងបណ្តាញវិមជ្ឈការ។

ដោយទទួលបានអត្ថប្រយោជន៍ជាច្រើន និងកម្មវិធីចម្រុះនៃ blockchain វាអាចហាក់ដូចជាគួរឱ្យភ្ញាក់ផ្អើលដែលបច្ចេកវិទ្យាដ៏ជោគជ័យនេះមិនទាន់បានឈានទៅដល់គ្រប់ឧស្សាហកម្មទាំងអស់នៅឡើយ។ បញ្ហាគឺថា blockchains វិមជ្ឈការទំនើបខ្វះលទ្ធភាពធ្វើមាត្រដ្ឋាន។ Ethereum ដំណើរការប្រហែល 20 ប្រតិបត្តិការក្នុងមួយវិនាទី ដែលមិនគ្រប់គ្រាន់ដើម្បីបំពេញតម្រូវការនៃអាជីវកម្មដែលមានថាមពលនាពេលបច្ចុប្បន្ននេះ។ ទន្ទឹមនឹងនេះដែរក្រុមហ៊ុនដែលប្រើបច្ចេកវិទ្យា blockchain ស្ទាក់ស្ទើរក្នុងការបោះបង់ចោល Ethereum ដោយសារតែកម្រិតខ្ពស់នៃការការពារពីការលួចចូល និងការបរាជ័យបណ្តាញ។

ដើម្បីធានាបាននូវវិមជ្ឈការ សុវត្ថិភាព និងការធ្វើមាត្រដ្ឋាននៅក្នុង blockchain ដូច្នេះការដោះស្រាយ Scalability Trilemma ក្រុមអភិវឌ្ឍន៍ ឱកាស បានបង្កើត Plasma Cash ដែលជាខ្សែសង្វាក់បុត្រសម្ព័ន្ធដែលមានកិច្ចសន្យាឆ្លាតវៃ និងបណ្តាញឯកជនផ្អែកលើ Node.js ដែលផ្ទេរស្ថានភាពរបស់វាជាទៀងទាត់ទៅខ្សែសង្វាក់ឫស (Ethereum) ។

ដំណើរការសំខាន់ៗនៅក្នុង Plasma Cash

1. អ្នកប្រើប្រាស់ហៅមុខងារកិច្ចសន្យាឆ្លាតវៃថា 'ការដាក់ប្រាក់' ដោយបញ្ចូលទៅក្នុងវានូវបរិមាណ ETH ដែលគាត់ចង់ដាក់ចូលទៅក្នុងផ្លាកសញ្ញាសាច់ប្រាក់ប្លាស្មា។ មុខងារកិច្ចសន្យាឆ្លាតវៃបង្កើតសញ្ញាសម្ងាត់ និងបង្កើតព្រឹត្តិការណ៍អំពីវា។

2. ថ្នាំងសាច់ប្រាក់ប្លាស្មាដែលបានជាវព្រឹត្តិការណ៍កិច្ចសន្យាឆ្លាតវៃទទួលបានព្រឹត្តិការណ៍អំពីការបង្កើតប្រាក់បញ្ញើ និងបន្ថែមប្រតិបត្តិការអំពីការបង្កើតនិមិត្តសញ្ញាទៅក្នុងអាង។

3. តាមកាលកំណត់ ថ្នាំងប្លាស្មាសាច់ប្រាក់ពិសេសយកប្រតិបត្តិការទាំងអស់ពីអាង (រហូតដល់ 1 លាន) ហើយបង្កើតប្លុកពីពួកវា គណនាមែកធាង Merkle ហើយតាមនោះ សញ្ញា។ ប្លុកនេះត្រូវបានបញ្ជូនទៅថ្នាំងផ្សេងទៀតសម្រាប់ការផ្ទៀងផ្ទាត់។ ថ្នាំងពិនិត្យមើលថាតើលេខសម្ងាត់ Merkle មានសុពលភាពដែរឬទេ និងថាតើប្រតិបត្តិការមានសុពលភាពដែរឬទេ (ឧទាហរណ៍ ថាតើអ្នកផ្ញើសញ្ញាសម្ងាត់គឺជាម្ចាស់របស់វាទេ)។ បន្ទាប់ពីផ្ទៀងផ្ទាត់ប្លុក នោះថ្នាំងហៅមុខងារ 'submitBlock' នៃកិច្ចសន្យាឆ្លាតវៃ ដែលរក្សាទុកលេខប្លុក និង Merkle hash ទៅខ្សែសង្វាក់គែម។ កិច្ចសន្យាឆ្លាតវៃបង្កើតព្រឹត្តិការណ៍ដែលបង្ហាញពីការបន្ថែមប្លុកដោយជោគជ័យ។ ប្រតិបត្តិការត្រូវបានយកចេញពីអាង។

4. ថ្នាំងដែលទទួលព្រឹត្តិការណ៍ដាក់ស្នើប្លុកចាប់ផ្តើមអនុវត្តប្រតិបត្តិការដែលត្រូវបានបន្ថែមទៅប្លុក។

5. នៅចំណុចខ្លះ ម្ចាស់ (ឬមិនមែនម្ចាស់) នៃសញ្ញាសម្ងាត់ចង់ដកវាចេញពី Plasma Cash ។ ដើម្បីធ្វើដូចនេះគាត់បានហៅមុខងារ 'startExit' ដោយបញ្ចូលព័ត៌មានអំពីប្រតិបត្តិការ 2 ចុងក្រោយនៅលើសញ្ញាសម្ងាត់ ដែលបញ្ជាក់ថាគាត់ជាម្ចាស់និមិត្តសញ្ញា។ កិច្ចសន្យាឆ្លាតវៃដោយប្រើសញ្ញា Merkle ពិនិត្យមើលវត្តមាននៃប្រតិបត្តិការនៅក្នុងប្លុក និងផ្ញើសញ្ញាសម្ងាត់សម្រាប់ការដកប្រាក់ដែលនឹងកើតឡើងក្នុងរយៈពេលពីរសប្តាហ៍។

6. ប្រសិនបើប្រតិបត្តិការដកសញ្ញាសម្ងាត់បានកើតឡើងជាមួយនឹងការរំលោភបំពាន (និមិត្តសញ្ញាត្រូវបានចំណាយបន្ទាប់ពីនីតិវិធីដកប្រាក់បានចាប់ផ្តើម ឬសញ្ញាសម្ងាត់គឺជារបស់អ្នកផ្សេងមុនការដកប្រាក់) ម្ចាស់និមិត្តសញ្ញាអាចបដិសេធការដកនេះក្នុងរយៈពេលពីរសប្តាហ៍។

ភាពឯកជនត្រូវបានសម្រេចតាមពីរវិធី

1. ខ្សែសង្វាក់ឫសមិនដឹងអ្វីទាំងអស់អំពីប្រតិបត្តិការដែលត្រូវបានបង្កើត និងបញ្ជូនបន្តនៅក្នុងខ្សែសង្វាក់កុមារ។ ព័ត៌មានអំពីអ្នកដែលដាក់ប្រាក់ និងដក ETH ពី Plasma Cash នៅតែជាសាធារណៈ។

2. ខ្សែសង្វាក់កុមារអនុញ្ញាតឱ្យប្រតិបត្តិការអនាមិកដោយប្រើ zk-SNARKs ។

ជង់បច្ចេកវិទ្យា

• NodeJS
• Redis
• អេធើរ្យូម
• Sild

សាកល្បង

ខណៈពេលដែលកំពុងអភិវឌ្ឍ Plasma Cash យើងបានសាកល្បងល្បឿននៃប្រព័ន្ធ ហើយទទួលបានលទ្ធផលដូចខាងក្រោម៖

• រហូតដល់ 35 ប្រតិបត្តិការក្នុងមួយវិនាទីត្រូវបានបន្ថែមទៅក្នុងអាង។
• ប្រតិបត្តិការរហូតដល់ 1 អាចត្រូវបានរក្សាទុកក្នុងប្លុកមួយ។

ការធ្វើតេស្តត្រូវបានធ្វើឡើងនៅលើម៉ាស៊ីនមេចំនួន 3 ខាងក្រោម៖

1. Intel Core i7-6700 Quad-Core Skylake រួមបញ្ចូល។ NVMe SSD - 512 GB, RAM 64 GB DDR4
ថ្នាំងសាច់ប្រាក់ប្លាស្មាដែលមានសុពលភាពចំនួន 3 ត្រូវបានលើកឡើង។

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, RAM 64 GB DDR4
ថ្នាំង Ropsten testnet ETH ត្រូវបានលើកឡើង។
ថ្នាំងសាច់ប្រាក់ប្លាស្មាដែលមានសុពលភាពចំនួន 3 ត្រូវបានលើកឡើង។

3. Intel Core i9-9900K Octa-Core រួមបញ្ចូល។ NVMe SSD - 1 TB, RAM 64 GB DDR4
1 ថ្នាំងបញ្ជូនសាច់ប្រាក់ប្លាស្មាត្រូវបានលើកឡើង។
ថ្នាំងសាច់ប្រាក់ប្លាស្មាដែលមានសុពលភាពចំនួន 3 ត្រូវបានលើកឡើង។
ការធ្វើតេស្តត្រូវបានចាប់ផ្តើមដើម្បីបន្ថែមប្រតិបត្តិការទៅកាន់បណ្តាញ Plasma Cash ។

សរុប: ថ្នាំងសាច់ប្រាក់ប្លាស្មាចំនួន 10 នៅក្នុងបណ្តាញឯកជន។

តេស្ត ១

មានដែនកំណត់ 1 លានប្រតិបត្តិការក្នុងមួយប្លុក។ ដូច្នេះ 1 លានប្រតិបត្តិការធ្លាក់ចូលទៅក្នុង 2 ប្លុក (ចាប់តាំងពីប្រព័ន្ធគ្រប់គ្រងដើម្បីយកផ្នែកនៃប្រតិបត្តិការនិងដាក់ស្នើខណៈពេលដែលពួកគេកំពុងត្រូវបានផ្ញើ) ។

ស្ថានភាពដំបូង៖ ប្លុកចុងក្រោយ #7; ប្រតិបត្តិការ និងសញ្ញាសម្ងាត់ចំនួន 1 លានត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ។

00:00 - ការចាប់ផ្តើមនៃការបង្កើតស្គ្រីបប្រតិបត្តិការ
01:37 - ប្រតិបត្តិការ 1 លានត្រូវបានបង្កើតឡើង ហើយការផ្ញើទៅកាន់ថ្នាំងបានចាប់ផ្តើម
01: 46 - ដាក់ស្នើថ្នាំងបានយកប្រតិបត្តិការ 240k ពីអាងនិងទម្រង់ប្លុកលេខ 8 ។ យើងក៏ឃើញដែរថាប្រតិបត្តិការ 320k ត្រូវបានបន្ថែមទៅក្នុងអាងក្នុងរយៈពេល 10 វិនាទី
01:58 — ប្លុក #8 ត្រូវបានចុះហត្ថលេខា និងផ្ញើសម្រាប់សុពលភាព
02:03 — ប្លុកលេខ 8 ត្រូវបានធ្វើឱ្យមានសុពលភាពហើយមុខងារ 'submitBlock' នៃកិច្ចសន្យាឆ្លាតវៃត្រូវបានហៅជាមួយលេខសញ្ញា Merkle និងលេខប្លុក
02:10 - ស្គ្រីបសាកល្បងបានបញ្ចប់ដំណើរការ ដែលបានបញ្ជូនប្រតិបត្តិការ 1 លានក្នុងរយៈពេល 32 វិនាទី
02:33 - ថ្នាំងចាប់ផ្តើមទទួលបានព័ត៌មានថាប្លុក #8 ត្រូវបានបន្ថែមទៅខ្សែសង្វាក់ឫស ហើយចាប់ផ្តើមធ្វើប្រតិបត្តិការ 240k
02:40 - ប្រតិបត្តិការ 240k ត្រូវបានដកចេញពីអាង ដែលស្ថិតនៅក្នុងប្លុក #8 រួចហើយ
02: 56 - ដាក់ស្នើថ្នាំងបានយកប្រតិបត្តិការ 760k ដែលនៅសល់ពីអាង ហើយចាប់ផ្តើមគណនា Merkle hash និងការចុះហត្ថលេខាប្លុក #9
03:20 - ថ្នាំងទាំងអស់មានប្រតិបត្តិការ និងសញ្ញាសម្ងាត់ 1 លាន 240k
03:35 — ប្លុក #9 ត្រូវបានចុះហត្ថលេខា និងផ្ញើសម្រាប់សុពលភាពទៅកាន់ថ្នាំងផ្សេងទៀត។
03:41 - កំហុសបណ្តាញបានកើតឡើង
04:40 - ការរង់ចាំសម្រាប់ប្លុក #9 សុពលភាពបានផុតកំណត់
04: 54 - ដាក់ស្នើថ្នាំងបានយកប្រតិបត្តិការ 760k ដែលនៅសល់ពីអាង ហើយចាប់ផ្តើមគណនា Merkle hash និងការចុះហត្ថលេខាប្លុក #9
05:32 — ប្លុក #9 ត្រូវបានចុះហត្ថលេខា និងផ្ញើសម្រាប់សុពលភាពទៅកាន់ថ្នាំងផ្សេងទៀត។
05: 53 - ប្លុក # 9 ត្រូវបានធ្វើឱ្យមានសុពលភាពហើយត្រូវបានបញ្ជូនទៅខ្សែសង្វាក់ឫស
06:17 - ថ្នាំងចាប់ផ្តើមទទួលបានព័ត៌មានដែលប្លុក #9 ត្រូវបានបន្ថែមទៅខ្សែសង្វាក់ឫស ហើយចាប់ផ្តើមធ្វើប្រតិបត្តិការ 760k
06: 47 - អាងបានសម្អាតប្រតិបត្តិការដែលមាននៅក្នុងប្លុក #9
09:06 - ថ្នាំងទាំងអស់មានប្រតិបត្តិការ និងសញ្ញាសម្ងាត់ចំនួន 2 លាន

តេស្ត ១

មានដែនកំណត់ 350k ក្នុងមួយប្លុក។ ជាលទ្ធផលយើងមាន 3 ប្លុក។

ស្ថានភាពដំបូង៖ ប្លុកចុងក្រោយ #9; ប្រតិបត្តិការ និងសញ្ញាសម្ងាត់ចំនួន 2 លានត្រូវបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ

00:00 — ស្គ្រីបជំនាន់ប្រតិបត្តិការត្រូវបានដាក់ឱ្យដំណើរការរួចហើយ
00:44 - ប្រតិបត្តិការ 1 លានត្រូវបានបង្កើតឡើង ហើយការផ្ញើទៅកាន់ថ្នាំងបានចាប់ផ្តើម
00: 56 - ដាក់ស្នើថ្នាំងបានយកប្រតិបត្តិការ 320k ពីអាងនិងទម្រង់ប្លុកលេខ 10 ។ យើងក៏ឃើញដែរថាប្រតិបត្តិការ 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 លាន

តេស្ត ១

នៅក្នុងម៉ាស៊ីនមេទីមួយ និងទីពីរ ថ្នាំងដែលមានសុពលភាពមួយត្រូវបានជំនួសដោយថ្នាំងបញ្ជូន។

ស្ថានភាពដំបូង៖ ប្លុកចុងក្រោយ #84; 0 ប្រតិបត្តិការ និងសញ្ញាសម្ងាត់ដែលបានរក្សាទុកក្នុងមូលដ្ឋានទិន្នន័យ

00:00 — ស្គ្រីប 3 ត្រូវបានដាក់ឱ្យដំណើរការ ដែលបង្កើត និងផ្ញើ 1 លានប្រតិបត្តិការនីមួយៗ
01:38 — ប្រតិបត្តិការចំនួន 1 លានត្រូវបានបង្កើតឡើង ហើយការផ្ញើទៅដាក់ស្នើលេខ 3 បានចាប់ផ្តើម
01:50 — ដាក់ស្នើថ្នាំង #3 បានយកប្រតិបត្តិការ 330k ពីអាង និងទម្រង់ប្លុក #85 (f21)។ យើងក៏ឃើញដែរថាប្រតិបត្តិការ 350k ត្រូវបានបន្ថែមទៅក្នុងអាងក្នុងរយៈពេល 10 វិនាទី
01:53 — ប្រតិបត្តិការចំនួន 1 លានត្រូវបានបង្កើតឡើង ហើយការផ្ញើទៅដាក់ស្នើលេខ 1 បានចាប់ផ្តើម
01:50 — ដាក់ស្នើថ្នាំង #3 បានយកប្រតិបត្តិការ 330k ពីអាង និងទម្រង់ប្លុក #85 (f21)។ យើងក៏ឃើញដែរថាប្រតិបត្តិការ 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 — ស្គ្រីប server #2 បានបញ្ចប់ដំណើរការ ដែលបញ្ជូនប្រតិបត្តិការ 1 លានក្នុងរយៈពេល 47 វិនាទី
០៣:៣៨ - ថ្នាំងទាំងអស់បានទទួលព័ត៌មានពីខ្សែសង្វាក់ឫសដែលរារាំង #03 (f38), #85(21e), #86(65) ត្រូវបានបន្ថែម ហើយចាប់ផ្តើមអនុវត្តប្រតិបត្តិការ 87k, 256k, 330
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 លាន

ឧបសគ្គ

កំឡុងពេលបង្កើត Plasma Cash យើងបានជួបប្រទះបញ្ហាដូចខាងក្រោម ដែលយើងដោះស្រាយបណ្តើរៗ ហើយកំពុងដោះស្រាយ៖

1. ជម្លោះក្នុងអន្តរកម្មនៃមុខងារប្រព័ន្ធផ្សេងៗ។ ឧទាហរណ៍ មុខងារនៃការបន្ថែមប្រតិបត្តិការទៅអាងបានរារាំងការងារនៃការដាក់ស្នើ និងធ្វើឱ្យប្លុកមានសុពលភាព ហើយផ្ទុយទៅវិញ ដែលនាំឱ្យល្បឿនធ្លាក់ចុះ។

2. វាមិនច្បាស់ភ្លាមៗអំពីរបៀបផ្ញើចំនួនដ៏ធំនៃប្រតិបត្តិការខណៈពេលដែលកាត់បន្ថយការចំណាយលើការផ្ទេរទិន្នន័យ។

3. វាមិនច្បាស់អំពីរបៀប និងកន្លែងដែលត្រូវរក្សាទុកទិន្នន័យដើម្បីទទួលបានលទ្ធផលខ្ពស់។

4. វាមិនច្បាស់អំពីរបៀបរៀបចំបណ្តាញរវាងថ្នាំងទេ ដោយសារទំហំនៃប្លុកដែលមានប្រតិបត្តិការ 1 លានត្រូវចំណាយពេលប្រហែល 100 មេកាបៃ។

5. ការធ្វើការនៅក្នុងរបៀបខ្សែតែមួយបំបែកការតភ្ជាប់រវាងថ្នាំងនៅពេលដែលការគណនាដ៏វែងកើតឡើង (ឧទាហរណ៍ ការសាងសង់មែកធាង Merkle និងការគណនាសញ្ញារបស់វា)។

តើ​យើង​បាន​ដោះស្រាយ​បញ្ហា​ទាំង​អស់​នេះ​ដោយ​របៀប​ណា?

កំណែដំបូងនៃ Plasma Cash node គឺជាប្រភេទបន្សំដែលអាចធ្វើអ្វីៗគ្រប់យ៉ាងក្នុងពេលតែមួយ៖ ទទួលយកប្រតិបត្តិការ ដាក់ស្នើ និងធ្វើឱ្យប្លុកមានសុពលភាព និងផ្តល់ API សម្រាប់ការចូលប្រើទិន្នន័យ។ ដោយសារ NodeJS មានដើមតែមួយខ្សែ មុខងារគណនាមែកធាង Merkle ធ្ងន់បានរារាំងមុខងារបន្ថែមប្រតិបត្តិការ។ យើងបានឃើញជម្រើសពីរសម្រាប់ដោះស្រាយបញ្ហានេះ៖

1. ចាប់ផ្តើមដំណើរការ NodeJS ជាច្រើន ដែលនីមួយៗដំណើរការមុខងារជាក់លាក់។

2. ប្រើ worker_threads ហើយផ្លាស់ទីការប្រតិបត្តិនៃផ្នែកនៃកូដទៅជាខ្សែស្រឡាយ។

ជាលទ្ធផល យើងបានប្រើជម្រើសទាំងពីរក្នុងពេលដំណាលគ្នា៖ យើងបានបែងចែកថ្នាំងមួយទៅជា 3 ផ្នែកដែលអាចធ្វើការដោយឡែកពីគ្នា ប៉ុន្តែនៅពេលជាមួយគ្នាធ្វើសមកាលកម្ម

1. ថ្នាំងបញ្ជូន ដែលទទួលយកប្រតិបត្តិការចូលទៅក្នុងអាង និងបង្កើតប្លុក។

2. ថ្នាំងដែលមានសុពលភាពដែលពិនិត្យមើលសុពលភាពនៃថ្នាំង។

3. ថ្នាំង API - ផ្តល់ API សម្រាប់ចូលប្រើទិន្នន័យ។

ក្នុងករណីនេះ អ្នកអាចភ្ជាប់ទៅថ្នាំងនីមួយៗតាមរយៈរន្ធ unix ដោយប្រើ cli ។

យើងបានផ្លាស់ប្តូរប្រតិបត្តិការធ្ងន់ៗ ដូចជាការគណនាមែកធាង Merkle ទៅជាខ្សែស្រឡាយដាច់ដោយឡែក។

ដូច្នេះហើយ យើងសម្រេចបាននូវប្រតិបត្តិការធម្មតានៃមុខងារ 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 ហើយទទួលបានប្រតិបត្តិការ ~80k ក្នុងមួយវិនាទីក្នុង 1 pipelining mode។

សម្រាប់ដំណើរការខ្ពស់ យើងបានកែសម្រួល Redis ឱ្យកាន់តែល្អិតល្អន់៖

• ការតភ្ជាប់រន្ធយូនីកត្រូវបានបង្កើតឡើង។
• យើងបានបិទការរក្សាទុកស្ថានភាពទៅថាស (សម្រាប់ភាពអាចជឿជាក់បាន អ្នកអាចរៀបចំការចម្លង និងរក្សាទុកទៅថាសក្នុង Redis ដាច់ដោយឡែក)។

នៅក្នុង Redis បណ្តុំគឺជាតារាង hash ពីព្រោះយើងត្រូវការដើម្បីអាចទាញយកប្រតិបត្តិការទាំងអស់នៅក្នុងសំណួរមួយ ហើយលុបប្រតិបត្តិការម្តងមួយៗ។ យើងបានព្យាយាមប្រើបញ្ជីធម្មតា ប៉ុន្តែវាយឺតជាងពេលដកបញ្ជីទាំងមូល។

នៅពេលប្រើស្តង់ដារ NodeJS បណ្ណាល័យ Redis សម្រេចបាននូវប្រតិបត្តិការ 18k ក្នុងមួយវិនាទី។ ល្បឿនធ្លាក់ចុះ ៩ ដង។

ចាប់តាំងពីសន្ទស្សន៍បង្ហាញយើងពីលទ្ធភាពគឺច្បាស់ជាង 5 ដង យើងបានចាប់ផ្តើមបង្កើនប្រសិទ្ធភាព។ យើងបានផ្លាស់ប្តូរបណ្ណាល័យទៅជា ioredis ហើយទទួលបានដំណើរការ 25k ក្នុងមួយវិនាទី។ យើងបានបន្ថែមប្រតិបត្តិការម្តងមួយៗដោយប្រើពាក្យបញ្ជា 'hset' ។ ដូច្នេះ យើង​កំពុង​បង្កើត​សំណួរ​ជា​ច្រើន​នៅ​ក្នុង Redis។ គំនិតនេះបានបង្កើតឡើងដើម្បីបញ្ចូលគ្នានូវប្រតិបត្តិការទៅជាបណ្តុំ ហើយផ្ញើវាដោយប្រើពាក្យបញ្ជាមួយ 'hmset' ។ លទ្ធផលគឺ 32k ក្នុងមួយវិនាទី។

សម្រាប់ហេតុផលមួយចំនួន ដែលយើងនឹងរៀបរាប់ខាងក្រោម យើងធ្វើការជាមួយទិន្នន័យដោយប្រើ `Buffer` ហើយដូចដែលវាប្រែថា ប្រសិនបើអ្នកបំប្លែងវាទៅជាអត្ថបទ (`buffer.toString('hex')`) មុនពេលសរសេរ អ្នកអាចទទួលបានបន្ថែម ការសម្តែង។ ដូច្នេះល្បឿនត្រូវបានកើនឡើងដល់ 35k ក្នុងមួយវិនាទី។ នៅពេលនេះ យើងបានសម្រេចចិត្តផ្អាកការបង្កើនប្រសិទ្ធភាពបន្ថែមទៀត។

យើងត្រូវប្តូរទៅពិធីការប្រព័ន្ធគោលពីរ ដោយសារ៖

1. ប្រព័ន្ធនេះច្រើនតែគណនាសញ្ញា ហត្ថលេខា ជាដើម។ ហើយសម្រាប់វា វាត្រូវការទិន្នន័យនៅក្នុង `buffer ។

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 ឬបញ្ជូនបន្តទៅកាន់ 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` - លេខសម្គាល់សារដើម្បីឱ្យការឆ្លើយតបអាចត្រូវបានកំណត់អត្តសញ្ញាណ។

- ពិធីការសម្រាប់អន្តរកម្មរវាងថ្នាំង

  ```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` - ការកំណត់អត្តសញ្ញាណសារ;
• `រាប់កំណាត់` и `លេខកំណាត់` ចាំបាច់សម្រាប់បំបែកសារធំ;
• `ប្រវែង` и `បន្ទុក` ប្រវែងនិងទិន្នន័យខ្លួនឯង។

ដោយសារយើងវាយបញ្ចូលទិន្នន័យជាមុន ប្រព័ន្ធចុងក្រោយគឺលឿនជាងបណ្ណាល័យ 'rlp' របស់ Ethereum ។ ជាអកុសល យើងមិនទាន់អាចបដិសេធបានទេ ដោយសារចាំបាច់ត្រូវបញ្ចប់កិច្ចសន្យាឆ្លាតវៃ ដែលយើងគ្រោងនឹងធ្វើនាពេលខាងមុខ។

ប្រសិនបើយើងអាចឈានដល់ល្បឿន 35 ផ្លូវទី 000th ប្រតិបត្តិការក្នុងមួយវិនាទី យើងក៏ត្រូវដំណើរការពួកវាក្នុងពេលវេលាដ៏ល្អប្រសើរផងដែរ។ ដោយសារពេលវេលាបង្កើតប្លុកប្រហាក់ប្រហែលចំណាយពេល 30 វិនាទី យើងត្រូវបញ្ចូលក្នុងប្លុក 1 000 000 ប្រតិបត្តិការ ដែលមានន័យថា ផ្ញើបន្ថែមទៀត 100 MB នៃ​ទិន្នន័យ

ដំបូងឡើយ យើងបានប្រើបណ្ណាល័យ 'ethereumjs-devp2p' ដើម្បីទំនាក់ទំនងរវាងថ្នាំង ប៉ុន្តែវាមិនអាចគ្រប់គ្រងទិន្នន័យបានច្រើននោះទេ។ ជាលទ្ធផល យើងបានប្រើបណ្ណាល័យ `ws` និងកំណត់រចនាសម្ព័ន្ធការផ្ញើទិន្នន័យគោលពីរតាមរយៈ websocket ។ ជាការពិតណាស់ យើងក៏ជួបប្រទះបញ្ហានៅពេលផ្ញើកញ្ចប់ទិន្នន័យធំ ប៉ុន្តែយើងបានបែងចែកវាទៅជាកំណាត់ ហើយឥឡូវនេះបញ្ហាទាំងនេះបានបាត់ទៅហើយ។

ក៏បង្កើតមែកធាង Merkle និងគណនាសញ្ញា 1 000 000 ប្រតិបត្តិការទាមទារអំពី 10 វិនាទីនៃការគណនាជាបន្តបន្ទាប់។ ក្នុងអំឡុងពេលនេះ ការតភ្ជាប់ជាមួយថ្នាំងទាំងអស់អាចបំបែកបាន។ វាត្រូវបានសម្រេចចិត្តផ្លាស់ទីការគណនានេះទៅខ្សែស្រឡាយដាច់ដោយឡែក។

សេចក្តីសន្និដ្ឋាន:

ជាការពិត ការរកឃើញរបស់យើងមិនមែនជារឿងថ្មីទេ ប៉ុន្តែសម្រាប់ហេតុផលមួយចំនួន អ្នកជំនាញជាច្រើនភ្លេចអំពីពួកគេនៅពេលកំពុងអភិវឌ្ឍ។

• ការប្រើប្រាស់កម្មវិធី Functional Programming ជំនួសឱ្យ Object-Oriented Programming ជួយបង្កើនផលិតភាព។
• monolith គឺអាក្រក់ជាងស្ថាបត្យកម្មសេវាកម្មសម្រាប់ប្រព័ន្ធ NodeJS ដែលមានផលិតភាព។
• ការប្រើប្រាស់ 'worker_threads' សម្រាប់ការគណនាធ្ងន់ធ្វើអោយប្រសើរឡើងនូវការឆ្លើយតបរបស់ប្រព័ន្ធ ជាពិសេសនៅពេលដោះស្រាយជាមួយប្រតិបត្តិការ i/o ។
• រន្ធ unix មានស្ថេរភាព និងលឿនជាងសំណើ http ។
• ប្រសិនបើអ្នកត្រូវការផ្ទេរទិន្នន័យធំតាមបណ្តាញយ៉ាងលឿន វាជាការប្រសើរក្នុងការប្រើប្រាស់ websockets និងបញ្ជូនទិន្នន័យគោលពីរ ដោយបែងចែកជាកំណាត់ ដែលអាចត្រូវបានបញ្ជូនបន្តប្រសិនបើពួកគេមិនមកដល់ ហើយបន្ទាប់មកបញ្ចូលគ្នាជាសារតែមួយ។

យើងសូមអញ្ជើញអ្នកឱ្យមកទស្សនា GitHub គម្រោង៖ https://github.com/opporty-com/Plasma-Cash/tree/new-version

អត្ថបទនេះត្រូវបានសហនិពន្ធដោយ អាឡិចសាន់ឌឺ ណាស៊ីវ៉ាន់, អ្នកអភិវឌ្ឍន៍ជាន់ខ្ពស់ ក្រុមហ៊ុន Clever Solution Inc.

ប្រភព: www.habr.com