Exposure of Sector Status Method to Smart contracts from Builtin Miner Actor #1108
Replies: 5 comments 18 replies
|
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:
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:
|
|
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? |
|
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". |
|
perfectly stated by @Stebalien , having info around last proven epoch would help in developing payment system around that. 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". |
|
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. |
|
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. |
|
This SGTM |
What is an example of a bad location? |
Im not following this, happy to discuss this sync sometime |
|
One thing id confirm is whether miner softwares like curio saves DataActivationNotification.address for each piece locally, if so it can be used to avoid sending the notification to irrelevant market and cause gas waste (re your "sending the notification to the right contract"). my hunch is curio either can save this or get that info from somewhere; for example with pdp they can get the listeners of their pdp verifier datasets and sign the notification accordingly. SP software has the incentive to support this cuz, without doing something, payment collection/settlement may fail |
I somehow missed this need of Also I was thinking if we can just do it in proveCommitSectors3 and include this in notification callback we get on sector onboarding as of now to just get things started but looking at stats |
FIP-0076 authors spent a decent amount of time trading this off and decided to not store piece manifest in state cuz one may have a lot of pieces in one sector, and miner actor already store a lot of states which makes calls expensive, adding even more sounds suboptimal to me. |
|
Yeah i was not thinking of whole piece manifest, just the notifees, can be done offchain though much care needed on sp software for all this to be done offchain. |
I disagree with this. See stats below. only ~30 out of the 1000+ sp called it ~480 times and not frequently
|
|
i mean yeah not that frequently in that scale but in filfox it shows 5 times in feb so we can't ignore it if one of those SPs have rails as they would not get paid. |
|
@wjmelements does compactSectorNumbers move location too? |
|
No. I believe location can only be changed by |
Uh oh!
There was an error while loading. Please reload this page.
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):
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.
All reactions