tlsnotary / tlsn

Rust implementation of the TLSNotary protocol
https://tlsnotary.org
279 stars 75 forks source link

wasm: intermitten issue in p2p flow #579

Open 0xtsukino opened 2 months ago

0xtsukino commented 2 months ago

Found an intermitten issue while integrating with p2p flow in js. Here is the setup i am using.

const verifier = new Verifier(...);
cosnt prover = new Prover(...);

// Connect verifier to rendezvous
await verifier.connect(...);
const verifiedDataPromise = verifier.verify();

await prover.setup(...);
await prover.sendRequest(...);
await prover.reveal(...);

const verifiedData = await verifiedDataPromise;

The Verifier throw the following errors:

ERROR verifier{id="6931d2ad63340d3a1fb1a5c1e3f4454c5a518164d6de5ad272e744832355ee02"}:setup:poll{role=Server}:server_handle_inbound: uid_mux::yamux: error=decode error: decode error: unknown version: 123
ERROR verifier{id="6931d2ad63340d3a1fb1a5c1e3f4454c5a518164d6de5ad272e744832355ee02"}:setup: tlsn_common::mux: mux error: Decode(Header(Version(123)))

Sometimes the Prover will throw the following, but not always. Screenshot 2024-09-01 at 8 29 55 PM

sinui0 commented 2 months ago

This looks like potentially an issue with your WS proxy. Given the error from the mux mux error: Decode(Header(Version(123))) that indicates corruption in the transport layer. If it were an application layer issue the error would occur during deserialization.

0xtsukino commented 2 months ago

I see. Any details on what the Verifier is expecting at that moment (after verifier.verify())? Is it exchanging data with the Prover at that moment?

sinui0 commented 2 months ago

Yes, the verifier will be waiting for a message. Are you sure that the websocket proxy isn't buffering some data between runs? I can't think of anything else which would cause this kind of transport frame corruption.

sinui0 commented 2 months ago

Is this resolved?

0xtsukino commented 2 months ago

not resolved yet, still couldnt identify the root cause