commonware-cryptography Distributing Keyshares #2419
-
|
I'm reading the commonware-cryptography blog & i'm curious the reasoning behind distributing keyshares over encrypted connections directly with each participant rather than broadcasting encrypted keyshares to the blockchain? Is this because broadcasting ack's that each participant received their keyshare is more blockspace efficient than broadcasting encrypted keyshares? Or is it for some privacy benefit to participants? Also, the common-ware cryptography blog as well as some of the other ones are 1+ years old, are they outdated or still worth reading to learn about the library? i.e. should I focus more on reading the code than the blogs to learn about the tech? Thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The design choice is driven by scalability and simpler cryptographic assumptions, not blockspace efficiency. From The tradeoff: Direct distribution requires a synchrony assumption (bounded network delay). The broadcast approach doesn't require synchrony but is newer, more complex, and less scalable. You're correct that acknowledgements are more efficient than encrypted shares—the protocol broadcasts commitments and acks, with reveals only for non-responsive players (at most The blogs (updated Jan 2025) are still current. Read both alongside the extensive documentation in the DKG module. |
Beta Was this translation helpful? Give feedback.
-
|
Makes sense, ty for the detail! |
Beta Was this translation helpful? Give feedback.
-
|
One more thing rq, I saw from this post a while ago that you guys are interested in getting help with some higher level developer guides or explanations on how some of the primitives work. I'd be interested in helping out. As I go through the primitives on my own I can keep note of where I think new info can be added, but if there are any specific primitives that you think could use some more explanation please LMK! #230 |
Beta Was this translation helpful? Give feedback.
The design choice is driven by scalability and simpler cryptographic assumptions, not blockspace efficiency.
From
/cryptography/src/bls12381/dkg/mod.rs: Broadcasting encrypted shares requires Zero-Knowledge Proofs (Groth21, Kate23) to prove correct share generation, which don't scale well. It also "provides observers the opportunity to brute force decrypt shares."The tradeoff: Direct distribution requires a synchrony assumption (bounded network delay). The broadcast approach doesn't require synchrony but is newer, more complex, and less scalable.
You're correct that acknowledgements are more efficient than encrypted shares—the protocol broadcasts commitments and acks, with reveals only f…