The number of harvesters (and number of excluded addresses) are practically limited by the available gas in a transaction. This means that if either of these get too large then they contract will revert. In the case of too many harvesters this would be catastrophic as harvesting would fail permanently.
This is the number of harvesters total, not just active harvesters.
Understanding the gameplay and the admin roles, this does not seem likely to happen. However, understanding the possible future gameplay where a smart contract may be able to create its own harvesters, this may allow a situation where an untrusted third party could take down the application.
Rating note: If third-party harvester creation were part of the game today this would be a critical issue. Severity is reduced because only the admin could currently cause this problem and the admin is documented as a trusted entity.
Recommendation:
Documentation this limitation in functional level documentation (NatSpec). It will remind us in the future when building any third-party harvester automation tools of this risk.
If much harvester churn is expected (creating then disabling), switch to enumerated set data structure for harvesters, this allows better scalability.
Review if the expected use case for excluded addresses (today and in future) requires this same consideration.
Sorry for this late addition!
Related to https://github.com/ghoul-sol/treasure-staking/issues/51
The number of harvesters (and number of excluded addresses) are practically limited by the available gas in a transaction. This means that if either of these get too large then they contract will revert. In the case of too many harvesters this would be catastrophic as harvesting would fail permanently.
This is the number of harvesters total, not just active harvesters.
Understanding the gameplay and the admin roles, this does not seem likely to happen. However, understanding the possible future gameplay where a smart contract may be able to create its own harvesters, this may allow a situation where an untrusted third party could take down the application.
Rating note: If third-party harvester creation were part of the game today this would be a critical issue. Severity is reduced because only the admin could currently cause this problem and the admin is documented as a trusted entity.
Recommendation: