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
{{ message }}
This repository has been archived by the owner on Dec 3, 2024. It is now read-only.
Context and scope EIP-150 introduced the 63/64 rule when forwarding gas to an external call. In short, when the CALL opcode is invoked, 63/64 of the provided gas is actually forwarded to the call; 1/64 is silently withheld. This opens up an edge case in the token bridges in which it's possible for the call made during the sendAndCall flow to fail due to OOG, but for there to be enough gas remaining at the caller for the transaction to succeed. This is limited to cases in which 1/64 of the gas provided to the external call is enough to complete the transaction.
Discussion and alternatives
At the application level, this can be worked around by specifying slightly more gas than is actually necessary to complete the call, such that 63/64 of the specified gas is enough to execute the call. At the protocol level, we can explicitly check that we do not hit this case by checking the remaining gas immediately after the call, per this example. See the code comments for a derivation of why this check is sufficient.
Open questions
It may be a worthwhile exercise to think of how this (or a similar gas estimatation inaccuracy) could be taken advantage of by a malicious party. Given the fix is relatively simple, identifying such cases is not necessary to merge, but would be good to understand generally how this class of bugs could impact the bridge.
The text was updated successfully, but these errors were encountered:
Context and scope
EIP-150 introduced the 63/64 rule when forwarding gas to an external call. In short, when the
CALL
opcode is invoked, 63/64 of the provided gas is actually forwarded to the call; 1/64 is silently withheld. This opens up an edge case in the token bridges in which it's possible for the call made during thesendAndCall
flow to fail due to OOG, but for there to be enough gas remaining at the caller for the transaction to succeed. This is limited to cases in which 1/64 of the gas provided to the external call is enough to complete the transaction.Discussion and alternatives
At the application level, this can be worked around by specifying slightly more gas than is actually necessary to complete the call, such that 63/64 of the specified gas is enough to execute the call. At the protocol level, we can explicitly check that we do not hit this case by checking the remaining gas immediately after the call, per this example. See the code comments for a derivation of why this check is sufficient.
Open questions
It may be a worthwhile exercise to think of how this (or a similar gas estimatation inaccuracy) could be taken advantage of by a malicious party. Given the fix is relatively simple, identifying such cases is not necessary to merge, but would be good to understand generally how this class of bugs could impact the bridge.
The text was updated successfully, but these errors were encountered: