ഫേസ്‌ബുക്കിന്റെ ലിബ്ര ബ്ലോക്ക്‌ചെയിൻ പ്രോഗ്രാമിംഗ് ഭാഷയായ മൂവ്-ലേക്ക് ഡൈവ് ചെയ്യുക

അടുത്തതായി, മൂവ് ഭാഷയുടെ പ്രധാന സവിശേഷതകളും സ്മാർട്ട് കരാറുകൾക്കുള്ള മറ്റൊരു ജനപ്രിയ ഭാഷയുമായുള്ള അതിന്റെ പ്രധാന വ്യത്യാസങ്ങൾ എന്തൊക്കെയാണെന്ന് ഞങ്ങൾ വിശദമായി പരിഗണിക്കും - സോളിഡിറ്റി (Ethereum പ്ലാറ്റ്ഫോമിൽ). ലഭ്യമായ ഓൺലൈൻ 26 പേജുള്ള വൈറ്റ്പേപ്പറിന്റെ പഠനത്തെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് ഈ മെറ്റീരിയൽ.

ആമുഖം

ഉപയോക്തൃ ഇടപാടുകളും സ്‌മാർട്ട് കരാറുകളും നടപ്പിലാക്കാൻ ഉപയോഗിക്കുന്ന എക്‌സിക്യൂട്ടബിൾ ബൈറ്റ്‌കോഡ് ഭാഷയാണ് മൂവ്. ദയവായി രണ്ട് പോയിന്റുകൾ ശ്രദ്ധിക്കുക:

1. മൂവ് വെർച്വൽ മെഷീനിൽ നേരിട്ട് നടപ്പിലാക്കാൻ കഴിയുന്ന ഒരു ബൈറ്റ്കോഡ് ഭാഷയാണെങ്കിലും, സോളിഡിറ്റി (Ethereum- ന്റെ സ്മാർട്ട് കരാർ ഭാഷ) ഒരു EVM (Ethereum Virtual Machine) ൽ നടപ്പിലാക്കുന്നതിനുമുമ്പ് ആദ്യമായി ബൈറ്റ്കോഡിലേക്ക് സമാഹരിച്ച ഒരു ഉയർന്ന തലത്തിലുള്ള ഭാഷയാണ്.
2. സ്മാർട്ട് കരാറുകൾ നടപ്പിലാക്കാൻ മാത്രമല്ല, ഇഷ്‌ടാനുസൃത ഇടപാടുകൾക്കും മൂവ് ഉപയോഗിക്കാൻ കഴിയും (പിന്നീട് ഇതിനെക്കുറിച്ച് കൂടുതൽ), സോളിഡിറ്റി ഒരു മികച്ച കരാർ മാത്രമുള്ള ഭാഷയാണ്.

INDEX പ്രോട്ടോക്കോൾ പ്രോജക്ട് ടീമാണ് വിവർത്തനം നടത്തിയത്. ഞങ്ങൾ ഇതിനകം വിവർത്തനം ചെയ്തിട്ടുണ്ട് തുലാം പദ്ധതി വിവരിക്കുന്ന വലിയ മെറ്റീരിയൽ, ഇപ്പോൾ മൂവ് ഭാഷയെ കുറച്ചുകൂടി വിശദമായി നോക്കേണ്ട സമയമാണിത്. ഹബ്രൗസറുമായി ചേർന്നാണ് വിവർത്തനം നടത്തിയത് കൂൾസിയു

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

ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്ന കോഡ് സ്നിപ്പെറ്റ് ഒരു പിശക് എറിയും: നീക്കിയ മൂല്യം 'x' ഉപയോഗം. റസ്റ്റിൽ മാലിന്യ ശേഖരണം ഇല്ലാത്തതിനാലാണിത്. വേരിയബിളുകൾ പരിധിയിൽ നിന്ന് പോകുമ്പോൾ, അവ പരാമർശിക്കുന്ന മെമ്മറിയും സ്വതന്ത്രമാകും. ലളിതമായി പറഞ്ഞാൽ, ഡാറ്റയുടെ ഒരു "ഉടമ" മാത്രമേ ഉണ്ടാകൂ. ഈ ഉദാഹരണത്തിൽ x യഥാർത്ഥ ഉടമയും തുടർന്ന് y പുതിയ ഉടമയായി മാറുന്നു. ഈ പെരുമാറ്റത്തെക്കുറിച്ച് കൂടുതൽ ഇവിടെ വായിക്കുക.

തുറന്ന സംവിധാനങ്ങളിൽ ഡിജിറ്റൽ ആസ്തികളുടെ പ്രാതിനിധ്യം

ഡിജിറ്റലായി പ്രതിനിധീകരിക്കാൻ ബുദ്ധിമുട്ടുള്ള ഭൗതിക ആസ്തികളുടെ രണ്ട് ഗുണങ്ങളുണ്ട്:

• അപൂർവത (ക്ഷാമം, യഥാർത്ഥത്തിൽ ക്ഷാമം). സിസ്റ്റത്തിലെ ആസ്തികളുടെ എണ്ണം (എമിഷൻ) നിയന്ത്രിക്കണം. നിലവിലുള്ള ആസ്തികളുടെ തനിപ്പകർപ്പ് നിരോധിക്കണം, പുതിയവ സൃഷ്ടിക്കുന്നത് ഒരു പ്രത്യേക പ്രവർത്തനമാണ്.
• പ്രവേശന നിയന്ത്രണം... ആക്‌സസ് നിയന്ത്രണ നയങ്ങൾ ഉപയോഗിച്ച് സ്വത്ത് പരിരക്ഷിക്കാൻ സിസ്റ്റം പങ്കാളിയ്ക്ക് കഴിയണം.

