പബ്ലിക് ടെസ്റ്റ്: Ethereum-ലെ സ്വകാര്യതയ്ക്കും സ്കേലബിലിറ്റിക്കുമുള്ള ഒരു പരിഹാരം

ബ്ലോക്ക്‌ചെയിൻ മനുഷ്യജീവിതത്തിന്റെ പല മേഖലകളും മെച്ചപ്പെടുത്തുമെന്ന് വാഗ്ദാനം ചെയ്യുന്ന ഒരു നൂതന സാങ്കേതികവിദ്യയാണ്. ഇത് യഥാർത്ഥ പ്രക്രിയകളും ഉൽപ്പന്നങ്ങളും ഡിജിറ്റൽ സ്ഥലത്തേക്ക് മാറ്റുന്നു, സാമ്പത്തിക ഇടപാടുകളുടെ വേഗതയും വിശ്വാസ്യതയും ഉറപ്പാക്കുന്നു, അവയുടെ ചിലവ് കുറയ്ക്കുന്നു, കൂടാതെ വികേന്ദ്രീകൃത നെറ്റ്‌വർക്കുകളിൽ സ്മാർട്ട് കരാറുകൾ ഉപയോഗിച്ച് ആധുനിക DAPP ആപ്ലിക്കേഷനുകൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ബ്ലോക്ക്‌ചെയിനിന്റെ നിരവധി നേട്ടങ്ങളും വൈവിധ്യമാർന്ന ആപ്ലിക്കേഷനുകളും കണക്കിലെടുക്കുമ്പോൾ, ഈ വാഗ്ദാന സാങ്കേതികവിദ്യ ഇതുവരെ എല്ലാ വ്യവസായങ്ങളിലും കടന്നുവന്നിട്ടില്ലെന്നത് ആശ്ചര്യകരമായി തോന്നിയേക്കാം. ആധുനിക വികേന്ദ്രീകൃത ബ്ലോക്ക്ചെയിനുകൾക്ക് സ്കേലബിളിറ്റി ഇല്ലെന്നതാണ് പ്രശ്നം. Ethereum ഒരു സെക്കൻഡിൽ ഏകദേശം 20 ഇടപാടുകൾ പ്രോസസ്സ് ചെയ്യുന്നു, ഇന്നത്തെ ഡൈനാമിക് ബിസിനസ്സുകളുടെ ആവശ്യങ്ങൾ നിറവേറ്റാൻ ഇത് പര്യാപ്തമല്ല. അതേസമയം, ഹാക്കിംഗിൽ നിന്നും നെറ്റ്‌വർക്ക് പരാജയങ്ങളിൽ നിന്നും ഉയർന്ന പരിരക്ഷയുള്ളതിനാൽ ബ്ലോക്ക്ചെയിൻ സാങ്കേതികവിദ്യ ഉപയോഗിക്കുന്ന കമ്പനികൾ Ethereum ഉപേക്ഷിക്കാൻ മടിക്കുന്നു.

ബ്ലോക്ക്‌ചെയിനിൽ വികേന്ദ്രീകരണം, സുരക്ഷ, സ്കേലബിലിറ്റി എന്നിവ ഉറപ്പാക്കുന്നതിന്, വികസന ടീമായ സ്കേലബിലിറ്റി ട്രൈലെമ്മ പരിഹരിക്കുന്നു അവസരം ഒരു സ്മാർട്ട് കരാറും Node.js അടിസ്ഥാനമാക്കിയുള്ള ഒരു സ്വകാര്യ നെറ്റ്‌വർക്കും അടങ്ങുന്ന ഒരു സബ്‌സിഡിയറി ശൃംഖലയായ പ്ലാസ്മ ക്യാഷ് സൃഷ്ടിച്ചു, അത് അതിന്റെ അവസ്ഥയെ റൂട്ട് ചെയിനിലേക്ക് (Ethereum) ഇടയ്‌ക്കിടെ മാറ്റുന്നു.

പ്ലാസ്മ പണത്തിലെ പ്രധാന പ്രക്രിയകൾ

