Update EIP-7708: Move to Draft

[etan-status]

Add details about log address and suggest concrete topics[0] values.

Withdrawals and priority fees could be covered with block level system logs, as proposed here:

• https://github.com/ethereum/EIPs/pull/9002/files

[eth-bot]

✅ All reviewers have approved.

[70nyIT]

As proposed here, I think it's better to use the 0xeee...eee address rather than EIP-4778

[github-actions]

There has been no activity on this issue for six months. It will be closed in 7 days if there is no new activity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[etan-status]

@RazorClient currently looking into this as part of EPF

[Carsons-Eels]

EIP-7708 currently has no active champion. I made a separate PR to add myself as an author/champion so that I can help accelerate this process since 7708 was CFId for Amsterdam and I am implementing the spec version.
Once I am added I will review this ASAP. Thanks for summarizing the EthMagician comments into a PR!

[etan-status]

Thanks! Yeah, it has been tricky to get any reaction here (I opened this back in 2024).

Regarding the missing logs, I also made EIP-7799 for prio fees + withdrawal logs, and then also this one to make it only emit 1 log per block for the prio fee credit: #10997

Note that 7708 standalone still improves situations, as it removes the need to trace every single transaction. One still has to process all block headers (for fees + withdrawal logs), but that's a much smaller task. Still, can argue that one should just bump it by a fork (H* e.g.) and do the complete scope there, rather than incrementally.

[g11tech]

may be we should have a field champions other than author which EIP editors should be able to approve for additions/deletions to so that the EIP development is not hindered

cc @SamWilsn @poojaranjan

[etan-status]

The fee credit could be made manageable with https://eips.ethereum.org/EIPS/eip-8115

[etan-status]

And the fee deduction could be made manageable with https://eips.ethereum.org/EIPS/eip-7668

[benaadams]

Is 0x000..000 better for Rlp encoding?

[etan-status]

It's a byte array, not an int, so does not use varlen encoding.

RLP encoding is 0x94 + 20byte address regardless of value.

There is also an idea of 0xeee...eee: https://ethereum-magicians.org/t/eip-7708-eth-transfers-emit-a-log/20034/46?u=metony

Right now it just uses the same system address from EIP-4788

[benaadams]

I prefer 0x0 as is ETH the asset emitting the log; rather than the system

But not strongly held

[etan-status]

Sure, worth a broader discussion. Keep in mind can also change the value lateron if there are multiple opinions about it. For now, would just settle with any one so that implementations can continue.

[Carsons-Eels]

So, if I have this correctly, these are the rough meanings and benefits of each:

• 0x000...000: The null address is often used to mean "not a contract" and might take less storage on disk.
  • "ETH is the asset emitting the log; rather than the system"
  • Highly compressible (but does not matter for RLP encoding)
• 0xeee...eee: Some contracts use this to represent native ether, when an address is required.
  • Many Eth apps already use it
  • eth_simulateV1 (in multiple clients) logs ETH transfers with it
  • Backwards Compatibility, since it would be the same as ERC-20 transfer logs
  • De facto standard when contracts support both tokens & ETH
  • Follows ERC-7528: ETH (Native Asset) Address Convention
• 0xfff...ffe: Since moving ether is done by the "system", the system contract should emit it.
  • Already in use as a system address for EIP-4788: Beacon block root in the

For now I'm going to implement 0xfff...ffe in the spec branch, since that's what this reads. I'll ask for responses from client teams on which they prefer. I can update the spec branch later, we can keep this as is for now or you can update it to match @etan-status your choice. Either way, you're right, needs discussion.

@benaadams can I consider your opinion representative of Nethermind as a whole?

[etan-status]

Not "my choice", 0xfff..e was the only one depicting a concept of an address for "system originated" in the EIPs.

If the tests use 0xeee..e, can also start with that one. Is confusing if EIP doesn't match the tests

[fselmo]

If the tests use 0xeee..e, can also start with that one. Is confusing if EIP doesn't match the tests

It was mentioned by @Carsons-Eels two comments above this that the specs and tests will use 0xfff...e and is currently in PR (here). The value in this PR is currently 0xeee...e (here).

Can we agree before merging? From this thread, the agreement looks to be 0xfff...e? Let's go with this for now?

[etan-status]

His comment was edited; it used to say 0xeee..e

Will do 0xfff...e then to match his latest comment. Thanks for catching it.

[fselmo]

His comment was edited; it used to say 0xeee..e

