[RFC] Example-driven proposal for Move-based programmability #4

sblackshear · 2021-11-18T23:30:13Z

See included README

gdanezis

Wow. Mind blowing stuff.

fastx_programmability/Move.toml

fastx_programmability/README.md

fastx_programmability/examples/CustomObjectTemplate.move

fastx_programmability/sources/Coin.move

fastx_programmability/sources/Escrow.move

gdanezis · 2021-11-19T11:11:58Z

fastx_programmability/sources/Transfer.move

+    // logic for their structs that cannot be subverted by other modules
+    public native fun transfer<T: key>(obj: T, recipient: Authenticator);
+
+    /// Transfer ownership of `obj` to another object `id`. Afterward, `obj`


Nice one: also I think the constraint is a little stronger than it may be used only when another object is in the Tx. The 'owner' object smart contact needs to invoke the operation that uses the owned object?

I don't think I understood this. Here's what I was thinking in more detail; let me know which part is too strong.

Every transaction has to be signed by one end-user Bob

A transaction can include objects directly owned by Bob (e.g., obj1.authenticator = Bob)

Under the George proposal, objects can own other objects, and a the transaction can also include objects transitively owned by Bob (e.g., ParentObj.authenticator = GranparentObj, ChildObj.Authenticator=ParentObj, GrandparentObj.authenticator = Bob)

If a transaction wants to use ChildObj, it must also include ParentObj and GrandparentObj + be signed by Bob. Otherwise, we can't verify which end-user's signature grants permission to include ChildObj.

huitseeker

Thanks for these examples, they're great!

In several cases, I've noticed portions of examples that angle towards ACLs: we have a list of subjects with special permissions:

const ADMIN in Hero.move,
const OWNER in TrustedCoin.move

I've indicated other "roles" that may arise, for instance on the EscrowSwap contract.

Sidenote:
Just so we're on the same page re: vocabulary in the context of this discussion:

we're dealing with resources (e.g. a boar, a sword, a TreasuryCap),

and we're dealing with subjects (e.g. the owner of the passed resources, the admin account, the coin OWNER account),

ACLs are what guarantees safety when you "classify" what can happen depending on the resource at hand (e.g. for the Hero contract, the normal callers have ambient permissions to slay, heal, ..., whereas the admin also has permissions to create_{potion, boar}). And, as you know, capabilities are what happen when you "sort" permissions on the subject at hand (e.g. Bob has a Sword, and a Boar, so he can create a Hero, and maybe slay, but not heal).

Overall, I would like some details on the management of the contract ACL list, if you will.

if it is, as demonstrated, limited to constants —requiring a full-fleged contract update to change— do we plan to manage those updates more loosely in FastX? If not, is this manageable? How do we address the proliferation of contracts who want a "fork" of the HeroesOfBC&Magic game?
Will we materialize explicit ACLs? What would that look like? Maybe a Permissions type, pointers from smart contracts to a specific handful of coarse Permissions instances, and a global namespace tying Permissions to users ?
How do we delegate and revoke permissions?

fastx_programmability/sources/Escrow.move

fastx_programmability/examples/Hero.move

huitseeker · 2021-11-19T20:34:13Z

fastx_programmability/examples/Hero.move

+        sword: Sword,
+    }
+
+    /// The hero's trusty sword


I think the later. What I haven't seen is the Sword creation though.

huitseeker · 2021-11-19T20:50:20Z

fastx_programmability/examples/CustomObjectTemplate.move

+    ) {
+        let v = read_field(to_read);
+        write_field(to_write, v + int_input);
+        transfer(to_consume, Authenticator::new(bytes_input));


I think the idea here I think is to represent object ownership (in the pecuniary sense) by object ownership (in the Rust capability sense).

Even If a &mut foo sufficed at runtime to transfer foo (by, say a —hypothetical— mutation of an owner field in foo), then any smart contract you'd give this &mut foo to could either give your foo a new sword, or transfer it away, at its discretion.

One language trick to reconcile your expectation of drop and your read of "taking a value" is to call it "consuming" a value.

fastx_programmability/examples/TrustedCoin.move

fastx_programmability/sources/Coin.move

huitseeker · 2021-11-19T21:16:19Z

fastx_programmability/sources/Escrow.move

+    public fun create<T: key + store, ExchangeForT: key + store>(
+        recipient: Authenticator,
+        third_party: Authenticator,
+        exchange_for: IDBytes,
+        escrowed: T,
+        ctx: &mut TxContext
+    ) {


IIUC, nothing prevents e.g. me from escrowing the object to myself, and then scamming others into participating in an exchange with me.

Without a return_to_sender call automatically issued by a timekeeper I do not control (as discussed later), this allows me to block another person's object (as well as my own), trolling them, or alternatively, holding this as a perpetual American option.

In other terms, we need to make sure the 3d party is not only not the sender (symmetrically receiver), but also not otherwise controlled by the sender (resp. receiver).

Ah, interesting point. I don't think there's much we can do about this--at the very least, we can assert that sender and recipient are not the same as third_party. But of course in general, third_party can be recipient with a different authenticator, and there's no good way to prevent that.

I think this attack is a special case of "if the trusted third party is not trustworthy, your objects will get locked up", but makes the important point that the trusted third party might have more motivation to lock up your object than you might think (i.e., trolling is not rational, holding a free American option is...)

sblackshear · 2021-11-20T00:26:45Z

Thanks for these examples, they're great!

In several cases, I've noticed portions of examples that angle towards ACLs: we have a list of subjects with special permissions:

const ADMIN in Hero.move,

const OWNER in TrustedCoin.move

I've indicated other "roles" that may arise, for instance on the EscrowSwap contract.

Sidenote:
Just so we're on the same page re: vocabulary in the context of this discussion:

we're dealing with resources (e.g. a boar, a sword, a TreasuryCap),

and we're dealing with subjects (e.g. the owner of the passed resources, the admin account, the coin OWNER account),

ACLs are what guarantees safety when you "classify" what can happen depending on the resource at hand (e.g. for the Hero contract, the normal callers have ambient permissions to slay, heal, ..., whereas the admin also has permissions to create_{potion, boar}). And, as you know, capabilities are what happen when you "sort" permissions on the subject at hand (e.g. Bob has a Sword, and a Boar, so he can create a Hero, and maybe slay, but not heal).

Overall, I would like some details on the management of the contract ACL list, if you will.

if it is, as demonstrated, limited to constants —requiring a full-fleged contract update to change— do we plan to manage those updates more loosely in FastX? If not, is this manageable? How do we address the proliferation of contracts who want a "fork" of the HeroesOfBC&Magic game?

Will we materialize explicit ACLs? What would that look like? Maybe a Permissions type, pointers from smart contracts to a specific handful of coarse Permissions instances, and a global namespace tying Permissions to users ?

How do we delegate and revoke permissions?

if it is, as demonstrated, limited to constants —requiring a full-fleged contract update to change— do we plan to manage those updates more loosely in FastX? If not, is this manageable?

I think contract updates are not possible in the fastX model--see https://github.com/MystenLabs/fastnft/pull/4/files#r753590022.
We can use ACL's for rigid access control and capabilities for more flexibile access control (e.g., supporting delegation, key rotation, further constraining an access polic after-the-fact).

How do we address the proliferation of contracts who want a "fork" of the HeroesOfBC&Magic game?

If you want to use objects defined by HeroesOfBC&Magic in a different game, that should be possible by simply defining a new module that adds new logic around those objects. However, if the user wants to mutate the objects in ways that aren't allowed by the original module, or change the game logic, they'll need to fork the contract. If it's well-engineered, HeroesOfBC&Magic will be split across multiple modules that isolate the more generic bits from the game-specific ones + allows lots of customization of the generic bits.

Will we materialize explicit ACLs? What would that look like? Maybe a Permissions type, pointers from smart contracts to a specific handful of coarse Permissions instances, and a global namespace tying Permissions to users ?

TBD. I think there are interesting decisions between simplicity (it doesn't get any easier than asserting that the sender authenticator is equal to a constant) and more complex, but possibly harder-to-use access control functionality. My inclination is to start with the simplest methods, then add more as there are needs/clear value props (using capabilities, which are more complex but enable delegation is a great example).

How do we delegate and revoke permissions?

See #4 (comment)

[Object Ownership #4] Prevent circular ownership

# This is the 1st commit message: reword # The commit message MystenLabs#2 will be skipped: # fix # The commit message MystenLabs#3 will be skipped: # fix # The commit message MystenLabs#4 will be skipped: # fix

sblackshear force-pushed the programmability_rfc branch 3 times, most recently from 870cfb3 to a13ed34 Compare November 19, 2021 05:30

gdanezis reviewed Nov 19, 2021

View reviewed changes

huitseeker reviewed Nov 19, 2021

View reviewed changes

sblackshear force-pushed the programmability_rfc branch 4 times, most recently from ced417d to c0c0fa5 Compare November 22, 2021 18:08

[RFC] Example-driven proposal for Move-based programmability

c1ed7cc

sblackshear force-pushed the programmability_rfc branch from c0c0fa5 to c1ed7cc Compare November 26, 2021 16:20

sblackshear merged commit e170b6f into MystenLabs:main Nov 26, 2021

sblackshear mentioned this pull request Dec 2, 2021

[programmability MVP][umbrella] end-to-end demo of "heroes of blockchain and magic" game #14

Closed

lxfind added a commit that referenced this pull request Feb 1, 2022

Merge pull request #295 from MystenLabs/check-circular-ownership

bfcf1b9

[Object Ownership #4] Prevent circular ownership

Clay-Mysten mentioned this pull request Jul 20, 2022

[Sui Rust SDK] - Build and publish sui-sdk crate #1537

Closed

brson pushed a commit to brson/sui that referenced this pull request Apr 30, 2024

Doc for rust-analyzer settings (MystenLabs#4)

a4c6d7a

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[RFC] Example-driven proposal for Move-based programmability #4

[RFC] Example-driven proposal for Move-based programmability #4

sblackshear commented Nov 18, 2021

gdanezis left a comment

gdanezis Nov 19, 2021

sblackshear Nov 19, 2021

huitseeker left a comment •

edited

Loading

huitseeker Nov 19, 2021

huitseeker Nov 19, 2021

huitseeker Nov 19, 2021 •

edited

Loading

sblackshear Nov 20, 2021

sblackshear commented Nov 20, 2021 •

edited

Loading

[RFC] Example-driven proposal for Move-based programmability #4

[RFC] Example-driven proposal for Move-based programmability #4

Conversation

sblackshear commented Nov 18, 2021

gdanezis left a comment

Choose a reason for hiding this comment

gdanezis Nov 19, 2021

Choose a reason for hiding this comment

sblackshear Nov 19, 2021

Choose a reason for hiding this comment

huitseeker left a comment • edited Loading

Choose a reason for hiding this comment

huitseeker Nov 19, 2021

Choose a reason for hiding this comment

huitseeker Nov 19, 2021

Choose a reason for hiding this comment

huitseeker Nov 19, 2021 • edited Loading

Choose a reason for hiding this comment

sblackshear Nov 20, 2021

Choose a reason for hiding this comment

sblackshear commented Nov 20, 2021 • edited Loading

huitseeker left a comment •

edited

Loading

huitseeker Nov 19, 2021 •

edited

Loading

sblackshear commented Nov 20, 2021 •

edited

Loading