Export Sector Status #1220
Open
Export Sector Status #1220
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ZenGround0
requested review from
TippyFlitsUK,
anorth,
dannyob,
jennijuju,
jsoares,
lanzafame,
momack2 and
rvagg
as code owners
jsoares
approved these changes
Dec 7, 2025
Member
jsoares
left a comment
jsoares
left a comment
There was a problem hiding this comment.
Hardly the strongest change motivation section, but seems clear enough.
| <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the FIP.--> | ||
| We propose exporting a new method `validate_sector_status` from the builtin miner actor for creating user space FEVM smart contracts that can check the status of filecoin sectors, either live or dead, on chain. An additional exported method `generate_sector_status_info` can be used in an offchain call to generate inputs to `validate_sector_status`. | ||
|
|
||
| Combined with the recent changes to ProveCommitSectors3 in FIP 109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. |
Member
There was a problem hiding this comment.
Suggested change
| Combined with the recent changes to ProveCommitSectors3 in FIP 109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. | |
| Combined with the recent changes to ProveCommitSectors3 in FIP-0109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. |
| <!--A short (~200 word) description of the technical issue being addressed.--> | ||
| We propose exporting a new method `validate_sector_status` from the builtin miner actor for creating user space FEVM smart contracts that can check the status of filecoin sectors, either live or dead, on chain. An additional exported method `generate_sector_status_info` can be used in an offchain call to generate inputs to `validate_sector_status`. | ||
|
|
||
| Combined with the recent changes to ProveCommitSectors3 in FIP 109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. |
Member
There was a problem hiding this comment.
Suggested change
| Combined with the recent changes to ProveCommitSectors3 in FIP 109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. | |
| Combined with the recent changes to ProveCommitSectors3 in FIP-0109 allowing smart contract notifications upon sector commitent, this FIP establishes a minimally useful interface for a rich set of programmable storage applications. |
|
|
||
| We forwent a similar validating interface pattern with `get_sector_expiration`. This would look like a method that takes in the correct expiration and returns True or False depending on whether the input expiration is correct. This is done for expediency and convenience. The thinking is that this method only ever provides a useful hint anyway as it cannot provide any useful information when handling early terminations. | ||
|
|
||
| We considered including the most current guess of a sectors expiration from `get_sector_expiration` this could be accomplished by providing the sector location and traversing the partition's expiration queue. This would effectively expose a signal of a sector's faultiness which runs counter to our design of `validate_sector_status`. If we want to expose this information we should be consistent and create a new `Fault` sector status value from the enum. |
Member
There was a problem hiding this comment.
Suggested change
| We considered including the most current guess of a sectors expiration from `get_sector_expiration` this could be accomplished by providing the sector location and traversing the partition's expiration queue. This would effectively expose a signal of a sector's faultiness which runs counter to our design of `validate_sector_status`. If we want to expose this information we should be consistent and create a new `Fault` sector status value from the enum. | |
| We considered including the most current guess of a sectors expiration from `get_sector_expiration`, which could be accomplished by providing the sector location and traversing the partition's expiration queue. This would effectively expose a signal of a sector's faultiness which runs counter to our design of `validate_sector_status`. If we want to expose this information we should be consistent and create a new `Fault` sector status value from the enum. |
| a) sector number recorded in the `sectors` bitfield of some `Partition` | ||
| b) sector number NOT recorded in the `terminated` bitfield of the same `Partition` | ||
|
|
||
| Furthermore the separation of the search for the partition and deadline index into the offchain call `generate_sector_status_info` ensures that gas costs and miner state size have no impact on a user's ability to make this call. Hence there is no provide practical denial of service to make the call and condition (1) is satisfied both in principle and in practice. |
Member
There was a problem hiding this comment.
Suggested change
| Furthermore the separation of the search for the partition and deadline index into the offchain call `generate_sector_status_info` ensures that gas costs and miner state size have no impact on a user's ability to make this call. Hence there is no provide practical denial of service to make the call and condition (1) is satisfied both in principle and in practice. | |
| Furthermore the separation of the search for the partition and deadline index into the offchain call `generate_sector_status_info` ensures that gas costs and miner state size have no impact on a user's ability to make this call. Hence there is no denial of service vector and condition (1) is satisfied both in principle and in practice. |
This sentence is broken in at least two ways -- I'm not sure if this is what was meant, so feel free to ignore the suggestion and rewrite as you wish.
lordshashank
reviewed
Dec 8, 2025
|
|
||
| ## Implementation | ||
| <!--The implementations must be completed before any core FIP is given status "Final", but it need not be completed before the FIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> | ||
| WIP builtin actors PR here: https://github.com/filecoin-project/builtin-actors/pull/1707/files |
There was a problem hiding this comment.
Suggested change
| WIP builtin actors PR here: https://github.com/filecoin-project/builtin-actors/pull/1707/files | |
| WIP builtin actors PR here: https://github.com/filecoin-project/builtin-actors/pull/1707 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This FIP is to add a liveness check method to the builtin miner actor to allow for user space fevm contracts to check on the status of filecoin sectors based on sector number.
Still WIP. Will move out of Draft PR when it is ready for review.
Discussion #1108