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

Perform bisection when verifying headers using the light client #51

Merged
merged 5 commits into from
Apr 14, 2020

Conversation

romac
Copy link
Member

@romac romac commented Apr 9, 2020

Closes: #49

Description

This PR implements proposal B described in #49.

All tasks spawned in the start command are now spawned on a local task set which executes them all on the same thread, ie. the main thread.

This seems like an acceptable solution to me given that the overall architecture of the relayer and the light client will likely change quite a bit in the coming weeks.


For contributor use:

  • Unit tests written
  • Added test to CI if applicable
  • Updated CHANGELOG_PENDING.md
  • Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
  • Updated relevant documentation (docs/) and code comments
  • Re-reviewed Files changed in the Github PR explorer

@romac romac requested a review from ancazamfir as a code owner April 9, 2020 21:27
@ancazamfir
Copy link
Collaborator

I tried to run the relayer on this branch and I don't see the light client update header messages. Just these:
Apr 10 10:26:56.933 INFO relayer_cli::relayer: Relayer is running

If I remove the relay thread then the relayer finishes quietly after spawning light client... messages

ancas-macbook-pro:1ibc-rs ancaz$ cargo run --bin relayer -- -c simple_config.toml start
...
Apr 10 10:30:21.657  INFO relayer_cli::commands::start: spawning light client chain.id=ibc0
Apr 10 10:30:21.658  INFO relayer_cli::commands::start: spawning light client chain.id=ibc1
ancas-macbook-pro:1ibc-rs ancaz$ 

Maybe I am doing smthg wrong, it's the first time I try this; followed the instructions from: https://github.com/informalsystems/ibc-rs/blob/master/README.md

@romac
Copy link
Member Author

romac commented Apr 10, 2020

Yeah, I get the same output too. My bad, I should have mentioned that and marked the PR as a draft. Will let you know once(if) it works and is actually ready for review.

@romac romac force-pushed the romac/light-client-bisection branch from a5ef581 to 05dc0d9 Compare April 10, 2020 09:16
@ancazamfir
Copy link
Collaborator

ah ok, thought is ready for review :)

@romac
Copy link
Member Author

romac commented Apr 10, 2020

I had forgotten to .await the client task 🤦‍♂️

This now works as expected but has not been rebased on master yet.

I rebased locally, but the start command now fails because of a deserialization error when fetching the TrustOptions from the store. Might be an issue with tendermint-rs@v0.33. Will investigate further!

@informalsystems informalsystems deleted a comment from codecov-io Apr 10, 2020
@romac
Copy link
Member Author

romac commented Apr 10, 2020

@romac
Copy link
Member Author

romac commented Apr 10, 2020

Unblocked now that informalsystems/tendermint-rs#210 has been merged.

@romac romac force-pushed the romac/light-client-bisection branch from 05dc0d9 to a6a5473 Compare April 10, 2020 13:18
@informalsystems informalsystems deleted a comment from codecov-io Apr 10, 2020
@romac
Copy link
Member Author

romac commented Apr 10, 2020

@ancazamfir Ready for review.

Copy link
Collaborator

@ancazamfir ancazamfir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This looks good to me, a couple minor comments. There's a bit more cleanup imo that needs to be done, but we can do in a separate PR.

interval.tick().await;
}
}

async fn update_headers<C: Chain, S: Store<C>>(mut client: Client<C, S>) {
async fn update_client<C: Chain, S: Store<C>>(mut client: Client<C, S>) {
debug!(chain.id = %client.chain().id(), "updating headers");

let mut interval = tokio::time::interval(Duration::from_secs(3));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the documentation: "Note that when it starts, it produces item too." So the interval.tick().await; should be the first in the loop. I looked at the logs when running with two chains and noticed two updates per chain without the wait when starting the relayer.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch!

debug!(chain.id = %client.chain().id(), "updating headers");

let mut interval = tokio::time::interval(Duration::from_secs(3));

loop {
info!(chain.id = %client.chain().id(), "updating client");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
info!(chain.id = %client.chain().id(), "updating client");
interval.tick().await;
info!(chain.id = %client.chain().id(), "updating client");

and remove from end of loop.

debug!(chain.id = %client.chain().id(), "updating headers");

let mut interval = tokio::time::interval(Duration::from_secs(3));

loop {
info!(chain.id = %client.chain().id(), "updating client");

let result = client.update(SystemTime::now()).await;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is the only place we should upate client, i.e. remove from client.rs

--- a/relayer/relay/src/client.rs
+++ b/relayer/relay/src/client.rs
@@ -93,10 +93,6 @@ where
             client.init_with_trust_options(trust_options).await?;
         }

-        // Perform an update already, to make sure the client is up-to-date.
-        // TODO: Should we leave this up to the responsibility of the caller?
-        let _ = client.update(SystemTime::now()).await?;
-
         Ok(client)
     }```

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link
Collaborator

@ancazamfir ancazamfir left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After restarting the relayer that had previously sync-ed some header, there are some debug messages about hashes not matching and trusted options height < header height in store. I think we need to look into this a bit, not sure why they occur as this is seen with good providers/ chains. Raised #53 for this.

@romac
Copy link
Member Author

romac commented Apr 14, 2020

Just addressed your comments :)

@ancazamfir
Copy link
Collaborator

Just addressed your comments :)

Looks good! Thanks @romac!

@romac romac merged commit 8cd5bd0 into master Apr 14, 2020
@romac romac deleted the romac/light-client-bisection branch April 14, 2020 10:17
hu55a1n1 pushed a commit to hu55a1n1/hermes that referenced this pull request Sep 13, 2022
…rmalsystems#51)

* Perform bisection when verifying new headers in client

* Fix typo in README

* Tick interval at the beginning of the client loop

* Do not update the light client upon creation

* Improve client logs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Perform full verification when verifying headers using the light client
2 participants