Multiple Configurations Approach - a possible design pattern?

Move
#1

Hello again!
Recently I have been thinking about global variables in Move. Some time ago it was proposed, that there could be a convenience variable to get the deployer’s address, and store global singletons there (Any notion of global variables?).

However, I was thinking, because of Move’s transaction script structure, what if ditching globals alltogether?

I mean, that transaction script could point to a account with a configuration resource.

By designing your smart contract like this, you would automatically add a layer of configurability.

Let’s say you have an auction smart contract X. and an admin has created a configuration to account A. Then B could issue a transaction script to bid on C’s resource like this:

X.place_bid(A, C, 1234);

By accepting parameters (such as C and the amount 1234), a transaction script could trivially hide the selection of the configuration. This depends, how flexible the final script implementation is in terms of arguments to main(), but the transaction script could look like this (quick mock-up):

script {
    use 0xFF::X;
    
    const CONF: address = 0xCOFFEE;

    fun main(a: address, amount: XUS) {
        X.place_bid(CONF, a, amount);
    }
}

The multiple configuration setting could be part of the design, like with Uniswap, which lets anyone to create markets, or admins (if any) could grant permissions to create configurations.

This would provide flexibility in the future, and make “global” variables obsolete.

What do you think?

Best regards,
Ville

2 Likes
#2

Yes, I think this is a sensible design pattern that makes it easy to create and share configurations.

We use a somewhat similar pattern to provide multiple configurations under the same address: index the configuration by type instead of by address. For example, the DIP20 coin standard (and corresponding Diem<CurrencyType> resource) store all coin configurations under the 0xA550C18 address indexed by CurrencyType. This is a good pattern if you want to restrict who can create configs (as we do here: only the Association should be able to create new currencies). But the address-indexed variant you describe probably makes more sense if you want to allow anyone to create configs.

2 Likes