សៀវភៅបញ្ជីចែកចាយសម្រាប់កង់៖ បទពិសោធន៍ជាមួយក្រណាត់ Hyperledger

ជំរាបសួរ ខ្ញុំធ្វើការនៅក្នុងក្រុមនៃគម្រោង DRD KP (ការចុះបញ្ជីទិន្នន័យចែកចាយសម្រាប់ការត្រួតពិនិត្យវដ្តជីវិតនៃសំណុំកង់)។ នៅទីនេះខ្ញុំចង់ចែករំលែកបទពិសោធន៍របស់ក្រុមរបស់យើងក្នុងការអភិវឌ្ឍន៍សហគ្រាស blockchain សម្រាប់គម្រោងនេះក្រោមឧបសគ្គនៃបច្ចេកវិទ្យា។ ភាគច្រើនខ្ញុំនឹងនិយាយអំពីក្រណាត់ Hyperledger ប៉ុន្តែវិធីសាស្រ្តដែលបានពិពណ៌នានៅទីនេះអាចត្រូវបានបន្ថែមទៅ blockchain ដែលមានការអនុញ្ញាតណាមួយ។ គោលដៅចុងក្រោយនៃការស្រាវជ្រាវរបស់យើងគឺរៀបចំដំណោះស្រាយ blockchain សហគ្រាសដើម្បីឱ្យផលិតផលចុងក្រោយមានភាពរីករាយក្នុងការប្រើប្រាស់ និងមិនពិបាកថែទាំពេក។

វា​នឹង​មិន​មាន​ការ​រក​ឃើញ ដំណោះស្រាយ​ដែល​មិន​បាន​រំពឹង​ទុក ហើយ​នឹង​មិន​មាន​ការ​អភិវឌ្ឍ​ពិសេស​ណា​មួយ​នឹង​ត្រូវ​បាន​គូស​បញ្ជាក់​នៅ​ទីនេះ (ព្រោះ​ខ្ញុំ​មិន​មាន)។ ខ្ញុំគ្រាន់តែចង់ចែករំលែកបទពិសោធន៍តិចតួចរបស់ខ្ញុំ បង្ហាញថា "វាអាចទៅរួច" ហើយប្រហែលជា អានអំពីបទពិសោធន៍របស់អ្នកដ៏ទៃក្នុងការធ្វើការសម្រេចចិត្តល្អ និងមិនល្អនៅក្នុងមតិយោបល់។

បញ្ហា៖ Blockchains មិនទាន់ធ្វើមាត្រដ្ឋាននៅឡើយទេ

សព្វថ្ងៃនេះការខិតខំប្រឹងប្រែងរបស់អ្នកអភិវឌ្ឍន៍ជាច្រើនមានគោលបំណងធ្វើឱ្យ blockchain ក្លាយជាបច្ចេកវិទ្យាដ៏ងាយស្រួលមួយ ហើយមិនមែនជាគ្រាប់បែកពេលវេលានៅក្នុងរុំដ៏ស្រស់ស្អាតនោះទេ។ បណ្តាញរដ្ឋ ការប្រមូលផ្តុំសុទិដ្ឋិនិយម ប្លាស្មា និងការបំបែកនឹងក្លាយជារឿងធម្មតា។ ថ្ងៃណាមួយ។ ឬប្រហែលជា TON នឹងពន្យារពេលការបើកដំណើរការម្តងទៀតសម្រាប់រយៈពេលប្រាំមួយខែ ហើយ Plasma Group បន្ទាប់នឹងឈប់មាន។ យើងអាចជឿជាក់លើផែនទីបង្ហាញផ្លូវបន្ទាប់ ហើយអានក្រដាសសដ៏អស្ចារ្យនៅពេលយប់ ប៉ុន្តែនៅទីនេះ និងឥឡូវនេះ យើងត្រូវធ្វើអ្វីមួយជាមួយនឹងអ្វីដែលយើងមាន។ ធ្វើរឿងអាស្រូវ។

