-
Notifications
You must be signed in to change notification settings - Fork 795
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
Conversation
rai/node/rpc.cpp
Outdated
@@ -1578,6 +1579,25 @@ void rai::rpc_handler::frontiers () | |||
response_errors (); | |||
} | |||
|
|||
void rai::rpc_handler::is_confirmed () |
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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?
rai/node/node.cpp
Outdated
{ | ||
// We always re-process the block to guarantee it's marked as confirmed |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
4d16050
to
8052e80
Compare
TODO: tally will be inconsistent with winner. Is this a problem?
0f86dc4
to
f8164d1
Compare
f8164d1
to
892f7fe
Compare
We're moving this to V18.0 as it needs more testing before we're willing to accept it. |
An separate implementation of this is making progress. This PR has way too many merge conflicts to be merged, so I'm closing it. |
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:
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:
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).