[move] Switch to public(script) for Sui Move entry points (MystenLabs…

…#1333)

* [move] Switch to public(script) for Sui Move entry points

- entry points for execution are no longer inferred
- they must be annotated with `public(script)`
- same rules for signatures as before (with some small tweaks to type parameters)

doc/move_code/objects_tutorial/sources/Ch1_2/ColorObject.move

@@ -24,7 +24,7 @@ module Tutorial::ColorObject {
         }
     }
 
-    public fun create(red: u8, green: u8, blue: u8, ctx: &mut TxContext) {
+    public(script) fun create(red: u8, green: u8, blue: u8, ctx: &mut TxContext) {
         let color_object = new(red, green, blue, ctx);
         Transfer::transfer(color_object, TxContext::sender(ctx))
     }
@@ -35,12 +35,12 @@ module Tutorial::ColorObject {
 
     // == Functions covered in Chapter 2 ==
 
-    public fun delete(object: ColorObject, _ctx: &mut TxContext) {
+    public(script) fun delete(object: ColorObject, _ctx: &mut TxContext) {
         let ColorObject { id, red: _, green: _, blue: _ } = object;
         ID::delete(id);
     }
 
-    public fun transfer(object: ColorObject, recipient: address, _ctx: &mut TxContext) {
+    public(script) fun transfer(object: ColorObject, recipient: address, _ctx: &mut TxContext) {
         Transfer::transfer(object, recipient)
     }
 }
@@ -131,4 +131,4 @@ module Tutorial::ColorObjectTests {
             assert!(TestScenario::can_take_object<ColorObject>(scenario), 0);
         };
     }
-}
+}

doc/src/build/move.md

@@ -246,7 +246,7 @@ simplest entry functions is defined in the SUI
 implement gas object transfer:
 
 ```rust
-public fun transfer(c: Coin::Coin<SUI>, recipient: address, _ctx: &mut TxContext) {
+public(script) fun transfer(c: Coin::Coin<SUI>, recipient: address, _ctx: &mut TxContext) {
     ...
 }
 ```
@@ -631,7 +631,7 @@ point of view of a Sui developer. First, let us create
 sword creation and transfer and put them into the `M1.move` file:
 
 ``` rust
-    public fun sword_create(magic: u64, strength: u64, recipient: address, ctx: &mut TxContext) {
+    public(script) fun sword_create(magic: u64, strength: u64, recipient: address, ctx: &mut TxContext) {
         use Sui::Transfer;
         use Sui::TxContext;
         // create a sword
@@ -644,7 +644,7 @@ sword creation and transfer and put them into the `M1.move` file:
         Transfer::transfer(sword, recipient);
     }
 
-    public fun sword_transfer(sword: Sword, recipient: address, _ctx: &mut TxContext) {
+    public(script) fun sword_transfer(sword: Sword, recipient: address, _ctx: &mut TxContext) {
         use Sui::Transfer;
         // transfer the sword
         Transfer::transfer(sword, recipient);
@@ -852,7 +852,7 @@ function to take the forge as a parameter and to update the number of
 created swords at the end of the function:
 
 ``` rust
