Poste ni konsideros detale la ĉefajn karakterizaĵojn de la lingvo Move kaj kiaj estas ĝiaj ĉefaj diferencoj kun alia, jam populara lingvo por inteligentaj kontraktoj - Solideco (sur la platformo Ethereum). La materialo baziĝas sur studo de la disponebla interreta 26-paĝa blanka libro.
Enkonduko
Move estas plenumebla bajtkoda lingvo, kiu estas uzata por plenumi uzanttransakciojn kaj inteligentajn kontraktojn. Bonvolu noti du punktojn:
- Dum Move estas bajta koda lingvo, kiu povas esti rekte efektivigita per la virtuala maŝino Move, Solideco (la inteligenta kontrakta lingvo de Ethereum) estas pli altnivela lingvo, kiu unue estas kompilita al bajta kodo antaŭ ol esti ekzekutita sur EVM (Ethereum Virtual Machine).
- Move povas esti uzata ne nur por efektivigi inteligentajn kontraktojn, sed ankaŭ por laŭmendaj transakcioj (pli pri tio poste), dum Solideco estas inteligenta nur kontrakta lingvo.
La traduko estis farita de la projektteamo INDEX Protocol. Ni jam tradukis , nun estas tempo rigardi la Move-lingvon iom pli detale. La traduko estis farita kune kun Habrauser
Ĉefa trajto de Move estas la kapablo difini specialadaptitajn rimedspecojn kun semantiko bazita sur lineara logiko: rimedo neniam povas esti kopiita aŭ implicite forigita, nur movita. Funkcie, tio similas al la kapabloj de la Rust-lingvo. Valoroj en Rust povas esti asignitaj nur al unu nomo samtempe. Asigni valoron al malsama nomo faras ĝin neatingebla sub la antaŭa nomo.
Ekzemple, la sekva kodpeceto ĵetos eraron: Uzo de movita valoro 'x'. Ĉi tio estas ĉar ne ekzistas rubkolekto en Rust. Kiam variabloj eliras el amplekso, la memoro al kiu ili aludas estas liberigita ankaŭ. Simple dirite, povas esti nur unu "posedanto" de la datumoj. En ĉi tiu ekzemplo x estas la origina posedanto kaj tiam y iĝas la nova posedanto. .
Reprezento de ciferecaj aktivoj en malfermaj sistemoj
Estas du ecoj de fizikaj aktivaĵoj malfacile ciferece reprezenti:
- Malofteco (Malabundeco, originale malabundeco). La nombro de aktivoj (emisio) en la sistemo devas esti kontrolita. Duobligo de ekzistantaj aktivaĵoj devas esti malpermesita, kaj krei novajn estas privilegia operacio.
- Alirkontrolo... La partoprenanto de la sistemo devas povi protekti aktivaĵojn per alirkontrolaj politikoj.
Ĉi tiuj du karakterizaĵoj, naturaj por fizikaj aktivaĵoj, devas esti efektivigitaj por ciferecaj objektoj, se ni volas konsideri ilin kiel aktivaĵojn. Ekzemple, rara metalo havas naturan malabundecon, kaj nur vi havas aliron al ĝi (tenante ĝin en viaj manoj, ekzemple) kaj vi povas vendi aŭ elspezi ĝin.
Por ilustri kiel ni alvenis al ĉi tiuj du propraĵoj, ni komencu per la jenaj frazoj:
Sugesto # 1: La Plej Simpla Regulo Sen Malabundeco kaj Alirkontrolo
- G [K]: = n indikas ĝisdatigon de nombro atingebla per ŝlosilo К en la tutmonda stato de la blokĉeno, kun nova signifo n.
- transakcio lAlice, 100⟩ signifas agordi la konton de Alice en 100.
La supra solvo havas plurajn gravajn problemojn:
- Alico povas ricevi senliman nombron da moneroj per simple sendado transakcio lAlice, 100⟩.
- La moneroj, kiujn Alico sendas al Bob, estas senutilaj, ĉar Bob povus sendi al si senliman nombron da moneroj per la sama tekniko.
Sugesto n-ro 2: Konsiderante la deficiton
Nun ni kontrolas la situacion tiel ke la nombro da moneroj Ka estis almenaŭ egala n antaŭ la transiga transakcio. Tamen, dum tio solvas la problemon de malabundeco, ekzistas neniuj informoj pri kiu povas sendi la monerojn de Alicio (nuntempe iu ajn povas fari tion, la ĉefa afero estas ne malobservi la regulon limigi la sumon).
Propono # 3: Kombini malabundecon kaj alirkontrolon
Ni solvas ĉi tiun problemon per cifereca subskriba mekanismo kontroli_sig antaŭ ol kontroli la ekvilibron, kio signifas, ke Alice uzas sian privatan ŝlosilon por subskribi la transakcion kaj konfirmi, ke ŝi estas la posedanto de siaj moneroj.
Programlingvoj pri blokĉenoj
La ekzistantaj blokĉenaj lingvoj alfrontas la jenajn problemojn (ĉiuj estis solvitaj en Move (notu: bedaŭrinde, la aŭtoro de la artikolo nur apelacias al Ethereum en siaj komparoj, do indas preni ilin nur ĉi-kuntekste. Ekzemple, plej multaj el la sekvaj estas solvitaj ankaŭ en EOS.)):
Nerekta reprezentado de aktivaĵoj. Valoraĵo estas kodita uzante entjeron, sed entjero ne samas kiel valoraĵo. Fakte, ne ekzistas tipo aŭ valoro reprezentanta Bitcoin/Ether/<Any Coin>! Ĉi tio igas skribi programojn, kiuj uzas aktivaĵojn, malfacilaj kaj eraraj. Ŝablonoj kiel transdono de valoraĵoj al/de proceduroj aŭ stokado de valoraĵoj en strukturoj postulas specialan subtenon de la lingvo.
La deficito ne estas pligrandigebla... Lingvo reprezentas nur unu malabundan havaĵon. Krome la rimedoj kontraŭ malabundeco estas ligitaj rekte al la semantiko de la lingvo mem. La programisto, se li volas krei laŭmendan aktivaĵon, devas zorge kontroli ĉiujn aspektojn de la rimedo mem. Ĉi tiuj estas ĝuste la problemoj de inteligentaj kontraktoj de Ethereum.
Uzantoj eldonas siajn havaĵojn, ERC-20-ĵetonojn, uzante entjerojn por determini kaj la valoron kaj la totalan provizon. Kiam ajn novaj tokensoj estas kreitaj, la inteligenta kontrakta kodo devas sendepende kontroli plenumadon de la reguloj pri emisioj. Krome nerekta prezento de aktivaĵoj kondukas, en iuj kazoj, al gravaj eraroj - multobligo, duobla elspezado aŭ eĉ kompleta perdo de aktivaĵoj.
Manko de fleksebla alira kontrolo... La sola nura alirkontrola politiko uzata hodiaŭ estas subskriba skemo uzanta nesimetrian kriptografion. Kiel malabunda protekto, alirkontrolaj politikoj estas profunde enigitaj en la semantikon de la lingvo. Sed kiel etendi la lingvon por permesi al programistoj difini siajn proprajn alirkontrolajn politikojn estas ofte tre malfacila tasko.
Ĉi tio ankaŭ validas ĉe Ethereum, kie inteligentaj kontraktoj ne havas denaskan kriptografian subtenon por alirkontrolo. Programistoj devas mane agordi alirkontrolon, ekzemple, uzante la modifilon de onlyOwner.
Kvankam mi estas granda ŝatanto de Ethereum, mi kredas, ke valoraĵaj propraĵoj devus esti denaske subtenataj de la lingvo por sekurecaj celoj. Precipe, translokigi Eteron al inteligenta kontrakto implikas dinamikan sendon, kiu enkondukis novan klason de cimoj konataj kiel reeniraj vundeblecoj. Dinamika sendo ĉi tie signifas, ke la ekzekutlogiko de la kodo estos determinita ĉe rultempo (dinamika) prefere ol je kompiltempo (senmova).
Tiel, en Solideco, kiam kontrakto A nomas funkcion en kontrakto B, kontrakto B povas ruli kodon kiu ne estis celita fare de la ellaboranto de kontrakto A, kiu povas rezultigi (kontrakto A hazarde agas kiel kontrakto B por eltiri monon antaŭ ol la konto-saloj estas efektive subtrahataj).
Move Lingvo-Dezajno Fundamentoj
Unuarangaj rimedoj
Je alta nivelo, la interago inter moduloj / rimedoj / proceduroj en la lingvo Move estas tre simila al la rilato inter klasoj / objektoj kaj metodoj en OOP-lingvoj.
Movaj moduloj similas al inteligentaj kontraktoj en aliaj blokĉenoj. La modulo deklaras rimedajn specojn kaj procedurojn, kiuj difinas la regulojn por krei, detrui kaj ĝisdatigi deklaritajn rimedojn. Sed ĉio ĉi estas nur konvencioj ("ĵargono”) En Movu. Ni ilustros ĉi tiun punkton iom poste.
Fleksebleco
Move aldonas flekseblecon al Libra per skripto. Ĉiu transakcio en Pesilo inkluzivas skripton, kiu estas esence la kerna proceduro de la transakcio. La skripto povas plenumi aŭ unu specifitan agon, ekzemple, pagojn al specifita listo de ricevantoj, aŭ reuzi aliajn rimedojn - ekzemple, vokante proceduron en kiu la ĝenerala logiko estas specifita. Jen kial Move-transakciaj skriptoj ofertas pli grandan flekseblecon. Skripto povas uzi ambaŭ unufojajn kaj ripetantajn kondutojn, dum Ethereum povas nur efektivigi ripeteblajn skriptojn (vokante unu metodon laŭ inteligenta kontrakto-metodo). La kialo, ke ĝi nomiĝas "reuzebla" estas ĉar la funkcioj de inteligenta kontrakto povas esti ekzekutitaj plurfoje. (noto: La punkto ĉi tie estas tre subtila. Unuflanke, transakciaj skriptoj en formo de pseŭdo-bajtokodo ankaŭ ekzistas en Bitcoin. Aliflanke, kiel mi komprenas ĝin, Move vastigas ĉi tiun lingvon, fakte, al la nivelo de plenrajta inteligenta kontraktolingvo.).
Sekureco
La rulebla formato de Move estas bajtkodo, kiu estas, unuflanke, pli alta nivela lingvo ol asembla lingvo, sed pli malalta ol fontkodo. La bajtkodo estas kontrolita en rultempo (sur-ĉeno) por resursoj, tipoj kaj memorsekureco uzante bajtkoda kontrolilon, kaj tiam efektivigita fare de la interpretisto. Ĉi tiu aliro permesas al Move disponigi la sekurecon de fontkodo, sed sen la kompilprocezo kaj la bezono aldoni kompililon al la sistemo. Fari Move bajtokodan lingvon estas vere bona solvo. Ĝi ne bezonas esti kompilita de fonto, kiel estas la kazo kun Solidity, kaj ne necesas zorgi pri eblaj fiaskoj aŭ atakoj sur la kompilila infrastrukturo.
Verfabileco
Ni celas fari kontrolojn kiel eble plej facile, ĉar ĉio ĉi estas farita ĉene (notu: interrete, dum la plenumado de ĉiu transakcio, do ia prokrasto kaŭzas malrapidiĝon de la tuta reto), tamen komence la lingvodezajno estas preta uzi eksterĉenajn senmovajn konfirmilojn. Kvankam tio estas pli preferinda, nuntempe la evoluo de konfirmiloj (kiel aparta ilaro) estis prokrastita por la estonteco, kaj nun nur dinamika kontrolado en rultempo (sur-ĉeno) estas subtenata.
Modulareco
Movi modulojn provizas datuman abstraktadon kaj lokalizas kritikajn operaciojn pri rimedoj. La enkapsuligo provizita de la modulo, kune kun la protekto provizita de la sistemo Move-tipo, certigas, ke ecoj starigitaj sur la tipoj de la modulo ne povas esti malobservitaj per kodo ekster la modulo. Ĉi tio estas sufiĉe bone pripensita abstrakta projekto, kio signifas, ke datumoj ene de kontrakto povas ŝanĝiĝi nur ene de la kontrakto, sed ne ekstere.
Movi superrigardon
La transakcia skripta ekzemplo montras, ke malicaj aŭ senzorgaj agoj de programisto ekster modulo ne povas kompromiti la sekurecon de rimedoj de modulo. Poste ni rigardos ekzemplojn pri kiel moduloj, rimedoj kaj proceduroj estas uzataj por programi la blokan ĉenon Libra.
Samrangaj pagoj
La nombro da moneroj specifita en kvanto estos transdonita de la saldo de la sendinto al la ricevanto.
Estas kelkaj novaj aferoj ĉi tie (emstarigitaj ruĝe):
- 0x0: adreso de la konto, kie la modulo estas konservita
- monero: modula nomo
- monero: rimedospeco
- La monero-valoro redonita de la procedo estas rimedo-valoro de tipo 0x0.Currency.Coin
- move (): valoro ne povas esti uzata denove
- kopii (): valoro povas esti uzata poste
Analizu la kodon: en la unua paŝo, la sendinto vokas procedon nomatan retiri_de_sendinto de modulo konservita en 0x0.Valuto. En la dua paŝo, la sendinto transdonas financon al la ricevanto movante la monerresursan valoron en la deponan proceduron de la modulo. 0x0.Valuto.
Jen tri ekzemploj de eraroj en kodo, kiuj estos malakceptitaj per ĉekoj:
Duplikati monon ŝanĝante la alvokon movi (monero) sur kopio (monero). Rimedoj nur povas esti movitaj. Provante duobligi kvanton de rimedo (ekzemple, per vokado kopio (monero) en la supra ekzemplo) rezultigos eraron dum kontrolo de la bajtokodo.
Reuzo de financoj per specifado movi (monero) dufoje . Aldonante linion 0x0.Currency.deposit (kopiu (iu_alia_paganto), movu (monero)) ekzemple, ĉi-supra permesos al la sendinto "elspezi" la monerojn dufoje - la unuan fojon kun la pagito, kaj la dua kun iu_alia_paganto. Ĉi tio estas nedezirinda konduto, kiu ne eblas kun fizika valoraĵo. Feliĉe, Move malakceptos ĉi tiun programon.
Perdo de financo pro rifuzo movi (monero). Se vi ne movas la rimedon (ekzemple, forigante la linion enhavantan movi (monero)), bajtokoda konfirmeraro estos ĵetita. Ĉi tio protektas Move-programistojn kontraŭ hazarda aŭ malica perdo de financo.
Valuta modulo
Ĉiu konto povas enhavi 0 aŭ pli da moduloj (montritaj kiel rektanguloj) kaj unu aŭ pluraj valoroj de rimedoj (montritaj kiel cilindroj). Ekzemple, konto ĉe 0x0 enhavas modulon 0x0.Valuto kaj la valoro de la rimeda tipo 0x0.Monero.Monero. Konto ĉe adreso 0x1 havas du rimedojn kaj unu modulon; Konto ĉe adreso 0x2 havas du modulojn kaj unu rimedan valoron.
Nekotory-momentoj:
- La transakcia skripto estas atoma - aŭ ĝi estas plenumita tute aŭ tute ne.
- Modulo estas longdaŭra peco de kodo, kiu estas tutmonde alirebla.
- La tutmonda ŝtato estas strukturita kiel hashtabelo, kie la ŝlosilo estas la kontadreso
- Kontoj povas enhavi ne pli ol unu rimedvaloron de difinita tipo kaj ne pli ol unu modulon kun persona nomo (konto ĉe 0x0 ne povas enhavi plian rimedon 0x0.Monero.Monero aŭ alia modulo nomita monero)
- La adreso de la deklarita modulo estas parto de la tipo (0x0.Monero.Monero и 0x1.Monero.Monero estas apartaj tipoj kiuj ne povas esti uzataj interŝanĝeble)
- Programistoj povas stoki plurajn okazojn de ĉi tiu speco de rimedo en konto difinante sian kutiman rimedon - (rimedo TwoCoins {c1: 0x0.Monero.Monero, c2: 0x0.Monero.Monero})
- Vi povas rilati al rimedo per ĝia nomo sen konfliktoj, ekzemple vi povas rilati al du rimedoj uzante DuMoneroj.c1 и DuMoneroj.c2.
Monera rimedo anonco
Modulo nomita monero kaj rimeda tipo nomita monero
Nekotory-momentoj:
- monero estas strukturo kun unu kampo de tipo u64 (64-bita sensigna entjero)
- Modulaj proceduroj nur monero povas krei aŭ detrui valorojn de tipo monero.
- Aliaj moduloj kaj skriptoj povas nur skribi aŭ referenci la valorkampon per publikaj proceduroj provizitaj de la modulo.
Vendo de deponejo
Ĉi tiu proceduro akceptas rimedon monero kiel enigaĵo kaj kombinas ĝin kun la rimedo monerokonservita en la konto de la ricevanto:
- Detruante la enigan rimedon Coin kaj registri ĝian valoron.
- Ricevante ligilon al unika Monero-rimedo konservita en la konto de la ricevanto.
- Ŝanĝi la valoron de la nombro da Moneroj per la valoro pasita en la parametro kiam oni vokas la proceduron.
Nekotory-momentoj:
- Malpaku, BorrowGlobal - enkonstruitaj proceduroj
- Malpaki Ĉi tio estas la nura maniero forigi rimedon de tipo T. La proceduro prenas rimedon kiel enigaĵon, detruas ĝin, kaj resendas la valoron asociitan kun la kampoj de la rimedo.
- BorrowGlobal prenas adreson kiel enigaĵon kaj resendas referencon al unika okazo de T publikigita (posedata) de tiu adreso
- &mut Monero ĉi tio estas ligilo al la rimedo monero
Efektivigo de withdraw_from_sender
Ĉi tiu proceduro:
- Akiras ligon al unika rimedo monero, ligita al la konto de la sendinto
- Malgrandigas la valoron de rimedo monero per la ligilo por la specifita kvanto
- Kreas kaj resendas novan rimedon monero kun ĝisdatigita bilanco.
Nekotory-momentoj:
- deponejo povas esti kaŭzita de iu ajn, sed retiri_de_sendinto nur havas aliron al la moneroj de la voka konto
- GetTxnSenderAddress simila al msg.sender en Solideco
- RejectKrom se simila al postulas en Solideco. Se ĉi tiu kontrolo malsukcesas, la transakcio estas ĉesigita kaj ĉiuj ŝanĝoj estas reigitaj.
- Paki ĝi ankaŭ estas enkonstruita proceduro kiu kreas novan rimedon de tipo T.
- Kaj ankaŭ Malpaki, Paki nur povas esti vokita ene de la modulo kie la rimedo estas priskribita T
konkludo
Ni ekzamenis la ĉefajn trajtojn de la lingvo Move, komparis ĝin kun Ethereum, kaj ankaŭ konatiĝis kun la baza sintakso de skriptoj. Fine, mi tre rekomendas kontroli . Ĝi inkluzivas multajn detalojn pri programlingvo-dezajnprincipoj, same kiel multajn utilajn ligilojn.
fonto: www.habr.com