Revisiting the initial Safecoin Design for native Token

So, this has got in my head now. Just woke up thinking about it! :sweat_smile:

I’m actually wondering why all mutable types currently use key addressing, with derived private key. I’m tempted to review the code to understand more.

I’m assuming it is because it is a cheap operation to validate that the owner is the one doing the mutation. It is just a unique value that is impossible to guess. Therefore, signature checking becomes a secondary, more computationally costly step.

However, (private) key addressing is frustrating in a number of use cases, where being able to derive an address (from a public convention) would be extremely useful (see above post for these, but others too).

Assuming this is a decision for validation efficiency, that comes at a high usability cost in many cases.

Given we could attach a public key to any mutable data, which could be used to validate the owner for mutations, it would seem like a feasable alternative. The seed key to derive the address could be based on public information instead, allowing arbitrary keys for storage and reassignment of ownership.

Ofc, it would mean nodes having to check signatures as a primary validation operation, but arguably getting quotes to perform a potential mutation is at least a heavy lift.

Edit: fwiw, just adding an ‘owner’ public key field to existing types, then using this to derive ownership could suffice. Allowing more flexibility in address choice would improve on that too.

3 Likes