-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Add block announce validator. #3346
Changes from 10 commits
88f0b53
877419c
dabb6d8
89f26a5
f05b2d1
ce11dd9
5d279bf
8becf1f
a5d2802
87d20bc
4a2fd48
acc2b11
4adb484
ca2aa07
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,66 @@ | ||
// Copyright 2019 Parity Technologies (UK) Ltd. | ||
// This file is part of Substrate. | ||
// | ||
// Substrate is free software: you can redistribute it and/or modify | ||
// it under the terms of the GNU General Public License as published by | ||
// the Free Software Foundation, either version 3 of the License, or | ||
// (at your option) any later version. | ||
// | ||
// Substrate is distributed in the hope that it will be useful, | ||
// but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
// GNU General Public License for more details. | ||
// | ||
// You should have received a copy of the GNU General Public License | ||
// along with Substrate. If not, see <http://www.gnu.org/licenses/>. | ||
|
||
bkchr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
//! Block announcement validation. | ||
|
||
use crate::BlockStatus; | ||
use sr_primitives::{generic::BlockId, traits::Block}; | ||
use std::{error::Error, sync::Arc}; | ||
|
||
/// A type which provides access to chain information. | ||
pub trait Chain<B: Block> { | ||
/// Retrieve the status of the block denoted by the given [`BlockId`]. | ||
fn block_status(&self, id: &BlockId<B>) -> Result<BlockStatus, Box<dyn Error + Send>>; | ||
} | ||
|
||
impl<T: Chain<B>, B: Block> Chain<B> for Arc<T> { | ||
fn block_status(&self, id: &BlockId<B>) -> Result<BlockStatus, Box<dyn Error + Send>> { | ||
(&**self).block_status(id) | ||
} | ||
} | ||
|
||
/// Result of `BlockAnnounceValidator::validate`. | ||
#[derive(Debug, PartialEq, Eq)] | ||
pub enum Validation { | ||
/// Valid block announcement. | ||
Success, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why not call them There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Typical Rust style would have this be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think naming the type "Valid" can be misleading because "valid" is already biased towards "yes". Saying something valid is not valid feels a little inconsistent to me, so at a minimum I would like to see a neutral name. I agree that the "Result" suffix should better be avoided, especially since the type name will often be embedded in another |
||
/// Invalid block announcement. | ||
Failure, | ||
} | ||
|
||
/// Type which checks incoming block announcements. | ||
pub trait BlockAnnounceValidator<B: Block> { | ||
/// Validate the announced header and its associated data. | ||
fn validate(&mut self, header: &B::Header, data: &[u8]) -> Result<Validation, Box<dyn Error + Send>>; | ||
} | ||
|
||
/// Default implementation of `BlockAnnounceValidator`. | ||
#[derive(Debug)] | ||
pub struct DefaultBlockAnnounceValidator<C> { | ||
Demi-Marie marked this conversation as resolved.
Show resolved
Hide resolved
|
||
chain: C | ||
} | ||
|
||
impl<C> DefaultBlockAnnounceValidator<C> { | ||
pub fn new(chain: C) -> Self { | ||
Self { chain } | ||
} | ||
} | ||
|
||
impl<B: Block, C: Chain<B>> BlockAnnounceValidator<B> for DefaultBlockAnnounceValidator<C> { | ||
fn validate(&mut self, _h: &B::Header, _d: &[u8]) -> Result<Validation, Box<dyn Error + Send>> { | ||
Ok(Validation::Success) | ||
} | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -261,6 +261,8 @@ pub mod generic { | |
pub struct BlockAnnounce<H> { | ||
/// New block header. | ||
pub header: H, | ||
/// Data associated with this block announcement, e.g. a candidate message. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The |
||
pub data: Vec<u8> | ||
} | ||
|
||
#[derive(Debug, PartialEq, Eq, Clone, Encode, Decode)] | ||
|
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.
@tomusdrw solved or needs an issue?
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 seems that we are notifying about all blocks (not only the new best ones), so I think we don't really need any special handling here. CC @jacogr what would you expect in case of re-orgs and storage changes subscription?
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.
If there is a re-org, would expect the subscriptions to pass through the most-recent-actual-state values.
Effectively the lasted values from the subscription and
state_getStorage
should match - both should reflect the current chain state.