ភារកិច្ចដែលបានកំណត់សម្រាប់ក្រុមរបស់យើងនៅក្នុងគម្រោងបច្ចុប្បន្នមើលទៅជាទូទៅដូចនេះ: មានមុខវិជ្ជាជាច្រើនឈានដល់រាប់ពាន់នាក់ដែលមិនចង់បង្កើតទំនាក់ទំនងលើការជឿទុកចិត្ត។ វាចាំបាច់ក្នុងការបង្កើតដំណោះស្រាយនៅលើ DLT ដែលនឹងដំណើរការលើកុំព្យូទ័រធម្មតាដោយគ្មានតម្រូវការប្រតិបត្តិការពិសេស និងផ្តល់នូវបទពិសោធន៍អ្នកប្រើប្រាស់មិនអាក្រក់ជាងប្រព័ន្ធគណនេយ្យកណ្តាលណាមួយឡើយ។ បច្ចេកវិទ្យាដែលនៅពីក្រោយដំណោះស្រាយត្រូវតែកាត់បន្ថយលទ្ធភាពនៃការប្រើប្រាស់ទិន្នន័យដែលមានគំនិតអាក្រក់ - នោះហើយជាមូលហេតុដែល blockchain នៅទីនេះ។

ពាក្យស្លោកពីសៀវភៅស និងប្រព័ន្ធផ្សព្វផ្សាយសន្យាយើងថាការអភិវឌ្ឍន៍បន្ទាប់នឹងអនុញ្ញាតឱ្យយើងធ្វើប្រតិបត្តិការរាប់លានក្នុងមួយវិនាទី។ តើ​វា​ពិត​ជា​អ្វី?

Mainnet Ethereum បច្ចុប្បន្នកំពុងដំណើរការនៅ ~30 tps ។ ដោយសារតែនេះតែម្នាក់ឯងវាពិបាកក្នុងការយល់ថាវាជា blockchain ក្នុងមធ្យោបាយណាមួយដែលសមរម្យសម្រាប់តម្រូវការសាជីវកម្ម។ ក្នុង​ចំណោម​ដំណោះស្រាយ​ដែល​មាន​ការ​អនុញ្ញាត មាន​គោល​បង្ហាញ 2000 tps (កូរ៉ុម) ឬ 3000 tps (ក្រណាត់ហ៊ីបល្លីលមានការបោះពុម្ពផ្សាយតិចជាងបន្តិច ប៉ុន្តែអ្នកត្រូវយកទៅពិចារណាថា ចំណុចគោលត្រូវបានអនុវត្តនៅលើម៉ាស៊ីនរួមចាស់)។ បាន ការប៉ុនប៉ងលើដំណើរការក្រណាត់រ៉ាឌីកាល់ដែលមិនបានផ្តល់លទ្ធផលអាក្រក់បំផុត 20000 tps ប៉ុន្តែរហូតមកដល់ពេលនេះនេះគ្រាន់តែជាការស្រាវជ្រាវសិក្សាប៉ុណ្ណោះ ដោយរង់ចាំការអនុវត្តប្រកបដោយស្ថិរភាពរបស់វា។ វាមិនទំនងថាសាជីវកម្មដែលអាចមានលទ្ធភាពរក្សានាយកដ្ឋានរបស់អ្នកអភិវឌ្ឍន៍ blockchain នឹងដាក់សូចនាករបែបនេះទេ។ ប៉ុន្តែ​បញ្ហា​មិន​ត្រឹម​តែ​ឆ្លង​កាត់​ប៉ុណ្ណោះ​ទេ វា​ក៏​មាន​ភាព​យឺតយ៉ាវ​ដែរ។

ភាពយឺតយ៉ាវ

