EIP-7708: ETH transfers emit a log

EIPs EIPs core
44

With chains moving to even lower block times ( see https://x.com/jessepollak/status/1911858196836483540 ) I think this EIP becomes even more important, if we don’t want to trace-debug 5 blocks per seconds to undertsand when ETH has been sent out of a Smart Wallet

1 Like
45

This would be much easier to filter ETH transfers. :clap:

1 Like
46

I think source address should be set to 0xeee…eee instead of 0xfffffffffffffffffffffffffffffffffffffffe . This is what ERC-7528: ETH (Native Asset) Address Convention recommends. Or to 0x000…000 for better compressibility

2 Likes
47

ERC-7528 doesn’t have consensus. Plenty of protocols (such as UniswapV4) use the zero address for native assets. I prefer zero or null for compression, but also because it can become a precompile in the future.

48

The rationale of 0xffff…e is that it is already used in finalized EIP-4788. I don’t really see the point of having multiple system addresses, but they seem to be used for validator operations as well (with arbitrary deployed contracts designated to be system relevant), so one could also use 0xeee.ee specifically for ETH transfers as well. There’s also the EIP-7799 interaction for getting a complete picture of the ETH balance history; one could also use the 0xeee.ee address for these. Or zero.

49

Was dealing with an issue one of our customers had today. To give context, we provide a smart-account based wallet. Our customer wanted to deposit on Bitfinex ETH, so he sent money and on the other side no money were received.

Deep diving I found this: https://support.bitfinex.com/hc/en-us/articles/214441685-Ethereum-Deposits-at-Bitfinex

We can argue it’s Bitfinex fault. But the reality is that if to track internal ETH transfer the only way is debug traceCall for each block, no one is gonna do that, affecting essentially Smart Contract adoption. This is why I think this EIP is a crucial one around Smart Contract adoption and overall improve UX.

3 Likes
50

This is an essential EIP to improve support massively, great discussion above that shows all the point of friction that exist today and some open questions that need closing.

1 Like
51

Reading through the discussion, it seems we’ve reached a solid agreement on a few key points:

  • The ”Why” is clear: We all acknowledge the significant challenge of tracking ETH transfers from smart contract wallets. This hurts the user experience and creates real-world problems for users and services. This EIP is crucial for the adoption of smart accounts.

  • What should trigger a log: There’s a general agreement that, at a minimum, value-transferring CALL and SELFDESTRUCT operations should emit a log.

  • Log format: The idea to replicate the ERC-20 Transfer event format seems to have a good level of support, as it would simplify implementation for wallets and indexers that already handle ERC-20 tokens. Event is emitted by 0xfffffffffffffffffffffffffffffffffffffffe

  • Backfill The idea is to enable from a certain moment on, avoiding the backfill of all the past ETH transfers now covered by this EIP.

The primary unresolved issue remains the gas cost. While some argue that current operational costs could absorb the new logging cost, the prevailing view is that any new action must be accurately priced to reflect the resources it consumes. This is the critical point we need to resolve.

With the ongoing scalability efforts, it’s likely that any minor gas increase could be absorbed by senders as the overall cost per gas is expected to decrease. However, the path to formally evaluating and deciding on this cost increase isn’t clear to me.

Could anyone with experience in the EIP process share how this is typically handled when it comes to gas? Ideally with practical next-steps on what is the standard approach for analyzing and agreeing on gas cost adjustments. ( cc @MicahZoltu if you can help )

52

I still like 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE because many apps on Ethereum already use it, and eth_simulateV1 which is implemented in multiple clients uses it for logging ETH transfers already. I think these benefits of backwards compatibility outweigh the incredibly minor benefit of “coming from the system address”.

This should be easy (technically), just add the log costs to the intrinsic gas for non-0 value transfers. Sadly, in reality this will break sooo many things that it hurts my soul to even think about it.

Encode the correct gas costs into the EIP, propose it to Core Devs, but mention in the discussion with them all of the things that will break, then let them decide, of their own volition, to just ignore the gas costs of these new logs.

1 Like
53

I have some comments regarding this EIP:

  1. Sending value with CREATE or CREATE2 is not considered here, I believe it should be added
  2. When considering this EIP we should take into account this adds extra logs to the receipts and thus the gas limit to reach the 10 MiB devp2p limit is closer (we need: EIP-7975: eth/70 - partial block receipt lists to remove this limit/problem)
  3. The log origin address is saved per log, so we could omit the sender topic for normal transfers as this is already saved in the log. However this would not allow filtering on the sender address (so likely a bad idea)
  4. Adding all ETH transfers to logs is, for UX, likely a good idea. This would mean adding withdrawals, fee payments, and eth burn to the logs (as somewhat asked in open questions already). This would allow to craft a complete net balance change per block by just inspecting the logs. It would add at most 3 logs per tx: one for the tx transfer, one for the fee payment, and one for the fee burn. Open question would be what the target address of the fee burn would be. Note: in practice creating the net balance change might be less trivial than initially thought, as any contract could craft the LOG3 stack to add logs which look like ETH transfers, but are not.
  5. How to handle blob gas?

If we ship EIP-7668: Remove bloom filters we also don’t have to worry about these mandatory extra items to the filter.

I believe we should do all ETH transfers including fee payments/burn, but am not sure about the withdrawals since these are already in the block header and it feels like duplicating data to also add them to the logs. However, adding them to the logs does ensure that all transfers are accounted for.

Note that using a sender/target address for withdrawals/burn which uses an address larger than 20 bytes would work currently as it is not possible to target >20 byte addresses. However if we go to 32-byte addresses this is thus not the case anymore. So we should likely pick a designated sender/receiver for these, just as the topic, keeping in mind that any contract can fabricate these logs so these should be carefully treated anyways (to check for bogus transfer logs).

3 Likes
54

While not reflected in the EIP, this has been discussed in this thread and it is proposed to set the address of the log to be coming from 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE (my preference for reasons discussed above) or 0x0000000000000000000000000000000000000000000000000000000000000000 or 0xfffffffffffffffffffffffffffffffffffffffe.

@vbuterin @petertdavies Can we get the EIP updated to reflect the discussion that has occurred in this thread? Alternatively, if you two aren’t following along anymore could we get a new author added that can maintain this EIP and help push it through (not me)?

2 Likes
55

One risk with this EIP is that, if adopted alone, it does not fulfil what it aims for: removing the need for external indexers. The missing pieces are due to operations which change balances outside transactions, and I think that it makes sense to combine this EIP with sth like EIP-7799 which adds those pieces.

7799 provides a suggestion for batching priority fee credits to avoid hundreds of micro-credits per block. But it affects mevboost builders, as they cannot spend the prio fee in the same block anymore, as the credit would have to go at the end. Further, 7799 also extends the block header with a new system logs tree, so may be better suited for a fork when the block header gets cleaned up (e.g., EIP-7807).

But without sth like EIP-7799, I don’t think adding the logs should be done in isolation, as it doesn’t remove the indexers need. Would vote to defer it for H*, while recognizing it’s super high relevance.