KubuxuNote: Markets is an imprecise word for the component in question, I'm trying out "broker" here, I'm open to suggestions.
Calls passing through a broker
Maintain
Instead of going to the miner actor and then to a broker for deal activation and maintenance, the flow could be through a broker to the miner actor. For example for WindowPoSt, the flow would be calling Maintain on the Broker with the proof as a parameter, this proof gets passed to the miner's Maintain for verification, and if verification is successful (I forgot about optimistic WindowPoSt but the same scheme is possible), the miner gets credited for active deals.
Ideally, the verification was successful is the default happy path and incurs minimal cost. If previous WindowPoSt was missed or sector faults were declared, additional bookkeeping costs can be incurred.
As WindowPoSt verifies a set of ~2300 sectors, in this scheme Maintain on the miner side would be called multiple times as part of single verification with different brokers sharing the same partition. A possible approach to solving that is that the miner actor stores a hash of public inputs for the last (or last-N) successful WindwoPoSt, if Maintain on a miner is called again with the same public inputs, the verification can be skipped.
The broker would also want feedback if WindowPoSt was skipped in the past or faults happened, this can be done by returning a number of faulty proving periods once the WindowPoSt is submitted.
The broker can validate if a given sector still contains deal data by checking if CommR is unchanged. The Maintain call to the miner could allow sending a selected set of them back as part of the return.
I fully expect in the future that a MetaMaintenance actor will emerge which will call Maintain on all relevant brokers with one message.
Onboarding
The same strategy can be applied to onboarding new storage and SnapDeals. The call has to pass through the relevant broker for validation. This would make CommD storage relevant to brokers actors and not relevant to the miner actor.
Direct onboarding is still possible, and it doesn't prevent off-chain deals, but it completely eliminates the necessity of storing CommD as part of the miner actor.
Termination
The termination behaviour in broker can mirror the termination behaviour for the miner (or be more strict), either party to the deal can report it as breaking the contract (the deal wouldn’t be explicitly marked on-chain as faulty but it can be easily computed based on last successful Maintain , and termination should be applied or at least noted if Maintain response from a miner indicates fault period longer than one agreed in the contract.
Immediate termination of the deal is not required as payment processing can be done at the time of payment withdrawal and tooling for checking the status of a deal can be built based on the last successful Maintain and current epoch.
Benefits
Proving ongoing maintenance of storage is much simpler in this case than in the case of calling SubmitWindowPoSt and then relaying that information somehow to the market.
The miner actor doesn’t care about CommD anymore, this responsibility is delated to the broker.
Drawbacks
Increased change complexity and mindset change required