search

zemse / hardhat-tracer

🕵️ allows you to see internal calls, events and storage operations in the console
MIT License
341 stars 35 forks source link

missing data in sload #53

Open 3commascapital opened 1 year ago

3commascapital commented 1 year ago

while performing a fulltrace, it appears that keys that start (maybe end?) with a 0, are truncated:

   [SLOAD]  0x5ae927a7f2066d8b16875771f50a71dd5068c7a536dc05f9790d2ed7e7e7dfeb → 0x658f34ca497f40089838ec7824ee93500001723f5f6bec3bb
   [SLOAD]  0xa1e32f41d99bbd4a21e24a4bc7ea34cc6a935534d92e3de0a64b79dfa8ffe21 → 0x658f34ca497f40089672fd5237f1a74000017ae3b99856753
   [SLOAD]  0x559790eddc715ccb852a36c4a435823360917a679a3700ef7a54745cd147f937 → 0x658f34ca497f400894bcf78a12f0d89000017b8eb292312ca

note the arrow is not in the same place (character missing) the above trace is a subset from 0xf1072bfb39468c6e7b49ed2a9eba43ddd728dbbcc50a9c45706de2a6b7e1f15c on ethereum

zemse commented 1 year ago

it appears that keys that start (maybe end?) with a 0, are truncate

yeah right now zero characters are not padded. if you have slot 0, slot 1, it would appear as 0x0, 0x1.

note the arrow is not in the same place

thanks for pointing this would, I think ideally the arrow should be in the same place, which would need padding with zero characters on the left side.

missing data in sload

the data should not be missing, just the zeros must have been stripped out (probably because the bigint was directly converted into hex string, I'll just convert it into bytes32 word)