Make Schemas definition not unique

Verax Improvement Proposals
1

Verax Improvement Proposal [VIP-4] - Make Schemas definition not unique

Author: @alain_ncls

Title: Make Schemas definition not unique

Type: Verax Improvement Proposal

Abstract

This proposal aims to modify the current Verax protocol to allow non-unique Schemas. Currently, Schemas are made unique by taking a hash of their definition. 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 non-unique Schemas, thereby increasing the versatility and potential applications of Schemas within the Verax ecosystem.

Overview of Proposal

The key objective of this proposal is to remove the uniqueness constraint from Schemas in the Verax protocol. This would involve modifying the way Schemas are hashed and stored in the registry, potentially allowing for multiple instances of the same Schema.

Motivation

The current constraint of unique Schemas limits the potential use cases and flexibility within the Verax ecosystem. By allowing non-unique Schemas, we can increase the versatility of Schemas 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 must at least be debated.

Technical considerations

Expected Timeline

  • Governance Vote: 2024-03-24T23:00:00Z
  • Deployment Target: 2024-04-01T22:00:00Z

Design Considerations

The design of this upgrade would involve modifying the way Schemas are hashed and stored in the registry. 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 non-unique Schemas could increase the versatility and potential use cases of Schemas 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 generate a new hash of a Schema (hence its ID), by including more or less data in its computation:

  1. From the Schema’s definition + name (differentiate Schemas by their name)
  2. From the Schema’s definition + name + description (differentiate Schemas by their name and/or description)
  3. From the Schema’s definition + name + description + context (differentiate Schemas by their name and/or description and/or context)
  4. From the Schema’s definition + context (differentiate Schemas by their context)

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 don’t think there is much need to change. The main reasons are:

  1. Verax requires permissions to create a schema.
  2. If you have the same schema string, there is really no need to create it. You can share it, which can save gas.
  3. Attestation can be distinguished through the portal field
    Perhaps the only problem is that the fields displayed above https://explorer.ver.ax/ are not what the developer wants.
3

I agree with this proposal. I think schemas are an important way for projects to explain what the attestation represents, having full customiseability over the schema name, description etc should be offered to those teams