New FIP: MarketNotifyDeal called by market actor on proposal clients

[ZenGround0]

Summary

Abstractly deal clients interact with PublishStorageDeals in two key ways. (1) they provide a signature to authorize the message. FIP 44 extended the builtin market to open this up to general contracts. (2) they read the return value of the message to learn the deal ID that references their deal. This is not yet opened up to contract clients but I believe it should be.

It's become clear from thinking over more interesting use cases of FIP 44 that knowing the deal ID of a completed deal is useful. This can be achieved with a change to PSD parameters, and an additional optional internal call to the client: MarketNotifyDeal.

Motivation

Looking at the recent additions to builtin market API, they uniformly take a deal ID as input. This is the right design for useability without a complicated redesign and expensive migration. However it means that callers to the market need to know deal IDs.

One interesting user of the contract client functionality, of interest to @irenegia @lucaniz and @nicola, is a perpetual storage contract client. This contract pays out for a bounded number of deals for each cid in its bounty set and internally tracks when these deals end. When deals end the contract will pay out for new deals with the same data. This allows the contract to manage its limited funds to incentive ongoing storage. This currently works with just FIP 44 because the authentication method has access to the deal proposal and so can parse out the end time of the deal and record it.

This all works fine ignoring terminations. However designing against terminations is possible and desirable. In terminology I recently learned from CNL this is the Repair functionality as opposed to the Renew functionality. Repeating an idea of @Kubuxu's: the ideal design of a perpetual storage deal client contract is to lazily determine terminations and expirations when its AuthenticateMessage method is called by the next PSD triggered by a new storage provider. This way we don't need to make additional assumptions about contract operators running management messages against the contract. However without learning the deal ID associated with the deal that satisfied the client contract's CID bounty the client contract cannot reliably know when a deal is terminated. If it does know the deal id it can just call GetDealActivation to learn whether the deal is expired during an authentication check triggered by PSD.

Of course with some additional assumptions this can be made to work. The contract client needs an external caller to provide deal ID which can then be verified by the contract to be for a deal with the correct client, provider, datacid, datasize. But providing this guarantee directly from the market actor powerfully cuts down the complexity of operating a client contract. The only one sending messages doing the internal client repair and renewal management are the SPs storing with the client.

An alternative that seems workable at first is to have the provider publishing the proposal for a repair deal to include the deal ID being repaired in the proposal label. Unfortunately this is thwarted by the market's quick cleanup mechanism. The market will cron up a slashed deal within at most a day and in the worst case one epoch after its termination. After this point there is no way to validate that the deal ID was associated with the right data, client etc. So this approach only works if there is a guarantee that someone will make a new deal within a potentially very short time bound after the termination occurs.

Implementation Details

We would achieve this by adding a new public API call MarketNotifyDeal from market actor to the client contract in the case that a new boolean notify parameter now associated with each deal is set true. This call sends deal ID and serialized proposal to the client address in the deal proposal.

New parameter structure means we would now add a new PSD method that calls the same internal logic as regular PSD with this one parameter difference. This copies the pattern used throughout nv17 actors changes to minimize disruption to network users. Since the parameter would be optional we wouldn't have to have the account actor implement MarketNotifyDeal which would be undesireable since external clients are notified by listening for message receipt return values.

This doesn't require a migration or other changes to market code.

Alternatives

1. We could extend AuthenticateMessage to pass in deal ID but this ruins the abstraction. Less importantly it messes with PSD's internal logic flow so that implementation would be a bit more challenging.
2. We could not do this. Contract clients that want to interact with the market would require an additional caller to provide a deal ID which the contract could then check. Or contract clients could just focus on renewal and do repair only after more powerful interfaces to filecoin storage/deal are opened up.

[arajasek]

EDIT: I see @anorth had the same idea on Slack.

I think this makes sense, I like the motivation -- can we just always "blindly" call MarketNotifyDeal in the hope that it exists? That makes PSD uniformly more expensive, but simplifies the "registering for notification" business.

[ZenGround0]

Looks like great minds think alike. Very nice idea.

[ZenGround0]

Prototyping here, looks pretty noninvasive.

[anorth]

FWIW I'd suggest a new FIP for this. FIP-44 is quite general in nature, this is pretty unrelated except that they both happen to apply to the built-in market actor.

[irenegia]

@ZenGround0 a question:
MarketNotifyDeal will notify and provide the deal_id a sc when a storage deal is published by a provider. Correct?
But at this point the deal is not active yet, it has to go through the activation process (sealing).

How does the smart contract can get this notification too?
Is it feasible to read this info from the state using the deal_id?
Like, GetDealActivation is enough?

[ZenGround0]

Yes the client getting notified, in interesting cases a smart contract, will be able to track the deal id and then associate it with a proposal so that future invocation can check GetDealActivation or other market getters on deal state.