In one sentence. ComputeFlux's most powerful keys are never created as whole keys at all — they're born already split across independent machines, and signing requires a supermajority of them to cooperate.
Picture it like this. A vault that opens only when three of its four keyholders turn their keys together is a familiar idea. Now make it stranger: the master key those four were cut from never existed. It was never manufactured, never held, never sat in a room where a camera could see it. Each holder received their fragment directly, and the complete key is a mathematical fiction — one that can still authorize a transfer without ever being assembled.
Why it matters. Nearly every large crypto theft and most cloud breaches share a single shape: somewhere, at some moment, a complete secret existed in one place. This article is about deleting that moment from the design.
Here for the curve choices? Skip to dual-suite signatures.
A blockchain network that stores a signing key in one place has a single point of failure. Key management systems, hardware security modules, and even the TEE enclaves from Article 1 all share that limitation. If one entity holds the complete key material, that entity becomes the bottleneck for both security and liveness.
ComputeFlux's answer is three cooperating primitives: Pedersen Distributed Key Generation, dual-suite threshold signatures, and proxy re-encryption with non-interactive zero-knowledge proofs. None of them replaces the hardware trust anchor. They distribute what that anchor protects across nodes, so that no single enclave — however well attested — ever holds a complete signing key.
Why Pedersen DKG Over Feldman
The choice between Pedersen and Feldman DKG is not merely academic — it fundamentally determines what an adversary learns about the shared secret. Both protocols operate on the same premise: each of n participants generates a random polynomial of degree t-1, distributes point evaluations (shares) to peers, and collectively derives a group public key without any participant ever constructing the full private key. The distinguishing property is information-theoretic versus computational hiding.
In Feldman VSS, each participant publishes commitments to polynomial coefficients in the form g^a_i,j. These commitments bind the dealer to their polynomial — any deviation is detectable because the verification equation g^{f_i(j)} = ∏ (g^{a_i,k})^{j^k} must hold for every share recipient. The cost is that the public commitments leak one bit of information about the secret: given g^{a_i,0}, an adversary learns whether the discrete log of some candidate matches the secret. This isn't an immediate break — recovering the secret still requires solving discrete log — but it means the protocol only achieves computational hiding. In a post-quantum setting, or if side-channel information about the discrete log becomes available, this leakage could be exploitable.
Pedersen DKG adds a second polynomial with a different generator h for which no one knows the discrete log relative to g. Each coefficient gets committed as g^{a_i,j} · h^{b_i,j}, and the verification equation involves both bases. Because h acts as a perfect blinding factor — b_i,j is uniformly random — the commitment distribution is statistically independent of the secret. An unbounded adversary with infinite computation learns precisely nothing about a_i,0 from the public transcript. This information-theoretic hiding matters deeply given the TEE context from Article 1: if SGX's remote attestation were ever compromised, the computational hiding of Feldman would become a liability. Pedersen's statistical hiding ensures forward secrecy even against future algorithmic advances — a second, independent layer of protection beneath the hardware root of trust, not a substitute for it.
The trade-off is complexity. Pedersen means twice as many coefficients per participant, plus two-generator discrete log equality proofs during share verification. In ComputeFlux's small validator set the extra round complexity is negligible at current network latencies, and it buys guarantees that would otherwise require post-quantum primitives to match. When the asset is the network's entire signing authority, information-theoretic hiding is cheap insurance.
The Mathematical Reason for t = ⌊2n/3⌋ + 1
Threshold selection is a tension between availability and integrity. Lower thresholds tolerate more node failures; higher thresholds resist more adversarial corruption. The 2/3 + 1 threshold — meaning 3 of 4 nodes must cooperate to sign — is the point where Byzantine fault tolerance and Lagrange interpolation intersect optimally.
Lagrange interpolation reconstructs a polynomial of degree t-1 from any t distinct evaluation points. In threshold signing, each honest node computes a partial signature using its secret share s_i = Σ f_k(i), where the f_k are the polynomials contributed during DKG. The aggregator collects t partial signatures and computes the full signature via Lagrange coefficients:
sig = Σ_{i∈S} λ_i · sig_i, where λ_i = ∏_{j∈S\{i}} (0 - j) / (i - j)
Any subset of fewer than t shares produces a linear combination statistically independent of the correct signature. If an adversary holds t-1 shares, infinitely many degree-(t-1) polynomials interpolate those points, each yielding a different value at x=0 (the secret) — the adversary cannot distinguish the true secret from any other group element. This is the geometric interpretation of Shamir secret sharing: t-1 points constrain a degree-(t-1) polynomial to a line in a t-dimensional space, leaving one degree of freedom. Without the t-th point, every possible y-intercept is equally consistent with the observed data.
With n=4 and t=3, the system tolerates any single node failing — Byzantine or crashed — because n−t=1. Fully compromise one node — extract its enclave memory, expose its share — and the adversary still needs two more shares to produce a valid signature. The remaining honest nodes hold three between them, which satisfies the threshold. A second simultaneous failure, whether Byzantine or crashed, drops the available shares below t and stalls signing until the node recovers; CometBFT consensus (Article 4) can usually route around that through view changes.
Neither neighbouring value works as well. Raise the threshold to 4 and you get n-of-n security with zero fault tolerance: one offline node halts the network. Lower it to 2 and you tolerate two failures, but a single compromised node plus one coerced node is enough to seize signing authority. Byzantine resilience requires f < t ≤ n - f; with f=1 that means 1 < t ≤ 3, and t=3 is the most secure threshold the constraint allows.
Dual-Suite Signatures: Ed25519 and BLS12-381
Deploying two distinct signature schemes with different mathematical foundations might look redundant. The rationale is that neither suffices alone for ComputeFlux's cross-chain requirements.
Ed25519, built on the twisted Edwards curve over GF(2^255-19), excels at single-signature verification speed and compact representation — 64-byte signatures, 32-byte public keys, roughly 50μs to verify via double-scalar multiplication. But Ed25519 has a structural weakness for threshold settings: partial signatures don't aggregate natively. Each node produces a partial signature, and the aggregator applies Lagrange coefficients — O(t) scalar multiplications per partial signature — then sums the results. The output is indistinguishable from a single-signer Ed25519 signature (the entire point, for chain compatibility), but the aggregator must also verify each partial signature individually before aggregation, adding O(t) verification overhead.
BLS12-381 inverts this trade-off. Built on pairing-friendly curves with bilinear maps e: G₁ × G₂ → G_T, BLS partial signatures aggregate through simple addition in G₁: σ_agg = Σ σ_i. Verification of the aggregate checks e(σ_agg, g₂) = e(H(m), pk_agg) in a single pairing computation — no Lagrange coefficients, no per-share verification. This makes BLS ideal for the consensus-critical path where multiple signatures must be verified under time pressure, at the cost of pairing operations roughly 60x more expensive than Ed25519 verification (~3ms vs ~50μs) and 48-byte compressed signatures (the G₁ element in the verification equation above). Note that the public key sits in G₂ at 96 bytes — the trade is cheap aggregation vs. larger keys.
The reason for two curves isn't academic optimization — it's blockchain compatibility. Different chains mandate different signature schemes:
| Curve | Chains |
|---|---|
| Ed25519 | Solana, Cosmos, NEAR, Aptos, Sui, Aleph Zero, Celestia, Sei, Injective, Osmosis, dYdX, Axelar, Akash, Juno, Stargaze, Secret Network, Kujira, Fetch.ai, Agoric — nearly every non-EVM L1. (Polkadot/Kusama use Sr25519 for user accounts and reserve Ed25519 for GRANDPA finality keys; the DKG Ed25519 path covers the latter.) |
| BLS12-381 | Ethereum Beacon Chain, Filecoin, ZCash, Dfinity ICP, Chia |
| ECDSA (secp256k1) | Ethereum, BSC, Polygon, Avalanche C-Chain, Arbitrum, Optimism, Base, Linea, Scroll, zkSync Era, StarkNet |
Ed25519 is the default for modern blockchain design generally, not just Polkadot's curve: deterministic nonces, no side-channel vulnerabilities in the reference implementation, and batched verification roughly 10x faster than ECDSA. A DKG ceremony producing Ed25519 threshold shares therefore unlocks most non-EVM chains, which matters for the cross-chain relay work in Article 11.
BLS12-381 covers the next wave: chains with pairing precompiles that verify aggregate signatures natively. There, partial signatures aggregate through simple G₁ addition, collapsing on-chain verification from O(n) to O(1) — exactly what a relay needs when many validators attest to the same event. One DKG ceremony produces shares for both curves, so reaching a new ecosystem never means re-running the protocol.
The Nonce Reuse Attack: Why Pre-Generation Is Unavoidable
Ed25519's Schnorr-like signature computes r = H(hash_prefix || M) deterministically from the message, where hash_prefix derives from the private key. In a single-key setting, this deterministic nonce derivation eliminates the catastrophic failure mode of nonce reuse: sign two different messages with the same nonce, and anyone can solve for the private key as sk = (s₁ - s₂) / (h₁ - h₂) mod q, where s_i = r + sk · h_i.
The DKG setting breaks this safeguard. Each node signs with its share sk_i, and the aggregator combines the partial signatures. Reuse the same nonce r_i for two different messages and those partials let anyone solve for sk_i. The aggregator sees both partials, so node i doesn't even have to be malicious — buggy nonce handling is enough.
Deterministic derivation can't rescue this, because the problem is structural. Producing r = H(sk, M) requires the complete private key, not a share. No node can compute it without the full secret, which is precisely what threshold distribution exists to prevent.
The fix is a pre-generation pool. Nodes run extra DKG-style ceremonies ahead of time, producing a batch of independent random shares that are persisted locally and indexed by position. At signing time, no node picks its own nonce. Instead, ComputeFlux maps the transaction's index deterministically onto a position in the pool, so every node signing that transaction draws the same entry. That is what lets the protocol combine partial signatures correctly without an extra coordination round to agree on which random values to use.
The pool holds 500 pre-generated shares per node by default, and a background process keeps it topped up as in-flight and retried transactions consume entries. How often that refill actually runs, and how much throughput headroom it leaves, isn't something the pool's data structure alone can tell you.
NIZK Proofs in Proxy Re-Encryption: What Is Being Proven
Proxy re-encryption transforms a ciphertext encrypted under the DKG group public key into one a specific pod can decrypt using its own ephemeral key, without any node ever decrypting the plaintext. The re-encryption share from node i is:
re_i = sk_i^{-1} · (C₁)^{r_i} mod q
where C₁ = r · G is the first component of an ElGamal-style ciphertext. Verifying re_i is well-formed involves the node's secret share sk_i — without a proof, a malicious node could submit garbage re-encryption shares that derail aggregation, producing a valid-looking but incorrect re-encryption key with no way to identify which share was corrupted.
The NIZK proves, in zero knowledge, that the node knows a scalar sk_i satisfying two equations at once: pk_i = sk_i · G, already verified during DKG, and re_i · sk_i = C₁^{r_i}, meaning the re-encryption share is correctly formed. It's a sigma protocol made non-interactive via Fiat-Shamir.
The zero-knowledge property is doing real work here, not decorating the design. Leakage accumulates: if a verifier learned one bit about sk_i per session, a node performing 1,000 re-encryptions could leak up to 1,000 bits — potentially enough for a lattice-based key recovery attack. The NIZK's simulator-based definition guarantees the transcript is indistinguishable from random no matter how much computation the verifier has. The verifier learns exactly one thing: "this share is correctly formed."
A malicious node can still refuse to submit a share. But that is just the crash fault the t-of-n threshold already absorbs. The NIZK eliminates the harder Byzantine case — plausible-looking but incorrect shares — entirely.
Latency Overhead: DKG Signing vs. Single-Key Signing
The latency budget for a threshold signature decomposes into share generation, share collection (network round-trip to the aggregator), and aggregation. Single-key signing collapses this to one local computation.
Take a single datacenter, RTT around 0.5ms. Share generation runs ~50μs for Ed25519 and ~200μs for BLS12-381. Share collection costs ~0.5ms, parallelized across the three responding nodes. Aggregation is ~150μs for Ed25519 — O(t) scalar multiplications plus one addition — or ~10μs for BLS, which needs a single G₁ addition. That totals roughly 0.7ms for Ed25519 DKG and ~0.71ms for BLS, against ~50μs for single-key Ed25519. A 14x slowdown, optimistically measured.
The comparison misses the point, though. Single-key signing requires the key to exist somewhere, which is the single point of compromise this whole design exists to remove. The DKG overhead is what removing it costs. At under 0.1% of CometBFT's typical one-second block time, it disappears inside the consensus loop — which is exactly where DKG and consensus meet, and the subject of Article 4.
The real latency concern is cross-datacenter deployment, where RTT might reach 50ms — a naive signing exchange spanning several round-trips would push DKG signing to ~150ms. Here the pre-signature optimization becomes critical: nodes compute and exchange partial signatures as soon as they receive the message to be signed — during the view change or block proposal phase — so that by the time the aggregator needs the final signature, all shares are already in hand. The remaining aggregation costs a single round-trip, so the latency is subsumed by the consensus round duration and adds no incremental latency to block finalization.
Key Takeaways
- The whole key never exists. Not in memory, not in a config file, not for a microsecond during setup. An attacker who fully owns one machine gets one fragment and learns nothing useful from it.
- Pedersen instead of Feldman is cheap insurance. Both are secure against today's computers. Pedersen additionally leaks nothing at all to an adversary with unlimited computing power. When the asset is the network's entire signing authority, paying a little complexity for that is an easy call.
- 3-of-4 is a calculated point, not a round number. It's the strongest threshold that still tolerates any single node failing — Byzantine or crashed; any second failure drops the available shares below t and stalls signing. Require all four and a single reboot halts the network; require two and one compromised node plus one coerced node owns you.
- Two signature systems, because chains disagree. Ed25519 unlocks most non-EVM blockchains; BLS lets many validators' signatures collapse into one cheap-to-verify proof. A single setup ceremony yields both, so no re-run is needed to reach a new ecosystem.
- Splitting the key breaks a built-in safety net, so it gets rebuilt. Ordinary Ed25519 protects itself from a catastrophic class of bug in a way that structurally cannot work on a key fragment. ComputeFlux replaces it with pre-generated pools of shared randomness.
- The cost is real and irrelevant. Roughly 0.7 milliseconds versus 0.05 for ordinary signing — a 14× slowdown that amounts to less than 0.1% of a block. You are not trading performance for this property; you're getting it nearly free.
DKG gives ComputeFlux a signing authority with no single point of compromise, built on top of the hardware trust established in Article 1 and persisted, where relevant, through the sealed storage layer covered in Article 2. The next article shows exactly how these threshold signatures and per-block attestation interleave inside the consensus protocol itself — DKG doesn't just sit next to consensus, it's woven into how votes and proposals get validated at every height.
Next — Article 4: CometBFT Consensus with TEE: hardware trust and split keys are both settled. Now several independent machines have to agree, in order, on what actually happened — while assuming some of them are lying.