Threshold Cryptography in ADIC

Version: 1.0 Date: 2025-10-08 Status: Production

Executive Summary

ADIC uses BLS12-381 threshold signatures for all production threshold cryptography needs. Ultrametric diversity enforcement is handled at the quorum selection layer, creating a clean separation between consensus concerns (p-adic geometry) and cryptographic primitives (battle-tested BLS).

Key Design Principle: Separate ultrametric diversity (consensus) from threshold cryptography (application).

Architecture

Production Stack

┌─────────────────────────────────────────┐
│     Quorum Selection Layer              │
│  (Ultrametric Diversity Enforcement)    │
│                                         │
│  • VRF-based committee selection        │
│  • Multi-axis p-adic distribution       │
│  • ASN/region diversity caps            │
│  • Per ADICPoUW2.pdf §3.2               │
└─────────────────────────────────────────┘
                   ↓
┌─────────────────────────────────────────┐
│   Threshold Cryptography Layer          │
│    (BLS12-381 Threshold Signatures)     │
│                                         │
│  • adic-crypto/bls: Threshold signer    │
│  • adic-crypto/dkg: Distributed keygen  │
│  • threshold_crypto: BLS12-381 backend  │
└─────────────────────────────────────────┘

Why This Separation?

Security: Uses battle-tested BLS12-381 (Zcash, Ethereum 2.0)
Auditability: Standard crypto primitives are easier to verify
Correctness: Diversity enforced where it matters (quorum selection)
ADIC-Aligned: Matches ADICPoUW2.pdf §3.2 specification

Components

1. Quorum Selection (`adic-quorum`)

File: crates/adic-quorum/src/selection.rs

Purpose: Select committee members with ultrametric diversity

Algorithm (per ADICPoUW2.pdf §3.2):

For each axis j in [0, d):
    For each eligible node u:
        Compute VRF score: y_{u,j} := VRF(R_k || domain || axis_id=j || axis_ball_u)

    Select m_j nodes with lowest VRF scores

Merge and deduplicate across all axes
Enforce diversity caps (max per ASN, max per region)
Return committee of size n

Ultrametric Properties:

Each node has p-adic coordinates per axis
VRF score includes axis_ball_u (ball membership)
Diversity enforced by selecting across multiple axes

2. BLS Threshold Signatures (`adic-crypto/bls`)

File: crates/adic-crypto/src/bls.rs

Purpose: Production threshold signatures

Features:

BLS12-381 pairing-based signatures
Threshold (t, n) schemes: Requires t signatures from n participants
Domain separation: Different DSTs for governance, PoUW, etc.
Signature aggregation: Lagrange interpolation in the exponent

Domain Separation Tags (PoUW III §10.3):

pub mod dst {
    pub const GOV_PROPOSAL: &[u8] = b"ADIC-GOV-PROP-v1";
    pub const GOV_VOTE: &[u8] = b"ADIC-GOV-VOTE-v1";
    pub const GOV_RECEIPT: &[u8] = b"ADIC-GOV-R-v1";
    pub const POUW_RECEIPT: &[u8] = b"ADIC-PoUW-RECEIPT-v1";
    pub const POUW_HOOK: &[u8] = b"ADIC-PoUW-HOOK-v1";
    pub const POUW_CLAIM: &[u8] = b"ADIC-PoUW-CLAIM-v1";
}

Usage Example:

use adic_crypto::bls::{BLSThresholdSigner, ThresholdConfig, dst};

// Create 5-of-7 threshold scheme (Byzantine fault tolerant)
let config = ThresholdConfig::with_bft_threshold(7)?; // t = ⌈2*7/3⌉ = 5
let (pk_set, shares) = generate_threshold_keys(7, 5)?;

let signer = BLSThresholdSigner::new(config);

// Each participant signs
let message = b"Governance proposal XYZ";
let share_0 = signer.sign_share(&shares[0], 0, message, dst::GOV_PROPOSAL)?;
let share_1 = signer.sign_share(&shares[1], 1, message, dst::GOV_PROPOSAL)?;
// ... collect t=5 shares ...

// Aggregate to threshold signature
let threshold_sig = signer.aggregate_shares(&pk_set, &sig_shares)?;

