Threshold ECDSA Signatures

[victorshoup]

We have in fact done an initial analysis of the tokenomics and we feel that this will not be a major problem. Based on the cost of paying node providers, we would have to charge on the order of a few cents per signature to not be inflationary. Indeed, if we assume a throughput of 1 sig/sec, 35 nodes in a dedicated signing subnet, and $2000 per month per node, we would need to charge about 3 cents per sig to break even. This is generally in line with what we initially plan to charge.

You are right that 100% utilization is not realistic. Assuming the IC and this feature really take off, we can fine tune things to aim for something realistic, like 25-30% utilization, and still have some spare capacity for surges. Over time, we will fine tune the performance and price, as well as build out several signing subnets with load balancing (“horizontal scaling”). As long as everyone is on board with the idea that the price per sig is on the order of cents (rather than, say, hundredths of a cent), this all seems reasonable, at least to me.

[skilesare]

It does eventually need to be cheap to sign these things. 3 cents sounds cheap until your a service provider signing hundreds of thousands of polygon transactions a day in a gasless model.

[victorshoup]

Understood. But I don’t think the economics of this can be changed much, so dapp developers will have to plan accordingly.

[coteclaude]

@victorshoup

Based on the cost of paying node providers, we would have to charge on the order of a few cents per signature to not be inflationary.

From what I can see, as of today and excluding all voting rewards, there was 2,777,790 ICP paid to nodes providers and total 92,279 ICP burned. The the gap towards the providers is constantly increasing. So I don’t really understand the ‘not to be inflationary’ statement. Am I missing something? Should this be an actual issue to be resolved, if possible? Any plans?

[Zane]

Usage of the network is still not high enough to create deflation

[coteclaude]

To my feel, the more you need computing, the more nodes you need, thus more inflation as well. To be even, it would mean the network is only actually used at 3% (92279 / 2777790). On top, we all know the usage cannot go to 100%.
But if the network is used at 3%, why adding more nodes now?
Would really be happy to see a plan, expectation from Dfinity on this?
Because for me, numbers don’t work and will not work for deflation ever, very far from it. @Kyle_Langham is the expert at numbers but I haven’t seen any study on this.
Show me evidence, if there are.
Really hope I am totally wrong but I cannot see how I can be.

[victorshoup]

I only meant that the threshold ECDSA feature would not make inflation any worse, not that it would do anything by itself to make it any better (unless we charge huge fees for ECDSA sigs so that it would subsidize other costs)

[mparikh]

Personally, I would like to see more fees for the ECSDA feature; simply because it is a market differentiator. Devs should pay more for such a feature. Or put it in the reverse-gas model context, devs should build dapps that use this feature in a novel enough way that it increases their user base.

I don’t think that we should use fees from ECSDA to “subsidize” other features.

[Zane]

I disagree, it should be a cheap as possible as long as the tokenomics allow for deflation with realistic usage, this way devs can use it more easily and for more use cases bringing more dApps and users to the ecosystem, which in turn will cause more cycle usage.

[Kyle_Langham]

Early node providers were paid significantly just after launch, I believe as a result of providing nodes prior to launch and as a reflection of the increased risk at that time. Recently, the rewards paid to node providers has been much lower than last year.

I don’t remember where I documented this a year ago (perhaps Twitter) but my memory is that if the network operated at 100% capacity it would result in a 7x-10x burn to mint ratio.

It’s also possible that the NNS decides to charge more for computations in the future to increase the deflationary pressures. I imagine that wouldn’t be considered until there’s more growth, however.

[Zane]

I have 2 concerns:

• Subnets are quite small right now, so the 7-10x ratio isn’t just optimistic cause it assumes 100% usage at all time but also the average subnet being made of 13 nodes.

• Subnets can currently handle 300GBs of state, that means at 5$ GB/yr it’d only take 1500$/yr to occupy a subnet and make it unavailable to anyone else, effectively wasting a subnet’s capacity and making it inflationary. Has Dfinity thought about a similar scenario?

[tsetse]

This calculates only storage, not computation, right?

[Zane]

That’s right, but there are no guarantees computation will be done on that data or at all. The space might be used for simple storage or as a mean to attack the IC.

Currently we have 35~ subnets, so an attacker could spend 52,500$/yr (1500$ x n of subnets) and waste almost the entire computational capabilities of the IC, I say almost cause already existing dApps would still work but they might encounter some issues, e.g inability to spawn new canisters and on top of that make it impossible for the system to become deflationary.

[dieter.sommer]

@Zane

Is there still room for improvement with future optimizations? What do you consider as “reasonably large”?

I think there is, but it’s getting harder and harder the more we have squeezed out performance of the protocol already already.
I don’t have the exact size of the testnet that was used for this in my head, but if I recall correctly, it was rather close to 30 nodes, so smaller than the one we want to launch on, but not much.

@JaMarco

Can multiple tECDSA subnets be ran in parallel to increase the overall throughput? How would the IC load balance that?

Yes, that’s possible if there’s demand. The feature can scale out horizontally by adding more signing subnets for the same key. The governance for all of this is already part of the initial design and the NNS proposals, but some parts, such as the deterministic load balancing, would still need to be implemented to make this work.
The idea of load balancing would be to determine, for each signing request, deterministically to which signing subnets to send the request to. All signing subnets would be listed in the registry.

[hpeebles]

Can a single subnet only handle a single signing request at a time?
I’m not a cryptography expert but intuitively it seems like these requests should be able to run in parallel.

[Zane]

@dieter.sommer

I think there is, but it’s getting harder and harder the more we have squeezed out performance of the protocol already already.

What’s the biggest bottleneck consesus or complexity of the cryptography involved? If the latter would it be possible in future to optimize by running specific hardware for ECDSA subnets?

Also considering performance degrades with node count, has Dfinity considered implementing a system similar to the one described in the original whitepaper and have only a subset of nodes chosen via VRF each block to reach consensus?

[hokosugi]

I have a question that I have been thinking about for a while after reading the statement in the wiki about the “vast number of derivable ECDSA keys.”
Can T-ECDSA signatures support multiple private keys? For example, can multiple child private keys(BIP32 should be able to generate) generated in addition to the master key also be managed in the ECDSA subnet, so that private keys can be assigned and signed on a per-Canister basis? Or is there only one master private key?
If you are not familiar with cryptography and the question is off-topic, please feel free to skip it.

[diegop]

Hey folks,

Here is a relevant security audits for those interested:

