multihash key gen func #36

i-norden · 2022-05-13T02:14:51Z

i-norden commented

2022-05-13 02:14:51 +00:00

Using the feature branch prefix this time.

Function for converting a SSZ SHA2-256 Merkle root into a blockstore-prefixed multihash key. Wasn't sure where you'd want to put it, so it's in a new shared pkg.

The PR to canonize the byte prefix isn't merged yet so it is still subject to change.

So, when you insert into public.blocks for beacon block you will insert the MultihashKeyFromSSZRoot(beacon_block_root) as key and the SSZ encoded beacon block binary for data. Similarly, for beacon state you will insert the MultihashKeyFromSSZRoot(beacon_state_root) as key and the SSZ encoded beacon state binary as data.

As a sanity check you should first make sure you can reproduce the beacon_block_root and beacon_state_root from the binary you are inserting into data using the SSZ Merkleization function (if you haven't already).

Using the `feature` branch prefix this time. Function for converting a SSZ SHA2-256 Merkle root into a blockstore-prefixed multihash key. Wasn't sure where you'd want to put it, so it's in a new `shared` pkg. The PR to canonize the byte prefix isn't merged yet so it is still subject to change. So, when you insert into public.blocks for beacon block you will insert the MultihashKeyFromSSZRoot(beacon_block_root) as `key` and the SSZ encoded beacon block binary for `data`. Similarly, for beacon state you will insert the MultihashKeyFromSSZRoot(beacon_state_root) as `key` and the SSZ encoded beacon state binary as `data`. As a sanity check you should first make sure you can reproduce the `beacon_block_root` and `beacon_state_root` from the binary you are inserting into `data` using the SSZ Merkleization function (if you haven't already).

abdulrabbani00 commented

2022-05-13 12:48:16 +00:00

(Migrated from github.com)

@i-norden - Thank you for putting this together. I will work on this branch and make some changes for integration.

Quick question though:

Should we perform the sanity check before each DB write? Or should we have the sanity check as some testing function?

@i-norden - Thank you for putting this together. I will work on this branch and make some changes for integration. Quick question though: * Should we perform the sanity check before each DB write? Or should we have the sanity check as some testing function?

Sign in to join this conversation.

No reviewers

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/ipld-eth-beacon-indexer#36