[EVM] re-enable ecrecover as a native function

[benjaminbollen]

No description provided.

[benjaminbollen]

duplicate of #419

[silasdavis]

What is the aim of this?

If the aim is just to support code using ecrecover then adding this back will allow solidity code using ecrecover execute successfully. But it will do nothing to make solidity code that assumes secp256k1 keys are being used give correct results. If you provide it with a ed25519 signature it should provide you with an address, but that address will not be the one corresponding to the signer. So in effect we will just have silently failing code (which is worse than not supporting it at all).

So it seems (unless I'm mistaken) this only makes sense if we introduce/add back support for secp256k1 keys. If we do that, how do we deal with ed25519 signatures? It seems like Ethereum have plans to introduce support for other signatures (ethereum/EIPs#28) so do they have a way to deal with it.

It would be useful to see an example usage of ecrecover in a contract. @VoR0220 could you provide one. I think I need to understand where these signatures are coming from; are they being provided by the EVM (I don't think it is) or are signatures being sent as arguments to functions?

[silasdavis]

Here is an instructive example: https://github.com/edmundedgar/realitykeys-examples-ethereum/blob/master/sponsor/sponsor.sol#L55

        address signer_address = ecrecover(result_hash, v, r, s);
        uint256 result_value = uint256(result_value_hex) / p.base_unit;

        LogSettlementAmount(result_value);
        if (signer_address != p.oracle_address) {
           LogFail(signer_address);
           LogFail(p.oracle_address);
           return false;
        }

It seems in that example since the arguments for ecrecover and the oracle_address are all being set externally, then it is down to the clients interacting with the contract to make sure secp256k1 keys are being used and passed in. If they are then it would work. The key types we happen to be using for participants of our chain do not matter.

Whereas it would fail if, for example, the msg.sender address was being checked rather than an externally set address, and if that sender was not using a secp256k1 signing key.

I suppose if it is acceptable to push the responsibility for ensuring those entities participating in your contract that uses ecrecover are using secp256k1 then it is okay to support this.

[VoR0220]

👍

[compleatang]

See #777