-
Notifications
You must be signed in to change notification settings - Fork 11.2k
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
Explorer: Amount field for transferring coin #3992
Comments
potentially leverage the events |
I think the inability to look at historical state without re-execution is a broader problem that might merit a broader solution. One fairly simple one is to support an optional |
This doesn't mean we shouldn't also look at adding |
The proposal is to expose the |
@666lcz @sblackshear a couple quick questions and then comments:
@sblackshear as far as inspecting historical state, you mean historical objects right? My long term plan is to include historical objects at the minimum at epoch boundaries, but ideally we can optionally carry the initial objects at the beginning of every checkpoint. Otherwise, when our TPS goes up, it will become impossible for anybody who is behind or new to catch up. In the meantime, we are keeping older object versions and we don;'t have a purge policy yet. We can certainly have a policy that keeps a specified number of versions or some other criteria. |
Transfer amount is only available for
@velvia I am surprised to learn that Move transfers does not emit a |
@velvia nice, do you have a code pointer of how to fetch object by a version number? We can then add an optional |
@sblackshear @666lcz currently we do keep historical objects. It's in the In terms of confusion, to start, we only show amount for Sui objects by parsing them when generating events on FullNode. For non-Sui objects, it will be expensive to have parse all of their contents (structure may be complicated) and extract the amount on the node side. But we can add |
@666lcz basically what @longbowlu said... we do emit |
The
The |
PR is out for Sui backend change: #4328 it only implements the partial TransferSui amount for now. |
The only tricky thing is that we would need to deserialize the object, just as Lu said. So we can match the object and if it comes from the Coin module then we deserialize it and get the amount field out, is that right? |
@velvia yes we probably can do that by looking into its |
@sblackshear @velvia My concern for opening up a public API on the fullnode that allows for querying a historic version of an object is that, people might depend on it and expect it to work to a certain degree. It's difficult to define for how long we can keep historic object versions. For example, it is difficult to prune object state at epoch boundaries, because we simply don't have a good way to tell which object versions are older than the current epoch. We also cannot promise to keep objects for X versions, if we ever consider using lamport versions (which we will very likely given the dynamic child object loading work). I am also curious about the application: is there a similar use case from other chains? (e.g. be able to show account state from X transactions earlier) |
yes and I can finish my design for this if needed. :)
I agree we have no guarantees on how long we keep stuff, nor should we. I agree with the concern. Maybe we should sketch out the requirements for something like older object lookup more thoroughly and then we can reassess. Broadly speaking, the more successful Sui becomes, the harder it will be to keep any number of older versions (other than for bulk node state syncing, for example). |
PR is merged. |
Figure out if it is possible to derive and store an
amount
field in transaction effects if:TransferObject
transaction where the object is aCoin
TransferSui
transaction, where the amount is not specified.The text was updated successfully, but these errors were encountered: