Module Installation Flow

Module Installation Flow

Context and Problem Statement

A clear flow for module installations needs to be established to ensure proper instantiation of the account's infrastructure. When defining this flow a couple problems emerge.

1. A module can have dependencies. These dependencies need to be asserted.
2. A module with a dependency might want to call it's dependency at instantiation. I.e. the dependency must already be part of the infrastructure at the moment of instantiation of the module.
3. A module could want to execute actions on the account at instantiation.

Considered Options

• Post-install Hooks
• Flush Flags
• Instantiate2
• Self Registration

Current Implementation

The current implementation has the following flow:

1. The manager calls the module factory with all the modules it wants installed.
2. The module factory creates all the instantiation (sub)messages and catches all their replies. Saving the mapping Module -> Addr.
3. When all the contracts are instantiated the module factory registers the modules with the manager contract (and subsequently the proxy).

• Problem: A module with a dependency can not access that dependency's address at instantiation as it is not yet registered with the manager.
• Problem: That same module can not perform mutating logic on either the proxy or any of its dependencies as it does not have the permissions to do so yet.

test-case failure example

Decision Outcome

Chosen option: TBD But I (Howard) lean into exploring the instantiate2 approach.

Consequences

• Good,

• Bad,

Pros and Cons of the Options

Post-install Hooks

A module can configure a message that should be called on it after all the modules have been registered successfully.

This could be implemented on the registry store and loaded by the manager itself or passed on by the module factory.

• Good, because it would be relatively simple to implement.
• Bad, because it requires the developer to add a separate entrypoint for instantiation finalization.
• Bad, because it doesn't really solve the problems as they are stated. This is a bandaid solution.
• Bad, high gas consumption

Flush Flags

A flush flag could be passed/configured for each module. The flag would "flush" the installation process. Essentially whenever a flush flag is encountered the registration process is triggered. This functionally separates the installation process of a module's dependencies from its own instantiation.

• Good, ?
• Bad, dangerous to introduce complexity into the registration/privileging process.
• Bad, requires extra thought by the module developer/account creator
• Bad, high gas consumption

Instantiate2

By using instantiate2 we can front-load module registration and permissioning. When the module-factory receives its request it can compute the addresses of the to-be-installed modules. It can then register these modules with the manager before actually instantiating the modules.

• Good, cleanest implementation
• Good, no overhead for devs/users
• Good, improves gas usage
• Bad, requires instantiate2 (do all chains support this yet?)
• Bad, requires thoughtful design around the instantiate2 salt.

Self-registration

Adapters could self-register. Meaning they perform a call to the manager themselves that registers them. This could be done by setting the manager in a Configurable state that allows any contract to register itself to the manager while it is in that state.

• Good, ?
• Bad, doesn't give contract execution permission during its instantiation, only after (like in a reply)
• Bad, more gas usage.

More Information

instantiate2