// Anyone can verify
let is_valid = signer.verify(&pk_set, message, dst::GOV_PROPOSAL, &threshold_sig)?;

3. Distributed Key Generation (`adic-crypto/dkg`)

File: crates/adic-crypto/src/dkg.rs

Purpose: Generate threshold keys without trusted dealer

Protocol: Feldman VSS-based DKG

Each participant generates random polynomial (degree t-1)
Broadcasts public key commitments
Sends shares to other participants
Recipients verify shares against commitments
Combine verified shares to get final key share
PublicKeySet derived from combined commitments

Security:

Honest majority assumption (< t dishonest participants)
Verifiable secret sharing (Feldman VSS)
No single party knows complete secret key

Usage Example:

use adic_crypto::dkg::{DKGCeremony, ThresholdConfig};

let config = ThresholdConfig::new(7, 5)?;
let mut ceremony = DKGCeremony::new(config, my_participant_id);

// Phase 1: Generate commitment
ceremony.start();
let my_commitment = ceremony.generate_commitment()?;
broadcast_to_committee(&my_commitment);

// Phase 2: Receive commitments from others
for commitment in received_commitments {
    ceremony.add_commitment(commitment)?;
}

// Phase 3: Generate and send shares
let shares_to_send = ceremony.generate_shares()?;
for share in shares_to_send {
    send_to_participant(share.to, &share);
}

// Phase 4: Receive and verify shares
for share in received_shares {
    ceremony.add_share(share)?;
}

// Phase 5: Finalize
let result = ceremony.finalize()?;
let my_secret_share = result.secret_key_share;
let public_key_set = result.public_key_set;

Production Usage

Governance Receipts (PoUW III §10)

Scenario: Validate governance proposal with threshold BLS

// Committee selected via adic-quorum (with ultrametric diversity)
let committee = quorum_selector.select_committee(epoch, config, nodes).await?;

// DKG ceremony to generate threshold keys
let (pk_set, shares) = run_dkg_ceremony(&committee).await?;

// Each committee member signs proposal
let proposal_hash = hash_proposal(&proposal);
for (i, member) in committee.iter().enumerate() {
    let sig_share = bls_signer.sign_share(
        &shares[i],
        i,
        &proposal_hash,
        dst::GOV_PROPOSAL
    )?;
    collect_signature_share(sig_share);
}

// Aggregate and verify
let threshold_sig = bls_signer.aggregate_shares(&pk_set, &sig_shares)?;
let receipt = GovernanceReceipt {
    proposal_id,
    threshold_signature: threshold_sig,
    public_key_set: pk_set,
};

PoUW Task Receipts (PoUW III §8)

Scenario: Committee validates PoUW task execution

// Committee selected for task validation (ultrametric diverse)
let committee = worker_selector.select_validation_committee(task_id, epoch)?;

// Committee members re-execute or verify proof
for member in &committee {
    let is_valid = validator.verify_task_result(task, result)?;
    if is_valid {
        let sig_share = bls_signer.sign_share(
            &member.secret_share,
            member.id,
            &task.result_hash,
            dst::POUW_RECEIPT
        )?;
        submit_verdict(sig_share);
    }
}

// Aggregate verdicts to PoUWReceipt
let pouw_receipt = create_pouw_receipt(task_id, threshold_sig, pk_set);

Ultrametric Diversity Enforcement

At Quorum Selection Layer

File: crates/adic-quorum/src/selection.rs

Diversity Mechanisms:

Multi-Axis Selection (ADICPoUW2.pdf §3.2)
- Select m_j members per axis j
- Different p-adic balls per axis
- Ensures geometric diversity

Network Topology Diversity (ADICPoUW2.pdf §3.3)

pub struct DiversityCaps {
    pub max_per_asn: usize,      // e.g., 2
    pub max_per_region: usize,   // e.g., 3
    pub max_per_ball: usize,     // e.g., 1 (per axis)
}

VRF-Based Determinism
- Same R_k (canonical randomness) → same committee
- Prevents manipulation
- Verifiable by all nodes

Example:

let quorum_config = QuorumConfig {
    total_size: 64,
    members_per_axis: 16,
    num_axes: 3,
    min_reputation: 50.0,
    domain_separator: b"ADIC-QUORUM-EPOCH",
    diversity_caps: DiversityCaps {
        max_per_asn: 2,
        max_per_region: 3,
        max_per_ball_per_axis: 1,
    },
};

