Alex NorthThis note describes an idea for a mechanism of notifying the market actor of faults in deal-bearing sectors that could be extended to other, third-party markets in the future. It builds up by walking through a few alternatives first.
Take discussion to the FIPs repo:
Problem
At present, the market actor doesn’t know about sector faults. Deal payments from clients to providers continue even while a sector is faulty, so long as it is recovered. 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 if we implement the .
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 for .
Solution ideas
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 (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)
Market registrations [best so far]
Rather than a global pubsub, each miner actor maintains a subscription from each market with which it wishes to deal. Thus the provider controls where events will be sent. A market actor is notified about each registration, after which it will accept deals from that provider (the miner code is trusted, network level code).
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