You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RequiredGas() (here in funtoken.go as well as in the other precompiles) charges a fixed amount of gas. This is problematic as the bankSend function accepts a dynamic type parameter, string memory to, as the transfer recipient.
If the bankSend precompile is called with the to string set to a very large string value, the DecomposeInput() call will consume a lot of computational resources to unpack the large to value, which the user is not charged for. The bank send will ultimately fail, but before it will have consumed a lot of gas. So this opens up a DoS/griefing vector.
If dynamic types are used as function parameters, it's very important to be accurate with gas accounting, as the value can potentially be very large. For example, consider parsing the input also in RequiredGas() and charge additional gas for dynamic size parameters (e.g. string, bytes, etc.)
github-actionsbot
added
the
S-triage
Status: This issue is waiting on initial triage. More Info: https://tinyurl.com/25uty9w5
label
Oct 17, 2024
Unique-Divine
changed the title
Use dynamic gas computation for the FunToken.sol precompile
[evm] Use dynamic gas computation for the FunToken.sol precompile
Oct 17, 2024
Unique-Divine
added
x: evm
Relates to Nibiru EVM or the EVM Module
and removed
S-triage
Status: This issue is waiting on initial triage. More Info: https://tinyurl.com/25uty9w5
labels
Oct 17, 2024
Abstract / Summary
Scope: x/evm/precompile/funtoken.go
RequiredGas()
(here infuntoken.go
as well as in the other precompiles) charges a fixed amount of gas. This is problematic as thebankSend
function accepts a dynamic type parameter,string memory to
, as the transfer recipient.If the
bankSend
precompile is called with theto
string set to a very large string value, theDecomposeInput()
call will consume a lot of computational resources to unpack the largeto
value, which the user is not charged for. The bank send will ultimately fail, but before it will have consumed a lot of gas. So this opens up a DoS/griefing vector.If dynamic types are used as function parameters, it's very important to be accurate with gas accounting, as the value can potentially be very large. For example, consider parsing the
input
also inRequiredGas()
and charge additional gas for dynamic size parameters (e.g.string
,bytes
, etc.)Originally posted by @berndartmueller in https://github.com/code-423n4/2024-10-nibiru-zenith/pull/28#discussion_r1801090069
The text was updated successfully, but these errors were encountered: