Verax Improvement Proposal [VIP-8] - Modules V2

Verax Improvement Proposals
1

Verax Improvement Proposal [VIP-8] - Modules V2

Author[s]: @alain_ncls

Title: Modules V2: Additional Fields for Enhanced Flexibility

Type: Verax Improvement Proposal

Abstract

This proposal focuses on an upgrade to the Verax protocol, around the Modules feature.

Proposal Summary

Introduce additional fields attester and portal in the function calling the Modules for higher flexibility and more complex use cases.

Overview of Proposal

The “Modules V2” upgrade allows additional fields attester and portal to be added in the function calling the Modules, providing extra context. This change offers higher flexibility to build more complex use cases, such as dynamic sender validation, which no longer needs to be hardcoded in the Module. No changes will be required for Modules already deployed but we should plan deprecation of the previous Module interface after a few months.

The objectives are to:

  • Enhance the flexibility of the Verax protocol.
  • Enable more complex use cases and dynamic validation.
  • Maintain backward compatibility while planning the deprecation of the old interface.

The team responsible for implementation includes the core developers of the Verax protocol.

Motivation

The proposed upgrade is relevant to enhancing Verax’s adoption and integration within the existing ecosystem. By adding the fields attester and portal, the upgrade enables dynamic sender validation and other complex use cases, which can significantly improve the protocol’s flexibility and usability.

Technical Considerations

The technical aspects involve updating the AbstractModule to AbstractModuleV2, adding additional parameters to the run function in Modules, and updating related contracts like AbstractPortal and ModuleRegistry to support the new interface. The key challenge is ensuring backward compatibility and a smooth transition to the new interface.

Expected Timeline

  • Governance Vote: 2024-07-03T22:00:00Z
  • Deployment Target: 2024-07-10T22:00:00Z

Design Considerations

The design of the upgrade encompasses modifying the run function signature in the Module to include attester and portal, updating the AbstractPortal to handle the new V2 methods, and ensuring that the ModuleRegistry can support both old and new interfaces. The core team will be responsible for implementing and maintaining the upgraded components.

Deployment Considerations

The technical approach to implementing the upgrade involves:

  • Introducing a new AbstractModuleV2 contract.
  • Updating the ModuleRegistry with new V2 methods.
  • Modifying existing modules to support the V2 interface.

The deployment will be handled by the core team, ensuring minimal disruption to the existing ecosystem.

Research Outcomes

The research supporting this upgrade indicates that adding flexibility and context to the Modules can significantly enhance their usability and allow for more dynamic and complex use cases. Our experience with multiple issuers suggest that this upgrade will improve the protocol’s adaptability and long-term sustainability, helping onboard new issuers with more diverse use cases.

Conflict of Interest

No potential conflicts of interest have been identified. All contributors to this proposal are motivated by the goal of improving the Verax protocol.

Next Steps

Submit the proposal to the governance forum.
Collect community feedback and incorporate it into the final proposal.
Schedule the governance vote.
Begin the deployment process after a successful vote.

References and Links

GitHub Pull Request: Link to PR
Related Issue: #574

2

I’d also suggest adding the ability in the portal’s smart-contract to retrieve a user’s attestation list by their wallet address. So that it would be possible to receive this data onchain (now for this purpose subgraph - offchain data receipt is used). This would allow seamless verification of attestation data from other smart-contracts.

3

That’s an interesting suggestion!

For now, we have the IndexerModule, which can index attestations by “subject” (i.e., providing a user’s attestation list by their wallet address, as you mentioned). For reference, this is the mapping storing that information.

The main caveat that I can see with this kind of implementation (at the Portal level or via a Module) is the gas cost of such an operation. The more data you store while attesting, the higher the gas cost to issue one attestation.

What about a case-by-case approach?

  • We create such a Portal (IndexerPortal?), as an example, without changing the AbstractPortal.
  • By default, Issuers use the AbstractPortal, not indexing the issued attestations (the cost to issue an attestation doesn’t change).
  • If an Issuer wants to index the attestations they issue for future checks, they can deploy the IndexerPortal and use it for their specific use case.

This approach doesn’t cover the case where Issuer A wants to act differently depending on Issuer B’s attestation, though.

What do you think?

4

Yeah, that’s a workable option. In this case, it would be nice to be able to connect modules after the Portal contract has been deployed. This would allow to manage dependencies flexibly and change the behavior of Portal depending on changing conditions.

5

Oh man, do I have a proposal for that! :grin:
=> Allow Variable Modules in Portals

1 Like