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

dex: streamline PositionManager #4098

Merged
merged 5 commits into from
Mar 26, 2024
Merged

Conversation

hdevalence
Copy link
Member

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.

Comment on lines +207 to +219
// 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;
}
}
Copy link
Member Author

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

Copy link
Member

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.

Comment on lines +271 to +273
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);
Copy link
Member Author

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.
@hdevalence hdevalence force-pushed the dex-positionmanager-streamline branch from c69ba97 to 01c416a Compare March 26, 2024 05:59
@hdevalence hdevalence marked this pull request as ready for review March 26, 2024 06:00
@erwanor erwanor self-requested a review March 26, 2024 11:51

/// Withdraw from a closed position, incrementing its sequence number.
///
/// Updates the position's reserves and rewards to zero and returns the withdrawn balance.
Copy link
Member

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());
Copy link
Member

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

@cratelyn cratelyn added this to the Sprint 3 milestone Mar 26, 2024
@cratelyn cratelyn added the A-dex Area: Relates to the dex label Mar 26, 2024
@conorsch conorsch merged commit 2058857 into main Mar 26, 2024
7 checks passed
@conorsch conorsch deleted the dex-positionmanager-streamline branch March 26, 2024 18:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dex Area: Relates to the dex
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

4 participants