As a subnet owner, I want the commit-reveal intervals to align precisely with the epoch tempo of my subnet, so that the commit and reveal phases begin and end at the expected times without any offsets.
Acceptance Criteria
Commit-Reveal Alignment: Commit-reveal intervals start and end exactly at the epoch boundaries defined by the subnet's tempo parameter, with no shifts or offsets.
Synchronized Intervals: For any subnet (netuid), the commit and reveal phases are synchronized with the epochs, allowing commits from the start to the end of an epoch without delay.
Calculations Based on Tempo: The system calculates commit and reveal intervals based solely on the subnet's tempo, ensuring consistency even if the tempo changes dynamically.
No Netuid-Based Offsets: The implementation removes any block offsets based on netuid that cause commit-reveal intervals to shift relative to the epoch.
Testing: Unit and integration tests confirm that commit-reveal intervals align with epochs across various tempos and subnets.
Documentation: Updated documentation reflects the alignment change, explaining that commit-reveal intervals now align with epochs without offsets.
2. Concealment Period Expressed in Tempos
User Story
As a subnet owner, I want to configure the concealment period using tempos instead of block numbers, allowing for dynamic tempo lengths and ensuring consistent concealment durations across different subnet configurations.
Acceptance Criteria
Concealment Period Configuration: Subnet owners can configure the concealment period using an integer number of tempo units rather than fixed block counts.
Dynamic Tempo Support: The system correctly adapts the concealment period when the tempo changes dynamically, ensuring the concealment duration remains consistent in terms of epochs.
Internal Calculations: The system internally converts concealment periods from tempos to blocks for precise timing while abstracting this complexity from users .
Testing: Unit tests cover scenarios with varying tempos to ensure the concealment period always corresponds accurately to the configured number of tempos.
Documentation: Documentation guides subnet owners on setting concealment periods in tempos and explains the implications of dynamic tempo changes.
3. Return Extrinsic ID upon Commit
User Story
As a validator, I want the commit operation to return an extrinsic ID (block serial number and transaction index within the block) through the Python layer to the caller, so I can accurately track and reference my commits in subsequent operations.
Acceptance Criteria
Extrinsic ID Availability: Upon successful commit, the system returns an extrinsic identifier containing the block number and the transaction index within that block.
API Integration: The extrinsic ID is accessible through the Python API layer and is provided back to the caller without additional requests.
Unique Identification: The extrinsic ID uniquely identifies each commit transaction, allowing validators to reference and track their commits reliably.
Error Handling: If retrieval of the extrinsic ID fails, the system provides an informative error message, and the commit operation remains unaffected.
Testing: Tests validate that the extrinsic ID is correctly returned for commits under various conditions and that the API passes it through to the caller.
Documentation: Instructions and examples are updated to show how validators can access and utilize the extrinsic ID after committing.
4. Enhanced Error Reporting
User Story
As a validator, when I attempt to commit or reveal weights but violate protocol terms, I want to receive clear and informative error messages detailing the violation and guidance on how to resolve it, instead of generic or vague error messages.
Acceptance Criteria
Specific Error Messages: The system returns clear and specific error messages detailing the exact reason when a commit or reveal operation fails due to protocol violations.
Helpful Guidance: Error messages include actionable guidance, such as:
"You must wait another X blocks to reveal this commit."
"The reveal period for your commit has passed Y blocks ago."
"Commit phase has not started. It will begin in Z blocks."
Relevant Parameters: Error messages display relevant hyperparameters (e.g., concealment duration, current block, required wait time) to aid understanding.
Consistent Formatting: All error messages follow a consistent format and style, making them easily recognizable and understandable.
Testing: Tests cover various failure scenarios to ensure the correct error messages are returned and include accurate information.
Documentation: The error messages are documented, explaining their meanings and suggested user actions for each.
5. Support Multiple Weights per Tempo
User Story
As a validator, I want the commit-reveal mechanism to support submitting multiple weight updates per tempo, so I can adjust my weights granularly within the same tempo without being limited to a single submission.
Acceptance Criteria
Multiple Updates Allowed: Validators can commit and reveal multiple weight updates within the same tempo without restrictions unless explicitly configured otherwise.
No Unintended Enforcement: The system does not accidentally enforce a single weight update per tempo due to code logic or configuration defaults.
Proper Tracking: Each commit and reveal within the same tempo is tracked independently, ensuring validators' multiple updates are processed correctly.
Testing: Tests confirm that multiple weight updates within a single tempo are accepted, committed, and revealed as expected.
Documentation: Guidelines are provided on how validators can submit multiple weight updates in the same tempo, including any limitations if they exist.
6. Support Multiple Unrevealed Commits
User Story
As a validator, I want the ability to have multiple unrevealed commits across tempos, enabling me to commit weights multiple times and reveal them after several tempos, while the system correctly tracks and validates each commit-reveal sequence.
Acceptance Criteria
Multiple Unrevealed Commits: Validators are able to have multiple unrevealed commits across different tempos, accommodating strategies that involve delayed reveals.
Individual Commit Tracking: The system maintains individual records for each commit, ensuring they can be revealed independently at the appropriate times.
Reveal Timing Enforcement: The system checks that reveals occur within valid intervals for each specific commit, based on when the commit was made.
Commit Identification: Validators can reference their commits using extrinsic IDs or hashes when revealing to ensure the correct pairing.
Testing: Tests verify that multiple unrevealed commits are managed correctly, with reveals processed in accordance with protocol rules.
Documentation: Instructions are provided on handling multiple commits and reveals, including examples and best practices for validators.
7. Enforce Order of Reveals
User Story
As a subnet owner, I want the system to enforce the order of weight reveals based on the commit sequence, preventing validators from selectively revealing commits out of order or skipping reveals to manipulate outcomes, thus ensuring fairness and integrity.
Acceptance Criteria
Sequential Reveals Required: Validators must reveal their commits in the exact order they were made; the system enforces this sequence strictly.
Skip Prevention: Validators are not allowed to skip reveals of earlier commits to reveal later ones. Attempting to do so results in an error.
Error Messaging: If a validator tries to reveal commits out of order, the system provides a clear error message explaining the violation and indicating which commit must be revealed next.
Forfeiture Option: Validators may choose to forfeit unrevealed commits, but the system requires acknowledgment of this action, possibly with a penalty or effect on participation.
Testing: Tests confirm that out-of-order reveal attempts are rejected and that the enforcement logic works across various commit sequences.
Documentation: Guidelines explain the importance of revealing commits in order and outline the consequences of failing to do so.
8. Handle Incomplete Reveal Sequences
User Story
As a subnet owner, I want the system to exclude a validator's votes from epoch calculations if they have not revealed all commits within a given interval, preventing validators from only revealing favorable commits and promoting honest participation.
Acceptance Criteria
Epoch Calculation Exclusion: Validators who have unrevealed commits within a given interval are excluded from weight-based calculations for that epoch.
Notification of Incompletion: Validators receive notifications or error messages if they have incomplete reveal sequences affecting their epoch participation.
Integrity Assurance: The system ensures that only fully revealed and valid weight updates are included in epoch calculations, maintaining fairness.
Selective Reveal Prevention: Validators cannot reveal only favorable commits to influence outcomes; incomplete sequences result in exclusion.
Testing: Tests verify that validators with incomplete reveals are appropriately excluded and that the system handles these cases gracefully.
Documentation: Explanations are provided about the impact of incomplete reveal sequences and the importance of timely reveals.
9. Practical Integration Guide for Subnet Owners
User Story
As a subnet owner, I want a concise and practical guide on how to integrate the commit-reveal mechanism into my subnet, including examples and necessary configurations, so I can implement it efficiently without relying solely on theoretical documentation.
Acceptance Criteria
Comprehensive Guide Creation: A concise, step-by-step integration guide is provided for subnet owners detailing how to configure and implement commit-reveal.
Configuration Instructions: The guide includes explicit instructions on setting commit-reveal parameters such as intervals, concealment periods, and any related hyperparameters.
Code Examples: Practical code snippets and configuration file examples are provided to illustrate typical setups.
Best Practices: Recommendations are included on best practices, common pitfalls, and how to avoid them during integration.
Template Integration: The guide references or includes updates to the subnet template repository to demonstrate commit-reveal integration in a standard setup.
Accessibility: The guide is easily accessible, possibly linked from main documentation pages, and written in clear, understandable language.
gztensor
commented
1 month ago
1. Alignment of Commit Interval with Tempo
User Story
As a subnet owner, I want the commit-reveal intervals to align precisely with the epoch tempo of my subnet, so that the commit and reveal phases begin and end at the expected times without any offsets.
Acceptance Criteria
tempoparameter, with no shifts or offsets.netuid), the commit and reveal phases are synchronized with the epochs, allowing commits from the start to the end of an epoch without delay.tempo, ensuring consistency even if thetempochanges dynamically.netuidthat cause commit-reveal intervals to shift relative to the epoch.2. Concealment Period Expressed in Tempos
User Story
As a subnet owner, I want to configure the concealment period using tempos instead of block numbers, allowing for dynamic tempo lengths and ensuring consistent concealment durations across different subnet configurations.
Acceptance Criteria
tempounits rather than fixed block counts.tempochanges dynamically, ensuring the concealment duration remains consistent in terms of epochs.3. Return Extrinsic ID upon Commit
User Story
As a validator, I want the commit operation to return an extrinsic ID (block serial number and transaction index within the block) through the Python layer to the caller, so I can accurately track and reference my commits in subsequent operations.
Acceptance Criteria
4. Enhanced Error Reporting
User Story
As a validator, when I attempt to commit or reveal weights but violate protocol terms, I want to receive clear and informative error messages detailing the violation and guidance on how to resolve it, instead of generic or vague error messages.
Acceptance Criteria
Specific Error Messages: The system returns clear and specific error messages detailing the exact reason when a commit or reveal operation fails due to protocol violations.
Helpful Guidance: Error messages include actionable guidance, such as:
Relevant Parameters: Error messages display relevant hyperparameters (e.g., concealment duration, current block, required wait time) to aid understanding.
Consistent Formatting: All error messages follow a consistent format and style, making them easily recognizable and understandable.
Testing: Tests cover various failure scenarios to ensure the correct error messages are returned and include accurate information.
Documentation: The error messages are documented, explaining their meanings and suggested user actions for each.
5. Support Multiple Weights per Tempo
User Story
As a validator, I want the commit-reveal mechanism to support submitting multiple weight updates per tempo, so I can adjust my weights granularly within the same tempo without being limited to a single submission.
Acceptance Criteria
6. Support Multiple Unrevealed Commits
User Story
As a validator, I want the ability to have multiple unrevealed commits across tempos, enabling me to commit weights multiple times and reveal them after several tempos, while the system correctly tracks and validates each commit-reveal sequence.
Acceptance Criteria
7. Enforce Order of Reveals
User Story
As a subnet owner, I want the system to enforce the order of weight reveals based on the commit sequence, preventing validators from selectively revealing commits out of order or skipping reveals to manipulate outcomes, thus ensuring fairness and integrity.
Acceptance Criteria
8. Handle Incomplete Reveal Sequences
User Story
As a subnet owner, I want the system to exclude a validator's votes from epoch calculations if they have not revealed all commits within a given interval, preventing validators from only revealing favorable commits and promoting honest participation.
Acceptance Criteria
9. Practical Integration Guide for Subnet Owners
User Story
As a subnet owner, I want a concise and practical guide on how to integrate the commit-reveal mechanism into my subnet, including examples and necessary configurations, so I can implement it efficiently without relying solely on theoretical documentation.
Acceptance Criteria
Related Link