Exposure of Sector Status Method to Smart contracts from Builtin Miner Actor

[lordshashank]

Abstract

We should expose the method somewhat similar to StateSectorExpiration method from the built-in miner actor to smart contracts. This enhancement will enable smart contracts to access sector status information, facilitating the development of decentralized marketplaces around Direct-Data-Onboarding (DDO) and the design of Service Level Agreements (SLAs) and payment structures based on sector duration and early termination.

Motivation

Currently, smart contracts lack direct access to sector status information, limiting their ability to interact with storage-related data. By exposing these methods, developers can create more dynamic and responsive smart contracts that can monitor sector lifecycles, thereby enabling innovative solutions such as automated SLAs and payment systems that account for storage duration and early termination. With DDO, this become more critical as sectors are the only thing to track the status of client data stored by SPs.

Specification

Modify the built-in miner actor to expose the following method to the Filecoin Virtual Machine (FVM):

• GetSectorExpiration: Returns the epoch at which a given sector will expire along with some error code if its teminated.

Rationale

Exposing these methods will provide smart contracts with the necessary tools to access real-time sector status, promoting the development of decentralized applications that can manage and monetize storage more effectively. Given that these are state read methods, they are non-intrusive and should not introduce significant overhead or security risks.

Implementation

The implementation will involve modifying the built-in miner actor code to develop and expose the specified method to the FVM. Testing can be conducted to ensure the methods function as intended within smart contracts.

Security Considerations

As the method is read-only and do not alter state, the security risks are minimal. However, thorough testing can be done to avoid any issue.

[Stebalien]

One tricky part is handling early termination. At the moment, sector terminations update the partition state but don't touch the sector info (because, e.g., they might be processed from cron and we want to minimize the amount of work).

The solution is to either:

1. Provide some "locator" (partition/deadline) information to this method so we can know where the sector is.
2. Ensure that the on-chain sector info is object is removed on termination. E.g., we can do this by removing termination from cron and instead force the SP to handle this in window post (which, IMO, is the best approach anyways). The idea is to remove the "max fault days" logic entirely and rely on incentives. An SP should terminate faulty sectors manually because, at some point (usually very quickly) the fault fees will start exceeding the expected termination fee.

Another tricky part is that, after a sector is terminated, we really don't want to keep any information around regarding this sector. So, at that point, all we'll know is "this sector doesn't exist". Unfortunately, we likely won't know when the sector ceased to exist. We could consider keeping some form of rolling history of sector terminations, but we'd have to carefully consider the cost of doing this.

Finally, none of these address the issue if figuring out the fault status of a sector. If we know the "location" (partition/deadline) of the sector, we can query the faulty status. But otherwise we can't. IMO:

1. We should provide some way to query the faulty status of a sector (proving a way to pass some form of locator metadata).
2. This isn't a high priority. PoRep is all about persistence and not having the data available isn't really an issue as long as it's still there and available most of the time.

[rvagg]

Can we talk through the implications of sector info removal resulting in "no such sector", how bad might that be for the kind of smart contract @lordshashank is describing? If they had to be designed with the assumption that you'd eventually get a result like this, would that present difficulties that would make these contracts significantly less useful?

[Stebalien]

It's useful to know when a sector was terminated and/or when a sector was last successfully proven so we can charge for the period when the sector was live.

On the other hand, it might be sufficient to say "if you're going to terminate a sector, do something on-chain to witness the fact that the sector was live before you terminate it".

[lordshashank]

perfectly stated by @Stebalien , having info around last proven epoch would help in developing payment system around that.
But if maintaining that is too much work or cost, getting something like "sector does not exist" might also work. In contract we can develop a penalizing function for early terminations, incentivizing people to call that and assuming the sector was active until the timestamp of the function call.

For "faulty status" of sectors ( I assume you are referring something similar to StateMinerFaults ), having that might be good but is not critical, we just want a way to handle the case of early termination to maintain SLAs in contract, if not terminated early, ig we can assume everything to be "good".

[anorth]

I concur with @Stebalien that it'll be too expensive/complex for us to maintain any information on chain about sectors which have already been terminated: they'll just be gone.

I also concur that we should fix termination so that it is always done by the miner. Unsure whether it should block this access.

I am a little averse to adding this method to fetch the sector's lifetime because I would like us to move away from sector expiration. Sectors should live ideally forever or, if not, just until the miner decides to terminate them. In that case what we currently call early termination would just be termination. I wrote up a sketch of this here.

So I just don't want future changes like that to be blocked by the fact that we've exposed a method to smart contracts, which now doesn't mean what it used to. If we can document up front some return value that means does not expire, then we can switch all sectors to return that value if we make such a change in the future and clients smart contracts would be on notice to handle it. If we can align on that then I wouldn't object to adding this useful introspection.

[wjmelements]

Can we flip the enum so that Dead is 0?

0 is a default value in the EVM, and sectors are not committed by default, which corresponds to a Dead status.

[wjmelements]

ValidateSectorStatus fails with bad location

What is an example of a bad location?

[wjmelements]

Does this mean sector number and sector location need to match?

GenerateSectorLocation says

This method is designed to be called offline.
It performs an expensive linear search through deadline state of the miner actor to return the deadline index and partition index termed the SectorLocation

Can the sector location change between the invocation of this call and the invocation of ValidateSectorStatus? For example, can compact_partitions move it?

If we want to be able to use ValidateSectorStatus in a FilecoinPay IValidator, the IValidator would have to know the location ahead of time, but it doesn't get this information in the FIP-0109 callback.

When is the sector location determined? Can it change?