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

Propagate block after header validation #590

Merged
merged 30 commits into from
Jan 27, 2023
Merged

Conversation

heifner
Copy link
Member

@heifner heifner commented Dec 22, 2022

Validate block header and propagate blocks without touching the main thread. This should greatly improve block propagation times. This allows a block header to be validated and a block sent to peers without touching the main thread as long as the previous block has been processed. If the previous block has not been fully processed then it is queued for processing on the main thread.

Includes:

  • Removal of unused zipkin calls in net_plugin & removal of unused zipkin in libfc
  • Optimization of broadcast blocks behavior
  • Optimization of peer_block_state_index

Resolves #568
Built on #543

@heifner heifner added the OCI Work exclusive to OCI team label Dec 22, 2022
@heifner heifner marked this pull request as ready for review December 22, 2022 21:38
…read is doing block header validation at a time.
fc_dlog( logger, "signaled pre_accepted_block, blk num = ${num}, id = ${id}", ("num", block->block_num())("id", id) );

auto blk_trace = fc_create_trace_with_id("Block", id);
auto blk_span = fc_create_span(blk_trace, "PreAccepted");
Copy link
Member

Choose a reason for hiding this comment

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

Should FC zipkin related files be removed all together?

Copy link
Member Author

Choose a reason for hiding this comment

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

Now that fc is no longer a submodule, I would think yes.

Copy link
Member Author

Choose a reason for hiding this comment

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

Removed

cmadh pushed a commit to cmadh/leap that referenced this pull request Jan 2, 2023
cmadh pushed a commit to cmadh/leap that referenced this pull request Jan 2, 2023
…OGH-590-shutdown-race

[3.1] Fix race condition on trace_api_plugin shutdown
cmadh pushed a commit to cmadh/leap that referenced this pull request Jan 2, 2023
cmadh pushed a commit to cmadh/leap that referenced this pull request Jan 2, 2023
…OGH-590-into-main

[3.1 -> main] Fix race condition on trace_api_plugin shutdown
@heifner heifner changed the base branch from GH-525-block-propagation-main to main January 18, 2023 20:39
@@ -38,7 +38,7 @@ namespace eosio { namespace chain { namespace plugin_interface {

namespace incoming {
namespace methods {
// synchronously push a block/trx to a single provider, block_state_ptr may be null
// synchronously push a block/trx to a single provider, block_state_ptr may be null
Copy link
Member

Choose a reason for hiding this comment

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

Not sure if this comment is accurate about synchronously push a transaction, as its name is transaction_async. Maybe split block/trx

Copy link
Member Author

Choose a reason for hiding this comment

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

We have a somewhat confusing use of async used in our codebase. async here means that there is a next_function provided which will continue processing. The comment is meant to convey, that regardless of the name, these methods are called synchronously unlike channels which are implemented via post() calls.

@@ -1750,8 +1751,6 @@ producer_plugin_impl::start_block_result producer_plugin_impl::start_block() {
}

try {
_account_fails.clear();
Copy link
Member

Choose a reason for hiding this comment

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

Why is this removed?

Copy link
Member Author

Choose a reason for hiding this comment

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

It is called in abort_block(), no need to call it here.

plugins/net_plugin/net_plugin.cpp Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
@greg7mdp
Copy link
Contributor

@heifner As much as I want to, I don't feel I understand enough to approve the PR, sorry about that!

@heifner heifner requested a review from dimas1185 January 26, 2023 13:36
@arhag arhag requested review from arhag and removed request for dimas1185 January 26, 2023 22:17
@dimas1185
Copy link
Contributor

general comment for future:
it is better to make such changes granular: one PR for removing zipkin, another is for block propagation. In case of we will want to revert any it will be easier to manage.

plugins/net_plugin/net_plugin.cpp Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
plugins/net_plugin/net_plugin.cpp Outdated Show resolved Hide resolved
@heifner heifner requested a review from arhag January 27, 2023 18:53
@heifner heifner merged commit a4c2960 into main Jan 27, 2023
@heifner heifner deleted the GH-568-block-propagate branch January 27, 2023 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
OCI Work exclusive to OCI team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Propagate block after header validation
5 participants