What it is good for
AVSS is the right backend when the secret value is a cryptographic scalar whose share needs a public commitment or curve-compatible output:- the program exposes public commitments to secret shares;
- the backend must use a curve selected by an external verifier or protocol;
- public transcript bytes must become curve-field challenges;
- the outside system consumes a commitment, curve-encoded value, opened scalar response, or signature-related artifact.
Protocol model
AVSS uses a dealer/share/commitment model:- a secret scalar is shared as evaluations of a polynomial;
- the dealer publishes commitments to the polynomial coefficients;
- each party verifies its share against those commitments;
- later, enough valid shares can reconstruct or derive the intended cryptographic value.
G, the commitment form is conceptually:
a_j is a polynomial coefficient. A party can verify a scalar share against the public commitment points without learning the underlying secret scalar.
Security posture
AVSS commitments are public group elements tied to the shared scalar. That is useful when another system needs to verify a commitment, curve-encoded value, or scalar response, but it is usually the wrong privacy boundary for ordinary application data. If the value is app data and the goal is private computation over integers or fixed-point values, start with HoneyBadgerMPC. Cryptographic note: Feldman-style commitments are binding under discrete-log hardness, but they are not hiding commitments. The developer consequence is that AVSS commitments are verifier-facing artifacts, not a drop-in privacy boundary for low-entropy values. Keep these distinctions in mind:- AVSS is about verifiable scalar shares and group commitments.
- Feldman-style commitments expose public group elements tied to the secret polynomial.
- Low-entropy application values should not be treated like random cryptographic scalars.
- Full threshold signing protocols may need additional logic beyond share generation and commitment access.
- Stoffel’s current local/network config enforces
parties >= 4 * threshold + 1.
Curves
Stoffel accepts AVSS curve selectors through the CLI and Rust SDK:
Use the curve required by the external verifier or protocol boundary. Curve selectors are not interchangeable when another system needs to verify a public commitment, encoded group element, scalar response, or signature-related artifact.
Configure AVSS
avss defaults to bls12_381:
bls12_381. Other AVSS curves are available to the bytecode/runtime path, local protocol work, and StoffelLang examples where the selected curve is handled by the VM/backend.
Circuit-shaping for AVSS
AVSS is the right choice when the application needs verifiable scalar shares, group commitments, or curve-compatible threshold-cryptography building blocks. The optimization target is the cryptographic transcript: keep public transcript work public, choose the curve for the external protocol, use commitments deliberately, and minimize unnecessary openings. See Performance and circuit shaping for the full checklist.StoffelLang AVSS helpers
StoffelLang includes anAvssShare opaque type and AVSS helper methods:
Use-case examples
AVSS is the best fit when the secret is a cryptographic scalar and the application needs public group commitments, curve-specific encodings, or threshold-signature building blocks. The examples below use Stoffel features that are specific to those workflows: persisted secret shares,Mpc.curve(), commitment extraction, curve encodings, transcript hashing, and client-output shares.
Persistent threshold key material
Use this shape when MPC parties need to generate a signing key once, persist each party’s share, and publish the corresponding curve point as the application-facing public key:Threshold signature response with client output
Use this shape when a signing workflow needs committed nonces, curve-specific challenge hashing, and selected signature shares returned to a client:Further reading
- Performance and circuit shaping
- Feldman, “A Practical Scheme for Non-interactive Verifiable Secret Sharing”: https://www.cs.umd.edu/~gasarch/TOPICS/secretsharing/feldmanVSS.pdf
- Cachin, Kursawe, Lysyanskaya, Strobl, “Asynchronous Verifiable Secret Sharing and Proactive Cryptosystems”: https://doi.org/10.1145/586110.586122
- Gennaro, Jarecki, Krawczyk, Rabin, “Secure Distributed Key Generation for Discrete-Log Based Cryptosystems”: https://doi.org/10.1007/3-540-48910-X_21
- FROST threshold Schnorr signatures: https://eprint.iacr.org/2020/852