Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Ledger Pruning #1094

Open
rkeene opened this issue Aug 23, 2018 · 9 comments

Comments

Projects
None yet
5 participants
@rkeene
Copy link
Contributor

commented Aug 23, 2018

As a part of node stratification (#1092) not all nodes will need the full ledger, and a mechanism will need to be created to determine which parts of the ledger can be safely discarded on each node. This mechanism will be called pruning.

More details will be added as time goes on.

@ghost

This comment has been minimized.

Copy link

commented Aug 27, 2018

Are you also thinking of a mechanism to make pending deposits compatible with pruning?

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Aug 27, 2018

All mechanisms that involve pruning must not break the ledger. This includes not pruning the sending block for blocks that have no corresponding receiving block but which could in the future (i.e., we are free to locally prune sends to address 0, since there can be no receive block generated from that address).

@ghost

This comment has been minimized.

Copy link

commented Aug 27, 2018

Has the core team ever discussed the possibility of making such that the receive block is automatically generated after its send block, by making changes in the protocol?

@cryptocode

This comment has been minimized.

Copy link
Collaborator

commented Aug 27, 2018

@Omarino99 account holder must sign the receive block, but may not be online/cold wallet/etc

@ghost

This comment has been minimized.

Copy link

commented Aug 27, 2018

@cryptocode what I'm suggesting would be changing the protocol such that receive blocks don't require the signature of the account. I guess this has already been discussed? I know it would bring up different problems though.

@ghost

This comment has been minimized.

Copy link

commented Aug 27, 2018

@rkeene on the roadmap I find this:

Ledger Pruning allows for a much smaller database size. This is done through pruning off blocks other than the frontier (head block) +1 or 2 previous for each account. This feature is dependent on Universal Blocks as they create a snapshot of an account on a per block basis requiring fewer blocks to verify an account.

Isn't this just plain wrong? It would work only on certain accounts. Everyone who doesn't know the protocol believes that it would be possible to prune all accounts, while instead it's not possible.
Link: https://developers.nano.org/roadmap/ledger-pruning/

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Aug 27, 2018

It can be either considered incorrect or incomplete.

Considering it incomplete is the most charitable interpretation, so we shall proceed under that interpretation. The most likely reason it is incomplete is because the author elided the detail that pending information would also be included in the ledger for simplicity or simply failed to consider this additional detail or simply thought it was implied that referable blocks could not be elided.

Ultimately the number of pending blocks are they can go down over time, so they are a very minor factor regarding ledger pruning.

I think the best thing we can do regarding this information is update the roadmap documentation to be more specific.

@anarkrypto

This comment has been minimized.

Copy link

commented Sep 12, 2018

If a spammer wants to increase the ledger, to circumvent the pruning he just needs to transact for millions of different accounts, correct?

@funkspock

This comment has been minimized.

Copy link

commented Dec 26, 2018

@kaiquenunes23 account creation and transaction creation is controlled/limited by PoW.

@rkeene Ledger pruning will prune off blocks other than the frontier (head block) +1 or 2 previous for each account. Which to my understanding [Limits history of transactions]

  1. In addition to this, will pruning take place (periodically?) for accounts below a certain threshold (dust accounts)? or like other coins require that "dust accounts" be topped first before they can be used in transactions (for example XRP requires a base reserve of 20). [Limits number of accounts]

  2. Regarding "dust transactions", will these be rate-limited or blocked below a certain threshold (can this threshold be dynamic based on network conditions)? [Limits number of transactions]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.