1. ഉപയോക്താവ് സ്‌മാർട്ട് കോൺട്രാക്‌ട് ഫംഗ്‌ഷനെ `ഡെപ്പോസിറ്റ്' എന്ന് വിളിക്കുന്നു, പ്ലാസ്മ ക്യാഷ് ടോക്കണിലേക്ക് നിക്ഷേപിക്കാൻ ആഗ്രഹിക്കുന്ന ETH തുക അതിലേക്ക് കൈമാറുന്നു. സ്‌മാർട്ട് കോൺട്രാക്‌ട് ഫംഗ്‌ഷൻ ഒരു ടോക്കൺ സൃഷ്‌ടിക്കുകയും അതിനെക്കുറിച്ച് ഒരു ഇവന്റ് സൃഷ്‌ടിക്കുകയും ചെയ്യുന്നു.

2. സ്‌മാർട്ട് കോൺട്രാക്‌റ്റ് ഇവന്റുകൾ സബ്‌സ്‌ക്രൈബുചെയ്‌ത പ്ലാസ്മ ക്യാഷ് നോഡുകൾക്ക് ഒരു ഡെപ്പോസിറ്റ് സൃഷ്‌ടിക്കുന്നതിനെക്കുറിച്ചുള്ള ഒരു ഇവന്റ് ലഭിക്കുകയും പൂളിലേക്ക് ഒരു ടോക്കൺ സൃഷ്‌ടിക്കുന്നതിനെക്കുറിച്ചുള്ള ഒരു ഇടപാട് ചേർക്കുകയും ചെയ്യുന്നു.

3. ആനുകാലികമായി, പ്രത്യേക പ്ലാസ്മ ക്യാഷ് നോഡുകൾ പൂളിൽ നിന്ന് (1 ദശലക്ഷം വരെ) എല്ലാ ഇടപാടുകളും എടുക്കുകയും അവയിൽ നിന്ന് ഒരു ബ്ലോക്ക് രൂപപ്പെടുത്തുകയും മെർക്കൽ ട്രീയും അതിനനുസരിച്ച് ഹാഷും കണക്കാക്കുകയും ചെയ്യുന്നു. സ്ഥിരീകരണത്തിനായി ഈ ബ്ലോക്ക് മറ്റ് നോഡുകളിലേക്ക് അയയ്ക്കുന്നു. Merkle ഹാഷ് സാധുവാണോ എന്നും ഇടപാടുകൾ സാധുവാണോ എന്നും നോഡുകൾ പരിശോധിക്കുന്നു (ഉദാഹരണത്തിന്, ടോക്കൺ അയച്ചയാൾ അതിന്റെ ഉടമയാണോ). ബ്ലോക്ക് പരിശോധിച്ചുറപ്പിച്ചതിന് ശേഷം, സ്‌മാർട്ട് കരാറിന്റെ `സബ്മിറ്റ്ബ്ലോക്ക്' ഫംഗ്‌ഷനെ നോഡ് വിളിക്കുന്നു, ഇത് ബ്ലോക്ക് നമ്പറും മെർക്ക്ലെ ഹാഷും എഡ്ജ് ചെയിനിലേക്ക് സംരക്ഷിക്കുന്നു. ഒരു ബ്ലോക്കിന്റെ വിജയകരമായ കൂട്ടിച്ചേർക്കലിനെ സൂചിപ്പിക്കുന്ന ഒരു ഇവന്റ് സ്മാർട്ട് കരാർ സൃഷ്ടിക്കുന്നു. ഇടപാടുകൾ കുളത്തിൽ നിന്ന് നീക്കം ചെയ്യുന്നു.

4. ബ്ലോക്ക് സബ്മിഷൻ ഇവന്റ് സ്വീകരിക്കുന്ന നോഡുകൾ ബ്ലോക്കിലേക്ക് ചേർത്ത ഇടപാടുകൾ പ്രയോഗിക്കാൻ തുടങ്ങുന്നു.