ការពន្យាពេលចាប់ពីពេលដែលប្រតិបត្តិការត្រូវបានផ្តួចផ្តើមដល់ការអនុម័តចុងក្រោយដោយប្រព័ន្ធគឺអាស្រ័យមិនត្រឹមតែទៅលើល្បឿនដែលសារឆ្លងកាត់គ្រប់ដំណាក់កាលនៃសុពលភាព និងការបញ្ជាទិញប៉ុណ្ណោះទេ ប៉ុន្តែក៏នៅលើប៉ារ៉ាម៉ែត្រនៃការបង្កើតប្លុកផងដែរ។ ទោះបីជា blockchain របស់យើងអនុញ្ញាតឱ្យយើងធ្វើការក្នុងល្បឿន 1000000 tps ប៉ុន្តែត្រូវការ 10 នាទីដើម្បីបង្កើតប្លុក 488 MB តើវានឹងកាន់តែងាយស្រួលសម្រាប់យើងទេ?

សូមពិនិត្យមើលឱ្យកាន់តែដិតដល់នូវវដ្តជីវិតប្រតិបត្តិការនៅក្នុង Hyperledger Fabric ដើម្បីយល់ពីកន្លែងដែលពេលវេលាត្រូវចំណាយ និងរបៀបដែលវាទាក់ទងនឹងការទប់ស្កាត់ប៉ារ៉ាម៉ែត្រជំនាន់។

យកពីទីនេះ: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) អតិថិជនបង្កើតប្រតិបត្តិការ ផ្ញើវាទៅមិត្តភក្ដិដែលគាំទ្រ ក្រោយមកក្លែងធ្វើប្រតិបត្តិការ (អនុវត្តការផ្លាស់ប្តូរដែលធ្វើឡើងដោយលេខកូដខ្សែសង្វាក់ទៅនឹងស្ថានភាពបច្ចុប្បន្ន ប៉ុន្តែកុំប្រព្រឹត្តចំពោះបញ្ជីឈ្មោះ) និងទទួលបាន RWset - ឈ្មោះគន្លឹះ កំណែ និងតម្លៃ។ យកពីការប្រមូលនៅក្នុង CouchDB, (2) អ្នកយល់ព្រមផ្ញើ RWset ដែលបានចុះហត្ថលេខាទៅអតិថិជនវិញ (3) អតិថិជនពិនិត្យមើលវត្តមាននៃហត្ថលេខារបស់មិត្តភ័ក្តិដែលចាំបាច់ទាំងអស់ (អ្នកយល់ព្រម) ហើយបន្ទាប់មកផ្ញើប្រតិបត្តិការទៅសេវាកម្មបញ្ជាទិញ។ ឬផ្ញើវាដោយគ្មានការផ្ទៀងផ្ទាត់ (ការត្រួតពិនិត្យនឹងនៅតែកើតឡើងនៅពេលក្រោយ) សេវាកម្មបញ្ជាទិញបង្កើតជាប្លុក ហើយ (4) ផ្ញើត្រឡប់ទៅមិត្តភ័ក្តិទាំងអស់ មិនមែនត្រឹមតែអ្នកគាំទ្រប៉ុណ្ណោះទេ។ មិត្តភ័ក្តិពិនិត្យមើលថាកំណែសំខាន់ៗនៅក្នុងសំណុំដែលបានអានត្រូវគ្នានឹងកំណែនៅក្នុងមូលដ្ឋានទិន្នន័យ ដែលអ្នកយល់ព្រមទាំងអស់មានហត្ថលេខា ហើយចុងក្រោយបានកំណត់ប្លុក។

