Number of parties in threshold ECDSA

Developers CDK
1

Hi, I’m wondering how many parties are there in ICP’s tECDSA implementation, and what’s the protocol that is used. I saw this in the documentation:

The fees for the ECDSA signing API are as defined below. The threshold ECDSA test key resides on a regular-sized (13-node) application subnet, while the threshold ECDSA production key resides on an about 30-node-sized fiduciary subnet. The subnet size of the subnet where the threshold signature key resides and the signatures are computed define the resulting cost. The size of the subnet of the calling canister does not matter for the fees. For costs in USD, the USD/XDR exchange rate as of of November 23, 2022 has been used.

So I think this means there are 30 parties, but I’m not familiar with a protocol that can handle a 30-party tECDSA signature, at least without it taking an obscene amount of time to generate a signature. I know THORChain limit their vaults to up to 20 parties because of that, so curious what’s the story here? Maybe only a few nodes hold MPC shares and participate? Perhaps you’re using some new tECDSA protocol I’m not familiar with?

Thanks and really cool diving into what you built!!

2 Likes
2

Hi! The ICP implements the tECDSA signing protocol by Groth and Shoup (Design and analysis of a distributed ECDSA signing service). Currently, the tECDSA signing service on the ICP is deployed on subnet pzp6e, which consists of 28 nodes, and all nodes participate in the tECDSA protocol.

3 Likes
3

Cool thanks for the reply, skimmed through the paper, I’ll take a deeper look later! A couple of initial questions:

  1. I’m assuming since it is asynchronous, there is no identifiable abort like in gg20 - is that correct? How does the protocol deal with an adversarial scenario where a sophisticated group (less than a third) of adversarial nodes attempt to DoS the network? I would assume running retries with different subsets of 2/3 is impractical (given mCn for 19 out of 28 is in the millions)? Is there a different way of detecting and punishing malicious nodes, or to stop a DoS attack?
  2. What are the current benchmarks for generating a signature with 28 participating parties using this protocol? Does it take milliseconds, seconds, minutes? Any data I can review?

Thanks again for all the answers!

1 Like
4
  1. I’m assuming since it is asynchronous, there is no identifiable abort like in gg20 - is that correct? How does the protocol deal with an adversarial scenario where a sophisticated group (less than a third) of adversarial nodes attempt to DoS the network? I would assume running retries with different subsets of 2/3 is impractical (given mCn for 19 out of 28 is in the millions)? Is there a different way of detecting and punishing malicious nodes, or to stop a DoS attack?

[GS22] provides not only identifiable abort but also guaranteed output delivery. Regarding DoS scenarios, maybe someone else has deeper knowledge about that.

  1. What are the current benchmarks for generating a signature with 28 participating parties using this protocol? Does it take milliseconds, seconds, minutes? Any data I can review?

Currently, the throughput is slightly more than 1 sig/s. But this is being constantly improved.

1 Like
5
  1. I’m assuming since it is asynchronous, there is no identifiable abort like in gg20 - is that correct? How does the protocol deal with an adversarial scenario where a sophisticated group (less than a third) of adversarial nodes attempt to DoS the network? I would assume running retries with different subsets of 2/3 is impractical (given mCn for 19 out of 28 is in the millions)? Is there a different way of detecting and punishing malicious nodes, or to stop a DoS attack?

As @tkachenko mentioned, the protocol ICP uses has guaranteed output delivery. This means that as long as < 1/3rd is malicious, a signature will be generated. Maybe to give some intuition: there is no need to first select some subset that then all have to participate to create a signature (which you hint at with “given mCn for 19 out of 28 is in the millions”). Instead, all nodes of the 28-node signing subnet realize a signature request was made, and all honest nodes will then send their shares to create the signature, and this is sufficient to construct a signature, irrespective of what the malicious parties do.

1 Like