bedeho
commented
4 years ago Simple ideas
- limit total number of active proposals, and the fee is set by a function that explodes in terms of the number of currently outstanding proposals, or the number of proposals submitted within some window of time into the past, to penalize spamming.
- do not limit the number of active proposals at once, just require that its one cannot submit more than N proposals that will finalize (at the latest) in any given block. This allows sidestepping voting iteration and instead of storing when proposals should be processed in terms of blocks.
I believe the proposal system currently puts a limit on the number of proposals that can be in the pipeline at any given time. This can be exploited by an attacker to introduce a delay in the ability of the council to respond to some sort of abuse or problem via the proposal system. They would have to be willing to incur the risk of losing a proposal stake in a large number of Sybil proposals, but it could be worth it, given the return on the attack in some subsystem. This should be carefully evaluated at some point, and if the risk depends on parameter values, then it should at least be recorded in the Handbook to inform the future community about risks of changing values.