Open nebojsa94 opened 4 days ago
Again, is there a practical usecase which drives this, or is it just about symmetry? Do you have a tracer which does a lot of hashing and suffers from performance bottlenecks?
Yes, there is a practical use case for GetCodeHash
. We aim to track the state objects required during the execution of each transaction in a block, as well as the resulting state changes. Instead of storing the entire code in the state object for every transaction (which would significantly increase result size), we store only the codeHash for each transaction’s state object and maintain a separate map of codeHash => code
.
Currently, hashing every new code encountered during block execution increases tracing time by a factor of 5 and overall block execution time by a factor of 2. This performance bottleneck is significant, and GetCodeHash provides a direct way to address it.
This PR extends tracing.StateDB by adding a GetCodeHash function.
Motivation
Currently, tracing.StateDB supports 2 out of 3 basic account data getters (GetBalance and GetNonce). Adding GetCodeHash completes the set, making it 3/3.
This addition significantly improves the performance of tracers that need to compute code hashes. Previously, the only available option was to use
crypto.Keccak256Hash(t.stateDB.GetCode(addr))
, which is less efficient.