Skip to content

Commit

Permalink
remove old functions
Browse files Browse the repository at this point in the history
  • Loading branch information
@ebuchman
ebuchman committed Dec 31, 2019
1 parent 525c89f commit bb78cf5
Showing 1 changed file with 0 additions and 227 deletions.
227 changes: 0 additions & 227 deletions tendermint/src/lite/verifier.rs
View file
Original file line number Diff line number Diff line change
Expand Up @@ -36,79 +36,6 @@ where
}
}

/// Captures the skipping condition, i.e., it defines when we can trust the header
/// h2 based on a known trusted state.
/// Note that the trusted header included in the trusted state and h2 have already
/// passed basic validation by calling `verify`.
/// `Error::InsufficientVotingPower`is returned when there is not enough intersection
/// between validator sets to have skipping condition true.
pub fn check_support<TS, SH, C, L>(
trusted_state: &TS,
h2: &SH,
trust_threshold: &L,
trusting_period: &Duration,
now: &SystemTime,
) -> Result<(), Error>
where
TS: TrustedState<LastHeader = SH, ValidatorSet = C::ValidatorSet>,
SH: SignedHeader<Commit = C>,
L: TrustThreshold,
C: Commit,
{
let h1 = trusted_state.last_header();
let h1_next_vals = trusted_state.validators();

// TODO(EB): can we move all these checks? it seems the
// is_within doesn't need to happen here and the sequential check
// for vals hash should be part of validate_vals_and_commit. then this function
// is basically just verify_commit_trusting. Would need to update spec as well.
// In sequential case, would still need to return early or not call check_support at all.
is_within_trust_period(h1.header(), trusting_period, now)?;

// check the sequential case
if h2.header().height() == h1.header().height().increment() {
if h2.header().validators_hash() == h1_next_vals.hash() {
// It's sequential, so verify_commit_trusting would be
// redundant with verify since the validators are the same
// when we're not skipping.
return Ok(());
} else {
return Err(Error::InvalidNextValidatorSet);
}
}

// check if enough trusted validators signed to skip to the new height.
verify_commit_trusting(h1_next_vals, h2.commit(), trust_threshold)
}

// XXX: Replaced by validate_signed_header_and_vals.
// Remove when removing check_support
fn validate_vals_and_commit<H, V, C>(header: &H, commit: &C, vals: &V) -> Result<(), Error>
where
H: Header,
V: ValidatorSet,
C: Commit,
{
// ensure the header validators match these validators
if header.validators_hash() != vals.hash() {
return Err(Error::InvalidValidatorSet);
}

// ensure the header matches the commit
if header.hash() != commit.header_hash() {
return Err(Error::InvalidCommitValue);
}

// ensure the validator size matches the commit size
// NOTE: this is commit structure specifc and should be
// hidden from the light client ...
if vals.len() != commit.votes_len() {
return Err(Error::InvalidCommitLength);
}

Ok(())
}

/// Validate the validators, next validators, and commit against the header.
// TODO(EB): consider making this a method on Commit so the details are hidden,
// and so we can remove the votes_len() method (that check would be part of the
Expand Down Expand Up @@ -149,22 +76,6 @@ where
Ok(())
}

/// Verify the commit is valid from the given validators for the header.
pub fn verify<SH, C>(signed_header: &SH, validators: &C::ValidatorSet) -> Result<(), Error>
where
SH: SignedHeader<Commit = C>,
C: Commit,
{
let header = signed_header.header();
let commit = signed_header.commit();

// basic validatity checks that header, commit, and vals match up
validate_vals_and_commit(header, commit, validators)?;

// ensure that +2/3 validators signed correctly
verify_commit_full(validators, commit)
}

/// Verify that +2/3 of the correct validator set signed this commit.
/// NOTE: these validators are expected to be the correct validators for the commit,
/// but since we're using voting_power_in, we can't actually detect if there's
Expand Down Expand Up @@ -212,144 +123,6 @@ where
Ok(())
}

