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

External block verifier #916

Merged
merged 28 commits into from
Jan 23, 2023
Merged

External block verifier #916

merged 28 commits into from
Jan 23, 2023

Conversation

xgreenx
Copy link
Collaborator

@xgreenx xgreenx commented Jan 18, 2023

Refs: #883

It is the implementation of the block verifier. Right now it provides only one function to verify the block's fields. But in the future, we can add verification of the seals(it is why it holds a relayer) and reuse this verifier in the fuel-core-sync.

Along with the verifier, I changed the fuel_core_poa::Config and ChainConfig to have rules for the block's time of the network and separate rules for block production.

  • Added NodeRole::Producer and NodeRole::Validator. Based on the role, we will create a fuel_core_poa::Config.
  • Removed Never from BlockProduction from ChainConfig because it is the block production information of the PoA.

No unit tests right now.

@xgreenx xgreenx requested a review from a team January 18, 2023 15:30
@xgreenx xgreenx self-assigned this Jan 18, 2023
@xgreenx xgreenx force-pushed the featue/block-verifier branch from 6f48202 to 64facf2 Compare January 19, 2023 00:38
freesig
freesig previously approved these changes Jan 19, 2023
Copy link
Contributor

@freesig freesig left a comment

Choose a reason for hiding this comment

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

Looks good, just one question around the time bounds.

} => {
let previous_block_time = Tai64N::from(prev_header.time());
// The block should be in the range
// [min..max + (max - min)/2]
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't understand why this is true?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Because it is not true=) Created an issue to discuss it #918

I already disabled this check in the production for now.

@xgreenx xgreenx marked this pull request as ready for review January 19, 2023 13:50
@xgreenx xgreenx requested a review from a team January 19, 2023 13:50
Dentosal
Dentosal previously approved these changes Jan 19, 2023
Copy link
Member

@Dentosal Dentosal left a comment

Choose a reason for hiding this comment

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

LGTM; Helpful comments as well

xgreenx and others added 7 commits January 19, 2023 23:50
- Added `debug_assert_eq` to verify that the block header id is an identifier of the block. And that it uses the last hash of the application header.

No unit tests right now.
Co-authored-by: Tom <tomrgowan@gmail.com>
@xgreenx xgreenx force-pushed the feature/block-importer branch from 3190082 to 7e3ba96 Compare January 19, 2023 23:55
@xgreenx xgreenx force-pushed the featue/block-verifier branch from 1c50045 to 838a716 Compare January 19, 2023 23:58
Base automatically changed from feature/block-importer to master January 20, 2023 22:02
#[cfg(feature = "relayer")]
relayer: Default::default(),
#[cfg(feature = "p2p")]
p2p: P2PConfig::<NotInitialized>::default("test_network"),
consensus_key: Some(Secret::new(default_consensus_dev_key().into())),
}
}

pub fn poa_config(&self) -> anyhow::Result<fuel_core_poa::Config> {
Copy link
Member

@Voxelot Voxelot Jan 20, 2023

Choose a reason for hiding this comment

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

Would using impl TryFrom<&Config> for fuel_core_poa::Config instead be more idiomatic rust?

@@ -75,6 +75,9 @@ pub struct Task<D, T, B> {
/// a bit, but doesn't cause any other issues.
pub(crate) last_block_created: Instant,
pub(crate) trigger: Trigger,
// TODO: Consider that the creation of the block takes some time, and maybe we need to
Copy link
Member

Choose a reason for hiding this comment

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

👍🏻

/// This configuration exists because right now consensus module uses the `Tai64::now`
/// during the generation of the block. That means if the node(block producer) was
/// offline for a while, it would not use the expected block time after
/// restarting(it should generate blocks with old timestamps).
Copy link
Member

Choose a reason for hiding this comment

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

(it should generate blocks with old timestamps)

Don't follow why we'd want to forge stale timestamps for blocks. Using older timestamps may make the verification logic easier to implement, but the time should always aim to be as current/correct as possible.

let previous_block_time = Tai64N::from(prev_header.time());

// If the `average_block_time` is 15 seconds, the block should be in the range
// [15..15 + 15/2] -> [15..23]
Copy link
Member

@Voxelot Voxelot Jan 21, 2023

Choose a reason for hiding this comment

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

I think we should only have a min bound, there's no reason to be strict about the max time between blocks and enforce the producer makes blocks fast enough. In poa we really only care about the producer making blocks too fast.

Simplified validation rules of verification.
Removed `NodeRole`. Instead, the production mode is controlled by CLI argument `--instant`, `--interval 13`, `--hybrid 13,14,15`
@Voxelot
Copy link
Member

Voxelot commented Jan 21, 2023

@xgreenx and I were discussing the issue of whether or not we should be validating things like min or max block times in poa.

Ultimately his conclusion was that if something is part of the chainconfig, it should be part of the consensus validation in some way. My conclusion was that we shouldn't add all these verification around timestamps for poa as it could make the system brittle and cause syncing to stall.

So we decided that poa trigger configs should be local parameters that only apply to the authority node, and not included in the chain config. Eventually as our cli args grow in complexity, we could extend clap to support loading from a config file instead which will make it easier to manage.

Green already did the work of stripping the trigger params out of chainconfig, tomorrow I will improve the cli interface a bit using clap argument groups.

fuel-core-storage = { path = "../storage", version = "0.15.1" }
fuel-core-types = { path = "../types", version = "0.15.1", features = [
"serde",
"random",
] }
hex = { version = "0.4", features = ["serde"] }
humantime-serde = "1.1.1"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this actually used anywhere? I removed the dep and ran ci_checks.sh locally and everything seemed to pass for me

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Nope, it is not used, I don't know why we didn't get a warning=D

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Oh, I know=D
image

@xgreenx
Copy link
Collaborator Author

xgreenx commented Jan 23, 2023

Approved!=) Voxelot's changes, thank you <3

@Voxelot Voxelot merged commit 4c65bd2 into master Jan 23, 2023
@Voxelot Voxelot deleted the featue/block-verifier branch January 23, 2023 04:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants