search

steemit / steem

The blockchain for Smart Media Tokens (SMTs) and decentralized applications.
https://steem.com
Other
1.95k stars 793 forks source link

Community Suggestion - RC Budget Witness Parameters #2991

Open TimCliff opened 6 years ago

TimCliff commented 6 years ago

The current implementation of RC budgets requires all witnesses to use the same budgets, otherwise there will be inconsistencies of behavior between nodes. Also, each time a budget is changed, it requires a code change and replay.

It seems that a more optimal way of handling changes in the RC budgets would be for witnesses to vote on each budget via a witness parameter, and have the blockchain use the median value as the current budget.

syvb commented 6 years ago

Just to be clear, would RCs still be implemented as a soft fork?

TimCliff commented 6 years ago

The witness parameter values would need to become part of consensus (afaik) but their enforcement through the RC plugin could still be done via non-consensus / soft-fork.

iamsmooth commented 6 years ago

I don't think this should be witness settable. One of the factors that go into RC limits is ability to run nodes which implicates all of those running nodes in the ecosystem, including those whose economic influence may far exceed their stake (such as large exchanges, potentially UI operators apart from steemit.com etc.).

Requiring all members of the ecosystem to buy into these limits via a node upgrade (or for that matter their initial decision to support the chain and run a node knowing some planned resource requirements) is more sensible than allowing witnesses to arbitrarily adjust, at any time without notice, which in effect puts the decision mostly in the hands of the largest stakeholders while imposing costs on those running nodes or potentially forcing them off the network altogether.

Some range of adjustments being dynamic by witnesses would probably be okay as long as the some overall cap on the rate of growth in node resources is enforced upon the witnesses (and requires a node upgrade/HF to change). Whether or not this is worth the added complexity is not really clear to me (what specific sort of use cases are in mind here?).

Yes, I know RC currently isn't enforced by consensus, sometimes exchanges don't need to upgrade, etc. but thinking about this going forward longer term this is how I believe it should work.