ប៉ុន្តែនោះមិនមែនទាំងអស់នោះទេ។ ពាក្យ "អ្នកបញ្ជាបង្កើតប្លុក" លាក់មិនត្រឹមតែការបញ្ជាទិញប្រតិបត្តិការប៉ុណ្ណោះទេ ថែមទាំងសំណើបណ្តាញជាបន្តបន្ទាប់ចំនួន 3 ពីអ្នកដឹកនាំទៅកាន់អ្នកដើរតាម និងត្រឡប់មកវិញ៖ អ្នកដឹកនាំបន្ថែមសារទៅកំណត់ហេតុ ផ្ញើវាទៅអ្នកដើរតាម ក្រោយមកបន្ថែមវា ទៅកាន់កំណត់ហេតុរបស់ពួកគេ ផ្ញើការបញ្ជាក់ពីការចម្លងជោគជ័យទៅកាន់អ្នកដឹកនាំ អ្នកដឹកនាំផ្ញើសារ ផ្ញើការបញ្ជាក់ទៅកាន់អ្នកដើរតាម អ្នកដើរតាមសន្យា។ ទំហំ និងពេលវេលានៃការបង្កើតប្លុកកាន់តែតូច សេវាបញ្ជាទិញកាន់តែញឹកញាប់នឹងត្រូវបង្កើតការយល់ស្រប. ក្រណាត់ Hyperledger មានប៉ារ៉ាម៉ែត្រពីរសម្រាប់ការបង្កើតប្លុក៖ BatchTimeout - ពេលវេលាបង្កើតប្លុក និងទំហំ BatchSize - ទំហំប្លុក (ចំនួនប្រតិបត្តិការ និងទំហំនៃប្លុកខ្លួនវាគិតជាបៃ)។ ដរាបណាប៉ារ៉ាម៉ែត្រមួយក្នុងចំណោមប៉ារ៉ាម៉ែត្រឈានដល់ដែនកំណត់ ប្លុកថ្មីមួយត្រូវបានចេញផ្សាយ។ ថ្នាំងលំដាប់កាន់តែច្រើន វានឹងចំណាយពេលយូរ។ ដូច្នេះ អ្នកត្រូវបង្កើន BatchTimeout និង BatchSize ។ ប៉ុន្តែចាប់តាំងពី RWSets ត្រូវបានកំណែ ប្លុកធំជាងដែលយើងបង្កើត លទ្ធភាពនៃការប៉ះទង្គិច MVCC កាន់តែខ្ពស់។ លើសពីនេះទៀតនៅពេលដែល BatchTimeout កើនឡើង UX កាន់តែមហន្តរាយ។ គ្រោងការណ៍ខាងក្រោមសម្រាប់ការដោះស្រាយបញ្ហាទាំងនេះហាក់ដូចជាសមហេតុផល និងជាក់ស្តែងសម្រាប់ខ្ញុំ។

តើធ្វើដូចម្តេចដើម្បីជៀសវាងការរង់ចាំសម្រាប់ការបញ្ចប់ប្លុកនិងមិនបាត់បង់សមត្ថភាពក្នុងការតាមដានស្ថានភាពប្រតិបត្តិការ

ពេលវេលាបង្កើត និងទំហំប្លុកកាន់តែយូរ លំហូរនៃ blockchain កាន់តែខ្ពស់។ មួយមិនធ្វើតាមដោយផ្ទាល់ពីអ្នកផ្សេងទៀតទេប៉ុន្តែវាគួរតែត្រូវបានចងចាំថាការបង្កើតការយល់ស្របនៅក្នុង RAFT តម្រូវឱ្យមានសំណើបណ្តាញចំនួនបីពីអ្នកដឹកនាំទៅអ្នកដើរតាមនិងត្រឡប់មកវិញ។ ថ្នាំងលំដាប់កាន់តែច្រើន វានឹងចំណាយពេលយូរ។ ទំហំ និងពេលវេលានៃការបង្កើតប្លុកកាន់តែតូច អន្តរកម្មបែបនេះមានកាន់តែច្រើន។ តើធ្វើដូចម្តេចដើម្បីបង្កើនពេលវេលាបង្កើត និងទំហំប្លុកដោយមិនបង្កើនពេលវេលាឆ្លើយតបរបស់ប្រព័ន្ធសម្រាប់អ្នកប្រើប្រាស់ចុងក្រោយ?

ជាដំបូង យើងត្រូវដោះស្រាយវិវាទ MVCC ដែលបណ្តាលមកពីទំហំប្លុកធំ ដែលអាចរួមបញ្ចូល RWSets ផ្សេងគ្នាជាមួយនឹងកំណែដូចគ្នា។ ជាក់ស្តែងនៅលើផ្នែកអតិថិជន (ទាក់ទងនឹងបណ្តាញ blockchain នេះអាចជាផ្នែកខាងក្រោយហើយខ្ញុំមានន័យថាវា) អ្នកត្រូវការ កម្មវិធីដោះស្រាយជម្លោះ MVCCដែលអាចជាសេវាកម្មដាច់ដោយឡែក ឬអ្នកតុបតែងធម្មតានៅពីលើការហៅទូរសព្ទដែលចាប់ផ្តើមប្រតិបត្តិការជាមួយនឹងតក្កវិជ្ជាព្យាយាមម្តងទៀត។

ការព្យាយាមម្តងទៀតអាចត្រូវបានអនុវត្តជាមួយនឹងយុទ្ធសាស្រ្តអិចស្ប៉ូណង់ស្យែល ប៉ុន្តែបន្ទាប់មកភាពយឺតយ៉ាវនឹងថយចុះដូចអិចស្ប៉ូណង់ស្យែល។ ដូច្នេះ អ្នកគួរតែប្រើការព្យាយាមម្តងទៀតដោយចៃដន្យក្នុងដែនកំណត់តូចជាក់លាក់ ឬមួយថេរ។ ជាមួយនឹងភ្នែកលើការប៉ះទង្គិចដែលអាចកើតមាននៅក្នុងជម្រើសដំបូង។

ជំហានបន្ទាប់គឺធ្វើឱ្យអន្តរកម្មរបស់អតិថិជនជាមួយប្រព័ន្ធអសមកាល ដើម្បីកុំឱ្យវារង់ចាំរយៈពេល 15, 30 ឬ 10000000 វិនាទី ដែលយើងនឹងកំណត់ជា BatchTimeout ។ ប៉ុន្តែក្នុងពេលជាមួយគ្នានេះ វាចាំបាច់ក្នុងការរក្សាសមត្ថភាពក្នុងការផ្ទៀងផ្ទាត់ថាការផ្លាស់ប្តូរដែលផ្តួចផ្តើមដោយប្រតិបត្តិការគឺ/មិនត្រូវបានកត់ត្រានៅក្នុង blockchain នោះទេ។
មូលដ្ឋានទិន្នន័យអាចត្រូវបានប្រើដើម្បីរក្សាទុកស្ថានភាពប្រតិបត្តិការ។ ជម្រើសដ៏សាមញ្ញបំផុតគឺ CouchDB ដោយសារតែភាពងាយស្រួលនៃការប្រើប្រាស់របស់វា៖ មូលដ្ឋានទិន្នន័យមាន UI ចេញពីប្រអប់ REST API ហើយអ្នកអាចរៀបចំការចម្លង និងការចែករំលែកបានយ៉ាងងាយស្រួលសម្រាប់វា។ អ្នកអាចបង្កើតបណ្តុំដាច់ដោយឡែកមួយនៅក្នុងឧទាហរណ៍ CouchDB ដូចគ្នាដែលប្រើ Fabric ដើម្បីរក្សាទុកស្ថានភាពពិភពលោករបស់វា។ យើងត្រូវរក្សាទុកឯកសារប្រភេទនេះ។

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

ឯកសារនេះត្រូវបានសរសេរទៅមូលដ្ឋានទិន្នន័យ មុនពេលប្រតិបត្តិការត្រូវបានផ្ញើទៅមិត្តភក្ដិ លេខសម្គាល់អង្គភាពត្រូវបានប្រគល់ជូនអ្នកប្រើប្រាស់វិញ (លេខសម្គាល់ដូចគ្នាត្រូវបានប្រើជាសោ) ប្រសិនបើនេះជាប្រតិបត្តិការបង្កើត ហើយបន្ទាប់មកវាល ស្ថានភាព TxID និងកំហុស។ បានធ្វើបច្ចុប្បន្នភាព ដោយសារព័ត៌មានពាក់ព័ន្ធត្រូវបានទទួលពីមិត្តភ័ក្តិ។

នៅក្នុងគ្រោងការណ៍នេះ អ្នកប្រើប្រាស់មិនរង់ចាំឱ្យប្លុកបង្កើតជាចុងក្រោយឡើយ ដោយមើលកង់វិលនៅលើអេក្រង់រយៈពេល 10 វិនាទី គាត់ទទួលបានការឆ្លើយតបភ្លាមៗពីប្រព័ន្ធ ហើយបន្តដំណើរការ។

យើងបានជ្រើសរើស BoltDB ដើម្បីរក្សាទុកស្ថានភាពប្រតិបត្តិការ ពីព្រោះយើងត្រូវរក្សាទុកអង្គចងចាំ ហើយមិនចង់ខ្ជះខ្ជាយពេលវេលាលើអន្តរកម្មបណ្តាញជាមួយម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យដាច់ដោយឡែក ជាពិសេសនៅពេលដែលអន្តរកម្មនេះកើតឡើងដោយប្រើពិធីការអត្ថបទធម្មតា។ ដោយវិធីនេះ មិនថាអ្នកប្រើ CouchDB ដើម្បីអនុវត្តគ្រោងការណ៍ដែលបានពិពណ៌នាខាងលើ ឬសាមញ្ញដើម្បីរក្សាទុកស្ថានភាពពិភពលោក ក្នុងករណីណាក៏ដោយ វាសមហេតុផលក្នុងការបង្កើនប្រសិទ្ធភាពវិធីរក្សាទុកទិន្នន័យនៅក្នុង CouchDB ។ តាមលំនាំដើម នៅក្នុង CouchDB ទំហំនៃថ្នាំង b-tree គឺ 1279 បៃ ដែលតូចជាងទំហំវិស័យនៅលើឌីស ដែលមានន័យថាទាំងការអាន និងការធ្វើឱ្យមានតុល្យភាពឡើងវិញនឹងតម្រូវឱ្យមានការចូលប្រើប្រាស់រូបវ័ន្តបន្ថែមទៀតទៅកាន់ថាស។ ទំហំល្អបំផុតត្រូវគ្នានឹងស្តង់ដារ ទ្រង់ទ្រាយកម្រិតខ្ពស់ និង ៤ គីឡូបៃ។ ដើម្បីបង្កើនប្រសិទ្ធភាពយើងត្រូវកំណត់ប៉ារ៉ាម៉ែត្រ btree_chunk_size ស្មើនឹង 4096 នៅក្នុងឯកសារកំណត់រចនាសម្ព័ន្ធ CouchDB ។ សម្រាប់ BoltDB អន្តរាគមន៍ដោយដៃបែបនេះ មិនចាំបាច់.

សម្ពាធខាងក្រោយ៖ យុទ្ធសាស្ត្របណ្ដោះអាសន្ន

ប៉ុន្តែអាចមានសារជាច្រើន។ លើសពីប្រព័ន្ធអាចគ្រប់គ្រងបាន ការចែករំលែកធនធានជាមួយសេវាកម្មជាច្រើនផ្សេងទៀត ក្រៅពីអ្វីដែលបានបង្ហាញនៅក្នុងដ្យាក្រាម ហើយអ្វីៗទាំងអស់នេះគួរតែដំណើរការដោយគ្មានកំហុសសូម្បីតែនៅលើម៉ាស៊ីនដែលដំណើរការ Intellij Idea នឹងគួរឱ្យធុញទ្រាន់បំផុត។

បញ្ហានៃសមត្ថភាពផ្សេងគ្នានៃប្រព័ន្ធទំនាក់ទំនង អ្នកផលិត និងអ្នកប្រើប្រាស់ត្រូវបានដោះស្រាយតាមវិធីផ្សេងៗគ្នា។ សូមមើលអ្វីដែលយើងអាចធ្វើបាន។

ទម្លាក់៖ យើងអាចអះអាងថាយើងអាចដំណើរការប្រតិបត្តិការ X ភាគច្រើនក្នុងរយៈពេល T វិនាទី។ សំណើទាំងអស់ដែលលើសពីដែនកំណត់នេះត្រូវបានលុបចោល។ នេះគឺសាមញ្ញណាស់ ប៉ុន្តែបន្ទាប់មកអ្នកអាចភ្លេចអំពី UX ។

ការត្រួតពិនិត្យ។៖ អ្នកប្រើប្រាស់ត្រូវតែមានចំណុចប្រទាក់ប្រភេទមួយចំនួនដែលតាមនោះ អាស្រ័យលើបន្ទុក គាត់អាចគ្រប់គ្រង TPS របស់អ្នកផលិតបាន។ មិនអាក្រក់ទេប៉ុន្តែវាដាក់កាតព្វកិច្ចលើអ្នកអភិវឌ្ឍន៍របស់អតិថិជនដែលបង្កើតបន្ទុកដើម្បីអនុវត្តចំណុចប្រទាក់នេះ។ នេះមិនអាចទទួលយកបានសម្រាប់យើងទេ ព្រោះនៅពេលអនាគត blockchain នឹងត្រូវបានបញ្ចូលទៅក្នុងប្រព័ន្ធដែលមានស្រាប់មួយចំនួនធំ។

ការផ្អាក៖ ជំនួសឱ្យការព្យាយាមទប់ទល់នឹងស្ទ្រីមទិន្នន័យបញ្ចូល យើងអាចផ្ទុកស្ទ្រីមនេះ ហើយដំណើរការវាតាមល្បឿនដែលត្រូវការ។ ជាក់ស្តែង នេះគឺជាដំណោះស្រាយដ៏ល្អបំផុត ប្រសិនបើយើងចង់ផ្តល់នូវបទពិសោធន៍អ្នកប្រើប្រាស់ដ៏ល្អ។ យើង​បាន​អនុវត្ត​បណ្តុំ​ដោយ​ប្រើ​ជួរ​ក្នុង RabbitMQ ។

សកម្មភាពថ្មីចំនួនពីរត្រូវបានបន្ថែមទៅក្នុងគ្រោងការណ៍៖ (1) បន្ទាប់ពីសំណើទៅកាន់ API មកដល់ សារដែលមានប៉ារ៉ាម៉ែត្រចាំបាច់ដើម្បីហៅប្រតិបត្តិការត្រូវបានដាក់ក្នុងជួរ ហើយអតិថិជនទទួលបានសារដែលប្រតិបត្តិការត្រូវបានទទួលយកដោយ ប្រព័ន្ធ, (2) កម្មវិធីខាងក្រោយអានទិន្នន័យក្នុងល្បឿនដែលបានបញ្ជាក់ក្នុងការកំណត់ពីជួរ។ ចាប់ផ្តើមប្រតិបត្តិការ និងធ្វើបច្ចុប្បន្នភាពទិន្នន័យនៅក្នុងហាងស្ថានភាព។
ឥឡូវនេះ អ្នកអាចបង្កើនពេលវេលាបង្កើត និងសមត្ថភាពទប់ស្កាត់បានច្រើនតាមដែលអ្នកចង់បាន ដោយលាក់ការពន្យារពេលពីអ្នកប្រើប្រាស់។

ឧបករណ៍ផ្សេងទៀត។

