Verax Improvement Proposal [VIP-9] - Workflow Differentiation for “Attest” and “Replace”
Author[s]: @alain_ncls
Title: Workflow Differentiation for “Attest” and “Replace”
Type: Verax Improvement Proposal
Abstract
This proposal focuses on an upgrade to the Verax protocol to enhance the differentiation between “attest” and “replace” workflows.
Proposal Summary
Introduce an operationType string in the runModulesV2 function to differentiate between “attest” and “replace” workflows.
Overview of Proposal
This proposal aims to enhance the Verax protocol by allowing Modules to distinguish between “attest” and “replace” workflows through an additional parameter, operationType, in the runModulesV2 function. The key objectives include:
- Providing dedicated logic for “attest” and “replace” workflows in the Modules.
- Allowing Modules to perform operations specific to the workflow type.
Projected Timeline:
- Governance Vote: 2024-07-28T22:00:00Z (min. 2 weeks from publishing proposal)
- Deployment Target: 2024-08-04T22:00:00Z (min. 1 week from start of voting period)
Implementation Team:
- Development: Core Verax Development Team
- Review: Verax Governance Committee
Anticipated Benefits:
- Improved flexibility and functionality of the Verax protocol.
- Enhanced ability for Modules to perform specialized tasks based on the workflow type.
Motivation
The current implementation of the runModulesV2 function does not differentiate between “attest” and “replace” workflows, limiting the ability of modules to execute workflow-specific logic. By introducing an operationType parameter, this proposal aims to enhance the functionality and versatility of the Verax protocol, thus improving its adoption and integration within the ecosystem.
Technical Considerations
The technical aspects of this proposal include:
- Modifying the
runModulesV2function in theModuleRegistrycontract to accept an additionaloperationTypeparameter. - Updating the
AbstractModuleV2interface to handle the new parameter. - Updating the
AbstractPortalinterface to pass the new parameter to the Module.
Previous Implementation:
function runModulesV2(
address[] memory modulesAddresses,
AttestationPayload memory attestationPayload,
bytes[] memory validationPayloads,
uint256 value,
address initialCaller,
address attester
) public {
if (modulesAddresses.length == 0) return;
if (modulesAddresses.length != validationPayloads.length) revert ModuleValidationPayloadMismatch();
for (uint32 i = 0; i < modulesAddresses.length; i = uncheckedInc32(i)) {
if (!isRegistered(modulesAddresses[i])) revert ModuleNotRegistered();
AbstractModuleV2(modulesAddresses[i]).run(
attestationPayload,
validationPayloads[i],
initialCaller,
value,
attester,
msg.sender
);
}
}
Proposed Implementation:
function runModulesV2(
address[] memory modulesAddresses,
AttestationPayload memory attestationPayload,
bytes[] memory validationPayloads,
uint256 value,
address initialCaller,
address attester,
OperationType operationType
) public {
if (modulesAddresses.length == 0) return;
if (modulesAddresses.length != validationPayloads.length) revert ModuleValidationPayloadMismatch();
for (uint32 i = 0; i < modulesAddresses.length; i = uncheckedInc32(i)) {
if (!isRegistered(modulesAddresses[i])) revert ModuleNotRegistered();
AbstractModuleV2(modulesAddresses[i]).run(
attestationPayload,
validationPayloads[i],
initialCaller,
value,
attester,
msg.sender,
operationType
);
}
}
Deployment Considerations
As the onchain upgrade for Modules V2 has not been done yet, we can take this opportunity to still change the signature of the runModulesV2 function without breaking backward compatibility. This means that the upgrade of the contract will contain both these VIPs implementations.
Research Outcomes
The necessity and potential effectiveness of this upgrade are supported by:
- Analysis of current limitations in handling different workflows.
- Feedback from the community and developers indicating the need for enhanced workflow differentiation.
- Studies on the potential improvements in efficiency and functionality provided by the proposed changes.
Conflict of Interest
No conflicts of interest to disclose.
Next Steps
- Publish the proposal for community review and feedback.
- Conduct the governance vote.
- Implement the changes in the
ModuleRegistrycontract. - Update and test all relevant modules.
- Deploy the updated contracts to the testnets and mainnets.