diff --git a/GRAVEYARD.md b/GRAVEYARD.md deleted file mode 100644 index d947d6e591..0000000000 --- a/GRAVEYARD.md +++ /dev/null @@ -1,54 +0,0 @@ -# Language feature idea graveyard - -Move is a smart contract language that counts minimalism as one of its guiding principles. Features are often proposed, but not always implemented. This list exists to record feature proposals that did not progress to acceptance. The goal of maintaining this list is to avoid duplicate proposals, and to explain the rationale for not moving forward with an idea that might seem promising at first blush. - -## Pure data structs - -### Decision -We should let adapters decide how to handle this - -### Rationale -Structs being passed to transactions cause safety issues because deserialization can circumvent modular encapsulation. For example, below make is the only way to create S and the program guarantees that field x is always greater zero; however, if S is obtained via deserialization, this constraint can be violated:: -``` -struct S has drop, copy { x: u64 } -public fun make(x: u64) { assert!(x > 0); S{x} } - -fun(entry) foo(s: S/*no guarantee about s.x*/) { … } -``` - -## Native structs - -### Decision -This is obsolete as regular structs can be used from native code, e.g. struct S { native_handle: u128 } - -### Rationale -As Move evolves to an extensible language, native structs are an important tool for extensibility. However, support for native structs has been removed from the VM (though still supported in compiler and file format). - -### Design -Bring back support for native structs in the VM. They can use a simple uniform representation via handles which are managed by the runtime environment (like u128 or u256 for each and every native struct value), so implementation effort should be small. - -## Signer relaxation for `move_to` - -### Decision -Tables and framework-specific workarounds like `ResourceAccount` make this unneccessary. - -### Rationale -In some usage scenarios of Move, it does not make sense to only allow move_to(s, x) with s a signer. For instance, when Move is running on the EVM, storage is not owned and paid for by the account owner, but by the contract caller, which manages the accounts on behalf of owners. In general, the signer requirement allows one to only create new resources at addresses for which the transaction has a signer, which disables the capability to manage resource collections on behalf of others. - -## Design (Option A) -Drop the requirement of passing a signer to move-to all together. For downwards compatibility reasons, the compiler allows passing either a signer or an address. Rationale for this quite radical step is that in-real world contracts (e.g. the Diem Payment Network) more complex access control patterns than enabled by signer/move_to are needed anyway. Moreover, since only modules which declare a resource R can call move_to, preventing publishing without a signer can still be modeled by modular encapsulation. - -### Design (Option B) -Use an attribute on struct declarations to indicate a signer is not required for publishing this struct. - -### Design (Option C) -Have another function which does not require a signer, e.g. move_to_address. This, however, raises questions of adequate naming and methodology (when to use which function, should there be constraints when which function is allowed, etc.) - -### Design (Option D) -Add no new features and ask clients that want this feature (e.g., the Move -> EVM compilation effort) to implement it via design patterns and/or native functions. See SignerCapability in the Starcoin Account code for one example of a design pattern for (effectively) implementing move_to_address without changing the language. - -### Design (Option E) -Support this via a new internal ability that allows framework designers to implement more powerful native functions with the same encapsulation guarantees as bytecodes. For example, the framework designer can define a function `public native fun move_to_address(a: address, t: T)` that can only be invoked on `T`’s declared in the calling module. - -### Design (Option F) -Use tables when there is a need to index storage without signer. diff --git a/README.md b/README.md index b104c8c01a..dfae24bd47 100644 --- a/README.md +++ b/README.md @@ -1,36 +1,32 @@ [![License](https://img.shields.io/badge/license-Apache-green.svg)](LICENSE) -[![Discord chat](https://img.shields.io/discord/903339070925721652.svg?logo=discord&style=flat-square)](https://discord.gg/M95qX3KnG8) -![Move logo](assets/color/SVG/Move_Logo_Design_Digital_Final_-01.svg) +![Move logo](assets/color/PNG/MoveOnAptos.png) -# The Move Language +# The Move Language -Move is a programming language for writing safe smart contracts originally developed at Facebook to power the Diem blockchain. Move is designed to be a platform-agnostic language to enable common libraries, tooling, and developer communities across diverse blockchains with vastly different data and execution models. Move's ambition is to become the "JavaScript of web3" in terms of ubiquity--when developers want to quickly write safe code involving assets, it should be written in Move. +Move is a programming language for writing safe smart contracts originally developed at Facebook to power the Diem blockchain. Move is designed to be a platform-agnostic language to enable common libraries, tooling, and developer communities across diverse blockchains with vastly different data and execution models. -This repository is the official home of the Move virtual machine, bytecode verifier, compiler, prover, package manager, and book. For Move code examples and papers, check out [awesome-move](https://github.com/MystenLabs/awesome-move). +This repository is a mirror of *Move on Aptos*, a natural evolution of the Move language how it was originally intended. The repository contains the generic part of the Move language and implementation as it is used on the [Aptos Network](https://aptosfoundation.org/) and on other networks. Major components of the implementation include +the Move virtual machine, bytecode verifier, compiler, prover, and package manager. -## Quickstart +For an introduction into the Move language, please check out the following resources: -### Build the [Docker](https://www.docker.com/community/open-source/) Image for the Command Line Tool +- The [Move Landing Page](https://aptos.dev/move/move-on-aptos) in the Aptos developer documentation +- TODO: more resources -``` -docker build -t move/cli -f docker/move-cli/Dockerfile . -``` +> *NOTE* If you have an issue with Move on Aptos while working with Aptos, please open it [here](https://github.com/aptos-labs/aptos-core/issues/new/choose) and not in this repo. -### Build a Test Project +# Consuming and Contributing -``` -cd ./language/documentation/tutorial/step_1/BasicCoin -docker run -v `pwd`:/project move/cli build -``` +The repository mirrors the content of the `aptos-core` repo, subtree [`third_party/move`](https://github.com/aptos-labs/aptos-core/tree/main/third_party/move). By consuming this repo, one can avoid cloning the large aptos-core repo. The repo is updated on a monthly basis with the newest changes from aptos-core. -Follow the [language/documentation/tutorial](./language/documentation/tutorial/README.md) to set up move for development. +> TODO: we plan to automate the update with a nightly schedule -## Community +For contributions, we ask for now to submit those to the [aptos-core](https://github.com/aptos-labs/aptos-core/tree/main/third_party/move) repo. + +> TODO: come up with a workflow to allow contributions downstream and upstream -* Join us on the [Move Discord](https://discord.gg/cPUmhe24Mz). -* Browse code and content from the community at [awesome-move](https://github.com/MystenLabs/awesome-move). ## License diff --git a/assets/color/PNG/MoveOnAptos.png b/assets/color/PNG/MoveOnAptos.png new file mode 100644 index 0000000000..2ed72a0844 Binary files /dev/null and b/assets/color/PNG/MoveOnAptos.png differ