-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Conversation
6f48202
to
64facf2
Compare
There was a problem hiding this 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] |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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
- 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>
3190082
to
7e3ba96
Compare
1c50045
to
838a716
Compare
Updated tests to be more different.
#[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> { |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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). |
There was a problem hiding this comment.
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] |
There was a problem hiding this comment.
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`
@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. |
crates/chain-config/Cargo.toml
Outdated
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" |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved!=) Voxelot's changes, thank you <3 |
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
andChainConfig
to have rules for the block's time of the network and separate rules for block production.NodeRole::Producer
andNodeRole::Validator
. Based on the role, we will create afuel_core_poa::Config
.Never
fromBlockProduction
fromChainConfig
because it is the block production information of thePoA
.No unit tests right now.