reth
reth copied to clipboard
Add RPC endpoint getBalancesChangesInBlock
Describe the feature
Add RPC endpoint getBalancesChangesInBlock like erigon: https://github.com/ledgerwatch/erigon/pull/4609
Additional context
No response
would there be interest in standardizing this endpoint by adding it to the official spec?
ah after reading further i see this endpoint wouldnt be practical for certain clients
migh want to create a seperate rpc interface for reth specific endpoints like this one? I don't think it should fall under the eth namespace, not sure if it would fit under any existing namespaces
I think the function definition itself could look something like
async fn get_balances_changes_in_block(&self, number: BlockHashOrNumber) -> RpcResult<HashMap<Address,u32>>;
would there be interest in standardizing this endpoint by adding it to the official spec?
Yes
migh want to create a seperate rpc interface for reth specific endpoints like this one? I don't think it should fall under the eth namespace, not sure if it would fit under any existing namespaces
I think the function definition itself could look something like
async fn get_balances_changes_in_block(&self, number: BlockHashOrNumber) -> RpcResult<HashMap<Address,u32>>;
Yes
yeah, I'd like to move this to a new trait instead.
Is this endpoint similar to the existing statediff tracer but only uses balance changes?
Is this endpoint similar to the existing statediff tracer but only uses balance changes?
still trying to wrap my head around it, but I think we might be able to use the AccountChangeSet
@eserilev would something like this work inside TraceApi?
pub async fn get_balances_changes_in_block(
&self,
block_id: BlockId,
) -> RpcResult<Option<HashMap<Address, U256>>> {
let traced: EthResult<Option<Vec<Vec<(Address, U256)>>>> = self
.trace_block_with(
block_id,
TracingInspectorConfig::default_parity(),
|_, _, _, _, db| {
Ok(db.accounts.iter().map(|(k, v)| (*k, v.info.balance)).collect())
},
)
.await;
return if let Ok(Some(v)) = traced {
let accounts: HashMap<Address, U256> = v.into_iter().flatten().collect();
Ok(Some(accounts))
} else {
Ok(None)
};
}
This makes the perhaps totally incorrect assumption that db.accounts only contains the changed accounts inside the callback, if it includes all accounts it will of course fail spectacularly.
I'm very interested in trying to work on and debug this function, but am curious how to do so? Like how do the reth developers test their code locally, do you all work w/ a locally synced node or is there something like geth's --dev mode that I'm missing?