Standardise proposal creation process #1620
Conversation
86667
force-pushed
the
1320-wait-for-txns-before-proposing-an-empty-block-with-an-aggqc
branch
from
3fbacdd
to
f5becaf
Compare
… wait for timeout
|
@JamesHinshelwood Thanks. This is ready for review now. There is lots of |
There was a problem hiding this comment.
LGTM, thank you :)
Cloning State is generally okay, since the underlying DB is wrapped in an Arc so really you're just cloning the few extra bits we store along side it - The one thing to be cautious of there is not to make a bunch of pending change to the state, without calculating the root_hash() (thus keeping those changes in memory) and then cloning those. This is another reason I want to have:
- One struct for state which we store and clone around
- Another struct for the transient state on which we execute transactions and eventually get a root hash from
* feat: pass in qc and aggac to propose block if we have it * feat: separate fn for adding qc and agg to early_block * feat: pull out set timeout code into ready_for_block_proposal() * fix: overwrite early_proposal if view no longer matches * fix: consistency in function naming * fix: set qc at beginning of early_block assembly * fix: do not check votes for new view porposal * fix: always fetch view value from proposal * fix: do not attempt to create early proposal every time were ready to wait for timeout
Yes agreed that would be cleaner - its too easy to make an error with the current code, as i did for these changes. |
github-merge-queue
bot
removed this pull request from the merge queue due to no response for status checks
Have leaders use the same proposal creation process whether via
vote()(proposer for direct-chain with QC) ornew_view()(proposer after previous block missed with AggQC). This closes #1320.