Actors as deal clients (FIP-0035) - withdrawn

[anorth]

Update 2022-08: I wish to drop this proposal in favour of #413

The built-in storage market actor does not currently support other actors as deal clients. When the FVM makes user actors possible, I expect a significant use case to be acting as deal clients. Examples might include deals made by a group (multisigs) or more complex DAOs, or deals made by decentralised replication/repair services.

The built-in market's limitation is because it requires a client signature on the deal proposal, and only externally-owned accounts (EOAs) can make signatures. The deal proposal is submitted unilaterally by the provider, but the client's signature confirms their assent. This is efficient in keeping deal negotiation entirely off chain until a proposal is agreed to by both parties, but excludes natively on-chain entities like actors from participating.

This seems on the surface pretty straightforward to resolve, amounting to supporting some limited account abstraction for deal clients. Here's a sketch of a basic solution (all changes to the market actor):

• Add a ProposeDeal method, called by clients (contract or EOA) which records a deal proposal, with the provider, term, cost, piece CID etc in a new PendingDealProposals structure in the market actor state, and returns a proposal ID (sequence number).
• Add a ConfirmDeal method, called by providers, which identifies a pending proposal and elevates it into a full deal proposal, equivalent to if it had been submitted to PublishStorageDeals. The pending proposal is removed.

The pair of calls, one by each party confirming the same proposal, provide equivalent mutual assent to the terms, without needing a signature. This involves slightly more use of chain state in return. Note that where clients are BLS accounts, the total gas use will probably be lower, since BLS signature verification is very expensive; but for the more common SECP signatures, the verification is likely cheaper than storing the pending proposal.

Unlike the current system, a client-side EOA (whoever triggered the contract to propose a deal) would pay part of the gas cost of submitting a deal. Confirming such a deal will be slightly cheaper for a provider than the PublishStorageDeals call.

Some other points of discussion:

• It might be worth generalising the Propose/Confirm calls so that a provider could propose a deal to a client.
• Should we add a RetractDeal method callable by the proposer?
• I haven't addresses garbage collection of pending proposals. An on-chain queue is probably a bit overkill? We could use a page-flipping type thing between two collections, expiring the old page after each fixed time window?
• I can't think of any other pieces of marketplace logic that exclude smart contracts as clients, but if there are any let's find and fix them here too.

This topic is intended for discussion prior to drafting a FIP to implement this in the built-in market actor. Please voice your ideas or concerns here.

Aside
In the future I hope we don't need FIPs for such functionality improvements, because the built-in storage market becomes one of a collection of marketplaces competing on features, cost, etc. Enhancements will be implemented by a contract upgrade rather than network-wide consensus upgrade, and subject to each market's governance process. See #241

cc @nicola @Kubuxu @ZenGround0 @arajasek

[anorth]

It might be worth generalising the Propose/Confirm calls so that a provider could propose a deal to a client

I'm going to go with simplicity for the built-in market, and not generalise this.

Should we add a RetractDeal method callable by the proposer?

Similarly going to go with no for this, until the deal start epoch passes and so the deal expires.

[anorth]

I've drafted a FIP in #305.

Garbage collection uses the existing expiration queue, although this does raise a security concern due to the use of cron. We should put some thought into alternatives and mitigations.

The proposal notes two possible extensions:

• Mechanism to authorise other addresses to offer/claim deals on one's behalf (similar to ERC-20 token authorizations)
• Extension to support deal offers that can be accepted by any provider (i.e. bounties)

It's also worth discussing whether either of those are worth rolling in to the proposal from the outset.

[Kubuxu]

Possible mitigation to the spam issue is to:

• not have a "cleaner" task in cron
• separate the Offer data structure by ClientID (form AMT[abi.DealID]DealProposal to HAMT[ClientID]AMT[abi.DealID]DealProposal)
• add a CleanupOffers([ClientID, RLE]) method callable by anyone to perform a clean-up of stale offers.
  • RLE select DealIDs for scanning, empty RLE signifies that AMT should be iterated whole
  • If a fresh offer is found during the scan, it is left as is, stale offers are removed
  • if the Client's entry within HAMT is empty, delete it

Reasoning:
Offer data structure separated by ClientID means that one client's stale offers do not affect the efficiency of another client (beyond one additional entry in the HAMT, this, in theory, can be spammed)
CleanupOffers is callable by anyone so the chain state can be reduced in case of abandoned clients.
An array of DealIDs can be passed such that it is impossible to brick ClientID by having too many stale offers. In the case of many active offers, it may be beneficial RLE such that scanning of all offers doesn't have to be performed on-chain.

The clients are expected to clean up stale offers after the cost of not cleaning them up (due to an increased gas cost of future offers) is higher than the cost of the cleanup operation.

In case of forgotten or lost ClientIDs, a good samaritan can clean up the state.

[jennijuju]

@anorth The lotus team wanna 👍 up this proposal rather than adding more jobs to the system cron actor. By doing so - in the future, such cron job may be managed by the user defined smart contract.

[anorth]

I've change the FIP to reflect this.

[anorth]

Copying a comment from the draft PR:

The Lotus team wanna strongly propose that the "provider" can be an optional field in the offer as a part of this proposal rather than future improvement/consideration.

[anorth]

We'll have to think about it a bit. The DealProposal type is used off-chain for negotiation, so changing it is high friction (it will need to change later anyway to accomodate #298). We could possibly hack in a sentinel "empty" address rather than make it actually nullable. Or maybe we can use a slightly different type here, and migrate other deals to match it later (tricky because we used CID to check uniqueness).

[anorth]

I think a sentinel address representing "anyone" in the offer is probably the best way to do this. Changing the DealProposal type isn't worth it at the moment. Such a sentinel could be the ID-address of actor ID zero (the system actor), f00? Another could be the address of the market actor itself, f05.

We would also need to add a ProviderID parameter to AcceptStorageDealsParams, since the offer information will no longer necessarily identify the provider.

[Kubuxu]

This way of making open storage contracts will necessitate a bad user experience on the SP side.
Contracts would have to become locked to given SP when PreCommit is posted on-chain, meaning SP already had run PreCommit1/2.
This means that the following chain of events is very much possible:

1. Client posts open deal proposal
2. SP1 signals to the Client that they are interested in storing the data, and they fetch the data and proceed to run PreCommit1/2.
   • It is important to point out that at this point, neither the Client nor the SP1 are obligated to follow through with the deal.
3. Either: Client miss-behaves and gives data to another SP2 who shows interest in storing the data; or SP1 miss-behaves and doesn't post PreCommit on-chain, resulting in the Client giving the data to SP2 who is interested in the deal. SP2 runs PreCommit1/2.
4. Two SPs have run PreCommit1/2, but only one of these PreCommit will result in a sector, resulting in a loss for one of the SPs.
5. Alternative: data is publicly available and SPs rush to be the first to complete a deal, resulting again in loss for N-1 SPs.

In my option, this naive approach of making open storage deals would have little engagement from SPs due to the above.
Another point is that "Actors as Deal Clients" becomes useful whenever user-programmable contracts emerge (FVM M2).
The same event will allow for better ways of making open/bounty storage contracts, some of which we are already discussing and planning to propose and/or grant.

cc @jennijuju

[anorth]

Pending support and approval of the proposal described in #413, I wish to withdraw this proposal from further consideration.