ഭൗതിക ആസ്തികൾക്ക് സ്വാഭാവികമായ ഈ രണ്ട് സ്വഭാവവിശേഷങ്ങളും ഡിജിറ്റൽ വസ്തുക്കൾക്ക് അസറ്റുകളായി പരിഗണിക്കണമെങ്കിൽ അവ നടപ്പിലാക്കണം. ഉദാഹരണത്തിന്, ഒരു അപൂർവ ലോഹത്തിന് സ്വാഭാവിക ക്ഷാമമുണ്ട്, നിങ്ങൾക്ക് മാത്രമേ അതിലേക്ക് പ്രവേശനമുള്ളൂ (ഉദാഹരണത്തിന്, അത് നിങ്ങളുടെ കൈയിൽ പിടിക്കുക), നിങ്ങൾക്ക് അത് വിൽക്കാനോ ചെലവഴിക്കാനോ കഴിയും.

ഈ രണ്ട് പ്രോപ്പർട്ടികളിൽ ഞങ്ങൾ എങ്ങനെ എത്തിച്ചേർന്നുവെന്ന് വ്യക്തമാക്കുന്നതിന്, ഇനിപ്പറയുന്ന വാക്യങ്ങളിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം:

നിർദ്ദേശം # 1: ദൗർലഭ്യവും പ്രവേശന നിയന്ത്രണവും ഇല്ലാത്ത ലളിതമായ നിയമം

• ജി [കെ]: = എൻ ഒരു കീ ഉപയോഗിച്ച് ആക്സസ് ചെയ്യാവുന്ന ഒരു നമ്പറിലേക്കുള്ള അപ്ഡേറ്റ് സൂചിപ്പിക്കുന്നു К ബ്ലോക്ക്‌ചെയിനിന്റെ ആഗോള അവസ്ഥയിൽ, ഒരു പുതിയ അർത്ഥത്തോടെ n.
• ഇടപാട് ⟨ആലീസ്, 100⟩ ആലീസിന്റെ അക്കൗണ്ട് ബാലൻസ് 100 ആക്കുക എന്നാണ് അർത്ഥമാക്കുന്നത്.

മുകളിലുള്ള പരിഹാരത്തിന് നിരവധി പ്രധാന പ്രശ്നങ്ങളുണ്ട്:

• ലളിതമായി അയച്ചുകൊണ്ട് ആലീസിന് പരിധിയില്ലാത്ത നാണയങ്ങൾ ലഭിക്കും ഇടപാട് ⟨ആലീസ്, 100⟩.
• ആബിസ് ബോബിന് അയക്കുന്ന നാണയങ്ങൾ ഉപയോഗശൂന്യമാണ്, കാരണം അതേ സാങ്കേതികവിദ്യ ഉപയോഗിച്ച് ബോബിന് സ്വയം പരിധിയില്ലാത്ത നാണയങ്ങൾ അയയ്ക്കാൻ കഴിയും.

നിർദ്ദേശം # 2: കമ്മി കണക്കിലെടുക്കുന്നു

ഇപ്പോൾ ഞങ്ങൾ നാണയങ്ങളുടെ എണ്ണം അങ്ങനെ സ്ഥിതി നിരീക്ഷിക്കുന്നു Ka കുറഞ്ഞത് തുല്യമായിരുന്നു n കൈമാറ്റ ഇടപാടിന് മുമ്പ്. എന്നിരുന്നാലും, ഇത് ക്ഷാമത്തിന്റെ പ്രശ്നം പരിഹരിക്കുമ്പോൾ, ആലീസിന്റെ നാണയങ്ങൾ ആർക്കാണ് അയയ്ക്കാനാവുക എന്നതിനെക്കുറിച്ച് വിവരമില്ല (ഇപ്പോൾ, ആർക്കും ഇത് ചെയ്യാൻ കഴിയും, പ്രധാന കാര്യം തുക പരിമിതപ്പെടുത്തുന്ന നിയമം ലംഘിക്കരുത്).

നിർദ്ദേശം # 3: ക്ഷാമവും ആക്സസ് നിയന്ത്രണവും സംയോജിപ്പിക്കുന്നു

ഡിജിറ്റൽ സിഗ്നേച്ചർ സംവിധാനം ഉപയോഗിച്ച് ഞങ്ങൾ ഈ പ്രശ്നം പരിഹരിക്കുന്നു verify_sig ബാലൻസ് പരിശോധിക്കുന്നതിന് മുമ്പ്, അതായത് ആലീസ് ഇടപാടിൽ ഒപ്പിടാനും അവളുടെ നാണയങ്ങളുടെ ഉടമയാണെന്ന് സ്ഥിരീകരിക്കാനും അവളുടെ സ്വകാര്യ കീ ഉപയോഗിക്കുന്നു.

ബ്ലോക്ക്‌ചെയിൻ പ്രോഗ്രാമിംഗ് ഭാഷകൾ

