Our paper on eprint, Design and analysis of a distributed ECDSA signing service, gives a detailed comparison between the protocol we implement on the IC and several others, including GG20. The main differences between ours and GG20 is that ours provides both liveness and security in an asynchronous setting even with some crashed or malicious nodes, while GG20 does not. The statement made in GG20 about asynchrony is very limited: it just says that the online stage consists of a single round, so does not require any coordination. However, that is all it says. First, if any of the parties in the subcommittee designated to produce signatures is crashed or corrupt, then no signature will be produced, so liveness is lost. Second, in the offline preprocessing stage, if any party in the subcommittee is crashed or corrupt, then also no signatures will be produced. The claim that the protocol provides “identifiable aborts” inherently relies on a synchronous communication model, since on an asynchronous model, there is no way to distinguish between a party that is slow or temporarily disconnected from the network from one that is crashed or corrupt.
(By the way, our protocol also has an online stage that consists of a single round, and so does not require any coordination.)
Let me be clear: the protocol in our paper is just as good or better on almost every performance metric than GG20 – a fully optimized version of it (which we have not yet implemented) will be just as good or better as that in GG20 in terms of communication and computational costs, and it provides guaranteed liveness and security with any synchrony assumptions.
I think the most important difference between GG20 and our protocol is that GG20 can provide security with much higher signing thresholds – even n out of n, whereas ours can only achieve n/3 our of n (although there are some variants that can get us close to n/2 out of n that we are exploring). This difference is a tradeoff: achieving higher thresholds inherently comes at the cost of sacrificing liveness and possibly imposing synchrony assumptions. Since the general model for the IC is to provide security and liveness with up to n/3 corruptions is an asynchronous (or sometimes partially synchronous) setting, we made the conscious decision to adopt this model as our design criteria for threshold ECDSA as well, and try to get the most performant protocol possible within those design constraints.