Ah! That makes sense then :) Thanks!

[petertdavies]

I'm not sure I support the special fee transfer log proposal. In the ERC20 world, any balance change is reflected by a transfer log (mints transfer from 0x0, burns to 0x0). Ideally we would like to be as similar to ERC20 machinery as possible. If we wanted to faithfully match the semantics of fees each transaction would need to emit:

1. At the start of the transaction, sender_address -> 0x0, paying the theoretical max fee.
2. At the end of the transaction 0x0 -> sender_address, refund unused gas.
3. At end of the transaction 0x0 -> coinbase, paying the gas fee.

The problem is that this is 3 logs per transaction. In the EVM gas schedule, Transfer logs cost 1788 gas each (haven't checked thoroughly), so adding fee logs would cost 5364 gas per transaction. If the extra logs emitted are acceptable that would be the best approach.

It would be nice to know how many logs will be emitted by this EIP. It could easily be more than all other sources of logs.

[etan-status]

As is, this EIP contains the minimum so that indexers (exchanges, infra providers) no longer have to run debug trace command on every single transaction to discover hidden internal transfers.

They still need to process all block headers, transactions, and receipts, to get a complete picture, i.e., fee payments, block producer rewards, and CL withdrawals, and testnet genesis balances.

EIP-7799 contains the missing aspecst to make it "complete", so that a complete picture can be gotten with solely eth_getLogs API (with a trustless extension). However, 7708 alone would already be very useful.

[benaadams]

Ideally we would like to be as similar to ERC20 machinery as possible.

Would also cause significant receipt bloat; as would mean transferring an ERC20 token (with no explicit ETH transfer) would also emit 3 ETH transfer logs

[spencer-tb]

Aligns well with EELS spec PR now. LGTM! Thanks for fast update

[petertdavies]

This all looks good. Agree that restricting this EIP to just CALL family and SELFDESTRUCT transfers is sensible. Questions about fees, withdrawals etc can be pushed to a future EIP.

Happy to see active authors taking this forward!

[jwasinger]

Some edge cases to think about here:

1. a selfdestruct-to-self for a contract created in the same transaction will immediately burn that balance.
2. a selfdestruct-to-self for a previously-existing contract will result in no net balance difference even if it is "nonzero-value-transferring"

For the sake of simplicity, I suggest we treat both cases as a transfer of value to self. There is not really a proper way to indicate that the balance is being burned in the case of 1.

[etan-status]

Is it possible from solely the information in the logs (whatever is proposed to be emitted here), the transactions (amount, max prio fee), the receipts (gas used), the block header (base block fee, withdrawals), and the genesis balance (or, whatever the balance was at the time of the fork when this activates) to reconstruct the account balance accurately, in all cases?

Or do we need a second log for burning ETH in these situations?

[jwasinger]

I think we would need a special log to indicate burn in the case of 1.

[jwasinger]

for the case of 2. we can just mark this as a transfer of zero value to self. It's the only case where a value transfer log of this type would be allowed.

[etan-status]

The special log could either be a LOG2 Burn(from, amount), or reuse the Transfer log (with a destination of system address). The Burn log would probably be cleaner, as it doesn't actually increase the balance of the system address. The Transfer log would be a bit more consistent with ERC20 (no need to combine the result from multiple log topics); but for ERC20 it actually gets credited to zero/burnaddress so it's not the same semantics.

[etan-status]

Or, Selfdestruct(from, amount)? To indicate the special operation? Then, (1) and (2) would be the same?

[jwasinger]

Yeah, I like that

Or, Selfdestruct(from, amount)? To indicate the special operation? Then, (1) and (2) would be the same?

This could work.

[etan-status]

Added Selfdestruct(from, amount).

[benaadams]

There is not really a proper way to indicate that the balance is being burned in the case of 1.

Isn't burn for ETH a transfer to 0x0? (to null) like emission is a transfer from 0x0

Symbolic burns transfer to 0xdEaD but that's not what we are talking about here

[etan-status]

In a Transfer, the value is actually credited to the destination.
This Selfdestruct doesn't credit anything. One couldn't reconstruct the actual value of the zero / 0xdead address if the special case isn't denoted as such.

[jochem-brouwer]

Some minor comments.

Description of this PR says: "Further propose a fee payment log for completeness." I do not see this payment log in the diff though.

[eth-bot]

All Reviewers Have Approved; Performing Automatic Merge...