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 Feb 26, 2024. It is now read-only.
Currently, if the debugger sees that an address has no code, it has no idea why it has no code. An address with no code could be an EOA... or it could be a precompile. Ideally the debugger would be aware of and able to report on this distinction.
There are two obstacles to this.
The first obstacle is that there's not entirely clear how to make this distinction. Currently, in standard EVM, addresses 1-9 are precompiles, but new precompiles are occasionally added, and I'm guessing we don't want to have to maintain a list. Now, there was EIP-1352, which attempted to set aside all addresses from 1 to 2^16-1 for precompiles, but this EIP was never approved and is now stagnant, so I'd be wary of relying on it.
But notice I said above "in standard EVM"... the problem is complicated by the fact that other chains often add their own custom precompiles, which we'd have to somehow know about. In particular, there's the console.log precompile used by Hardhat and Ganache, situated at address 0x000000000000000000636F6e736F6c652e6c6f67, which isn't even in the range that would have been set aside by EIP-1352! So we'd have to handle that somehow.
The second obstacle is issue #2894; because the debugger doesn't yet use debug_accountAt, currently in the debugger a contract that self-destructs during the transaction (or later during the block) will appear (incorrectly) to have no code at the start of a transaction. This means that an address that appears to have no code actually has three possibilities; it could be an EOA, it could be a precompile, or it could actually have code but the debugger can't see it. Oops! Possibly this obstacle is ignorable depending on priorities, but it is worth noting.
Environment
Truffle version (truffle version): 5.8.4
The text was updated successfully, but these errors were encountered:
Currently, if the debugger sees that an address has no code, it has no idea why it has no code. An address with no code could be an EOA... or it could be a precompile. Ideally the debugger would be aware of and able to report on this distinction.
There are two obstacles to this.
The first obstacle is that there's not entirely clear how to make this distinction. Currently, in standard EVM, addresses 1-9 are precompiles, but new precompiles are occasionally added, and I'm guessing we don't want to have to maintain a list. Now, there was EIP-1352, which attempted to set aside all addresses from 1 to 2^16-1 for precompiles, but this EIP was never approved and is now stagnant, so I'd be wary of relying on it.
But notice I said above "in standard EVM"... the problem is complicated by the fact that other chains often add their own custom precompiles, which we'd have to somehow know about. In particular, there's the console.log precompile used by Hardhat and Ganache, situated at address
0x000000000000000000636F6e736F6c652e6c6f67
, which isn't even in the range that would have been set aside by EIP-1352! So we'd have to handle that somehow.The second obstacle is issue #2894; because the debugger doesn't yet use
debug_accountAt
, currently in the debugger a contract that self-destructs during the transaction (or later during the block) will appear (incorrectly) to have no code at the start of a transaction. This means that an address that appears to have no code actually has three possibilities; it could be an EOA, it could be a precompile, or it could actually have code but the debugger can't see it. Oops! Possibly this obstacle is ignorable depending on priorities, but it is worth noting.Environment
truffle version
): 5.8.4The text was updated successfully, but these errors were encountered: