Regarding the open questions, I think that they don’t necessarily have to be combined with this EIP. Both withdrawals and fee payments are easier to track than plain ETH transfers.
For fee payments: When monitoring logs in a trust-minimized world (EIP-6466: SSZ Receipts Root), they are already cross-checked against the receipts_root. The full ETH fees are also part of the same receipt that is already being proven, so full information is extractable in a straight-forward way. Especially in a EIP-7706 multidimensional fee world, some users may want separate logs per fee type, while others may only be interested in the total. I think that it’s fine to expect that a trust-minimized wallet / accounting software can process the full receipt relevant to its own transactions.
Withdrawals: This point should be extended with the ‘fee_recipient’ payment (formerly ‘coinbase’) as well. Both withdrawals and fee_recipient payments only affect users that solo stake, and larger staking operators that already have access to trusted monitoring; notably, liquid staking users or members of decentralized staking pools don’t benefit as they interact through a smart contract and never directly receive the withdrawals / fee payments. Furthermore, processing is already comparably simple because there is no concept of failures, and the withdrawals tree / block header are tiny compared to the full transactions/receipts logic. I think that it’s fine to have no logs for withdrawals and the fee_recipient payment.
If the motivation behind this EIP is to track balances changes, we would need that all ETH transactions emit a log including payments fees and withdrawals. Backfilling is a must also.
The main issue here is that we are going to almost duplicate the amount of logs per day. I did an extension of @metony Dune dashboard to analyze this point: https://dune.com/fergmolina/eip-7708-eth-transfers-emit-a-log
while users can opt out of it for slightly cheaper gas costs
If this EIP is implemented, it must be for all the logs (no opt-in options). We’re proposing this to simplify tracking of ETH within smart accounts, so it should work for every transfer.
Good point @fergmolina on not just viewing this from a “gas increase” perspective, but also from a “log size” increase perspective.
This should increase the cost of any operation that moves ETH. If it is believed that CALL is overpriced, then we should separately analyze and lower the price of CALL as a separate EIP. The cost of writing a log is meant to capture the storage space required (receipts) as well as the increase in block body size over the network, plus perhaps some minor costs associated with generating the log.
I feel like it would be very hard to argue the usefulness tradeoff of such logs if it places additional financial tax on every user who may or may not care them
Every token seems to be willing enough to pay the price, though part of that could be driven mostly by the fact that it is required in the ERC20 standard.
Agree backfill would be best. Though if this is not technically possible (due to changing receipt history), what might also work is emitting the entire balance of the from and/or to accounts after the transfer instead of the amount transferred. Then overtime, indexers would be able to fill out the balance of all active accounts just by looking at these logs.
Accounts that don’t send / receive any ETH won’t get indexed, but presumably this wouldn’t matter much because most of the reason you do this is to display an active user’s balance on a frontend.
Actually, not everybody has the advanced tooling I have so they rely on event subscriptions to detect changes. So this EIP would actually make it easier for others to update a user’s balance in a frontend.
I think the attached screenshot sums up perfectly why we need it. This is a message sent by the #1 hackathon. I’ve highlighted the part that matters to this thread.
My position is that we don’t necessary need to make it retroactively compatible, I don’t see a huge advantage into that. But definitively emitting events when ETH is transferred is a critical one, so that wallets can easily show when a native token is sent to a user.
Just signaling my support for this! We ran into this problem when adding smart contract wallet support for the Devcon ticketing system. Have seen others struggling with this in the wild too.
It’s shockingly difficult to verify ETH payments stemming from smart contract wallets.
I’m not a fan of horse trading. If dropping the bloom makes sense, then we should drop the bloom. If it further makes sense to reduce the gas cost of logs or transactions due to the removal of the bloom then we should do that.
Separately, if we generate new logs automatically, we should increase the cost of affected transactions as appropriate.
I dislike the idea that we should ship the two things at the same time and “call it even”. If the math works out to be even that would be neat, but I doubt it it would (things in the real world are never that clean).
The various core dev teams essentially try to estimate the load a given operation puts on the node. This could be CPU load, storage capacity load, disk read/write load, or network load. They then compare that to other operations (e.g., ADD, SSTORE, LOG, etc.) and try to align them all so a given amount of gas puts the same load on the system no matter how you use it.
It is definitely more of an art than a science, particularly since network, storage, I/O, and CPU aren’t directly comparable. I believe they may have some benchmarking tools that helps them complete this task, but I’m not personally familiar with them.
