You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Give dappnode users the amount of execution rewards they got when one of their validators proposed a block.
The problem
In a chain where MEV exists, getting execution rewards of a finalized block proposal with a non-archival execution node is hard.
MEV is transfered through different methods, majority of time in the last TX of a block or as a part of a smart contract call.
Non-archival geth only stores the sate of the latest block. We cant query historical blocks
A ot of information is only available offchain by asking MEV Relays directly.
Our approach
We have decided to get execution rewards by looking at the balance difference of the Fee Recipient(FR) address of the validator who proposed a block. No need to keep track of how MEV is transfered, query offchain information or require archival nodes
Steps
Cron each 12 seconds (or less) to get balance of all addresses that are the FR of 1 or more validators stored in brain.
1.1 Store in new postgreSQL table (Balance Table) the balance if it has changed from the latest balance stored on db OR we havent stored any balance of that address
When a block proposal duty is detected, check if it was missed or proposed. If it was missed, dont to anything else
2.1 If it was proposed, check the block index it was.
2.2 Search in Balance Table the difference between balance of FR in block proposal and block proposal -1. That is our Execution Rewards of the block proposal
Example of a Balance Table:
The following is a table where we start tracking only 1 fee recipient: A
In block 1, user uploads keystore with FR A to brain
In block 50, validator with FR A proposes a block, balance of FR A changes from 10 to 12
In block 120, user changed the FR A to FR B in brain
In block 150, user transfers funds from FR A to FR B. Balance of FR B changes from 0 to 12
In block 200, validator with FR B proposes a block, balance of FR B changes from 12 to 15
address (FR)
blockNumber
balance
A
1
10
A
50
12
B
120
0
B
150
12
B
200
15
When a block proposal duty of block 50 is detected by performance cron of brain, we calculate the difference of 12-10. Execution Rewards is 2 eth. Same happens for block proposal 200, we compare 15-12. Execution rewards is 3 eth
The text was updated successfully, but these errors were encountered:
The goal
Give dappnode users the amount of execution rewards they got when one of their validators proposed a block.
The problem
In a chain where MEV exists, getting execution rewards of a finalized block proposal with a non-archival execution node is hard.
geth
only stores the sate of the latest block. We cant query historical blocksOur approach
We have decided to get execution rewards by looking at the balance difference of the Fee Recipient(FR) address of the validator who proposed a block. No need to keep track of how MEV is transfered, query offchain information or require archival nodes
Steps
Cron each 12 seconds (or less) to get balance of all addresses that are the FR of 1 or more validators stored in brain.
1.1 Store in new postgreSQL table (Balance Table) the balance if it has changed from the latest balance stored on db OR we havent stored any balance of that address
When a block proposal duty is detected, check if it was missed or proposed. If it was missed, dont to anything else
2.1 If it was proposed, check the block index it was.
2.2 Search in Balance Table the difference between balance of FR in block proposal and block proposal -1. That is our Execution Rewards of the block proposal
Example of a Balance Table:
The following is a table where we start tracking only 1 fee recipient: A
When a block proposal duty of block 50 is detected by performance cron of brain, we calculate the difference of 12-10. Execution Rewards is 2 eth. Same happens for block proposal 200, we compare 15-12. Execution rewards is 3 eth
The text was updated successfully, but these errors were encountered: