Skip to content
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

Merged
merged 5 commits into from
Sep 6, 2023

Conversation

cryptonemo
Copy link
Contributor

No description provided.

@codecov-commenter
Copy link

codecov-commenter commented Jul 7, 2023

Codecov Report

Merging #1811 (eb90e48) into master (8f33aa6) will decrease coverage by 0.11%.
The diff coverage is 2.43%.

Additional details and impacted files

Impacted file tree graph

@@            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     
Impacted Files Coverage Δ
fvm/src/gas/price_list.rs 78.30% <ø> (ø)
shared/src/sector/registered_proof.rs 6.20% <2.43%> (-0.36%) ⬇️

... and 8 files with indirect coverage changes

@Stebalien
Copy link
Member

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.

@cryptonemo
Copy link
Contributor Author

cryptonemo commented Jul 7, 2023

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.

Cc: @snadrus @rjan90

@cryptonemo
Copy link
Contributor Author

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.

As it is, I have branches called synthetic-porep across the board (across all deps)

Copy link
Contributor

@arajasek arajasek left a 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.

@@ -139,6 +139,14 @@ lazy_static! {
(
RegisteredSealProof::StackedDRG64GiBV1P1,
Gas::new(359272)
),
(
RegisteredSealProof::StackedDRG32GiBV1P1_Feat_SyntheticPoRep,
Copy link
Contributor

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?

Copy link
Contributor Author

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,
}
}
} /*
Copy link
Contributor

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) {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Member

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),
Copy link
Contributor

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

Copy link
Contributor Author

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> {
Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

@cryptonemo cryptonemo force-pushed the synthetic-porep branch 2 times, most recently from 3d09b11 to 6d11002 Compare August 30, 2023 14:15
@cryptonemo
Copy link
Contributor Author

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.

@Stebalien This is all finally ready and pointing to the latest published releases. Looks like we'll need an fvm3 release for the FFI PR (filecoin-project/filecoin-ffi#400)

@vmx
Copy link
Contributor

vmx commented Sep 5, 2023

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.
@vmx
Copy link
Contributor

vmx commented Sep 5, 2023

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.

@Stebalien
Copy link
Member

We'll need both an FVMv3 and an FVMv2 release. Can we put together a quick PR for FVMv2 that updates these deps?

@vmx
Copy link
Contributor

vmx commented Sep 5, 2023

Which dependencies need to be updated for FVMv2? is it the release/v2 branch? filecoin-ffi works without any updates there, but it sounds like i miss something.

If we need updates, then I'd update blst and bls-signatures to the latest version, that's cleaner than the patch releases I made to get FVMv2 work.

@Stebalien
Copy link
Member

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.

@cryptonemo
Copy link
Contributor Author

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,
Copy link
Member

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???

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

@Stebalien Stebalien left a 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.

@Stebalien Stebalien merged commit da5d0e3 into master Sep 6, 2023
14 checks passed
@Stebalien Stebalien deleted the synthetic-porep branch September 6, 2023 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants