feat: expose sector status to FEVM #1707

Kubuxu · 2025-11-24T15:26:14Z

split into two methods, generating location and validating the location
location generation is expensive and should happen off-chain
validation is cheap, and returns Active/Terminated
status of expired sectors cannot be shown

Early review welcomed, FIP is going to be next.

Implement methods for generating and validating sector status information. This comes with a drawback that after expiry, the state becomes impossible to present. Signed-off-by: Jakub Sztandera <oss@kubuxu.com>

Signed-off-by: Jakub Sztandera <oss@kubuxu.com>

BigLep · 2025-11-24T17:48:39Z

@Kubuxu : I assume this relates to filecoin-project/FIPs#1108 ?

Kubuxu · 2025-11-24T21:49:09Z

Yes

ZenGround0

I like the separation into an offchain location generating call and an onchain lookup call.

Unfortunately this doesn't work as intended because terminated bitfield can be mutated during cleanup.

There are a lot of possible approaches. At the top level its a matter of decided whether to add in an immutable record of terminated sector numbers or to work around information loss. I'm going to spend some time reading up on @lordshashank's previous design which probably has a proposal for addressing this.

ZenGround0 · 2025-11-25T18:53:12Z

actors/miner/src/lib.rs

+        let current_status = if partition.terminated.get(params.sector_number) {
+            SectorStatusCode::Terminated
+        } else {
+            SectorStatusCode::Active // Includes faulty sectors


nit: we use the term Live within code for a sector that is !Terminated. It may make sense to use this teriminology instead.

ZenGround0 · 2025-11-25T18:55:54Z

actors/miner/src/lib.rs

+        let partition = deadline.load_partition(rt.store(), partition_idx)?;
+
+        // Determine status
+        let current_status = if partition.terminated.get(params.sector_number) {


Unfortunately this general approach does not work for the simple reason that partition.terminated is not immutable. It can get cleaned up during compact_partitions. See miner actor and deadline state code.

In the case of a cleaned up terminated sector we are going to get a failure from find_sector call above (sector <params.sector_number> not due at any deadline)

That is fine, I think. What we really care about is showing that the sector is Live. We could even hide the terminated state. What do you think?

A clear problem I see with the info loss of today is that we proof of non-existence is very expensive. So if we live with loss of information we'd basically need to move the interface to be proof of liveness which can succeed or fail. And no way to prove Terminatedness

Which IMO is fine, Filecoin L1 administers and manages that the sectors are stored and repeatedly proven.
Then we use this to unlock funds on FEVM.

Well actually we could do a sector number based check very cheaply by just going to the AMT. It is a bit rougher to do both but maybe not that bad. We can assign "No deadline No partition" to sectors that are fully removed / never added from/to the system

Since there's an invariant that all sectors in a partition are also in the AMT

Well actually we could do a sector number based check very cheaply by just going to the AMT.

what do you mean? Which AMT? We don't have mapping of sectorId->(deadline, partition), and we need that to check whether the sector has been terminated, and without being able to check that the sector hasn't been terminated, we can't assign it a Live state.

So the liveness check to me, narrows down to: "Exists in deadline and is not terminated in it"

we talked offline but for anyone follwoing along AMT meaning sectors AMT. We agreed that isDead is possible to prove quickly by either providing (partition,deadline) and demonstrating sector number is in terminated bitfield OR attempting to search in sectors AMT and coming back with a not found error

@Kubuxu is leaning towards only including isLive and not isDead in the interface for practical reasons which is ok with me.

ZenGround0 · 2025-11-25T19:03:22Z

@lordshashank I can't tag you for review directly so pinging you in comments.

Kubuxu · 2025-11-25T19:28:36Z

@ZenGround0 should I narrow it down to IsSectorLive or something like that? Seems like it would resolve the issues.
I don't think we can provide NotAlive, as someone might provide the wrong location.

Unfortunately this doesn't work as intended because terminated bitfield can be mutated during cleanup.

This is fine, they generate a new location and re-submit it if it is still alive, and if it is terminated, they no longer can show Alive proof. Which is why I'm thinking about hiding the Terminated state.
Thinking about it, this is the conclusion I came to a year ago when thinking about it last.

lordshashank · 2025-11-25T21:15:07Z

this is ok but imo if we can do something like wether sector was active on particular epoch or not somehow, it would be better.
Even if we consider Filecoin pay. we settle rails based on epoch, if we want to pay SPs through rails we would need to know if the sector was active until that particular epoch or not to settle correctly. Having just isSectorLive just checks if sector has not been terminated or not, which means miner needs to keep settling recurringly and lose payments after the last settle. I was trying to not put that compulsion on miner.

Kubuxu · 2025-11-26T15:05:49Z

Miner controls when the sector ends (either through expiration or termination).
The alternative is to put the complexity on the client or have checker participants, but that increases complexity even further.

ZenGround0 · 2025-12-03T05:50:38Z

I am also thinking the benefits of including expiration are limited since any consuming contract is going to need to handle the case where GetExpiration fails upon early termination. However I don't have any problem including an additional GetExpiration wrapper method which returns an expiration iff sector is live and fails if sector is dead.

beck-8 · 2025-12-06T06:53:18Z

I would like to ask an extreme case, SP can currently generate 40 days + fault sectors, does that mean that rails has been paying for downed services for 40 days continuously, which is as expected?

Should faulty sectors be exposed to contracts?

Kubuxu added 2 commits November 24, 2025 12:13

feat: add sector status info methods

eca80bb

Implement methods for generating and validating sector status information. This comes with a drawback that after expiry, the state becomes impossible to present. Signed-off-by: Jakub Sztandera <oss@kubuxu.com>

tests: sector status

12adec3

Signed-off-by: Jakub Sztandera <oss@kubuxu.com>

github-project-automation bot added this to FilOz Nov 24, 2025

github-project-automation bot moved this to 📌 Triage in FilOz Nov 24, 2025

appease the lint gods

6b01ef1

Signed-off-by: Jakub Sztandera <oss@kubuxu.com>

Kubuxu requested a review from ZenGround0 November 25, 2025 16:10

rjan90 requested a review from sudo-shashank November 25, 2025 16:10

ZenGround0 requested changes Nov 25, 2025

View reviewed changes

github-project-automation bot moved this from 📌 Triage to ⌨️ In Progress in FilOz Nov 25, 2025

ZenGround0 removed the request for review from sudo-shashank November 25, 2025 19:02

BigLep assigned Kubuxu Dec 1, 2025

feat: expose sector status to FEVM #1707

Are you sure you want to change the base?

feat: expose sector status to FEVM #1707

Conversation

Kubuxu commented Nov 24, 2025

Uh oh!

BigLep commented Nov 24, 2025

Uh oh!

Kubuxu commented Nov 24, 2025

Uh oh!

ZenGround0 left a comment

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kubuxu Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kubuxu Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

Kubuxu Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Kubuxu Nov 25, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 Nov 26, 2025

Choose a reason for hiding this comment

Uh oh!

ZenGround0 commented Nov 25, 2025

Uh oh!

Kubuxu commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lordshashank commented Nov 25, 2025

Uh oh!

Kubuxu commented Nov 26, 2025

Uh oh!

ZenGround0 commented Dec 3, 2025

Uh oh!

beck-8 commented Dec 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ZenGround0 Nov 25, 2025 •

edited

Loading

ZenGround0 Nov 25, 2025 •

edited

Loading

Kubuxu Nov 25, 2025 •

edited

Loading

Kubuxu commented Nov 25, 2025 •

edited

Loading

beck-8 commented Dec 6, 2025 •

edited

Loading