Extend the Math API with EVM precompiles

[artob]

To speed up performance and lower the cost of EVM-as-a-contract, this adds several functions to the contract runtime Math API in order to support implementing the standard EVM precompiled contracts:

• Add RIPEMD-160 support to the Math API #3922 ripemd160() (RIPEMD-160 hash function)
• Add BLAKE2b support to the Math API #3953 blake2b() (BLAKE2b hash function)
• Add ECRecover support to the Math API #3921 ecrecover() (ECRecover ECDSA signer recovery)

References:

• https://ethereum.stackexchange.com/questions/15479/list-of-pre-compiled-contracts/15483#15483
• https://docs.soliditylang.org/en/latest/units-and-global-variables.html#mathematical-and-cryptographic-functions
• https://en.wikipedia.org/wiki/RIPEMD
• https://en.wikipedia.org/wiki/BLAKE_(hash_function)
• https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ECDSA.sol

[ailisp]

Code looks good. This is considered as a protocol version change, so we need to introduce a new protocol feature & protocol version and import it with guard:

nearcore/runtime/near-vm-runner/src/imports.rs

Line 282 in 483af53

// #["protocol_feature_evm", EVM] test_api<[a: u64] -> []>,

[artob]

@ailisp Please re-review, this is substantially closer to graduating from draft status.

The top open question I still have is how, concretely, I should go about measuring and assigning the gas costs for the new functions. (Also, the runtime-params-estimator exits with a failure, so I may still be missing something in that regard.)

Code looks good. This is considered as a protocol version change, so we need to introduce a new protocol feature & protocol version and import it with guard:

Thanks. I've guarded everything new behind the EVM feature for now.

[ilblackdragon]

I also think this should be a separate feature from EVM, so that it can be released separately from the full precompiled EVM.

This can be (and probably should be) batched with bn128 host functions.
And as I mentioned a really useful would be to have host function for current storage cost.

[ailisp]

Looks like runtime param estimator tests failed because it isn't compiled with protocol-feature-evm enabled, so those new functions isn't exported:

https://buildkite.com/nearprotocol/nearcore/builds/5739#17b95e82-bc41-4b95-b620-44d8c5b42c89

I suggest:

1. change ci config to make it compile and pass. On CI it is using Time metric, which is fast to run, but isn't the one we use as actual cost.
2. Actual cost we use "count of CPU instructions on qemu", this takes 6+ hours to run, boot a cloud instance (at least 4 cpu 16g ram) and update runtime-params-estimator/estimate.sh to compile with protocol-feature-evm. Then run estimate.sh. Steps are here:

Use this to build a docker image:
https://github.com/near/nearcore/blob/master/runtime/runtime-params-estimator/emu-cost/README.md#usage

once in docker, disregard above steps, simply run estimate.sh
https://github.com/near/nearcore/blob/master/runtime/runtime-params-estimator/estimate.sh

[abacabadabacaba]

There is a problem with the BLAKE2b function added here. While this PR adds the whole BLAKE2b function, what EVM should provide to smart contracts is the compression function F (see EIP 152), and you can't use the whole BLAKE2b function to implement just the compression function.

While we can add just the function F as a host function, it would be preferred that the function is usable not just for the EVM but also for other contracts that may want to compute BLAKE2 hashes. So, I think that a better idea is to add a function that evaluates a sequence of calls to the compression function in a way similar to how the BLAKE2 function itself does it. Such function could be used to perform a single compression function call (as needed by the EVM), and it can also compute the BLAKE2 hash itself in a single call.

Another thing that I would have changed is to charge gas proportional to the number of blocks, not bytes.

[artob]

@joshuajbouw I will not have time to come back to this for a bit, so please take over this task and push it to completion. The subtasks I currently know about include the following:

• Investigate if/how we can batch this with feat: Add precompiled contracts for alt_bn128 curve [rebased] #3971, already merged (and also a good example of adding new host functions)
• Add any and all missing feature guards, as per @ilblackdragon's comment
• Change the feature guards in this PR to be based on a new distinct feature name, as per @ilblackdragon's comment
• Flesh out the ecrecover_10k() test case for the runtime-params-estimator, as per @ailisp's comment
• Add support for EIP-152 (the BLAKE2 F compression function) as per @abacabadabacaba's comment; I would retain the already implemented BLAKE2b function, so this would be a new function
• Measure and assign the gas costs for the new functions using the runtime-params-estimator, as per @ailisp's comment; for any support on that, ping @ailisp
• Move the PR out of Draft status and re-request reviews once ready to go

[joshuajbouw]

Ok, yes will go through all that today and this weekend.

[joshuajbouw]

Had to import two additional crates num-integer and byte-slice-cast, they are listed in our Cargo.lock as our dependencies do use it as well. Would be great if we had our own library or something similar to add in this missing functionality / unstable API from std.

[joshuajbouw]

Closing in favour of a new PR with blake2 descoped as we have to ensure that it is completely correct. Ecrecover is the most important method that we need in the PR for Aurora.