Advantage of using dynamic fields vs Option

Move
1

Hey there, I was wondering what’s the best concept between Option and Dynamic object fields in Move ?

In terms of gas cost and access, I understand that both will prevent an object from being publicly transferred because they now exist only inside another object. What about gas ? let’s take the Sui example with the Hero struct

struct SimpleWarrior has key, store {
    id: UID,
    sword: Option<Sword>,
    shield: Option<Shield>,
}

or is it more cost-efficient to do

struct SimpleWarrior has key, store {
    id: UID,
}

ofield::add(&mut warrior.id, b"sword", sword)

Note that a Sword would also have nested transferable objects like a Rune { }, or a Color { }, which could also have their own nested things

2 Likes
2

Hello,

  1. The most obvious one is that simple fields are more type-safe than dynamic-fields.
    With dynamic fields you have to make sure you are accessing with the correct key string.
  2. In terms of usage, dynamic fields only need UID access of the object. In case you provide UID access in your module, the owner of the object can edit them as preferred, in contrast simple fields inside the struct the developer explicitly specifies their usage.
  3. A Sui Object has a max size of 256KB. This is very large, but a limit worth mentioning. Using dynamic-fields do not count in reaching this limit, ie. dynamic fields can store as much as needed.
  4. I suppose there might also be some difference in cost, however Sui’s recommended practice is not to think about computation cost when developing, but instead focus on the use-case.

In general in case I am not sure which fields I need (eg. sword, shield, bracers, gloves, armor, gems etc.) I would use dynamic-fields. If I am sure that the fields are specific and would not change I would use simple fields.

2 Likes