Folgjende sille wy yn detail de haadkenmerken fan 'e Move -taal beskôgje en wat binne de wichtichste ferskillen mei in oare, al populêre taal foar tûke kontrakten - Solidity (op it Ethereum -platfoarm). It materiaal is basearre op in stúdzje fan 'e beskikbere online 26-pagina whitepaper.
Ynlieding
Move is in útfierbere bytecode-taal dy't brûkt wurdt om brûkerstransaksjes en tûke kontrakten út te fieren. Tink derom twa punten:
- Wylst Move in bytecodetaal is dy't direkt kin wurde útfierd op 'e Move-firtuele masine, is Solidity (Ethereum's smart contract language) in taal op heger nivo dy't earst wurdt gearstald nei bytecode foardat se wurdt útfierd op in EVM (Ethereum Virtual Machine).
- Move kin wurde brûkt net allinich foar it útfieren fan tûke kontrakten, mar ek foar oanpaste transaksjes (mear hjiroer letter), wylst Solidity in tûke is foar allinich kontrakt.
De oersetting waard útfierd troch it projektteam INDEX Protocol. Wy hawwe al oerset , no is it tiid om de Move-taal wat mear yn detail te besjen. De oersetting is yn gearwurking mei Habrauser útfierd
In wichtich skaaimerk fan Move is de mooglikheid om oanpaste boarnetypen te definiearjen mei semantyk basearre op lineêre logika: in boarne kin nea kopieare of ymplisyt wiske wurde, allinich ferpleatst wurde. Funksjoneel is dit gelyk oan de mooglikheden fan 'e Rust-taal. Wearden yn Rust kinne allinich oan ien namme tagelyk wurde tawiisd. It tawizen fan in wearde oan in oare namme makket it net beskikber ûnder de foarige namme.
Bygelyks, it folgjende koadefragment smyt in flater: Gebrûk fan ferpleatste wearde 'x'. Dit komt om't d'r gjin jiskefetkolleksje is yn Rust. As fariabelen bûten it berik geane, wurdt it ûnthâld wêr't se nei ferwize ek frijmakke. Simply sette, d'r kin mar ien "eigner" fan 'e gegevens wêze. Yn dit foarbyld x is de oarspronklike eigner en dan y wurdt de nije eigner. .
Fertsjintwurdiging fan digitale aktiva yn iepen systemen
D'r binne twa eigenskippen fan fysike aktiva dy't dreech binne digitaal foar te stellen:
- Seldsumens (Skaarste, oarspronklik tekoart). It oantal aktiva (útstjit) yn it systeem moat wurde kontroleare. Duplikaasje fan besteande besittings moat wurde ferbean, en it meitsjen fan nije is in befoarrjochte operaasje.
- Tagongskontrôle... De systeemdielnimmer moat aktiva kinne beskermje mei tagongsbehearbelied.
Dizze twa skaaimerken, dy't natuerlik binne foar fysike aktiva, moatte wurde ymplementeare foar digitale objekten as wy se as aktiva wolle beskôgje. Bygelyks, in seldsum metaal hat in natuerlike tekoart, en allinich jo hawwe tagong ta it (hâld it bygelyks yn jo hannen) en jo kinne it ferkeapje of útjaan.
Om te yllustrearjen hoe't wy by dizze twa eigenskippen kamen, litte wy begjinne mei de folgjende sinnen:
Suggestje # 1: De ienfâldichste regel sûnder krapte en tagongskontrôle
- G [K]: = n jout in update oan foar in nûmer dat tagonklik is mei in kaai К yn 'e wrâldwide steat fan' e blockchain, mei in nije betsjutting n.
- transaksje lAlice, 100⟩ betsjuttet it akkountsaldo fan Alice op 100 te setten.
De boppesteande oplossing hat ferskate grutte problemen:
- Alice kin in unbeheind oantal munten ûntfange troch gewoan te ferstjoeren transaksje lAlice, 100⟩.
- De munten dy't Alice nei Bob stjoert binne nutteloos, om't Bob himsels in unbeheind oantal munten koe stjoere mei deselde technyk.
Suggestje # 2: Rekken hâldend mei it tekoart
No kontrolearje wy de situaasje sadat it oantal munten Ka wie teminsten gelyk n foar de oerdracht transaksje. Hoewol dit dit it probleem fan skaarste oplost, is d'r gjin ynformaasje oer wa't de munten fan Alice kin stjoere (foar no kin elkenien dit dwaan, it wichtichste is net de regel te brekken om it bedrach te beheinen).
Foarstel # 3: Kombinearjen fan krapte en tagongskontrôle
Wy lossen dit probleem op mei in meganisme foar digitale hântekening ferifiearje_sig foar it kontrolearjen fan it saldo, wat betsjuttet dat Alice har privee kaai brûkt om de transaksje te tekenjen en befêstiget dat se de eigner is fan har munten.
Blockchain programmeertalen
De besteande blockchain -talen stean foar de folgjende problemen (allegear waarden oplost yn Move (opmerking: spitigernôch docht de auteur fan it artikel allinich in berop op Ethereum yn syn fergelikingen, dus it is it wurdich se allinich yn dizze kontekst te nimmen. Bygelyks, it measte fan 'e folgjende is ek oplost yn EOS.))):
Yndirekte fertsjintwurdiging fan aktiva. In asset wurdt kodearre mei in hiel getal, mar in hiel getal is net itselde as in asset. Yn feite is d'r gjin type of wearde dy't Bitcoin / Ether / <Elke munt> fertsjintwurdiget! Dit makket it skriuwen fan programma's dy't aktiva brûke lestich en flaterberich. Patroanen lykas it trochjaan fan fermogen nei/fan prosedueres of it opslaan fan fermogen yn struktueren fereaskje spesjale stipe fan 'e taal.
It tekoart is net útwreidber... Taal fertsjintwurdiget mar ien krappe oanwinst. Derneist wurde de remedies tsjin skaarste direkt yn 'e semantyk fan' e taal sels ferbûn. De ûntwikkelder, as hy in oanpaste aktiva wol oanmeitsje, moat alle aspekten fan 'e boarne sels foarsichtich kontrolearje. Dit binne krekt de problemen fan tûke kontrakten fan Ethereum.
Brûkers jouwe har fermogen, ERC-20-tokens út, mei heule getallen om sawol de wearde as it totale oanbod te bepalen. Wannear't nije tokens wurde oanmakke, moat de tûke kontraktkoade ûnôfhinklik neilibjen fan 'e útstjitregels ferifiearje. Derneist liedt de yndirekte presintaasje fan aktiva, yn guon gefallen, ta serieuze flaters - duplikaasje, dûbele útjeften as sels folslein ferlies fan aktiva.
Tekoart oan fleksibele tagongskontrôle... It ienige tagongskontrolebelied dat hjoed wurdt brûkt is in hantekeningsskema mei asymmetryske kryptografy. Lykas beskerming tsjin skaarste, binne belied foar tagongskontrôle djip ynbêde yn 'e semantyk fan' e taal. Mar hoe de taal út te wreidzjen sadat programmeurs har eigen belied foar tagongskontrôle kinne definiearje, is faaks in heul lestige taak.
Dit is ek wier op Ethereum, wêr't tûke kontrakten gjin native kryptografyske stipe hawwe foar tagongskontrôle. Untwikkelders moatte tagongskontrôle manuell ynstelle, bygelyks mei de onlyOwner-modifier.
Ek al bin ik in grutte fan fan Ethereum, ik leau dat asset eigenskippen natuerlik moatte wurde stipe troch de taal foar feiligens doelen. Benammen it oerdragen fan Ether nei in tûk kontrakt omfettet dynamyske ferstjoering, dy't in nije klasse fan bugs hat yntrodusearre bekend as kwetsberens foar opnij ynfier. Dynamyske ferstjoering betsjut hjir dat de útfieringslogika fan 'e koade sil wurde bepaald op runtime (dynamysk) ynstee fan op kompilaasjetiid (statysk).
Dus, yn Solidity, as kontrakt A in funksje yn kontrakt B neamt, kin kontrakt B koade útfiere dy't net bedoeld wie troch de ûntwikkelder fan kontrakt A, wat kin resultearje yn (kontrakt A fungearret by ûngelok as kontrakt B om jild werom te lûken foardat de akkountsaldo's feitlik ynlutsen wurde).
Move Language Design Fundamentals
Boarnen fan earste oarder
Op in heech nivo is de ynteraksje tusken modules / boarnen / prosedueres yn 'e Move -taal heul gelyk oan' e relaasje tusken klassen / objekten en metoaden yn OOP -talen.
Ferpleatsmodules binne gelyk oan tûke kontrakten yn oare blokken. De module ferklearret boarnetypen en prosedueres dy't de regels definiearje foar it meitsjen, ferneatigjen en bywurkjen fan ferklearre boarnen. Mar dit alles binne gewoan konvinsjes ("jargon") Yn beweging. Wy sille dit punt in bytsje letter yllustrearje.
Fleksibiliteit
Move foeget fleksibiliteit ta oan Libra troch skripting. Elke transaksje yn Libra omfettet in skript, dat is yn wêzen de kearnproseduere fan 'e transaksje. It skript kin ien spesifisearre aksje útfiere, bygelyks betellingen oan in spesifisearre list fan ûntfangers, of oare boarnen opnij brûke - bygelyks troch in proseduere oan te roppen wêryn de algemiene logika is oantsjutte. Dit is wêrom Move transaksje skripts biede gruttere fleksibiliteit. In skript kin sawol ien kear as werheljende gedrach brûke, wylst Ethereum allinich werhellbere skripts kin útfiere (ien metoade oproppe op in tûk kontraktmetoade). De reden dat it "werbrûkber" wurdt neamd, is om't de funksjes fan in tûk kontrakt meardere kearen kinne wurde útfierd. (noat: It punt hjir is heul subtyl. Oan 'e iene kant besteane transaksjeskripts yn' e foarm fan pseudo-bytekoade ek yn Bitcoin. Oan 'e oare kant, sa't ik it begryp, wreidet Move dizze taal út, trouwens, nei it nivo fan in folsleine tûke kontrakttaal).
Feiligens
It útfierbere formaat fan Move is bytecode, dat oan 'e iene kant in taal op heger nivo is dan assemblagetaal, mar leger nivo as boarnekoade. De bytekoade wurdt kontrolearre yn run-time (on-chain) foar middels, typen en ûnthâld feilichheid mei help fan in bytecode verifier, en dan útfierd troch de tolk. Dizze oanpak lit Move de feiligens fan boarnekoade leverje, mar sûnder it kompilaasjeproses en de needsaak om in kompilator ta te foegjen oan it systeem. It meitsjen fan Move in bytecode-taal is in echt goede oplossing. It hoecht net te kompilearjen fan 'e boarne, lykas it gefal is mei Solidity, en d'r is gjin need om soargen te meitsjen oer mooglike mislearrings of oanfallen op' e kompilerynfrastruktuer.
Ferifiearberens
Wy binne rjochte op it útfieren fan kontrôles sa maklik mooglik, om't dit alles wurdt dien on-chain (note: online, tidens de útfiering fan elke transaksje, sadat elke fertraging liedt ta in fertraging fan it heule netwurk), lykwols, yn earste ynstânsje is it taalûntwerp klear om statyske ferifikaasje-ark foar off-chain te brûken. Hoewol dit mear de foarkar is, is de ûntwikkeling fan ferifikaasje-ark (as in aparte toolkit) no útsteld nei de takomst, en no wurdt allinich dynamyske ferifikaasje yn run-time (on-chain) stipe.
Modulariteit
Ferpleatsmodules leverje gegevensabstraksje en lokalisearje krityske operaasjes op boarnen. De ynkapseling levere troch de module, kombineare mei de beskerming levere troch it systeem fan Move -type, soarget derfoar dat eigenskippen ynsteld op 'e types fan' e module net kinne wurde skeind troch koade bûten de module. Dit is in frij goed betocht abstraksje-ûntwerp, wat betsjuttet dat gegevens binnen in kontrakt allinich kinne feroarje binnen it berik fan it kontrakt, mar net ekstern.
Oersjoch ferpleatse
It foarbyld fan it transaksjeskript bewiist dat kweade as ûngeduldige aksjes troch in programmeur bûten in module de feiligens fan 'e boarnen fan in module net kinne kompromittearje. Folgjende sille wy foarbylden besjen oer hoe't modules, boarnen en prosedueres wurde brûkt foar it programmearjen fan 'e Libra -blockchain.
Peer-to-Peer betellingen
It oantal munten oantsjutte yn bedrach wurdt oerdroegen fan de stjoerder syn lykwicht oan de ûntfanger.
D'r binne hjir in pear nije dingen (yn read markearre):
- 0x0: adres fan it akkount wêr't de module wurdt opslein
- Muntsoarte: module namme
- Munt: boarnetype
- De muntwearde weromjûn troch de proseduere is in boarnewearde fan type 0x0.Currency.Coin
- ferhúzje (): wearde kin net wer brûkt wurde
- kopiearje (): wearde kin letter brûkt wurde
Parse de koade: yn 'e earste stap ropt de stjoerder in proseduere neamd weromlûke_fan_stjoerder fan in module opslein yn 0x0.Jild. Yn 'e twadde stap draacht de stjoerder jild oer nei de ûntfanger troch de muntboarnewearde te ferpleatsen yn' e boarchproseduere fan 'e module 0x0.Jild.
Hjir binne trije foarbylden fan flaters yn koade dy't sille wurde ôfwiisd troch kontrôles:
Dûbelje fûnsen troch de oprop te feroarjen bewegen (munt) op kopy (munt). Middels kinne allinnich wurde ferpleatst. Besykje in kwantiteit fan in boarne te duplisearje (bygelyks troch te skiljen kopy (munt) yn it foarbyld hjirboppe) sil resultearje yn in flater by it kontrolearjen fan de bytecode.
Gebrûk fan fûnsen troch te spesifisearjen bewegen (munt) twaris . In line tafoegje 0x0.Currency.deposit (kopy (some_other_payee), ferpleatse (munt)) bygelyks, it boppesteande sil tastean de stjoerder te "útjaan" de munten twa kear - de earste kear mei de beteler, en de twadde mei some_other_payee. Dit is in net winske gedrach dat net mooglik is mei in fysike asset. Lokkich sil Move dit programma ôfwize.
Ferlies fan fûnsen troch wegering bewegen (munt). As jo de boarne net ferpleatse (bygelyks troch de rigel te wiskjen mei bewegen (munt)), sil in bytecode-ferifikaasjeflater wurde smiten. Dit beskermet Move-programmeurs fan tafallich of kwea-aardich ferlies fan fûnsen.
Faluta module
Elk akkount kin 0 of mear modules befetsje (oanjûn as rjochthoeken) en ien of mear boarnewearden (oanjûn as silinders). Bygelyks, in akkount by 0x0 befettet module 0x0.Jild en de wearde fan it type boarne 0x0.Currency.Coin. Account op adres 0x1 hat twa middels en ien module; Account op adres 0x2 hat twa modules en ien boarne wearde.
Nekotory mominten:
- It transaksjeskript is atoom - of it wurdt folslein útfierd of hielendal net.
- In module is in lang libben stik koade dat is globaal tagonklik.
- De globale steat is strukturearre as in hash-tabel, wêrby't de kaai it akkountadres is
- Accounts kinne net mear as ien boarnewearde fan in opjûn type befetsje en net mear as ien module mei in opjûne namme (account by 0x0 kin gjin ekstra boarne befetsje 0x0.Currency.Coin of in oare module neamd Muntsoarte)
- It adres fan de ferklearre module is diel fan it type (0x0.Currency.Coin и 0x1.Currency.Coin binne aparte soarten dy't net trochinoar kinne wurde brûkt)
- Programmeurs kinne meardere eksimplaren fan dit type boarne opslaan yn in akkount troch har oanpaste boarne te definiearjen - (boarne TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Jo kinne ferwize nei in boarne troch syn namme sûnder konflikten, bygelyks kinne jo ferwize nei twa boarnen mei help TwoCoins.c1 и TwoCoins.c2.
Coin boarne oankundiging
Module neamd Muntsoarte en in boarne type neamd Munt
Nekotory mominten:
- Munt is in struktuer mei ien fjild fan type u64 (64-bit net ûndertekene hiel getal)
- Allinnich moduleprosedueres Muntsoarte kinne wearden fan type oanmeitsje of ferneatigje Munt.
- Oare modules en skripts kinne allinich it weardefjild skriuwe of ferwize fia iepenbiere prosedueres dy't troch de module oanbean wurde.
Ferkeap fan boarchsom
Dizze proseduere akseptearret in boarne Munt as ynput en kombinearret it mei de boarne Muntopslein yn it akkount fan de ûntfanger:
- It ferneatigjen fan de ynfier boarne Coin en it opnimmen fan syn wearde.
- Untfang in keppeling nei in unike Coin boarne opslein yn de ûntfanger syn account.
- It feroarjen fan de wearde fan it oantal Munten troch de wearde trochjûn yn de parameter by it oproppen fan de proseduere.
Nekotory mominten:
- Útpakke, BorrowGlobal - ynboude prosedueres
- Útpakke Dit is de ienige manier om te wiskjen in boarne fan type T. De proseduere nimt in boarne as ynfier, ferneatiget it, en jout de wearde ferbûn mei de boarne syn fjilden.
- BorrowGlobal nimt in adres as ynfier en jout in ferwizing nei in unike eksimplaar fan T publisearre (eigendom) troch dat adres
- &mut Munt dit is in keppeling nei de boarne Munt
Útfiering fan withdraw_from_sender
Dizze proseduere:
- Kriget in keppeling nei in unike boarne Munt, keppele oan it akkount fan de stjoerder
- Ferleget de wearde fan in boarne Munt fia de keppeling foar it oantsjutte bedrach
- Makket en jout in nije boarne werom Munt mei bywurke lykwicht.
Nekotory mominten:
- boarchsom kin wurde feroarsake troch eltsenien, mar weromlûke_fan_stjoerder hat allinnich tagong ta de munten fan de oprop account
- GetTxnSenderAddress gelyk oan msg.ferstjoerder yn Solidity
- RejectUnless gelyk oan fereaskje yn Solidity. As dizze kontrôle mislearret, wurdt de transaksje stoppe en wurde alle wizigingen weromdraaid.
- Pakke it is ek in ynboude proseduere dy't in nije boarne fan type T makket.
- Lykas Útpakke, Pakke kin allinnich neamd wurde binnen de module dêr't de boarne wurdt beskreaun T
konklúzje
Wy ûndersocht de wichtichste skaaimerken fan 'e Move-taal, fergelike it mei Ethereum, en waard ek bekend mei de basissyntaksis fan skripts. Uteinlik ried ik tige oan om te kontrolearjen . It omfettet in protte detail oangeande prinsipes foar ûntwerp fan programmeartaal, lykas ek in protte nuttige keppelings.
Boarne: www.habr.com