As per the current spec, the tests for the eth_getStorageAt do not match the definition. Specifically the test \tests\eth_getStorage\get-storage.io fails with the following request:
The second parameter is the 'Storage slot' parameter defined as $ref: '#/components/schemas/uint256'. This has the following issues:
The uint256 does not accept the leading 0s. The validation passes if the parameter is changed to "0x100000000000000000000000000000000000000000000000000000000000000".
The definition of $ref: '#/components/schemas/uint256' is not valid as it only allows 16 bytes:
This PR fixes eth_getStorageAt definition by setting it to more specific data types. The 'Storage slot' parameter has been changed to $ref: '#/components/schemas/bytesMax32'. This allows any of the values to be valid:
Motivation
As per the current spec, the tests for the
eth_getStorageAt
do not match the definition. Specifically the test\tests\eth_getStorage\get-storage.io
fails with the following request:The second parameter is the 'Storage slot' parameter defined as
$ref: '#/components/schemas/uint256'
. This has the following issues:The uint256 does not accept the leading 0s. The validation passes if the parameter is changed to
"0x100000000000000000000000000000000000000000000000000000000000000"
.The definition of
$ref: '#/components/schemas/uint256'
is not valid as it only allows 16 bytes:Summary
This PR fixes
eth_getStorageAt
definition by setting it to more specific data types. The 'Storage slot' parameter has been changed to$ref: '#/components/schemas/bytesMax32'
. This allows any of the values to be valid:The result value has been updated to always expect 32 bytes.
Additionally the definition of
$ref: '#/components/schemas/uint256'
has been extended to 32 bytes.Notes
For the 'Storage slot' parameter I used
bytesMax32
rather thanbytes32
orhash32
for two reasons:0x1
rather than0x0000000000000000000000000000000000000000000000000000000000000001