Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Represent bitwidth explicitly in root node #79

Open
anorth opened this issue Dec 3, 2020 · 2 comments
Open

Represent bitwidth explicitly in root node #79

anorth opened this issue Dec 3, 2020 · 2 comments
Labels
need/triage Needs initial labeling and prioritization

Comments

@anorth
Copy link
Member

anorth commented Dec 3, 2020

As of filecoin-project/go-amt-ipld#38 the AMT stores the bitwidth in the root node. Knowledge of the bitwidth is necessary to correctly interpret the blocks, so storing it makes the structure more self-describing.

I propose that we do the same thing for the HAMT. This will require a Root node structure, which the AMT already had but needs to be introduced here.

Thoughts @Stebalien @ZenGround0?

@anorth anorth added the need/triage Needs initial labeling and prioritization label Dec 3, 2020
@Stebalien
Copy link
Member

We'd also need to specify the hash function (e.g., with a multicodec) and maybe a hash digest length? That shouldn't be terrible, but it'll take up a few extra bytes (likely 4?).

@rvagg
Copy link
Member

rvagg commented Dec 3, 2020

Probably don't need the digest length since it's implied for most (all?) of the multihashes in the multicodec table. bitwidth and hash function multihash code are what we're storing in the IPLD hashmap spec. There's some discussion about whether this root should be a separate block but IMO it doesn't need to be since the root of a HAMT is a special thing anyway and can't be made use of as anything but the root, so you could just pack config into it.

We currently form a root a little like this (a single block with a nested structure):

type HAMTRoot struct {
  hashAlg Int
  bucketSize Int
  node HAMTNode
} representation tuple

type HAMTNode struct {
  map Bytes
  data [ Element ]
} representation tuple

# ...

so the "node" is nested within the root. An alternative form would be to nest the configuration inside "node", such that the root is the same format as every other node but it has this one additional field:

type HAMTRoot struct {
  map Bytes
  data [ Element ]
  config HAMTConfig
} representation tuple

type HAMTNode struct {
  map Bytes
  data [ Element ]
} representation tuple

type HAMTConfig struct {
  hashAlg Int
  bucketSize Int
} representation tuple

# ...

Or shaving off the additional List CBOR byte and sticking it all in the root:

type HAMTRoot struct {
  map Bytes
  data [ Element ]
  hashAlg Int
  bucketSize Int
} representation tuple

type HAMTNode struct {
  map Bytes
  data [ Element ]
} representation tuple

# ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization
Projects
None yet
Development

No branches or pull requests

3 participants