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

unsafe warp sync #2366

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

unsafe warp sync #2366

wants to merge 10 commits into from

Conversation

turuslan
Copy link
Contributor

Referenced issues

Description of the Change

  • download only one block with justifications instead of all
  • may specify block number to download, useful to debug/benchmark block execution
  • reuses warp sync logic to let babe/grandpa/beefy work with missing blocks

Possible Drawbacks

  • unsafe, doesn't check chain of justifications, but user must specify this sync mode explicitly

Signed-off-by: turuslan <[email protected]>
Signed-off-by: turuslan <[email protected]>
Copy link
Member

@xDimon xDimon left a comment

Choose a reason for hiding this comment

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

  • CI

Comment on lines 125 to 132
while (true) {
auto m = scale::encode(vote.message, j.round_number, set).value();
auto ok = ed25519.verify(vote.signature, m, vote.id);
if (ok and ok.value()) {
break;
}
++set;
}
Copy link
Member

Choose a reason for hiding this comment

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

Malicious peer can do DoS...

  1. needed reasonable limit of set value.
  2. failure on encoding or verifying should break loop immediately with error (does not matter to continue in this case).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, new protocols should learn from this mistake by storing some redundant information like set id.

Added limit of block number (new set each block).

Signed-off-by: turuslan <[email protected]>

# Conflicts:
#	core/application/app_configuration.hpp
#	core/application/impl/app_configuration_impl.cpp
#	core/application/impl/app_configuration_impl.hpp
#	core/network/warp/sync.cpp
Signed-off-by: turuslan <[email protected]>
Signed-off-by: turuslan <[email protected]>
Signed-off-by: turuslan <[email protected]>
Signed-off-by: turuslan <[email protected]>
Signed-off-by: turuslan <[email protected]>
@turuslan turuslan requested a review from xDimon March 24, 2025 08:38
Copy link
Contributor

@igor-egorov igor-egorov left a comment

Choose a reason for hiding this comment

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

Generally approved, please fix the comments.

Would the node stop after sync or continue with full sync when launched with --unsafe-sync-to?

Should it be launched at the same time with --sync Warp? or just --unsafe-sync-to is enough?

Please address these questions in the pr description.

const GrandpaJustification &j,
consensus::grandpa::AuthoritySetId set) {
HasAuthoritySetChange{header}.scheduled.value();
SL_INFO(log_, "unsafe, block {}, set {}", header.number, set);
Copy link
Contributor

Choose a reason for hiding this comment

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

Now it looks like developer's debugging printf. Since it has info log level, please reword it to be more friendly - replace "unsafe" with meaningful description - what this log line should tell.

Was it started, accomplished, in progress or something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants