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

Don't relay packets from other clients/connections #269

Open
webmaster128 opened this issue May 21, 2023 · 3 comments
Open

Don't relay packets from other clients/connections #269

webmaster128 opened this issue May 21, 2023 · 3 comments

Comments

@webmaster128
Copy link
Member

In the following logs you see that

  1. Client 07-tendermint-16 is on nois-testnet-005 updated
  2. A packet from channel channel-175 (client 07-tendermint-15) is relayed
  3. A packet from channel channel-198 (client 07-tendermint-16) is relayed

But 07-tendermint-15 was not updated by this instance (and should not because this is a different client). Since 2. and 3. are in the same transaction, both packets fail to be received.

As far as I can tell the issue here is that a connection is configured but then the packet search does not filter by connection.


info: Update Client on nois-testnet-005
verbose: Client state height before update: {6 1550903}
verbose: [uni-6] Get latest commit
verbose: [uni-6] Get validator set for height 1550914
verbose: [uni-6] Get header for height 1550914
verbose: [uni-6] Get validator set for height 1550904
verbose: [uni-6] Get header for height 1550904
verbose: [nois-testnet-005] Update Tendermint client 07-tendermint-16 to: trustedHeight={6 1550903} signed header height=1550914
verbose: Client state height after update: {6 1550914}
verbose: Creating proofs with height: {6 1550914}
verbose: [nois-testnet-005] Receive 2 packets..
verbose: [nois-testnet-005] Sending packet #10510 from nois-testnet-005:channel-175 {"amount":"50000000","denom":"transfer/channel-175/unois","receiver":"nois1xgnpkzr86cl7d2mjwdhalyt9md3vyfk5d66r9j4lfvsgkjc6wthse2q53d","sender":"juno1pjpntyvkxeuxd709jlupuea3xzxlzsfq574kqefv77fr2kcg4mcqvwqedq"}
verbose: [nois-testnet-005] Sending packet #9056 from nois-testnet-005:channel-198 {"request_beacon":{"after":"1684707607074764114","origin":"eyJzZW5kZXIiOiJqdW5vMTRldXQ4NXYyM3MweWtlY241c3RsZGN4ZW4wZnNjbTJhdTdhOTVrM2RjOHM0cWs3MmprNnE0NHdybHYiLCJqb2JfaWQiOiJQaW5nIDAuODk4NTAwMTA2MjQyODM1In0="}}
error: Caught error: Broadcasting transaction failed with code 7 (codespace: client). Log: receive packet verification failed: couldn't verify counterparty packet commitment: failed packet commitment verification for client (07-tendermint-15): please ensure the proof was constructed against a height that exists on the client: consensus state does not exist for height 6-1550914: consensus state not found {"code":7,"codespace":"client","log":"receive packet verification failed: couldn't verify counterparty packet commitment: failed packet commitment verification for client (07-tendermint-15): please ensure the proof was constructed against a height that exists on the client: consensus state does not exist for height 6-1550914: consensus state not found"}

@ethanfrey
Copy link
Contributor

Here is the relevant code where we determine the packets to get: https://github.com/confio/ts-relayer/blob/main/src/lib/link.ts#L576-L582

Which calls into querySentPackets https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L121-L124

Both final queries to get the packets (from tx and from block events), include the connection id:

https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L73-L79 and https://github.com/confio/ts-relayer/blob/main/src/lib/endpoint.ts#L101-L107

No obvious cause.
I do think I assumed only one connection per client, so if that doesn't hold true the code may have bugs mapping them

@webmaster128
Copy link
Member Author

webmaster128 commented Jun 22, 2023

I'm pretty sure this is what happens: A transaction that contains a packet for the right connection is found via the tx search linked above. However, that transaction then also contains packets for other connections. Since there is no packet level filtering implemented, all packets are relayed.

@ethanfrey
Copy link
Contributor

Ah, interesting observation

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

No branches or pull requests

2 participants