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

proto: add extra metadata fields to SwapView.Opaque #4164

Merged
merged 4 commits into from
Apr 23, 2024

Conversation

hdevalence
Copy link
Member

@hdevalence hdevalence commented Apr 5, 2024

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.

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:

    This is only a change to the client-side view code.

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.
@hdevalence
Copy link
Member Author

cc @aubrika @jessepinho

@cratelyn cratelyn added this to the Sprint 4 milestone Apr 8, 2024
@cratelyn cratelyn added the protobuf-changes Makes changes to the protobuf definitions. label Apr 8, 2024
@aubrika aubrika self-assigned this Apr 8, 2024
@aubrika
Copy link
Contributor

aubrika commented Apr 9, 2024

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.

@aubrika aubrika requested a review from jessepinho April 10, 2024 19:36
@aubrika aubrika marked this pull request as ready for review April 10, 2024 19:36
Copy link
Contributor

@jessepinho jessepinho left a 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!

crates/core/transaction/src/is_action.rs Show resolved Hide resolved
crates/core/transaction/src/is_action.rs Outdated Show resolved Hide resolved
@aubrika aubrika force-pushed the swap-view-opaque-data branch from 045d6a0 to b288996 Compare April 11, 2024 21:33
@cratelyn cratelyn self-requested a review April 22, 2024 18:32
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)
Copy link
Contributor

@cratelyn cratelyn left a 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.

@cratelyn cratelyn modified the milestones: Sprint 4, Sprint 5 Apr 22, 2024
@aubrika aubrika merged commit 2bec50c into main Apr 23, 2024
8 checks passed
@aubrika aubrika deleted the swap-view-opaque-data branch April 23, 2024 16:41
erwanor pushed a commit that referenced this pull request Apr 24, 2024
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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protobuf-changes Makes changes to the protobuf definitions.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants