There is currently a limit on the number of concurrent ongoing proposals, due to the fact that proposals need to be sorted (for flush) and that this is done using a set, which cannot grow indefinitely without causing gas cost problems.
This issue is meant to try to remove this limit by changing how ongoing proposals are tracked, and it's similar in intention to what #311 did for voters.
One idea is to remove proposal_key_list_sort_by_level and replace it with:
two fields to track the first and last ongoing proposals
a big_map where the key is a proposal's ID and the value is a tuple with the proposal ID that comes next and previously
in this way we would obtain and keep a doubly-linked-list of ongoing proposals that could be accessed and updated lazily.
With this different implementation it should be possible to remove the proposal limit while keeping the same interface and behavior of all the entrypoints.
Some details might change during implementation and the cost of this change will need to be checked as well, but it should be worthwhile.
Note: if accepted, this would replace #68 and make #172 unnecessary.
Acceptance criteria
proposal_key_list_sort_by_level is replaced by a lazy doubly-linked-list and the proposal limit is removed.
Clarification and motivation
There is currently a limit on the number of concurrent ongoing proposals, due to the fact that proposals need to be sorted (for
flush) and that this is done using aset, which cannot grow indefinitely without causing gas cost problems.This issue is meant to try to remove this limit by changing how ongoing proposals are tracked, and it's similar in intention to what #311 did for voters.
One idea is to remove
proposal_key_list_sort_by_leveland replace it with:firstandlastongoing proposalsbig_mapwhere the key is a proposal's ID and the value is a tuple with the proposal ID that comesnextandpreviouslyin this way we would obtain and keep a doubly-linked-list of ongoing proposals that could be accessed and updated lazily.
With this different implementation it should be possible to remove the proposal limit while keeping the same interface and behavior of all the entrypoints.
Some details might change during implementation and the cost of this change will need to be checked as well, but it should be worthwhile.
Note: if accepted, this would replace #68 and make #172 unnecessary.
Acceptance criteria
proposal_key_list_sort_by_levelis replaced by a lazy doubly-linked-list and the proposal limit is removed.