Discuss: How to handle block reward to miner

[rakita]

If there is transactions present inside block we could just add block reward (2eth) to last transaction change set.

The problem is how to handle it if there are no transactions inside block, we still need index for transaction to index validator account balance change.

Do we always include +1 transaction changeset for validator block reward? In that case index of transactions would always be body.len()+1. This could probably work but want others to be aware of it if we do it this way.

[ralexstokes]

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

[rakita]

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.

[ralexstokes]

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 :)

[rakita]

Yeah, we intend to support full genesis sync :)

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

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

[gakonst]

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.

[gakonst]

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

[rakita]

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

[gakonst]

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?

[rakita]

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

[gakonst]

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?

[rakita]

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

[joshieDo]

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

[rakita]

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.

[joshieDo]

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

[onbjerg]

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