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

Introduce stateless offline dealflow, bypassing the FSM/deallists #5961

Merged
merged 7 commits into from
May 17, 2021

Conversation

ribasushi
Copy link
Collaborator

( read diff under -w )

This is aproposal for an additional flag --manual-stateless-deal and a
corresponding API endpoint ClientStatelessDeal. This allows firing off
an offline-style deal against a miner without keeping further track of
it locally.

Not keeping any local state introduces the limitation of requiring free
storage deals, as there is nothing to tie the payment channel setup to.

Rationale/need for this type of flow is the case of incredibly large
sets of data nd deals, where the client and providers have prearranged
payment ahead of time, and the client has a separate-from-lotus database
of deal inventory. This way the client can use their lotus node merely
as a network gateway, without running into any limitations currently
present in both lotus as a whole and go-fil-markets in particular.

Specific context for this work is filecoin-discover, where the requirement
is to onboard ~ 12,000,000 individual deals against a pool of miners
with whom the client has prearranged a relationship.

This is aproposal for an additional flag --manual-stateless-deal and a
corresponding API endpoint ClientStatelessDeal. This allows firing off
an offline-style deal against a miner without keeping further track of
it locally.

Not keeping any local state introduces the limitation of requiring free
storage deals, as there is nothing to tie the payment channel setup to.

Rationale/need for this type of flow is the case of incredibly large
sets of data nd deals, where the client and providers have prearranged
payment ahead of time, and the client has a separate-from-lotus database
of deal inventory. This way the client can use their lotus node merely
as a network gateway, without running into any limitations currently
present in both lotus as a whole and go-fil-markets in particular.

Specific context for this work is filecoin-discover, where the requirement
is to onboard ~ 12,000,000 individual deals against a pool of miners
with whom the client has prearranged a relationship.
Copy link
Contributor

@magik6k magik6k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs make gen

@momack2 momack2 requested a review from magik6k April 12, 2021 20:34
@BigLep
Copy link
Member

BigLep commented Apr 12, 2021

Are there any additional tests we should be adding? During w3dt project leads meeting, I saw @raulk post that we should have a testground test that stresses this path.

@ribasushi
Copy link
Collaborator Author

Mmmmm this codepath shuts off pretty much all of client lotus, reducing everything to a single fire-and-forget libp2p message: there's nothing to stress.

Stress testing would be required on the miner side, since we can't do the same "short circuit" there. But that's a way larger endeavor for which a lot of ignite-like domain knowledge is required.

That said, a basic test can't hurt, provided there is interest in this functionality in core lotus the first place.

@pooja
Copy link
Contributor

pooja commented Apr 30, 2021

Hey team! Now that we're post-upgrade (congrats!!), wanted to check in on this PR again -- cc @magik6k @BigLep would you mind taking a look and merging if it looks ok?

node/impl/client/client.go Outdated Show resolved Hide resolved
@BigLep
Copy link
Member

BigLep commented May 3, 2021

@pooja : we missed talking about this during triage. It was a truncated session and Magik is also out this week and next.

Can this wait until his return or does it need to get done sooner? I'm bummed that we have PRs open for so long (not good). The team is also being asked to make Lotus 1.10 (with FIP8/13 integration) the top priority.

@ribasushi ribasushi requested a review from arajasek as a code owner May 6, 2021 13:57
@ribasushi
Copy link
Collaborator Author

@BigLep rebased/updated for master / apiv1

Copy link
Contributor

@arajasek arajasek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems reasonable to me. Have we / can we manually test out the flow (assuming the testground test isn't happening)?

That's probably the easiest way to have enough confidence to ship.

cli/client.go Outdated Show resolved Hide resolved
node/impl/client/client.go Outdated Show resolved Hide resolved
@ribasushi
Copy link
Collaborator Author

Have we / can we manually test out the flow

@arajasek I have been using this on mainnet / in production since I opened the PR, so it has about a month of mileage now.

@arajasek
Copy link
Contributor

Have we / can we manually test out the flow

@arajasek I have been using this on mainnet / in production since I opened the PR, so it has about a month of mileage now.

That's all I need to hear :)

@arajasek arajasek merged commit 9a6e601 into master May 17, 2021
@arajasek arajasek deleted the feat/stateless-offline-dealflow branch May 17, 2021 16:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants