secp256k1 precompiles

[zeroXbrock]

📝 Summary

• add randomUint precompile
• add secp256k1 precompiles
  • secp256k1Sign
  • secp256k1RecoverPubkey
  • secp256k1VerifySignature

TODO:

• add tests

📚 References

---

• I have seen and agree to CONTRIBUTING.md

[metachris]

should the hex addresses follow the same scheme as the others?

[zeroXbrock]

I see a loose pattern in how the addresses are chosen, but it doesn't seem totally consistent.
For example, from

fetchBidsAddr                = common.HexToAddress("0x0000000000000000000000000000000042030001")

we might infer that 0x00..42 implies MEV-Share bid-related precompiles. But then we see

fillMevShareBundleAddr       = common.HexToAddress("0x0000000000000000000000000000000043200001")

So then we might infer that 0x00..42 is strictly bids and 0x00..43 is just bundle-related. But then we see

simulateBundleAddr           = common.HexToAddress("0x0000000000000000000000000000000042100000")

So then my guess is that the scheme is "start with 0x000000000000000000000000000000004 and have some zeros in the middle?"... Is there an actual pattern I should be following?
I thought this address was fun :p but happy to change it -- just wondering how best to avoid conflicts w/ other precompile PRs.

[dmarzzz]

@zeroXbrock didnt realize my PR does the same #127 , Im curious why we need recover as a precompile if solidity already exposes ecrecover? also we dont include the curve name on signEthTransaction so Im not sure we need to for signing an arbitrary message either if its in ethereums native curve, only for non-native curves

[dmarzzz]

closing because stale