Replies: 2 comments
-
|
Would be great to have your input on that @bobbinth |
Beta Was this translation helpful? Give feedback.
-
|
Some preliminary thoughts: The things which may make sense to store on-chain in a hybrid mode are: code, vault, storage (account ID always stored on-chain, and i'm not sure if there is much value in hybrid storage mode for the nonce). There are also different levels of "hybrid" for each of the above. If we take account code, for example, the levels could be:
Post MASM/MAST refactoring, one can argue that 3 and 4 are basically the same thing and the user can chose how much of the code to reveal publicly. Similar levels exist for storage (none, commitment, all) and vault (none, commitment, all). Also, it is important to note that if we chose
This is 9 possible combinations, and if we overlay them with the possibility of encrypting all, or some, elements - we get even more (i.e., up to 28). So, the question is: do we we want to support full flexibility (which will come at the expense of considerable complexity)? Or do we want to support just a subset of possible options, and if so, which subset? |
Beta Was this translation helpful? Give feedback.
-
It could be interesting to research hybrid account models where a certain amount of data would be stored on-chain and another amount of data would be stored of chain:
Considering the following account model:
It could be interesting to have the following model, for example:
This would enable to have a public interface for the account, hence any user on the network could know what functions are implemented on the account interface but would not have access to the account vault, hence privacy at the asset level.
This would be an example of hybrid accounts enabling both privacy and better usability.
Beta Was this translation helpful? Give feedback.
All reactions