Access wrapped objects by ID outside of Move

[amnn]

Motivation

When an object is wrapped (made a field of) another object over the course of a move transaction, it disappears from the perspective of external tools, which can create confusing experiences, e.g.: When viewing a transaction that created an NFT in Explorer, if it is wrapped, its details will not be accessible via the transaction, even though it still exists in some sense. At a later time, the details may become accessible again, if the object is unwrapped.

Functionality

• Query an object by ID and discover that it is wrapped.
• Use this query to visualise wrapped objects in Explorer.

Proposal

• Full Node indexes wrapped events by scanning mutated objects looking for objects in the sub-structure whose id field matches the wrapped object's ID.
• Full Node persists this information into a table mapping an ID to a root object and access path.
• RPC calls to get objects by ID consult this table, and return a response indicating that the object was found wrapped.
• Explorer displays wrapped objects as differentiated from root objects, with an option to view the object that it is wrapped in.

Alternatives

It is possible to achieve the same functionality within the adapter layer between Sui and Move, by explicitly representing wrapped object's in validators' object storage. This could be done in one of two ways:

• Wrapped objects are represented by a root object and access path (like the proposed full node index) and the adapter scans mutated objects to look for wrapped objects to update.
• Wrapped objects are represented by their contents, and references to wrapped objects (in the object wrapping them) are represented by a forwarding pointer. This requires that the adapter layer re-constitutes the wrapped representation before objects before a move call, and then scan the resulting objects to flatten the representation back out when committing transaction effects to storage.

Both of these approaches require doing additional work on the validator which doesn't help with execution or consensus, and can be done in the full node for the benefit of readers.

There is also the possibility of an even simpler index representation in Full Node which omits the access path (i.e. the index just says that a wrapped object can be found "somewhere" in the sub-structure of a given root object). This saves indexing work on writes at the expense of scanning work on reads, which may make sense if reads are infrequent, but this may not be true if the Explorer is going to visualise all wrapped objects.