Investigate need of the topup feature and iterate on implementation

[ctrlc03]

As of now, the topup feature has not been used in production, although clr.fund has found an interesting use case and have been hitting blockers (#1133).

MACI should decide whether the overhead of this functionality is worth keeping (especially considering the increased number of constraints in the circuits and complexity logic).

Should this be kept as part of the core protocol, one suggestion would be to allow for poll specific topups to live in a separate tree, so that they are accounted for at the beginning of a poll, not in the middle of message processing. This way, whether a topup was performed at the beginning or end of a poll, the new number of voice credits should be considered by the offchain processing code, and allow voters to overspend credits before they are topped up. This way, message processing order would not affect the feature.

[kittybest]

Question: what does the topup feature designed at the very beginning? like under what kind of condition?
I agree with that sum up topup credit at the end of a poll, then process the messages, if there are overspend credits, then those overspend part would be invalid?

[ctrlc03]

Question: what does the topup feature designed at the very beginning? like under what kind of condition?

You can read on the feature proposal here https://hackmd.io/@chaosma/rkyPfI7Iq

if there are overspend credits, then those overspend part would be invalid?

Yes totally, just like they are invalid without a topup taking place