SIP: Remove the ID Leak Verifier

[manolisliolios]

Proposes removing the ID Leak Verifier, the bytecode pass that requires every object to be packed only with a freshly-minted UID.

This is an open request for feedback in an attempt to collect any scenarios that might get broken.

[RandyPen]

good idea

[admin-aftermath]

I am in favor of this SIP for a few reasons:

1. It solves this issue [move-std] Relaxing UID creation for sui::derived_object::claim MystenLabs/sui#24248; i.e., the ability to return a UID that can be used for creating an object.

I would much rather define a singular fun claim<K: copy + drop + store>(config: &mut Config, key: K): UID { ... } then have to expose a public(package) fun borrow_mut_id(config: &mut Config): &mut UID { ... } to derive objects across my package.

2. I have always wanted the ability of being able to define a general type (e.g., struct Pool<phantom StateVx> { ... }) where the inner field is a generic type and can be upgraded while not needing to change the parent UID. For example, defining a Pool<StateV1> and being able to migrate this to a Pool<StateV2> where the UID is the same. This would be an interesting huge pattern for safe versioning.

One security consideration worth mentioning is how this will impact when the ObjectID -> StructTag is inferred onchain.

For example, in our oracle aggregator package we have a function like this

public fun update_price_feed<PriceObject: key>(
    price_feed_storage: &mut PriceFeedStorage,
    config: &Config,
    ...
    price_object: &PriceObject,
    ...
) {
    ...
    let price_feed = /* not relevant */;

    if (price_feed.from() != object::id(price_object)) abort EInvalidSourceObjectForFeed;
    ...
}

For context: a PriceFeedStorage encapsulates a singular symbol and may hold prices from many different sources (Pyth, Stork, etc). When initializing the PriceFeedStorage you need to specify the whitelisted PriceObject that can solely be used to update the price from that source; if you are familiar with Pyth core, this can be a PriceInfoObject.

There is an implicit UID -> type that we define here, as PriceObject is enforced to be a specific type in an upstream package (one for Pyth, one for Stork, etc) and that link is established in the new_price_feed function. This SIP would change the security assumptions of this exact pattern: no longer is the established UID -> type link guaranteed to remain onchain.

In all of our packages, this is the only occurrence of where we (1) hardcode an expected UID + (2) are generic over the type of UID. Almost always it is (1) w/ an explicit type.

All-in-all this would be a nice QoL improvement and unlock some cool patterns.