Miner->market registrations for fault handling in deal markets

[anorth]

One challenge in implementation of the FIL+ explicit subsidy is that the storage market actor is not aware of sector faults. Deal payments continue to be paid while a sector hosting deals is faulty. While a good debate could be had about whether that is an appropriate policy for deal fees, it is not an appropriate policy for Filecoin Plus verified deal rewards. ​To continue rewards would be more lenient than the current behaviour, where all rewards halt when a sector is faulty (because the verified deal subsidy is represented by storage power, which is removed immediately).

We need a way to notify the market actor about faults so that it can withhold rewards, matching the current behaviour of quality-adjusted power. But we don’t want to privilege the built-in storage market actor with some capability that other markets could not replicate. We generally want to reduce coupling between the two to enable alternative storage market development. The general idea for that is "the miner actor never calls the market actor", but that is very limiting, forcing either inefficient polling or unreliable off-chain actors to propagate the information.

A mechanism to resolve this may be a necessary prerequisite for the FIL+ subsidy protocol change.

FYI @Kubuxu @nicola @ZenGround0 @arajasek

Proposal: market registrations

Rather than talk to a hard-coded built-in storage market actor, each miner actor maintains an explicit subscription from each market with which it wishes to deal. Events such as sector faults are sent to each subscribing market. Thus, the provider controls where events will be sent, which is important since the provider will pay the gas cost of notifications sent as a result of any explicit message.

A market contract can keep track of the subscribed providers, and only accept deals from providers that it knows will inform it of events such as faults (because the miner actor code is trustworthy as a network built-in), and hold pledge as security etc. A market with a policy of paying even through faults need not require subscription (but it will probably not be eligible for FIL+ rewards).

Good:

• Provider controls where notifications are published
• Provider pays cost of publishing notifications to opt-in streams (or cron, only for missed Window PoSt)
• Any market actor could accept a subscription, implement same interface
• Synchronous notification and processing

Bad:

• Cost of publishing events that a market may not care about, including sectors with no deals

Rejected alternatives

Below are some other, less good ideas for comparison

Market checks on sectors with cron

A simple but inefficient idea is for the market actor to check on the state of sectors with cron. If the market actor knew which sectors contained deals (it doesn’t, but could), it could periodically call the miner to check those sectors are healthy. Alternative markets (given access to cron) could do this too.

Good:

• Only incurs cost for sectors that do have deals

Bad:

• Most sectors are ok most of the time, but still pay cost
• Information is delayed by up to the cron interval used (tradeoff with cost of frequent checks)
• Cost paid by the network (cron) rather than providers or clients

Off-chain keepers

Off-chain parties could monitor sector state and inform the market when a deal-bearing sector faults. The market actor could the confirm those sectors’ state. Similarly, a party (probably the provider) would inform the market when the sector recovers. These off-chain parties (”keepers”) would need some incentive to do the work, like a piece of deal provider collateral or client fees.

Good:

• Only incurs costs when sectors actually fault

Bad:

• Delay in detecting and notifying events
• Unreliable when gas fluctuates, may fail in times of high activity
• More complex system to deploy and reason about, includes incentives of keepers

On-chain pubsub

We could create an on-chain publish/subscribe broadcast system, and have miner actors publish sector lifecycle events to it. Markets could subscribe to these event streams. Events might be processed either synchronously, or “async” at the end of each epoch in a cron trigger.

Good:

• Immediate (synchronous, or end of epoch) notification and processing

Bad:

• Open to abuse by actors subscribing to large event streams for free
• Cost of subscriber processing is paid either by publishers who can't control it (synchronous, miners) or the network (async, cron)
• Cost of publishing and receiving events which are of no interest to subscriber (e.g. sectors that a specific market doesn’t have deals for)

[Fatman13]

Could windowPost disputer assume the role of Off-chain keepers?

[anorth]

A WindowPoSt disputer is a type of off-chain keeper, yes. In that case we're moving an expensive computation off-chain entirely, because it almost always has the same result (PoSt OK).

Fault detection/notification is relatively much cheaper, but similarly frequently has the same result (no fault).

[ZenGround0]

This is a good idea. I might be missing something but I think it relies on trusted market code. In general faults (and terminations) will not be triggered outside of cron. So if a malicious market is registered by a malicious miner it could loop indefinitely and DOS cron. For this reason I think we want to wait for Safe Cron to really do this.

We could alternatively push for a VM feature that allows miner cron to call market registree in "safe mode" / "gas measurement mode" that bounds gas to the registered market method. We'll want this for a complete safe cron solution anyway so maybe it makes sense to land in miner cron first.

We could partially implement for DeclareFaults/SubmitWindowPost and TerminateSectors events. Or we could have external parties call the miner and flush notifications but that puts us into off-chain keepers space.