VM: Analyze rustbn.js native implementation possibility

[holgerd77]

The rustbn.js is rather somewhat of a submodule of the VM and is used for the ECADD, ECMUL and ECPAIRING precompiles.

This is realized as a WASM precompile from Rust and there is atm no one to really maintain this library.

Since this decision to go this way (and the subsequent implementation) has been made 4 years ago along the Byzantium hardfork implementation we might want to re-analyze the current native JS library situation and if more direct/native integration in the VM is possible.

Otherwise it might also be useful to integrate the package into the monorepo (it's rather not much code + no tests to be run I guess).

[jochem-brouwer]

So the question is either we move the WASM into our repo, or we write this ourselves in JS?

[axic]

The rustbn.js is rather somewhat of a submodule of the VM and is used for the ECADD, ECMUL and ECRECOVER precompiles.

Typo: it is used for ecadd/ecmul/ecpairing. ecrecover is a different curve.

This is realized as a WASM precompile from Rust and there is atm no one to really maintain this library.

Well, the thing is it required no changes, hence no updates to it.

My 5 cents: I think it will be quite a challenge writing a bn128 implementation, including pairing, in native Javascript. Can't comment about the speed, but I'd expect the pairing to be likely on the edge regarding speed.

[axic]

Could consider using iden3's webassembly implementation (https://github.com/iden3/wasmsnark), if this is still driven by the licensing question. It is not a drop-in replacement though.

[holgerd77]

@axic thanks, that helps a lot! We'll be more cautious here on an eventual decision.

[holgerd77]

Will close this after the feedback from @axic