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

Implement a Lazy Bootstrapping Client #995

Closed
rkeene opened this issue Jul 25, 2018 · 1 comment

Comments

Projects
None yet
1 participant
@rkeene
Copy link
Contributor

commented Jul 25, 2018

Currently the bootstrapping process is active and tries to import the entire ledger to every node, account by account.

In order to ensure that the blocks are valid in the face of forks, many blocks have to be voted on during bootstrapping, which is slow, bandwidth intensive, and I/O intensive.

However, a more lazy approach can be taken. On the real-time peer-to-peer network, new blocks are constantly being voted on and, ultimately, confirmed by the network. Each block is a node, and likely a head, of a Merkle tree where each node has 1 or 2 preceding nodes (the "previous" block, unless its the first block in a chain, and also the "link" or "source" block, if it is a receiving block).

Therefore, the confirmation of a single block also confirms MANY other blocks -- on a highly-connected (on the Merkle tree) account, it can confirm a significant amount of blocks without additional voting.

This ticket is to implement the client portion of this bootstrapping into the Nano node.

When a new block is confirmed on the network, the bootstrapping client should:

  1. Verify it does not already have the block
    a. If so: Do nothing
  2. Verify the block does not replace an existing block
    a. If so: Rollback
  3. Determine the account the block belongs to
  4. Determine the frontier for that account
  5. Determine if there is a "gap" between the block and the frontier
    a. If not: Insert the block and continue
    b. If so, issue a "bulk_pull" on the bootstrapping network from the block just verified down to the current local frontier; Process all blocks as below as well
  6. If the block is a receiving block, the sending block must have already been confirmed, perform this entire procedure from that block down
  7. Insert the confirmed blocks into the ledger database as confirmed blocks, transactionally

Additionally, nodes may be interested in specific but not active accounts -- such as accounts belonging to one of their local wallets. For these accounts a new bootstrap command called "bulk_pull_account" is being created to request blocks related to these accounts. For now, this work does not yet include pulling in those accounts explicitly.

@rkeene

This comment has been minimized.

Copy link
Contributor Author

commented Nov 30, 2018

This was implemented as part of #1332

@rkeene rkeene closed this Nov 30, 2018

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.