Dále podrobně zvážíme hlavní charakteristiky jazyka Move a jaké jsou jeho klíčové rozdíly s jiným, již populárním jazykem pro chytré smlouvy - Solidity (na platformě Ethereum). Materiál je založen na studii dostupného online 26stránkového dokumentu.
úvod
Move je spustitelný jazyk bajtového kódu, který se používá k provádění uživatelských transakcí a inteligentních kontraktů. Věnujte pozornost dvěma bodům:
- Zatímco Move je jazyk bytecode, který lze přímo spouštět na virtuálním stroji Move, Solidity (Ethereum's smart contract language) je jazyk vyšší úrovně, který je nejprve kompilován do bytecode před spuštěním na EVM (Ethereum Virtual Machine).
- Move lze použít nejen k implementaci inteligentních smluv, ale také pro vlastní transakce (více o tom později), zatímco Solidity je jazyk pouze pro inteligentní smlouvy.
Překlad provedl projektový tým INDEX Protocol. Dříve jsme překládali , nyní je čas podívat se blíže na jazyk Move. Překlad byl zhotoven společně s habrauserem
Klíčovou vlastností Move je schopnost definovat vlastní typy zdrojů se sémantikou založenou na lineární logice: zdroj nelze nikdy kopírovat ani implicitně odstranit, pouze přesunout. Funkčně je to podobné rysům jazyka Rust. Hodnoty v Rustu lze přiřadit vždy pouze jednomu názvu. Přiřazení hodnoty jinému názvu ji znepřístupní pod předchozím názvem.
Následující fragment kódu například vyvolá chybu: Použití posunuté hodnoty „x“. Důvodem je, že v Rustu není sběr odpadků. Když se proměnné dostanou mimo rozsah, uvolní se také paměť, na kterou odkazují. Jednoduše řečeno, „dat“ může být pouze jeden. V tomto příkladu x je původním vlastníkem a poté y se stává novým vlastníkem. .
Reprezentace digitálních aktiv v otevřených systémech
Existují dvě vlastnosti fyzických aktiv, které je obtížné digitálně znázornit:
- Rarita (Nedostatek, původně nedostatek). Počet aktiv (emisí) v systému musí být kontrolován. Duplikace stávajících prostředků musí být zakázána a vytváření nových je privilegovanou operací.
- Řízení přístupu... Účastník systému musí být schopen chránit aktiva pomocí zásad řízení přístupu.
Tyto dvě charakteristiky, které jsou přirozené pro fyzická aktiva, musí být implementovány pro digitální objekty, pokud je chceme považovat za aktiva. Například vzácný kov má přirozený deficit a pouze vy k němu máte přístup (například ho držíte v rukou) a můžete jej prodat nebo utratit.
Abychom ilustrovali, jak jsme k těmto dvěma vlastnostem dospěli, začněme následujícími větami:
Návrh č. 1: Nejjednodušší pravidlo bez nedostatku a řízení přístupu
- G [K]: = n označuje aktualizaci čísla přístupného klíčem К v globálním stavu blockchainu, s novým významem n.
- transakce liceAlice, 100⟩ znamená nastavení zůstatku na účtu Alice na 100.
Výše uvedené řešení má několik hlavních problémů:
- Alice může získat neomezený počet mincí jednoduchým odesláním transakce liceAlice, 100⟩.
- Mince, které Alice posílá Bobovi, jsou k ničemu, protože Bob si mohl stejnou technikou poslat neomezený počet coinů.
Návrh č. 2: Zohlednění deficitu
Nyní monitorujeme situaci tak, aby počet mincí Ka byl minimálně stejný n před transakcí převodu. Přestože se tím problém nedostatku řeší, neexistují žádné informace o tom, kdo může Aliciny mince posílat (prozatím to může udělat kdokoli, hlavní věcí je neporušovat pravidlo o omezení částky).
Návrh č. 3: Kombinace nedostatku a řízení přístupu
Tento problém řešíme mechanismem digitálního podpisu ověřit_sig před kontrolou zůstatku, což znamená, že Alice pomocí svého soukromého klíče podepíše transakci a potvrdí, že je vlastníkem jejích coinů.
Blockchain programovací jazyky
Stávající jazyky blockchainu čelí následujícím problémům (všechny byly vyřešeny v Move (poznámka: autor článku bohužel ve svých srovnání apeluje pouze na Ethereum, takže stojí za to je brát pouze v tomto kontextu. Například v EOSu je vyřešena také většina z následujících.)):
Nepřímé zastoupení majetku. Aktivum je zakódováno pomocí celého čísla, ale celočíselná hodnota není totéž jako aktiva. Ve skutečnosti neexistuje žádný typ nebo hodnota představující bitcoin / ether / <Any Coin>! Díky tomu je obtížné a náchylné k chybám při psaní programů, které využívají aktiva. Vzory, jako je předávání aktiv do/z procedur nebo ukládání aktiv ve strukturách, vyžadují speciální podporu jazyka.
Deficit není rozšiřitelný... Jazyk představuje pouze jedno vzácné aktivum. Prostředky proti nedostatku jsou navíc pevně zapojeny přímo do sémantiky samotného jazyka. Pokud chce vývojář vytvořit vlastní dílo, musí pečlivě kontrolovat všechny aspekty zdroje sám. To jsou přesně problémy inteligentních smluv Ethereum.
Uživatelé vydávají svá aktiva, tokeny ERC-20, pomocí celých čísel určují hodnotu i celkovou nabídku. Kdykoli jsou vytvořeny nové tokeny, kód inteligentní smlouvy musí nezávisle ověřit dodržování emisních pravidel. Nepřímá prezentace majetku navíc v některých případech vede k závažným chybám - duplikaci, zdvojnásobení výdajů nebo dokonce k úplné ztrátě majetku.
Nedostatek flexibilního řízení přístupu... Jedinou zásadou řízení přístupu, která se v současné době používá, je schéma podpisu využívající asymetrickou kryptografii. Stejně jako ochrana před nedostatkem jsou zásady řízení přístupu hluboce zakořeněny v sémantice jazyka. Ale jak rozšířit jazyk, aby umožnil programátorům definovat vlastní zásady řízení přístupu, je často velmi ošemetný úkol.
To platí i pro Ethereum, kde smart kontrakty nemají nativní podporu pro kryptografii pro řízení přístupu. Vývojáři musí ručně zapisovat řízení přístupu, například pomocí modifikátoru onlyOwner.
I když jsem velkým fanouškem Etherea, věřím, že vlastnosti aktiv by měly být z bezpečnostních důvodů nativně podporovány jazykem. Zejména předání Etheru do inteligentní smlouvy umožňuje dynamické odesílání, které zavedlo novou třídu chyb známých jako zranitelnosti opětovného vstupu. Dynamické odesílání zde znamená, že logika provádění kódu bude určena v době běhu (dynamická) a ne v době kompilace (statická).
V Solidity, když smlouva A volá funkci smlouvy B, smlouva B může spustit kód, který nebyl zamýšlen vývojářem smlouvy A, což může vést k (smlouva A náhodně funguje jako smlouva B o výběru peněz před tím, než jsou zůstatky skutečně odečteny z účtu).
Základy návrhu jazyka Move
Zdroje prvního řádu
Na vysoké úrovni je interakce mezi moduly / prostředky / postupy v jazyce Move velmi podobná vztahu mezi třídami / objekty a metodami v jazycích OOP.
Move moduly jsou podobné chytrým smlouvám v jiných blockchainech. Modul deklaruje typy prostředků a postupy, které definují pravidla pro vytváření, ničení a aktualizaci deklarovaných prostředků. Ale to všechno jsou jen konvence („žargon“) V pohybu. Tento bod ilustrujeme o něco později.
Flexibilita
Move přidává flexibilitu Libře prostřednictvím skriptování. Každá transakce ve Vahách obsahuje skript, což je vlastně hlavní procedura transakce. Skript může buď provést jednu zadanou akci, například provést platby určenému seznamu příjemců, nebo znovu použít jiné zdroje, například voláním procedury, ve které je specifikována obecná logika. To je důvod, proč transakční skripty Move nabízejí velkou flexibilitu. Skript může používat jednorázové i opakující se chování, zatímco Ethereum může spouštět pouze opakující se skripty (volání jedné metody chytré smlouvy). Důvod, proč se tomu říká „opakovaný“, je ten, že funkce inteligentní smlouvy lze provádět vícekrát. (Poznámka: tady je ten okamžik velmi jemný. Na jedné straně jsou v Bitcoinu transakční skripty ve formě pseudobytecode. Na druhou stranu, jak tomu rozumím, Move rozšiřuje tento jazyk v podstatě na úroveň plnohodnotného smart contract language).
zabezpečení
Spustitelný formát Move je bytecode, což je na jedné straně jazyk vyšší úrovně než assembler, ale nižší úrovně než zdrojový kód. Bytový kód je kontrolován za běhu (on-chain) na zdroje, typy a bezpečnost paměti pomocí ověřovače bajtového kódu a poté proveden interpretem. Tento přístup umožňuje Move poskytovat bezpečnost zdrojového kódu, ale bez procesu kompilace a nutnosti přidávat do systému kompilátor. Udělat z Move jazyk bytecode je opravdu dobrý nápad. Není nutné jej kompilovat ze zdroje, jako v případě Solidity, není třeba se obávat případných selhání nebo útoků na infrastrukturu kompilátoru.
Ověřitelnost
Naším cílem je co nejvíce zjednodušit kontroly, protože vše probíhá v řetězci (poznámka: online, během provádění každé transakce, takže jakékoli zpoždění vede ke zpomalení celé sítě), ale zpočátku je jazykový návrh připraven k použití mimořetězových nástrojů statického ověřování. Ačkoli je to výhodnější, vývoj ověřovacích nástrojů (jako samostatné sady nástrojů) byl odložen do budoucna a v současnosti je podporována pouze dynamická verifikace za běhu (on-chain).
Modularita
Přesunout moduly poskytují abstrakci dat a lokalizují důležité operace se zdroji. Zapouzdření poskytnuté modulem v kombinaci s ochranou poskytovanou systémem typu Move zajišťuje, že vlastnosti nastavené na typech modulů nelze narušit kódem mimo modul. Jedná se o poměrně dobře promyšlený návrh abstrakce, což znamená, že data ve smlouvě se mohou měnit pouze v rámci rozsahu smlouvy, ale ne externě.
Přesunout přehled
Příklad transakčního skriptu ukazuje, že škodlivé nebo nedbalé akce programátora mimo modul nemohou ohrozit zabezpečení prostředků modulu. Dále se podíváme na příklady toho, jak se moduly, prostředky a postupy používají k programování blockchainu Libra.
Platby peer-to-peer
Počet mincí uvedený v částce bude převeden ze zůstatku odesílatele na příjemce.
Je zde několik nových bodů (zvýrazněných červenými nápisy):
- 0x0: adresa účtu, kde je modul uložen
- Měna: název modulu
- Mince: typ zdroje
- Hodnota mince vrácená postupem je hodnotou zdroje typu 0x0.Currency.Coin
- přestěhovat se (): hodnotu nelze znovu použít
- kopírovat (): hodnotu lze použít později
Analyzujte kód: v prvním kroku odesílatel zavolá proceduru s názvem výběr_z_ odesílatele z modulu uloženého v 0x0. Měna. Ve druhém kroku odesílatel převede prostředky příjemci přesunutím hodnoty zdroje mincí do depozitní procedury modulu 0x0. Měna.
Zde jsou tři příklady chyb v kódu, které budou zamítnuty kontrolami:
Duplikovat prostředky změnou výzvy tah (mince) na kopie (mince). Zdroje lze pouze přesouvat. Pokus o duplikaci množství zdroje (například voláním kopie (mince) ve výše uvedeném příkladu) bude mít za následek chybu při kontrole bajtkódu.
Opakované použití finančních prostředků uvedením tah (mince) dvakrát . Přidání řádku 0x0.Currency.deposit(copy(some_other_payee), move(coin)) výše uvedený příklad umožní odesílateli „utratit“ mince dvakrát – poprvé s příjemcem a podruhé s nějaký_jiný_platič. Toto je nežádoucí chování, které u fyzického majetku není možné. Naštěstí Move tento program odmítne.
Ztráta finančních prostředků v důsledku odmítnutí tah (mince). Pokud zdroj nepřesunete (například odstraněním řádku obsahujícího tah (mince)), dojde k chybě ověření bajtového kódu. To chrání programátory Move před náhodnou nebo úmyslnou ztrátou finančních prostředků.
Měnový modul
Každý účet může obsahovat 0 nebo více modulů (zobrazených jako boxy) a jednu nebo více hodnot zdrojů (zobrazených jako válce). Například účet na 0x0 obsahuje modul 0x0. Měna a zdrojovou hodnotu typu 0x0.Currency.Coin. Účet na adrese 0x1 má dva zdroje a jeden modul; Účet na adrese 0x2 má dva moduly a jednu hodnotu zdroje.
Nekotory momenty:
- Transakční skript je atomický – buď zcela proveden, nebo vůbec.
- Modul je kus kódu s dlouhou životností, který je celosvětově dostupný.
- Globální stav je strukturován jako hashovací tabulka, kde je klíčem adresa účtu
- Účty mohou obsahovat maximálně jednu hodnotu zdroje daného typu a maximálně jeden modul s daným názvem (účet na 0x0 nemůže obsahovat další zdroj 0x0.Currency.Coin nebo jiný pojmenovaný modul Měna)
- Adresa deklarovaného modulu je součástí typu (0x0.Currency.Coin и 0x1.Currency.Coin jsou samostatné typy, které nelze zaměnit)
- Programátoři mohou ukládat více instancí daného typu zdroje na účet definováním vlastního zdroje - (zdroj TwoCoins {c1: 0x0.Currency.Coin, c2: 0x0.Currency.Coin})
- Můžete odkazovat na zdroj jeho jménem bez konfliktu, například můžete odkazovat na dva zdroje pomocí Dvě mince.c1 и Dvě mince.c2.
Prohlášení o zdroji mincí
Jmenovaný modul Měna a pojmenovaný typ zdroje Mince
Nekotory momenty:
- Mince je struktura s jedním polem typu u64 (64bitové celé číslo bez znaménka)
- Pouze modulové procedury Měna může vytvářet nebo ničit hodnoty typu Mince.
- Jiné moduly a skripty mohou zapisovat nebo odkazovat na pole hodnoty pouze prostřednictvím veřejných procedur poskytovaných modulem.
Realizace vkladu
Tento postup přijímá zdroj Mince jako vstup a zřetězí jej se zdrojem Minceuloženy na účtu příjemce:
- Zničení vstupního zdroje Coin a zápis jeho hodnoty.
- Získání odkazu na jedinečný zdroj Coin uložený na účtu příjemce.
- Změna hodnoty počtu Coinů o hodnotu předávanou v parametru při volání procedury.
Nekotory momenty:
- Rozbalte, BorrowGlobal - vestavěné postupy
- Rozbalit toto je jediný způsob, jak odstranit zdroj typu T. Procedura vezme zdroj jako vstup, zničí jej a vrátí hodnotu přidruženou k polím zdroje.
- BorrowGlobal vezme adresu jako vstup a vrátí odkaz na jedinečnou instanci T publikovanou (vlastněnou) touto adresou
- &mut Coin toto je odkaz na zdroj Mince
Implementace draw_from_sender
Tento postup:
- Získá odkaz na jedinečný zdroj Mince, propojený s účtem odesílatele
- Snižuje hodnotu zdroje Mince odkazem na uvedenou částku
- Vytvoří a vrátí nový zdroj Mince s aktualizovaným zůstatkem.
Nekotory momenty:
- Vklad může zavolat kdokoli, ale výběr_z_ odesílatele má přístup pouze k coinům volajícího účtu
- GetTxnSenderAddress podobný msg.sender v Soliditě
- OdmítnoutPokud podobný vyžadovat v Soliditě. Pokud tato kontrola selže, provádění transakce se zastaví a všechny změny budou vráceny zpět.
- balíček je to také vestavěná procedura, která vytváří nový zdroj typu T.
- Stejně jako Rozbalit, balíček lze volat pouze uvnitř modulu, kde je deklarován zdroj T
Závěr
Rozebrali jsme hlavní charakteristiky jazyka Move, porovnali jej s Ethereem a také se seznámili se základní syntaxí skriptů. Nakonec vřele doporučuji prohlížet . Obsahuje mnoho podrobností o principech návrhu programovacího jazyka a také mnoho užitečných odkazů.
Zdroj: www.habr.com