നിലവിലുള്ള ബ്ലോക്ക്‌ചെയിൻ ഭാഷകൾ ഇനിപ്പറയുന്ന പ്രശ്നങ്ങൾ അഭിമുഖീകരിക്കുന്നു (അവയെല്ലാം നീക്കത്തിൽ പരിഹരിക്കപ്പെട്ടു (കുറിപ്പ്: നിർഭാഗ്യവശാൽ, ലേഖനത്തിന്റെ രചയിതാവ് തന്റെ താരതമ്യങ്ങളിൽ Ethereum- നോട് അഭ്യർത്ഥിക്കുന്നു, അതിനാൽ ഈ പശ്ചാത്തലത്തിൽ മാത്രം അവ എടുക്കുന്നത് മൂല്യവത്താണ്. ഉദാഹരണത്തിന്, ഇനിപ്പറയുന്നവയിൽ ഭൂരിഭാഗവും EOS- ലും പരിഹരിച്ചിരിക്കുന്നു.)):

ആസ്തികളുടെ പരോക്ഷ പ്രാതിനിധ്യം. ഒരു അസറ്റ് ഒരു പൂർണ്ണസംഖ്യ ഉപയോഗിച്ച് എൻകോഡ് ചെയ്‌തിരിക്കുന്നു, എന്നാൽ ഒരു പൂർണ്ണസംഖ്യ ഒരു അസറ്റിന് തുല്യമല്ല. വാസ്തവത്തിൽ, ബിറ്റ്കോയിൻ/ഈതർ/<ഏതെങ്കിലും നാണയം> പ്രതിനിധീകരിക്കുന്ന തരമോ മൂല്യമോ ഇല്ല! ഇത് അസറ്റുകൾ ഉപയോഗിക്കുന്ന പ്രോഗ്രാമുകൾ എഴുതുന്നത് ബുദ്ധിമുട്ടുള്ളതും പിശകുള്ളതുമാക്കുന്നു. നടപടിക്രമങ്ങളിലേക്ക് അസറ്റുകൾ കൈമാറുന്നതോ ഘടനകളിൽ അസറ്റുകൾ സംഭരിക്കുന്നതോ പോലുള്ള പാറ്റേണുകൾക്ക് ഭാഷയിൽ നിന്ന് പ്രത്യേക പിന്തുണ ആവശ്യമാണ്.

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

ഉപയോക്താക്കൾ അവരുടെ ആസ്തികൾ, ERC-20 ടോക്കണുകൾ, മൂല്യവും മൊത്തം വിതരണവും നിർണ്ണയിക്കാൻ പൂർണ്ണസംഖ്യകൾ ഉപയോഗിക്കുന്നു. പുതിയ ടോക്കണുകൾ സൃഷ്ടിക്കുമ്പോഴെല്ലാം, സ്മാർട്ട് കരാർ കോഡ് മലിനീകരണ നിയമങ്ങൾ പാലിക്കുന്നുണ്ടോ എന്ന് സ്വതന്ത്രമായി പരിശോധിക്കണം. കൂടാതെ, ആസ്തികളുടെ പരോക്ഷമായ അവതരണം ചില സന്ദർഭങ്ങളിൽ ഗുരുതരമായ പിശകുകളിലേക്ക് നയിക്കുന്നു - തനിപ്പകർപ്പ്, ഇരട്ട ചെലവ് അല്ലെങ്കിൽ സമ്പത്തിന്റെ പൂർണ്ണ നഷ്ടം.

വഴങ്ങുന്ന ആക്സസ് നിയന്ത്രണത്തിന്റെ അഭാവം... ഇന്ന് ഉപയോഗത്തിലുള്ള ഒരേയൊരു ആക്സസ് നിയന്ത്രണ നയം അസമമായ ക്രിപ്റ്റോഗ്രാഫി ഉപയോഗിച്ചുള്ള ഒരു ഒപ്പ് പദ്ധതിയാണ്. ക്ഷാമം സംരക്ഷണം പോലെ, ആക്സസ് നിയന്ത്രണ നയങ്ങളും ഭാഷയുടെ അർത്ഥശാസ്ത്രത്തിൽ ആഴത്തിൽ ഉൾക്കൊള്ളുന്നു. എന്നാൽ പ്രോഗ്രാമർമാർക്ക് അവരുടെ സ്വന്തം ആക്സസ് നിയന്ത്രണ നയങ്ങൾ നിർവ്വചിക്കാൻ ഭാഷ എങ്ങനെ വിപുലീകരിക്കാം എന്നത് പലപ്പോഴും വളരെ ബുദ്ധിമുട്ടുള്ള കാര്യമാണ്.

സ്‌മാർട്ട് കരാറുകൾക്ക് ആക്‌സസ്സ് നിയന്ത്രണത്തിന് നേറ്റീവ് ക്രിപ്‌റ്റോഗ്രഫി പിന്തുണ ഇല്ലാത്ത Ethereum-ലും ഇത് ശരിയാണ്. ഡവലപ്പർമാർ സ്വമേധയാ ആക്സസ് നിയന്ത്രണം സജ്ജമാക്കണം, ഉദാഹരണത്തിന്, ഒൺലി ഓണർ മോഡിഫയർ ഉപയോഗിച്ച്.

