[AIP-36][Universally Unique Identifiers]

[vusirikala]

AIP Discussion

Summary

This AIP proposes to add a new native function create_uuid in Aptos framework that generates and outputs a unique 256-bit identifier (of type address) for each function call. The create_uuid function calls can run efficiently and in parallel. In other words, when two transactions run create_uuid method, they can be executed in parallel without any conflicts. Initially, we will use these unique identifiers internally as addresses for newly created Move Objects.

Motivation

There is a general need to be able to create unique identifiers or addresses. There is no such utility in Move today, and so various alternatives have been used, which bring performance implications. We want to provide such an utility for all usecases that needed it.

Concretely, when a new object is created, we need to associate it with a unique address. For named objects, we deterministically derive it from the name. But for all other objects, we currently derive it from a GUID (Globally Unique Identifier) that we create on the fly. A GUID consists of a tuple (address, creation_num). We create GUID by having address be the account address of the object or resource’s creator, and the creation_num is the guid sequence number of the object or resource created by that account. As the sequence number creation_num has to be incremented for each object/resource creation, GUID generation is inherently sequential, within the same address. As an example, in Token V2 whenever a new token is minted using token::create_from_account, object is created to back it, which uses GUID generated based on the collection address, and so all such mints from the same collection are inherently sequential.

This AIP thereby creates a new type of identifier called UUID (Universally Unique Identifier). This is a 256-bit identifier that is universally unique amongst all the identifiers generated by all the accounts for all purposes. We propose adding a new native function create_uuid in Aptos framework. Every time a MOVE code calls create_uuid, the function outputs a universally unique 256-bit value.

Read more about it here: https://github.com/aptos-foundation/AIPs/blob/main/aips/aip-36.md

[davidiw]

The following is feedback about the proposal and the written content in the AIP:

• We need to define the user interface in Move. For example, the GUID / UID interface ensures that only the GUID generator can produce GUID structs, whereas anyone can construct UIDs. This is a useful construct that we should maintain. Such that a UUID struct can be generated only by the call into generate within the uuid module, but address is now the public version, maybe?
• Introducing risk and drawbacks of attacks that already exist within the framework we're replacing is distracting and offers little to the discussion. It could be part of a future work section, but this was never a feature we were discussing. Specifically, I don't know why anyone would assume that a UUID is not predictable.
• I don't understand the last paragraph on the replacement. That should be a component of the proposal not a "risk or drawback"

Otherwise looking forward to this!!

[igor-aptos]

@davidiw for the last two points, I think we should keep those nuances in the AIP (and expand based on discussion), but I agree - we should probably move them from "Risks and Drawbacks" portion, and put them into "Caveats" or "Notes" section

For the wrapping of UUID into a struct, we can make the utility function return:

  struct UUID {
    unique_addr: address
  }

but not sure how beneficial that is. if we add get_unique_addr function that returns that field - it's kinda the same? If we require reserialization and hashing like guid does, than it is unnecessarily pessimistic - we take unique addr, and create uniquer address from it :)
Which way were you suggesting, and what would you like the struct to help/clean up?

[davidiw]

Let's assume that in some cases I want to receive the UUID rather than call the UUID generator directly. Without the ability to push, we end up in a very tricky situation, where you need to build trust-based upon the call paths rather than the data type itself. That is, in the name of composability, make these strong, typed interfaces.

[igor-aptos]

agreed, we should have a function that returns UUID and guarantees that no other UUID objects have the same value inside (unless they are copied? should we prevent copying? )

but I think we can keep both functions - that return directly address and that returns UUID (and implement the second one in move), for places that don't need to pass UUID along. do you have concerns for that?

[alnoki]

I understand that assigning these GUIDs is parallelizable, but is there anyway to assign these while incrementing a counter for the number of assignments in parallel?

E.g. in #226 (comment) I asked about using aggregators to assign a parallelizable serial ID and got redirected here, but it's not clear if/how to get parallelizable serial IDs.

Perhaps the solution is to assign GUIDs and then have an aggregator simply track how many have been assigned?