1. "Threshold ECDSA Integration and Bitcoin Canisters - Security Review" by Trail of Bits (third-party security audit #5)

2. "Canister Sandbox Review" by Trail of Bits (third-party security audit #4)

[Manu]

A subnet maintains a single secret ECDSA key, and we can actually use that to derive keys many keys per canister (using BIP32). This means that we only have to maintain one secret key on a subnet, while functionally it’s as if every canister has it’s own keys.

[Manu]

Hi everybody! There have been some concerns about the 1/3rd (f+1 out of 3f+1) threshold for the ECDSA keys on the internet computer, and whether this gives sufficient security. We have taken this feedback seriously and took a step back to revisit different approaches to increase the security of threshold ECDSA.

First, some background info. It is very difficult to make threshold ECDSA signatures, much more difficult than eg threshold BLS signatures. We cannot simply set a 2/3rd (i.e., 2f+1 out of 3f+1) threshold for ECDSA signatures like we do for BLS. The best fault tolerance such that we both have liveness and safety from known practical protocols is 1/3rd (i.e., f+1 out of 3f+1). Note that this fault tolerance is actually the same as the consensus protocol ICC uses: even though we use 2/3rd threshold BLS keys, the protocol can only be proven safe and live with up to 1/3rd corruptions, which is also the theoretical optimal threshold for asynchronous consensus. Despite this, you could argue that practical attacks on tECDSA are perhaps easier to perform than attacks on ICC: for tECDSA, you’d have to steal the key material of 1/3rd of the nodes and obtain the full signing key, while for ICC you’d either need an coordinated active attack controlling 1/3rd of the nodes and some control over the network connection between nodes, or you need to steal the key material of 2/3rd of the nodes which would let you sign anything.

So how can we make things even more secure? There are many different approaches:

1. More nodes & larger subnets. This is conceptually the simplest approach. Work is in progress on this front, and you can follow the status in this forum thread.
2. Shuffle nodes between subnets. This has been suggested by the community and is an appealing idea: it could mean that an attacker cannot target a specific subnet as the membership constantly changes, and the only way to corrupt a subnet is to compromise a sufficiently large fraction of the overall IC nodes, meaning each subnet becomes more secure as the IC gets bigger. However, I believe that we first need more independent nodes before shuffling actually adds security.
3. Enable AMD SEV. Enabling some form of SEV could make it much harder to break into a node. Currently, the current IC nodes are of the “Gen-1” hardware specifiation which only support SEV-ES (and is no longer available) while new nodes will have Gen-2 hardware which support SEV-SNP. Gen-2 hardware (specification) is currently available. The relevant point here is that Gen-1 hardware with SEV-ES do not provide the security guarantees we want as they do not protect memory integrity and are thus vulnerable to attack by privileged users while Gen-2 with SEV-SNP does provide memory integrity and the ability for external parties to more easily validate the integrity of the system.
4. Increase tECDSA security threshold.While we know that we cannot increase the fault tolerance for both safety and liveness, we could sacrifice some liveness fault tolerance to increase the safety fault tolerance. A concrete example: a 34 node subnet can currently tolerate 11 corrupted nodes, meaning we can still sign, and the secret key is not compromised. We could change the thresholds to tolerate 15 corrupted nodes, making it harder for the attacker to steal the secret key. However, this means we can only tolerate 3 nodes that are unavailable. If a 4th node is offline, the subnet cannot create ECDSA signatures anymore.
   Since being unable to sign with a key is almost as bad as an attacker compromising a key, we think that this approach is not the best solution to apply on all subnets. It could be a promising solution to let smaller subnets also maintain the ECDSA key using a higher threshold (such that we can scale out the signing capabilities), while larger subnets still maintain the ECDSA key with a 1/3rd threshold. In this way, if a smaller subnet can no longer create ECDSA signatures due to too many failures, the larger subnets still hold the ECDSA key and can reshare it to other subnets.
5. Regularly reshare the ECDSA secret key. The idea is that nodes can regularly update their encryption key used to decrypt their secret key shares in the distributed key generation protocol that maintains the ECDSA key. The ECDSA secret key shares will be reshared every time membership changes or any of the members updated their encryption key.
   The result of this approach is that if an attacker steals an ECDSA secret key share or a DKG decryption key from a node, it will only be usable for a limited amount of time, because the keys refresh regularly. This means that an attacker would have to steal the key material of 1/3rd of the subnet nodes within a small time window, which seems much more complicated to pull off.
   One caveat is that the node signing key could also be stolen, and an attacker could try to slowly steal node signing keys, and then quickly register malicious encryption keys on behalf of those nodes, such that it can still steal the ECDSA signing key. To avoid this attack, we can limit how frequently node encryption keys can be updated for nodes in one subnet. An attacker can then only slowly try to register malicious keys for nodes. However, this is a very visible attack, and nodes can complain upon seeing a malicious key registered in their name, upon which they can be removed from the subnet.

The first three options all require a bit more time, as it involves new hardware and onboarding new node providers. So while we are actively working on 1 and 3, I do not expect they will help strengthen the ECDSA security this calendar year. Option 4 is mainly helpful to allow smaller subnets to also sign, when we have larger subnets that back up the key with the standard threshold. Initially we plan to only use large subnets, where this idea does not help. Option 5 however meaningfully improves the security of ECDSA and can be implemented more quickly.

Planned next steps.

Our proposal is to implement option 5 now, and then release a “production ready” ECDSA key, which will be maintained on large (e.g., 34 node) subnets. We can further improve the security of this key when more nodes are added and increase the subnet size. However, when a new feature is added that significantly improves the security (eg, SEV enabled replicas), we can also consider creating a new ECDSA key that has always been at this level of security, and applications can then choose whether they want to migrate to this key.

Please let us know what you think!