-
Notifications
You must be signed in to change notification settings - Fork 302
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
proto: add extra metadata fields to SwapView.Opaque
#4164
Conversation
Many of the "opaque" variants of our view messages don't have any extra data other than the raw action. This turns out to be insufficient, because often there's additional data that's practically necessary to understand the public parts of the action. For instance, in this case, the `SwapView`, we want to correctly and nicely render the public parts of the swap, which include: - the input amounts, which are transparent; - the pro-rata output amounts, which are computable given public information. However, this information can't be easily rendered just from the underlying `Swap`, because: - it doesn't contain the asset `Metadata` about the values, only the amount and asset IDs; - it doesn't contain the `BatchSwapOutputData` with the (public) results of the batch swap; - it doesn't have precomputed output values, so the rendering would have to understand and replicate the pro-rata computations. Instead, we should make use of the perspective/view mechanism to augment the `SwapView.Opaque` with that data. To complete this PR, we'll need to: - [ ] Regenerate protos and fix any compile errors in the Rust code. - [ ] Ensure that the tx+perspective => view transformation uses data from the perspective to fill in the new fields (this should be similar to the existing code, but for opaque swaps rather than just visible ones). The web frontend's code for displaying simulated "public views" of the user's transactions can probably make use of this functionality after the first step (since it constructs the simulated view by attenuating the "full view" rather than by regenerating with a fresh perspective), but we should fill in the perspective generation for completeness and to ensure that the data we're adding actually makes sense and is possible to generate from the perspective.
Met with @/jessepinho to discuss this changeset - the work seems straightforward & we will revisit once the initial proto/perspective generation changes are made, but these proposed changes seem straightforward to consume on the web side, as expected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One main concern about how outputs are calculated. I think someone else will have to advise on how to do that, though — or if it's even possible!
da319a6
to
045d6a0
Compare
045d6a0
to
b288996
Compare
this removes a todo comment asking a question. > Not finding a BSOD in the TxP means that whoever generated the > transaction perspective didn't include that data, either because they > didn't have it (eg the transaction was created but never confirmed by > the chain and executed) or because they didn't support it in their > implementation. > > We should handle that by graceful degradation, just not rendering the > BSOD-requiring data if we don't have it. \- #4164 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is great work @aubrika! this PR looks good to me.
this removes a todo comment asking a question. > Not finding a BSOD in the TxP means that whoever generated the > transaction perspective didn't include that data, either because they > didn't have it (eg the transaction was created but never confirmed by > the chain and executed) or because they didn't support it in their > implementation. > > We should handle that by graceful degradation, just not rendering the > BSOD-requiring data if we don't have it. \- #4164 (comment)
Many of the "opaque" variants of our view messages don't have any extra data other than the raw action. This turns out to be insufficient, because often there's additional data that's practically necessary to understand the public parts of the action.
For instance, in this case, the
SwapView
, we want to correctly and nicely render the public parts of the swap, which include:However, this information can't be easily rendered just from the underlying
Swap
, because:Metadata
about the values, only the amount and asset IDs;BatchSwapOutputData
with the (public) results of the batch swap;Instead, we should make use of the perspective/view mechanism to augment the
SwapView.Opaque
with that data.To complete this PR, we'll need to:
The web frontend's code for displaying simulated "public views" of the user's transactions can probably make use of this functionality after the first step (since it constructs the simulated view by attenuating the "full view" rather than by regenerating with a fresh perspective), but we should fill in the perspective generation for completeness and to ensure that the data we're adding actually makes sense and is possible to generate from the perspective.
Checklist before requesting a review
If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason: