-
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
dex: streamline PositionManager
#4098
Conversation
999c33d
to
d33971e
Compare
// Handle "close-on-fill": automatically flip the position state to "closed" if | ||
// either of the reserves are zero. | ||
if position.close_on_fill { | ||
if position.reserves.r1 == 0u64.into() || position.reserves.r2 == 0u64.into() { | ||
tracing::debug!( | ||
id = ?position.id(), | ||
r1 = ?position.reserves.r1, | ||
r2 = ?position.reserves.r2, | ||
"marking position as closed due to close-on-fill" | ||
); | ||
position.state = position::State::Closed; | ||
} | ||
} |
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.
@erwanor this can be done safely now that we're distinguishing position execution from other position handling
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 looks great, I think we should add a guard just to be paranoid against indexing/validation failures. The reasoning is that the inflation bug was two-pronged: you could create positions with duplicate IDs, and position execution/handling was commingled.
let mut position_1 = SellOrder::parse_str("100gm@1gn")?.into_position(OsRng); | ||
position_1.close_on_fill = true; | ||
let position_2 = SellOrder::parse_str("100gm@1.1gn")?.into_position(OsRng); |
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 much nicer for writing tests than many of the existing methods (which were made prior to this api)
This implements an API suggestion originally made by @cronokirby to expose context-specific methods for updating positions. We maintain a single `put_position` method on the `Inner` trait so that we're able to have a single point where we edit any necessary indexes, but this is now not exposed to callers. Instead they call a scope-specific method that calls `put_position` internally. Currently there's still room to improve the API safety but we'll want to potentially change the signature of `put_position` to ensure that this remains efficient. It would be ideal if it were possible to do all reads up front and concurrently. Further investigation on this point would be desirable. This commit has a security-critical change in that the logic for position withdrawals' balance commitment changes, and it'd be good to get review on that part in particular.
c69ba97
to
01c416a
Compare
|
||
/// Withdraw from a closed position, incrementing its sequence number. | ||
/// | ||
/// Updates the position's reserves and rewards to zero and returns the withdrawn balance. |
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.
It doesn't actually zero the rewards, right?
.reserves | ||
.balance(&metadata.phi.pair) | ||
.commit(Fr::zero()); | ||
let expected_reserves_commitment = actual_reserves.commit(Fr::zero()); |
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.
ACK: I am convinced that this is correct because position_withdraw
returns the withdrawn reserves
This implements an API suggestion originally made by @cronokirby to expose context-specific methods for updating positions.
We maintain a single
put_position
method on theInner
trait so that we'reable to have a single point where we edit any necessary indexes, but this is
now not exposed to callers. Instead they call a scope-specific method that
calls
put_position
internally.Currently there's still room to improve the API safety but we'll want to
potentially change the signature of
put_position
to ensure that this remainsefficient. It would be ideal if it were possible to do all reads up front and
concurrently. Further investigation on this point would be desirable.
This commit has a security-critical change in that the logic for position
withdrawals' balance commitment changes, and it'd be good to get review on that
part in particular.