Host functions to support EVM

[arhag]

Host functions enabling specific cryptographic operations need to be added as a protocol feature in Mandel to support the EVM runtime (and especially the EVM precompiles):

• Big integer modular exponentiation. (Supports EVM precompile ModExp address 0x05. See https://eips.ethereum.org/EIPS/eip-198 for details.)
• Add, multiply, and pairing check functions for the alt_bn128 elliptic curve. (Supports EVM precompiles BN128Add address 0x06, BN128Mul address 0x07, and BN128Pair address 0x08. See https://eips.ethereum.org/EIPS/eip-196 and https://eips.ethereum.org/EIPS/eip-197 for details.)
• BLAKE2b F compression function. (Supports EVM precompile Blake2F address 0x08. See https://eips.ethereum.org/EIPS/eip-152 for details.)
• Keccak256 hash function. (Supports EVM KECCAK256 opcode.)

We can also consider adding a variation of the host function to do ECSDA public key recovery which returns uncompressed public keys and which does not abort the transaction if the signature is bad. This would allow the EVM runtime to support the precompile ECRecover address 0x01 in way that allows the runtime to be more compliant and more performant. However, this additional host function is not necessary for Mandel 3.1 since we can leverage the existing recover_key host function. That may be the approach to go with for the time being in the interest in time as well as to consider an alternative way to provide this functionality that is more general than another recovery key host function, e.g. providing add and multiply primitives instead for that elliptic curve.

Another host function is needed to support the EVM runtime which should be considered as part of a separate protocol feature:

• Get current block height/number. (Supports EVM NUMBER opcode.)

It is possible to get the current block height through a roundabout way without a protocol feature. An updated system contract can keep track of the last block height using the onblock action which is given the previous block header each block. However, that approach is not guaranteed to be reliable and it would be simpler to just add a new host function in a release where many other protocol features are being included.

[heifner]

Related:
EOSIO/eos#10831
EOSIO/eos#6718