គ្មានអ្វីត្រូវបាននិយាយនៅទីនេះអំពីកូដខ្សែសង្វាក់នោះទេ ពីព្រោះជាក្បួនមិនមានអ្វីដើម្បីបង្កើនប្រសិទ្ធភាពនៅក្នុងវាទេ។ Chaincode គួរតែមានលក្ខណៈសាមញ្ញ និងមានសុវត្ថិភាពតាមដែលអាចធ្វើទៅបាន - នោះហើយជាអ្វីដែលចាំបាច់របស់វា។ ក្របខ័ណ្ឌជួយយើងសរសេរកូដខ្សែសង្វាក់យ៉ាងសាមញ្ញ និងសុវត្ថិភាព CCKit ពី S7 Techlab និងឧបករណ៍វិភាគឋិតិវន្ត រស់ឡើងវិញ ^ CC.

លើសពីនេះ ក្រុមការងាររបស់យើងកំពុងបង្កើតឧបករណ៍ប្រើប្រាស់មួយឈុតដើម្បីធ្វើឱ្យការធ្វើការជាមួយ Fabric មានភាពសាមញ្ញ និងរីករាយ៖ អ្នករុករក blockchain, ឧបករណ៍ប្រើប្រាស់សម្រាប់ ការផ្លាស់ប្តូរការកំណត់បណ្តាញដោយស្វ័យប្រវត្តិ (បន្ថែម/យកអង្គការចេញ ថ្នាំង RAFT) ឧបករណ៍ប្រើប្រាស់សម្រាប់ ការដកហូតវិញ្ញាបនបត្រ និងការដកអត្តសញ្ញាណចេញ. ប្រសិនបើអ្នកចង់ចូលរួមចំណែក សូមស្វាគមន៍។

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

វិធីសាស្រ្តនេះអនុញ្ញាតឱ្យអ្នកងាយស្រួលជំនួសក្រណាត់ Hyperledger ជាមួយ Quorum បណ្តាញ Ethereum ឯកជនផ្សេងទៀត (PoA ឬសូម្បីតែ PoW) កាត់បន្ថយការបញ្ជូនជាក់ស្តែងយ៉ាងខ្លាំង ប៉ុន្តែក្នុងពេលតែមួយរក្សា UX ធម្មតា (ទាំងសម្រាប់អ្នកប្រើប្រាស់នៅក្នុងកម្មវិធីរុករក និងសម្រាប់ប្រព័ន្ធរួមបញ្ចូលគ្នា)។ នៅពេលជំនួស Fabric ជាមួយ Ethereum នៅក្នុងគ្រោងការណ៍ អ្នកនឹងត្រូវផ្លាស់ប្តូរតក្កវិជ្ជានៃសេវាកម្មព្យាយាមម្តងទៀត/អ្នកតុបតែងពីការដំណើរការការប៉ះទង្គិច MVCC ទៅជាអាតូមិកមិនបង្កើន និងបញ្ជូនបន្ត។ ការផ្ទុកបណ្តោះអាសន្ន និងស្ថានភាពបានធ្វើឱ្យវាអាចបំបែកពេលវេលាឆ្លើយតបពីពេលវេលាបង្កើតប្លុក។ ឥឡូវនេះអ្នកអាចបន្ថែមថ្នាំងការបញ្ជាទិញរាប់ពាន់ ហើយកុំខ្លាចថាប្លុកត្រូវបានបង្កើតឡើងញឹកញាប់ពេក ហើយផ្ទុកសេវាកម្មបញ្ជាទិញ។

ជាទូទៅ នោះជាអ្វីទាំងអស់ដែលខ្ញុំចង់ចែករំលែក។ ខ្ញុំនឹងរីករាយប្រសិនបើរឿងនេះជួយនរណាម្នាក់ក្នុងការងាររបស់ពួកគេ។

ប្រភព: www.habr.com