You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/blogs/golden.md
+14-13Lines changed: 14 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,9 +1,9 @@
1
1
---
2
2
title: "A Golden Ticket to One-Round DKGs"
3
-
description: "We've completed an initial implementation of the Golden protocol, which lets you perform a DKG in just a single round. Going from two rounds to just one is a huge improvement in simplicity and performance."
4
-
date: "May 18th, 2026"
5
-
published-time: "2026-05-18T00:00:00Z"
6
-
modified-time: "2026-05-18T00:00:00Z"
3
+
description: "We've completed an initial implementation of the Golden protocol, which lets you perform a DKG in just a single round."
4
+
date: "May 20th, 2026"
5
+
published-time: "2026-05-20T00:00:00Z"
6
+
modified-time: "2026-05-20T00:00:00Z"
7
7
author: "Lucas Meier"
8
8
author_twitter: "https://x.com/cronokirby"
9
9
url: "https://commonware.xyz/blogs/golden"
@@ -146,9 +146,9 @@ which we usually try to avoid, because assuming realtime execution is quite unre
146
146
In practice, you can improve the situation by tying the clock to a consensus protocol,
147
147
e.g. waiting a certain number of *blocks* rather than a certain amount of time.
148
148
It's possible that this is correct in the
149
-
[partial synchrony model](https://dl.acm.org/doi/10.1145/42282.42283) as well (todo: citation).
149
+
[partial synchrony model](https://dl.acm.org/doi/10.1145/42282.42283) as well ([citation](https://eprint.iacr.org/2023/1196)).
150
150
151
-
It's also operationally complicated to have multiple rounds.
151
+
Multiple rounds are also operationally complicated.
152
152
The protocol is stateful between the rounds.
153
153
Players need to remember what shares they received, and what they did or didn't
154
154
ack.
@@ -175,9 +175,9 @@ We wouldn't need any state at all: if we lost our memory completely,
175
175
we would be able to retrieve our share and any public results just by
176
176
looking at the log, which contains what each dealer posted.
177
177
178
-
We would not need any kind of synchrony assumption.
179
-
After all dealers have posted their log, you're ready to go,
180
-
with no need to wait for acknowledgement.
178
+
The protocol can proceed immediately after the dealers have posted their logs,
179
+
without needing to wait for acknowledgments from the players.
180
+
This lets us avoid any kind of synchrony assumption.
181
181
In practice you would want to set a cutoff time (in terms of blocks, ideally),
182
182
and would need to make sure that you had a supermajority of valid contributions,
183
183
in order to prevent stalling by having malicious dealers withhold their contribution.
@@ -202,9 +202,10 @@ to the public polynomial $F_j$ we're including in our contribution.
202
202
This is essentially the approach taken by prior non-interactive constructions
203
203
such as [Groth's DKG](https://eprint.iacr.org/2021/339), which uses ElGamal
204
204
encryption together with a NIZK of correct encryption.
205
-
That achieves the properties we want, but would involve a very large,
206
-
and thus expensive, ZK proof.
207
-
Doing this naively would not be enough, so we need to dig a bit deeper.
205
+
That achieves the properties we want, but would involve a ZK proof
206
+
over an excessively large statement.
207
+
This naive approach would be orders of magnitude slower than something practical,
208
+
so we need to dig a bit deeper.
208
209
209
210
# Making this more efficient
210
211
@@ -435,7 +436,7 @@ because you don't need to wait for acks, in practice this would be a lot faster.
435
436
436
437
# Conclusion
437
438
438
-
We hope to continue grinding on the performance, as well as testing and
439
+
We'll continue grinding on the performance, as well as testing and
439
440
verifying the security of our implementation, in order to make this protocol
440
441
a trustworthy alternative to our current DKG.
441
442
We expect that the one round protocol will be a lot simpler to use,
<p>We've completed an initial implementation of the Golden protocol, which lets you perform a DKG in just a single round. Going from two rounds to just one is a huge improvement in simplicity and performance.</p>
137
143
<h3><ahref="/blogs/phone-a-friend.html">Phone a Friend</a></h3>
<p>Instead of every single validator carrying out the work of decryption, a well-provisioned helper can do the work once and broadcast hints to the network which will be used to quickly verify the result.</p>
143
-
<h3><ahref="/blogs/golden.html">A Golden Ticket to One-Round DKGs</a></h3>
<p>We've completed an initial implementation of the Golden protocol, which lets you perform a DKG in just a single round. Going from two rounds to just one is a huge improvement in simplicity and performance.</p>
149
149
<h3><ahref="/blogs/route-66.html">Get Your Blocks on Route 66</a></h3>
0 commit comments