Avoids circular dependency related to block creation between Consensus and Execution

[diegoximenes]

Resolves NIT-3189

Avoids circular dependency related to block creation between Consensus and Execution:

• Moves sequencing triggering from Execution to Consensus. With that all triggers that create blocks are in a single place, Consensus, which simplifies lock handling related to that operation.
• Execution doesn't call Consensus to write messages related to sequenced transactions anymore. With this PR Consensus calls Execution triggering a sequencing operation. In that call Execution returns a sequenced message to Consensus. Consensus then processes this sequenced message, and finally calls Execution again to end sequencing, e.g., appending the related block to the blockchain.

[tsahee]

initial

[tsahee]

Some more notes about forward/pause.

I think this is a good direction, but it touches a lot of delicate code so we'll need to be very careful with it.

[codecov]

Codecov Report

❌ Patch coverage is 57.65199% with 202 lines in your changes missing coverage. Please review.
✅ Project coverage is 22.67%. Comparing base (a9286ce) to head (25d311e).
⚠️ Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3111      +/-   ##
==========================================
+ Coverage   22.62%   22.67%   +0.04%     
==========================================
  Files         387      387              
  Lines       58608    58664      +56     
==========================================
+ Hits        13262    13304      +42     
- Misses      43307    43318      +11     
- Partials     2039     2042       +3     

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bragaigor]

Maybe I'm missing some context, but isn't there a possibility to starve createBlockWithRegularTxs() if Sequencer keeps getting delayed messages? Or not a problem here?

[diegoximenes]

You are right.
I will add some randomization, or alternate which kind of transaction to sequence first.
Good catch 🙂

[diegoximenes]

Strategy to address that:

• If next delayed msg to be sequence is too old:
  • next will be delayed msg turn, will wait 0ms
• Else if is sequenced delayed msg turn:
  • If there are normal txs to be sequenced: next will be normal tx turn, will wait 250ms
  • Else if there are delayed msgs to be sequenced: next will be delayed msg turn, will wait 0ms
  • Else: next will be normal tx turn, will wait 250ms
• Else is normal tx turn:
  • if there are delayed msgs to be sequenced: next will be delayed msg turn, will wait 0ms
  • Else If there are normal txs to be sequenced: next will be normal tx turn, will wait 250ms (or 0ms, since today we retry immediately in some scenarios, such as if the block was not created due to all txs failing)
  • Else: next will be normal tx turn, will wait 250ms