Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is BFT Consensus really a big limitation to use Pedersen's DKG? #45

Closed
pool2win opened this issue Aug 29, 2024 · 4 comments
Closed

Is BFT Consensus really a big limitation to use Pedersen's DKG? #45

pool2win opened this issue Aug 29, 2024 · 4 comments

Comments

@pool2win
Copy link

I want to understand why the consensus / BFT broadcast requirement is considered such a big drawback - especially for small, permissioned, known membership setups?

We can use multiple bft consensus protocols that work well in permissioned and known membership setups. For example, if we know that we have these seven participants and that the we know that the BFT consensus is limited to between these seven participants. In such cases, using simple protocols like Raft under partial synchrony assumption and HotStuff under an asynchronous assumption will suffice to meet the Pedersen's DKG requirement.

With known parties of limited size is it not sufficient to run Pedersen's DKG instantiation using known and well implemented consensus protocols? Further, we also have BFT consensus protocols that scale well to group sizes of up to 10 or so and are not dependent on a co-ordinator.

@jonasnick
Copy link
Collaborator

Hi @pool2win.

Requiring BFT agreement is a drawback for two reasons:

  1. In the synchronous setting, BFT protocols typically require that less than a half of the signers are dishonest ("faulty") and, in the asynchonous setting, less than a third of the signers must be dishonest. One design goal of the BIP is that it tolerates any number of dishonest signers f by setting the threshold t = f+1.
  2. Specifying a BFT protocol in the BIP would add significant complexity compared to the relatively simple CertEq protocol.

@real-or-random
Copy link
Collaborator

In such cases, using simple protocols like Raft under partial synchrony assumption and HotStuff under an asynchronous assumption will suffice to meet the Pedersen's DKG requirement.

As pointed out in the previous comment, the "consensus" part of the BIP is just a handful of LoC. What's the complexity of a HotStuff implemenation? I assume it's in the order of magnitude of thousands of LoC, not counting the dependencies.

Sure, if your system already has a small, permissioned setting, and you anyway have some majority assumption, then BFT sounds natural. But even then, you need to compose the DKG with the BFT and reason about the security of the resulting system. Probably not trivial.

@pool2win
Copy link
Author

Thanks for your responses.

I agree composing BFT consensus with a DKG protocol will be complicated and probably not the right direction.

I am intrigued by the comments on ZcashFoundation/frost#577 about echo broadcast not being sufficient as well. I have left a comment there to continue the discussion around using echo broadcast.

@real-or-random
Copy link
Collaborator

Let me close this issue then. Thanks for your feedback in #47, I'll take a look at this soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants