RFC for Table of Constants TZIP

The corresponding MR: https://gitlab.com/tezos/tezos/-/merge_requests/2474

Several things about names:

First, I’ve gotten the feedback that “constants” might confuse users, who might not associate things like lambda’s with the word “constant”. An alternative is “global table of values”. I think I use “global constants” in the code. I’m not particular - we just need to pick something and I’ll make it universal in the code.

Second, about the names of the constants themselves (that is, their keys in the tables). For this initial pass I’ve allowed arbitrary strings, but obviously this is too lax. The choice before is: do we allow users to pick relatively arbitrary names (like package names in opam or npm)? Or do we do some kind of name based on the content of the value?

Allowing users to name things means we have to deal with several social problems like name squatting and name spacing.

Hashing the content is a really cool idea. Gabriel has pointed it out this locks us into whatever hashing algorithm we use - this is a serious drawback to be considered. However, overlooking that for a moment, there are some superpowers to be gained if we can find code on the chain based on its content. unison lang is doing some really stuff with content-addressed code, as is Formality lang/Moonad and it’s more recent incarnations. In short, if you have a guaranteed hashing scheme, you never have to publish the same code twice to the chain. Compilers could take advantage of this and hash-consing everything automatically, reducing the size of contracts substantially. The most used addresses could be heavily optimized (e.g., converted to native OCaml).

I’m sure there are drawbacks even beyond what Gabriel pointed out, otherwise everyone would be doing this aleady and Unison wouldn’t have any buzz about it. In fact, Arthur explicitly said we may want to avoid providing any guarantee of a mapping from value to address - I’d be interested to hear him elaborate on his reasons.

1 Like

@murbard , in your original post, you suggested a Michelson instruction that registers a global constant. What is the purpose of such an instruction? Why would contracts need to create libraries, rather than managers simply publishing them, (especially since you cannot dynamically construct lambdas from within Michelson)?

Isn’t this proposal less generic than the one about views (Views TZIP)? Assuming we have views I can register a constant c named n of type ty by originating the contract parameter never; storage unit; code {CAR; NEVER}; view n unit ty {DROP; PUSH ty c} and then I can access it by calling PUSH address "KT1.."; UNIT; VIEW n unit ty or am I missing something?