5. ചില ഘട്ടങ്ങളിൽ, ടോക്കണിന്റെ ഉടമ (അല്ലെങ്കിൽ ഉടമസ്ഥനല്ലാത്തത്) പ്ലാസ്മ പണത്തിൽ നിന്ന് അത് പിൻവലിക്കാൻ ആഗ്രഹിക്കുന്നു. ഇത് ചെയ്യുന്നതിന്, ടോക്കണിലെ അവസാന 2 ഇടപാടുകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ അതിലേക്ക് കൈമാറിക്കൊണ്ട് അദ്ദേഹം `startExit` ഫംഗ്‌ഷനെ വിളിക്കുന്നു, അത് ടോക്കണിന്റെ ഉടമയാണെന്ന് സ്ഥിരീകരിക്കുന്നു. മെർക്കൽ ഹാഷ് ഉപയോഗിച്ച് സ്മാർട്ട് കരാർ, ബ്ലോക്കുകളിലെ ഇടപാടുകളുടെ സാന്നിധ്യം പരിശോധിക്കുകയും പിൻവലിക്കലിനുള്ള ടോക്കൺ അയയ്ക്കുകയും ചെയ്യുന്നു, അത് രണ്ടാഴ്ചയ്ക്കുള്ളിൽ സംഭവിക്കും.

6. ടോക്കൺ പിൻവലിക്കൽ പ്രവർത്തനം ലംഘനങ്ങളോടെയാണ് സംഭവിച്ചതെങ്കിൽ (പിൻവലിക്കൽ നടപടിക്രമം ആരംഭിച്ചതിന് ശേഷം ടോക്കൺ ചെലവഴിച്ചു അല്ലെങ്കിൽ പിൻവലിക്കുന്നതിന് മുമ്പ് ടോക്കൺ മറ്റാരുടെയോ ആയിരുന്നു), ടോക്കണിന്റെ ഉടമയ്ക്ക് രണ്ടാഴ്ചയ്ക്കുള്ളിൽ പിൻവലിക്കൽ നിരസിക്കാൻ കഴിയും.

രണ്ട് വഴികളിലൂടെയാണ് സ്വകാര്യത കൈവരിക്കുന്നത്

1. ചൈൽഡ് ചെയിനിനുള്ളിൽ ജനറേറ്റ് ചെയ്യുകയും ഫോർവേഡ് ചെയ്യുകയും ചെയ്യുന്ന ഇടപാടുകളെക്കുറിച്ച് റൂട്ട് ചെയിനിന് ഒന്നും അറിയില്ല. പ്ലാസ്മ ക്യാഷിൽ നിന്ന് ETH നിക്ഷേപിക്കുകയും പിൻവലിക്കുകയും ചെയ്തവരെക്കുറിച്ചുള്ള വിവരങ്ങൾ പൊതുവായി തുടരുന്നു.

2. zk-SNARK-കൾ ഉപയോഗിച്ചുള്ള അജ്ഞാത ഇടപാടുകൾ ചൈൽഡ് ചെയിൻ അനുവദിക്കുന്നു.

ടെക്നോളജി സ്റ്റാക്ക്

• നോഡ്ജെഎസ്
• രെദിസ്
• എതെറിയം
• മണ്ണ്

പരിശോധിക്കുന്നു

പ്ലാസ്മ ക്യാഷ് വികസിപ്പിക്കുന്നതിനിടയിൽ, ഞങ്ങൾ സിസ്റ്റത്തിന്റെ വേഗത പരീക്ഷിക്കുകയും ഇനിപ്പറയുന്ന ഫലങ്ങൾ നേടുകയും ചെയ്തു:

• ഒരു സെക്കൻഡിൽ 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. ഇന്റൽ കോർ i9-9900K ഒക്ടാ കോർ ഉൾപ്പെടെ. NVMe SSD - 1 TB, 64 GB DDR4 റാം
1 പ്ലാസ്മ ക്യാഷ് സബ്മിഷൻ നോഡ് ഉയർത്തി.
3 സാധുതയുള്ള പ്ലാസ്മ ക്യാഷ് നോഡുകൾ ഉയർത്തി.
പ്ലാസ്മ ക്യാഷ് നെറ്റ്‌വർക്കിലേക്ക് ഇടപാടുകൾ ചേർക്കുന്നതിനുള്ള ഒരു പരീക്ഷണം ആരംഭിച്ചു.

