disable coibase touch in state tests with (reward 0)?
winsvega opened this issue · comments
it looks like the logic of coinbase touch (with mining reward) is a confusing one to many devs.
why a state test has to perform blockchain logic of mining reward (in state tests it is 0) and then on <=EIP150 it results in empty account present in the state.
the question here is:
Should we remove coinbase touch on state tests?
by the format state tests has 0 minign reward to focus on transaction rewards. and by name it has no blockchain logic.
this coinbase touch was introduced so only to be able to run state tests as blocks being imported in besu's RPC interface.
since besu does not support RPC anymore, this is just confusing in state tests.
currently all the t8n implemented coinbase touch in state tests.
this is confusing for new t8n implementations by other teams and some times they make code hacks for it which is not good.
So far I haven't understood that the coinbase touching is related to block rewards so we have this workaround to pass existing tests: https://github.com/ethereum/evmone/blob/master/test/state/state.cpp#L126-L132.
My preference for State Test would be to consider them as a state transition of one of a transaction from a block. I.e. do not apply any block finalization logic.
However, the t8n sister tool is designed differently as it can request application of multiple transactions and it has --state.reward CLI argument with some special value of -1. I'd be happy to skip any block reward logic in t8n too but maybe that would prevent using it for actually building blocks.
Coinbase touching is also related to fee payment, so if any gas is paid then the coinbase will be touched. Would this mean we are talking about the general state test situation where the transaction is invalid and hence not processed?
I think it would become more clear if there was a relevant test case where this change would impact test generation. Especially pre and post EIP150
I don't mind if we keep it around. Although initially it did confusing for me, but it's presence also reveal design flaw in some parts of nimbus-eth1 client. So far it doesn't only have negative side but also contribute positively for better a client.
Would this mean we are talking about the general state test situation where the transaction is invalid and hence not processed?
Exactly. This only matters in case of invalid transaction (so nothing is executed) for before SPURIOUS_DRAGON (because after empty accounts are deleted anyway).
yes the only case is rejected transaction or transaction with 0 gaspice <=EIP150
so soon we won't care about it anyway as we only focus on most recent tests
and old are archived to LegacyTests
so soon we won't care about it anyway as we only focus on most recent tests
and old are archived to LegacyTests
It's exactly the opposite. If you want to keep the legacy tests without modification then we need to keep the current behavior. I.e. we apply the block reward of 0.
Since its a blockchain logic I think we can fix the state test so it does not happen. So no changes required on the clients t8n and the test is fixed. (Put the non empty coinbase in the pre state)
@rodiazet has been fixing related issues in evmone and in the end we don't see anything very broken in the current design. Maybe we can argue that state test should not be related to coinbase block reward, but on the other hand the t8n tool can receive more than a single transaction therefore you can argue it applies all transactions from a block.
I would wait a bit until we finish all the details and be able to confirm everything works as it is.
I would argue that there are two ways one could interpret state tests:
- Interpret it as run a single transaction (are there state tests with more than one tx currently?)
- Interpret it as run a single transaction inside a block
Currently, both scenarios are not interpreted as-is:
- There is no block reward (so, it should not be regarded as a block with a single transaction)
- However, if there is a failing tx, block coinbase still is touched and should be removed if it is empty
I would argue that the solution is:
- If there are tests with more than 1 tx, interpret it as block, and thus reward the coinbase with block rewards
- If there are no tests with more than 1 tx, interpret it as running a transaction. So do not reward coinbase block rewards.
The argument that block coinbase is still rewarded, but the reward is 0 eth, is that it can be easily debugged regarding gas costs. However, I would argue that if you have tx gas price of 1 wei and then just use the default block rewards, it is easy to spot how much gas is used by just looking at the number. Also, rewarding the coinbase 0 eth on all hardforks essentially puts a "hardfork" over the hardfork which is running which puts the block reward to 0 eth.
To the last post solution, what if a block has 0 or 1 tx how would I tell t8n to still treat it as a block then?
The tool doesn't has to know. But we can adjust the state test. In the end hive runs blockchain version, so we can consider tool always do blocks.