Ezután részletesen megvizsgáljuk a Move nyelv fő jellemzőit, és mi a legfontosabb különbség az intelligens szerződések másik, már népszerű nyelvével - a Solidity (az Ethereum platformon). Az anyag az elérhető 26 oldalas online papír tanulmányán alapul.
Bevezetés
A Move egy végrehajtható bájtkód nyelv, amelyet felhasználói tranzakciók és intelligens szerződések végrehajtására használnak. Kérjük, vegye figyelembe a két pontot:
- Míg a Move egy bájtkódnyelv, amely közvetlenül végrehajtható a Move virtuális gépen, a Solidity (Ethereum intelligens szerződés nyelve) egy magasabb szintű nyelv, amelyet először bájtkódra fordítanak, mielőtt végrehajtják az EVM-en (Ethereum Virtual Machine).
- A Move nemcsak intelligens szerződések végrehajtására, hanem egyedi tranzakciókhoz is használható (erről bővebben később), míg a Solidity egy okos szerződéses nyelv.
A fordítást az INDEX Protocol projekt csapata végezte. Már lefordítottuk , itt az ideje, hogy egy kicsit részletesebben megvizsgáljuk a Move nyelvet. A fordítást Habrauserrel közösen végeztük
A Move egyik kulcsfontosságú jellemzője az egyéni erőforrástípusok lineáris logikán alapuló szemantikával történő meghatározása: az erőforrást soha nem lehet másolni vagy implicit módon törölni, csak áthelyezni. Funkcionálisan ez hasonló a Rust nyelv képességeihez. A Rust értékek egyszerre csak egy névhez rendelhetők. Ha egy másik névhez értéket rendel, az nem érhető el az előző név alatt.
Például a következő kódrészlet hibát jelez: Az „x” áthelyezett érték használata. Ez azért van, mert a Rustban nincs szemétszállítás. Amikor a változók kimaradnak a hatókörből, a felszabaduló memória is felszabadul. Egyszerűen fogalmazva, az adatoknak csak egy "tulajdonosa" lehet. Ebben a példában x az eredeti tulajdonos, majd y lesz az új tulajdonos. .
Digitális eszközök ábrázolása nyílt rendszerekben
A fizikai eszközöknek két olyan tulajdonsága van, amelyeket nehezen lehet digitálisan ábrázolni:
- Ritkaság (Szűkösség, eredetileg szűkösség). A rendszerben lévő eszközök (kibocsátás) számát ellenőrizni kell. Meg kell tiltani a meglévő eszközök sokszorosítását, és újak létrehozása kiváltságos művelet.
- Belépés ellenőrzése... A rendszer résztvevőjének képesnek kell lennie az eszközök védelmére a hozzáférés -ellenőrzési házirendek használatával.
Ezt a két jellemzőt, amelyek természetesek a fizikai eszközök esetében, meg kell valósítani a digitális objektumok esetében, ha eszköznek akarjuk tekinteni őket. Például egy ritka fémnek természetes hiánya van, és csak Ön férhet hozzá (például a kezében tartva), és eladhatja vagy elköltheti.
Hogy szemléltessük, hogyan jutottunk el ehhez a két ingatlanhoz, kezdjük a következő mondatokkal:
1. javaslat: A legegyszerűbb szabály szűkösség és hozzáférés -ellenőrzés nélkül
- G [K]: = n a billentyűvel elérhető szám frissítését jelöli К a blokklánc globális állapotában, új jelentéssel n.
- tranzakció lAlice, 100⟩ azt jelenti, hogy Alice számlaegyenlegét 100 -ra állítja.
A fenti megoldásnak számos jelentős problémája van:
- Alice korlátlan számú érmét kaphat egyszerűen elküldve tranzakció lAlice, 100⟩.
- Az Alice Bobnak küldött érmék haszontalanok, mivel Bob korlátlan számú érmét küldhet magának ugyanezzel a technikával.
2. javaslat: A hiány figyelembevétele
Most nyomon követjük a helyzetet, hogy az érmék száma Ka legalább egyenlő volt n az átutalási tranzakció előtt. Bár ez megoldja a szűkösség problémáját, nincs információ arról, hogy ki küldheti el Alice érméit (egyelőre ezt bárki megteheti, a legfontosabb, hogy ne sértse meg az összeg korlátozásának szabályát).
3. javaslat: A szűkösség és a hozzáférés -ellenőrzés kombinálása
Ezt a problémát digitális aláírási mechanizmussal oldjuk meg ellenőriz_szig az egyenleg ellenőrzése előtt, ami azt jelenti, hogy Alice a magánkulcsával írja alá a tranzakciót, és megerősíti, hogy ő az érmék tulajdonosa.
Blockchain programozási nyelvek
A meglévő blokklánc -nyelvek a következő problémákkal szembesülnek (mindegyiket a Move -ban oldották meg (megjegyzés: sajnos a cikk szerzője összehasonlításaiban csak az Ethereumra apellál, ezért érdemes csak ebben az összefüggésben venni őket. Például az alábbiak többsége az EOS -ban is megoldódik.)):
Az eszközök közvetett ábrázolása. Egy eszköz egész számmal van kódolva, de az egész szám nem azonos az eszközzel. Valójában nincs Bitcoin/Ether/<Any Coin> típus vagy érték! Ez megnehezíti az eszközöket használó programok írását, és megnehezíti a hibákat. Az olyan minták, mint az eszközök átadása eljárásoknak/eljárásokból, vagy az eszközök struktúrákban való tárolása speciális nyelvi támogatást igényelnek.
A hiány nem bővíthető... A nyelv csak egy szűkös értéket képvisel. Ezenkívül a szűkösség elleni gyógymódok közvetlenül a nyelv szemantikájába vannak bekötve. A fejlesztőnek, ha egyéni eszközt szeretne létrehozni, magának kell alaposan ellenőriznie az erőforrás minden aspektusát. Pontosan ezek a problémák az Ethereum okos szerződésekkel.
A felhasználók egész számok segítségével adják ki eszközeiket, az ERC-20 tokeneket az érték és a teljes kínálat meghatározásához. Amikor új tokeneket hoznak létre, az intelligens szerződési kódnak függetlenül kell ellenőriznie a kibocsátási szabályok betartását. Ezenkívül az eszközök közvetett bemutatása bizonyos esetekben súlyos hibákhoz vezet - megkettőződéshez, kettős kiadáshoz vagy akár teljes vagyonvesztéshez.
A rugalmas beléptetés hiánya... Az egyetlen beléptetés -szabályozás, amelyet ma használnak, egy aláírási séma, amely aszimmetrikus titkosítást használ. A szűkösségvédelemhez hasonlóan a hozzáférés -szabályozás mélyen beágyazódik a nyelv szemantikájába. De a nyelv kiterjesztése annak lehetővé tételére, hogy a programozók meghatározzák saját beléptető szabályzatukat, gyakran nagyon trükkös feladat.
Ez az Ethereumra is igaz, ahol az intelligens szerződések nem rendelkeznek natív kriptográfiai támogatással a hozzáférés-vezérléshez. A fejlesztőknek manuálisan kell beállítaniuk a hozzáférés-vezérlést, például az onlyOwner módosítóval.
Annak ellenére, hogy nagy rajongója vagyok az Ethereumnak, úgy gondolom, hogy biztonsági okokból a nyelvnek natív módon támogatnia kell az eszköztulajdonságokat. Az Ether intelligens szerződésre átvitele magában foglalja a dinamikus elküldést, amely a hibák új osztályát vezette be, az úgynevezett visszatérési sebezhetőséget. A dinamikus diszpécser itt azt jelenti, hogy a kód végrehajtási logikája futási időben (dinamikus) lesz meghatározva, nem pedig fordítási időben (statikus).
Így a Solidityben, amikor az A szerződés meghív egy függvényt a B szerződésben, a B szerződés olyan kódot futtathat, amelyet nem az A szerződés fejlesztője szánt, ami azt eredményezheti, hogy (Az A szerződés véletlenül B szerződésként működik, hogy pénzt vonjon ki, mielőtt a számlaegyenlegeket ténylegesen levonnák).
Move Language Design Fundamentals
Elsőrendű erőforrások
Magas szinten a modulok / erőforrások / eljárások közötti interakció a Move nyelvben nagyon hasonlít az OOP nyelvek osztályai / objektumai és metódusai közötti kapcsolathoz.
A Move modulok hasonlóak az intelligens szerződésekhez más blokkláncokban. A modul deklarálja az erőforrástípusokat és eljárásokat, amelyek meghatározzák a bejelentett erőforrások létrehozásának, megsemmisítésének és frissítésének szabályait. De mindezek csak egyezmények ("szakmai nyelv”) In Move. Ezt a pontot egy kicsit később illusztráljuk.
rugalmasság
A Move rugalmasságot ad a Libra számára a szkriptek segítségével. A Libra-ban minden tranzakció tartalmaz egy szkriptet, amely lényegében a tranzakció alapeljárása. A szkript végrehajthat egy meghatározott műveletet, például kifizetéseket a címzettek meghatározott listájának, vagy más erőforrásokat is felhasználhat – például egy olyan eljárás meghívásával, amelyben az általános logika meg van adva. Ez az oka annak, hogy a Move tranzakciós szkriptek nagyobb rugalmasságot kínálnak. Egy parancsfájl egyszeri és ismétlődő viselkedést is használhat, míg az Ethereum csak megismételhető szkripteket tud végrehajtani (egy metódus meghívása intelligens szerződéses metóduson). Azért nevezik „újrafelhasználhatónak”, mert az intelligens szerződés funkciói többször is végrehajthatók. (jegyzet: A lényeg itt nagyon finom. Egyrészt a Bitcoinban is léteznek tranzakciós szkriptek pszeudo-bytecode formájában. Másrészt, ahogy én értem, a Move ezt a nyelvet valójában egy teljes értékű intelligens szerződéses nyelv szintjére bővíti.).
biztonság
A Move futtatható formátum a bytecode, amely egyrészt magasabb szintű nyelv, mint az assembly nyelv, de alacsonyabb szintű, mint a forráskód. A bájtkódot futásidőben (on-chain) ellenőrzi az erőforrások, típusok és memóriabiztonság szempontjából egy bájtkód-ellenőrző segítségével, majd az értelmező végrehajtja. Ez a megközelítés lehetővé teszi a Move számára, hogy biztosítsa a forráskód biztonságát, de a fordítási folyamat és a fordító hozzáadása nélkül a rendszerhez. A Move készítése bytecode nyelvre nagyon jó megoldás. Nem kell forrásból fordítani, mint a Solidity esetében, és nem kell aggódni a fordítói infrastruktúra esetleges meghibásodása vagy támadása miatt.
Ellenőrizhetőség
Célunk, hogy az ellenőrzéseket a lehető legegyszerűbben végezzük el, mivel mindez a láncon történik (megjegyzés: online, minden tranzakció végrehajtása során, így minden késedelem a teljes hálózat lelassulásához vezet), azonban kezdetben a nyelvi kialakítás készen áll a láncon kívüli statikus ellenőrző eszközök használatára. Bár ez előnyösebb, egyelőre az ellenőrző eszközök (mint külön eszközkészlet) fejlesztését a jövőre halasztották, és már csak a futásidejű (on-chain) dinamikus ellenőrzés támogatott.
Modularitás
A Move modulok adatok kivonását és az erőforrások kritikus műveleteinek lokalizálását biztosítják. A modul által biztosított beágyazás a Move típusú rendszer által biztosított védelemmel kombinálva biztosítja, hogy a modul típusainál beállított tulajdonságokat ne sértse meg a modulon kívüli kód. Ez egy meglehetősen átgondolt absztrakciós terv, ami azt jelenti, hogy a szerződésen belüli adatok csak a szerződés keretein belül változhatnak, kívül nem.
Áthelyezés áttekintése
A tranzakciós szkript példája azt mutatja, hogy a modulon kívüli programozó rosszindulatú vagy gondatlan cselekedetei nem veszélyeztethetik a modul erőforrásainak biztonságát. Ezután példákat fogunk látni arra, hogyan használják a modulokat, erőforrásokat és eljárásokat a Libra blokklánc programozására.
Peer-to-Peer fizetések
Az összegben megadott számú érme a feladó egyenlegéről kerül átutalásra a címzetthez.
Van itt néhány újdonság (pirossal kiemelve):
- 0x0: annak a fióknak a címe, ahol a modult tárolják
- Valuta: modul neve
- Érme: erőforrás típusa
- Az eljárás által visszaadott érme értéke 0x0.Currency.Coin típusú erőforrásérték
- lépés (): az értéket nem lehet újra használni
- másolat (): érték később használható
A kód értelmezése: az első lépésben a feladó meghív egy elnevezett eljárást send_from_sender ben tárolt modulból 0x0.Pénznem. A második lépésben a küldő pénzt utal át a címzettnek úgy, hogy az érme erőforrás értékét áthelyezi a modul befizetési eljárásába. 0x0.Pénznem.
Íme három példa a kód hibáira, amelyeket az ellenőrzések elutasítanak:
Ismétlődő pénzeszközök a hívás megváltoztatásával lépés (érme) on másolat (érme). Az erőforrásokat csak mozgatni lehet. Egy erőforrás mennyiségének megkettőzése (például hívással másolat (érme) a fenti példában) hibát okoz a bájtkód ellenőrzése során.
A pénzeszközök újra felhasználása a megadásával lépés (érme) kétszer . Egy sor hozzáadása 0x0.Currency.deposit (másolás (egyes_egyéb_kedvezményezett), áthelyezés (érme)) Például a fentiek lehetővé teszik a feladó számára, hogy kétszer „elköltse” az érméket – először a kedvezményezettel, a második alkalommal pedig some_other_payee. Ez egy nemkívánatos viselkedés, amely fizikai eszközzel nem lehetséges. Szerencsére a Move elutasítja ezt a programot.
Pénzkiesés az elutasítás miatt lépés (érme). Ha nem helyezi át az erőforrást (például a következőt tartalmazó sor törlésével). lépés (érme)), bájtkód-ellenőrzési hiba jelenik meg. Ez megvédi a Move programozókat a véletlen vagy rosszindulatú pénzvesztéstől.
Pénznem modul
Minden fiók 0 vagy több modult (téglalapként) és egy vagy több erőforrásértéket (hengerként) tartalmazhat. Például egy fiók a 0x0 modult tartalmaz 0x0.Pénznem és az erőforrástípus értéke 0x0.Valuta.Érme. Számla a címen 0x1 két erőforrással és egy modullal rendelkezik; Számla a címen 0x2 két modullal és egy erőforrás értékkel rendelkezik.
Nekotory pillanatok:
- A tranzakciós szkript atomi – vagy teljesen végrehajtódik, vagy egyáltalán nem.
- A modul egy hosszú életű kódrészlet, amely globálisan elérhető.
- A globális állapot hash-táblaként épül fel, ahol a kulcs a fiók címe
- A fiókok legfeljebb egy adott típusú erőforrás értéket és legfeljebb egy adott nevű modult tartalmazhatnak (fiók 0x0 nem tartalmazhat további erőforrást 0x0.Valuta.Érme vagy egy másik nevű modult Valuta)
- A deklarált modul címe része a típusnak (0x0.Valuta.Érme и 0x1.Valuta.Érme külön típusok, amelyek nem használhatók felváltva)
- A programozók az ilyen típusú erőforrások több példányát is tárolhatják egy fiókban egyéni erőforrásuk meghatározásával - (erőforrás TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Egy erőforrásra a nevével hivatkozhat ütközések nélkül, például hivatkozhat két erőforrásra TwoCoins.c1 и TwoCoins.c2.
Érmeforrás bejelentése
A modul neve Valuta és egy nevű erőforrástípust Érme
Nekotory pillanatok:
- Érme egy struktúra egy típusú mezővel u64 (64 bites előjel nélküli egész szám)
- Csak modul eljárások Valuta típusú értékeket hozhat létre vagy semmisíthet meg Érme.
- Más modulok és szkriptek csak a modul által biztosított nyilvános eljárásokon keresztül írhatnak vagy hivatkozhatnak az értékmezőre.
Betét értékesítése
Ez az eljárás erőforrást fogad el Érme bemenetként, és egyesíti az erőforrással Érmea címzett fiókjában tárolva:
- A bemeneti erőforrás Coin megsemmisítése és értékének rögzítése.
- A címzett fiókjában tárolt egyedi Coin-erőforrásra mutató hivatkozás fogadása.
- A Coin-ok számának megváltoztatása a paraméterben megadott értékkel az eljárás hívásakor.
Nekotory pillanatok:
- Csomagold ki, BorrowGlobal - beépített eljárások
- Csomagolja ki Ez az egyetlen módja a T típusú erőforrás törlésének. Az eljárás bemenetként vesz egy erőforrást, megsemmisíti, és visszaadja az erőforrás mezőihez tartozó értéket.
- BorrowGlobal bemenetként egy címet vesz fel, és hivatkozást ad vissza az adott cím által közzétett (tulajdonos) T egyedi példányára
- &mut Coin ez egy link a forráshoz Érme
A return_from_sender megvalósítása
Ez az eljárás:
- Hivatkozást kap egy egyedi forráshoz Érme, a feladó fiókjához kapcsolva
- Csökkenti az erőforrás értékét Érme linken keresztül a megadott összegért
- Létrehoz és visszaad egy új erőforrást Érme frissített egyenleggel.
Nekotory pillanatok:
- Letét bárki okozhatja, de send_from_sender csak a hívószámla érméihez férhet hozzá
- GetTxnSenderAddress hasonló msg.sender a Szilárdságban
- Elutasít Hacsak hasonló szükség a Szilárdságban. Ha ez az ellenőrzés sikertelen, a tranzakció leáll, és minden módosítás visszaáll.
- Csomag ez is egy beépített eljárás, amely egy új, T típusú erőforrást hoz létre.
- Továbbá Csomagolja ki, Csomag csak azon a modulon belül hívható meg, ahol az erőforrás le van írva T
Következtetés
Megvizsgáltuk a Move nyelv főbb jellemzőit, összehasonlítottuk az Ethereummal, és megismerkedtünk a szkriptek alapvető szintaxisával is. Végezetül nagyon ajánlom a megtekintést . Sok részletet tartalmaz a programozási nyelv tervezési elveiről, valamint sok hasznos hivatkozást.
Forrás: will.com