Update EIP-7708: Move to Draft #9003
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,9 +2,9 @@ | |
| eip: 7708 | ||
| title: ETH transfers emit a log | ||
| description: All ETH transfers emit a log | ||
| author: Vitalik Buterin (@vbuterin), Peter Davies (@petertdavies), Etan Kissling (@etan-status), Gajinder Singh (@g11tech), Carson (@carsons-eels) | ||
| discussions-to: https://ethereum-magicians.org/t/eip-7708-eth-transfers-emit-a-log/20034 | ||
| status: Draft | ||
| type: Standards Track | ||
| category: Core | ||
| created: 2024-05-17 | ||
|
|
@@ -20,24 +20,31 @@ Logs are often used to track when balance changes of assets on Ethereum. Logs wo | |
|
|
||
| ## Specification | ||
|
|
||
| ### ETH transfer logs | ||
|
|
||
| A log, identical to a LOG3, is issued for: | ||
|
|
||
| - Any nonzero-value-transferring transaction, before any other logs created by EVM execution | ||
| - Any nonzero-value `CALL`, at the time that the value transfer executes | ||
| - Any nonzero-value-transferring `SELFDESTRUCT`, at the time that the value transfer executes | ||
|
|
||
| | Field | Value | | ||
| | - | - | | ||
| | `address` | `0xfffffffffffffffffffffffffffffffffffffffe` ([`SYSTEM_ADDRESS`](./eip-4788.md)) | | ||
|
Contributor
There was a problem hiding this comment. Is 0x000..000 better for Rlp encoding?
Contributor
Author
There was a problem hiding this comment. It's a byte array, not an int, so does not use varlen encoding. RLP encoding is There is also an idea of Right now it just uses the same system address from EIP-4788
Contributor
There was a problem hiding this comment. I prefer 0x0 as is ETH the asset emitting the log; rather than the system But not strongly held
Contributor
Author
There was a problem hiding this comment. 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.
Contributor
There was a problem hiding this comment. So, if I have this correctly, these are the rough meanings and benefits of each:
For now I'm going to implement @benaadams can I consider your opinion representative of Nethermind as a whole?
Contributor
Author
There was a problem hiding this comment. 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
Contributor
There was a problem hiding this comment.
It was mentioned by @Carsons-Eels two comments above this that the specs and tests will use Can we agree before merging? From this thread, the agreement looks to be
Contributor
Author
There was a problem hiding this comment. 
His comment was edited; it used to say 0xeee..e Will do 0xfff...e then to match his latest comment. Thanks for catching it.
Contributor
There was a problem hiding this comment.
Ah! That makes sense then :) Thanks!
etan-status marked this conversation as resolved.
Outdated
|
||
| | `topics[0]` | `0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef` (`keccak256('Transfer(address,address,uint256)')`) | | ||
| | `topics[1]` | `from` address (zero prefixed to fill uint256) | | ||
| | `topics[2]` | `to` address (zero prefixed to fill uint256) | | ||
| | `data` | `amount` in Wei (big endian uint256) | | ||
|
etan-status marked this conversation as resolved.
|
||
|
|
||
| ## Rationale | ||
|
|
||
| This is the simplest possible implementation that ensures that all ETH transfers are implemented in some kind of record that can be easily accessed through making RPC calls into a node, or through asking for a Merkle branch that is hashed into the block root. The log type is compatible with the ERC-20 token standard, but does not introduce any overly-specific ERC-20 features (eg. ABI encodings) into the specification. | ||
|
|
||
| ### Open questions | ||
|
|
||
| 1. Magic value used for `address` and `topics[0]`? For address: (a) `0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee` (same as `eth_simulateV1`), (b) `0xfffffffffffffffffffffffffffffffffffffffe` ([`SYSTEM_ADDRESS`](./eip-4788.md)), (c) zero address | ||
|
etan-status marked this conversation as resolved.
Outdated
|
||
| 2. Should fee payments trigger a log? It would ensure "completeness", in the sense that you can compute the exact current balance table by watching logs, but it would greatly increase the number of logs, perhaps to an unacceptably high amount. | ||
| 3. Should withdrawals also trigger a log? They are not associated with transactions. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some edge cases to think about here:
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would need a special log to indicate burn in the case of 1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The special log could either be a LOG2
Burn(from, amount), or reuse the Transfer log (with a destination of system address). TheBurnlog would probably be cleaner, as it doesn't actually increase the balance of the system address. TheTransferlog 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.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or,
Selfdestruct(from, amount)? To indicate the special operation? Then, (1) and (2) would be the same?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that
This could work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added
Selfdestruct(from, amount).Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't burn for ETH a transfer to 0x0? (to null) like emission is a transfer from 0x0
Symbolic burns transfer to
0xdEaDbut that's not what we are talking about hereThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.