-
Notifications
You must be signed in to change notification settings - Fork 43
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
feat(connext): lazy collateralization #1916
Conversation
f8b98d9
to
bab5f81
Compare
I finished adding comprehensive tests across the |
|
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.
Looking very good. Left some minor comments + simulation tests are still failing.
lib/connextclient/ConnextClient.ts
Outdated
// if not start a new request, and when it completes call channelBalance to refresh our inbound capacity | ||
// we don't await this request - instead we allow for "lazy collateralization" to complete since | ||
// we don't expect all orders to be filled at once, we can be patient | ||
const requestCollateralPromise = this.requestCollateralPromises.get(currency) ?? this.sendRequest('/request-collateral', 'POST', { |
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 logic below seems to be the same as the one defined in public checkInboundCapacity
. Can we extract this to a function?
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.
Done.
No, this feature is complementary to the order placing collateralization. For example:
|
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.
Approved but need to fix tests
e1c4924
to
e8f7690
Compare
I finally came up with a way to get the simulation instability tests to pass, as connext payments were inexplicably failing for certain cases. I couldn't figure out why the regular collateral calls on To work around this, I made it so the custom-xud patch code removes the lazy collateral calls logic, and tests are passing now. |
lib/connextclient/ConnextClient.ts
Outdated
}); | ||
|
||
this.requestCollateralPromises.set(currency, requestCollateralPromise); | ||
return from(requestCollateralPromise); |
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.
Maybe we can also remove the above lines and replace it with return from(this.requestCollateralInBackground(currency, minCollateralRequestUnits))
as it seems to be doing the same thing (with extra logging)?
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.
return from(this.requestCollateralInBackground(currency, minCollateralRequestUnits))
doesn't work exactly because requestCollateralInBackground
doesn't return a promise, by design the promise is resolved/handled in the background. I could just call the method and return nothing? that should be fine right?
Shouldn't we find out why these fail though? |
e8f7690
to
c4ef81f
Compare
Yes, I reached out to the connext team and I've spent a lot of time trying to figure it out myself but it's still a myster. I was thinking it could be that payments to a node that is in the middle of recollateralization would fail, but that's not supposed to be the case according to connext. |
This ads functionality to track reserved outboudn & inbound balances each tmie an own order is added to or removed from the order book. Every time an order is added (and reserved amount increases) we check if the inbound capaacity for that currency is sufficient to cover all orders. In Connext's case, if it's not sufficient then we make a collateral request to cover all orders +3% (unless we already have a pending collateral request waiting). We don't do anything on the lnd side since lnd can't dynamically increase its inbound capacity. Closes #1896.
c4ef81f
to
9d34b3a
Compare
This restores the logic to request collateral in the custom xud builds used for instability tests by adding a one second wait after adding an order on the maker side (who then requests collateralization) but before placing a matching order on the taker side. This appears to work around a brief, transient inability to send a connext payment to a node immediately after that node requests collateral. Related PR #1916 - specifically the persistent simulation test failures that were eventually avoided by removing the collateral requests from custom-xud, which is being restored here.
Closes #1896. Branched off of and dependant on #1885. WIP for now but this adds functionality to track reserved outbound & inbound balances each time an own order is added to or removed from the order book. Every time an order is added (and reserved amount increases) we check if the inbound capacity for that currency is sufficient to cover all orders. In Connext's case, if it's not sufficient then we make a collateral request to cover all orders +3% (unless we already have a pending collateral request waiting). We don't do anything on the lnd side since lnd can't dynamically increase its inbound capacity (although we could consider doing something like logging a message).
Related to #1584, which can use the reserved amounts that are being tracked in this PR and expose them over rpc.
Tests still need to be updated to mock the new methods that track reserved amounts and/or add test cases for the reserved amount tracking logic.