Discuss: How to handle block reward to miner about reth HOT 15 CLOSED

Ok got it, bringing the summary I got from discord: we'd be incrementing the CumulativeTxCount for the reward resulting in the following:

Tx1=1
Tx2=2
Block1Reward=3
Block2Reward=4
Tx3=5
Block3Reward=6

from reth.

just fyi the block reward has also varied over time, and is not always 2 ETH

but yeah, I didn't realize the intent was to support stuff from before the merge :)

from reth.

Sgtm. Concept ack, would like @joshieDo thoughts.

Is there a footgun exposed as a result of that in our internal apis? If somebody wants to talk to the db directly, what do they need to be aware of?

from reth.

maybe I'm missing some context but we just need to apply any COINBASE payments along with any txn priority fees to the block's fee_recipient

there is no "block reward" anymore and all validator rewards are handled at the consensus layer

from reth.

there is no "block reward" anymore and all validator rewards are handled at the consensus layer

I do really need to read this in detail few times https://eips.ethereum.org/EIPS/eip-3675#block-and-ommer-rewards :)
I thought that validator would receive rewards in the same way that was prior the Merge.
But still, for legacy/old blocks we need to add that reward to the state.

maybe I'm missing some context but we just need to apply any COINBASE payments along with any txn priority fees to the block's fee_recipient

Priority fee is already added inside revm. This is about 2 eth block reward that is updated when a block is executed.
The catch is how we plan to save state diff, as in history data/diff, it will not be in block granularity but on transaction granularity, updating that coinbase 2 eth at the block end that is not part of any transaction is an unusual update of reth state, we just need to mark it in some way.

from reth.

Yeah, we intend to support full genesis sync :)

Block rewards config from openethereum (5,3,2 eth):

"blockReward": {
	"0x0": "0x4563918244f40000",
	"0x42ae50": "0x29a2241af62c0000",
	"0x6f1580": "0x1bc16d674ec80000"
},

from reth.

just fyi the block reward has also varied over time, and is not always 2 ETH

but yeah, I didn't realize the intent was to support stuff from before the merge :)

Yeah I realize I may have miscommunicated that too -_- We want full genesis sync for archive nodes for historical data analyses. We want to offer support for "fast" sync using the post-Merge methods, but want to start with the full sync first.

from reth.

The catch is how we plan to save state diff, as in history data/diff, it will not be in block granularity but on transaction granularity, updating that coinbase 2 eth at the block end that is not part of any transaction is an unusual update of reth state, we just need to mark it in some way.

@rakita can we not write to the database directly and just add +2 ETH to the coinbase address? w/o going via the transactions path

from reth.

For plain state, yes, just writing it works. But this is about the history and how to index that block reward change.

from reth.

Should we store it at a "system contract" address? Maybe at a hardcoded keccak256("reth_coinbase_reward_address")? And then we could read its historical values from the kv store as usual?

from reth.

To be more precise.

History of storage on transaction granularity means that we have ChangeDiff table that looks like:

Tx1 -> [Acc1->BalanceChange, Acc2->NonceChange]
Tx2 -> [Acc3->Storage]
Tx3 -> [Acc1->BalanceChange]

This allows us to have history index of change (table Account/StorageHistory)

Acc1 -> [Tx1,Tx3]
Acc2 -> [Tx1]
Acc3 -> [Tx2]

Block1(Miner with address Acc1) contains [Tx1,Tx2]
Block2(Miner with address Acc2) contains [] zero transactions and
Block3(Miner with address Acc3) contains [Tx3]

What I am proposing is to include block rewards change set as:

Tx1 -> [Acc1->BalanceChange, Acc2->NonceChange]
Tx2 -> [Acc3->Storage]
Block1Reward -> [Acc1->BalanceChange]
Block2Reward -> [Acc2->BalanceChange]
Tx3 -> [Ac4->BalanceChange]
Block3Reward -> [Acc3->BalanceChange]

This BlockNReward is +1 transaction changediff that I want to introduce.

And History index would now look like:

Acc1 -> [Tx1,Block1Reward,Tx3]
Acc2 -> [Tx1,Block2Reward]
Acc3 -> [Tx2,Block3Reward]

It fits nicely

from reth.

downside is that we would have gaps in Transaction, TxSenders, Receipts, Logs tables, as we would need to match ids of them with Account/StorageChangeDiff table

from reth.

At first glance I see an issue here:

Acc1 -> [Tx1,Block1Reward,Tx3]

Tx1 is an integer, while Block1Reward is what? But either way, if we're putting them both in the same table, it would mess up with how we encode this data with EliasFano

from reth.

Block1Reward is supposed to be the same Id as Tx1 (The name is just different as I wanted to make a distinction) , as they "point" to the same table of ChangeSets.

from reth.

We ended up building separate block and tx indexes as outlined in https://github.com/paradigmxyz/reth/blob/main/docs/design/database.md#table-design

from reth.