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

Light client time followup #137

Closed
1 of 2 tasks
ebuchman opened this issue Feb 2, 2020 · 5 comments
Closed
1 of 2 tasks

Light client time followup #137

ebuchman opened this issue Feb 2, 2020 · 5 comments
Labels
light-client Issues/features which involve the light client
Milestone

Comments

@ebuchman
Copy link
Member

ebuchman commented Feb 2, 2020

As per #110 (comment):

In theory, if we check that time is monotonic, we only need to check that the highest height we're trying to sync to is not ahead of our local clock (ie. we don't need to check this for every header, since all the other headers are less than the highest one). However, if we only check for monotonic time after we've trusted a pivot header, its possible we would trust a pivot header who's time is too far ahead of our local clock, and hence might be outside the trusting period.

@liamsi
Copy link
Member

liamsi commented Feb 12, 2020

Note to myself: the spec calls x clockdrift and it is passed in as a parameter: https://github.com/tendermint/spec/blob/master/spec/consensus/light-client/verification.md#functions-1

@liamsi
Copy link
Member

liamsi commented Feb 12, 2020

Also, isn't there a weird edge case, where this method passes:

func isWithinTrustedPeriod(header Header,
                           trustingPeriod Duration,
                           now Time) bool {

    return header.Time + trustedPeriod > now
}

but only because the trusted header has header.Time > now? This shouldn't happen but shouldn't this still be covered by the spec too?
Note there is a check in the current Rust code:
https://github.com/interchainio/tendermint-rs/blob/a6f7c64e8214d5fbf32adee5ee3b6cbac09ee9da/tendermint/src/lite/verifier.rs#L43-L49
The name DurationOutOfRange stems from a time where we where using the duration_since method from SystemTime.

@ebuchman
Copy link
Member Author

Yes but that's why we need to ensure the header is not ahead of our local clock! ie untrusted_header.bft_time() < now + X

@liamsi
Copy link
Member

liamsi commented Feb 12, 2020

Ah, I think I see how this works: we make sure untrusted_header.bft_time() < now + X but also ensure trusted_header.bft_time() < untrusted_header.bft_time() < now + X. So we also have made sure trusted_header.bft_time() < now (or more precisely now+X) and the case I mentioned would have been caught by this without an extra check that trusted_header.bft_time() <= now.

@liamsi liamsi mentioned this issue Feb 12, 2020
5 tasks
@romac romac added the light-client Issues/features which involve the light client label May 25, 2020
@ebuchman ebuchman added this to the Light Node milestone Jun 2, 2020
@romac romac mentioned this issue Jun 3, 2020
19 tasks
@brapse
Copy link
Contributor

brapse commented Jun 10, 2020

This has been addressed and landed in master:

fn is_within_trust_period(
&self,
header: &Header,
trusting_period: Duration,
clock_drift: Duration,
now: Time,
) -> Result<(), VerificationError> {
ensure!(
header.time < now + clock_drift,
VerificationError::HeaderFromTheFuture {
header_time: header.time,
now
}
);
let expires_at = header.time + trusting_period;
ensure!(
expires_at > now,
VerificationError::NotWithinTrustPeriod {
at: expires_at,
now,
}
);
Ok(())
}
fn is_monotonic_bft_time(
&self,
untrusted_header: &Header,
trusted_header: &Header,
) -> Result<(), VerificationError> {
ensure!(
untrusted_header.time > trusted_header.time,
VerificationError::NonMonotonicBftTime {
header_bft_time: untrusted_header.time,
trusted_header_bft_time: trusted_header.time,
}
);
Ok(())
}

@brapse brapse closed this as completed Jun 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
light-client Issues/features which involve the light client
Projects
None yet
Development

No branches or pull requests

4 participants