-
Notifications
You must be signed in to change notification settings - Fork 103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[AIP-36][Universally Unique Identifiers] #154
Comments
The following is feedback about the proposal and the written content in the AIP:
Otherwise looking forward to this!! |
@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:
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 :) |
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. |
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? |
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? |
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 havingaddress
be the account address of the object or resource’s creator, and thecreation_num
is the guid sequence number of the object or resource created by that account. As the sequence numbercreation_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 usingtoken::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 callscreate_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
The text was updated successfully, but these errors were encountered: