-
Notifications
You must be signed in to change notification settings - Fork 140
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
Update dependencies and Proof types for Synthetic PoRep support #1811
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #1811 +/- ##
==========================================
- Coverage 75.20% 75.10% -0.11%
==========================================
Files 149 149
Lines 14593 14615 +22
==========================================
+ Hits 10975 10976 +1
- Misses 3618 3639 +21
|
Is this work ready to land? If not, it may make sense to update the proofs APIs and bls signatures packages first before actually adding support for synthetic porep. |
My understanding is that an end to end is needed for testing well before this lands, and that it's needed by next week. I was trying to wire all of the deps together in order for it to happen so that it could be taken off my hands for that testing before actually cutting releases across the board. This is tricky because it seems I'm hitting some deps that are also right around release boundaries. |
As it is, I have branches called |
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.
Generally looks good, a few notes / qs.
fvm/src/gas/price_list.rs
Outdated
@@ -139,6 +139,14 @@ lazy_static! { | |||
( | |||
RegisteredSealProof::StackedDRG64GiBV1P1, | |||
Gas::new(359272) | |||
), | |||
( | |||
RegisteredSealProof::StackedDRG32GiBV1P1_Feat_SyntheticPoRep, |
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.
This seems reasonable to me, but have we discussed whether or not these values need to change somewhere?
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.
No, we haven't. Fundamentally, the PoRep doesn't change, so I think it should be ok to use the existing as the model -- but that's a bit out of my wheelhouse too
@@ -50,7 +57,16 @@ impl RegisteredSealProof { | |||
SectorSize::_32GiB => Self::StackedDRG32GiBV1P1, | |||
SectorSize::_64GiB => Self::StackedDRG64GiBV1P1, | |||
} | |||
} | |||
} /* |
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.
Hmm, this doesn't seem right. There is no-longer a 1-1 mapping from sector size to seal proof type, because both "regular" and SyntheticPoRep types are supported.
Does anything actually use this? I suspect we can delete it.
@@ -65,6 +81,18 @@ impl RegisteredSealProof { | |||
}; | |||
} | |||
|
|||
/// Convert the original proof type to the v1 SyntheticPoRep proof added in network version ??. | |||
pub fn update_to_v1_feat_synthetic_porep(&mut self) { |
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.
Also not sure that we need this.
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.
Agreed, a lot of the conversions are starting to not make sense anymore, but it's not clear to me what's used and what isn't.
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.
So, I hate to be a stickler but... can we try to better understand what's happening here? The fact that we appear to be making changes without really understanding if we need them is concerning.
| StackedDRG8MiBV1P1 | ||
| StackedDRG2KiBV1P1_Feat_SyntheticPoRep | ||
| StackedDRG512MiBV1P1_Feat_SyntheticPoRep | ||
| StackedDRG8MiBV1P1_Feat_SyntheticPoRep => Ok(192), |
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.
You know better than I do, but just want a 👍 that these values are unchanged for SynthPoRep
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.
Yes, they are unchanged -- thanks for noting!
@@ -218,11 +272,21 @@ impl RegisteredSealProof { | |||
pub fn registered_winning_post_proof(self) -> Result<RegisteredPoStProof, String> { |
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.
Seems correct, but we might be able to delete this method too? I'd really like to get this kinda logic out of the FVM
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.
Agreed!
3d09b11
to
6d11002
Compare
6d11002
to
700fef1
Compare
@Stebalien This is all finally ready and pointing to the latest published releases. Looks like we'll need an |
I need to push one more commit, give me a sec. |
In `filecoin-proofs-api` are the `cuda` and `cuda-supraseal` features mutally exclusive. Hence add this feature to fvm, so that it can be enabled on the `filecoin-ffi` level.
Sorry for the delay. It turned out that fvm2 caused some troubles within filecoin-ffi, but I sorted all out with patch releases. This PR is now ready to be merged. Also if anyone finds the time to do a release, that would be great as this is the only thing that prevents us from cutting a new filecoin-ffi release. |
We'll need both an FVMv3 and an FVMv2 release. Can we put together a quick PR for FVMv2 that updates these deps? |
Which dependencies need to be updated for FVMv2? is it the If we need updates, then I'd update |
I think we at least need blst updated due to linking issues. I generally just update everything to reduce the size of the dependency tree. |
I took a stab at this here: #1875 |
@@ -25,6 +26,12 @@ pub enum RegisteredSealProof { | |||
StackedDRG8MiBV1P1, | |||
StackedDRG32GiBV1P1, | |||
StackedDRG64GiBV1P1, | |||
|
|||
StackedDRG2KiBV1P1_Feat_SyntheticPoRep, |
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.
Ok.... why _Feat_SyntheticPoRep
. Can we not just assign a new version?
Like.... we had V1. Then we tacked on a P1 instead of bumping it to V2. Now we're adding _Feat_SyntheticPoRep
instead of just bumping it to P2 or V2 or something???
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 PoRep proof version isn't changing, it's an optional feature that's been added -- and that's the naming convention we chose for optional features that are enabled by new proof types.
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.
Where do we actually use this? In the builtin actors, it looks like we don't care.
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.
Hm. Let's continue on slack and schedule a time tomorrow to talk about this. I think we can land this PR quickly, but doing this async will take too long.
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.
Reviewed and discussed out of band. We need to deduplicate some of these enums/constants, but that's a later thing.
No description provided.