Part 2: Advanced Building Blocks and the Power of BLS

In our previous post, we explored the elegant solution of Shamir's Secret Sharing (SSS) to combat the critical risk of a single point of failure. We learned how to split a secret into multiple shares, ensuring that only a specific threshold of participants could reconstruct it. However, SSS has an Achilles' heel: it relies on a single, trusted "dealer" to create and distribute the shares honestly. This brings us right back to a central point of failure.
Today, we move beyond that limitation. We'll explore how to create a shared secret without a trusted dealer and how to use these distributed shares to perform powerful cryptographic actions.
Introduction: Beyond the Trusted Dealer
The next logical step in our journey is to decentralize the secret's creation itself. This is the goal of Distributed Key Generation (DKG) protocols. The idea is to have a group of participants collaboratively create a single public key and a set of corresponding private key shares, with the crucial feature that no single participant ever knows the complete private key.
Distributed Key Generation (DKG): Creating a Secret Together
One of the most foundational DKG protocols is Pedersen's DKG. While the deep mathematics can be complex, the intuition is quite clever. It essentially runs multiple instances of a Verifiable Secret Sharing (VSS) scheme in parallel.
Here's the core idea:
Instead of one dealer, every participant acts as a dealer. Each participant i creates their own secret polynomial fᵢ(x), just like in SSS.
Each participant privately sends a share of their secret, fᵢ(j), to every other participant j.
Each participant j then combines the shares they've received from everyone else. Their final, personal secret share is the sum of all the shares they were sent:
$$s_j = \sum_{i=1}^{n} f_i(j)$$
- The combined secret key for the whole group is
$$s = \sum_{i=1}^{n} f_i(0)$$
but this is the magic part: this value is never calculated or held by any single party. It only ever exists in its distributed, shared form.
The "verifiable" part of VSS is critical. Protocols like Feldman's VSS, a building block for Pedersen's DKG, require each participant to publish a commitment (a kind of cryptographic "fingerprint") of their polynomial. This allows every other participant to verify that the shares they received are consistent and not from a malicious actor trying to sabotage the key generation.
Business Significance: DKG is the bedrock of decentralized consortia. It's the technology that enables multi-signature wallets for managing corporate treasuries, decentralized governance bodies for DAOs, and networks of notaries for cross-chain communication. It provides robust security by removing the single, all-powerful administrator.
A New Toolbox: Pairing-Based Cryptography
Simply creating a distributed key isn't enough; we need a way to use the shares. To do that, we need a more advanced tool: pairing-based cryptography.
At its heart, pairing-based cryptography gives us a special mathematical map, called a pairing, which we'll denote as e. This pairing takes two points from elliptic curve groups (let's call them G1 and G2) and maps them to a third, different group (Gt).
The magical property of this map is bilinearity. It means that for any secret numbers a and b, and generator points P and Q:
$$e(a \cdot P, b \cdot Q) = e(P, Q)^{ab}$$
This equation is profound. It allows us to move secrets around inside the pairing. We can multiply them on the "outside" of the points or on the "inside" as exponents, and the equation still holds. Think of it as a cryptographic lock multiplier; it lets us combine keys and locks in novel ways that standard elliptic curve math doesn't allow.
Boneh-Lynn-Shacham (BLS) Signatures: Short, Sweet, and Threshold-Friendly
A prime application of pairings is the Boneh-Lynn-Shacham (BLS) signature scheme. BLS signatures are known for being very short and, most importantly for our purposes, incredibly friendly to threshold operations.
Here's how they work:
- Key Generation: A private key
pk
is just a secret number. The corresponding public key is
$$P = pk \cdot G$$
where G is a known generator point on the curve.
- Signing: To sign a message m, you first hash the message to a point on a different curve, H(m). Then, you multiply this new point by your private key to get the signature:
$$S = pk \cdot H(m)$$
- Verification: This is where the pairing's bilinearity shines. A signature S is considered valid for a given public key P and message m if the following equation holds:
$$e(P, H(m)) = e(G, S)$$
Let's see why this works by substituting our definitions for P and S:
$$e(pk \cdot G, H(m)) = e(G, pk \cdot H(m))$$
Thanks to the bilinearity property, both sides of the equation are equal to
$$e(G, H(m))^{pk}$$
proving the signature is valid without ever revealing pk
.
The Payoff: Threshold BLS Signatures
This brings us to the crucial link that ties everything together. The secret shares we created using DKG are, in fact, valid BLS private keys themselves. This enables a seamless process for threshold signing:
To sign a message, at least t participants from the group use their individual private key share to create a partial signature.
These partial signatures are then collected. Using Lagrange interpolation (the same math used to reconstruct secrets in SSS), these t partial signatures can be combined to create a single, valid BLS signature that corresponds to the main public key of the entire group.
This is the "wow" moment. The full, combined secret key is never reconstructed in memory on a single machine. The cryptographic signature is created through a distributed process, completely removing the single point of failure from both the key's storage and its use.
Conclusion
In this post, we've made a significant leap. We went from a centralized dealer in SSS to a trustless, collaborative setup with Distributed Key Generation. We introduced the magic of pairings and saw how they enable the elegant and powerful BLS signature scheme. Finally, we connected it all to show how these building blocks allow a group to sign transactions without ever bringing their master secret key together.
We now have the core components for building truly decentralized systems. But what can we build with them? In our next post, we will explore the cutting-edge, real-world applications of this technology—from timed data release and fair auctions to fixing fundamental problems in blockchain like Miner Extractable Value (MEV). We'll also introduce the dcipher network, a platform designed to make all these powerful capabilities accessible to the next generation of developers and businesses.
Subscribe to my newsletter
Read articles from Mohammad Hatif Osmani directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Mohammad Hatif Osmani
Mohammad Hatif Osmani
A passionate software developer who loves experimenting and learning new tech.