You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One thing that we have had for a while without ever being particularly useful, is contract sets. We always thought about what they could be used for without having any need for them. Leading to over-engineered code, extra table joins and a more complicated API.
They are also very inconsistently used. e.g. downloads always use all contracts which makes sense too.
What we should do is add a column to the contracts table to indicate whether a contract is good for renewal. A contract that is good for renewal contributes positively to the health of a file and one that isn't causes the health to degrade.
If a contract becomes not good for renewal due to e.g. gouging and becomes good again afterwards it is fine to have more contracts than specified in the config. That will make sure temporary churn aborts unnecessary migration.
NOTE: this also means we should rename the Contracts setting to MinContracts to make it more clear that we no longer limit the number of contracts.
The text was updated successfully, but these errors were encountered:
Yeah, the original vision was that you could have different sets tuned for different parameters (cost, latency, throughput, location) and seamlessly switch between them. In practice no one does this because it would be a pain. I agree we should simplify things by assuming a single contract set.
One thing that we have had for a while without ever being particularly useful, is contract sets. We always thought about what they could be used for without having any need for them. Leading to over-engineered code, extra table joins and a more complicated API.
They are also very inconsistently used. e.g. downloads always use all contracts which makes sense too.
What we should do is add a column to the contracts table to indicate whether a contract is good for renewal. A contract that is good for renewal contributes positively to the health of a file and one that isn't causes the health to degrade.
If a contract becomes not good for renewal due to e.g. gouging and becomes good again afterwards it is fine to have more contracts than specified in the config. That will make sure temporary churn aborts unnecessary migration.
NOTE: this also means we should rename the
Contracts
setting toMinContracts
to make it more clear that we no longer limit the number of contracts.The text was updated successfully, but these errors were encountered: