Candid, to_candid, motoko assumptions

Just a couple of assumptions/questions here that I’d like to have verified:

  1. the bytes resulting from to_candid are stable enough so that a hash will be consistent?
  2. How expensive is the to_candid method? If I’m trying to take a hash of a highly variant type with nesting variants, do you think it would be cheaper to write my own has or just hash the to_candid output?

@kentosugama @ggreif @claudio

3 Likes

Just a couple of assumptions/questions here that I’d like to have verified:

  1. the bytes resulting from to_candid are stable enough so that a hash will be consistent?

Absolutely not. Don’t use the blob for hashing or even equality testing.

  1. How expensive is the to_candid method? If I’m trying to take a hash of a highly variant type with nesting variants, do you think it would be cheaper to write my own has or just hash the to_candid output?

It doesn’t matter how expensive it is, you need to write your own. The candid encoding is not a function but a relation. There are many valid candid encoding for the same source value and your motoko code will just return one of them. A different compilation of the same code could well produce different candid blobs for the same Motoko value. In principle, difference calls to_candid on the same value could also produce different results in the same code, but that won’t happen at the moment, I expect.

I think I warn about this in the docs…

1 Like

The main reason the blob isn’t a function of the value is that the encoder is free to choose the representation of the type table included in the blob and different ordering of type table entries or different ways of representing the same recursive type (e.g. different number of unfoldings) can lead to totally different blobs that still encode the same value.

1 Like

I’m glad I asked! :joy:

1 Like

Candid Serialization actually warns about this at the end of that section.

1 Like