Pairing-Based Cryptography
Also called Bilinear Pairing Cryptography, Pairing Cryptography
What it is. Certain elliptic curves come with a special operation called a bilinear pairing: a function e that takes one point from a group G1 and one from a group G2, and produces a value in a third group GT, with the property e(aP, bQ) = e(P, Q)^(ab). In plain terms: you can multiply two secret exponents "inside the exponent" without ever revealing either one, and the result is publicly checkable. That single algebraic trick is the engine behind several otherwise-impossible-looking capabilities: proving a signature is valid without seeing what it signs, combining dozens of separate signatures into one that's just as short, and building encryption schemes keyed to a person's identity string rather than a random public key.
Who built it. Antoine Joux first showed in 2000 that pairings, previously studied mainly as a tool for attacking certain curves, could be used constructively, with a one-round three-party key exchange. Dan Boneh and Matt Franklin then built the first practical identity-based encryption scheme on pairings (2001). Boneh, Lynn, and Shacham used the same math for the BLS signature scheme (2001), prized for producing the shortest signatures of any known scheme. Boneh, Boyen, and Shacham extended that into BBS group signatures (2004), which, after later refinement into "BBS+" by others in the space, became the selective-disclosure signature scheme Solidus uses. The specific curve most of this runs on today, BLS12-381, was parameterized by Paulo Barreto, Ben Lynn, and Michael Scott, and reached wide production use through the Zcash and Ethereum ecosystems.
How Solidus uses it. Two separate, unrelated uses, each with its own caveat. First: BBS+ signatures over the BLS12-381 curve power Solidus's selective-disclosure credentials. This is UNAUDITED, external audit targeted H2 2026 via NLnet NGI Zero, and that caveat applies every time this is mentioned. Second, and structurally separate: the HotStuff consensus layer uses BLS signature aggregation to compact many validators' votes on a block into a single short signature rather than shipping every individual signature. This code exists, is covered by an internal test suite, and runs on the live testnet. But say precisely what "the live testnet" means here: it is a 4-node dev committee, not the 21-of-100 VRF-selected validator committee the consensus design specifies. Neither pairing-based component, the credential side or the consensus side, has had an outside cryptographic audit yet.
Check it yourself. npm view @solidus-network/bbs version shows the shipped, versioned selective-disclosure package. The consensus-side BLS aggregation code is public in the consensus crates of github.com/solidusnetwork/protocol.
Where it comes from
Someone else specified this. Solidus assembles it.
Built from a sequence of independently published results: Antoine Joux's one-round tripartite key exchange (2000) first showed bilinear pairings were cryptographically useful; Dan Boneh and Matt Franklin used them for practical identity-based encryption (2001); Boneh, Lynn, and Shacham used them for the short BLS signature scheme (2001); Boneh, Boyen, and Shacham extended that into BBS group signatures (2004), the direct ancestor of the BBS+ scheme Solidus uses for selective disclosure. The BLS12-381 curve Solidus's BBS+ package runs on was parameterized by Paulo Barreto, Ben Lynn, and Michael Scott, and popularized for production use by the Zcash and Ethereum communities. Solidus assembles this prior art; it invented none of it.
How to check this
Running on the test network. Not mainnet.
npm view @solidus-network/bbs version confirms the shipped selective-disclosure package; the BLS aggregation code inside the consensus layer is public in github.com/solidusnetwork/protocol's consensus crates.