Today on the ICP Dashboard, we saw an updated front-end version preparing for the upcoming ‘private neurons’ feature, which was approved under proposal 130832. This feature will, among other things, hide the voting results for private neurons.
Summary
As a next natural step, in my opinion, we should increase the number of voting results that are visible for public and known neurons, with an initial suggestion to raise this limit to 1000 per topic.
Increasing this limit for public and known neurons would allow for more transparent and detailed tracking of the decisions these neurons make. This way, users could gain a fuller view of voting dynamics and better analyze trends and preferences within the network’s decision-making process.
Additionally, a higher limit would enable those who follow public neurons to conduct a deeper analysis of how each decision impacts the development direction of the Internet Computer. I hope the community sees the potential benefits of this change and supports this initiative with enthusiasm.
I’m curious to hear your thoughts! Do you also believe that increasing the storage limit to 1000 proposals for public neurons is a good step toward greater transparency and effectiveness?
I fully agree with this idea, but I would expand if further. Since all known neurons will be public and most other neurons will be private by default, there are not many neurons that will choose to become public. Hence, I would like to see all known and public neurons have a recorded vote history measured in years (e.g. 5 years). I also think this recorded history should exist in the NNS governance canister instead of 3rd parties needing to create databases of this historical data. Everyone who wants to build apps that tracks this governance information should have access to the same primary data.
Yes, I also believe that for private neurons, the on-chain voting history is required and essential only up to the point of the next reward distribution round. If someone wants their results to be stored longer on a public blockchain, they should simply choose to make them public - why not? Otherwise, I don’t see any purpose in keeping them, and even deleting such data could potentially enhance future trust in the privacy of users’ voting choices.
As for recording the voting history of public and known neurons, it seems unnecessary at this stage to make any distinction between public neurons and those registered as known. My reasoning is that a neuron becomes public by choice of its controller, while (for now) the registration of a neuron as known depends solely on decisions within the NNS. As you know, I’m not a fan of resetting records if it might threaten transparency. The 5 year period you suggested, @wpb, seems reasonable, but in my view, 8 years would be more “symbolic” If we were to implement a reset at all, it might not even be necessary with future optimizations and expansions of this solution through additional canisters. This would make storing older voting data by platforms like the ICP Dashboard unnecessary.
Resetting the voting history of private neurons (except for a record of the neuron’s last activity time) to retain only the history required for cyclical reward rounds would free up significant space in the NNS governance canister for new voting records. However, I would suggest transferring the voting history to a separate NNS subnet canister (for example, for records after rewards are settled) that would store the voting history of public and known neurons.
Hi both and thanks for the discussion!
This is an interesting idea.
for private neurons, the on-chain voting history is required and essential only up to the point of the next reward distribution round.
I am not sure I quite agree here. I think also voters that don’t want to share their vote with anyone might want to come back and see how they voted, for example to check whether the following mechanism kicked in or they should change following.
Moreover, the recent ballots are also needed to show to a user on which proposals they can still vote. This is used for example in the NNS dapp to show the actionable proposals to users.
Overall, I think it is good to think about which information should be kept longer or possibly forever. This is also reflected by the feature Archiving of NNS proposals which is on the public roadmap).
I think we should think this in the bigger context of this feature and discuss there what information the NNS should keep and how this can best be designed - e.g., we might want a solution that scales even more so we can keep information about some proposals forever.
I understand that voters might want to return and check something. I mentioned the idea of deleting the voting history of private neurons as just one of the possible future options, so I’m glad we’re discussing it. I simply believe that the NNS subnet is quite unique. Unlike many others, it doesn’t burning cycles, which makes sense, given it is one of the cores of the entire ecosystem. However, if it is meant to store data for the NNS community, we should approach the subject with care, considering the potentially limited storage space.
If certain data is stored in a public subnet to serve the entire community but remains private, over time, it could end up as information that’s unreadable and unused by anyone, existing indefinitely - almost like “space debris.” It technically belongs to someone, but it doesn’t serve anyone anymore. Apologies if this comparison doesn’t align perfectly in every aspect, but I’m trying to illustrate my perspective on why we should retain data indefinitely if it has historical value for future generations of voters. I simply proposed that the voting history for a given neuron could be deleted right after the reward round, meaning once the proposal’s voting period has ended and rewards have been distributed.
Now, I’m proposing only an increase in the record limit from 100 to 1000 per proposal. I’m gathering all opinions before submitting a formal proposal, and in the meantime, we can discuss potential solutions for storage issues in the long-term future. I’m glad that some of the good ideas are already included in the public DFINITY roadmap
This isn’t yet possible, but we are currently working on migrating Governance data into stable storage, which would make it feasible in the future to start changing the data retention policies in the future.
Eventually, a secondary archive canister would likely be needed to have permanent on-chain proposal storage, but that would be a bigger project.
Let me know which higher value than 100 you think would be most optimal, as in my opinion, most proposals use only a very marginal portion of the maximum available memory limit per proposal, which theoretically allows us to safely scale this parameter up to 1000.
Hey @tiago89, there may not be a mistake in that maximum_node_provider_rewards_e8s parameter. It was changed in proposal 64141, which was the last proposal that affected that parameter. The number that @krzysztofzelazko used for that parameter is the same.
At present, most of the data in the NNS Governance canister is stored in Heap memory, which only gives us 4GB to work with, and requires serializing and deserializing on upgrades.
That makes increasing the data retention potentially dangerous at the present moment, so we are avoiding increasing these limits until we have migrated all the data into stable memory.
Additionally, increasing the number of ballots to be kept would not increase the voting history kept for each neuron. That is a separate field held on each neuron at present.
The migration to stable memory requires a lot of preparatory work, as the performance using stable structures is quite a bit slower than the raw performance of heap memory, and we have to optimize many code paths to get ready. At that point, we can re-evaluate the impacts of storing more proposals and voting history.
This work is in progress, and we hope to be finished with it in the first few months of 2025.
If we were to implement a reset at all, it might not even be necessary with future optimizations and expansions of this solution through additional canisters. This would make storing older voting data by platforms like the 
