Logs are often used to track when balance changes of assets on Ethereum. Logs work for ERC-20 tokens, but they do not work for ETH. ETH transfers from EOAs can be read from the transaction list in the block, but ETH transfers from smart contract wallets are not automatically logged anywhere. This has already led to problems in the past, eg. early exchanges would often not properly support deposits from smart contract wallets, or only support them with a much longer delay. This EIP proposes that we automatically generate a log every time a value-transferring CALL or SELFDESTRUCT happens.
It should be backfilled too. Internal transactions have been a major challenge for blockchain accounting. This feature is more useful if it is available for all of the history.
The logâs address field should be nil. It is important that nobody can forge this log. The easiest way to do that is to have a special value for address, since other events would have to be emitted from a source account. nil should be used for all âsystem logsâ therefore.
The magic should not collide with any solidity-style event hash. A magic of 0000000000000000000000000000000000000000000000000000000000000000 will not have collisions. While the magic topics[0] can probably be removed altogether if the log address is unique, keeping it allows other types of âsystem logâ in the future. Other values will not compress as easily as all-zeros.
Should withdrawals also trigger a log? If so, what should the sender address be specified as?
Yes, from the zero-address, which is the common behavior for erc20 mints.
Should fee payments trigger a log?
I am in favor of this even when the gas price is 0. While it isnât necessary for accounting because transaction fees are specified by gasPrice * gasUsed, including them would allow eth balances to be completely tracked by querying logs. It would no-longer be necessary to query individual transactions, and it would be easier to locate all transactions sent from an account.
While I appreciate ETH resembling ERC20 for offchain accounting purposes by introducing logs, I wonder if this might be best accomplished on the paymaster-side, if the goal is to make things easier for smart accounts. Personally, I would prefer the approach we have seen so far â introducing features to ETH progressively through wrappers, like wETH. After all, if someone had ânew great idea that makes logs not usefulâ we would then be kind of stuck with bloat.
Working with Smart accounts this is the #1 pain for us when it comes to track ETH transfer. We ended up debug_ tracing calls on multiple chains, with big $$ in infra costs. And this is also a big blocker in decentralizing portion of what weâre doing (stealth addresses with smart accounts). This would be a huge benefit imho.
Of course we need to limit the logs to transfers with amount> 0.
Hmm. operations cost on ethereum try to reflect the cost (of storage, cpu) in term of âgasâ.
Emitting a âTransferâ event costs roughly 1700 gas.
Who should pay this cost?
On avg we have around 1M logs emitted. Considering gas 1700, it will be a total of 1.6B gas per day. Currently the avg usage of gas is around 100B per day. This means thereâs a 1.6% avg cost increase in gas spending.
The above costs come to cover for nonce change, balance change, and calldata cost.
the extra 6700 extra for transfer is for covering the balance change from both sender and reipient. compare the above cost to performing them using ânativeâ assembly: nonce increment is sload+sstore which is ~5100 gas
So you either think that the current cost is over-paid, and its OK to add another 1500, or that we need to adjust and add this extra gas to the "call"cost.
No it shouldnât. Things shouldnât be over-complicated. In a world of inifinite engineering capacity⌠yeah good idea. But we need to prioritize features and thereâs a limited amount of engineering capacity.
0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE is a defacto standard value that many contracts use when they support both tokens and ETH and they want to include ETH in a mapping and they need a lookup key. Unlike 0x0, there isnât risk of accidentally checking for it by leaving value uninitialized.
Following ERC20 Transfer log makes it so anything that parses ERC20 transfer logs can also parse ETH logs without any additional work. The ERC20 transfer logs contain all of the information desired, (âtokenâ, from, to, amount) so the fit the desired purpose well.
I donât think rewriting all of the blocks is the easiest way to backfill. Instead, generate replacement receipts for all of the transactions (and blooms for all of the blocks) before the activation block and start serving them instead once they become available. I donât even think the nodes have to compute these themselves; their operators could trust an import. I was thinking there could be a contest to see who can generate the update first, and ways other competitors could disprove prior submissions if there was a mistake. Similar to re-genesis, it isnât necessary for all of the nodes to do all of the work, so-long as there is enough incentive to disprove a false submission.
The aforementioned import is only really necessary for already-running nodes. When doing a full block sync, the node would produce two sets of receipts: the one expected to match the blockâs receipt hash, and the one that will be served in eth_getLogs and eth_getTransactionReceipt. There could be a parameter for those methods to fetch the legacy logs.
Backfill is a very cool nice-to-have, if we can find a nice way to have it without delaying the consensus on this EIP, while being able to emit logs for ETH transfers is a must have.
I would support this if we could somehow tackle the questions:
How do we do this without increasing the gas of Transfers that do not wish to include logs ?
How do we do this without adding as much gas as a normal event emission? (native opcode/protocol level stuff â export it to blob?)
Ideally I think the optional Transfer log would be cool, while users can opt out of it for slightly cheaper gas costs. 1700 is obscene when considering 21k is the transfer cost, thatâs almost 10%.
I would think that such things should cost XX or XXX gas costs max, increasing with log size, and if not needed to store as permanent data, some expiry or onto blobs could save a lot of âgasâ maybe.
You seem to have some confusion about the spec. Do you understand that the proposal is for every ether transfer to be documented by a log, but the current gas costs are not increased?