Hashgraph Consensus Timing Vulnerability

There is a BLS-based strong common coin that we use at SKALE. Basically a BLS threshold signature of a known message is a common random number

Yes, good point, that is the most common technique, introduced by Cachin in his work https://link.springer.com/article/10.1007/s00145-005-0318-0

The idea is quite powerful and at the same time rather simple, and I believe this is what one should use for reliable randomness generation in blockchain. However, the nontrivial thing is how to generate the threshold keys in a trustless way.

This problem of generating keys has a name: DKG (Distributed Key Generation) and has a long history of research behind it. Summarizing very briefly: essentially all the past approaches work in the synchronous network model (such as Gennaro et al. https://link.springer.com/article/10.1007/s00145-006-0347-3) which is generally agreed to be ill-suited for blockchain applications. The only results that go beyond synchroncity are:

  1. “DKG in the Wild” by Kate et al. https://eprint.iacr.org/2012/377.pdf – it offers a partially synchronous solution, yet is quite heavy: O(n^3) communication per node
  2. Aleph protocol that I’m a coauthor of https://arxiv.org/abs/1908.05156 – offers full asynchroncity, O(1) rounds and O(n^2) communication per node
  3. This work https://eprint.iacr.org/2019/1015 by Kokoris et al. – full asynchronicity but latency up to n rounds and O(n^3) communication per node.