(VDB-309) rpc method to get statediff at specific block #16
Labels
No Label
bug
critical
duplicate
enhancement
epic
help wanted
in progress
invalid
low priority
question
rebase
v1
v5
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/go-ethereum#16
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "statediff_at"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is for vulcanizedb issue #123. This rpc method allows us to fetch the statediff at a particular block height, enabling us to backfill gaps in our data. Only works with a full node if the block height is within the pruning limit, otherwise an archival node is needed.
@elizabethengelman @rmulhol status on this? How long is the pruning limit?
@m0ar I think right now our thinking is that we could use the work by @i-norden in https://github.com/vulcanize/vulcanizedb/pull/157
Going to cut a new release for this branch. I'm not sure we need/want to merge this into
statediffing
, since that branch still has a PR open against the main geth branch.This looks awesome, nice job!
There was just one question about one of them mock methods, but it's not merge block.
@ -270,2 +274,4 @@
sds.Unlock()
}
// StateDiffAt returns a statediff payload at the specific blockheight
🎉
I'm trying to think through if we'll ever want to get a diff at a block given it's hash instead of/in addition to it's number. 🤔
Not a big deal, but I'm a bit confused about how this works. In the test statediff/service_test.go#L234 we're setting
testBlock1
totestBlock1.NumberU64()
which I think is the child block. But then in the internals of this method we're returning a block from the parent blocks collection. 🤔Nice!
A bit curious what happens if we request diffs for a block that is pruned, and how we can handle that sanely in vDB?
@elizabethengelman In theory it should be possible we ask for a state diff for a block that was just re-ordered, so maybe it's safer for us to ask for a hash? With reorg:d state diffs in vDB it shouldn't matter, since the diffs disappear on reorg anyway
:)
Performance wise fetching by hash is going to be a strain, we would need to fetch the block hash from Postgres for each block in the block range we want to fetch (which can be extremely large). Both backfillers are written to work with this end point at the moment. I think it would make sense to add a hash endpoint going forward though.
Sorry, the
parent
naming is confusing, all we are doing here is mapping blocks to return in the mockGetBlockByHash
to the hashes we want to return them for. In the context of the this service/these tests theGetBlockByHash
method is only called to fetch a parent block. Will update the naming.Parent block for the test is set here, since it is looked up by hash in
StateDiffAt
, the block for the block number we provide as an arg toStateDiffAt
(the child block) is set herePull request closed