ആകെ: ഒരു സ്വകാര്യ നെറ്റ്‌വർക്കിലെ 10 പ്ലാസ്മ ക്യാഷ് നോഡുകൾ.

ടെസ്റ്റ് 1

ഒരു ബ്ലോക്കിന് 1 ദശലക്ഷം ഇടപാടുകൾ എന്ന പരിധിയുണ്ട്. അതിനാൽ, 1 ദശലക്ഷം ഇടപാടുകൾ 2 ബ്ലോക്കുകളായി പെടുന്നു (ഇടപാടുകളുടെ ഭാഗമെടുക്കാനും അവ അയയ്‌ക്കുമ്പോൾ സമർപ്പിക്കാനും സിസ്റ്റം നിയന്ത്രിക്കുന്നതിനാൽ).

പ്രാരംഭ നില: അവസാന ബ്ലോക്ക് #7; 1 ദശലക്ഷം ഇടപാടുകളും ടോക്കണുകളും ഡാറ്റാബേസിൽ സംഭരിച്ചിരിക്കുന്നു.

00:00 — ട്രാൻസാക്ഷൻ ജനറേഷൻ സ്ക്രിപ്റ്റിന്റെ തുടക്കം
01:37 - 1 ദശലക്ഷം ഇടപാടുകൾ സൃഷ്ടിച്ചു, നോഡിലേക്ക് അയയ്ക്കുന്നത് ആരംഭിച്ചു
01:46 — സബ്മിറ്റ് നോഡ് പൂളിൽ നിന്ന് 240k ഇടപാടുകൾ നടത്തി ബ്ലോക്ക് #8 ഫോമുകൾ. 320 സെക്കൻഡിനുള്ളിൽ 10 ഇടപാടുകൾ പൂളിൽ ചേർക്കപ്പെടുന്നതും ഞങ്ങൾ കാണുന്നു
01:58 — ബ്ലോക്ക് #8 ഒപ്പിട്ട് മൂല്യനിർണ്ണയത്തിനായി അയച്ചു
02:03 — ബ്ലോക്ക് #8 സാധൂകരിക്കപ്പെടുകയും സ്മാർട്ട് കരാറിന്റെ `സബ്മിറ്റ്ബ്ലോക്ക്' ഫംഗ്‌ഷനെ മെർക്ക്ലെ ഹാഷും ബ്ലോക്ക് നമ്പറും ഉപയോഗിച്ച് വിളിക്കുകയും ചെയ്യുന്നു.
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 — സബ്മിറ്റ് നോഡ് പൂളിൽ നിന്ന് 320k ഇടപാടുകൾ നടത്തി ബ്ലോക്ക് #10 ഫോമുകൾ. 320 സെക്കൻഡിനുള്ളിൽ 10 ഇടപാടുകൾ പൂളിൽ ചേർക്കപ്പെടുന്നതും ഞങ്ങൾ കാണുന്നു
01:12 — ബ്ലോക്ക് #10 ഒപ്പിട്ട് മൂല്യനിർണ്ണയത്തിനായി മറ്റ് നോഡുകളിലേക്ക് അയച്ചു
01:18 — ഡെമോ സ്ക്രിപ്റ്റ് 1 സെക്കൻഡിനുള്ളിൽ 34 ദശലക്ഷം ഇടപാടുകൾ അയച്ചു
01:20 — ബ്ലോക്ക് #10 സാധൂകരിക്കുകയും റൂട്ട് ചെയിനിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു
01:51 - ബ്ലോക്ക് #10 ചേർത്തു 320k ഇടപാടുകൾ പ്രയോഗിക്കാൻ തുടങ്ങുന്ന റൂട്ട് ചെയിനിൽ നിന്ന് എല്ലാ നോഡുകൾക്കും വിവരം ലഭിച്ചു
02:01 - ബ്ലോക്ക് #320-ലേക്ക് ചേർത്ത 10 ഇടപാടുകൾക്കായി പൂൾ മായ്ച്ചു.
02:15 — സബ്മിറ്റ് നോഡ് പൂളിൽ നിന്ന് 350 ഇടപാടുകൾ നടത്തി, ബ്ലോക്ക് #11
02:34 — ബ്ലോക്ക് #11 ഒപ്പിട്ട് മൂല്യനിർണ്ണയത്തിനായി മറ്റ് നോഡുകളിലേക്ക് അയച്ചു
02:51 — ബ്ലോക്ക് #11 സാധൂകരിക്കുകയും റൂട്ട് ചെയിനിലേക്ക് അയയ്ക്കുകയും ചെയ്യുന്നു
02:55 — ബ്ലോക്ക് #10-ൽ നിന്നുള്ള ഇടപാടുകൾ പൂർത്തിയാക്കിയ അവസാന നോഡ്
10:59 — ബ്ലോക്ക് #9 സമർപ്പണത്തോടെയുള്ള ഇടപാട് റൂട്ട് ശൃംഖലയിൽ വളരെയധികം സമയമെടുത്തു, പക്ഷേ അത് പൂർത്തിയാകുകയും എല്ലാ നോഡുകൾക്കും അതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കുകയും 350k ഇടപാടുകൾ നടത്തുകയും ചെയ്തു.
11:05 - ബ്ലോക്ക് #320-ലേക്ക് ചേർത്ത 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 പൂളിൽ നിന്ന് 330k ഇടപാടുകൾ നടത്തി #85 ബ്ലോക്ക് (f21). 350 സെക്കൻഡിനുള്ളിൽ 10 ഇടപാടുകൾ പൂളിൽ ചേർക്കപ്പെടുന്നതും ഞങ്ങൾ കാണുന്നു
01:53 — 1 ദശലക്ഷം ഇടപാടുകൾ സൃഷ്‌ടിക്കുകയും നോഡ് #1 സമർപ്പിക്കാൻ അയയ്‌ക്കുകയും ചെയ്‌തു
01:50 — സബ്മിറ്റ് നോഡ് #3 പൂളിൽ നിന്ന് 330k ഇടപാടുകൾ നടത്തി #85 ബ്ലോക്ക് (f21). 350 സെക്കൻഡിനുള്ളിൽ 10 ഇടപാടുകൾ പൂളിൽ ചേർക്കപ്പെടുന്നതും ഞങ്ങൾ കാണുന്നു
02:01 — സമർപ്പിക്കുക നോഡ് #1 പൂളിൽ നിന്ന് 250 ഇടപാടുകൾ നടത്തി #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 - #330 (f250), #111855(85e), #21(86) ബ്ലോക്കുകളിലേക്ക് ചേർത്ത 65k, 87k, 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. വർക്കർ_ത്രെഡുകൾ ഉപയോഗിക്കുക, കോഡിന്റെ ഭാഗത്തിന്റെ നിർവ്വഹണം ത്രെഡുകളിലേക്ക് നീക്കുക.