let committee = quorum_selector.select_committee(
    epoch,
    &quorum_config,
    eligible_nodes  // All nodes with sufficient reputation
).await?;

// committee now has:
// - 64 members total
// - Distributed across 3 axes (p-adic geometry)
// - Max 2 per ASN, 3 per region
// - VRF-based deterministic selection

NOT at Threshold Crypto Layer

Why?

BLS12-381 operates on abstract algebraic groups (G1, G2, GT)
No notion of p-adic distance or ultrametric space
Adding p-adic structure would require novel crypto (unaudited, risky)

ADIC Design: Enforce diversity when selecting the committee, use standard crypto for threshold operations.

Removed: XOR Threshold Crypto

What Was Removed (0.3.0 Pre-Launch)

File: crates/adic-crypto/src/padic_crypto.rs Method: UltrametricKeyDerivation::combine_threshold_keys()

Why Removed:

Insecure: XOR combination provides zero security against collusion
Unused: No production code paths used this method
Redundant: BLS threshold crypto already available
Audit Burden: Novel crypto requires expensive security audit

Replaced With: Documentation pointing to BLS threshold crypto

Alignment with ADIC Papers

ADICPoUW2.pdf §3.2 (VRF-Based Quorum Selection)

✅ Implemented in: adic-quorum/src/selection.rs

"Committee selection uses VRF-based lottery with diversity constraints:

m_j members selected per axis j

VRF score y_{u,j} := VRF(R_k || domain || axis_id=j || axis_ball)

Lowest scores selected (deterministic given R_k)"

ADIC Implementation:

let vrf_score = self.vrf_service.compute_vrf_score_for_epoch(
    epoch,
    &config.domain_separator,
    axis_j,
    node.public_key.as_bytes(),
    axis_ball,  // ← Ultrametric ball membership
).await?;

PoUW III §10.3 (BLS Threshold Signatures)

✅ Implemented in: adic-crypto/src/bls.rs

"GovernanceReceipts and PoUWReceipts use BLS threshold signatures with:

Domain separation tags (ADIC-GOV-R-v1, ADIC-PoUW-RECEIPT-v1)

Threshold t ∈ [⌈m/2⌉, m] with default t = ⌈2m/3⌉ (BFT)

Lagrange interpolation for signature aggregation"

ADIC Implementation:

pub struct ThresholdConfig {
    pub total_participants: usize,
    pub threshold: usize,  // Validated: t ∈ [⌈m/2⌉, m]
}

impl ThresholdConfig {
    pub fn with_bft_threshold(total: usize) -> Result<Self> {
        let threshold = (2 * total + 2) / 3; // ⌈2m/3⌉
        Self::new(total, threshold)
    }
}

ADIC-DAG Paper §4 (Ultrametric Properties)

✅ Implemented in: adic-consensus, adic-mrw, adic-quorum

"Ultrametric properties used for:

MRW parent selection (proximity, trust, conflict penalty)

C1 constraint (parent ultrametric distance)

C2 constraint (multi-axis diversity)"

Note: Threshold cryptography is NOT mentioned in the ADIC-DAG paper as requiring p-adic properties!

Security Considerations

BLS12-381 Security

Curve: BLS12-381 (pairing-friendly curve) Security Level: 128-bit Used By: Ethereum 2.0, Zcash, Filecoin, Chia

Properties:

Signature Aggregation: Multiple signatures → single signature
Threshold Signatures: t-of-n signing without trusted dealer (via DKG)
Pairing-Based: e(sig, G2) = e(H(m), pk) for verification

Audited Implementations:

threshold_crypto crate (uses pairing and blstrs libraries)
BLS12-381 implementation audited by security firms

Threat Model

Assumptions:

Honest Majority: < t committee members are Byzantine
VRF Integrity: Canonical randomness R_k is unpredictable and verifiable
Network Diversity: Adversary controls < 50% of any ASN/region

Attacks Prevented:

Threshold Bypass: Cannot create valid signature with < t shares
Forgery: Cannot forge signature without secret key shares
Collusion: t-1 colluding parties learn nothing about secret
Committee Capture: Diversity caps prevent Sybil attacks on committee

