use uint256 for keys to disallow 0x empty

[macfarla]

the type currently used for storage slot key and storage proof key bytesMax32 allows 0x empty values. uint256 seems a better option for keys since the empty 0x value should never be used.

Added some clarification to make this less confusing -

The current type used for storage slot key from the schema is:

execution-apis/src/schemas/base-types.yaml

Line 18 in 4008859

bytesMax32:

bytesMax32:
  title: 32 hex encoded bytes
  type: string
  pattern: ^0x[0-9a-f]{0,64}$

From the existing types, this seemed like the one that matches the desired behaviour -

execution-apis/src/schemas/base-types.yaml

Line 59 in 4008859

uint256:

uint256:
  title: hex encoded 256 bit unsigned integer
  type: string
  pattern: ^0x(0|[1-9a-f][0-9a-f]{0,63})$

[macfarla]

storage slot key

execution-apis/src/eth/state.yaml

Line 38 in 4008859

$ref: '#/components/schemas/bytesMax32'

there's a comment here which indicates some history that may add context "this used to require strict uint256, but usage of leading zero is commonplace, so we can't disallow it."

[jflo]

This was discussed on RPC call #3 and no major objections were found. Will continue to solicit feedback.

[macfarla]

Added some clarification in the description based on discussion in the RPC standards call. If a new type makes more sense than using the existing hex encoded uint256 definition that's also fine.

[macfarla]

further investigation reveals that

• 0x empty is used for the storage root, so it does have meaning in this context to have 0x as a key
• usage of leading zeros is commonplace for storage slots

closing this PR.

however - maybe something of this context should be added to the spec itself for clarification
28e82b4

Note the slot parameter of eth_getStorageAt had to be relaxed to bytesMax32, since the
new uint256 pattern disallows leading zero, but usage of leading zero is commonplace
for storage slots.