Signature queue for key ecdsa:Secp256k1:key_1 is full

[cryptoschindler]

I think the confusion with 18 call contexts stems from this line, which does not actually set the limit for call contexts but rather resembles a protobuf field number for uniquely identifying a field within a message.

I think the limit is defined here and indeed 20 per subnet. I’d guess the reason this cap is lower than usual queue limits is that the amount of t-ECDSA signatures that can be created per second by one subnet is still less than 10. A “simple” way to increase throughput would probably be to create more signing subnets.

Some older threads about this topic

Exploring the Potential of Zero-Knowledge Rollups (ZKR) for Improved Cross-chain Efficiency on the IC

Thanks, @apotheosis, for the write-up! One aspect I’d like to bring up initially is that the current restriction to ~1 sig/s stems from the fact that the current implementation of tECDSA has not been optimized for speed; some aspects are intentionally kept simple for now. As the implementation matures further, we do expect significant speed-ups. That said, the protocol is inherently complex (simply because ECDSA is weird) and the rate of signatures per subnet will always be limited. For zkSNARK…

Technical Working Group: Scalability & Performance

To clarify: the limit you point to is the current throughput of tECDSA signatures per second that a subnet can produce (you need those in order to submit BTC transactions so of course the limit on those sort of implies a limit on the BTC transactions themselves). AFAIK, the current implementation of tECDSA is not super optimized, so I would expect that this limit can be increased eventually. Likely there is going to be some limit on what a single subnet can do (the protocol is quite complex) bu…

Threshold ECDSA Signatures

Indeed, this is very much a pity and I want to apologize for the inconvenience, but here are two key reasons why we cannot release the GA version now: We need to get performance to an acceptable level for 34-node or larger subnets. We can currently do 1.5 signatures/s on a 13-node subnet and performance decreases faster than linear with the replication factors. Thus, engineering has to solve some challenge here which does take some time. The performance was impossible to assess upfront, theref…

Tagging some people that should be able to shed some more light on the current limitations, future improvements and how to possibly work around them on the application layer.

@dieter.sommer @Manu @dsarlis @bjoern