commonware-cryptography: Unlocking Seeds, Links, and Views

When I chat with a developer about launching their own onchain application (as a specialized blockchain), the same questions always come up:

• Where can I source bias-resistant randomness? (ensure fair and unpredictable outcomes in onchain games)

• Will my application be able to interact with other applications? (transfer tokens between blockchains and gate experiences with external token ownership)

• Can users verify data fetched from an API is correct? (supermajority of validators indicate whether a payment was finalized, not an API provider)

Today, we're excited to share how @commonwarexyz is answering these questions with commonware-cryptography (now in ALPHA).

commonware-cryptography is an open (Apache-2 and MIT) implementation of BLS12-381 Distributed Key Generation (DKG), Resharing, and Threshold Signatures in Rust. Unlike most implementations, commonware-cryptography does not employ a "board" for share distribution (that requires dealers to broadcast encrypted shares over a public channel). Rather, dealers distribute shares over encrypted connections directly with each recipient and recipients broadcast an acknowledgement when they receive a correct share (no share material included).

With an eye towards consensus integration (natively emitting Threshold Signatures during finalization), the commonware-cryptography DKG/Resharing construction identifies disqualified contributors in each round (missing commitment, invalid commitment, invalid share distribution, ignoring reveal requests, etc.) and supports maintaining a threshold of 2f + 1 (of 3f + 1 total contributors) across Reshares (which can be run to introduce/remove contributors and/or proactively on a regular interval to bound the age of shares). You can read more about this construction here.

So, how does this answer any of a developer's questions?

• Seeds (Randomness): BLS12-381 Threshold Signatures are deterministic and can be used as a bias-resistant source of randomness. No contributor knows the value of a signature until collecting at least "threshold" partial signatures.

• Links (Connectivity): With BLS12-381 DKG/Resharing, a group of contributors (like a validator set) maintain a static public key over time (even as participants are added/removed). If this set of contributors signs over a finalized block, anyone can verify that block (or anything provable from its header) is included in the canonical history using the static public key of the group (48 bytes) and a Threshold Signature (96 bytes). A blockchain can support verification of BLS signatures in the execution layer (many already do) and read finalized data from another blockchain without following its consensus or tracking its validator set (as a lite client).

• Views (Access): "Links" can be extended beyond blockchain execution environments to wallets and explorers to provide trust-minimized access to onchain activity. Like a blockchain, all a user requires to verify that a blockchain included/emitted some data is its static public key (can be hardcoded) and a Threshold Signature over a block (or whatever artifact a developer wants to emit) referencing said data.

To showcase how "Seeds" will work, we implemented a Proof-of-Concept Verifiable Random Function (VRF) CLI with a trusted Arbiter (that will be removed after the release of commonware-consensus) and untrusted Contributors:

Contributors to this VRF connect to each other over commonware-p2p (using ED25519 identities), perform an initial DKG (to generate a static public key), and then perform a proactive refresh every 10 seconds. After a successful DKG and/or Reshare, contributors generate partial signatures over the round number and gossip them to others in the group (again using commonware-p2p). These partial signatures, when aggregated, form a bias-resistant source of randomness that was not knowable to any contributor prior to signing.

To demonstrate how malicious contributors are tolerated, the CLI also lets you behave as a "rogue" dealer that generates invalid shares, a "lazy" dealer that doesn't distribute shares to other contributors, or a "defiant" dealer that doesn't respond to requests to reveal shares that weren't acknowledged by other contributors.

Next up, commonware-consensus!

To support contributors and developers working with the Commonware Library, we launched a Discord. We look forward to seeing you there soon!