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

Store confirmation height in database to allow synchronously querying confirmation #1303

Closed

Conversation

PlasmaPower
Copy link
Contributor

@PlasmaPower PlasmaPower commented Oct 14, 2018

As a byproduct, this results in all confirmed blocks being immediately cemented. Attempting to replace a confirmed block with a different confirmed block results in a crash (from release_assert).

New terminology:

  • Block account height, aka block height or a block's account height: given a block, the block height of its account if the block was the frontier. For an open block, this is always 1.
  • Block sideband: this is all the information stored alongside a block in the database. Previously, this was just the block's successor hash, but this PR also stores the block's account height.

New information in the database:

  • rai::account_info::confirmation_height: the maximum account height of any confirmed block in the account. Any blocks in the account with an account height less than the confirmation height have been confirmed.
  • rai::pending_info::source_account_height: the source block's account height. Used to check if a pending block has been confirmed.
  • rai::block_sideband::account_height: the account height of the block. This is needed when we roll back a receive block and have to recreate the pending entry.

New node logic:

  • When searching for pending incoming sends, we now always confirm_req the source's account frontier instead of the specific send block.
  • process_confirmed is now recursively called for the confirmed block's previously unconfirmed dependencies, and this process also updates the confirmation_height of the account (note: this is not actually implemented with recursion to avoid running into a stack overflow).

rai/node/rpc.cpp Outdated
@@ -1578,6 +1579,25 @@ void rai::rpc_handler::frontiers ()
response_errors ();
}

void rai::rpc_handler::is_confirmed ()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest something more consistent with other RPCs, such as
"block_confirmed"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I also rename the rai::node and rai::ledger methods?

{
// We always re-process the block to guarantee it's marked as confirmed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this result in terrible performance? Single write transaction for each confirmed block

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, though it could cause a lot of problems if block_confirmed sometimes returned false for blocks from the callback.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I could move the block observer call into process_return_one after processing a confirmed block. That'd actually make a lot of sense.

@rkeene rkeene added enhancement major This item indicates the need for or supplies a major or notable change labels Oct 15, 2018
@rkeene rkeene added this to the V17.0 milestone Oct 15, 2018
@rkeene rkeene self-requested a review October 23, 2018 17:46
@rkeene
Copy link
Contributor

rkeene commented Nov 13, 2018

We're moving this to V18.0 as it needs more testing before we're willing to accept it.

@PlasmaPower
Copy link
Contributor Author

An separate implementation of this is making progress. This PR has way too many merge conflicts to be merged, so I'm closing it.

@zhyatt zhyatt removed this from the V19.0 milestone Feb 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement high effort remaining major This item indicates the need for or supplies a major or notable change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants