Refine deal protocol and lotus-miner

Goal

• reworking deal proposal protocol to enable the protocol allows client to be a smart contract
• explore, prototype and productize a solution for data onboarding softwares to support future user-programmable markets that allow contract as a verified client (with datacap)
• alternative solution discoveries see here
• for this milestone, we will
• prototype in go-fil-market, lotus-miner
• assume storage ask for verified deal with be 0

Challenge

• Current deal making follow includes the following steps
1. client queries SP’s ask
2. when agree, client sends SP a ClientDealProposal that includes Proposal and ClientSignature
3. if SP wanna accept the ClientDealProposal, SP will then signs and publish a PublishStorageDeals that includes the ClientDealProposal
4. The ClientSignature is validated when validating the PublishStorageDeals signature
• The challenge is, smart contracts can’t sign a message like regular accounts(bls or secp256k1), therefore we have introduced an FIP for introducing a stand AuthendicateMessage method for actors. We need to find a way to allow clients to send that authentication to storage provider, and be able to validate that in market when the PublishStorageDeals lands.

Alternative Solutions

Option A

@ToBeRemoved / @jennijuju

Workflow can be like:

• deploy a client contract in wallaby
• the client contract successfully gets datacap token
• using lotus client deal or similar , client contract sends a deal proposal (price = 0) to an SP
• SP receives and publish the storage deal to builtin storage actor
• the deal is then packed in an sector, and the sector is fully committed with the deal to be activate

Option B

@

• deploy a client contract
• client contract gets datacap
• client contract announces the availability of deals (CommP/size pairs and terms)
• SP creates a deal on its own listing the contract as a client using FIP-0044 (make sure that deal and message are domain-separated), the Authenticate method would only accept the deal if it matches announced deals
• How does SP create deal on its own?
• Offline deal flow?
• The SP has to get the data from somewhere but the deal itself can be created locally
• This is in essence bounty contract with datacap as payment
• Hmm, allocations have to be created as well, Authenticate to the rescue again; Ahh no, the market will create allocations
• the SP onboards the deal as any other, the client “signature” on the deal (there is no signature) validates thanks to the Authenticate method on the client contract

Proposed Flow (for demo purpose)

1. ✅dataDAO operator deploys a client contract
2. ✅the client contract gets the datacap

• Note: for the application to work on mainnet, we need to make sure the FIL+ program will support dataDAO contract to be a verified client.
• working with FIL+ here to make sure its possible
• test FIL+ application here

3. ✅dataDAO operator will add the piece CID to the contract
4. the contract will emit an event that has the necessary deal proposal information
5. lotus-miner will subscribe to the event and get the deal information
6. lotus-miner will have a cli to get the deals from the event database, make sure we have the data locally, and publish the storage deals
1. Note: we are also assuming all the deals are free and verified deal at this stage
2. We are also handling the deal-making locally within lotus miner, by passing the go-fil-market fsm as its not necessary/dont have to be that complicated at this stage for our use case
7. ✅the PSD message will call the client contract to authenticate the deal
8. once the PSD lands on chain successfully, we will add the data to a sector and make the deal sealed and fully activated onchain

Deliverable Date

Dec 16th: aim to ship the updated and working protocols, software needed for client contracts during early stage of Space Warp so that application developers can take the examples to build their own DataDao like use-case

Dec 17th - Jan 11th: get developer feedbacks for bug reports/future enhancement and bring prototype to production

above deliverable date was postponed due to the support request for FEVM

Deliverables by Feb 1st

• A client contract that's a verified client, holds a list of CIDs to store and emits events that contain deal proposal information
• A lotus release contains the tooling for an SP to subscribe to the contract and make the deal, and seal the deal (new sector or snap) fully unchain, and have the deal activated.
• This solution can be run in hyperspace, if there is a way for developers to signal f8 on how to get the data thats to be stored via DataDAO.
• A E2E demo/workshop video on lotus YouTube channel.

🚢Shipped

Coming soon..