Allow Variable Modules in Portals

Verax Improvement Proposals
1

Verax Improvement Proposal [VIP-5] - Allow Variable Modules in Portals

Author: @alain_ncls

Title: Allow Variable Modules in Portals

Type: Verax Improvement Proposal

Abstract

This proposal aims to modify the current Verax protocol to allow Portals to have a variable set of Modules. Currently, once a Portal is deployed with a set of Modules, we cannot change those modules, their order, or their number. We cannot remove a Module from the list, nor can we add a Module to the list. This change would allow for greater flexibility and potential use cases within the Verax ecosystem.

Proposal Summary

The proposal suggests altering the Verax protocol to allow for variable Modules in Portals, thereby increasing the versatility and potential applications of Portals within the Verax ecosystem.

Overview of Proposal

The key objective of this proposal is to remove the fixed constraint from Modules in Portals in the Verax protocol. This would involve modifying the way Portals are deployed and how they interact with Modules, potentially allowing for the addition, removal, and reordering of Modules in a Portal.

Motivation

The current constraint of fixed Modules in Portals limits the potential use cases and flexibility within the Verax ecosystem. By allowing variable Modules in Portals, we can increase the versatility of Portals and open up new possibilities for their use.

This feedback was given by some members of the community, and should at least be shared and debated.

Technical considerations

Expected Timeline

  • Governance Vote: 2024-04-01T22:00:00Z
  • Deployment Target: 2024-04-08T22:00:00Z

Design Considerations

The design of this upgrade would involve modifying the way Portals are deployed and how they interact with Modules. This would require careful consideration to ensure that the integrity and functionality of the Verax protocol are maintained.

Deployment Considerations

The deployment of this upgrade would involve changes to the Verax protocol and potentially the Verax registry. This would require careful planning and testing to ensure a smooth transition.

Research Outcomes

Preliminary research suggests that allowing variable Modules in Portals could increase the versatility and potential use cases of Portals within the Verax ecosystem. Further research and testing will be required to confirm these findings and to identify any potential issues or challenges.

Potential solutions to make a Portal’s set of Modules variable:

  1. Allow each and every Portal to change its Modules
  2. Add a boolean field to the Portal object to make its list of Modules variable or not (by default variable)
  3. Add a boolean field to the Portal object to make its list of Modules variable or not (by default fixed)

Potential functions to add:

  1. Add a Module to the Portal’s list of Modules
  2. Remove a Module from the Portal’s list of Modules
  3. Reorder the Portal’s list of Modules

Potential field to add:

  1. Boolean field defining of a Portal’s set of Modules is editable

Conflict of Interest

There are no known conflicts of interest associated with this proposal.

Next Steps

Following the submission of this proposal, the next steps would be to conduct further research and testing, followed by a governance vote and, if successful, deployment of the upgrade.

References and Links

N/A

2

I think this is a very good idea as I have had this similar need before. It is equivalent to providing the portal with the ability to dynamically update. I previously turned the portal into an upgradeable contract to meet the needs of dynamically updating code. I think the Variable Modules solution is more flexible. If a module changes, you only need to replace this module.

3

I agree with this proposal. Only comment I have is that the intial idea behind this design was about designing a system where you trust the attestations based on the portal and modules. Having variable modules would then eliminate this. However, I think by using events for example, we could still keep a record offchain of what attestations were created with a certain portal and module configuration, if needed.

1 Like
4

An absolutely necessary improvement!