Performance improvement on Elliptic Curve operations

[julien-marchand]

I'm running:

• Which Parity version?: 1.10.0-beta-0a9d41e-20180320/x86_64-linux-gnu/rustc1.24.1
• Which operating system?: Linux - Ubuntu 16.04
• How installed?: via docker hub
• Are you fully synchronized?: yes - using private network (PoA)
• Which network are you connected to?: private PoA (1s - 50M gas)
• Did you try to restart the node?: yes

Actual state
I'm working on a application/platform on parity using PoA.
Network: 50 nodes Parity on 1.10.0-beta-0a9d41e
Consensus: PoA, 1s block time, 20M gas
Transactions: All transactions involve huge solidity calculations: zkp using ecmul and ecadd precompiles on alt-bn128 elliptic curve.
Gas per tx: ~200 * ecmul + 150 * ecadd + 1,3 M (= 1,7 M given our genesis)
My current throughput is really slow: ~0.9 TPS, I suspect it's supposed to be quite faster and I need to speed it.

Improvements / Questions / Suggestions

1. Try to use Parity's Wasm
2. Re-coding a part of my solidity zkp in rust. Assuming that the bottleneck is 100% there, do you know what would be the improvement factor?
3. Use / Wait for integration of secp256k1 as this curve could be faster. Is this on your current roadmap?
4. Use of JITVM? I couldn't find a way to compile docker parity: ubuntu-jit, compile error: cannot compile evmjit. Is it currently supported?
5. Use the same implementation than CloudFlare for bn-128, article here (CloudFlare's Go implementation has been integrated in Geth: pull request). Is this integration in your roadmap?
6. Do you have any other general suggestions to speed up the process? (I came across every configuration option without success)

Steps to reproduce
Command to run 1M ecmul (which, I agree, is only a part of the bottleneck but the rest cannot be published yet).
spec.txt
parity-evm stats --gas 1FFFFFFFFFFFF --chain spec.txt --code 7f2bd3e6d0f3b142924f5ca7b49ce5b9d54c4703d7ae5648e61d02268b1a0a9fb76080527f21611ce0a6af85915e2f1d70300909ce2e49dfad4a4619c8390cae66cefdb20460a0527f00000000000000000000000000000000000000000000000011138ce750fa15c260c052620F42405b60406040606060806000600761fffff1506001900380607057

[pepyakin]

Hey! I don't have answers for the most of the questions, but here is for a few:

• (1) I would say that the current implementation of wasm is quite slow, since it uses an interpreter atm and that interpreter haven't yet seen any work on optimizations.
• (4) remove evmjit #8229

[folsen]

I can try to answer the rest of the questions, but there isn't a satisfactory answer to your overall problem without looking in more details at the code.

2. This is only possible in combination with 1), to which pepyakins comment above applies, the first implementation of the wasm VM has seen focus on safety & correctness, and optimisation is on the roadmap for the future, before then it's questionable how much speedup you'd see (worth a shot though, if you try please share your results).

3. What's on our roadmap in that regard is what's on Ethereums roadmap. However, it's worth considering adding for private chains, please add as a separate issue.

4. No, it's not currently supported. evmjit was an experiment but hasn't seen active development (or use).

5. No we can't integrate cloudflare's Go implementation, though we've looked at it. It's basically just an assembly version for x64 and then it's slow for any other platform. We use https://github.com/paritytech/bn which is a fork from zcash's implementation, though we've added a bit of performance improvements recently.

6. Unfortunately not really anything that comes to my mind, evm has seen a ton of optimisation and there's not much a user can do to speed it up more, the options are to use the wasm VM but then you're into experimental territory, we would want to work with you to make it run well on wasm, but can't make any promises at this stage.