BlockScout coin balances view seem like a great way to track POA rewards coming into payout wallet. Is this view available via BlockScout’s JSON-RPC REST API or alternative a SQL / ES query to pull from AnyBlock? My understanding is that I need to query for internal transactions as these don’t show up as regular blockchain ledger txs.
Also, I see that sometimes instead of 1 POA / minute payout wallet gets 2 POA / 2 minutes. How is this possible?
Best, MM
You can get historical balances via our (Anyblock Analytics) ElasticSearch API like this:
{
"query": {
"bool": {
"filter": [
{
"term": {
"address.raw": "0xF977814e90dA44bFA03b6295A0616a897441aceC"
}
}
]
}
},
"sort": {
"timestamp": "desc"
},
"_source": ["timestamp", "blockHash", "blockNumber.num", "balance.eth", "balance.raw"],
"size": 1000
}
This covers all balance movements though. If you only want to look at the mining rewards, you should check the internal transactions / traces like this:
{
"query": {
"bool": {
"filter": [
{
"term": {
"type": "reward"
}
},
{
"nested": {
"path": "action",
"query": {
"bool": {
"filter": [
{
"term": {
"action.author.raw": "0x1985293823D122F11AbFbB82fB245e345A0AC60d"
}
}
]
}
}
}
}
]
}
},
"sort": {
"timestamp": "desc"
},
"_source": ["timestamp", "blockHash", "blockNumber", "action.value.raw", "action.value.num"],
"size": 10
}
@Micwebnet Such is possible if you see balance history of recent blocks. This view just shows the balance deltas between blocks in which balance has changed from the Blockscout DB. But new blocks processing is not ordered in Blockscout: first block processed -> first imported to DB. It means, that this is possible at some point of time when blocks #1 and #3 processed and #2 not yet processed. Thus, you will see coin balance delta between blocks #1 and #3. When block #2 will be processed, the view should change, as we can see for the same account, as you posted, missing blocks appeared in the coin balance history view:
BlockScout coin balances view seem like a great way to track POA rewards coming into payout wallet. Is this view available via BlockScout’s JSON-RPC REST API
There is no JSON-RPC API method in Blockscout which returns exactly such balance deltas in the response, but Blockscout provides eth_get_balance which hash absolutely the same interface, that is for eth_get_balance of Ethereum JSON RPC which returns the balance of address at any block:
curl -X GET "https://blockscout.com/poa/core/api?module=account&action=eth_get_balance&address=0xC57fE00C51aB00a4d6f270DEDbe5e7965dc6ADd5&block=16316421" -H "accept: application/json" {"jsonrpc":"2.0","result":"0xd9c2a908e4c249c00","id":0}
@viktorbaranov thanks for confirming this was an out-of-order block processing UX race condition and historical balance data wasn’t affected. Not sure if it makes sense to have UX process serialize on block ID to avoid this race condition, given underlying data layer isn’t offering sequential guarantee on processing completion, but at least maybe highlight that intra-blocks haven’t been processed yet when this happens?
@saschagoebel, thanks for the sample queries! I’ll be sure to play with ES some more. For now aggressive pre-filtering together with query folding made PostgreSQL a viable source for Power BI. My refresh times have reduced from hours to minutes, so I’m unblocked. 
I’m interested in all incoming POA coins, so need to track both reward emissions as well as tx/uncle fees. Looks like the latter are represented in trace table via trace_type=call so one table has them both! Is there a way to distinguish between tx vs. uncle fees?
Best, MM
@saschagoebel, so I’ve done some analytics, and seeing interesting results for pre-5,761,157 blocks. Back then POA used to transfer mined block rewards + tx/uncle fees every hour to payout wallet. I see quite a few 33.999979, which doesn’t makes sense since 34 POA were mined and the minimum should be 34. Any ideas why AnyBlocks SQL is returning a smaller number (I see the same when 35 POA were mined in an hour, shows up as 34.999979)? Would that be accounting for the gas to make the transfer?
Also any way to track tx/uncle fees separately for pre-5,761,157 blocks directly from the AnyBlock SQL DB, other than having to count and subtract block rewards for every hour?
Best, MM
Hi @Micwebnet,
regarding the 33.999 vs 34 transfers, I’d also guess that’s the gas being used already subtracted, but @igorbarinov can probably give a more confident answer 
As for the uncles … I’m not aware there are special fees that are delegated to the uncles. Ultimately an uncled block has no transactions, so there’s nothing to participate in.
Uncle rewards are tracked in the trace table as trace_type reward
SELECT *
FROM trace
WHERE trace_type = 'reward'
AND reward_type = 'block'
-- AND reward_type = 'uncle'
LIMIT 10
Hi @saschagoebel, I’m getting zero hits on reward_type = “uncle” in trace table. Can you show an example of what you are seeing for it?
I do see:
This matches the initial reward to mining address with 1h transfers, followed by direct on-chain reward to payout address starting from block 5761157. I always thought uncle rewards + tx fees validator income were both captured in the trace_type = “call”. Post-5761157 it’s all they are, but pre-5761157 it includes block rewards, minus the tx gas fee. Shouldn’t this have actual gas paid for the call (value transfer)?
In the trace table, gas=gas_used=0 for trace_type = “call”.
Here are examples (value column adjusted by 1 buterin for readability)
Best, MM
Hi Michael,
sorry, I was testing this on mainet. POA runs on AuRa which assigns the validators round-robin, so there are no uncles at all.
As POA Core doesn’t have that many transactions, blocks can be empty and have therefore no gas cost.
Also, AuRa sometimes sends transactions to report benign validators. These transactions are send from the validator itself and should therefore be free.
Anyhow, if you want to do analytics on gas usage, you should look at the transaction table, as the traces reflect only small parts of the complete transaction.
Cheers!
Gotcha. Gas cost only if there is a tx in the block.
Related question. In the trace table I’m seeing two columns: gas and gas_used. What are their definitions?
I assume one of those is the gas paid for the transfer from/to?
Best, Michael
gas is the gas limit provided to the call, gas_used is the actual used gas.
gas_used can never be larger than gas.
Thanks @saschagoebel. This makes sense! I see that most of the content in trace table is trace_type = create. What are these?
The other two types: call and reward as far as I understand representing value transfer transactions and internal transaction block rewards, respectively.
Also, how can value and/or gas_used be zero on a value transfer (trace_type = call) - e.g.
Thanks, MM
create is a contract deployment on chain, thus, a new contract has been created.
reward is a block reward
call is a call to some address, which may be a smart contract call, or just a simple value transfer
As for the zero values, the call may have been reverted, or it was just a reading call within another transaction. When looking at the traces, you should always sort by transaction_hash and trace_address. The latter being the order of calls within one transaction.
Would it then be fair to call transaction_hash a transaction ordinal and trace_address a call ordinal within transaction? I’ve been sorting on block_number so far. I assume these two are second and third level sorts on the sorted block #s?
How do you distinguish between call that is invoking a smart contract and simple value transfer? Why not track transfers as transfer?
Thanks, MM
Yes, pretty much like this
You don’t distinguish, as they are the same thing. Any smart-contract call can also have an ether value attached and any value transfer could trigger a smart contract without any payload.
See https://openethereum.github.io/wiki/JSONRPC-trace-module#trace_block
Would it be fair to say then that value transfers are calls on an implicit Deposit smart contract. I was under impression that every smart contract you call has its own address, but in this case I’m not sure which smart contract is getting called to perform the value transfer.
I also assume that each smart contract call has from that pays for the call, but not quite sure what to represents for non-value-transfers.
It’s more the other way round.
The to address is always the recipient of the transaction, with or without transferred value.
And every address can hold value (ETH, xDAI) and MAY be a smart contract or just a wallet.
