secp256k1 precompiles #123
Conversation
| @@ -42,14 +47,18 @@ var ( | |||
| fetchBidsAddr = common.HexToAddress("0x0000000000000000000000000000000042030001") | |||
| fillMevShareBundleAddr = common.HexToAddress("0x0000000000000000000000000000000043200001") | |||
| newBidAddr = common.HexToAddress("0x0000000000000000000000000000000042030000") | |||
| randomUintAddr = common.HexToAddress("0x00000000000000000000000000000000F00bA777") | |||
There was a problem hiding this comment.
should the hex addresses follow the same scheme as the others?
There was a problem hiding this comment.
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.
|
@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 |
|
closing because stale |
📝 Summary
TODO:📚 References