The result was expected: it was much cheaper to validate ring signatures on-chain, but we noted another problem compared to the previous implementation using secp256k1 — our tools to generate ring signatures were now many times slower and we were still very concerned about the impact of running transactions which cost nearly 1 million gas on Ethereum.
So, why is it that the
ecmul operation introduced in Ethereum as part of the Byzantine release costs 40,000 gas? Even though the ECDSA key recovery operation
ecrecover requires several underlying
ecmul operations but costs only 3000 gas?
There are really two problems:
- The high-cost of the BN-256
ecmuloperation makes it too costly and inefficient to allow widespread adoption of competitive privacy technology.
- Choosing only BN-256 over libsecp256k1 isolates Ethereum from the rest of the industry, preventing code reuse and cross-chain compatibility.
There is a solution
Matthew Di Ferrante proposed EIP 603, which would introduce
ecadd opcodes for the secp256k1 curve, but the Ethereum foundation favoured to only implement BN-256.
What are the advantages of using secp256k1 over BN-256?
- Cheaper gas cost, ring signatures, anonymous voting and privacy becomes affordable
- Pervasive industry support, battle-tested code and libraries
- Compatibility with the
In short, imagine if
ecrecovercost 120,000 gas just because the underlying library to verify signatures was unoptimised and slow even though the exact same thing existed in a more widely used, more optimised and well tested library.
What impact would that have on the decentralised exchanges which make up a large percentage of the gas cost today, in short — I don’t think Ethereum would have as much appeal because it would simply be too expensive to perform a decentralised exchange.
Let’s look at the average Gas costs for a privacy enhanced Mobius transaction on Ethereum:
- Deposit: 150,000
- Withdraw: 750,000
With a ring size of 8it costs 600k gas to Deposit and 6million Gas to Withdraw, given that the block Gas limit on Ethereum is 8 million this would probably have to be spread across multiple blocks and could significantly disrupt other transactions (similar to CryptoKitties) if any privacy technology gained significant popularity.
But, why is it slow?
Why is the Go BN-256 library so slow? And why are the other libraries used by Parity and cpp-ethereum also slow? Brendan Mcmillon, the author of CloudFlare’s fast BN-256 library, elaborates in a short article. TL;DR high-level languages are horribly inefficient for many things, but careful optimisation can result in a 15–25x speed improvement simply by taking advantage of the underlying processor instructions designed specifically for these kinds of tasks.
CloudFlare’s BN256 library for Go increases the performance by 15–25x, bringing it close to the highly optimised and widely used secp256k1 library. Other implementations used in smartcards perform equally as well as secp256k1 according to this multi-vendor benchmark.
According to ethernodes.org over 90% of the network uses x86_64 processors, therefore we would like to open the conversation to use widely available optimisations for this specific architecture.
Harry Roberts, developer, Clearmatics
Tweet us @Clearmatics