-
Notifications
You must be signed in to change notification settings - Fork 296
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
crypto: rework action-level EffectingData
implementations
#2931
Conversation
For spends, only the body is considered effecting data, so we just hash the proto-encoded body.
For DAO spends, outputs, and deposits, the entire action is considered effecting data.
Note that previously the batch swap output data was _not_ included in the effect hash for the swap claim.
For delegate and undelegate actions, the effecting data should be the entire action. For undelgate claims however, the effecting data should just be the body, thus excluding the proof which is on the undelegate claim action.
The `PositionClose`, `PositionWithdraw`, and `PositionRewardClaim` actions effect hash still hashes the same data - but now first proto-encoded. The `PositionOpen` effect hash is slightly modified. Previously the `PositionOpen` effect hash consisted of: * The reserves R_1 and R_2 * The ID of the position, which is a hash computed from the nonce, asset IDs of the trading pair, the fee, and p and q Now, by using the proto-encoded position, the effect hash includes the: * State, which is an enum determining if the position is opened, closed, claimed, or withdrawn (new) * Reserves R_1 and R_2 * Phi (trading function), which means the fee, p, and q, as well as the trading pair (two asset IDs) * Nonce * A `close_on_fill` boolean indicating if this position is a limit order (new) The `PositionOpen` effect hash no longer includes the ID.
EffectingData
implementationsEffectingData
implementations
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.
Looks straightforward to me; I think we can probably add a helper function for the same 3 repeated lines of logic, would make things a bit cleaner.
Also, one thing I haven't really reviewed is whether or not we haven't missed any relevant structs with this set of changes.
EffectingData
implementationsEffectingData
implementations
b2addcc
to
cdbfac7
Compare
EffectingData
implementationsEffectingData
implementations
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.
LGTM
Towards one of the checkboxes in #2808
Closes #2000
The scope of this PR is to in each
EffectingData
implementation hash a single proto that represents the effecting data of that transaction action.