Determine how to efficiently index Beacon State with proof #77
Labels
No Label
backlog
beacon
bug
critical
documentation
duplicate
enhancement
epic
feature
good first issue
help wanted
in review
invalid
question
test
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/ipld-eth-beacon-indexer#77
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
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?
Beacon state is a 60MB structured record that significantly changes every slot (12 seconds). If we want to represent this historical state in a hash-linked form, similar to our approach with ipld-eth, we need to be able to split the SSZ tree into changed and non-changed components that have their own hashes, then store the resulting pieces in a way that allows them to be found for a given block height, and also stitched together again to make a whole Beacon State record.
Difference iteration statediffing approach (analogous to what we do in the execution layer):