Accounts prototype (move side only)

[mystenmark]

Prototype of the move-side implementation of sui accounts.

The basic design is this:

• Modules must define a translation from the "user" type (e.g. Balance<T>) to a type that supports merging (e.g. MergableBalance<T>)
• Mergable types are types constructed entirely from types defined in mergable.move
• Things not shown/implemented in this PR:
  • The "mergable" types are what would be stored in the actual DF for a given account.
  • Merging will be done by rust code that traverses values and merges each subfield defined in mergable.rs
  • Merging could be done by the VM as well but who wants to invoke the VM to add two u128s together.

Things to note:

• There are no untyped values anywhere (its not "ethy")
• No special-casing in the framework for Balance or SUI - any type can use this system

Important TODOs:

• Verifier changes are necessary to make transfer_to_account private in the same way that transfer is
• PTB checker would have to verify that reserve is only called with an Input, not a result. I'm very open to better ideas of how to do reservations.

Things to not worry about:

• No, events are not the right way to do this. I used them because they are there and they demonstrate what we care about, which is that types are preserved as data flows through the system.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

3 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
multisig-toolkit	⬜️ Ignored (Inspect)			Dec 16, 2024 9:36pm
sui-kiosk	⬜️ Ignored (Inspect)			Dec 16, 2024 9:36pm
sui-typescript-docs	⬜️ Ignored (Inspect)			Dec 16, 2024 9:36pm

[mystenmark]

note that this is overkill for supporting Balance. We could have another type called CappedSum { u64 } for when values can't overflow.

But it would be dangerous to expose this type, since if it were improperly used by user code it could cause overflow.

So, we would have the option to special case Balance anyway and save 8 bytes if we want to, by having a public(package) CappedSum type.

[tnowacki]

Suggested change

	return Reservation { owner, limit }
	Reservation { owner, limit }

[sblackshear]

Was thinking about this, and I unfortunately don't think it's safe if:

1. recipient is an object ID (rather than an end-user address)
2. We allow transfers to "wrapped" accounts (e.g., struct Obj has key { .., wrapped_account_id: ID })

The reason is that with wrapped Balance/Coin fields, you often want to maintain invariants that could be violated by a direct transfer. For example, in a classic CFMM pool

struct Pool has key {
  // ...
  coin1_account_id: ID, // before: Balance<T1>
  coin2_account_id: ID, // before: Balance<T2>
}

, you would want to maintain the invariant balance(coin1_account_id) = k * balance(coin2_account_id). With the current Balance-based approach, you leverage encapsulation to enforce this--e.g. only allow writes in swap, and only if the invariant are maintained. But with an implementation that used wrapped accounts, it would not be possible to enforce this invariant because of (2) (e.g., can just deposit directly to balance 1 without touching balance 2).

[sblackshear]

Two approaches come to mind for addressing this--the key ideas behind both are to enforce encapsulation on transfers to "object accounts":
A. transfer_to_account requires a &mut UID or &ID of object O to transfer to an object account for O (not needed for an address account, of course)
B. Object accounts must be explicitly created, and have a different/more structured API for transfers than addresses. E.g.,

struct Account has store {
  id: UID,
}

public fun create(ctx: &mut TxContext): Account

// could also split into more fine-grained caps
public fun transfer_to_account<T>(deposit: T, account: &mut Account)