Proposal: 50x Price reduction for chain-key ECDSA signing / threshold ECDSA signing

Dear community!

The Internet Computer’s chain-key ECDSA signing capabilities based on threshold ECDSA are one of the best, maybe even the best, USP of the platform. Threshold ECDSA allows smart contract to compute ECDSA signatures on chain, with the private key being secret shared among many replica nodes. This allows for integrating with any other blockchain that supports ECDSA as signature scheme for singing transactions.

The current pricing for computing one threshold ECDSA signature is ~26.15B cycles on a high-replication subnet (~ 3.4 USD cents) and 10B cycles for the test key on a 13-node subnet.

This price is still rather high and prevents certain use cases to be realized on the Internet Computer. In this forum post we propose to reduce the cost for computing a threshold ECDSA signature substantially. The reduction is envisioned to implemented immediately, before protocol throughput improvements are rolled out.

Current pricing

The current price is based on benchmarks representing the current threshold ECDSA performance, with an optimization that increases throughput by ~2x being already anticipated in the price, but not yet implemented. The price to be cost covering in the applied pricing model (recovering the subnet cost) would be ~2x the current price, i.e., ~6.8 USD cents per signature.

Short-term protocol improvements (1/2-year timeframe)

@victorshoup has proposed multiple improvements to the implementation of the current threshold ECDSA protocol that are expected to result in a 10x improvement of the throughput of threshold ECDSA on the same subnet configuration (hardware, subnet size etc.). Two notable improvements are batch processing and parallelizing the crypto operations to multiple cores. These improvements are planned to be tackled by our engineering teams, with a timeframe of around 1/2 year to realize those 10x gains in throughput.

Considering the implementation of those improvements, we can expect the throughput of threshold ECDSA to increase by 10x in the next 1/2 year to 5 signatures / second, the baseline being the current throughput of 0.5 signatures / second.

Long-term protocol improvements (5-year timeframe)

DFINITY furthermore has ideas on how to dramatically improve throughput of threshold ECDSA using a completely new protocol architecture, requiring a complete reimplementation of the protocol. The expected throughput improvements using this are in the range of 20x–100x.

The protocols for this are not designed yet and the improvement factor is a rough estimate of where we could land. Performing the protocol research and implementing the resulting new protocols is not in the near-term scope of work of the Foundation. This is work to come in the 5-year planning horizon.

Considering these improvements, we can expect the throughput of threshold ECDSA to increase by 20x–100x in the next 5 years solely due to protocol improvements, the baseline being the current throughput of 0.5 signatures / second.

Reduction in node operating costs

Over the time horizon of 5 years, a notable decrease of compute, storage, and connectivity cost can be expected. This will yield a constant factor that is hard to predict, but something in the range of 2x or more seems very reasonable to materialize in practice.

  • CPU production costs reduce over time within a given semiconductor process, meaning lower cost for buying the chips for server manufacturers or node providers. Moving to more advanced nodes means initial large investments for setting up new fabs by the semiconductor companies, but with cost decreases over time, this has so far always resulted in price reduction of CPUs. Note that Moore’s law has been slowing down, but has in no way come to an end, and is not expected to in the next 6+ years.
  • Flash has seen steep price decreases over recent years and further decreases are to be expected within the next 5 years.
  • Global Internet bandwidth has been growing rapidly in the recent years, increasing competition and driving prices down. Thus, bandwidth prices for IP transit have been going down in almost all region and this is a trend expected to continue in the coming years, particularly in the now still expensive regions where the IC will receive new nodes.

For the considered 5-year timeframe, I expect at least 2 new generations of IC nodes to be defined. No one knows now how these generations will look like, but clearly the cost per MIPS and per TB of storage will be lower than today, so will be connectivity cost when hosting them in data centers. Improvements in cpu fabrication technology will also drive power consumption per operation down, resulting in lower direct power cost and additional reductions in indirect cost such as cooling.

In a successful IC ecosystem, which is the assumption we are working with, one can expect the node provider business to become more competitive so that the spectrum of price quotes for different node providers and regions will narrow and the average price paid for a node globally will move towards the lower end of this spectrum. Similarly, I would expect that the node provider rewards in relation to investment would reduce further from the still very generous earnings per year for a node in a successful Internet Computer ecosystem.

