[SDK] Simplify discovery of object history

[amnn]

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]

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

[gegaowp]

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]

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

[stefan-mysten]

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