Skip to content
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

[SDK] Simplify discovery of object history #6529

Closed
amnn opened this issue Dec 2, 2022 · 5 comments
Closed

[SDK] Simplify discovery of object history #6529

amnn opened this issue Dec 2, 2022 · 5 comments

Comments

@amnn
Copy link
Member

amnn commented Dec 2, 2022

Motivation

With lamport timestamps landed in #6163, it is no longer possible to discover the previous version(s) of an object by decrementing its SequenceNumber by one, because a transaction could increase an object's version by more than one. Currently, the only way to know an object's previous version is to look for input objects in the certificate of its owning transaction, (which also does not work for dynamically accessed objects).

Proposal

Add an API to the SDK to get the previous version of an object given its ID and an optional version (which defaults to the latest version).

  • The response from this API will contain the object's previous data, including its previous version, which makes it possible to chain calls to this function to get the object at arbitrary versions.
  • This request can fail if there isn't a previous version of this object in storage -- e.g. if the object was created at that version, or wrapped at its previous version (see also Access wrapped objects by ID outside of Move #5816).

Implementation

There are two ways this could be implemented:

  • In terms of the modified_at_versions in TransactionEffects (e.g. look up the transaction's effects by its digest, find the object's ID in modified_at_versions read the object at that version).
  • By doing a range-based lookup to find the the highest available version less than the provided version.

The second approach is probably more efficient, but both have to watch out for edge cases related to wrapping.

Alternatives

  • Add the object's previous version to Object and ObjectInfo, and always return it in the RPC response.
    • Object and ObjectInfo already contain the TransactionDigest so as long as the getTransaction RPC response returns the modified_at_versions from its effects (it currently does not), always adding the previous version directly to the object response is redundant.
    • These types are used pervasively (including outside the RPC layer), so if the assumption holds that requesting a past object is rare, it is probably not worth adding the previous version here, especially as internally, there are more efficient ways to access that information.
  • Add an API to return an object's entire history.
    • If it's common for people to need to get an object's entire history, this makes sense, but otherwise, it's a lot of work up-front, if people just want to access the immediately previous object.
@amnn amnn changed the title [SDK] Simplify discovery of object history. [SDK] Simplify discovery of object history Dec 2, 2022
@amnn
Copy link
Member Author

amnn commented Dec 2, 2022

@Jordan-Mysten -- does the Explorer (or Wallet) currently relying on being able to decrement an Object's version to get at its history?

@gegaowp
Copy link
Contributor

gegaowp commented Dec 7, 2022

The proposal wrt previous object version looks great, note that sui-core team will soon start pruning historic objects, which makes approach #2 even more efficient.

With pruning, it would be tricky to have object versions of all history but I think that’s a further-out question, I am not aware of a common use-case of this one.

@FrankC01
Copy link

@gegaowp Trace and Audit come to mind as use-cases for the all of object history

@stefan-mysten
Copy link
Contributor

@amnn - is this still relevant? If not, let's close this.

@amnn
Copy link
Member Author

amnn commented Dec 27, 2023

Yes this is still relevant, and will be addressed when we launch RPC 2.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants