RFC 54 - Published and Unpublished DataType

#1

Discussion topic for RFC 54.

13 Likes
#2

From Unresolved Questions:

It is not clear if the special OwnerGet RPC is worthwhile enough. The data is stored publicly by the vaults so is retrievable by them anyway. The Network doing extra checks and work to make certain data get-able only by the owner(s) (or keys authorised by the owner(s)) for something that is stored in public by the vaults and can be worked around with not much effort (e.g., published on clearnet etc.) seems like an artificial constraint. Also there isn’t much incentive for the vaults to adhere to this behaviour. Can it in-fact, over a period of time, might become a norm for the vaults to just return data irrespective of the asker (which is the case now) for GETs and earn rewards for doing such work anyway ?

Yeah this is tricky!

I reckon the check adds a good ‘extra level’ of security which is certainly imperfect but still probably quite robust in practice.

One thing that niggles me here is more complex ownership structures in the future may cause a lot of friction here.

eg time-based-locks or hierarchical multisig or oracle-based checks etc. may impose a lot of work on the ownership checking.

This might reduce the usefulness of the datatype or introduce attacks on the verifiers.

I don’t like to over-optimise for merely a ‘maybe’ future problem, but this seems worth further reflection.

My current thinking is the ‘protection’ of OWNER-GET is not enough to justify the possible future difficulties it will bring or the additional network load caused by longer routes.

Still gotta ruminate on it for a while.

5 Likes