# Krešimir Klas - Smart Contract Development — Move vs. Rust (Highlights)  ## Metadata **Review**:: [readwise.io](https://readwise.io/bookreview/24368502) **Source**:: #from/readwise **Zettel**:: #zettel/fleeting **Status**:: #x **Authors**:: [[Krešimir Klas]] **Full Title**:: Smart Contract Development — Move vs. Rust **Category**:: #articles #readwise/articles **Category Icon**:: 📰 **Document Tags**:: #blockchain **URL**:: [medium.com](https://medium.com/@kklas/smart-contract-development-move-vs-rust-4d8f84754a8f) **Host**:: [[medium.com]] **Highlighted**:: [[2023-02-14]] **Created**:: [[2023-02-14]] ## Highlights ### 1. Introduction - In recent weeks and months, there’s been a lot of buzz around **Aptos** and **Sui**, the emerging high-performance L1s, and the **Move** smart contract programming language which is integral to these new chains. ([View Highlight](https://read.readwise.io/read/01gs7qj78z5078gzqsweh5yvhr)) ^475784649 ### 2. The Solana Programming Model - In a way, you can think of Solana programs as **programs in an operating system** and accounts as **files** where anyone can freely execute any program and even deploy their own programs. When programs (smart contracts) are run they will read from and write to files (accounts). All files are available to all programs for reading, but only the programs which have ownership permission on a file can write to it. ([View Highlight](https://read.readwise.io/read/01gs7qvy816x0p374a22d8cwfy)) ^475787015 ### 3. The Move Programming Model - To put this in the context of Solana, this is as if all smart contracts are published as modules within a single program. This means that all smart contracts (modules) are contained within the same type system and can call each other directly without going through an intermediate API or an interface. ([View Highlight](https://read.readwise.io/read/01gs7scw70243ah6fjpqj72rxy)) ^475792760 #### 3.1. Objects - Aptos or Diem/core Move ([View Highlight](https://read.readwise.io/read/01gs7sdba752kaaxnejqa4vmmx)) ^475792781 Move variants - Objects are struct instances that are stored by the runtime and persist state across transactions. ([View Highlight](https://read.readwise.io/read/01gs7sf33wjjvp4z9t1r3ckg0t)) ^475792962 - **Owned objects** are objects which belong to users. Only the user who owns the object can use it in a transaction. ([View Highlight](https://read.readwise.io/read/01gs7sfwrjzsqqk57297rbpnha)) ^475792991 - **Shared objects** are similar to owned objects but they don’t have an owner associated with them. Therefore you don’t have to possess any private keys to be able to use them in a transaction (anyone can use them). ([View Highlight](https://read.readwise.io/read/01gs7shn2c26nnvabab2nkqg9g)) ^475793114 - **Immutable objects** are objects which cannot be mutated. ([View Highlight](https://read.readwise.io/read/01gs7shtjgasc6yahbj7can05t)) ^475793132 ### 4. Move Safety - This means that if you’re handling an instance of this struct in a function in another module, **you wouldn’t be able to mutate its fields, clone it, store it in a field in another struct, or drop it** (you’d have to pass it on somewhere else via a function call). ([View Highlight](https://read.readwise.io/read/01gs7swdr6k54qetrcscd1sz51)) ^475794712 - **key** — this allows a struct to **become an object** (Sui specific, core Move is slightly different). As explained earlier, objects are persisted and, in the case of owned objects, require user signatures to be used in a smart contract call. ([View Highlight](https://read.readwise.io/read/01gs7t55z2yqyqfgx07x968qn3)) ^475795578 - **store** — this allows the struct to be **embedded as a field in another struct** ([View Highlight](https://read.readwise.io/read/01gs7t507k797qyw9466g1gjcy)) ^475795574 - Since there’s no **drop** capability, the Coin cannot be accidentally discarded (destroyed) in a function. This is a very nice feature — it means that you can’t lose a Coin by accident. ([View Highlight](https://read.readwise.io/read/01gs7t7efd6s79msca8ycmbt38)) ^475795759 - No **clone** capability means that nobody can duplicate the Coin and thus create new supply out of thin air. ([View Highlight](https://read.readwise.io/read/01gs7t8s16cb60qebk8c4qzfj0)) ^475795802 - In Move, the resource safety of a resource is defined by its type. Considering that Move has a global type system, this enables a more natural and safer programming model where resources can be passed in and out of untrusted code directly while preserving their safety. ([View Highlight](https://read.readwise.io/read/01gs7ta8hjbq6dmyy14c52r9dc)) ^475795878 - The Move verifier is a static analysis tool that analyzes Move bytecode and determines whether it respects the required type, memory, and resource safety rules. All code uploaded onto the chain needs to pass the verifier. ([View Highlight](https://read.readwise.io/read/01gs7tcbd0qpf3efr2t02xwqfx)) ^475796046 ### 5. Solana vs. Move - On Solana, each transaction consist of multiple instructions (smart contract calls), and from any instruction you can inspect other instructions (their program ID, instruction data, and accounts) present in the same transaction. ([View Highlight](https://read.readwise.io/read/01gs7tjzejgs4ftnz8an83fd0q)) ^475796861 - Move’s linear type system allows for creation of structs that are guaranteed to be consumed exactly once during transaction execution. This is the so-called “[**hot potato**](https://examples.sui.io/patterns/hot-potato.html)” pattern — a struct that has no `key`, `store`, `drop`, or `clone` capabilities. A module that implements such a pattern will usually have one function which instantiates the struct and another which destroys it. ([View Highlight](https://read.readwise.io/read/01gs7tm4pmcw4j8b4s6ctakr5c)) ^475796953