Taking all of those cost reductions for compute, storage, and bandwidth into account, as well as expected reduced node operating costs in terms of ICP payout, this would give a reasonable factor of reduction over the next 5 years in ICP paid out per node per month. A 2x–4x improvement sounds more than reasonable to assume here.

Further, more aggressive approaches to bring the node cost for nodes running threshold ECDSA down could be to use specially-tailored nodes for this purpose that save on NVMe and RAM cost, thereby reducing the node cost by a further solid constant factor. Nodes with FPGA-based accelerators for the required operations may further help drive performance up and cost down substantially. None of this is currently planned to be done for the reasons of resulting in a non-homogeneous node pool, but is mentioned here for completeness of how threshold ECSDA-related costs can be driven down further if necessary to make best possible use of this feature of the IC.

Adoption and re-pricing of threshold ECDSA

The current cycles pricing, even though it anticipates already a 2x improvement in throughput that is pending implementation, is too costly for different use cases related to integrating with low-gas-fee blockchains and also stablecoin use cases on the Internet Computer. Thus, the current price is an inhibitor to adoption of exciting projects that can help the ecosystem grow, while growth of adoption is what we are in clear need of.

To facilitate wider adoption of threshold ECDSA signing on the IC and help the IC at large, we propose to decrease the cycles price for a signature on the production subnet by a factor of 50, the benchmark price being the 26.15B cycles (~3.4 USD cents) per signature. The new price would thus be around 523M cycles or 0.068 USD cents per signature.

The current implementation will be improved to yield a throughput improvement of about 10x to around 5 signatures per second in the next 1/2 year. For the longer-term future, we can expect an up to 100x improvement in throughput with a completely different protocol architecture and a reimplementation of the protocol based on this novel architecture.

Considering the reductions in node costs and operating costs in a more competitive environment and resulting reduced paid out rewards per node as argued above together with the expected protocol improvements, we expect that the proposed reduction of 50x is well within where the IC will be in the fast-moving technology landscape given the above-discussed improvements.

The main motivation for this proposed price reduction is to get adoption of threshold ECDSA for new use cases for which it is not applicable given the current per-signature pricing.
for

Conclusion and call for action

This price reduction proposal is targeted at helping the IC ecosystem to grow further and to better leverage one of its strongest weapons — threshold ECDSA. The main risk associated with this proposal is DoS against the threshold ECDSA feature. However, the gains to be expected for the IC ecosystem may well outweigh the risks.

Let me know what you think about moving forward with this proposal.

26 Likes

Reading this felt like someone read my mind over the weekend… I’ve been doing cost calculations on t-ECDSA for the last couple of days, and for the use case I’m working on, there would need to be two off per user transaction, not including the “unknown unknowns”. These costs quickly add up in successful applications, making it harder for a newly born, pre-PMF protocol to survive until PMF. So glad to hear this 50x reduction. Composability needs affordable t-ECDSA.

2 Likes

Projects like yours where the current pricing seems too expensive are exactly the reason why this proposal has been put up for discussion.

Happy to hear opinions of other builders as well, and of course also of those with a critical opinion towards this proposal!

3 Likes

Big thank you for? being DFINITY’s affiliates or how DFINITY made a last minute annoucement about Toniq’s KYT and their insider operations?

You are mistaken Dieter if you think DFINITY can gaslight us with rubbish excuses and reasons. DFINITY’s actions indicate corruption. In a healthy economy, ethical economists call this Insider Trading.

  1. No one asked Toniq to provide API other than DFINITY.
  2. Many teams building on this platform wanted the KYT to be a service offered by Applications not DFN affiliates.

DFINITYs design is flawed and full of loopholes just like the many other major features released over the two years.

Other flawed features include

  • SNS - First SNS-1 got Drained by 51% attack
  • Neuron Fund/Community Fund
  • Voting Rewards
  • Maturity Modulation
  • Token Standard developments

so maybe DFINITY can focus on building decentralized systems for now isntead of misleading community on how great their crypto and decentralization is.


Doesn’t DFINITY fund Toniq with cycle ops, marketing and grants?

If I am not wrong, DFINITY pays toniq labs 20,000 cycles for their asset hosting every month

that translates to 25,000 USD every month just for hosting assets.

we do not know how much DFINITY funds toniq for this feature precisely. Note that the fees are paid in ckSats not cycles or ICP (which are worth less due to inflation and poor decentralization standards)


while this is true, DFINITY bashes AWS on a daily basis but hosts Petabytes of Data on AWS.

Sorry if it came out wrong, but we don’t have a soft spot towards hypocrisy. We won’t be thanking any rug pull organizers and corrupt builders who have repeatedly rugged their own users and community.

You can either correct us here or resort to censorship. We believe DFINITY would choose the latter like it always has. Can you explain how this is offtopic?

2 Likes

@Artemi5 This is off topic, so please remove it here. Thanks!
This forum topic is only for discussing the reducing in cycles pricing for t-ECDSA.

Who designs and develops t-ECDSA?

Some links related to the design:

Who are the stakeholders involved and manage components of the protocol?

Being a cross-cutting protocol, several teams were involved in implementing different parts of the stack. The crypto team (which I lead) implemented the cryptographic protocol, the consensus team was responsible for the orchestration of the protocol and its integration with the consensus protocol, the execution team to implement the system API and dealing with the routing of requests, the NNS team for the changes needed for the registry… and many others.

Who decides the cost?

This post it is literally asking the community about making a proposal to change the costs of the protocol! It would be nice if we could keep the discussion around the main topic.

Who writes and pushes the code? a to z execution.

The code is opensource and you are very welcome to review it here. Since you have been very active in the forum today, I am sure you came across proposals for new IC releases, so you are probably already familiar with the process. Btw this is off-topic as it is the rest of the questions you asked here, and many others you posted elsewhere.

3 Likes

This topic is temporarily closed for at least 4 hours due to a large number of community flags.

This topic was automatically opened after 4 hours.

We would like to know the answers for these questions. Particularly the direct stakeholders involved and their stake. Since this is a “Public” feature and was solely developed by DFINITY, it is DFINITY’s responsibility to answer the questions.

We never saw a KYT post or price discussion for ckBTC until the feature had been created and finalized by DFINITY

You failed to answer questions and are being vague about the stake holders. If only DFINITY’s researchers were involved, doesn’t it seem centralized to you?

If Stake holders outside of DFINITY were involved, mention them here.

2 Likes

Hi, can someone tell me the current status of this proposal? Thanks!

1 Like

Very good question, let me give you the current status.

When we made the proposal originally, the support inside DFINITY was not overwhelming due to the large load of other new features that the teams that would be involved here should work on. Just some examples are threshold EdDSA and Schnorr and the required generalizations to the current threshold architecture to implement them (e.g., to be able to store multiple threshold keys per ICP subnet) as well as VETkeys. Those features are considered to be much more important in the near to medium term than the performance enhancements.

However, note that efforts to reduce the latency of threshold ECDSA signatures are currently being performed, targeting protocol and implementation improvements. This addresses a crucial orthogonal aspect of threshold signing performance and will become available in the near future. Threshold EdDSA and Schnorr also benefit from those enhancements once available. Applications will benefit from reduced latency for having threshold signatures computed.

For now, we can consider the proposal of substantial throughput improvements presented in this topic inactive. Implied by this, also a pricing change will not be realized. However, in the future, aspects of this proposal may become relevant again, particularly when the usage of threshold signatures is picking up to a degree that cannot be handled by the current implementation platform constraints.

4 Likes

The prioritization is understandable. When we get back to this topic, I wanted to open up the conversation a little bit more on the consequences of drastically dropping the price for a feature before the cost improvements have actually arrived.

This has to be paid for somehow, so I imagine we would be in some way borrowing from the future to pay for this now. I would guess this is just done through ICP inflation. I just hope that’s well understood and agreeable to everyone involved.

5 Likes

Here’s someone building something significant in the Bitcoin ecosystem, and here’s a basic overview of his requirements. The current threshold throughput is unfortunately quite inadequate: Signature queue for key ecdsa:Secp256k1:key_1 is full - #13 by BennyTheDev

And given that this is just one application with these requirements…I feel that absolutely major throughput requirements might be necessary to service the Chain Fusion dream.

5 Likes

Bitcoin swap and bridge, yes. Everything works well and I am impressed how rock solid everything is. Only thing that needs attention is this imho.

2 Likes

With “this” you are referring to signature throughput?

2 Likes

Yes, sorry for being unclear.