തൽഫലമായി, ഞങ്ങൾ ഒരേ സമയം രണ്ട് ഓപ്ഷനുകളും ഉപയോഗിച്ചു: ഞങ്ങൾ ഒരു നോഡിനെ 3 ഭാഗങ്ങളായി വിഭജിച്ചു, അത് വെവ്വേറെ പ്രവർത്തിക്കാൻ കഴിയും, എന്നാൽ അതേ സമയം സമന്വയത്തോടെ

1. സമർപ്പണ നോഡ്, ഇത് പൂളിലേക്ക് ഇടപാടുകൾ സ്വീകരിക്കുകയും ബ്ലോക്കുകൾ സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

2. നോഡുകളുടെ സാധുത പരിശോധിക്കുന്ന ഒരു സാധൂകരണ നോഡ്.

3. API നോഡ് - ഡാറ്റ ആക്സസ് ചെയ്യുന്നതിനായി ഒരു API നൽകുന്നു.

ഈ സാഹചര്യത്തിൽ, cli ഉപയോഗിച്ച് ഒരു unix സോക്കറ്റ് വഴി നിങ്ങൾക്ക് ഓരോ നോഡിലേക്കും കണക്ട് ചെയ്യാം.

മെർക്കൽ ട്രീയുടെ കണക്കുകൂട്ടൽ പോലുള്ള കനത്ത പ്രവർത്തനങ്ങൾ ഞങ്ങൾ ഒരു പ്രത്യേക ത്രെഡിലേക്ക് മാറ്റി.