/// Returns Ok if we can trust the passed in (untrusted) header
/// based on the given trusted state, otherwise returns an Error.
fn can_trust_bisection<TS, SH, C, L, S, R>(
trusted_state: &TS, // h1 in spec
untrusted_header: &SH, // h2 in spec
trust_threshold: &L,
trusting_period: &Duration,
now: &SystemTime,
req: &R,
store: &mut S,
) -> Result<(), Error>
where
TS: TrustedState<LastHeader = SH, ValidatorSet = C::ValidatorSet>,
SH: SignedHeader<Commit = C>,
C: Commit,
L: TrustThreshold,
S: Store<TrustedState = TS>,
R: Requester<SignedHeader = SH, ValidatorSet = C::ValidatorSet>,
{
// can we trust the still untrusted header based on the given trusted state?
match check_support(
trusted_state,
untrusted_header,
trust_threshold,
trusting_period,
now,
) {
Ok(_) => {
let untrusted_next_vals =
req.validator_set(untrusted_header.header().height().increment())?;
let untrusted_state = TS::new(untrusted_header, &untrusted_next_vals);
store.add(&untrusted_state)?;
return Ok(());
}
Err(e) => {
if e != Error::InsufficientVotingPower {
return Err(e);
}
}
}

// Here we can't trust the passed in untrusted header based on the known trusted state.
// Run bisection: try again with a pivot header whose height is in the
// middle of the trusted height and the desired height (h2.height).

let trusted_header = trusted_state.last_header();
let trusted_height: u64 = trusted_header.header().height().value();
let untrusted_height: u64 = untrusted_header.header().height().value();
let pivot: u64 = (trusted_height + untrusted_height) / 2;
let pivot_header = req.signed_header(pivot)?;
let pivot_vals = req.validator_set(pivot)?;

verify(&pivot_header, &pivot_vals)?;

// Can we trust pivot header based on trusted_state?
can_trust_bisection(
trusted_state,
&pivot_header,
trust_threshold,
trusting_period,
now,
req,
store,
)?;
// Trust the header in between the trusted and (still) untrusted height:
let pivot_next_vals = req.validator_set(pivot + 1)?;
let pivot_trusted = TS::new(&pivot_header, &pivot_next_vals);
store.add(&pivot_trusted)?;

// Can we trust the (still) untrusted header based on the (now trusted) "pivot header"?
can_trust_bisection(
&pivot_trusted,
untrusted_header,
trust_threshold,
trusting_period,
now,
req,
store,
)?;
// Add header (and corresponding next validators) to trusted state store:
let untrusted_next_vals = req.validator_set(untrusted_header.header().height().increment())?;
let untrusted_state = TS::new(untrusted_header, &untrusted_next_vals);
store.add(&untrusted_state)?;

Ok(())
}

/// This function captures the high level logic of the light client verification, i.e.,
/// an application call to the light client module to (optionally download) and
/// verify a header for some height.
pub fn verify_header<TS, SH, C, L, S, R>(
height: Height,
trust_threshold: &L,
trusting_period: &Duration,
now: &SystemTime,
req: &R,
store: &mut S,
) -> Result<(), Error>
where
TS: TrustedState<LastHeader = SH, ValidatorSet = C::ValidatorSet>,
L: TrustThreshold,
S: Store<TrustedState = TS>,
R: Requester<SignedHeader = SH, ValidatorSet = C::ValidatorSet>,
C: Commit,
SH: SignedHeader<Commit = C>,
{
// Check if we already trusted a header at the given height and it didn't expire:
if let Ok(ts2) = store.get(height) {
is_within_trust_period(ts2.last_header().header(), trusting_period, now)?
}

// We haven't trusted a header at given height yet. Request it:
let sh2 = req.signed_header(height)?;
let sh2_vals = req.validator_set(height)?;
verify(&sh2, &sh2_vals)?;
is_within_trust_period(sh2.header(), trusting_period, now)?;

// Get the highest trusted header with height lower than sh2's.
let sh1_trusted = store.get_smaller_or_equal(height)?;
can_trust_bisection(
&sh1_trusted,
&sh2,
trust_threshold,
trusting_period,
now,
req,
store,
)?;

// TODO(Liamsi): The spec re-checks if we are still in trust period here
// and stores the now trusted header again.
// Figure out if we want to store it here or in can_trust_bisection!
// My understanding is: with the current impl, we either bubbled up an
// error, or, successfully added sh2 (and its nex vals) to the trusted store here.

Ok(())
}

mod tests {
use super::*;
use crate::{hash::Algorithm, Hash};
Expand Down

0 comments on commit bb78cf5

Please sign in to comment.