Shared storage for instantiable FRAME pallets

[sacha-l]

Implementing instantiable pallets could benefit from more flexibility and ease of usability if they could share common storage items. This was brought up at Substrate Seminar by @chevdor whereby the following scenario was outlined to give a practical use case example:

• Assume a runtime has 100 instances of the Societies pallet
• Each Society shares some common constant, such as the minimum balance of a societies treasury for it to stay alive
• Over time, as per discussions within the governing body of this system containing all these Societies, this constant may change
• How could a change to a constant (which must remain common to all Societies) be brought without needing to make 100 separate calls to storage?

As pointed out by @shawntabrizi, the work-away around this would be to create a custom instantiable pallet (not using FRAME) and to hardcode some shared storage key where all pallets will know to look when needed to retrieve the common information they require. Having FRAME give developers this possibility "out-the-box" could be something useful. Thanks @chevdor for the thinking here!

[bkchr]

A shared storage item mostly makes sense for stuff that is only read. Aka you can use a constant and all instantiated pallets already can share the same constant.

When you want to have some shared storage item that you write from multiple pallets, you probably require some custom logic anyway. Not sure what we should do here?

[shawntabrizi]

this would be to create a custom instantiable pallet (not using FRAME)

This is not accurate. You could completely use FRAME here, but you would just use the low level sp-io libraries to write to a specific storage key versus using decl_storage or #[pallet::storage] to automatically generate that stuff for you.

I somewhat agree with Basti that in most cases here, a configuration variable which points all pallets to some single storage/hard-coded value would work, that being said I dont think it is out of question for a feature like this to exist. Basically some way to tell the storage macros to not add the instantiation prefix to the storage key

[chevdor]

Thanks @sacha-l for opening this "issue" and putting me in CC in the discussion. Indeed the idea I had in mind goes mostly in the direction of read-only storage. So the solutions mentioned above sound good to me.

I could imagine that we, in theory, could make use of a "static" behavior where all instances could read but also write a single common state.

An example could be multiple treasury instances that want to ensure they all track the same base USD reference price. Any of the instance can update the price for all the others. This specific example is however a little far stretched as we would probably use an external oracle that is not part of any of the instances and handle the modification of the common price.

One benefit of such a static R/W behavior is that we keep it all inside the instance implementation. It would not matter whether we end up deploying one or mutiple instances and it would not require any global/external storage. This is obviously assuming that instance managers (accounts authorized to modified such a static variable) are the same or similar and have all access to modify the value from any of the instances.

[xlc]

This is possible with #6296

[stale]

Hey, is anyone still working on this? Due to the inactivity this issue has been automatically marked as stale. It will be closed if no further activity occurs. Thank you for your contributions.