അങ്ങനെ, എല്ലാ പ്ലാസ്മ ക്യാഷ് ഫംഗ്‌ഷനുകളുടെയും സാധാരണ പ്രവർത്തനം ഞങ്ങൾ ഒരേസമയം, പരാജയങ്ങളില്ലാതെ കൈവരിച്ചു.

സിസ്റ്റം പ്രവർത്തനക്ഷമമായിക്കഴിഞ്ഞാൽ, ഞങ്ങൾ വേഗത പരിശോധിക്കാൻ തുടങ്ങി, നിർഭാഗ്യവശാൽ, തൃപ്തികരമല്ലാത്ത ഫലങ്ങൾ ലഭിച്ചു: സെക്കൻഡിൽ 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 ഞങ്ങൾക്ക് അനുയോജ്യമല്ലെന്ന് സൂചിപ്പിക്കുന്നു. എനിക്ക് എല്ലാം തികച്ചും പ്രവർത്തനപരമായ സമീപനത്തിലേക്ക് മാറ്റിയെഴുതേണ്ടിവന്നു.

ഡാറ്റാബേസിൽ രേഖപ്പെടുത്തുന്നു

തുടക്കത്തിൽ, ഞങ്ങളുടെ ആവശ്യകതകൾ നിറവേറ്റുന്ന ഏറ്റവും ഉൽപ്പാദനക്ഷമമായ പരിഹാരങ്ങളിലൊന്നായി ഡാറ്റ സംഭരണത്തിനായി Redis തിരഞ്ഞെടുത്തു: കീ-മൂല്യം സംഭരണം, ഹാഷ് ടേബിളുകൾക്കൊപ്പം പ്രവർത്തിക്കുക, സെറ്റുകൾ. ഞങ്ങൾ redis-benchmark സമാരംഭിക്കുകയും 80 പൈപ്പ്ലൈനിംഗ് മോഡിൽ സെക്കൻഡിൽ ~1k പ്രവർത്തനങ്ങൾ നേടുകയും ചെയ്തു.

ഉയർന്ന പ്രകടനത്തിനായി, ഞങ്ങൾ Redis കൂടുതൽ നന്നായി ട്യൂൺ ചെയ്തു:

• ഒരു യുണിക്സ് സോക്കറ്റ് കണക്ഷൻ സ്ഥാപിച്ചു.
• ഡിസ്കിലേക്ക് സ്റ്റേറ്റ് സംരക്ഷിക്കുന്നത് ഞങ്ങൾ അപ്രാപ്തമാക്കി (വിശ്വാസ്യതയ്ക്കായി, നിങ്ങൾക്ക് ഒരു പകർപ്പ് സജ്ജീകരിക്കാനും ഒരു പ്രത്യേക Redis-ൽ ഡിസ്കിൽ സംരക്ഷിക്കാനും കഴിയും).

റെഡിസിൽ, ഒരു പൂൾ ഒരു ഹാഷ് ടേബിളാണ്, കാരണം ഞങ്ങൾക്ക് എല്ലാ ഇടപാടുകളും ഒരു ചോദ്യത്തിൽ വീണ്ടെടുക്കാനും ഇടപാടുകൾ ഓരോന്നായി ഇല്ലാതാക്കാനും കഴിയണം. ഞങ്ങൾ ഒരു സാധാരണ ലിസ്‌റ്റ് ഉപയോഗിക്കാൻ ശ്രമിച്ചു, പക്ഷേ മുഴുവൻ ലിസ്‌റ്റും അൺലോഡ് ചെയ്യുമ്പോൾ വേഗത കുറവാണ്.

സ്റ്റാൻഡേർഡ് NodeJS ഉപയോഗിക്കുമ്പോൾ, Redis ലൈബ്രറികൾ സെക്കൻഡിൽ 18k ഇടപാടുകൾ നടത്തി. വേഗത 9 തവണ കുറഞ്ഞു.

