How can a client detects a fork?

For example, initially the ledger state version goes like 1 - 2 - 3. At this point, the validators collectively agree to make a fork based on version 2. So the ledger history now looks like 1 - 2 - 3’ - 4’.

Before the fork, a client already has knowledge about state version 3. Now it queries the network and gets a new state 4’. How can it detect the fork and find out 4’ is not a successor of 3?

Hi @the729! In this case, the client would perform a query with a “known version” of 3. This would result in a proof coming back relative to this known version. Let’s say that you have seen 3 which has a hash of 0x1234. Now you will get a proof of 4’ relative to 3’ (because the validator is returning a proof relative to what it thinks is version 3). Based on the resultant proof, you will be able to detect that the returned values do not match up to the hash you expected to occur at 3 (0x1234 in this case).

Is this logic currently implemented?

I didn’t see any difference in the responses to whatever client_known_version I gave to UpdateToLatestLedgerRequests.

The response only includes ledger info with signatures from the validators. And I don’t see any code verifying the relativity from client_known_version to the current version.

You are correct that it is not yet implemented. It’s on our roadmap but hasn’t yet been finished