Attacks Not Prevented (out of scope):

Eclipse Attacks: Network-layer attacks (mitigated by peer diversity)
Long-Range Attacks: Requires finality layer (F1/F2)
MEV Extraction: Requires transaction ordering rules (future work)

Testing

Unit Tests

BLS Threshold Crypto:

cargo test --package adic-crypto bls::tests

DKG:

cargo test --package adic-crypto dkg::tests

Quorum Selection:

cargo test --package adic-quorum selection::tests

Integration Tests

BLS + Quorum:

cargo test --package adic-pouw tests::bls_threshold_integration_test

DKG Network:

cargo test --package adic-pouw tests::dkg_network_integration_test

Governance End-to-End:

cargo test --package adic-node tests::governance_integration_test

Security Tests

Threshold Bypass Attempts:

cargo test --package adic-crypto tests::security_attacks_test::test_threshold_key_security

Migration Guide

If You Were Using `UltrametricKeyDerivation::combine_threshold_keys()`

Old Code (removed):

let ukd = UltrametricKeyDerivation::new(3, 10, 1);
let keys = ukd.generate_threshold_keys(&master_key, &neighborhoods, 3)?;
let combined = ukd.combine_threshold_keys(&keys[..3], &positions, 3)?;

New Code (use BLS):

use adic_crypto::bls::{generate_threshold_keys, BLSThresholdSigner, ThresholdConfig};

// Generate threshold keys
let config = ThresholdConfig::new(5, 3)?;
let (pk_set, shares) = generate_threshold_keys(5, 3)?;

// Sign with threshold
let signer = BLSThresholdSigner::new(config);
let mut sig_shares = Vec::new();
for i in 0..3 {
    let share = signer.sign_share(&shares[i], i, message, dst)?;
    sig_shares.push(share);
}

// Aggregate
let threshold_sig = signer.aggregate_shares(&pk_set, &sig_shares)?;

If You Need Ultrametric Diversity

Enforce at quorum selection:

use adic_quorum::{QuorumSelector, QuorumConfig};

let quorum_config = QuorumConfig {
    total_size: 64,
    members_per_axis: 16,
    num_axes: 3,
    // ... diversity caps ...
};

let committee = quorum_selector.select_committee(epoch, &quorum_config, nodes).await?;

// Then use BLS with this diverse committee
let (pk_set, shares) = run_dkg_with_committee(&committee)?;

Future Work

Potential Extensions

Aggregate Signatures Across Epochs
- BLS signatures can be aggregated across different messages
- Could compress governance history
Recursive Threshold Schemes
- Hierarchical committees (e.g., 3-of-5 regions, each region 5-of-7 nodes)
- Aligns with ultrametric hierarchy
Proactive Secret Sharing
- Periodic key refresh without changing public key
- Limits damage from long-term key compromise
Post-Quantum Alternatives
- BLS12-381 is not post-quantum secure
- Future: lattice-based threshold signatures (e.g., Dilithium)

References

ADIC Papers

ADIC-DAG Paper: Core consensus, ultrametric properties, C1-C3 constraints
ADICPoUW2.pdf §3.2: VRF-based quorum selection
PoUW III §10.3: BLS threshold signatures for receipts

Cryptography

BLS12-381 Spec: https://github.com/zkcrypto/bls12_381
Threshold Crypto: threshold_crypto crate documentation
Feldman VSS: "A Practical Scheme for Non-interactive Verifiable Secret Sharing" (1987)
BLS Signatures: "Short Signatures from the Weil Pairing" (Boneh-Lynn-Shacham, 2001)

Code References

crates/adic-crypto/src/bls.rs - BLS threshold signatures
crates/adic-crypto/src/dkg.rs - Distributed key generation
crates/adic-quorum/src/selection.rs - VRF-based committee selection
crates/adic-quorum/src/diversity.rs - Diversity cap enforcement

Changelog

v1.0 (2025-10-08)

Initial design document
Removed insecure XOR threshold crypto
Documented BLS threshold signatures
Documented separation of ultrametric diversity and threshold crypto
Added migration guide

FilesExpand file tree

THRESHOLD_CRYPTO_DESIGN.md

Latest commit

History