സാധ്യതകൾ 5 മടങ്ങ് കൂടുതലാണെന്ന് ബെഞ്ച്മാർക്ക് ഞങ്ങളെ കാണിച്ചുതന്നതിനാൽ, ഞങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യാൻ തുടങ്ങി. ഞങ്ങൾ ലൈബ്രറിയെ ioredis എന്നാക്കി മാറ്റുകയും സെക്കൻഡിൽ 25k പ്രകടനം നേടുകയും ചെയ്തു. `hset` കമാൻഡ് ഉപയോഗിച്ച് ഞങ്ങൾ ഇടപാടുകൾ ഓരോന്നായി ചേർത്തു. അതിനാൽ ഞങ്ങൾ റെഡിസിൽ ധാരാളം ചോദ്യങ്ങൾ ജനറേറ്റുചെയ്യുകയായിരുന്നു. ഇടപാടുകൾ ബാച്ചുകളായി സംയോജിപ്പിച്ച് ഒരു കമാൻഡ് `hmset` ഉപയോഗിച്ച് അയയ്ക്കുക എന്ന ആശയം ഉടലെടുത്തു. ഫലം സെക്കൻഡിൽ 32k ആണ്.

ഞങ്ങൾ താഴെ വിവരിക്കുന്ന നിരവധി കാരണങ്ങളാൽ, ഞങ്ങൾ `ബഫർ` ഉപയോഗിച്ച് ഡാറ്റയുമായി പ്രവർത്തിക്കുന്നു, എഴുതുന്നതിന് മുമ്പ് നിങ്ങൾ അത് ടെക്‌സ്‌റ്റിലേക്ക് (`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();`, `BD.decode(ബഫർ, പ്രോട്ടോക്കോൾ)` എന്നിവ ഉപയോഗിച്ച് 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 - 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` - സന്ദേശ ഐഡന്റിഫയർ;
• `countChunk` и `ചങ്ക് നമ്പർ` വലിയ സന്ദേശങ്ങൾ വിഭജിക്കുന്നതിന് ആവശ്യമാണ്;
• `നീളം` и `പേലോഡ്` ദൈർഘ്യവും ഡാറ്റയും.

ഞങ്ങൾ ഡാറ്റ മുൻകൂട്ടി ടൈപ്പ് ചെയ്തതിനാൽ, അന്തിമ സിസ്റ്റം Ethereum-ന്റെ `rlp` ലൈബ്രറിയേക്കാൾ വളരെ വേഗതയുള്ളതാണ്. നിർഭാഗ്യവശാൽ, ഞങ്ങൾക്ക് ഇത് നിരസിക്കാൻ ഇതുവരെ കഴിഞ്ഞിട്ടില്ല, കാരണം ഭാവിയിൽ ഞങ്ങൾ ചെയ്യാൻ ഉദ്ദേശിക്കുന്ന സ്മാർട്ട് കരാർ അന്തിമമാക്കേണ്ടത് ആവശ്യമാണ്.

നമുക്ക് വേഗത കൈവരിക്കാൻ കഴിഞ്ഞെങ്കിൽ 35 000 സെക്കൻഡിലെ ഇടപാടുകൾ, ഒപ്റ്റിമൽ സമയത്ത് ഞങ്ങൾ അവ പ്രോസസ്സ് ചെയ്യേണ്ടതുണ്ട്. ഏകദേശ ബ്ലോക്ക് രൂപീകരണ സമയം 30 സെക്കൻഡ് എടുക്കുന്നതിനാൽ, ഞങ്ങൾ ബ്ലോക്കിൽ ഉൾപ്പെടുത്തേണ്ടതുണ്ട് 1 000 000 ഇടപാടുകൾ, അതായത് കൂടുതൽ അയക്കുക എന്നാണ് 100 MB ഡാറ്റ.

തുടക്കത്തിൽ, നോഡുകൾക്കിടയിൽ ആശയവിനിമയം നടത്താൻ ഞങ്ങൾ `ethereumjs-devp2p` ലൈബ്രറി ഉപയോഗിച്ചു, പക്ഷേ അതിന് വളരെയധികം ഡാറ്റ കൈകാര്യം ചെയ്യാൻ കഴിഞ്ഞില്ല. തൽഫലമായി, ഞങ്ങൾ `ws` ലൈബ്രറി ഉപയോഗിക്കുകയും വെബ്‌സോക്കറ്റ് വഴി ബൈനറി ഡാറ്റ അയയ്ക്കുന്നത് കോൺഫിഗർ ചെയ്യുകയും ചെയ്തു. തീർച്ചയായും, വലിയ ഡാറ്റ പാക്കറ്റുകൾ അയയ്‌ക്കുമ്പോഴും ഞങ്ങൾ പ്രശ്‌നങ്ങൾ നേരിട്ടു, പക്ഷേ ഞങ്ങൾ അവയെ ഭാഗങ്ങളായി വിഭജിച്ചു, ഇപ്പോൾ ഈ പ്രശ്‌നങ്ങൾ ഇല്ലാതായി.

ഒരു മെർക്കൽ ട്രീ രൂപീകരിക്കുകയും ഹാഷ് കണക്കാക്കുകയും ചെയ്യുന്നു 1 000 000 ഇടപാടുകൾക്ക് ഏകദേശം ആവശ്യമാണ് 10 സെക്കന്റുകൾ തുടർച്ചയായ കണക്കുകൂട്ടൽ. ഈ സമയത്ത്, എല്ലാ നോഡുകളുമായുള്ള ബന്ധം തകർക്കാൻ നിയന്ത്രിക്കുന്നു. ഈ കണക്കുകൂട്ടൽ ഒരു പ്രത്യേക ത്രെഡിലേക്ക് മാറ്റാൻ തീരുമാനിച്ചു.

നിഗമനങ്ങൾ:

വാസ്തവത്തിൽ, ഞങ്ങളുടെ കണ്ടെത്തലുകൾ പുതിയതല്ല, എന്നാൽ ചില കാരണങ്ങളാൽ പല വിദഗ്ധരും വികസിപ്പിക്കുമ്പോൾ അവയെക്കുറിച്ച് മറക്കുന്നു.

• ഒബ്ജക്റ്റ് ഓറിയന്റഡ് പ്രോഗ്രാമിംഗിന് പകരം ഫങ്ഷണൽ പ്രോഗ്രാമിംഗ് ഉപയോഗിക്കുന്നത് ഉൽപ്പാദനക്ഷമത മെച്ചപ്പെടുത്തുന്നു.
• ഉൽപ്പാദനക്ഷമമായ NodeJS സിസ്റ്റത്തിനായുള്ള സേവന ആർക്കിടെക്ചറിനേക്കാൾ മോണോലിത്ത് മോശമാണ്.
• ഹെവി കംപ്യൂട്ടേഷനായി `worker_threads` ഉപയോഗിക്കുന്നത് സിസ്റ്റം പ്രതികരണശേഷി മെച്ചപ്പെടുത്തുന്നു, പ്രത്യേകിച്ച് i/o ഓപ്പറേഷനുകൾ കൈകാര്യം ചെയ്യുമ്പോൾ.
• unix സോക്കറ്റ് http അഭ്യർത്ഥനകളേക്കാൾ കൂടുതൽ സ്ഥിരതയുള്ളതും വേഗതയുള്ളതുമാണ്.
• നിങ്ങൾക്ക് നെറ്റ്‌വർക്കിലൂടെ വലിയ ഡാറ്റ വേഗത്തിൽ കൈമാറണമെങ്കിൽ, വെബ്‌സോക്കറ്റുകൾ ഉപയോഗിക്കുന്നതും ബൈനറി ഡാറ്റ അയയ്ക്കുന്നതും നല്ലതാണ്, അവ വരുന്നില്ലെങ്കിൽ ഫോർവേഡ് ചെയ്യാം, തുടർന്ന് ഒരു സന്ദേശമായി സംയോജിപ്പിക്കാം.

സന്ദർശിക്കാൻ ഞങ്ങൾ നിങ്ങളെ ക്ഷണിക്കുന്നു സാമൂഹികം പദ്ധതി: https://github.com/opporty-com/Plasma-Cash/tree/new-version

എന്നിവർ ചേർന്നാണ് ലേഖനം എഴുതിയത് അലക്സാണ്ടർ നശിവൻ, മുതിർന്ന ഡെവലപ്പർ Clever Solution Inc.

അവലംബം: www.habr.com