Background: the HatsModuleFactory
While Hats Protocol itself does not place any restrictions on who can deploy a module or how they can be deployed, the most common way is to use the HatsModulesFactory.
HatsModuleFactory and the HatsModule template provides some nice features for developers looking to build and deploy Hats modules:
- Module instances can be deployed cheaply by users as minimal proxy clones
- Such clones can incorporate immutable args for lower gas costs at runtime…
- …as well as initial mutable settings
- Instances can be immutably configured to align with a given target hat (or branch)
- Compatibility with the Hats Modules Registry, which enables users to configure, deploy, and manage modules from apps that support the registry (eg using the Modules SDK).
Potential Problem: fixing bad module configuration
When configuring module instances, users set up both the immutable args (2) as well as initial settings which can be modified later (3).
If they make a mistake on (2), they can easily redeploy with the correct settings. But they may not be so easily able to fix a mistake on (3) — or, indeed, if a mistake is made later to the mutable settings.
This is because immutable args and the target hat (4) are factors in determining the deployment address of the instance. Changing them will change the deployment address, allowing for redeployment. But if they need to stay the same, then redeployment would not be possible.
As a result, mistakes on mutable settings can only be resolved if the code in the module allows it. This is not ideal because it places additional burden on module developers to implement such logic (which is not always simple) as well as on module registry curators when reviewing new registry submissions.
Recommended Solution: add a salt nonce to the HatsModuleFactory
There is a clean solution to this problem: add an additional factor — a “salt nonce” — to the determinants of module instance deployment addresses to allow for the same instance to be deployed to a new address.
Here’s what a change to the HatsModuleFactory might look like:
Benefits
This solution has a number of benefits:
- Ensures Hats users can always* fix an erroneous configuration, regardless of whether the module developer explicitly implements the necessary in-module logic
- Avoids placing additional review burden on module registry curators
- Requires no changes to already-developed modules, since the change to the salt is applied at the factory level not the module level
- Fully backwards-compatible with existing module instances, for which the salt nonce value is effectively
0
*If the target hat is mutable. If a hat is immutable, its modules cannot be changed.
Work to be done
If we determine this is a good approach, here is what remains to be done
- The HatsModuleFactory contract code will need to be updated and tested
- It will need to be deployed to all existing Hats-supported networks
- The Modules SDK will need to be updated to support the new factory
- Existing Hats apps and clients will need to be updated to support the updated Modules SDK and factory
- They may also want to build in redeployment UX flows
Your Input Requested
I am interested in what the Hats community thinks!
- How urgent is this problem?
- Is the recommended solution advisable?
- Are there any drawbacks not considered here?
- Are there any additional steps or work to be done?