Feat/multiple commits

[distributedstatemachine]

Description

Motivation for change

The current weight commitment system lacks flexibility and doesn't allow validators to queue multiple weight updates. This limitation can lead to inefficiencies in the network, especially during periods of high activity or when validators need to make rapid adjustments to their weights.

Behaviour pre-change

• Validators could only commit and reveal one set of weights at a time.
• There was no mechanism to handle multiple commits or to enforce the order of processing.
• Old commits were not automatically removed, potentially leading to storage bloat.

Behaviour post-change

• Validators can now commit multiple weight updates, which are processed in a First-In-First-Out (FIFO) order.
• A nonce system has been introduced to ensure monotonicity and prevent replay attacks.
• The system now enforces a limit of 10 pending commits per validator, automatically removing the oldest commit when this limit is reached.
• Old commits are now automatically removed after successful processing, improving storage efficiency.
• The do_commit_weights function now checks for nonce monotonicity and prevents duplicate nonces within the current interval.

Alternatives considered

1. Batch commits: We considered allowing validators to submit multiple weight updates in a single transaction. This was rejected due to increased complexity in processing and potential issues with transaction size limits.

2. Time-based expiry: An alternative to the FIFO system was to expire commits based on time. This was not implemented as it could lead to issues with network congestion and block time variations.

3. Unlimited commits: We considered allowing unlimited pending commits per validator. This was rejected to prevent potential DoS attacks and to limit storage usage.

Related Issue(s)

• Closes Enhance Commit/Reveal Mechanism to Allow Multiple Pending Commits #598

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Other (please describe):

##Breaking Change

If this PR introduces a breaking change, please provide a detailed description of the impact and the migration path for existing applications.

Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have run cargo fmt and cargo clippy to ensure my code is formatted and linted correctly
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

[orriin]

Does this need a migration?

[distributedstatemachine]

done. Can you please review the implementation and test