A continuació, considerarem detalladament les principals característiques del llenguatge Move i quines són les seves diferències clau amb un altre llenguatge ja popular per als contractes intel·ligents: Solidity (a la plataforma Ethereum). El material es basa en un estudi del llibre blanc disponible en línia de 26 pàgines.
Introducció
Move és un llenguatge de bytecode executable que s'utilitza per executar transaccions d'usuari i contractes intel·ligents. Fixeu-vos en dos punts:
- Tot i que Move és un llenguatge de codis de bytes que es pot executar directament a la màquina virtual Move, Solidity (el llenguatge de contracte intel·ligent d’Ethereum) és un llenguatge de nivell superior que es compila primer per bytecode abans d’executar-se en un EVM (Ethereum Virtual Machine).
- Move es pot utilitzar no només per implementar contractes intel·ligents, sinó també per a transaccions personalitzades (més sobre això més endavant), mentre que Solidity és un llenguatge només per a contractes intel·ligents.
La traducció l'ha fet l'equip del projecte INDEX Protocol. Hem traduït prèviament , ara és el moment d'aprofundir en l'idioma Move. La traducció es va fer conjuntament amb l'habrauser
Una característica clau de Move és la capacitat de definir tipus de recursos personalitzats amb una semàntica basada en la lògica lineal: un recurs mai es pot copiar ni esborrar implícitament, només es pot moure. Funcionalment, això és similar a les característiques del llenguatge Rust. Els valors de Rust només es poden assignar a un nom alhora. Assignar un valor a un altre nom fa que no sigui accessible amb el nom anterior.
Per exemple, el fragment de codi següent generarà un error: Ús del valor mogut 'x'. Això es deu al fet que no hi ha recollida d’escombraries a Rust. Quan les variables surten de l'abast, també s'allibera la memòria a què fan referència. En poques paraules, només hi pot haver un "propietari" de les dades. En aquest exemple x és el propietari original i després y es converteix en el nou propietari. .
Representació d’actius digitals en sistemes oberts
Hi ha dues propietats dels actius físics difícils de representar digitalment:
- Raretat (Escassetat, originalment escassetat). Cal controlar el nombre d’actius (emissió) del sistema. Cal prohibir la duplicació d’actius existents i crear-ne de nous és una operació privilegiada.
- Control d'accés... El participant del sistema ha de poder protegir els actius mitjançant polítiques de control d’accés.
Aquestes dues característiques, que són naturals per als actius físics, s’han d’implementar per als objectes digitals si volem considerar-los com a actius. Per exemple, un metall rar: té una escassetat natural i només hi teniu accés (tenint-lo a les mans, per exemple) i el podeu vendre o gastar.
Per il·lustrar com hem arribat a aquestes dues propietats, comencem per les frases següents:
Suggeriment núm. 1: la regla més senzilla sense escassetat i control d'accés
- G [K]: = n indica una actualització d’un número accessible per una clau К a l’estat global de la cadena de blocs, amb un nou significat n.
- transacció lAlice, 100⟩ significa establir el saldo del compte d’Alice a 100.
La solució anterior té diversos problemes importants:
- Alícia pot rebre un nombre il·limitat de monedes simplement enviant transacció lAlice, 100⟩.
- Les monedes que Alice envia a Bob són inútils, ja que Bob podria enviar-se un nombre il·limitat de monedes amb la mateixa tècnica.
Suggeriment núm. 2: tenint en compte el dèficit
Ara estem supervisant la situació perquè el nombre de monedes Ka era almenys igual n abans de la transacció. Tanmateix, tot i que això soluciona el problema de l’escassetat, no hi ha informació sobre qui pot enviar les monedes d’Alicia (de moment, qualsevol persona pot fer-ho, el més important és no trencar la regla de limitar l’import).
Proposta # 3: Combinar escassetat i control d’accés
Solucionem aquest problema amb un mecanisme de signatura digital verificar_sig abans de comprovar el saldo, el que significa que Alice utilitza la seva clau privada per signar la transacció i confirmar que és la propietària de les seves monedes.
Llenguatges de programació Blockchain
Els idiomes de blockchain existents s’enfronten als problemes següents (tots es van resoldre a Move (nota: malauradament, l'autor de l'article només apel·la a Ethereum en les seves comparacions, per la qual cosa val la pena prendre-les només en aquest context. Per exemple, la majoria del següent també es resol a EOS.)):
Representació indirecta d’actius. Un actiu es codifica amb un nombre enter, però un valor enter no és el mateix que un actiu. De fet, no hi ha cap tipus ni valor que representi bitcoin / èter / <Qualsevol moneda>! Això fa que sigui difícil i propens a errors escriure programes que utilitzen actius. Els patrons com ara passar actius a/des dels procediments o emmagatzemar actius en estructures requereixen un suport especial de l'idioma.
El dèficit no és ampliable... El llenguatge només representa un bé escàs. A més, els remeis contra l’escassetat es connecten directament a la semàntica del propi idioma. El desenvolupador, si vol crear un recurs personalitzat, ha de controlar ell mateix tots els aspectes del recurs. Aquests són exactament els problemes dels contractes intel·ligents d’Ethereum.
Els usuaris emeten els seus actius, els tokens ERC-20, mitjançant enteros per determinar tant el valor com el subministrament total. Sempre que es creen noves fitxes, el codi de contracte intel·ligent ha de verificar independentment el compliment de les normes d’emissions. A més, la presentació indirecta d’actius comporta, en alguns casos, greus errors: duplicació, despesa doble o fins i tot pèrdua completa d’actius.
Manca de control d’accés flexible... L’única política de control d’accés que s’utilitza actualment és un esquema de signatures que utilitza criptografia asimètrica. Igual que la protecció per escassetat, les polítiques de control d’accés estan profundament incrustades en la semàntica de la llengua. Però la manera d’estendre el llenguatge per permetre als programadors definir les seves pròpies polítiques de control d’accés és sovint una tasca molt complicada.
Això també és cert per a Ethereum, on els contractes intel·ligents no tenen suport natiu per a la criptografia per al control d'accés. Els desenvolupadors han d'escriure manualment el control d'accés, per exemple, utilitzant el modificador onlyOwner.
Tot i que sóc un gran fan d'Ethereum, crec que les propietats dels actius haurien de ser compatibles de manera nativa amb l'idioma per motius de seguretat. En particular, passar Ether a un contracte intel·ligent permet l'enviament dinàmic, que ha introduït una nova classe d'errors conegudes com a vulnerabilitats de reentrada. L'enviament dinàmic aquí significa que la lògica d'execució del codi es determinarà en temps d'execució (dinàmic) i no en temps de compilació (estàtica).
Així, a Solidity, quan el contracte A anomena una funció del contracte B, el contracte B pot executar codi que no estava previst pel desenvolupador del contracte A, cosa que pot conduir a (el contracte A actua accidentalment com a contracte B per retirar diners abans que els saldos es dedueixin realment del compte).
Moveu els fonaments del disseny del llenguatge
Recursos de primer ordre
A un nivell alt, la interacció entre mòduls / recursos / procediments en el llenguatge Move és molt similar a la relació entre classes / objectes i mètodes en llenguatges OOP.
Els mòduls Move són similars als contractes intel·ligents en altres cadenes de blocs. El mòdul declara els tipus de recursos i els procediments que defineixen les regles per crear, destruir i actualitzar recursos declarats. Però tot això són només convencions (“argot”) A Mou. Il·lustrarem aquest punt una mica més endavant.
Flexibilitat
Move afegeix flexibilitat a Libra mitjançant scripts. Cada transacció a Libra inclou un script, que en realitat és el procediment principal de la transacció. L'script pot realitzar una acció especificada, per exemple, fer pagaments a una llista especificada de destinataris, o reutilitzar altres recursos, per exemple, cridant un procediment que defineix la lògica comuna. És per això que els scripts de transacció Move ofereixen molta flexibilitat. Un script pot utilitzar tant comportaments puntuals com recurrents, mentre que Ethereum només pot executar scripts recurrents (cridant un mètode de contracte intel·ligent únic). El motiu pel qual s'anomena "repetició" és perquè les funcions de contracte intel·ligent es poden executar diverses vegades. (nota: aquí el moment és molt subtil. D'una banda, hi ha scripts de transaccions en forma de pseudo-bytecode a Bitcoin. D'altra banda, tal com ho entenc, Move amplia aquest llenguatge, de fet, al nivell d'un llenguatge de contracte intel·ligent complet.).
Безопасность
El format executable de Move és bytecode, que, d'una banda, és un llenguatge de nivell superior al de l'assemblador, però de nivell inferior al codi font. El bytecode es comprova en temps d'execució (en cadena) per als recursos, els tipus i la seguretat de la memòria mitjançant un verificador de bytecode i després l'executa l'intèrpret. Aquest enfocament permet que Move proporcioni la seguretat del codi font, però sense el procés de compilació i la necessitat d'afegir un compilador al sistema. Fer que Move sigui un llenguatge bytecode és una molt bona idea. No cal compilar-lo des de la font, ja que en el cas de Solidity, no cal preocupar-se per possibles errors o atacs a la infraestructura del compilador.
Verificació
Pretenem fer les comprovacions el més fàcil possible, ja que tot va en cadena (nota: en línia, durant l'execució de cada transacció, de manera que qualsevol retard comporta una desacceleració de tota la xarxa), però inicialment el disseny del llenguatge està preparat per utilitzar eines de verificació estàtica fora de la cadena. Tot i que això és més preferible, el desenvolupament d'eines de verificació (com a conjunt d'eines independent) s'ha posposat per al futur, i actualment només s'admet la verificació dinàmica en temps d'execució (en cadena).
Modularitat
Els mòduls Move proporcionen l’abstracció de dades i localitzen les operacions crítiques dels recursos. L'encapsulació proporcionada pel mòdul, combinada amb la protecció proporcionada pel sistema de tipus Move, garanteix que les propietats establertes en els tipus del mòdul no es puguin infringir amb el codi extern al mòdul. Es tracta d’un disseny d’abstracció ben pensat, que significa que les dades d’un contracte només es poden canviar dins l’àmbit del contracte, però no externament.
Visió general del moviment
L'exemple de script de transaccions demostra que les accions malicioses o descurades d'un programador fora d'un mòdul no poden comprometre la seguretat dels recursos d'un mòdul. A continuació, veurem exemples de com s’utilitzen mòduls, recursos i procediments per programar la cadena de blocs Libra.
Pagaments d’igual a igual
El nombre de monedes especificat en quantitat es transferirà del saldo del remitent al destinatari.
Hi ha diversos punts nous aquí (ressaltats amb inscripcions vermelles):
- 0x0: adreça del compte on s’emmagatzema el mòdul
- Moneda: nom del mòdul
- Moneda: tipus de recurs
- El valor de la moneda retornat pel procediment és un valor de recurs del tipus 0x0.Currency.Coin
- move (): el valor no es pot tornar a utilitzar
- copy (): el valor es pot utilitzar més endavant
Analitzeu el codi: al primer pas, el remitent crida a un procediment anomenat retirar_de_emissor des d'un mòdul emmagatzemat a 0x0.Divisa. En el segon pas, el remitent transfereix fons al destinatari movent el valor del recurs de moneda al procediment de dipòsit del mòdul. 0x0.Divisa.
A continuació, es mostren tres exemples d'errors en el codi que seran rebutjats mitjançant controls:
Dupliqueu els fons canviant la trucada moure (moneda) en còpia (moneda). Els recursos només es poden moure. Intentar duplicar la quantitat d'un recurs (per exemple, trucant a còpia (moneda) a l’exemple anterior) donarà lloc a un error durant la validació de codis byt.
Reutilització de fons especificant moure (moneda) dues vegades . Afegint una línia 0x0.Currency.deposit(copiar(algun_altre_beneficiari), moure(moneda)) L'exemple anterior permetrà que el remitent "gasti" les monedes dues vegades: la primera vegada amb el beneficiari i la segona amb algun_altre_beneficiari. Aquest és un comportament indesitjable que no és possible amb un actiu físic. Afortunadament, Move rebutjarà aquest programa.
Pèrdua de fons per denegació moure (moneda). Si no moveu el recurs (per exemple, eliminant la línia que conté moure (moneda)), es generarà un error de verificació del bytecode. Això protegeix els programadors de Move de pèrdues accidentals o malintencionades de fons.
Mòdul de moneda
Cada compte pot contenir 0 o més mòduls (representats com a caixes) i un o més valors de recursos (representats com a cilindres). Per exemple, un compte a 0x0 conté el mòdul 0x0.Divisa i un valor de recurs de tipus 0x0.Moneda.Moneda. Compte a l'adreça 0x1 té dos recursos i un mòdul; Compte a l'adreça 0x2 té dos mòduls i un valor de recurs.
Alguns moments:
- L'script de transacció és atòmic, ja sigui completament executat o no.
- Un mòdul és una peça de codi de llarga vida disponible a tot el món.
- L'estat global s'estructura com una taula hash, on l'adreça del compte és la clau
- Els comptes no poden contenir més d'un valor de recurs d'un tipus determinat i no més d'un mòdul amb un nom donat (un compte a 0x0 no pot contenir cap recurs addicional 0x0.Moneda.Moneda o un altre mòdul anomenat Moneda)
- L'adreça del mòdul declarat forma part del tipus (0x0.Moneda.Moneda и 0x1.Moneda.Moneda són tipus separats que no es poden utilitzar indistintament)
- Els programadors poden emmagatzemar diverses instàncies d'un tipus de recurs determinat en un compte definint el seu recurs personalitzat - (recurs TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Podeu fer referència a un recurs pel seu nom sense conflicte, per exemple podeu fer referència a dos recursos utilitzant TwoCoins.c1 и TwoCoins.c2.
Declaració de recursos monedes
Mòdul anomenat Moneda i un tipus de recurs anomenat Moneda
Alguns moments:
- Moneda és una estructura amb un camp de tipus u64 (número enter sense signe de 64 bits)
- Només tràmits del mòdul Moneda pot crear o destruir valors de tipus Moneda.
- Altres mòduls i scripts només poden escriure o fer referència al camp de valor mitjançant procediments públics proporcionats pel mòdul.
Implementació del dipòsit
Aquest procediment accepta un recurs Moneda com a entrada i la concatena amb un recurs Monedaemmagatzemats al compte del beneficiari:
- Destruint el recurs d'entrada Coin i escrivint el seu valor.
- Obtenció d'un enllaç a un recurs de moneda únic emmagatzemat al compte del destinatari.
- Canviar el valor del nombre de monedes pel valor passat al paràmetre en cridar el procediment.
Alguns moments:
- Desempaqueteu, BorrowGlobal - procediments integrats
- Desempaquetar aquesta és l'única manera d'esborrar un recurs de tipus T. El procediment pren un recurs com a entrada, el destrueix i retorna el valor associat als camps del recurs.
- BorrowGlobal pren una adreça com a entrada i retorna una referència a la instància única de T publicada (propietat) per aquesta adreça
- &mut Coin aquest és un enllaç a un recurs Moneda
Implementant withdraw_from_sender
Aquest procediment:
- Obté un enllaç a un recurs únic Moneda, enllaçat al compte del remitent
- Disminueix el valor d'un recurs Moneda per referència per l'import especificat
- Crea i retorna un recurs nou Moneda amb saldo actualitzat.
Alguns moments:
- Dipòsit pot ser trucat per qualsevol, però retirar_de_emissor només té accés a les monedes del compte de trucada
- GetTxnSenderAddress semblant a msg.sender en Solidesa
- Rebutja tret que semblant a exigir en Solidesa. Si aquesta comprovació falla, l'execució de la transacció s'atura i tots els canvis es revertiran.
- paquet també és un procediment integrat que crea un nou recurs de tipus T.
- Així com Desempaquetar, paquet només es pot cridar dins del mòdul on es declara el recurs T
Conclusió
Vam analitzar les característiques principals del llenguatge Move, el vam comparar amb Ethereum i també ens vam familiaritzar amb la sintaxi bàsica dels scripts. Finalment, us recomano molt navegar . Inclou molts detalls sobre els principis de disseny del llenguatge de programació, així com molts enllaços útils.
Font: www.habr.com