ഞാൻ Ethereum-ന്റെ വലിയ ആരാധകനാണെങ്കിലും, അസറ്റ് പ്രോപ്പർട്ടികൾ സുരക്ഷാ ആവശ്യങ്ങൾക്കായി ഭാഷയുടെ പ്രാദേശികമായി പിന്തുണയ്ക്കണമെന്ന് ഞാൻ വിശ്വസിക്കുന്നു. പ്രത്യേകിച്ചും, ഈതറിനെ ഒരു സ്‌മാർട്ട് കരാറിലേക്ക് മാറ്റുന്നതിൽ ഡൈനാമിക് ഡിസ്‌പാച്ച് ഉൾപ്പെടുന്നു, ഇത് റീ-എൻട്രൻസി വൾനറബിലിറ്റികൾ എന്നറിയപ്പെടുന്ന ഒരു പുതിയ തരം ബഗുകൾ അവതരിപ്പിച്ചു. ഇവിടെ ഡൈനാമിക് ഡിസ്പാച്ച് അർത്ഥമാക്കുന്നത് കോഡിന്റെ എക്സിക്യൂഷൻ ലോജിക്ക് കംപൈൽ സമയത്തേക്കാൾ (സ്റ്റാറ്റിക്) റൺടൈമിൽ (ഡൈനാമിക്) നിർണ്ണയിക്കപ്പെടും എന്നാണ്.

അങ്ങനെ, സോളിഡിറ്റിയിൽ, കോൺട്രാക്‌ട് B-യിലെ ഒരു ഫംഗ്‌ഷനെ കരാർ A വിളിക്കുമ്പോൾ, കോൺട്രാക്‌റ്റ് B, കരാർ A-യുടെ ഡെവലപ്പർ ഉദ്ദേശിച്ചിട്ടില്ലാത്ത കോഡ് പ്രവർത്തിപ്പിച്ചേക്കാം, അത് കാരണമാകാം റീ-എൻട്രി കേടുപാടുകൾ (അക്കൌണ്ട് ബാലൻസുകൾ യഥാർത്ഥത്തിൽ കുറയ്ക്കുന്നതിന് മുമ്പ് പണം പിൻവലിക്കാൻ കരാർ A ആകസ്മികമായി കരാർ B ആയി പ്രവർത്തിക്കുന്നു).

മൂവ് ലാംഗ്വേജ് ഡിസൈൻ അടിസ്ഥാനങ്ങൾ

ആദ്യ ഓർഡർ ഉറവിടങ്ങൾ

