Are durableHandles superior over plain strings when used as "key" in store?

[anilhelvaci]

Let's say we have some durable objects that we need store in a Zoe contract. I'm struggling to determine the form of the key to be used when storing those objects. The usual suspects are;

• durable handles
• strings

One advantage I can think of for using durableHandles is that we don't need any efforts to make sure the uniqueness of our keys. But on the other hand, having live objects as keys means that we need to deal with their marshalling in our tests. Especially going from unit tests to full e2e tests. In our case, end users will use these keys to specify what they want from the contract (getSomething(key)). This is pretty similar to how vault factory selects collateral managers by getCollateralManager(collateralBrand). I would appreciate if someone validate my approach or let me know if there's anything missing. Thanks 🙏

cc @dckc

[dckc]

As you point out, there are advantages and disadvantages to each; it's not the case that handles are always superior to strings as keys.

The terminology we use to talk about the distinction is: strings are forgeable identities, and handles are unforgeable.

strings can be effectively unforgeable in some senses, if sufficient entropy is used to allocate them; but since the operation of the chain and the JS VM are visible to anyone running a node, they could take that string and use it in a contract. This is not so for unforgeable objects. Even if you have all sorts of knowledge about the identity, there's no way to break ocap access rules and get a reference in a contract.

cc @Jovonni

[erights]

strings can be effectively unforgeable in some senses

in some senses, yes. But the rest of the paragraph above makes clear the senses in which it is not. Better to say that strings and numbers can be unguessable but cannot be unforgeable. Another way to make the distinction clear: objects as access limited. Strings and numbers are (only) knowledge limited.

[anilhelvaci]

Thanks a lot for this awesome clarification! I believe there are some advantages to be made in terms of simplifying the source code in exchange for possible complexity in the test code which is a trade off I'm happy to make. Great answer, thanks again 👍