Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save gas, precompute hashed value #249

Open
antonio-fr opened this issue Jan 25, 2022 · 2 comments
Open

Save gas, precompute hashed value #249

antonio-fr opened this issue Jan 25, 2022 · 2 comments

Comments

@antonio-fr
Copy link

antonio-fr commented Jan 25, 2022

I'm not expert in how the EVM works internally and counts gaz. I just think the method abi.encodeWithSignature is internally computing a Keccak256 hash, which is very computational intensive. That costs 36 units of gaz, and a basic static value would be way more efficient.
Why not replacing the balanceOf(address) method (and same L54) with its corresponding hash key 70a08231, and also building the argument in a lazy way, using a simple packing way ?

@Mrtenz
Copy link
Collaborator

Mrtenz commented Jan 26, 2022

I did some testing with this, and using abi.encodeWithSelector and hardcoding the selector seems to consistently use more gas than using abi.encodeWithSignature. I'm assuming this is because the optimiser is able to optimise the current somehow, but I'm not really sure. What do you mean by "building the argument in a lazy way, using a simple packing way"?

@antonio-fr
Copy link
Author

I just see the encodeWithSelector is exactly what I thought. It takes the hashed key as input. But maybe the compiler does this job, it sees the input is static and precomputes the hash. A mystery why more gaz, should be the same. Maybe this is related to the input arguments encoding?

Then, my other idea was to convert the data args to bytes ourself, as the input is an address list, we don't need all the "universal" ABI encoding. Still, I don't know how much more efficient, and the security drawbacks it can bring.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants