Struct CertBySenderVerifier 

pub struct CertBySenderVerifier<T: NodeType, C: Verifiable<T>> {
    tasks: JoinMap<T::SignatureKey, Option<ValidCert<C::Output>>>,
    pending: HashMap<T::SignatureKey, C>,
    completed: BTreeSet<ViewNumber>,
    lower_bound: ViewNumber,
    membership: EpochMembershipCoordinator<T>,
    upgrade_lock: UpgradeLock<T>,
    invalid_certs: u64,
}

Verifies certificates off the main coordinator thread.

Unlike CertVerifier, these certificates are keyed by sender key instead of view/epoch, helping a lagging node jump to the frontier. While a certificate is verified, subsequent requests are dropped which bounds each peer to one verification at a time.

Fields

tasks: JoinMap<T::SignatureKey, Option<ValidCert<C::Output>>>

pending: HashMap<T::SignatureKey, C>

completed: BTreeSet<ViewNumber>

lower_bound: ViewNumber

membership: EpochMembershipCoordinator<T>

upgrade_lock: UpgradeLock<T>

invalid_certs: u64

Implementations

impl<T: NodeType, C: Verifiable<T> + Send + 'static> CertBySenderVerifier<T, C>

where C::Output: HasViewNumber,

pub fn new( membership: EpochMembershipCoordinator<T>, upgrade_lock: UpgradeLock<T>, ) -> Self

pub fn verify( &mut self, sender: T::SignatureKey, cert: C, ) -> Option<EpochNumber>

Submit an item received from sender for verification.

Dropped if the sender’s previous submission is still being verified. If the epoch’s membership isn’t ready the item is held and its epoch returned so the caller can drive that epoch’s catchup.

pub fn mark_completed(&mut self, view: ViewNumber)

Record that this view’s item was completed by other means.

This can happen locally from votes for example.

pub fn retry_pending(&mut self) -> Vec<EpochNumber>

Re-attempt any items deferred because their epoch stake table wasn’t available. Returns the epochs whose stake table is still missing so the caller can keep driving their catchup.

pub async fn next(&mut self) -> Option<ValidCert<C::Output>>

pub fn gc(&mut self, view: ViewNumber)

pub fn num_invalid_certs(&self) -> u64