Filecoin HAMTs need to have byte serializing keys to be compliant with the spec and the conforming implementation used by lotus. However the implementation as it stands accepts arbitrary cbor serializable key types.
For existing code ported from specs-actors this hasn't caused issues because actors HAMTs have so far always needed to match bytes created by go HAMTs so they handle this on the caller site by converting ints (for example) into keys that serialize as bytes.
In the new world where we develop state in rust first with rust builtin actors this is a problem. This recently led to an issue with the helix token type having integer keys, causing lotus integration to fail to load the HAMT root.
We should enforce that HAMT key types implement a trait converting them to bytes and then serialize these bytes directly. This way the compiler will prevent this sort of problem from happening again.
Filecoin HAMTs need to have byte serializing keys to be compliant with the spec and the conforming implementation used by lotus. However the implementation as it stands accepts arbitrary cbor serializable key types.
For existing code ported from specs-actors this hasn't caused issues because actors HAMTs have so far always needed to match bytes created by go HAMTs so they handle this on the caller site by converting ints (for example) into keys that serialize as bytes.
In the new world where we develop state in rust first with rust builtin actors this is a problem. This recently led to an issue with the helix token type having integer keys, causing lotus integration to fail to load the HAMT root.
We should enforce that HAMT key types implement a trait converting them to bytes and then serialize these bytes directly. This way the compiler will prevent this sort of problem from happening again.