-    public fun sword_create(forge: &mut Forge, magic: u64, strength: u64, recipient: address, ctx: &mut TxContext) {
+    public(script) fun sword_create(forge: &mut Forge, magic: u64, strength: u64, recipient: address, ctx: &mut TxContext) {
         ...
         forge.swords_created = forge.swords_created + 1;
     }
@@ -928,7 +928,7 @@ We can also transfer an object to be owned by another object. Note that the owne
 Once an object is owned by another object, it is required that for any such object referenced in the entry function, its owner must also be one of the argument objects. For instance, if we have a chain of ownership: account address `Addr1` owns object `a`, object `a` owns object `b`, and `b` owns object `c`, in order to use object `c` in a Move call, the entry function must also include both `b` and `a`, and the signer of the transaction must be `Addr1`, like this:
 ```
 // signer of ctx is Addr1.
-public fun entry_function(a: &A, b: &B, c: &mut C, ctx: &mut TxContext);
+public(script) fun entry_function(a: &A, b: &B, c: &mut C, ctx: &mut TxContext);
 ```
 
 A common pattern of object owning another object is to have a field in the parent object to track the ID of the child object. It is important to ensure that we keep such a field's value consistent with the actual ownership relationship. For example, we do not end up in a situation where the parent's child field contains an ID pointing to object A, while in fact the parent owns object B. To ensure the consistency, we defined a custom type called `ChildRef` to represent object ownership. Whenever an object is transferred to another object, a `ChildRef` instance is created to uniquely identify the ownership. The library implementation ensures that the `ChildRef` goes side-by-side with the child object so that we never lose track or mix up objects.

doc/src/build/programming-with-objects/ch1-object-basics.md

@@ -64,7 +64,7 @@ Below is the code that creates a new `ColorObject` and makes it owned by the sen
 use Sui::Transfer;
 
 // This is an entry function that can be called directly by a Transaction.
-public fun create(red: u8, green: u8, blue: u8, ctx: &mut TxContext) {
+public(script) fun create(red: u8, green: u8, blue: u8, ctx: &mut TxContext) {
     let color_object = new(red, green, blue, ctx);
     Transfer::transfer(color_object, TxContext::sender(ctx))
 }

doc/src/build/programming-with-objects/ch2-using-objects.md

@@ -19,7 +19,7 @@ struct ColorObject has key {
 Now let's add this function:
 ```rust
 /// Copies the values of `from_object` into `into_object`.
-public fun copy_into(from_object: &ColorObject, into_object, &mut ColorObject, _ctx: &mut TxContext) {
+public(script) fun copy_into(from_object: &ColorObject, into_object, &mut ColorObject, _ctx: &mut TxContext) {
     into_object.red = from_object.red;
     into_object.green = from_object.green;
     into_object.blue = from_object.blue;
@@ -49,7 +49,7 @@ public fun delete(versioned_id: VersionedID);
 ```
 Let's define a function in the `ColorObject` module that allows us to delete the object:
 ```rust
-    public fun delete(object: ColorObject, _ctx: &mut TxContext) {
+    public(script) fun delete(object: ColorObject, _ctx: &mut TxContext) {
         let ColorObject { id, red: _, green: _, blue: _ } = object;
         ID::delete(id);
     }
@@ -83,7 +83,7 @@ The first part is the same as what we have seen in [Chapter 1](./ch1-object-basi
 #### Option 2. Transfer the object
 The owner of the object may want to transfer it to another account. To support this, the `ColorObject` module will need to define a `transfer` API:
 ```rust
-public fun transfer(object: ColorObject, recipient: address, _ctx: &mut TxContext) {
+public(script) fun transfer(object: ColorObject, recipient: address, _ctx: &mut TxContext) {
     Transfer::transfer(object, recipient)
 }
 ```

doc/src/build/wallet.md

@@ -137,7 +137,7 @@ connection to the authorities.
 You can also connect the wallet to the Sui network via a [Rest Gateway](rest-api.md#start-local-rest-server);
 To use the rest gateway, update `wallet.conf`'s `gateway` section to:
 ```json
-{ 
+{
   ...
   "gateway": {
     "rest":"http://127.0.0.1:5001"
@@ -719,7 +719,7 @@ for the first look at Move source code and a description of the
 following function we will be calling in this tutorial:
 
 ```rust
-public fun transfer(c: Coin::Coin<SUI>, recipient: address, _ctx: &mut TxContext) {
+public(script) fun transfer(c: Coin::Coin<SUI>, recipient: address, _ctx: &mut TxContext) {
     Coin::transfer(c, Address::new(recipient))
 }
 ```

doc/src/explore/prototypes.md

@@ -69,7 +69,7 @@ POST `/call` with body:
        "function": "update_monster_stats",
        "args": [
            "0x{{player_id}}",
-           "0x{{farm_id}}", 
+           "0x{{farm_id}}",
            "0x{{pet_monsters}}",
            "0x{{monster_id}}",
            {{monster_level}},
@@ -107,11 +107,11 @@ GET /object_info?objectId={{monster_id}}
         // ID of the applied cosmetic at this slot
         applied_monster_cosmetic_0_id: Option<ID>,
         // ID of the applied cosmetic at this slot
-        applied_monster_cosmetic_1_id: Option<ID>,    
+        applied_monster_cosmetic_1_id: Option<ID>,
     }
 
     // Create a Monster and add it to the Farm's collection of Monsters
-    public fun create_monster(_player: &mut Player,
+    public(script) fun create_monster(_player: &mut Player,
                               farm: &mut Farm,
                               pet_monsters_c: &mut Collection::Collection,
                               monster_name: vector<u8>,
@@ -140,7 +140,7 @@ GET /object_info?objectId={{monster_id}}
     }
 
     // Creates a basic Monster object
-    public fun create_monster_(
+    public(script) fun create_monster_(
         monster_name: vector<u8>,
         monster_img_index: u64,
         breed: u8,
@@ -171,7 +171,7 @@ GET /object_info?objectId={{monster_id}}
 
 ```
     // Update the attributes of a monster
-    public fun update_monster_stats(
+    public(script) fun update_monster_stats(
         _player: &mut Player,
         _farm: &mut Farm,
         _pet_monsters: &mut Collection::Collection,

doc/src/explore/tutorials.md

@@ -28,7 +28,7 @@ gas units) times the price of gas in the SUI currency (i.e. the gas price).
 
 ## Gather accounts and gas objects
 
-In that new terminal, let us take a look at the account addresses we own in 
+In that new terminal, let us take a look at the account addresses we own in
 our wallet:
 ```
 $ wallet addresses
@@ -183,7 +183,7 @@ export GAME=F1B8161BD97D3CD6627E739AD675089C5ACFB452
 By convention, Player X goes first. Player X wants to put a mark at the center of the gameboard ((1, 1)). This needs to take two steps. First Player X creates a Mark object with the placement intention and send it to the admin.
 We will call the `send_mark_to_game` function in `TicTacToe`, whose signature looks like this:
 ```
-public fun send_mark_to_game(cap: &mut MarkMintCap, game_address: address, row: u64, col: u64, ctx: &mut TxContext);
+public(script) fun send_mark_to_game(cap: &mut MarkMintCap, game_address: address, row: u64, col: u64, ctx: &mut TxContext);
 ```
 The `cap` argument will be Player X's capability object (XCAP), and `game_address` argument will be the admin's address (ADMIN):
 ```
@@ -209,7 +209,7 @@ Mutated Objects:
 The above call created a Mark object, with ID `AE3CE9176F1A8C1F21D922722486DF667FA00394`, and it was sent to the admin.
 The admin can now place the mark on the gameboard. The function to place the mark looks like this:
 ```
-public fun place_mark(game: &mut TicTacToe, mark: Mark, ctx: &mut TxContext);
+public(script) fun place_mark(game: &mut TicTacToe, mark: Mark, ctx: &mut TxContext);
 ```
 The first argument is the game board, and the second argument is the mark the admin just received from the player. We will call this function (replace the second argument with the Mark object ID above):
 ```

sui/Cargo.toml

@@ -41,6 +41,7 @@ sui-adapter = { path = "../sui_programmability/adapter" }
 sui-framework = { path = "../sui_programmability/framework" }
 sui-network = { path = "../network_utils" }
 sui-types = { path = "../sui_types" }
+sui-verifier = { path = "../sui_programmability/verifier" }
 
 rustyline = "9.1.2"
 rustyline-derive = "0.6.0"