Comments (15)
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'sfee_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.
Related Issues (20)
- extract persistence event handling into standalone functions HOT 2
- Add metrics for dropped outgoing messages HOT 5
- ExEx starts up and exits afterwards without any error/warning HOT 2
- Ensure peer receives all new transactions
- Extract test generation from derive macros
- Make `BlockchainProvider2` requests methods aware of in-memory state
- Make sync metrics work for engine2
- feature req: Need logIndex in type CallLogFrame when invoke API debug_trace* HOT 1
- op-reth node keeps resyncing on pipeline mode HOT 1
- Update repo/layout.md
- feat: relax `sync` constraint on Provider traits
- UnexpectedStaticFileBlockNumber Error Using Engine2
- remove usage of PeerCount type HOT 3
- Abstract `Chainspec`
- Failed to fetch finalized head in op-node HOT 3
- Add Txpool functions to retrieve txs by state and origin HOT 2
- `BlockchainProvider2` range methods do not fetch in-memory blocks
- Remove default implementation for `state_by_block_id` HOT 1
- should we update the recommended hardware in the installation page? HOT 2
- Improve op-node installation docs HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from reth.