-
Notifications
You must be signed in to change notification settings - Fork 4
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
Consensus worker task impl #34
Conversation
257c55c
to
35b387c
Compare
…tegrating some credential checking, etc
2e8be28
to
aa36fb8
Compare
aa36fb8
to
e1f6be6
Compare
fn process_ct_msg<D: Database, E: ExecEngineCtl>( | ||
ctm: ChainTipMessage, |
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 think the function and args are quit abbreviated: what do you think of process_chaintip_message(message: ChainTipMessage...)
?
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.
Will make naming changes in another cleanup pass, there's also too many things that are "trackers".
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.
This looks good. And is huge! Some queries and comments and a couple of nitpicks.
Regarding the nitpicks, I feel like at some places the names are a bit too abbreviated.
// Insert block into pending block tracker and figure out if we | ||
// should switch to it as a potential head. This returns if we | ||
// created a new tip instead of advancing an existing tip. | ||
let cur_tip = cstate.chain_state().chain_tip_blockid(); |
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 thought this would be same as csstate.finalized_tip
. What's the difference?
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.
Finalized is what's been proven on chain. The current tip is where we expect new blocks to be attached and what we treat as the current state. We take it out here since we need to figure out after attaching the block to the pending blocks tree if we're going to switch from the current block to that and how. This is still a bit unfinished and we'll have more sophisticated logic after we've figured out the rest of the block signing mechanics.
params: Arc<Params>, | ||
|
||
/// Underlying database hierarchy that writes ultimately end up on. | ||
// TODO should we move this out? | ||
database: Arc<D>, |
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.
params and database could be out I guess. As I understand, params will be constant during the worker running and is not specific to worker itself.
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.
Still reworking this, I'm planning on a type that specifically manages the current state and splits up the data some more. Not going to act on any of this yet until it's time for more general cleanup.
This is just a skeleton, there's some stuff coming from earlier PRs dripping into this PR. Will rebase.
Resolves: #16