Skip to content

Conversation

@rex1fernando
Copy link
Contributor

@rex1fernando rex1fernando commented Nov 16, 2025

Description

Introduces a new WeightedConfig type that is generic over both arkworks and blstrs.

Stacks on top of #18102.

How Has This Been Tested?

Same tests as in the original weighted_config.rs

Key Areas to Review

Now that WeightedConfig applies to both arkworks and blstrs, we should move it out of src/blstrs. Where should we move it to? @alinush @waamm

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Performance improvement
  • Refactoring
  • Dependency update
  • Documentation update
  • Tests

Which Components or Systems Does This Change Impact?

  • Validator Node
  • Full Node (API, Indexer, etc.)
  • Move/Aptos Virtual Machine
  • Aptos Framework
  • Aptos CLI/SDK
  • Developer Infrastructure
  • Move Compiler
  • Other aptos-crypto

Note

Make WeightedConfig generic over threshold backends and update all DKG/WVUF/consensus code to use the blstrs alias (WeightedConfigBlstrs) with minor API adjustments.

  • Crypto:
    • Introduce generic WeightedConfig<TC: ThresholdConfig> with aliases WeightedConfigBlstrs and WeightedConfigArkworks.
    • Replace direct field access (tc.t/n) with trait getters; add Display/SecretSharingConfig impls for generic type.
    • Keep evaluation-domain helpers on WeightedConfigBlstrs.
  • DKG/WVUF + Benches/Tests:
    • Migrate all uses of WeightedConfig to WeightedConfigBlstrs (traits, transcripts, helpers, benches, tests).
    • Update function signatures and generics (e.g., Transcript::SecretSharingConfig, bench helpers) accordingly.
  • Consensus Randomness:
    • Change RandConfig.wconfig and related imports/usages to WeightedConfigBlstrs.
  • Types (DKG rounding):
    • Use WeightedConfigBlstrs for wconfig/fast_wconfig construction and storage.

Written by Cursor Bugbot for commit ba21684. This will update automatically on new commits. Configure here.

Copy link

@cursor cursor bot left a comment

Choose a reason for hiding this comment

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

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.


/// Weighted config for the Arkworks-based PVSS
#[allow(type_alias_bounds)]
pub type WeightedConfigArkworks<F: FftField> = WeightedConfig<ShamirThresholdConfig<F>>;
Copy link

Choose a reason for hiding this comment

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

Bug: Trait Bound Mismatch Permits Invalid Type Aliases

The WeightedConfigArkworks type alias uses F: FftField as its bound, but ShamirThresholdConfig<F> only implements ThresholdConfig when F: PrimeField. Since WeightedConfig<TC> requires TC: ThresholdConfig, this type alias allows constructing invalid types where the trait bound isn't satisfied. The bound should be F: PrimeField instead of F: FftField.

Fix in Cursor Fix in Web

}

let tc = ThresholdConfigBlstrs::new(threshold_weight, W)?;
let tc = TC::new(threshold_weight, W)?;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Last time we discussed the ThresholdConfig trait I thought the consensus was to move or remove the new() method... but I think it works here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, it ended up being useful here.

My original idea was to define a single ThresholdConfig struct that's generic over an evaluation domain; then we'd be able to use it both for blstrs and for arkworks, and we wouldn't need a trait. But the blstrs version has both an EvaluationDomain and a BatchEvaluationDomain, so I wasn't sure how to do this cleanly...

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.

3 participants