ഉയർന്ന തലത്തിൽ, മൂവ് ഭാഷയിലെ മൊഡ്യൂളുകൾ / ഉറവിടങ്ങൾ / നടപടിക്രമങ്ങൾ തമ്മിലുള്ള ഇടപെടൽ OOP ഭാഷകളിലെ ക്ലാസുകൾ / വസ്തുക്കൾ, രീതികൾ എന്നിവ തമ്മിലുള്ള ബന്ധത്തിന് സമാനമാണ്.
മറ്റ് ബ്ലോക്ക്‌ചെയിനുകളിലെ സ്മാർട്ട് കരാറുകൾക്ക് സമാനമാണ് മൂവ് മൊഡ്യൂളുകൾ. പ്രഖ്യാപിത ഉറവിടങ്ങൾ സൃഷ്ടിക്കുന്നതിനും നശിപ്പിക്കുന്നതിനും അപ്‌ഡേറ്റ് ചെയ്യുന്നതിനുമുള്ള നിയമങ്ങൾ നിർവ്വചിക്കുന്ന ഉറവിട തരങ്ങളും നടപടിക്രമങ്ങളും മൊഡ്യൂൾ പ്രഖ്യാപിക്കുന്നു. എന്നാൽ ഇതെല്ലാം വെറും കൺവെൻഷനുകൾ മാത്രമാണ് ("പദപ്രയോഗം”) നീങ്ങുന്നു. കുറച്ച് കഴിഞ്ഞ് ഞങ്ങൾ ഈ കാര്യം വിശദീകരിക്കും.

വഴക്കം

സ്ക്രിപ്റ്റിംഗിലൂടെ മൂവ് ലിബ്രയ്ക്ക് വഴക്കം നൽകുന്നു. തുലാം രാശിയിലെ എല്ലാ ഇടപാടുകളിലും ഒരു സ്ക്രിപ്റ്റ് ഉൾപ്പെടുന്നു, അത് പ്രധാനമായും ഇടപാടിന്റെ പ്രധാന നടപടിക്രമമാണ്. സ്‌ക്രിപ്റ്റിന് ഒന്നുകിൽ ഒരു നിർദ്ദിഷ്ട പ്രവർത്തനം നടത്താൻ കഴിയും, ഉദാഹരണത്തിന്, സ്വീകർത്താക്കളുടെ ഒരു നിർദ്ദിഷ്ട ലിസ്റ്റിലേക്കുള്ള പേയ്‌മെന്റുകൾ, അല്ലെങ്കിൽ മറ്റ് ഉറവിടങ്ങൾ വീണ്ടും ഉപയോഗിക്കുക - ഉദാഹരണത്തിന്, പൊതുവായ ലോജിക് വ്യക്തമാക്കിയ ഒരു നടപടിക്രമം വിളിക്കുന്നതിലൂടെ. അതുകൊണ്ടാണ് മൂവ് ട്രാൻസാക്ഷൻ സ്ക്രിപ്റ്റുകൾ കൂടുതൽ വഴക്കം നൽകുന്നത്. ഒരു സ്‌ക്രിപ്‌റ്റിന് ഒറ്റത്തവണയും ആവർത്തിക്കുന്ന സ്വഭാവങ്ങളും ഉപയോഗിക്കാൻ കഴിയും, അതേസമയം Ethereum-ന് ആവർത്തിക്കാവുന്ന സ്‌ക്രിപ്റ്റുകൾ മാത്രമേ എക്‌സിക്യൂട്ട് ചെയ്യാനാകൂ (ഒരു സ്‌മാർട്ട് കോൺട്രാക്‌റ്റ് രീതിയിൽ ഒരു രീതി വിളിക്കുന്നത്). ഒരു സ്‌മാർട്ട് കരാറിന്റെ പ്രവർത്തനങ്ങൾ ഒന്നിലധികം തവണ എക്‌സിക്യൂട്ട് ചെയ്യാൻ കഴിയുന്നതിനാലാണ് ഇതിനെ "പുനരുപയോഗിക്കാവുന്നത്" എന്ന് വിളിക്കുന്നത്. (കുറിപ്പ്: ഇവിടെ പോയിന്റ് വളരെ സൂക്ഷ്മമാണ്. ഒരു വശത്ത്, കപട-ബൈറ്റ്കോഡിന്റെ രൂപത്തിലുള്ള ഇടപാട് സ്ക്രിപ്റ്റുകളും ബിറ്റ്കോയിനിൽ നിലവിലുണ്ട്. മറുവശത്ത്, ഞാൻ മനസ്സിലാക്കിയതുപോലെ, മൂവ് ഈ ഭാഷയെ വിപുലീകരിക്കുന്നു, വാസ്തവത്തിൽ, ഒരു സമ്പൂർണ്ണ സ്മാർട്ട് കരാർ ഭാഷയുടെ തലത്തിലേക്ക്).

സുരക്ഷ

Move എക്സിക്യൂട്ടബിൾ ഫോർമാറ്റ് bytecode ആണ്, ഇത് ഒരു വശത്ത്, അസംബ്ലി ഭാഷയേക്കാൾ ഉയർന്ന ലെവൽ ഭാഷയാണ്, എന്നാൽ സോഴ്സ് കോഡിനേക്കാൾ താഴ്ന്ന നിലയാണ്. ബൈറ്റ്കോഡ് വെരിഫയർ ഉപയോഗിച്ച് ഉറവിടങ്ങൾ, തരങ്ങൾ, മെമ്മറി സുരക്ഷ എന്നിവയ്ക്കായി റൺ-ടൈമിൽ (ഓൺ-ചെയിൻ) ബൈറ്റ്കോഡ് പരിശോധിക്കുന്നു, തുടർന്ന് ഇന്റർപ്രെട്ടർ എക്സിക്യൂട്ട് ചെയ്യുന്നു. ഈ സമീപനം സോഴ്‌സ് കോഡിന്റെ സുരക്ഷ നൽകുന്നതിന് Move-നെ അനുവദിക്കുന്നു, എന്നാൽ കംപൈലേഷൻ പ്രക്രിയ കൂടാതെ സിസ്റ്റത്തിലേക്ക് ഒരു കമ്പൈലർ ചേർക്കേണ്ട ആവശ്യമില്ല. മൂവ് ഒരു ബൈറ്റ്കോഡ് ഭാഷയാക്കുന്നത് ഒരു നല്ല പരിഹാരമാണ്. സോളിഡിറ്റിയുടെ കാര്യത്തിലെന്നപോലെ ഇത് ഉറവിടത്തിൽ നിന്ന് സമാഹരിക്കേണ്ട ആവശ്യമില്ല, കൂടാതെ കംപൈലർ ഇൻഫ്രാസ്ട്രക്ചറിൽ സാധ്യമായ പരാജയങ്ങളെക്കുറിച്ചോ ആക്രമണങ്ങളെക്കുറിച്ചോ വിഷമിക്കേണ്ടതില്ല.

പരിശോധിച്ചുറപ്പിക്കൽ

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

മോഡുലാരിറ്റി

മൂവ് മൊഡ്യൂളുകൾ ഡാറ്റ സംഗ്രഹം നൽകുകയും ഉറവിടങ്ങളിലെ നിർണായക പ്രവർത്തനങ്ങൾ പ്രാദേശികവൽക്കരിക്കുകയും ചെയ്യുന്നു. മൊഡ്യൂൾ നൽകുന്ന എൻക്യാപ്സുലേഷൻ, മൂവ് ടൈപ്പ് സിസ്റ്റം നൽകുന്ന പരിരക്ഷയോടൊപ്പം, മൊഡ്യൂളിന്റെ തരങ്ങളിൽ സജ്ജീകരിച്ചിരിക്കുന്ന പ്രോപ്പർട്ടികൾ മൊഡ്യൂളിന് പുറത്തുള്ള കോഡ് ഉപയോഗിച്ച് ലംഘിക്കാൻ കഴിയില്ലെന്ന് ഉറപ്പാക്കുന്നു. ഇത് വളരെ നന്നായി ചിന്തിച്ചുള്ള അമൂർത്ത രൂപകൽപ്പനയാണ്, അതായത് കരാറിനുള്ളിലെ ഡാറ്റയ്ക്ക് കരാറിന്റെ ചട്ടക്കൂടിനുള്ളിൽ മാത്രമേ മാറാൻ കഴിയൂ, പക്ഷേ പുറത്ത് അല്ല.

അവലോകനം നീക്കുക

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

പിയർ-ടു-പിയർ പേയ്മെന്റുകൾ

തുകയിൽ വ്യക്തമാക്കിയ നാണയങ്ങളുടെ എണ്ണം അയച്ചയാളുടെ ബാലൻസിൽ നിന്ന് സ്വീകർത്താവിന് കൈമാറും.
ഇവിടെ കുറച്ച് പുതിയ കാര്യങ്ങൾ ഉണ്ട് (ചുവപ്പ് നിറത്തിൽ ഹൈലൈറ്റ് ചെയ്തിരിക്കുന്നു):

• 0x0: മൊഡ്യൂൾ സൂക്ഷിച്ചിരിക്കുന്ന അക്കൗണ്ടിന്റെ വിലാസം
• കറൻസി: മൊഡ്യൂളിന്റെ പേര്
• നാണയം: വിഭവ തരം
• നടപടിക്രമം മടക്കിനൽകുന്ന നാണയ മൂല്യം 0x0.Currency.Coin ടൈപ്പിന്റെ ഒരു റിസോഴ്സ് മൂല്യമാണ്
• നീക്കുക (): മൂല്യം വീണ്ടും ഉപയോഗിക്കാൻ കഴിയില്ല
• കോപ്പി (): മൂല്യം പിന്നീട് ഉപയോഗിക്കാം

കോഡ് പാഴ്സ് ചെയ്യുക: ആദ്യ ഘട്ടത്തിൽ, അയച്ചയാൾ ഒരു നടപടിക്രമത്തെ വിളിക്കുന്നു പിൻവലിക്കുക_ അയച്ചയാളിൽ നിന്ന് സംഭരിച്ചിരിക്കുന്ന ഒരു മൊഡ്യൂളിൽ നിന്ന് 0x0.നാണയം. രണ്ടാം ഘട്ടത്തിൽ, അയക്കുന്നയാൾ നാണയ വിഭവ മൂല്യം മൊഡ്യൂളിന്റെ നിക്ഷേപ നടപടിക്രമത്തിലേക്ക് നീക്കിക്കൊണ്ട് സ്വീകർത്താവിന് ഫണ്ട് കൈമാറുന്നു. 0x0.നാണയം.

ചെക്കുകൾ വഴി നിരസിക്കുന്ന കോഡിലെ പിശകുകളുടെ മൂന്ന് ഉദാഹരണങ്ങൾ ഇതാ:
കോൾ മാറ്റിക്കൊണ്ട് ഫണ്ടുകളുടെ തനിപ്പകർപ്പ് നീക്കുക (നാണയം) ഓൺ കോപ്പി (നാണയം). വിഭവങ്ങൾ നീക്കാൻ മാത്രമേ കഴിയൂ. ഒരു റിസോഴ്സിന്റെ അളവ് തനിപ്പകർപ്പാക്കാൻ ശ്രമിക്കുന്നു (ഉദാഹരണത്തിന്, വിളിക്കുന്നതിലൂടെ കോപ്പി (നാണയം) മുകളിലുള്ള ഉദാഹരണത്തിൽ) ബൈറ്റ്കോഡ് പരിശോധിക്കുമ്പോൾ ഒരു പിശക് ഉണ്ടാകും.

വ്യക്തമാക്കി ഫണ്ടുകളുടെ പുനരുപയോഗം നീക്കുക (നാണയം) രണ്ടുതവണ . ഒരു വരി ചേർക്കുന്നു 0x0.Currency.deposit (പകർപ്പ് (മറ്റൊരു_പണക്കാരൻ), നീക്കുക (നാണയം)) ഉദാഹരണത്തിന്, മുകളിൽ പറഞ്ഞവ അയക്കുന്നയാളെ രണ്ടുതവണ നാണയങ്ങൾ "ചെലവഴിക്കാൻ" അനുവദിക്കും - ആദ്യമായി പണം സ്വീകരിക്കുന്നയാളുമായി, രണ്ടാമത്തേത് ചില_മറ്റൊരു_പണക്കാരൻ. ശാരീരിക ആസ്തി കൊണ്ട് സാധ്യമല്ലാത്ത അനഭിലഷണീയമായ പെരുമാറ്റമാണിത്. ഭാഗ്യവശാൽ, മൂവ് ഈ പ്രോഗ്രാം നിരസിക്കും.

വിസമ്മതം കാരണം ഫണ്ട് നഷ്ടം നീക്കുക (നാണയം). നിങ്ങൾ ഉറവിടം നീക്കുന്നില്ലെങ്കിൽ (ഉദാഹരണത്തിന്, അടങ്ങുന്ന ലൈൻ ഇല്ലാതാക്കുന്നതിലൂടെ നീക്കുക (നാണയം)), ഒരു ബൈറ്റ്കോഡ് സ്ഥിരീകരണ പിശക് എറിയപ്പെടും. ഇത് മൂവ് പ്രോഗ്രാമർമാരെ ആകസ്മികമോ ക്ഷുദ്രകരമായതോ ആയ ഫണ്ടുകളുടെ നഷ്ടത്തിൽ നിന്ന് സംരക്ഷിക്കുന്നു.

കറൻസി മൊഡ്യൂൾ

ഓരോ അക്കൗണ്ടിലും 0 അല്ലെങ്കിൽ കൂടുതൽ മൊഡ്യൂളുകളും (ദീർഘചതുരങ്ങളായി കാണിച്ചിരിക്കുന്നു) ഒന്നോ അതിലധികമോ റിസോഴ്സ് മൂല്യങ്ങളും (സിലിണ്ടറുകളായി കാണിച്ചിരിക്കുന്നു) അടങ്ങിയിരിക്കാം. ഉദാഹരണത്തിന്, ഒരു അക്കൗണ്ട് 0x0 മൊഡ്യൂൾ അടങ്ങിയിരിക്കുന്നു 0x0.നാണയം റിസോഴ്സ് തരത്തിന്റെ മൂല്യവും 0x0.Currency.Coin. വിലാസത്തിൽ അക്കൗണ്ട് 0x1 രണ്ട് ഉറവിടങ്ങളും ഒരു മൊഡ്യൂളും ഉണ്ട്; വിലാസത്തിൽ അക്കൗണ്ട് 0x2 രണ്ട് മൊഡ്യൂളുകളും ഒരു റിസോഴ്സ് മൂല്യവുമുണ്ട്.

നെകൊട്ടറി നിമിഷങ്ങൾ:

• ട്രാൻസാക്ഷൻ സ്ക്രിപ്റ്റ് ആറ്റോമിക് ആണ് - ഒന്നുകിൽ അത് പൂർണ്ണമായി എക്സിക്യൂട്ട് ചെയ്യുന്നു അല്ലെങ്കിൽ ഇല്ല.
• മൊഡ്യൂൾ എന്നത് ആഗോളതലത്തിൽ ആക്സസ് ചെയ്യാവുന്ന ഒരു ദീർഘകാല കോഡാണ്.
• ആഗോള നില ഒരു ഹാഷ് ടേബിളായി ക്രമീകരിച്ചിരിക്കുന്നു, ഇവിടെ കീ അക്കൗണ്ട് വിലാസമാണ്
• അക്കൗണ്ടുകളിൽ നൽകിയിരിക്കുന്ന തരത്തിലുള്ള ഒന്നിൽ കൂടുതൽ റിസോഴ്‌സ് മൂല്യവും നൽകിയിരിക്കുന്ന പേരുള്ള ഒന്നിൽ കൂടുതൽ മൊഡ്യൂളുകളും അടങ്ങിയിരിക്കരുത് (അക്കൗണ്ടിൽ 0x0 ഒരു അധിക ഉറവിടം ഉൾക്കൊള്ളാൻ കഴിയില്ല 0x0.Currency.Coin അല്ലെങ്കിൽ പേരുള്ള മറ്റൊരു മൊഡ്യൂൾ കറൻസി)
• പ്രഖ്യാപിത മൊഡ്യൂളിന്റെ വിലാസം തരത്തിന്റെ ഭാഗമാണ് (0x0.Currency.Coin и 0x1.Currency.Coin പരസ്പരം ഉപയോഗിക്കാനാവാത്ത പ്രത്യേക തരങ്ങളാണ്)
• പ്രോഗ്രാമർമാർക്ക് അവരുടെ ഇഷ്‌ടാനുസൃത ഉറവിടം നിർവചിച്ച് ഒരു അക്കൗണ്ടിൽ ഇത്തരത്തിലുള്ള റിസോഴ്‌സിന്റെ ഒന്നിലധികം സംഭവങ്ങൾ സംഭരിക്കാനാകും - (റിസോഴ്സ് TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
• പൊരുത്തക്കേടുകളില്ലാതെ നിങ്ങൾക്ക് ഒരു ഉറവിടത്തെ അതിന്റെ പേരിൽ റഫർ ചെയ്യാൻ കഴിയും, ഉദാഹരണത്തിന് നിങ്ങൾക്ക് രണ്ട് ഉറവിടങ്ങൾ ഉപയോഗിച്ച് റഫർ ചെയ്യാം TwoCoins.c1 и TwoCoins.c2.

നാണയ വിഭവ പ്രഖ്യാപനം

മൊഡ്യൂളിന് പേരിട്ടു കറൻസി പേരുള്ള ഒരു റിസോഴ്സ് തരവും നാണയം

നെകൊട്ടറി നിമിഷങ്ങൾ:

• നാണയം തരം ഒരു ഫീൽഡ് ഉള്ള ഒരു ഘടനയാണ് u64 (64-ബിറ്റ് ഒപ്പിടാത്ത പൂർണ്ണസംഖ്യ)
• മൊഡ്യൂൾ നടപടിക്രമങ്ങൾ മാത്രം കറൻസി തരം മൂല്യങ്ങൾ സൃഷ്ടിക്കാനോ നശിപ്പിക്കാനോ കഴിയും നാണയം.
• മൊഡ്യൂൾ നൽകുന്ന പൊതു നടപടിക്രമങ്ങളിലൂടെ മാത്രമേ മറ്റ് മൊഡ്യൂളുകൾക്കും സ്ക്രിപ്റ്റുകൾക്കും മൂല്യ ഫീൽഡ് എഴുതാനോ പരാമർശിക്കാനോ കഴിയൂ.

നിക്ഷേപത്തിന്റെ വിൽപ്പന

ഈ നടപടിക്രമം ഒരു റിസോഴ്സ് സ്വീകരിക്കുന്നു നാണയം ഇൻപുട്ട് ആയി അതിനെ റിസോഴ്സുമായി സംയോജിപ്പിക്കുന്നു നാണയംസ്വീകർത്താവിന്റെ അക്കൗണ്ടിൽ സൂക്ഷിച്ചിരിക്കുന്നു:

1. ഇൻപുട്ട് റിസോഴ്സ് കോയിൻ നശിപ്പിക്കുകയും അതിന്റെ മൂല്യം രേഖപ്പെടുത്തുകയും ചെയ്യുന്നു.
2. സ്വീകർത്താവിന്റെ അക്കൗണ്ടിൽ സംഭരിച്ചിരിക്കുന്ന ഒരു അദ്വിതീയ കോയിൻ റിസോഴ്സിലേക്കുള്ള ലിങ്ക് സ്വീകരിക്കുന്നു.
3. നടപടിക്രമം വിളിക്കുമ്പോൾ പാരാമീറ്ററിൽ പാസാക്കിയ മൂല്യം കൊണ്ട് നാണയങ്ങളുടെ എണ്ണത്തിന്റെ മൂല്യം മാറ്റുന്നു.

നെകൊട്ടറി നിമിഷങ്ങൾ:

• അൺപാക്ക്, BorrowGlobal - അന്തർനിർമ്മിത നടപടിക്രമങ്ങൾ
• അൺപാക്ക് ചെയ്യുക T ടൈപ്പ് റിസോഴ്‌സ് ഇല്ലാതാക്കാനുള്ള ഒരേയൊരു മാർഗ്ഗമാണിത്. നടപടിക്രമം ഒരു റിസോഴ്‌സ് ഇൻപുട്ടായി എടുക്കുകയും അത് നശിപ്പിക്കുകയും റിസോഴ്‌സിന്റെ ഫീൽഡുകളുമായി ബന്ധപ്പെട്ട മൂല്യം നൽകുകയും ചെയ്യുന്നു.
• കടം ഗ്ലോബൽ ഒരു വിലാസം ഇൻപുട്ടായി എടുക്കുകയും ആ വിലാസം പ്രസിദ്ധീകരിച്ച (ഉടമസ്ഥതയിലുള്ള) T യുടെ ഒരു അദ്വിതീയ ഉദാഹരണത്തിലേക്ക് ഒരു റഫറൻസ് നൽകുകയും ചെയ്യുന്നു
• &മുട്ട് കോയിൻ ഇത് ഉറവിടത്തിലേക്കുള്ള ഒരു ലിങ്കാണ് നാണയം

withdraw_from_sender നടപ്പിലാക്കൽ

ഈ നടപടിക്രമം:

1. ഒരു അദ്വിതീയ ഉറവിടത്തിലേക്കുള്ള ഒരു ലിങ്ക് ലഭിക്കുന്നു നാണയം, അയച്ചയാളുടെ അക്കൗണ്ടുമായി ലിങ്ക് ചെയ്‌തു
2. ഒരു വിഭവത്തിന്റെ മൂല്യം കുറയ്ക്കുന്നു നാണയം നിർദ്ദിഷ്ട തുകയ്ക്കുള്ള ലിങ്ക് വഴി
3. ഒരു പുതിയ ഉറവിടം സൃഷ്ടിക്കുകയും തിരികെ നൽകുകയും ചെയ്യുന്നു നാണയം പുതുക്കിയ ബാലൻസിനൊപ്പം.

നെകൊട്ടറി നിമിഷങ്ങൾ:

• നിക്ഷേപം ആർക്കും കാരണമാകാം, പക്ഷേ പിൻവലിക്കുക_ അയച്ചയാളിൽ നിന്ന് കോളിംഗ് അക്കൗണ്ടിന്റെ നാണയങ്ങളിലേക്ക് മാത്രമേ പ്രവേശനമുള്ളൂ
• GetTxnSenderAdress സമാനമായ msg.sender സോളിഡിറ്റിയിൽ
• നിരസിക്കുക അല്ലാതെ സമാനമായ ആവശ്യമുണ്ട് സോളിഡിറ്റിയിൽ. ഈ പരിശോധന പരാജയപ്പെടുകയാണെങ്കിൽ, ഇടപാട് നിർത്തുകയും എല്ലാ മാറ്റങ്ങളും പിൻവലിക്കുകയും ചെയ്യും.
• പാക്ക് ടൈപ്പ് ടിയുടെ ഒരു പുതിയ റിസോഴ്‌സ് സൃഷ്ടിക്കുന്ന ഒരു ബിൽറ്റ്-ഇൻ നടപടിക്രമം കൂടിയാണിത്.
• കൂടാതെ അൺപാക്ക് ചെയ്യുക, പാക്ക് ഉറവിടം വിവരിച്ചിരിക്കുന്ന മൊഡ്യൂളിനുള്ളിൽ മാത്രമേ വിളിക്കാൻ കഴിയൂ T

തീരുമാനം

മൂവ് ഭാഷയുടെ പ്രധാന സവിശേഷതകൾ ഞങ്ങൾ പരിശോധിച്ചു, അതിനെ Ethereum-മായി താരതമ്യം ചെയ്തു, കൂടാതെ സ്ക്രിപ്റ്റുകളുടെ അടിസ്ഥാന വാക്യഘടനയും ഞങ്ങൾ പരിചിതമായി. അവസാനമായി, പരിശോധിക്കാൻ ഞാൻ വളരെ ശുപാർശ ചെയ്യുന്നു യഥാർത്ഥ വെള്ള പേപ്പർ. പ്രോഗ്രാമിംഗ് ലാംഗ്വേജ് ഡിസൈൻ തത്വങ്ങളെക്കുറിച്ചുള്ള ധാരാളം വിശദാംശങ്ങളും ഉപയോഗപ്രദമായ നിരവധി ലിങ്കുകളും ഇതിൽ ഉൾപ്പെടുന്നു.

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