Challenges of on-chain sector termination notifications for user actors

Here’s a design direction that Zen and I have discussed in detail, but unfortunately doesn’t work.

For user-programmed storage markets and similar applications, it would be nice if sector state changes could be pushed to those actors, so that the actors could rely on those pushes to track relevant changes. E.g. for data D satisfying some deal:

For data being added to a sector, we could have SPs opt in to sending the notifications by specifying the actors to notify. The

For cases were data is removed, it’s not enough to allow the SP to send the notification, they must be forced to send it.

We could record in sector state information about (or a commitment to) which actors were notified about the initial commitment, and hence must be notified about changes. This could be a lot of state, but ignore that for now. Then, whenever an SP changes a sector, we could force them to notify the same parties notified earlier. This works for explicit removal of sector data.

Forced notifications don’t work so well for involuntary events. A sector can be terminated automatically by being faulty for a long period, with no interaction from the SP. The fault and eventual termination are handled by cron. We can’t make calls to untrusted code like user-programmed markets from cron (and would like to minimise use of cron altogether), so can’t send notifications to interested actors.

A promising direction for reducing cron work is to restrict cron to merely checking that the SP has manually performed any required processing. For example we could introduce a “process deadline” method to be invoked explicitly at the end of every proving deadline which includes the logic of faulting partitions that missed Window PoST and terminating long-faulty sectors. Such an explicit call could be forced to send notifications.

The cron handler would then merely check that the deadline has been processed manually by the SP. And if it hasn’t? Enact some cheap-to-enforce penalty like immediately faulting everything in the deadline.

So, to summarise:

The big problem with this is that it boils down to “force the SP to call untrusted user code”. Malicious user-programmed “markets” could consume arbitrary amounts of gas. Not only could be this expensive, but it could exceed the block gas limit, making the message impossible to execute.

This is a risk generally for on-chain notifications but at least, when voluntary, the SP can set appropriate gas limits, and if it all goes wrong can just chose to resubmit and not notify the malicious actor. This might cost them something, but is fundamentally recoverable and limited in scope to interactions with the malicious actor.

But if the core protocol requires the SP to send the notification, a malicious contract can hold the SP at ransom up to the value of whatever the penalty the chain will enforce for not sending the impossible notification.

Even without forced notifications, forced termination handling has a bandwidth challenge. In a disaster scenario, SPs might have many sectors terminating in a short period of time. The chain might not have enough total bandwidth to process all of the terminations within the deadline’s window. Faulting sectors will only make the systemic problem worse, as it would introduce some expensive Window PoST verifications for recovery as further competition for scarce bandwidth, or set more sectors on track for termination.

Even if bandwidth is sufficient, the gas price could be arbitrarily high. Forced termination processing could be a big financial risk to SPs, compounding the cost of any disaster. Gas lanes or an equivalent might help.