Idea: Pruning for Reps

[My1]

Summary

Similar to my previous idea of "deep pruning" in #3207 (but apparently pruning depth is a thing so I need a new name), this is a new spin on the idea that has a different focus, rather than squeezing out every bit of storage we can, we can also opt to maintain the possibility to vote.

What problem would be solved by this feature?

One well known "issue" with the current state of nodes and voting is that nodes that can vote, are not able to prune because that would make voting a big problem, not only because apparently, online checks work by asking for a vote on a random block, but in a more relevant manner, new nodes could not get their blocks confirmed.

Are there any previous requests for this feature?

I dont think this exact idea has been anywhere except me bringing it up in reddit yesterday [1] and being reposted by Qwahzi in the discord for further discussion, also as mentioned this idea is a spin on my previous idea of not just operating pruning at the block level but going deeper and deleting parts of blocks.

[1] https://www.reddit.com/r/nanocurrency/comments/ua8bv7/comment/i693igu/ [2] https://discord.com/channels/370266023905198083/405506987045158914/968499812989284452 [3] #3207

Do you have a suggested solution?

According to Trashman on discord [1] voting uses only Block Hashes. This means Nodes would not need the whole block data to participate in voting but only the block hashes of any existing block and what would be the next/previous block depending on if you look at the existing block (election root) or the candidate block to be voted upon.

So instead of just removing all blocks we dont need (which in the most optimal case would be all except frontiers), we instead opt to keep a list of hashes for each account, in the order of them on the account chain.

---

A small calculation which is completely ignoring any benefits in more efficient storing or any database overhead for an apples to apples comparison would yield the following amounts of storage for both a full and a pruned Database:

I will be using the current (at the time of drafting) numbers of my node monitor we have 150 751 504 blocks (cemented only) and 27 037 450 accounts.

According to the Nano Docs [2] a block takes 216 Bytes This would amount of 30,3GiB of total data.

A list of pruned blocks for each account would have to be 32 bytes (the account public key/address) per account plus 32 Bytes (block hash) for each pruned block.

Given a full pruning would take place (keep only frontiers, and prune the rest) we would get about 13,62GB including the frontier Blocks, and 8,18GB without the frontier Blocks.

Also while not quite sure, dsiganos on discord (marked as Nano core team member) believes [3] that a list of block hashes is already stored to check if any given block exists, which makes it possibly even easier to actually implement the proposal as the hashes would only need to be grouped and sorted to get voting in a plausible range.

Calculations: https://www.wolframalpha.com/input?i=150751504+*+216+bytes+in+GiB https://www.wolframalpha.com/input?i=%28%28150751504+-+27037450%29+*+64+%2B+27037450*%2832%29%29+bytes+in+GiB https://www.wolframalpha.com/input?i=%28%28150751504+-+27037450%29+*+64+%2B+27037450*%28216%2B32%29%29+bytes+in+GiB

Refs: [1] https://discord.com/channels/370266023905198083/405506987045158914/968553730242904134 [2] https://docs.nano.org/protocol-design/blocks/ [3] https://discord.com/channels/370266023905198083/405506987045158914/968832734082519080

If this feature is approved, would you be willing to submit a pull request with the solution?

I am willing to collaborate

Possible solution

No response

Supporting files

No response

[KaffinPX]

Tbh i dont think its sustainable, easier things like maybe pruning signatures can be better?

[My1]

can you elaborate on what you mean with "sustainable"?

[KaffinPX]

Possibly more spam on Nano.

[My1]

how would this lead to more spam?