-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIPXXXX: Introducing sealerID #993
base: master
Are you sure you want to change the base?
Conversation
This proposal introduced the sealerID. This is a new identifier created for parties that participate to the Filecoin network by creating replicas, which can then transferred to SPs. This fully enables the Sealing-as-a-Service scenario already introduced in FIP0090 (NI-PoRep). Discussion: #890
FIPS/fip-xxx-sealerid.md
Outdated
2. The list of SealerIDs is disjoint from the MinerID list | ||
3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer); | ||
1. ie, the actor needs `SectorNumber` facilities. | ||
3. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If NI PoRep were accepted and shipped in an upgrade first, we will need to add a new method, ProveCommitSectorsNI2, for this change, given this is a breaking change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this "fully enables" NI-Porep, does this make it worth considering folding this into that FIP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
However we organize the FIPS I think it would be ideal to land both at the same time
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ZenGround0 we are planning to ship NI-PoRep in nv23, but I don't think sealearID can make for it, unless we prioritise it now (fine with me)... what's your opinion on this?
cc @rjan90
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I would prefer we ship them together so we can maintain the momentum from NI Porep and immediately unlock sealing as a service. But I don't know if filoz has the capacity to get both done on time.
FIPS/fip-xxx-sealerid.md
Outdated
4. [Access control, needed to avoid front-run attacks] | ||
5. Store in the Sealer Actor another address: this is an address to a proxy contract that can be used to implement ACL | ||
|
||
When an SP onboards a sector (ie, call to method `ProveCommitSectorsNIParams` in the Miner Actor), then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the plan to ship an FRC for this hook/interface as well..?
Editor: I think we will need a bit more spec design work to do before it can be merged😄 would recommend to turn this FIP into a draft PR until them |
Co-authored-by: Jiaying Wang <[email protected]>
FIPS/fip-xxx-sealerid.md
Outdated
1. We add a new type of actor: the Sealer Actor (to be used for SaaS Providers); | ||
1. This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; | ||
2. Add the method to create and register `SealerID` | ||
2. The list of SealerIDs is disjoint from the MinerID list |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As I understand it the SealerActor type should be a multiple instance type. Anyone can create a SealerActor and SealerID will simply be the actor ID. This ensures SealerIDs are disjoin from MinerIDs. If we wanted a singleton actor it would become quite difficult to ensure they are disjoint.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, no singleton actor. We should go with the two separate actors. I'll update the spec with the details you suggested here 🙏 .
FIPS/fip-xxx-sealerid.md
Outdated
1. This can be a “disposable” actor, no need for an owner key. If something bad happens, create a new id. This is okay because no tokens are locked for this actor; | ||
2. Add the method to create and register `SealerID` | ||
2. The list of SealerIDs is disjoint from the MinerID list | ||
3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Concretely this sector number list would be a bitfield as is the case in the miner actor.
FIPS/fip-xxx-sealerid.md
Outdated
3. Add a new map `SealerID -> [SectorNumber]` to the chain state (that is, we have a list of used sector numbers for each sealer); | ||
1. ie, the actor needs `SectorNumber` facilities. | ||
3. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . | ||
4. Add the `SealerID` field to `SectorNIActivactionInfo` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note we'll also need to add SealerSectorNumber
to the activation info as this will generally need to be separately declared from the miner actor's sector number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could use CBOR -1 or some well defined value <= current actor id to indicate EMPTY_SEALER_ID. SealerSectorNumber could either be ignored or enforced to be 0 if we have the EMPTY_SEALER_ID case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or alternatively we could enforce SealerID is explicitly set as minerID in the empty case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If these are disjoint sets, your recent post would make the proposal simpler to code and verify: struct{sealerID, sectorNumber} would be a unique identifier, replacing struct{minerID, sectorNumber}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 I agree with {sealerID, sectorNumber} for replica ID info. Annoyingly replica ID sector number and miner metadata sectorNumber will be different so we do have to handle that. Probably with {minerID, sectorNumber, minerSectorNumber} where last value can be -1.
5. Store in the Sealer Actor another address: this is an address to a proxy contract that can be used to implement ACL | ||
|
||
When an SP onboards a sector (ie, call to method `ProveCommitSectorsNIParams` in the Miner Actor), then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An idea from @jennijuju: One design direction to consider is making the SealerActor an Fevm actor. We could do this by writing a user contract that enforces sector numbers are only claimed once. Then when calling sealer id from miner actor we check that we are 1) calling evm actor 2) the bytecode of the evm actor matches the expected contract.
Reasons for and against are pretty split so I don't know which to advocate for.
Reasons FOR
- Take advantage of solidity development tooling
- Less actor bundle overhead
- No migration overhead
- We can deploy and test out the contract before the upgrade
Reasons AGAINST
- Performance might suffer
- Probably a bit harder to develop for our team. Less copy past of rust code, more learning new stuff. Not in builtin actors repository. Miss out on builtin actors testing framework.
- Finding/building a performant analogue to the bitfield data type in solidity might be too much
@anorth @Kubuxu @Stebalien any thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moved design question to #890 (comment) so it’s more discoverable and trackable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it seems to me that the conclusion here is to go with the original proposed design (sealer id in actor code and all other feature, as for example the ACL, in FEVM)
#890 (reply in thread)
|
||
|
||
## Backwards Compatibility | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking into the use of prover_id and sector_number by the window post circuit. I think that these values do not need to match the prover_id and sector_number used by sealing as they are used for challenge generation independent of the sealing process.
However if these values do need to be the same across sealing and post we will have to change miner actor state to keep around enough information to reconstruct the sealer id and sector number.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any other instances where we need the inputs to the ReplicaID (original sector number and prover id) after commiting a sector? Are there any reasons we might want these in the future? If so it is important to identify them so we can make sure we have enough information in the miner actor state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking into the use of prover_id and sector_number by the window post circuit. I think that these values do not need to match the prover_id and sector_number used by sealing as they are used for challenge generation independent of the sealing process
Correct, they do not need to match.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any other instances where we need the inputs to the ReplicaID (original sector number and prover id) after commiting a sector?
@lucaniz and I checked for this, we did not find any
Are there any reasons we might want these in the future?
Nothing that come to mind to me now :)
added some spec details
Co-authored-by: Rod Vagg <[email protected]>
Co-authored-by: Rod Vagg <[email protected]>
2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . | ||
- Add a new field to `SectorNIActivationInfo` for passing the `SealerID`: | ||
- if empty, use the the minerID when creating the `ReplicaID` | ||
- if a value is passed, use this for `ReplicaID` (in the place of `minerID`) | ||
- Add a new field to `SectorNIActivationInfo` for passing `SealerSectorNumber`: | ||
- again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; | ||
- note that the miner actor identifies sectors internally using a `SectorID` structure with a `{minerID, sectorNumber}` pair. This is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2. Modify the method `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID` . | |
- Add a new field to `SectorNIActivationInfo` for passing the `SealerID`: | |
- if empty, use the the minerID when creating the `ReplicaID` | |
- if a value is passed, use this for `ReplicaID` (in the place of `minerID`) | |
- Add a new field to `SectorNIActivationInfo` for passing `SealerSectorNumber`: | |
- again, if we are in the case EMPTY_SEALER_ID, then `sealerSectorNumber` could either be ignored or enforced to be 0, otherwis eit is used for `ReplicaID`; | |
- note that the miner actor identifies sectors internally using a `SectorID` structure with a `{minerID, sectorNumber}` pair. This is replaced by `{minerID, sectorNumber, minerSectorNumber}` where last value can be 0. | |
2. Modify the handling of parameters to `ProveCommitSectorsNI` to accept the sealerID to create `ReplicaID`: | |
- Allow the `SealerID` field in `SectorNIActivationInfo` to specify an actor separate to the calling actor and use this for `ReplicaID` (i.e. it will either be the actor ID of the storage provider, or the actor ID of the sealer in the case of involvement of a sealing SaaS). | |
- Allow the `SealingNumber` field of `SectorNIActivationInfo` to accept a sector number different to the number allocated in the calling actor's state for this sector and use this for `ReplicaID`. | |
- note that the miner actor identifies sectors internally using a `SectorID` structure with a `{minerID, sectorNumber}` pair. This is replaced by `{minerID, sectorNumber, sealerSectorNumber}` where 2nd and 3rd values may be the same. |
So does this get us closer to the diff on top of 0090 @irenegia @ZenGround0 ?
|
||
## Specification | ||
|
||
1. We add a new type of actor: the Sealer Actor; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. We add a new type of actor: the Sealer Actor; | |
1. We add a new type of built-in actor: the Sealer Actor; |
1. We add a new type of actor: the Sealer Actor; | |
1. We add a new type of actor: the Sealer Actor; |
- Store in the Sealer Actor another address: this is an address to a proxy contract that can be used to implement ACL. When an SP onboards a sector, then call to the Sealer Actor. If the ACL is enabled, then call the ACL contract. | ||
- TODOs: write the concrete interface to the ACL contract (eg, `check(sectorNumber, minerID) bool`) ![Sealer ID](https://github.com/filecoin-project/FIPs/assets/23217773/4852d5eb-6c81-4fc7-9f7e-dd7a351ed943) | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The sketch of this spec looks fine, but it's missing a lot of detail at the moment.
- The sealer actor's state schema should be specified (fairly simple, but at least leave room for an owner later on)
- The sealer actor will need a method that checks and consumes sector numbers, called from the miner actor.
- If we want the ACL features now, the API for it needs to be specified here. Or just cut it from scope now.
This PR has seen no activity in 4 months. Is work on this topic still ongoing? We should either move to draft or close for now, depending on the answer. |
No active work here, we are waiting for some spec actor resource to free up and help us (@lucaniz and I) to finalize the spec section. Maybe @magik6k will able to help soon ? 🙏 |
This proposal introduced the sealerID. This is a new identifier created for parties that participate to the Filecoin network by creating replicas, which can then transferred to SPs.
This fully enables the Sealing-as-a-Service scenario already introduced in FIP0090 (NI-PoRep).
Discussion: #890